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