【セッションレポート】インシデントの影響を封じ込めるクラウドアーキテクチャの実践（AWS-58）#AWSSummit

はじめに

AWS Summit Japan 2024 に参加しました。

「インシデントの影響を封じ込めるクラウドアーキテクチャの実践」のセッションレポートです。

セッション概要

障害の影響範囲を抑えてシステムのレジリエンスを向上させる方法に関する Deep dive セッションです。マルチテナントの SaaS 環境でも広く使われており、AWS や Amazon が障害を隔離する際の戦略に採用している Cell-based architecture や Shuffle Sharding のテクニックについてご紹介します。併せて、これらを実装する上での技術的な課題や考慮点についても触れます。

セッションスピーカー：奥野 友哉

所属：アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリ技術本部 デジタルソリューション部

取り扱い内容

• セルベースアーキテクチャの効果
• セルベースアーキテクチャの設計ポイント
• 追加手法：シャッフルシャーディング

セッションレポート

ウェブアプリケーションの紹介事例3つ

• シナリオ1：コスト削減のため、不要になったDynamoDBの属性を一部削除した
  • 障害原因：実はアプリ内に残っていた依存関係があり障害がおきた
  • 対策案：テストを行い切り戻しできるようにしておく
    • しかし、全てのシナリオをテストすることは非現実的
• シナリオ2：ある機能の挙動がおかしいので、切り分けのためにポートをあける作業を行った
  • 障害原因：セキュリティグループのルール変更ではなく、ルールの削除をしてしまい障害がおきた
  • 対策案：本番環境は、手動では触らない。IaCやCI/CDを用いる
    • ミスを完全に防ぐのは難しい
• シナリオ3：特定のユーザーが想定していないデータ型/頻度のリクエストを送ってきた（Poison pill）
  • 障害原因：バグを踏んで障害を発生
  • 対策案：テストやスロットリング
    • 全てを想定することは難しい

３つのシナリオに共通するのが、全ての可能性を予測しつつ防ぐのは難しい。

障害の範囲が全体であることが問題。セルベースアーキテクチャで障害の影響範囲を小さくするのが有効的である

セルベースアーキテクチャとは

• アプリ全体をセル単位で複製し、論理的な境界を作成する手法
  • データプレーン
    • セル：独立したアプリケーション
    • セルルーター：リクエストを振り分け
  • コントロールプレーン
    • セルの作成や削除、データ移動を行う

セルベースアーキテクチャのメリット

• 障害分離性：障害の影響を全体のうち一部に抑えられる
  • 一般の構成：Poison pillで障害影響が全体に及ぶ可能性が高い
• スケール性：セルを追加することでスケールできる
  • 挙動が予想しやすくなる
  • 一般の構成：スケールアップが中心。サービス規模が大きくなることで発生する障害を受ける
• テスト性：特定のセルのみに変更が適用できるため、テストしやすい
  • 一般の構成：ブルーグリーンの影響は全体に影響がある

セルベースアーキテクチャを導入した場合、障害のシナリオを防ぐことができる

セルベースデメリット

• ハードウェア故障確率が増加する可能性がある
  • セルの数だけ増える
  • 自動復元で対策可能
• 複雑性とコストが増える
  • 自動化が一定の対策になる

EBSでも採用されている事例

• EBSのプライマリストレージは、セカンダリストレージにも書き込まれる
• プライマリの情報を「設定情報サービス」から取得することで整合性を保つ
  • 設定情報サービスの復元力が重要である

処理の流れは以下の通り。

1. クライアントは設定情報サービス内のセルルーターに問い合わせる
2. セル情報を取得
3. セルへプライマリ情報を取得

セルベースアーキテクチャ導入後、設定情報サービスの可用性が向上した。

ここまでのまとめ

• セルベースアーキテクチャとは、アプリ全体をセル単位で複製し論理的な境界を作成する手法
  • Poison pillなどの障害の影響範囲を1つのセルに封じ込めることができる
  • スケール性やテスト性のメリットもある
• 予期せぬ障害に対する対策が必要な重要サービスで効果的である

セルベースアーキテクチャの設計ポイント

セルベースアーキテクチャの主要設計ポイント３つ

• セルルーター
• セル
• コントロールプレーン

セルルーター

• セルルーターの機能と特性
  • データ分割に利用されているパーティーキーがどのセルにマッピングされているかを保持する
  • 共通コンポーネントのため、高い可用性とスケーラビリティが求められる
  • 可能な限りシンプルにすること
    • テスト不足や障害モードを減らす

セルルーティングの方法：DNSパターン

• DNSに対してどのセルに行くべきか問い合わせて、返ってくるIPでアクセスする方式
• Route 53はSLA 100%
• パーティションキーが利用できる場合は有用
• クライアント側で持っている情報とDNS名をマッピングのために、クライアント処理を追加する場合がある
  • マッピングが許容できない場合、API Gatewayパターンを利用検討する

セルルーティングの方法：API Gatewayパターン

• API GatewayをDynamoDBのプロキシとして利用する
• API Gatewayの機能が利用可能というメリットがある
• SLAを鑑みて、必要に応じてマルチリージョン化する
  • 高い柔軟性が求められる場合、コンピュータ層パターンを利用する

セルルーティングの方法：コンピュータ層パターン

• コンピュータ層を用意する
• 認証を含めて柔軟な処理が可能
• コンピュータ層自体も耐障害性を高める必要がある
  • データプレーン
    • ルーティング層を別々のVPCにする
    • DNSパターンでリクエストを分散する
    • セルベースアーキテクチャで耐障害性を高める
  • コントロールプレーン
    • セル情報をDBに置いておき、タスクが定期的に情報を更新する

アンチパターン：バイモーダルな挙動

• 古いデータしか見つからなかった場合は、クライアントへ最新情報を返却するために、ソースDBへアクセスする
• レジリエンスの観点でアンチパターン
• サービスが成長すると、過負荷になりやすい
• 古いデータを返却しながらポーリングし続ける方が障害範囲を広げずに済み、データプレーンの可用性も高くなる
• 仕事量を変えないシンプルな実装がレジリエンス向上につながる

その他のセルルーター構成パターン

• 非同期処理の場合、SQSキューパターン
• クライアントの変更が許容されない場合、リバースプロキシパターン

Amazon Music

• ユーザーメトリクス収集サービス
• リバースプロキシパターンを採用している
• 重要なイベントが他のイベントの影響を受けないことが目的である
• 最近セルベースアーキテクチャに移行された
• セルルーティングの設定情報はコード内に保存する。基本コードは変更しない。

セル

• セルの機能と特性
  • データはパーティションキーで分割
  • セル同士はレプリケーションせず、依存関係を無くすことが推奨されている

セルのパーティションキー

• セル同士のやりとりが少なくなるような、サービスワークロードを分割できるもの
• データの偏りが大きい場合、複数種類のキーを組み合わせることを検討する

セルのサイズと数

• 単一セルの特性を理解してセルのサイズと数を決定する
  • コスト
  • ネットワーク帯域など
• セルの上限になる前にセルの数を増やす。配置換えを行う
• セルの再配分方式を検討しておくことが重要になる

パーティションキーとセルのマッピング方法例

• 完全なマッピング（1:1）
• 範囲マッピング
• モジュロマッピング

コントロールプレーン

セルへのデプロイメント

• セルを利用した段階的なデプロイを採用すること
  • １つのセルで問題ないことを確認して段階的にデプロイしていく

セルのObservability

• セルを意識したモニタリングとロギングが必要
  • ログにセル情報を付与しておくことを推奨する

セルの再配分/移動の流れ

1. 移行元からコピー
2. 書き込み停止
3. 動機完了を確認
4. リダイレクト設定
5. セルルーター設定を変更
6. 移行元を削除

シャッフルシャーディングについて

一般的なアーキテクチャ

• クライアント全体がワークロード全体に対して、負荷分散される方式
• 8つのワーカーで処理
  • Poison pill で障害が起きると、他のワーカーにも流入し全体で障害が発生してしまう

セルベースアーキテクチャ

• クライアントに対して複数のワーカを割り当てる方式
  • Poison pill の影響範囲はセルに狭まる

シャッフルシャーディング

• クライアントに対して複数のワーカー（シャード）を割り当てる方式
  • ワーカー全体から複数のワーカーをクライアントに組み合わせる
  • ワークロードは障害の影響を一時的に受けるが、別のワーカーで処理が継続的に可能になる

まとめ

• セルベースアーキテクチャおよびシャッフルシャーディングにより障害の影響が狭められる
  • 複雑性やコスト増とのトレードオフになる

セルベースアーキテクチャのハンズオン

感想

セルベースアーキテクチャでは、障害の影響範囲を限定できることを学びました。

大規模なシステムでは予期せぬ問題が発生することは避けられませんが、セルベースアーキテクチャによって影響を最小限に抑えることができるというのは、システムの信頼性と可用性を高める上で非常に重要だと感じました。

セルベースアーキテクチャの設計ポイントにおいて、馴染みのなかった用語ですが、セルルーター、セル、コントロールプレーンのそれぞれの役割と実装方法について、理解することができました。

特に、セルルーティングの方法として紹介されたDNSパターン、API Gatewayパターン、コンピュート層パターンの比較は、実際のシステム設計時に参考になりそうです。

それぞれのパターンの特徴や適用場面を把握することで、より適切なアーキテクチャ選択ができると考えます。

セルベースアーキテクチャでは複雑性やコストの増加は避けられない課題ですが、システムの重要性や求められる可用性、スケーラビリティに応じて、適切に判断する必要があると理解しました。

ハンズオンがありますので、実際に試して理解を深めたいと思います。