この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。
この記事では、2022年5月26日(木)に行われたAWS Summit Online 2022のオンラインセッション SP-04『Design for Resilience - 如何にしてクラウドアプリケーションの耐久力を高めるか』をレポートします。
セッション概要
タイトル:
Design for Resilience - 如何にしてクラウドアプリケーションの耐久力を高めるか(SP-04)
概要:
今日では多くのビジネスがクラウド上に構成され、私たちの生活と密接に結びついています。ひとたびクラウド上のシステムに問題が発生するとその影響範囲は広く、クラウドの特性を踏まえてシステムの耐久力を高めることは開発者にとって重要な課題になっています。本セッションでは、想定外の障害からアプリケーションを柔軟に回復させるためのベストプラクティスをアーキテクチャ、開発プロセス、組織・文化の観点から紐解きます。
トピック:
ディザスタリカバリ / レジリエンス / Well-Architected
スピーカー:
AWS 技術統括本部 チーフテクノロジスト 技術統括本部 チーフテクノロジスト 内海 英一郎 氏
セッションリンク（AWS Summit Online 2022 への登録が必要です）
下記リンクでアーカイブが視聴可能です。
※閲覧には、AWS Summit Online 2022の無料登録が必要です。
レポート
前座
AWSジャパンの五十嵐さん、宇都宮さんによるお話
昨日の振り返り
- 電笑戦
- キーセッション
このセッションについて
- 何が聞けるのか？
- どうやって課題を克服するか
- レジリエンス＝回復する力、耐久性
- クラウドにおけるベストプラクティスだけでなく、レジリエンスを実現するための開発プロセス、文化醸成の話
ここからが内海さんによるお話
レジリエンスとは
- 英語で「抵抗力」や「回復性」あるいは「弾力性」を表す言葉
- ストレスを跳ね返すという言葉としても使われていた。
では情報システムにおけるレジリエンスとは？
- HA (High Availability)
- 定常的に発生しうる部分的な障害に対する抵抗力
- MTBFとMTTR
- DR (Disaster Recovery)
- 滅多に発生しない広範囲の障害に対する回復力
- RTOとRPO
- アップタイムを長く、ダウンタイムを短く
なぜレジリエンスが必要なの？
- 障害を起こした場合の影響が大きすぎる
- 業績に大きく影響
- 特にお金に関係する場合
- 飛行機予約サービス、振込関係のサービスなど
- 影響は強くなることはあっても弱くなることはない
障害とは？
レジリエンスを高めるにはまず障害を知ろう
障害の原因
- コードや設定
- データや状態
- データの損害、古いキャッシュを参照、リソース逼迫など
- コアインフラ
- 上2つより稀なケース
- 電力供給設備障害など
- 災害シナリオ
- コアインフラより稀なケース
障害の影響
- エラー応答
- 「コードや設定」の障害に起因
- レイテンシー増大
- 「データや状態」の障害に起因
- 接続性低下
- 「コアインフラ」の障害に起因
- サービス中断
- 「災害シナリオ」の障害に起因
どうすればいいのか？
- 障害の原因は、あらゆる状況を想定するのが難しい
- だが、障害の影響というのはコントロールが効きやすい
- バックアップ
- リージョン切り替え、引き継ぎはオンラインで簡単
コントロール出来ないもの（原因）にコストを投資するべきではない
出来ることにコスト投資をするべき
クラウドにおけるレジリエンス
- AWSの対応範囲はハードウェア、インフラ部分 (クラウドそのもののレジリエンス)
- お客様の対応範囲はその上に乗るアプリケーション (クラウド上のレジリエンス)
- ↓ この範囲でレジリエンスを高める ↓
- アーキテクチャ
- 開発プロセス
- 組織・文化
- ↓ この範囲でレジリエンスを高める ↓
アーキテクチャ
- アーキテクチャの対応は以下に分かれる
- 基本戦略
- 構造
- 振る舞い
基本戦略
冗長化
- webサーバの可用性
- DBの可用性
- 冗長構成を取ることでアプリケーション全体の可用性が上がる
- これが冗長化の力
- 複数系統を用意すればするほどアプリケーションの可用性が上がる
- データのバックアップも大事
隔離
- リソースの保護
- マルチAZデプロイメントはクラウド特有の構成
- 複数のAZは同時に影響を受けにくい
- AWSの標準
- マルチリージョンデプロイメントでリージョン単位の障害から保護することも可能
- DynamoDBやS3などもクロスリージョンの機能を持つ
冗長化と隔離はセット
構造
サービス指向アーキテクチャ
- 全てを1つのドメインにするのではなく、複数のドメイン(サービス)に分割
- そうすることで、あるサービスの障害が別のサービスに影響しなくなる
セルアーキテクチャ
- サービス指向アーキテクチャのサービス内をさらにセルと呼ばれる区画に分割する
- 障害の影響範囲をさらに狭めることが可能に
振る舞い
- 構成要素の依存関係
- 依存関係の障害を予防するのが振る舞い
リトライ
- 再試行することでエラーを回避
- ただ、即座に再試行するとリトライ先のサービスが過負荷になる
- なので呼び出しを段階的に増やしリクエストの衝突を避ける
タイムアウト
- リクエスト先のサービスが応答しない場合、リクエストを切る
- リクエスト元のサービスが過負荷になるため
フォールバック
- リクエスト先のサービスが応答しない場合、事前に用意していた応答を返す
- ただし、代替手段が副作用を持つ場合があることに注意
サーキットブレーカー
- 非常にスマートな振る舞い
- 失敗するもの、過負荷なものは実行しない
- リクエスト元とリクエスト先のサービスをどちらも保護する
- タイムアウトタイマーの期限が切れると、ハーフオープン状態に移行
- 呼び出し成功率が一定の閾値に到達した場合、クローズする
レート制限
- 呼び出しの失敗数が一定になった場合
- リクエスト先のサービスのせいでリクエスト元のサービスに負荷がかかっている
- リクエスト元で制限をかけることで、リクエスト先の負荷も軽減される
- リクエスト先のサービスのせいでリクエスト元のサービスに負荷がかかっている
開発プロセス
- モニタリング
- デリバリー
- テスト
モニタリング
UCM (User-Centric Monitoring)
鍵となるメトリクスを段階的に監視する
- 正常性メトリクス
- 障害がユーザーに影響しているか？
- ↓ これら4つのメトリクスは大事。これらについてはオンコールエンジニアに必ず報告 ↓
- 「エラーレート」
- 「レイテンシー」
- 「リクエスト数」
- 「カナリアテスト失敗」
- 診断メトリクス
- 障害の原因は何か？に、答えるかもしれないデータ
- 「リソース可用性」
- 「リソース使用率」
- 「エラーログ・トレース」
- 「依存関係の正常性メトリクス」
ダッシュボーディング
- 良いダッシュボードは影響の確認〜原因の修正が素早くできる
- アプリケーション更新の際には必ずダッシュボードも見直そう
- 本番前の環境でもダッシュボードを使えるようにしておきたい
- ダッシュボードはIaCで管理しよう
『良いダッシュボードとは？』
- 最重要なメトリクスは最上部に大きく表示
- 正常性メトリクスが大事
- 画面解像度の低いデバイス用にレイアウト
- 特に横スクロールバーは見落としがちなので、横幅に気を付ける
- 単一のタイムゾーン(UTC)を表示
- 比較がしやすくなる
- 同一の時間幅と分解能でデータを表示
- 比較がしやすくなる
- アラームの閾値でグラフに注釈を入れる
- 正常か異常かがぱっと見でわかる
- グラフの説明文をテキストで表示
- APIの機能や正常な場合の数値、挙動など
デリバリー
フラクショナルデプロイメント
- 特に大きな変更というのは問題の発生時に原因の診断や影響の緩和が難しくなる
- 影響を限定化するのが、フラクショナルデプロイメント
- テストの環境を複数用意する（例：アルファ、ベータ、ガンマ）
- セルごとにテストし、One Boxにデプロイを行う
- デプロイも段階的に行う。ブルーグリーン or ローリング
- その後、Fleetにデプロイ
2フェーズデプロイメント
- ロールバックは本当に大事
- ロールバックを成功させるには、後方互換が大事
- アプリの例
- Ver1のデータをVer2で読み込めるが、逆が出来ない。
- どうすればいいか？変更を分割しよう
- Ver1とVer2の間にデータを中継出来るようなVerを1つ挟む
- これはDB切り替えにも利用できる
- 変更を分割し、ロールバックが成功することを確認しよう
テスト
カオスエンジニアリング
- 定常状態の定義 → 仮説構築
- 仮説構築が出来ない場合はアーキテクチャを見直す
- 実験ではメトリクスをモニタリング
- チームに「障害に対応できるんだ」という自信をつけさせられる
- つまり、文化を醸成させられる
- いきなり本番で始めないこと
- まずは避難訓練形式で実施
- その次にデリバリーパイプラインで自動化
- 最後に本番環境へ
組織・文化
- 動機づけ
- 知識形成
- スケール
動機づけ
明確で完全なオーナーシップ
- 1つのチームは1つのサービスを所有
- 1つのサービスは1つのチームが所有
- チームはサービスの全構成要素を所有
- チームはサービスの全フェーズを所有
『それが出来ていないと？』
- アーキテクチャや開発プロセスの習熟度が低下
- 別チームに依存
- リソースの境界設定や振る舞いの最適化が抑制
- コンウェイの法則
- 一部の構成要素・フェーズに改善意識が縮小
- 責任を持たなくなる
『出来ていると？』
- アーキテクチャや開発プロセスの習熟度が向上
- 完全に自分ごとでやる
- リソースの境界設定や振る舞いの最適化が促進
- 逆コンウェイの法則
- 全ての構成要素・フェーズへ改善意識が拡大
- 責任を持たなければならなくなる
知識形成
COE (Correction of Error)
- 回復のためのアクションアイテムを特定
- 自分のチームは新しいアイテムを獲得
- 別チーム(レビュワー)はアイデアを発見
- 記載すべき内容は以下
- 「障害の概要」
- 「メトリクス」
- 「影響」
- 「タイムライン」
- 「ラーニング」
- 「アクションアイテム」
スケール
週次の運用ミーティング
- ダッシュボードにおいて他チームからのフォードバックを受ける
- レビューイ(レビューされる側)のダッシュボードチームはルーレットでその場で決定
まとめ
- AWS利用ユーザーが以下を見直すことが大事
- クラウドにおけるレジリエンス
- アーキテクチャ
- 開発プロセス
- 組織・文化
- クラウドにおけるレジリエンス
- 以下も参考にしてほしい
- The Amazon Builders' Library
- 詳細な解説
- タイムアウトやリトライの閾値なども載っている
- 詳細な解説
- 信頼性の柱 - AWS Well-Architected フレームワーク
- The Amazon Builders' Library
最後に
聴講前はアプリケーションやインフラの構成における耐久性のベストプラクティスについて話されるセッションなのかな？と思っていましたが、実際にはそのための組織づくりという根本の大事なお話もありました。
聴いていて納得出来る部分が多く、非常に有意義なセッションでした。
アーカイブも残されていますので、是非ご視聴ください。(本記事上部の2つ目のセッションリンクからアクセス出来ます)
以上、べこみんでした。
0
