【AWS Summit Japan 2022】Design for Resilience – 如何にしてクラウドアプリケーションの耐久力を高めるか(SP-04)

kazuki.oshima

AWS

2022.5.27

Topics

セッション概要
セッション内容
まとめ

はじめに

この記事は AWS Summit Japan 2022 5月26日(木) のセッション「 SP-04：Design for Resilience – 如何にしてクラウドアプリケーションの耐久力を高めるか」に参加した時のレポートになります！

セッション概要

タイトル

Design for Resilience – 如何にしてクラウドアプリケーションの耐久力を高めるか(SP-04)

今日では多くのビジネスがクラウド上に構成され、私たちの生活と密接に結びついています。ひとたびクラウド上のシステムに問題が発生するとその影響範囲は広く、クラウドの特性を踏まえてシステムの耐久力を高めることは開発者にとって重要な課題になっています。本セッションでは、想定外の障害からアプリケーションを柔軟に回復させるためのベストプラクティスをアーキテクチャ、開発プロセス、組織・文化の観点から紐解きます。

スピーカー

AWS 技術統括本部チーフテクノロジスト
内海英一郎氏

セッション内容

【レジリエンスとは】

re・sil・ience

英語で「抵抗力」、「回復力」、「弾力性」を意味する。
物理学で「外力による歪みを跳ね返す力」と用いられていた。

近年心理学をはじめとして、「困難な状況下でしなやかに適用する能力」としても使われるようになる。

レジリエンスの言葉について深くまで知っていなかったので勉強になります。

【情報システムにおけるレジリエンス】

２つの力の足し算で成り立っている。

「定常的に発生しうる部分的な障害に対する抵抗力」
インスタンスを誤って落としてしまったり等ですね。
- HA ( High Availability )
  - 指標： MTBF・MTTR

「めったに発生しない広範囲の障害に対する回復力」
Disaster は「災害」の意味なので、データセンターが落ちてしまったりといったことになります。
- DR ( Disaster Recovery )
  - 指標： RTO・RPO

ここでは「アップタイムは長く、ダウンタイムは短く、そしてデータロスをできるだけ少なくすることが目的」という言葉が印象に残っています。

【レジリエンスの重要性】

レジリエンスが極めて重要な理由

障害が起きたとして、その障害の影響が大きすぎる。
- インフラの障害
  - お金の振り込みができない
  - 携帯がネットワークにつながらない、
  - 鉄道や航空機の運航を止めないといけない
ビジネスや生活は、システムに大きく依存している。
依存が強くなることがあっても、弱くなることはないので代替手段に戻せない。

IT に限らず公共のものが止まってしまうと、もはや災害に近い状態になるからこそレジリエンスが重要ですね。
身近な例で鉄道の振替輸送も1つのレジリエンスとして挙げられると思います。

【レジリエンスのデザイン】

障害とは
システムが正常な稼働状態を維持できていないこと

システムを保護するための２つのアプローチ

障害の「原因」から – 「コントロールが効かない」
1. コードや設定 ( バグ、証明書期限切れ )
2. データや状態 ( データ消失、リソースひっ迫 )
3. コアインフラ ( ラックが故障、電力供給の停止 )
4. 災害シナリオ ( 予期せぬ自然災害、大規模なサイバー攻撃 )

障害の「影響」から – 「コントロールが効きやすい」
1. エラー応答
2. レイテンシー増大
3. 接続性低下
4. サービス中断

自然災害を抑制することは不可能に近いので、利用者にエラー応答が返らないための仕組みを考える「影響」のアプローチが良いということになりますね。

【クラウドにおけるレジリエンス】

3つの構成要素がレジリエンスを支える

アーキテクチャ
1. 「振る舞い」
  - リトライ
    - 失敗したときに再試行する
    - 注意としてリトライストームが起きてしまい、逆に回復が長引く恐れがある
    - 指数的バックオフで呼び出しのバックオフを増やす
    - 呼び出しの間にランダムな待機時間を加える
  - タイムアウト
    - 失敗したときにタイムアウトしてリソースを開放する
    - キューが溜まり過負荷になる恐れがある
  - フォールバック
    - 予め用意した応答を返すことでエラーの連鎖を遮断する
  - サーキットブレーカー
    - 一定のしきい値を超過した場合にオープン状態になり、以降の呼び出しを即座に失敗させる
    - ハーフオープンになり、呼び出し成功率が一定のしきい値に到達するとクローズされ、全ての呼び出しを転送する
  - レート制限
    - 一定の上限値に到達した場合、超過した呼び出しを即座に失敗させる
2. 「構造」
  - サービス志向アーキテクチャ
    - アプリケーションの全機能でリソースを共有
    - 一部の機能障害がアプリケーションに波及しやすい
  - セルアーキテクチャ
    - アプリケーションを独立したサービス(ドメイン)に分割して境界を設定する
    - サービスを独立した区画(セル)に分割し、トラフィックをルーティング
    - 障害の影響範囲を特定のサービスに限定できる
3. 「基本戦略」
  - 冗長化と隔離
    - システムの経路を冗長化
    - マルチアベイラビリティゾーンデプロイメント
    - マルチリージョンデプロイメント

アーキテクチャだけでも「振る舞い」「構成」「基本戦略」と、深堀しつつリストアップすると様々な手段があることが伺えます。
セルアーキテクチャを取り入れることで、更にレジリエンスあるシステムになりそうです。

開発プロセス
1. 「テスト」
  - カオスエンジニアリング
2. 「デリバリー」
  - フラクショナルデプロイメント
    - ソース→ビルド→テスト→本番
    - デプロイメント時のテストについて
      - アルファ
        サービス単体のテスト
      - ベータ
        複数サービスでの結合テスト
      - ガンマ
        本番同等構成での運用テスト
  - 2フェーズデプロイメント
3. 「モニタリング」
  - UCM ( User-Centric Monitoring )
    - 正常性メトリクス (障害がユーザに影響しているか)
      ※ これらはアラームで通知させる
      - エラーレート
      - レイテンシー
      - リクエスト数
      - カナリアテスト失敗
    - 診断メトリクス (障害の原因は何か)
      - リソースの可用性
      - リソース使用率
      - エラーログ・トレース
      - 依存関係の正常性メトリクス
  - ダッシュボーディング
    障害の状況、問題の予兆を確認できるようになる
    - 最重要なメトリクスは最上部に大きく表示
    - 画像解像度の低いデバイス用にレイアウト
    - 単一のタイムゾーン (UTC) を表示
    - 同一の時間幅と分解能でデータを表示
    - アラームのしきい値でグラフに注釈をつける
    - グラフの説明文をテキストで表示

カオスエンジニアリングをする際、最初から本番で障害を起こさずに本番と同等の環境で障害を起こして、ある程度改善を重ねてパイプラインへの組み込みや本番でのカオスエンジニアリングとつなげていくようです。

モニタリングで触れたダッシュボーディングでは、グラフの説明文に調査するためのリンクを張り付けるといったプラクティスも取り入れてみたいですね。

組織・文化
1. 「スケール」
  - 週次の運用ミーティング
    - Ops Win 発表
    - COE ポストモーテムレビュー
    - ダッシュボードレビュー
2. 「知識形成」
  - COE (Correction of Error)
    - 改善となるアクションアイテムを特定
    - 障害の影響、経緯、原因、対策を示したポストモーテムを他チームに公開
    - 自チームはアイデアを見つけ、他チームは改善に応用できるプラクティスを学習
3. 「動機づけ」
  - 明確で完全なオーナーシップによる利点
    - アーキテクチャや開発プロセスの習熟度が向上
    - リソースの境界設定や振る舞いの最適化が促進
    - 全ての構成要素・フェーズへ改善意識が拡大