この記事は公開されてから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 レプリカ
- 参照クエリを扱う
- プライマリもレプリカも同じボリュームを見ている
- ３つの AZ に6つのコピーを持つ
Aurora エンドポイント
- クラスタエンドポイント
- 常にプライマリインスタンスを示す
- リーダーエンドポイント
- 常にAurora レプリカを示す
- インスタンスエンドポイント
- 各インスタンスごとのエンドポイント
セキュリティ
- 暗号化
- AES256 を用いる
- SSLで通信
- VPC 内に設置されるのでネットワークが分離される
- ノードへ直接アクセスは行うことができない
- PSIDSS などの業界標準のセキュリティとデータ保護の認証をサポート
ストレージ
- SSD を利用したシームレスにスケールするストレージ
- 10GB から 64TB まで自動的にスケール
- 実際に使った分だけ課金される
- 標準で高可用性
- 3つの AZ に6つのデータコピーを持つ
- クォーラムシステムの採用（レイテンシ軽減）
- 継続的に S3 へ増分バックアップ
堅牢性を高める手段の例
一般的なレプリケーション
- マスタの更新操作を複数のスタンバイ DB へ転送して複製する
- 同期レプリケーション
- 最も遅いディスクやノードに律速され, レイテンシ遅延が発生する可能性がある
- 非同期レプリケーション
- データ同期前に障害が発生した場合データロストの可能性がある
RDS での例
- プライマリノードが EBS / EBS のミラーに書き込み
- スタンバイノードが EBS / EBS のミラーに書き込み
- 両方終了後に ACK が返る
Aurora での例
Aurora ではクォーラムモデルを使用する
- 6つあるコピーに対して並列に書き込みを行う
- 4/6 のコピーから ACK が返ってくると ACK を返す
クォーラムモデル
- Vr : 読み込みクォーラム
- Vw : 書き込みクォーラム
- V : コピーの数
2つのルールが存在する
- 読み込みクォーラムと書き込みクォーラムが少なくとも１つの共通コピーを保持していること
- 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
3
