← AWSサービスの内部原理 コース
4. パーティションは実はサーバーである — 3コピー複製と可用性
「パーティション」の正体から可用性が成り立つ理由まで、箱と矢印で順に追っていきましょう。
①パーティションの正体は「データ」、載せているのはサーバー
テーブル見た目は1枚
実体は分割された
パーティションASSD上のストレージ割り当て
パーティションB
パーティションC
コピーを載せて動かすのは
ストレージノード物理サーバー
多くのテーブル由来のパーティションを相乗りで抱える(多対多)- ・パーティション=1台のマシンではない。実体はデータ(と複製)
- ・「ストレージノード」の呼称は2022年のDynamoDB論文(USENIX ATC)由来
パーティションはSSDに裏打ちされたデータの割り当てで、背後の物理サーバー群(ストレージノード)がそのコピーを載せて動かします。
②同じ中身を3コピー、別々のAZへ
パーティションA
3つのレプリカに複製
レプリカ1AZ-a のノード
レプリカ2AZ-b のノード
レプリカ3AZ-c のノード
- ・1台だけだと、そのサーバーやAZが落ちればデータに触れなくなる
- ・分散システムで学んだ「複製で冗長化」をAZまたぎで自動実行している実例
同じパーティションの中身は一般に3コピーとして別々のAZのノードへ複製されるため、利用者は故障やAZ障害を意識せずに使えます。
③レプリカ1つの中身 — B木とWAL
レプリカ1つ
中に持つ
B木キーを範囲で並べ対数時間で探索
WALまずログに追記→本体へ反映
ログレプリカB木なし・ログのみ
故障からの素早い復旧に使う軽量な複製- ・WALのおかげで途中でノードが落ちてもログを再生して整合した状態に復旧できる
- ・「レプリカは常にB木とログの両方を持つ」とは限らない
- ・この内部構造は2022年論文由来。AWS公式のパーティション解説ページには書かれていない
各レプリカは検索用のB木と、変更を先に記録するWALを持ちます。データベースの定石そのままの構造です。
④書き込みはリーダーが受け付ける(Multi-Paxos)
書き込み
1つのリーダーが受付
リーダーレプリカ
Multi-Paxosで1つの複製グループを組む他レプリカへ複製
レプリカ2
レプリカ3
- ・2007年のDynamo論文とは別物: あちらはリーダーレス+consistent hashing+quorumの結果整合性
- ・今のDynamoDBはそこから発展したMulti-Paxosによるリーダー方式。混同すると挙動予測を誤る
3レプリカは好き勝手に書くのではなく、Multi-Paxosで合意し、リーダー役の1つが書き込みを受けて他へ複製します。
⑤AZが落ちても続く理由 — クォーラム
レプリカ1 ✕AZごと障害
レプリカ2
レプリカ3
多数(クォーラム)が残れば
処理を継続
落ちたのがリーダーなら
リーダー再選出その間、書き込み・強整合読み取りは一時待ち
その後、自動で復帰- ・「即座に無停止で何でも続く」と単純化するのは不正確
3コピーが別AZにあるため、1つ落ちても残りで多数が保てれば継続。リーダー喪失時だけ再選出までの短い待ちが入ります。
⑥「高可用でマルチAZ」を基礎から再導出
サーバー
複製
合意
B木+ログ
組み合わせると
DynamoDBは高可用でマルチAZ
マネージドサービスの中身も、結局はコンピュータの基礎の組み合わせでできています。