可用性ニーズを理解する

最初に、アプリケーションの可用性をアプリケーション全体の単一ターゲットとして考えてしまうケースがよくあります。しかし多くの場合、詳しく分析してみれば、アプリケーションやサービスでは、特定の側面に応じて求められる可用性の要件もさまざまであることに気付くはずです。例えば、システムによっては、既存データを取得するよりも、新規データを受信して保存する機能を優先させる場合があります。また、システムの構成や環境を変更するオペレーションよりも、リアルタイムオペレーションを優先させるシステムもあります。1 日のうち特定の時間帯に極めて高い可用性が要求されるサービスでも、その時間帯以外は長時間の中断を許容できる可能性もあります。これらは、1 つのアプリケーションを分解し、それぞれの構成要素の可用性要件を評価する方法のほんの一例です。この方法のメリットは、システム全体を最も厳格な要件に合わせて設計するのではなく、特定のニーズに応じて可用性に労力 (および費用) をかけられることです。

推奨事項
各アプリケーションの固有の側面を厳密に評価し、必要に応じてビジネスニーズを反映して、可用性とディザスタリカバリの設計目標を差別化してください。

通常、AWS では、サービスを「データプレーン」と「コントロールプレーン」に分けて考えます。コントロールプレーンで環境を設定しつつ、データプレーンではリアルタイムのサービスを提供します。例えば、Amazon EC2 インスタンス、Amazon RDS データベース、Amazon DynamoDB テーブルの読み取り/書き込みオペレーションは、すべてデータプレーンによる操作です。逆に、EC2 インスタンスや RDS データベースの起動、DynamoDB のテーブルメタデータの追加や変更などは、すべてコントロールプレーンによる操作です。これらすべての機能には高レベルの可用性が重要となりますが、一般的にデータプレーンの可用性設計の目標は、コントロールプレーンより高くなります。したがって、高い可用性要件を持つワークロードでは、コントロールプレーンの操作に対するランタイム依存を避ける必要があります。

AWS のお客様の多くは、類似のアプローチを採用して、アプリケーションを厳密に評価し、さまざまな可用性ニーズを持つサブコンポーネントを特定しています。次に、さまざまな側面に応じた可用性設計目標の調整を行い、システムを設計するための適切な作業を行います。AWS は、99.999% 以上の可用性を持つサービスを含め、広い範囲の可用性設計目標を持つアプリケーションを開発する豊富な経験を有しています。AWSソリューションアーキテクト (SA) は、お客様の可用性目標に対する適切な設計を支援します。設計プロセスの初期段階から AWS を導入することで、当社が可用性目標の達成を支援する能力も高まります。可用性の計画は、実際のワークロードが始動する直前にだけ立てるものではありません。運用上の経験を積み、実際のイベントから学び、さまざまな種類の障害に耐えながら、設計を改良し続けることも必要です。これにより、実装を改善するための適切な作業を行うことができます。

ワークロードに求められる可用性のニーズは、ビジネスのニーズと重要度に合わせる必要があります。まず、RTO、RPO、および可用性を定義し、ビジネスにとって重要なことのフレームワークを明確にすることで、各ワークロードを評価できます。このようなアプローチでは、ワークロードの実装に関与する担当者が、フレームワークと、ワークロードがビジネスニーズに与える影響を理解している必要があります。