【レポート】Amazon Aurora Under the Hood #AWSSummit

AWS Summit 2018 Tokyo

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

こんにちは、黒澤です。
AWS Summit Tokyo 2018。Day1 で開催されたセッション
『Amazon Aurora Under the Hood』
についてレポートします。

  • スピーカー
    • アマゾン ウェブ サービス ジャパン株式会社 江川 大地 様

概要

Amazon Aurora は、AWS がクラウド時代に再設計したデータベースです。本セッションでは Aurora の根幹とも言えるストレージ部分のアーキテクチャやその設計思想についてご紹介します。本セッションを通じて、マネージドとして提供されるサービスが、どれだけ深く可用性、堅牢性について検討されているかをご説明します。

セッション内容

Amazon Aurora とは

  • AWS がクラウド時代に再設計した DB
  • MySQL 5.6/5.7, PostgreSQL 9.6 との互換性
  • 高い堅牢性/可用性
  • スケーラビリティ
    • 64TB まで自動スケール
    • リードレプリカに対応
  • フルマネージド

アーキテクチャ

  • ログとストレージレイヤをシームレスにスケールするストレージサービスに移動させている
  • 管理コンポーネントに EC2, VPC, DynamoDB, SWF, Route 53 などのAWSサービスを採用
  • S3 を利用してストリーミングバックアップ
  • キャッシュレイヤの分割
    • 通常はキャッシュが DB プロセス内にあるので DB がダウンしたら消去される
    • Amazon Aurora ではキャッシュをDBプロセス外に移動し,リスタートしてもキャッシュが残るようになっている(サバイバルキャッシュ)

コンポーネント

  • プライマリインスタンス
    • 参照/更新クエリを扱う
  • Aurora レプリカ
    • 参照クエリを扱う
  • プライマリもレプリカも同じボリュームを見ている
  • 3つの AZ に6つのコピーを持つ

Aurora エンドポイント

  • クラスタエンドポイント
    • 常にプライマリインスタンスを示す
  • リーダーエンドポイント
    • 常にAurora レプリカを示す
  • インスタンスエンドポイント
    • 各インスタンスごとのエンドポイント

セキュリティ

  • 暗号化
    • AES256 を用いる
  • SSLで通信
  • VPC 内に設置されるのでネットワークが分離される
  • ノードへ直接アクセスは行うことができない
  • PSIDSS などの業界標準のセキュリティとデータ保護の認証をサポート

ストレージ

  • SSD を利用したシームレスにスケールするストレージ
    • 10GB から 64TB まで自動的にスケール
    • 実際に使った分だけ課金される
  • 標準で高可用性
    • 3つの AZ に6つのデータコピーを持つ
    • クォーラムシステムの採用(レイテンシ軽減)
    • 継続的に S3 へ増分バックアップ

堅牢性を高める手段の例

一般的なレプリケーション

  • マスタの更新操作を複数のスタンバイ DB へ転送して複製する
  • 同期レプリケーション
    • 最も遅いディスクやノードに律速され, レイテンシ遅延が発生する可能性がある
  • 非同期レプリケーション
    • データ同期前に障害が発生した場合データロストの可能性がある

RDS での例

  1. プライマリノードが EBS / EBS のミラーに書き込み
  2. スタンバイノードが EBS / EBS のミラーに書き込み
  3. 両方終了後に ACK が返る

Aurora での例

Aurora ではクォーラムモデルを使用する

  1. 6つあるコピーに対して並列に書き込みを行う
  2. 4/6 のコピーから ACK が返ってくると ACK を返す

クォーラムモデル

  • Vr : 読み込みクォーラム
  • Vw : 書き込みクォーラム
  • V : コピーの数

2つのルールが存在する

  • 読み込みクォーラムと書き込みクォーラムが少なくとも1つの共通コピーを保持していること
    • Vr + Vw > V
  • 書き込みに使用されるクォーラムは書き込みは過半数のコピーを保持していること
    • Vw > V/2

Aurora の場合は V = 6 なので、 Vw = 4, Vr = 3 となる
2つのコピーに障害が起こっても読み書きに影響がないことが保証され
3つのコピーに障害が発生しても読み込みは保証される
更に障害は自動検知・修復されるので安心

なぜコピーの数が6つなのか

  • AWS は大規模環境
  • AZ 障害は影響範囲が広域
    • AZ 障害と + 1 の二重障害を許容し修復する必要がある
    • (6つのコピーのうち 1AZ 分 + 1 で3つのコピーに障害が発生する状態を許容する)

2/3 クォーラムの場合

  • V = 3, Vw = 2, Vr = 2 となる
  • コピーは3つの AZ に1つずつ
  • AZ 障害と + 1 の二重障害が発生した場合は 2/3 のコピーから ACK を返すことが実現できない

4/6 クォーラムなら "AZ + 1" の障害が発生してもデータを保全することができる
3/4 クォーラムでも実現可能だが, 4つの AZ が必要なため 3AZ で 4/6 クォーラムを採用した

MTTR の短縮

  • 小さなセグメントで修復が短くなる
    • 10GBのセグメントを使用
    • 無停止でのパッチ適用
    • ホット / コールドノードのリバランスも行いやすい

ストレージノードクラスタ

  • ストレージノードを 10GB ごとの論理ブロックに分割
  • プロテクショングループ毎に6つのストレージノードを使用
  • 各ログレコードはシーケンス番号で管理して不足 / 重複を判別できるようにする
    • 欠損時にはストレージノード間で補完し合う

ストレージノードの入れ替え

  • ほとんどのシステムはメンバーシップの変更にコンセンサスを使用するが, ジッタとストールの原因となる
  • Aurora ではクォーラムセットとエポックを使用
    • 疑わしいノードが発生した時点で, それ以外のノードと新しいノードからなる新しいクォーラムグループを作成する
    • 疑わしいノードの障害が確認された時点で、新しいクォーラムグループをアクティブにする
    • 無停止でクォーラムグループの以降が可能

長期間の AZ 障害

  • 地震等の災害などで AZ に長期間の障害が発生した場合はデグレートモードにより 3/4 クォーラムへ切り替え
    • AZ 障害発生時に別の二重障害 / AZ 障害が発生した場合でもデータロストを防ぐための対処

一般的なクォーラムシステムにおける課題

  • 読み込み書き込みコスト
  • ネットワーク負荷
  • 複数のストレージに対する読み込みが必要

ネットワーク負荷の軽減

  • Aurora ではログレコードのみがストレージノードに送信されるのでネットワーク負荷が軽減される
    • 1/9 のネットワークトラフィック

読み込みコストの削減

  • Aurora では最新のデータを持っているノードを管理している
  • 読み込みのコスト削減のため, 読み込み時はクォーラムを利用せず, 最新のデータを持っているノードから返す
  • 読み込みクォーラムは修理やクラッシュリカバリにのみに使用

ストレージ容量の削減

  • 通常はコピーが6つなら物理ストレージは6倍必要
  • Aurora では6つのコピーのうち, 3つはフルセグメント (データページとログレコード), 残り3つはテールセグメント (ログレコードのみ) としている
    • これにより物理ストレージに必要な容量は3倍強程度を実現

まとめ

  • Amazon Aurora は AWS がクラウド時代に再設計した RDBMS
  • 高い堅牢性/可用性を持っていて中では凄いアーキテクチャが動いてる

みなさんいかがでしたでしょうか。普段利用者としてはあまり意識することのない部分ですが, こうやってお話を聞いてみると中では凄いアーキテクチャが動いていているんだなと思い知らされます。皆さんもぜひ Aurora を使いましょう。 Aurora! すごい! 本当に凄いんだ!

参考リンク

(レポート) AWS Online Tech Talks : PostgreSQL互換Amazon Aurora #awsblackbelt