(レポート) DAT405: Amazon Auroraディープダイブ #reinvent

(レポート) DAT405: Amazon Auroraディープダイブ #reinvent

Clock Icon2015.10.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ウィスキー、シガー、パイプをこよなく愛する大栗です。 re:Invent 2015のセッションをレポートします。

レポート

Amazon Auroraとは?

MySQL互換のデータベース 商用データベースの性能と可用性 簡単でオープンソースのコスト効果

SQLベンチマークの結果

昨年発表したように書き込みで107,000rps、読み込みで585,000rpsの性能を発揮します

  • 接続数のスケーリング:8倍速い
  • テーブル数のスケーリング:11倍速い
  • データサイズのスケーリング:SYSBENCHは67倍速く、TPC-Cは136倍速い
  • リードレプリカと動作する:500倍速い

どのように結果をアーカイブしているのか?

仕事を少なく

  • IOを少なく
  • ネットワークパケットを最小化
  • 事前に結果をキャッシュ
  • DBエンジンの負荷を軽減

より効率的に

  • 非同期なプロセス
  • 待ち時間の経路を削減
  • ロックフリーなデータ構造を使用
  • バッチ操作をまとめる

AuroraのIOトラフィック(データベース)

  • IOの流れ: まとまったredoログレコード ー LSNで順序付する 適切なセグメントにシャッフルする ー 半順序 ストレージノードのまとまりと結果の書き込み
  • 所見: 書き込みのみのredoログレコード:全て非同期 データブロックの書き込み無し(チェックポイント、キャッシュ置換) 6倍の書き込みだが、ネットワークトラフィックを9倍削減 ネットワークとストレージの異常なレイテンシへの耐性
  • 性能: 27,378Kトランザクション -> 35倍増 100万トランザクション辺り950K I/O -> 7.7倍減少

AuroraのIOトラフィック(ストレージノード)

re:Inventでの新情報と思われます。

  • IOの流れ:
  1. レコードを受信し、インメモリキューに追加
  2. 記録とACKを持続
  3. レコードを整理し、ログにギャップを特定
  4. 穴を埋めるすること仲間とゴシップ
  5. 新しいデータブロックのバージョンにログレコードを合体
  6. 定期的にステージログとS3に新しいブロックのバージョン
  7. 定期的にゴミは、古いバージョンを集めます
  8. 定期的に、ブロックにCRCコードを検証します
  • 所見:
  • すべてのステップは非同期であります
  • 唯一の手順1と2は、フォアグラウンドレイテンシーパスに含まれています
  • 入力キューは、(1ノード当たり、増幅されていない)には、MySQLより46X小さいです
  • 遅延に敏感な操作を好みます
  • アクティビティの急増に対して、バッファリングするためにディスクスペースを使用します

非同期グループコミット

  • 最初の書き込みリクエストI/Oが書き込みをピックアップ
  • アドバンストで耐久性のあるDBが最も速い保留中のACKをポイントアップアップします。

適応したスレッドプール

再接続のコネクションはアクティブなスレッドで多重化します カーネルスペースでepoll()がラッチ-フリーイベントキューを投入します 動的サイズのスレッドプール r3.8xlargeでの5,000以上の同時接続セッションを正常に処理します

AuroraのIOトラフィック(リードレプリカ)

  • マスタからレプリカへredo情報を送ります。
  • レプリカ派ストレージを共有しています。書き込みを行いません。
  • キャッシュされたページはredoが適用済みです。
  • シベてコミットするすぐに読み込めます。

ストレージノードの可用性

  • 読み取り/書き込みのためのクォーラムシステム:レイテンシトレラント
  • 欠損を埋めるためのPeer-to-peerのゴシップレプリケーション
  • S3への継続的バックアップ(11ナインの耐久性を持つ設計)
  • データブロックの継続的洗浄
  • ノードとディスクの修復のために継続的なモニタリング
  • 素早く負荷を調整したり修復するために10GBのセグメント
  • クォーラム変更で書き込み停止をしません

インスタンスの障害復旧

Auroraではディスク読込の一環でオンデマンドのredoログを適用します 並列、分散、非同期で行う 起動時に再実行しない

存続可能なキャッシュ

キャッシュプロセスをDBプロセスの外にすることでDBプロセスのさ再起動時にもキャッシュが残ります インスタントキャッシュリカバリと存続可能なキャッシュで、DBの障害から迅速かつ簡単に回復します

より速い予測可能なフェイルオーバー

AuroraとMariaDBドライバの場合は障害検出に15〜20秒、リカバリに3〜20秒でアプリケーションを実行できます。

さいごに

日本でもblackbeltなどでAuroraの最新情報が公開されますが、re:Inventではストレージレイヤの内部アーキテクチャが新情報として出てきました。日本でもAuroraが使用可能になったので、ドンドン使って行きたいと思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.