2016AWS特集Auroraレポート2016年06月19日irbbb(180)21この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。2016のセッション資料が最近になって公開されました。~性能向上の仕組みと最新アップデート~」についてレポートします。リレーショナルデータベースを作ったのか?現在のRDB1970年代のデータベースのコアとなる論文をもとに作られているさまざまなハードウェアで動くことを前提に大きくてモノリシックなアプリケーションとして動作する。疎結合な構成キャッシュレイヤを分離した理由キャッシュをデータベースプロセスの外に移動パッチ適用・障害などの理由でデータベースのリスタートが発生しても、キャシュが残る。暖気せずとも、パフォーマンスへのインパクトがない。Aurora(ストレージノード)どうやってデータを6本のディスクにコピー作るのか?プライマリインスタンスからデータを受け取り、メモリのキューに追加。抑えている残り2本へのコピーはゴシッププロトコルでディスク同士が協調して正しい状態に持っていく。自動修復も同じ仕組が利用される。レプリケーション方法MySQLはバイナリーログを利用Auroraはマスタ・スレーブが同じディスク(共有ストレージのようなもの)を見ている。そのため、レプリカ遅延が少なく、データ同期のオーバーヘッドも少ない。バイナリーログの転送が終わっていなければ、マスターノードの障害がデータロスにつながる。エンジンと比べてもかなり高速にフェイルオーバーする。フェイルオーバー速度はどんどん高速化されており、リードレプリカが存在する場合は45秒程度。レプリカが存在しない場合は、DBインスタンスの作成が必要なので15分程度を要するMulti-AZにしていれば、AZダウンしてもサービづを提供し続けられる。フェイルオーバー時もエンドポイントの変更は発生せず、CNAMEの指し示す先だけが変わる。このクラスタエンドポイントを参照しておけば良い。関しては、インスタンスごとにインスタンスエンドポイントが存在するので、そちらを参照する。レプリケーションラグが発生する。フェイルオーバーが発生すると、新しいマスタノードに対してキャッシュの整合性を取るために、すべてのレプリカが5s-10s程度かけて再起動する(瞬断が発生する)。クライアントは、フェイルオーバーその他の瞬断に備えて、リトライ処理を入れること。再起動が発生しないようにすることも、開発チームと検討している高速でより予測可能なフェイルオーバー時間どうやって早いフェイルオーバーが実現されているのか?MySQLデータサイズチェックポイントが打たれたタイミングなどによってクラッシュリカバリの時間が予測できないAuroraAuroraのプロセスではクラッシュリカバリは行わないストレージノード側でクラッシュリカバリを常に行っている最大でも40秒あれば、アプリケーションからのコネクションを受け付けるようになる。PITRストリーミングバックアップをS3に行っている。ストレージに書き込まれる瞬間にS3にバックアップが取られている。ドキュメントではPITRの起点を「5分前から」としているが、タイミングによっては「1分前」など、より最近のポイントからのリカバリも可能。http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html継続的なバックアップフルスナップショットと差分バックアップで構成される。10GBずつの小さいブロック(セグメント)単位でストレージに格納している。リストア時には最後のフルスナップショットに以降のセグメントを並列で適用する。障害、データノード障害が発生しても、動き続けるか確認している。再現性のある手順も公開されている。