ステージ 1: 目標を設定する
必要なレベルの耐障害性とその測定方法を理解することが、「目標を設定する」ステージの基礎となります。目標がなく、また目標が測定できないと、何かを改善するのは困難です。
すべてのアプリケーションが同じレベルの耐障害性を必要とするわけではありません。目標を設定するときは、適切な投資とトレードオフを行うために必要なレベルを考慮してください。これは車とよく似ています。タイヤは 4 本ありますが、予備のタイヤは 1 本しか持ちません。乗車中に複数のタイヤがパンクする可能性は低く、余分なスペアがあることで、貨物スペースや燃料効率などの他の機能を損ねる可能性があるため、これは妥当なトレードオフです。
目標を定義したら、後のステージ (ステージ 2: 設計と実装、ステージ 4: 運用) でオブザーバビリティコントロールを実装し、目標が達成されているかどうかを把握します。
重要なアプリケーションのマッピング
耐障害性の目標を定義する際、技術的な会話に限定してはなりません。代わりに、ビジネス指向に焦点をあてた会話から始め、アプリケーションで提供する必要のある内容と障害による影響について理解します。次に、このビジネス目標に対する理解が、アーキテクチャ、エンジニアリング、運用などの分野にカスケードされます。定義する耐障害性目標がすべてのアプリケーションに適用される場合もありますが、目標の測定方法は多くの場合アプリケーションの機能によって異なります。ビジネスにとって重要なアプリケーションを実行している場合に、このアプリケーションに障害が発生すると、組織が重大な収益を損失したり、評判が損なわれたりする可能性があります。または、それほど重要ではなく、組織のビジネス遂行機能に悪影響を及ぼすことなく一部のダウンタイムを許容できる別のアプリケーションがあるかもしれません。
例えば、小売会社の注文管理アプリケーションについて考えてみましょう。注文管理アプリケーションのコンポーネントに障害が発生し、適切に稼働しなくなると、新規販売を遂行できません。この小売会社には、自社の建物の一角で営業を行っている従業員向けのコーヒーショップもあります。このコーヒーショップには、従業員が静的ウェブページでアクセスできるオンラインメニューがあります。このウェブページが利用できなくなった場合、一部の従業員は苦情を言うかもしれませんが、必ずしも会社に財務上の損害をもたらすとは限りません。この例に基づいて、会社では注文管理アプリケーションに対してより積極的な耐障害性目標を持つことを選択する可能性がありますが、ウェブアプリケーションの耐障害性を確保するために多大な投資を行うことはありません。
最も重要なアプリケーション、最も労力をかける場所、トレードオフを行う場所を特定することは、本番環境でのアプリケーションの耐障害性を測定することと同じくらい重要です。障害による影響をより適切に理解するために、ビジネスインパクト分析 (BIA) を実行できます。BIA は、重要なビジネスアプリケーションを特定して優先付けし、潜在的なリスクと影響を評価してサポートする依存関係を特定するための、構造化された体系的なアプローチを提供します。BIA は、組織の最も重要なアプリケーションに対するダウンタイムのコストを定量化するのに役立ちます。このメトリクスは、特定のアプリケーションに障害が発生し、その機能を完了できない場合のコストを概算するのに役立ちます。前の例では、注文管理アプリケーションに障害が発生した場合、小売ビジネスは大幅な収益損失となる可能性があります。
ユーザーストーリーのマッピング
BIA プロセス中に、アプリケーションが複数のビジネス機能に関与していること、またはビジネス機能に複数のアプリケーションが必要であることに気付くことがあります。前の小売会社の例を使用すると、注文管理機能のチェックアウト、プロモーション、料金設定用に個別のアプリケーションが必要になる可能性があります。1 つのアプリケーションで障害が発生すると、ビジネスや会社とやり取りするユーザーに影響が出る可能性があります。例えば、会社が新規注文の追加、プロモーションや割引へのアクセス提供、製品の価格更新を実行できない場合があります。注文管理機能に必要となるこうしたさまざまな機能は、複数のアプリケーションに依存している可能性があります。また、これらの機能には複数の外部依存関係が存在することもあり、この場合純粋にコンポーネントに焦点を当てた耐障害性を達成するプロセスが極端に複雑になります。このシナリオに対処するより良い方法は、ユーザーストーリー
ユーザーストーリーに焦点を当てることで、カスタマーエクスペリエンスのどの部分が最も重要なのかを把握できるため、特定の脅威から保護するためのメカニズムを構築できるようになります。前の例では、1 つのユーザーストーリーがチェックアウトであり、これにはチェックアウトアプリケーションが含まれ、価格アプリケーションとの依存関係があります。別のユーザーストーリーはプロモーションの表示に関するもので、プロモーションアプリケーションが関与しています。最も重要なアプリケーションとそのユーザーストーリーをマッピングしたら、これらのユーザーストーリーの耐障害性を測定するために使用するメトリクスの定義を開始できます。これらのメトリクスは、ポートフォリオ全体または個々のユーザーストーリーに適用できます。
測定値の定義
目標復旧時点 (RPO)、目標復旧時間 (RTO)、サービスレベル目標 (SLO) は、特定のシステムの耐障害性を評価するために使用される標準的な業界測定値です。RPO とは、障害が発生した場合にビジネスで許容できるデータ損失量を指します。一方、RTO は、停止後にアプリケーションを再度利用できるまでの速度の測定値を表します。これら 2 つのメトリクスは、秒、分、時間の時間単位で測定されます。アプリケーションが正常に動作している時間、つまり、設計どおりに機能し、ユーザーがアクセスできる時間を測定することもできます。これらの SLO では、顧客が享受することを期待するサービスレベルについて詳述し、1 秒未満の応答時間内にエラーなしで処理されたリクエストの割合 (%) などのメトリクスによって測定されます (例えば、リクエストの 99.99% が毎月応答を受け取ります)。 RPO と RTO はディザスタリカバリ戦略に関連しており、バックアップの復元からユーザートラフィックのリダイレクトまで、アプリケーションの運用とリカバリのプロセスが中断されることを前提としています。SLO は、アプリケーションのダウンタイムを軽減する傾向がある高可用性コントロールを実装することで対処されます。
SLO メトリクスは一般的に、サービスプロバイダーとエンドユーザー間の契約であるサービスレベルアグリーメント (SLA) の定義で使用されます。SLA には通常、財務上のコミットメントが伴い、これらの契約が満たされない場合にプロバイダーが支払う必要があるペナルティの概要が記載されています。ただし、SLA は耐障害性体制の測定ではなく、SLA を増やしてもアプリケーションの耐障害性は向上しません。
SLO、RPO、RTO に基づいて目標の設定を開始できます。耐障害性目標を定義し、RPO と RTO のターゲットを明確に理解したら、AWS Resilience Hub
追加の測定値の作成
RPO、RTO、SLO は耐障害性の良い指標となりますが、ビジネスの観点から目標を検討し、アプリケーションの機能に関する目標を定義することもできます。例えば、フロントエンドとバックエンド間のレイテンシーが 40% 増加した場合、1 分あたりの成功注文数は 98% を上回った状態が維持されます。または、1 秒あたりに開始されたストリームは、特定のコンポーネントが失われた場合でも、平均からの標準偏差内にとどまります。また、既知の障害タイプ全体で平均復旧時間 (MTTR) を短縮する目標を作成することもできます (例: これらの既知の問題のいずれかが発生した場合、復旧時間が x% 短縮される)。ビジネスニーズに沿った目標を作成すると、アプリケーションで許容する障害のタイプを予測できるようになります。また、アプリケーションに障害が発生する可能性を減らすアプローチを特定することもできます。
アプリケーションを強化するインスタンスの 5% が失われた場合に運用を継続するという目標を検討している場合、アプリケーションは事前にスケールするか、そのイベント中に発生する追加のトラフィックをサポートするのに十分な速さでスケールすることができると判断することがあります。または、「ステージ 2: 設計と実装」セクションで説明されているように、さまざまなアーキテクチャパターンを活用する必要があると判断することもできます。
また、特定のビジネス目標に対してオブザーバビリティ対策を実装する必要があります。例えば、平均注文率、平均注文価格、平均サブスクリプション数、またはアプリケーションの動作に基づいてビジネスの正常性に関するインサイトを提供できるその他のメトリクスを追跡できます。アプリケーションにオブザーバビリティ機能を実装することで、アラームを作成し、これらのメトリクスが定義された境界を超えた場合に対応策を取ることができます。オブザーバビリティの詳細については、「ステージ 4: 運用」セクションを参照してください。
