はじめに
3月28日に開催されたAmazon Aurora Dayに参加してきました。
全体的な感想
丸1日のセミナーで非常に勉強になりました。Auroraのプロダクトマネージャ2名は英語でのセッションでしたが、同時通訳もあり、支障なく聴くことができました。
セミナー会場はほぼ満席で、Auroraに対する期待や関心の高さが伺えました。Oracleのライセンス費用は年々上昇していますし、みんな商用DBライセンス費用に苦しんでいるのだろうな・・・ということがよくわかりました。
AuroraがAWS史上最も急成長しているサービスであるということから、今後もAWSはAuroraに力を入れてくるでしょう。今時、システム全体をクラウドに乗せるのに、DBだけCPUライセンスが必要というのは確かに現実的ではありません。商用DBからオープンソースDB、そしてAuroraへの流れは自然な流れなのかもしれません。
【Keynote1】Amazon Aurora with MySQL compatibility最新情報～MySQL5.7対応やプレビュー機能の狙い～
スピーカー
Sirish Chandrasekaran Principal Product Manager
なぜAuroraを作ったのか？
- Intuit社の事例
Auroraとは
- DBをクラウド環境のために再構築
特徴
- スケールアウト、分散、マルチテナントデザイン
- AWSを活用した、サービス指向アーキテクチャ
- フルマネージドサービス、自動化されたタスク
- ハイエンドDBのような性能と可用性
- オープンソースDBのようなシンプルさとコスト効率
- MySQLやPostgreSQLとの互換性
- 利用した分だけ支払うモデル
- マネージドサービスとして提供
Auroraを入れてもらえれば他は何もしなくていい、というようにしたい
1. スケールアウト、分散、マルチテナントデザイン
- コンピュートレイヤをストレージレイヤと分離している
- DB専用に作られたログストレージ
- ストレージボリュームは3つのAZにすトライピング
- 各AZに2つずつ、計6つのデータのコピーを保持
- AZ＋１の障害にも対応可能
- Masterとレプリカが同じストレージを参照している
2. AWSを活用した、サービス指向アーキテクチャ
- エコシステムを利用した構成
- Lambda
- ストアドプロシージャ、トリガーからLambdaイベントを実行
- S3
- S3からデータをロードしたり、スナップショットをS3に保存
- IAM
- IAMロールをDBアクセス管理に利用
- CloudWatch
- システムメトリクスや監査ログを保存
- Lambda
3. フルマネージドサービス、自動化されたタスク
- ユーザ
- スキーマデザイン
- クエリ作成
- クエリの最適化
- AWS
- 自動化されたフェイルオーバー
- バックアップとリカバリ
- 分離とセキュリティ
- 自動パッチ適用
- 定期的なメンテナンス
- 時間のかかるDB管理タスクを自動化することで、アプリの改善やビジネスに専念してもらう
- AWS史上最速で成長しているサービス
- AWSTOP100のうち、3/4が利用している
- なぜAuroraに移行したのか？
- オープンソースを使っていたユーザ
- より高いパフォーマンス（最大5倍）
- コストを最大60％削減
- 簡単な移行。アプリの変更なし
- コマーシャルDBを使っていたユーザ
- 1/10のコスト。ライセンスなし
- Cloudシステムとの統合
- 同等のパフォーマンスと可用性
- オープンソースを使っていたユーザ
- なぜAuroraに移行したのか？
- 今のトレンドは、NoSQLからAuroraへの移行
- ハイパフォーマンスアプリ用のデータストア
- Cassandra（>100nodes）Aurora(～10clusters)
- 大規模な遺伝子情報を扱う会社が、Auroraに移行することで、10ms未満の読み取りレイテンシと大幅なコスト削減
- ハイパフォーマンスアプリ用のデータストア
パフォーマンス
- MySQL5.6&5.7と比較
- R3ベースで約5倍の性能
- リードレプリカレイテンシ
- I/O
- RDSの場合
- プライマリインスタンス＞EBS＞EBSミラー
- プライマリからレプリカへ
- レプリカインスタンス＞EBS＞EBSミラー
- それぞれボリュームが独立しているため時間がかかる
- 両方のインスタンスで同様の作業負荷が発生する
- Auroraの場合
- シェアードストレージに書き込むのみ
- 物理的なIOは発生していない
- RDSとくらべて8倍速い
- RDSの場合
- Auroraでのパフォーマンス向上
- DMLスループット
- Fast B-tree insert
- Z-order spatial indexes
- Smart read-node selector
- どのノードを読むのが一番早いかを判断
- クエリ実行
- ハッシュjoin
- 一部のクエリでは8倍性能が向上した
- ハッシュjoin
- DDL
- パフォーマンスの高い監査機能
- DMLスループット
可用性について
- パフォーマンスはDBが正常に稼働しているときに気にすること
- なぜ6つのコピーが必要なのか？
- AZ+1の障害に対応する
- 大規模な環境だと常に何かしらの障害は起きる
- AZ障害は運命共同
- AZ+1障害にも対応できて、修復も可能である必要がある
- AZ+1の障害に対応する
- 15台までの昇格可能なレプリカ
- Masterが失われても10秒以内に昇格できる
Auroraは簡単
- RDSはたくさんのことを処理してくれる
- さらに64TBまで10GBずつ自動スケールするストレージ
- DBのcloneも簡単にできる
- コピーではないので早い
なぜ安価なのか？
- RDS
- シェアードストレージがないので、プライマリ・レプリカごとにストレージが必要
- Aurora
- ストレージは1つのみ
- このため、RDSよりも30％削減できる
- 地裁インスタンスサイズにするとさらにコスト削減できる
- ストレージは1つのみ
移行も容易
- 各種マイグレーションツールを用意している
Auroraの新機能
1. Multi-Master
- 1つのMASTER、15のリードレプリカが現状
- シングルAZなら全部がMasterになる？（要確認）
- Auroraのダウンタイムをゼロにしたい！という要望 ex.ECサイト
- 書込みの性能（20万/秒以上の性能が必要）ex.ゲームなど
- 継続した書込み可用性
- M1接続中に障害発生しても、他のノードへ接続を再接続
- シェアードストレージなので影響はゼロ
2. パラレルクエリ
- クエリをストレージノードの数千のCPUにプッシュダウン
- Auroraストレージには数千のCPUがある
- ユースケース
- OLTPワークロードの分析クエリ
- アドホッククエリに対するETLパイプラインを作らなくてよい
- 複数の分析クエリを同時実行
3. サーバレス
- 可変ワークロードを持つアプリ用のオンデマンド、自動スケーリングDB
- ユースケース
- スケールアップ・ダウン
- 0からスケール
4. パフォーマンスインサイト
- DB管理をしやすくするもの
- DBの負荷を表示するダッシュボード
- ボトルネックの原因を表示
- TOP SQL
5. MySQL5.7 compatibility
- 互換性
- JSONサポート
【Keynote2】Amazon Aurora with PostgreSQL compatibility最新情報～ついに東京リージョンでも利用可能に～
スピーカー
Kevin Jernigan Sr.Product Manager
RDSの歴史
- 2006年 S3リリース
- 2009年 RDSリリース
- 2012年 Oracleサポート
- 2013年 PostgreSQLサポート
- 2014年 Auroraをアナウンス
- 2015年 Aurora with MySQLがGA
- 2017年 Aurora with PostgreSQL compatibilityがGA
これまでのDBはスケールが難しい
- 複数の機能レイヤーが1つのアプリケーションになっている
- 従来のアプローチ
- アプリレイヤでシャーディング など
- RDBをもう1度考える
- Cloudでやるならどうするか？
- Auroraの誕生
Auroraをよりよく
- PostgreSQL
- オープンソースDBである
- 20年の歴史がある
- コミュニティが所有している
- 扱いやすいオープンソースライセンス
- 高性能
- 標準SQL
- 12言語でのストアドプロシージャサポート（Java、Rubyなど）
- Oracleからの移行先としても採用しやすい
- AWS移行ツールによる自動変換率は、OracleからPostgreSQLが最も高い
PostgreSQL compatibilityが意味するもの
- PostgreSQL9.6 + Aurora
- パフォーマンス向上（2~3倍）
- 可用性（30秒未満でのフェールオーバー）
- 堅牢性（３AZ6レプリカ）
- リードレプリカ（15台まで）
- セキュリティと暗号化
- KMS
- IAM
- RDSによる管理機能
- データロード・アンロード
- AWSマイグレーションツール
- PostgreSQLとの互換性
- 互換性のためのレイヤーがあるのではない
- PostgreSQLの実装をそのまま利用している
- 互換性に関してはバグはない
パフォーマンス
- 同じサイズのインスタンスで比較
- PostgreSQL
- 3つのEBS
- PostgreSQL
- pgbenchでの比較結果
- ピーク性能の1.6倍以上
- 最多クライアント数で実行した際の2.9倍以上のスループット
- Sysbench出の比較結果
- ピーク性能の2倍以上
- 最多クライアント数で実行した際の5倍以上のスループット
- AWSの見解
- 保守的に見ても、標準のポスグレよりも2~3倍性能がいいと言える
- スループット比較
- DBサイズが10GBから100GBに増えるとどうなるか？
- 1.8倍から4.4倍違う
- GQ版はプレビュー版よりもさらに高性能になっている
- DBロードでは、標準の2倍以上速く完了
- コピー
- バキューム処理
- 特にAuroraはバキューム処理が早い
- 標準よりも86％削減できる
- Writeの回数が圧倒的に減っているため
- インデックス構築
- レスポンスタイム比較
- 標準に比べて2倍以上短い
- スパイクも99%削減
- 標準はチェックポイント時に跳ね上がる
- Auroraはチェックポイントのスパイクはない
- 標準よりも99%削減
- チェックポイントを持たない
- スループット比較
- 標準に比べて3倍以上一貫した結果が得られた
- リカバリ時間比較
- ストレージシステムのリカバリが高速に実行可能
- 標準よりも97%短く
- 標準
- redoログサイズとともにクラッシュリカバリの時間が増加
- redoログ3GBで19秒
- redoログ30GBで123秒
- Aurora
- redoを持たない
- 極めて高いスループットを維持
- 3秒以内にリカバリを完了
- 標準
パフォーマンスインサイト
- DBの可視化をするダッシュボード
- データサンプリングを自動化する
- Top SQLも見れる
- まだプレビュー版
- GA提供はまだ
DBマイグレーションサービス
- AWS DB Migration Service
- データ移行の開始まで10分以下
- 移行中もアプリを実行可能
- 同種・異種間DBにて移行可能
- AWS Schema Conversion Tool
- RDBのコンバート
- DWHのコンバート
- 利用すると評価が得られる
- 自動コンバートできないものがあれば理由も表示される
- 様々なターゲットを比較できる
- 例えば、OracleからどのオープンソースDBがいいかを教えてくれる
- MySQLか？
- PostgreSQLか？
- 例えば、OracleからどのオープンソースDBがいいかを教えてくれる
Aurora with PostgreSQLについて
- 10/24ローンチ
- セキュリティ
- KMS
- SSL
- VPC default
- 高可用性
- 15代のリードレプリカ
- 高速なクラッシュリカバリ
- 高性能
- 標準の2～3倍のスループット
- 運用/互換性
- 機能レベルでの標準ポスグレとの互換性
- 10.3もサポートする
- メジャーバージョンは3年サポートする
- マイナーバージョンは1年サポートする
- 機能レベルでの標準ポスグレとの互換性
直近のアップデート
- GAローンチ（12のリージョン。東京含む）
- HIPAA認証
- 暗号化されたRDSスナップショットのインポート
- RDS for PostreSQLから、Aurora PostgreSQLリードレプリカの作成
- ダウンタイムを減らすことができる
- Aurora PostgreSQL 1.1リリース（標準9.6.6との互換性）
今後
- PostgreSQL10のサポート（1か月以内）
- クロスリージョンレプリカ
- アウトバウンドレプリケーション
- マルチマスタ
- サーバレス
- これらは来年早々にはできるようになると思う
Auroraファミリー
- Aurora MySQLに早く追いついていく
【Session1】徹底検証！！Aurora with PostgreSQL compatibility
スピーカー
株式会社アクアシステムズ 影山さん
内容
ブログへの掲載禁止のため割愛。
【Session2】マルチリージョンのテレビ会議クラウドをAurora+DMSで実現した話
スピーカー
株式会社リコー 井上さん
関連発表
サービス全断はダメ、ゼッタイ。途切れないテレビ会議システムを目指して。 ※去年のAWSサミット発表資料
Ricoh USCとは
- ビジネス向けテレビ会議システム
- 専用端末＋クラウド
- グローバル
- お客様に近い映像配信サーバから届ける
- AWSで11のリージョンを使っている
- 多拠点つなげる
- 2011年からprivateクラウドで運用開始
- 2017年に全サービスのパブリッククラウド移行完了
- Aurora運用開始
現構成
- 呼制御系
- AWSの公式ページに構成図あり
- ECSなど活用
- 映像配信
- サービス監視
AWS移行直後の構成
- オンプレからほぼそのままの構成で移行
- MySQL/RDSを1セット配置
- 課題
- インスタンス数が多い
- 複数リージョンで協調動作するシステム
- データは主に3種類
- 主リージョンで書き込み、全リージョンで参照
- 全リージョンで読み書き、主リージョンに集約
- SPOFの内向性が必要
- フェイルオーバー時間に不満
- アプリ対応に限界
- ストレージ不足に拡張処理が必要
- 小サイズのRDSは効率が悪い
- ５GBで十分なDBもある
- GP2ストレージの性能不足、補うには33GB以上が必要！！
- インスタンス数が多い
- 進構成の検討
- Auroraの利用
- しかし
- 数が多いため高コストで無駄が多い
- そこで
- DMSによる柔軟なレプリケーション構成を検討
- DMS
- 移行を行うマネージドサービス
- RDBMSからS3などもできる
- 一括コピー、継続的コピーが可能
- テーブルを取捨選択してコピー可能
- スキーマを変換しながらのコピー可能
- 移行を行うマネージドサービス
- DMSとMySQL
- 変更検知はBinary Logを使用
- checksumなし
- 注意点
- 文字セットの制限
- 以下は使えない
- utf8mb4
- us_ascii
- 以下は使えない
- 開始点は秒単位の時刻で指定
- 文字セットの制限
- 変更検知はBinary Logを使用
- 最終的なDMS導入決定
- 想定外の問題はAWSと協力してつぶしていく！！
新構成と移行
- リージョンごとに1つのAuroraクラスタをマルチAZで設置
- 検証
- Auroraのサイジング
- アプリの機能テスト・性能テスト
- ソースおよびターゲットDBのフェイルオーバー
- DMSの機能・性能
- 検証で分かったこと
- 機能や性能に問題はない
- Auroraのフェイルオーバー追従に課題
- Auroraのフェイルオーバー
- マルチAZでは30秒くらいで切り替わる
- クライアントから見た課題
- 読み書きするクライアントがレプリカにつながってしまう
- 対策
- JavaアプリはMariaDB Connector/Jを利用
- 高速フェイルオーバーの恩恵を受けれる
- クライアントを修正する
- 泥臭い修正
- JavaアプリはMariaDB Connector/Jを利用
- DMSの挙動
- ターゲットのAuroraが切り替わる：自動接続
- ソースのAuroraが切り替わる：自動接続しない
- DMS1.9時点
- 対策
- DMSタスク監視
- 移行手順１
- MySQLからAuroraのリードレプリカを用意してレプリケーション
- そのほかのDBからもAuroraへレプリケーション
- 移行手順２
- 当日の作業は30分くらい
- 旧DBからAuroraへのレプリケーション停止
- DMSで処理できないDBをダンプから投入
- DMSタスク作成＆開始
- 当日の作業は30分くらい
9か月分かったこと
- Auroraクラスタは毎日作るものではない
- 開発環境は毎日構築・破棄
- Auroraクラスタのスナップショットからの構築は遅い。時々失敗する
- Auroraクラスタだけ残してもコストはS3の5倍程度
- 句ら鵜s他を残し、DBインスタンスのみ毎日構築するようにした
- Auroraアップっグレードとの付き合い方
- 必須アップグレードは所定の期間内にメンテナンスが必要
- 20~30秒のダウンタイムが発生
- 本番環境以外で影響確認したい
- 旧バージョンのAuroraを顧客が作る方法はない
- 本番以外で常時稼働環境が必要になる！！
- Zero Downtime Patching
- 接続を維持したままアップグレードできる機能
- DBの使い方によって背教が出る
- サーバサイドのプリペアドステートメントが消える、など
まとめ
- すこしずつ移行するのがおすすめ
- 最終形ではない
- 日々のキャッチアップ
【Session3】Oracle DatabaseからAurora with PostgreSQL compatibilityへの移行～orafceの活用による活用事例＆メリット～
スピーカー
NTTテクノクロス株式会社 勝俣さん
orafceとは？
PostgreSQL上でOracleの機能を使えるようにする拡張モジュール 以下が使えるようになる - Data Type - SQL Queries - SQL Functions - SQL Operators - Packages
意外と多い細かな違い
- Varchar2(n)
- Oracle：byte数指定
- PostgreSQL：文字数指定
- DATE型
- Oracle：年月日時分秒
- PostgreSQL：年月日
メリット
- 移植の効率化
- ポスグレ標準＋orafceがサポートする関数カバー率：34%
- 実案件で使うだろう関数のカバー率：73%
【Session4】Oracle DatabaseからAmazon Auroraに移行するための実践ガイド
スピーカー
アマゾンウェブサービスジャパン株式会社 江川さん
お客様の声
- クラウドにシステム全体を移すのであれば、RDBMSもクラウドネイティブにしたい
- RDBMSもオートスケールさせたいが、CPUライセンスだとできない
- IT予算の多くをOracleライセンスを占めている
現場の悩み
- 業務部門・アプリ開発部門
- アプリへの影響はどれくらい？
- 移行の業務停止は短くしたい
- IT・インフラ部門
- 業務部門に何をガイドしたりいいの？
- 従来の管理腫瘍がどう変わる？
- 移行費用はかけたくない
決めないといけないこと（５W1H）
1. What?（対象システムは？）
2. Why?（移行理由は？）
3. How?（移行戦略は？）
AWSの考える6つの戦略
- Re-Host(ホスト変更）
- Re-Platform（プラットフォーム変更）
- 移行の複雑さ2位
- Re-Purchase（買い替え）オンプレのOracleを、ライセンス込のRDS for Oracleへ
- Refactor（書き換え）オンプレのOracleをAuroraに変更する、など
- 移行の複雑さ1位
- その分のメリットは大きい
- Retire（廃止）このタイミングで古いDBやシステムを破棄する
- Retain（保持）オンプレを使い続ける（Oracle9iに依存してるアプリなど）
4. Where?（移行先は？）
- RDS
- Aurora MySQL
- Aurora PostgreSQL
- 結合法方
- ネステッドループ
- ハッシュ
- ソートmerge
- インデックス
- Bツリー
- 関数
- 空間
- 全文
- ゾーンマップ
- 制約
- NOT NULL
- PK
- UNIQUE
- FK
- CHECK
- 結合法方
- Redshift
- データウェアハウス用途
- on EC2
5. When?（期限は？）
- 工数見積が必要
- 工数＝移行先との違いの量
6. Who?（担当者は？）
- 工数見積が必要
- 工数＝移行先との違いの量
移行支援サービス
- 計画
- AWS CTO Calculator
- 移行
- AWS DMS
- 運用
AWS DMSとは
- 既存DBを最小限のダウンタイムでマイグレーションするサービス
- 同種はもちろん異種プラットフォームの移行にも対応
- 移行中もアプリケーションは稼働したまま
- AWS上にDMS用のAurora起動
- 移行元のDBとDMSを以下で接続
- Internet
- VPN
- Direct Connect
- DB同期が完了したら、アプリ側のDBの向き先を変える（ダウンタイムはここだけ）
- マルチAZ構成が可能
AWS Schema Conversion Tool
- ソースDBのビューやFunctionをターゲットDB向けに変換
- デスクトップアプリで提供
- できること
- 自動変換＆自動変換の補助
- 評価レポートの作成
- どこができるか色分けされたグラフが出る
- 緑：自動変換
- 青：検討が必要
- 赤：深い検討が必要
- どこができるか色分けされたグラフが出る
- アプリケーションSQLにも対応
事例
- レコチョク
- Oracle RACからAurora移行
- 1000万会員のDB
- DMS/SCTリリース前に手動で移行
- 結果
- Auroraによる障害はこれまでゼロ
- DBサーバ運用に工数はほとんど咲かなくてよい
- Oracle RACからAurora移行
Oracleとの違い
- Objectの主な違い
- MySQLのシーケンス
- AUTO_INCREMENT属性を付与
- NULLまたは0を入れる
- PostgreSQLのマテリアライズドビュー
- リフレッシュは手動のフルリフレッシュのみ
- 読み取り専用のみ対応
- PostgreSQLのDBリンク
- dblink
- 関数として実装されている
- ビューで隠ぺいするのが一般的
- postgres_fdw
- dblink
- パーティショニング
- MySQL
- RANGE、HASH、LIST、KEY
- PostgreSQL
- RANGE、LIST
- v10~宣言的パーティショニング
- ストアドプロシージャ/ストアドファンクション
- AuroraはJavaプロシージャに未対応
- MySQL
- MySQLのシーケンス
- 互換性がないとどうなるのか
- 文法ERRORになる
- 地道に対応する
- 文法ERRORにならず結果が異なる
- このパターンが厄介
- 文法ERRORになる
結果相違を起こしやすい2大ポイント
- NULLと空文字の扱いの違い
- OracleがSQL標準からずれている
- Oracleでは区別しない
- MySQLやPostgreSQLは区別する
- 対策
- ''でgrepするとよい
- 外部結合した後の||にも注意
- CHARの埋められた空白の扱いの違い
- Oracleは末尾の空白を保持する
- MySQLとPostgreSQLは、末尾の空白を無視する
トランザクション分離レベル
- 数やデフォルトがDBで違う
バキューム
- postgreSQL独自
- 運用設計が必要
- 今は自動になっている
【Session5】移行の前には移行アセスメントを～移行難易度や工数を事前に確認する～
スピーカー
アマゾンウェブサービスジャパン株式会社 北川さん
現実では・・・
簡単にDB移行できないこともある（外字が入っているとか）
移行前に実施すべき内容
- システムの棚卸
- 移行対象DBを使っているシステムの把握
- システム間連携の有無
- データの流れの把握
- 障害発生時の復旧プロセス
- そもそもDMSがサポートしているDBバージョン・エディションか？
- 移行対象の決定
- ミドルウェアのサポート終了期間の確認（緊急度）
- アセスメントの実施
- プロシージャの数
- DDLはSCTで自動変換できる
- プロシージャはDCTの自動変換率が比較的低い
- SCTで評価レポートを作成する
- 予想工数が色分けされる
- 青：1時間未満
- 黄：4時間未満
- 赤：4時間以上
- 予想工数が色分けされる
- SCTで評価レポートを作成する
- SELECT文の数
- 自動変換率が比較的低い
- テストの洗い出し、工数確認
- SQL解釈の方言で同じSQLでも結果が違う可能性がある
- データが正しく移行されたかの確認が必要
- テストフレームワークがあればよいが、なければ大変
- 工数だけで判断しない
- 重要度と緊急度も考慮する
- 移行計画
- ダンプツール
- CSVアンロード
- レプリケーション
- DMS
- 何でもかんでもDMSでやろうとしない
- ネイティブの方法がベストな時もある
- 事前検証の実施
- 選択した移行方法で留意事項を確認
- ￥マーク、外字など
- 同期レプリケーションか？非同期レプリケーションか？
- どれくらい時間差があるのか
- 非同期の場合クラッシュしたらどうするか？
- マルチAZ構成
- DMSで二重障害が起きるとどこから再開するかが困難
- 「十分な時間がとれるか？」を再度検討すべき
- スケジュールの策定
- 事前検証結果から、移行方法が妥当か確認
- 連携状況から他のシステムを含めた影響を確認
- 本当に並行移行させる必要があるのか？
- 1日止めれば難易度は下がるのでは？（安全かつ確実）
- など
- トラブルを見越したスケジュールを組む
- 検証には可能な限り実データを使用する
まとめ
このエントリではAurora Dayの各セッションをまとめました。Auroraに興味がある方のお役に立てれば幸いです。私はPostgreSQLを使うことが多いため、Aurora with PostgreSQL compatibilityのリリースはとても嬉しいです。自分のプロダクトでAuroraに移行できないか検討してみたいと思います！！
