AWS Black Belt Tech Webinar 「Amazon Aurora」資料公開
こんにちは。ソリューションアーキテクトの下佐粉（しもさこ）で す。 先日(7/31)のお昼に緊急開催したAWS Black Belt Tech Webinar では RDSの新しいデータベースエンジン Amazon Auroraの解説を行いました。
これまでプレビューだったAuroraが一般公開（GA）された直後とあって、告知からあまり日にちが無かったにも関わらず非常に沢山の方にご参加いただきました。スライド資料を以下に公開しますので、見逃した方もぜひ参考になさってください。
Q&Aも非常に活発でした。時間の範囲お答えさせていただきましたが、それでも答えきれなかったご質問も多かったので、このエントリの後半にQ&Aをまとめています。こちらもぜひご参照ください。
次回のBlackbeltは8/5(水)18時から、AWSのNoSQL型データベースサービスであるDynamoDBについて解説します。
- 8月5日(水)18時
- Amazon DynamoDB - 森祐孝
- セミナー参加登録リンク: https://connect.awswebcasts.com/dynamodb-2015/event/registration.html
- セミナー内容:DynamoDBは、ストレージ制限、サーバの運用、管理の必要のない完全マネージド型の NoSQLデータベースサービスです。本Webiner ではDynamoDBの基本的な機能やテーブルの設計方法等をご紹介致します。また、この1年の間にリリースされた新機能も紹介しながら、利用上の注意点 や活用事例などもご紹介致します。
Q&Aは以下の通りです。
Q)まずは開発環境から導入してみたいと思っているのですが、インスタンスサイズがlarge?0となっているため、導入のハードルが高いです。medium、smallと言った小さいインスタンスサイズに対応する予定はありますでしょうか
A)要望は多く頂いていますが、現在のところお伝えできる予定はございません。しかし、開発環境としてはMySQL5.6をお使いいただき本番環境はAmazon Auroraを利用することでコストを削減出来るかと思います。
Q)TokyoリージョンはAZが2つしか無いですが、AuroraはTokyoに来る予定はありますでしょうか？
A)東京リージョンへのローンチも多く要望を頂いていますが、現在のところお伝えできる予定はございません。
Q)S3で管理ができるということは、S3に書き込まれたことをきっかけにLambdaファンクションの起動もできるのでしょうか。
A)RDSのスナップショットなどはお客様の管理するS3バケットではなく、AWSが管理する領域へバックアップが行われるためLambdaファンクションの起動は出来ません。
Q)共有ストレージを使用しているのに、レプリケーションに10-15msの遅延があるのはなぜでしょうか
A)各Readerノードのキャッシュをパージ・各ディスクへの書き込みなどに要する時間となっています。
Q)DB Parameter GroupとDB Cluster Parameter Groupでかぶる項目はありますか？あるとしたらどちらが優先されますか？
A)かぶる項目はありません。DBクラスタ全体に適用しなければならないものと各Auroraノード個別に設定するものと明確に分かれています。詳細は以下のURLをご覧ください。
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Appendix.ParameterGroups.html
Q)メトリクススキーマーへの頻繁なアクセスは、パフォーマンスに影響を与えますでしょうか？
A)他のクエリの状況によりますが、高頻度のアクセスが影響を及ぼす可能性はあります
Q)slaveへのSELECTはノードのエンドポイントに対して行うのですか？
A)はい。SELECTはReaderノード個別のエンドポイントに行います。
Q)フェイルオーバーしても書き込みロスが起きにくい理由、ブログでもう一度ご説明いただけますか？ちょっと説明があった気もしましたが、理解できませんでした
A)バイナリログを使用したレプリケーションでは無いため、バイナリログがSlaveに送られる前にMasterがクラッシュした場合などにデータロスの可能性がありますが、Amazon AuroraはWriterとReaderノードが同一のディスクを参照しているためディスクに書き込みが完了していればフェイルオーバーが起こってもデータロスの可能性が軽減出来ています。
Q)データをwriteするときに6つのうち４つ書き込みが完了したら、次の処理が行われるとおっしゃっていましたが、「強い整合性」は担保されているという理解でよろしいでしょうか？それとも場合によってはselectでギャップがでてくるのでしょうか。
A)Writerノードによって書き込みが正常に完了していれば各Readerノードでギャップは発生しません。
Q)クエリキャッシュを効かせるためにはMySQL同様、SQL文が完全一致していないとダメでしょうか?
A)はい。MySQLのクエリキャッシュと同様の条件です。
Q)バックアップは完全にオンラインで（DBを停止することなく）可能でしょうか。
A)はい。スナップショットやストリーミングバックアップはオンラインで行われています。手動スナップショットもオンラインで実行可能です。
Q)RDSからAuroraに変更するにあたってデメリットのようなものはあったりしますでしょうか？
A)大きなデメリットは無いと考えていますが、実行計画が変わる可能性があるためEXPLAINの結果やデフォルトパラメータの値などを事前に確認いただくことをオススメします。また、Readerノードに対して書き込み処理を行うことが出来ないため、データサイズの大きなテーブルを変更する場合など、SlaveにALTERを実行して昇格させる運用は現在は行えません。
Q)聞き逃したのですが、Writerは常に1ノードになっている理解で合っていますか？
A)はい。WriterはDBクラスタ内に1台のみです。
Q)CPU使用率のモニタリングがあまり意味なくなりそうですけど、モニタリング上のどんな工夫があるでしょうか。
A)CPUやメモリのモニタリングは今まで通り行っていただき、追加メトリクスとしてSELECT/DDLスループットやレイテンシなども合わせて監視することでAmazon Auroraの性能を監視可能です。
Q)個別パラメータグループを利用する場合の要件はどのような要件が考えられますか？
A)集計用のクエリを投げるために設定を変更するなど、用途に応じてReaderノードを使い分ける場合などに個別にパラメータグループを変更する用途も考えられます。
Q)PostgreSQLからのマイグレーションは可能？
A)RDS for PostgreSQLからのマイグレーションはサポートしておりません。PostgreSQLからマイグレーションをする場合はデータをダンプしていただき、MySQL5.6で定義可能なテーブルスキーマにしていただきデータを変換してインポートしていただくことで移行は可能です。
Q)アプリケーションで読み込みのクエリをReaderに向けている環境で、Readerに障害が起きた場合、フェイルオーバー等は発生するのでしょうか。
A)Readerノードに障害が発生した場合、ノードの置き換えが行われます。置き換えが行われるまでの間はクエリを当該ノードは受けることが出来ません。他のReaderノードに処理を向ける仕組みなどを組み込むことでアプリケーションのダウンタイムを最小限に出来ます。
Q)MySQLのアップデートは自動で適用されるんですか？その場合ダウンタイムはどれくらいになりますか？
A)Amazon Auroraへパッチは自動で適用されます。フェイルオーバーの時間はMulti-AZ配置などで変わるため一概にお伝えできる値はありませんが、Multi-AZ配置が有効な場合は1-2分程度です。
Q)Aurora用のドライバ（JDBC、ODBC）が提供される予定はありますか？MySQLのドライバをそのまま使い続けていいのかを気にしています。
A)現在のところAurora専用ドライバ提供に関してお伝えできる情報はございませんが、Amazon AuroraはMySQL5.6対応のJDBC/ODBCドライバをお使いいただけます。
Q)AuroraもAWSメンテナンス時間によりサービスが利用できない時間帯が発生する可能性はあるか。F/Oをすることで利用不可の時間帯をなくす等の工夫が必要か。
A)Amazon AuroraもMaintenance Windowがございます。ダウンタイムを短くするためにMulti-AZ配置をおすすめします。
Q&Aは以上です。
Blackbeltの今後の予定は以下のエントリで紹介しています。８月は「DB月間」としてDynamoDB, ElastiCache, Redshiftの解説を行います。以下のURLに予定が書いてありますので、ぜひご覧ください。
■８月のBlack Belt
http://aws.typepad.com/sajp/2015/07/2015-aug-aws-black-belt-tech-webinar.html
コメント