この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
TL;DR
- 現代のシステムには「回復力 (Resilience, レジリエンス)」が重要
- 責任共有モデル for Resilience と AWS W-A 信頼性の柱
- ベストプラクティスを全て採用する必要はない、理解することが重要
セッション情報
AWS Summit Tokyo 2023 会場にて行われた、標題のセッションをレポートします。
タイトル
AWS-14 Resilience at AWS 回復力のあるシステムを作る為の設計指針
(Level 200: 初級者向け)
スピーカー
石倉 徹氏
- アマゾン ウェブ サービス ジャパン合同会社
- パートナーアライアンス統括本部
- Strategic SI 技術部 パートナーソリューションアーキテクト
概要
システム継続性、パフォーマンス維持は、昨今の IT サービスにおいて重要な要素になっています。一方で障害が起きないシステムを作るということは、非常に難しいものとなっており、レジリエンス（障害からの回復力）を備えたシステムが求められています。本セッションでは、AWS クラウド上でのレジリエンスについて、どのようにアプローチすればよいか、設計指針、活用サービスをご紹介致します。
（公式セッション情報より引用）
内容
※ 以下、セッションで話された（聞き取った）内容のメモをもとに、記事執筆者の理解に基づいて情報を補いつつ記載します。全てが登壇者の言葉では無いことにご留意下さい。また、太字強調や外部引用、章分けも記事執筆者によります
セッションの対象者
- AWS の基本的な概念を知っている
- 信頼性や可用性に不安を持っている
なぜ Resilience が重要なのか？
- 現代のシステムには「回復力 (Resilience, レジリエンス)」が重要
- なぜ重要なのか？
- Amazon CTO の言葉「Everything fails, all the time.」
- 全てのものはいずれは壊れる、という意味
- 必ず壊れるものを「壊れないように」するより、壊れることを前提に 「壊れてもすぐ復旧 (回復) するようにしよう」 という考え方
- Resilience とは？
- 障害から迅速に復旧することができる能力
- ビジネスの面においても「これまで以上に」重要
- DevOps digestの記事：計画外のシステムダウンで莫大な損害
- 現代では、サービスは常時 ON が期待されていて、使えないとブランドに悪影響を及ぼす可能性がある
- AWS へ移行後、インシデントの数そのものの削減に成功している
- 海外の金融 Capital-One の事例
- なぜか？ --> レジリエンスの確保がしやすくなったから
(AWS re:Invent 2022 - Building modern apps: Architecting for observability & resilience セッション動画より)
- 責任共有モデル for Resilience
- Resilience 'of' the Cloud - クラウド「の」回復力についての責任
- クラウド基盤そのもののレジリエンス
- クラウド基盤の提供元 = AWS が責任を持って担当する範囲
- 利用者はここをコントロールできない
- なので、利用にあたっては 「どのような特性をもっているか？」を理解すること が重要
- Resilience 'in' the Cloud - クラウド「内の」回復力についての責任
- クラウドを使う上でのレジリエンス
- クラウド利用者 = ユーザーが責任を持つべき/持つしかない範囲
- (逆に言えば) 各ユーザーがコントロール可能、一番重要になる
(AWS ドキュメント 回復性に関する責任共有モデル - 信頼性の柱 より引用)
Resilience of the Cloud
- AWS グローバルインフラストラクチャ
- リージョン (Region)
- 他のリージョンと完全に分離されるように設計している
- 何かあっても他のリージョンに波及しない
- アベイラビリティゾーン（Availability Zone, AZ）
- 各 AZ 間は十分に離れてはいる
- 一方で AZ 間のレイテンシはリージョン間より短い（速い）
- リージョン (Region)
Resilience in the Cloud
- どう設計すれば良いか？ --> 3 つのポイント
- 高可用性（High-Availability, HA）
- 一般的な障害に対する耐性
- ディザスタリカバリ（Disaster Recovery, DR）
- 災害級の障害
- 起こることはまれ（ゼロではない）だが、起こってしまうと被害甚大
- Resilience の継続性
- HA と DR を横串に
- CI/CD、Code 改善、運用テスト、オブザーバビリティ、カオスエンジニアリング
- 高可用性（High-Availability, HA）
可用性
- 可用性 = ワークロードが使用可能な時間の割合
- 向上させるには？
- MTBF と MTTR
- MTBF : 耐障害性向上のアプローチ
- Mean Time Between Failure
- 冗長化、過負荷を避ける、テスト、バグの排除、障害範囲の限定化
- MTTR : 障害復旧・運用性向上のアプローチ
- Mean Time to Recover
- モニタリング、起動が速いサービス構造、復旧手順の確立・自動化
- MTBF : 耐障害性向上のアプローチ
- DR 目標の検討
- RTO = ダウンタイムの許容（どの位止まっていていいか？）
- Recovery Time objective
- RPO = データロストを許容できる時間（どの位前まで巻き戻ってもいいか？）
- Recovery Point objective
- RTO = ダウンタイムの許容（どの位止まっていていいか？）
- DR 戦略
- RPO/RTO: 数時間単位〜リアルタイム
- リアルタイム度があがればあがるほど費用もかかる
(事業継続性が求められる基幹システムの DR 戦略 | Amazon Web Services ブログ より同様の図を引用)
- 可用性のニーズ (設計)
- コンポーネント単位でも検討
- 宅配アプリの例
- ドライバーのアサイン : ないと業務がとまる --> 重要性:高
- 地図ナビゲーション : なくても地図を見ればなんとかなる --> 重要性:低
- それぞれのコンポーネントに適切な目標設計（差別化）
- 具体的にはどうつくれば？ --> W-A
AWS Well-Architected Framework (W-A) 信頼性の柱
- W-A とは
- 設計・運用の大局的な考え方、ベストプラクティス
- 「質問」とベストプラクティスが重要
- ひとつずつ確かめながらシステムレビューを行っていく
- ここではいくつかかいつまんで紹介
- ちなみに、W-A は難しい表現が使われているところがあるが、しっかり解説されているので中身を読んで欲しい
- ワークロードアーキテクチャ : 分散システムの設計
- 【REL04-BP02】 疎結合であること
- 密結合だと、ひとつのコンポーネント障害が全体に波及する
- パターン
- ELB をはさむ (並列分散)
- 非同期型 - SQS
- 【REL05-BP01】グレイスフル・デグラデーション
- ハードな依存関係 : 一連の処理で、連携先で 1 ヶ所エラーが起きると全てエラーとなる
- ソフトな依存関係 : 依存先でエラーが発生しても可能な限り可用性が維持される
- 【REL04-BP02】 疎結合であること
- 変更管理（モニタリング）
- 【REL06-BP01】全てのコンポーネントをモニタリングする
- フロントエンド、ビジネスロジック、ストレージ、AWS サービス etc.
- KPI に連動したモニタリングを
- 「正常に処理されたオーダー数」など
- サービス低下の早期警告サインを識別
- レスポンスの自動化 --> RTO/MTTR の短縮
- 【REL06-BP01】全てのコンポーネントをモニタリングする
- 障害管理
- 【REL12-BP05】カオスエンジニアリング
- 不安定な状況をシミュレート
- AWS Fault Injection Simulator
- AWS Resilience Hub
- 【REL12-BP05】カオスエンジニアリング
- ベストプラクティスとは
- 全てがこれに沿っている必要は無い
- 「こうなってないとリスクがある」という理解が重要
まとめ
- 本日のポイント
- 責任共有モデル for Resilience
- 'of' の性質と 'in' の設計指針
- W-A とベストプラクティス
- 是非 W-A を活用したレビューを！
所感
とかくシステムというと「全く落ちない」ことを目指しがち（目指されがち）ですが、目指せば目指すほどコストが爆上がりですし、万一が起きた際の復旧にかえって時間がかかってしまうようなこともありがちで、現実問題としては不可能と捉えるべきです。
ではそのうえで「どうすれば？」を、AWS の Well-Architected フレームワークというベストプラクティスを紐解きながら、要所要所を解説してもらえる非常に興味深いセッションでした。
資料等が公開されたら、是非いちどご覧ください！
18
