高可用性とフォールトトレランス：定義とトレードオフ

高可用性（HA）とフォールトトレランス（FT）は、アーキテクトが混同しがちな、異なる2つの信頼性の目標です。高可用性とは、システムのダウンタイムを最小限に抑えることです。障害には耐えられますが、復旧中に短時間の中断が発生する場合があります。フォールトトレランスとは、コンポーネントに障害が発生しても、完全に冗長化された経路が即座に引き継ぐことで、中断なくシステムの稼働を続けることです。

可用性は、年間の稼働時間の割合として測定します。99.9%の可用性（スリーナイン）は、年間で約8.7時間のダウンタイムを意味します。一方、99.99%（フォーナイン）で許容されるのは52.6分 בלבדです。99.999%（ファイブナイン）では、わずか5.26分しか許容されません。通常、9が1つ増えるごとに、より多くの冗長化、自動化、コストが必要になります。SAA-C03試験では、指定された可用性目標を満たすアーキテクチャを特定する問題がよく出題されます。

高可用性アーキテクチャでは、障害を自動的に検出し、数秒から数分以内に正常な代替コンポーネントへ切り替えることで、1つのコンポーネントの障害に耐えます。例として、RDS Multi-AZ（別のAZにあるスタンバイへの自動フェイルオーバー）、終了したインスタンスを置き換えるAuto Scaling Groups、異常なターゲットを避けてルーティングするElastic Load Balancersがあります。短時間の中断は発生しますが、手動操作なしでシステムは復旧します。

フォールトトレラントアーキテクチャにはアクティブ冗長化があります。複数の同一コンポーネントが同時にリクエストを処理するため、1つが故障しても他のコンポーネントが即座に負荷を吸収し、ダウンタイムがゼロになります。例として、複数のEC2インスタンスを使用するアクティブ-アクティブELB、複数リージョンで同時に読み取りと書き込みを処理するDynamoDB Global Tables、複数のリードレプリカを備えたAuroraがあります。フォールトトレランスには、常時稼働させる追加リソースが必要です。

フォールトトレランスは、常時プロビジョニングされた冗長キャパシティを必要とするため、高可用性よりも大幅に高コストです。高可用性のRDS Multi-AZインスタンスでは、障害発生時にのみ稼働するスタンバイのために、データベースコストが2倍になります。フォールトトレラントなマルチリージョンのアクティブ-アクティブAurora構成では、コストが4倍になる可能性がありますが、リージョン障害中のダウンタイムを完全になくせます。アーキテクトは、冗長化のコストとダウンタイムによるビジネス上の損失のバランスを取る必要があります。

目標復旧時間（RTO）とは、システムが利用できない状態で許容される最大時間です。高可用性アーキテクチャでは、自動フェイルオーバーによって、通常は数分という短いRTOを目標にします。フォールトトレラントアーキテクチャでは、ほぼゼロのRTOを目標にします。HAを設計する際は、設定したRTOの範囲内で復旧できるサービスと構成を選ぶ必要があります。たとえば、RDS Multi-AZはおよそ60～120秒のRTOを提供し、多くのHA要件に適しています。

単一障害点（SPOF）とは、そのコンポーネントが故障するとシステム全体が停止するようなコンポーネントです。一般的なSPOFには、ASGのない単一のEC2インスタンス、単一AZのRDSデータベース、単一のNAT gateway、単一のアベイラビリティゾーンなどがあります。SPOFの排除は、HAとFTの両方に向けた第一歩です。SAA-C03試験では、提示されたアーキテクチャ図からSPOFを特定して排除する能力が頻繁に問われます。

ステートレスサービス（WebサーバーやLambda関数など）では、どのインスタンスでも任意のリクエストを処理できるため、HAやFTを実現するのがはるかに簡単です。ステートフルサービス（データベース、キャッシュ、ファイルシステムなど）はより難しく、レプリカ間で状態を同期し、レプリケーション遅延に対処し、フェイルオーバー時の一貫性を確保する必要があります。EFS（共有ファイルシステム）、レプリケーショングループを備えたElastiCache、Aurora（共有ストレージ）などのAWSサービスは、ステートフルなHAを容易にするよう設計されています。

AWSで一般的なHAパターンには、次のものがあります。1) Multi-AZロードバランシング — EC2インスタンスを複数のAZに分散し、ALBの背後に配置します。2) リードレプリカ — 読み取りトラフィックをオフロードし、DR時に昇格させます。3) ステートレスなアセットにS3を使用 — S3は11ナインの耐久性を備え、本質的にHAです。4) Global Accelerator — 静的なAnycast IPを使用し、リージョンをまたいで正常なエンドポイントにルーティングします。それぞれのパターンは、特定の可用性レベルとコストのトレードオフになります。

フォールトトレラントパターンでは、あらゆる場所でアクティブ冗長化を行います。主なFTパターンは次のとおりです。DynamoDBは本質的にフォールトトレラントであり、フェイルオーバーなしでデータを3つのAZにレプリケートします。S3には組み込みのFTがあります。Aurora Multi-Master（現在のAurora Serverless v2 multi-writer）では、複数のAZに同時に書き込めます。Kinesisはデフォルトで複数のAZにデータを保存します。FTを組み込んだマネージドサービスを選ぶことが、ダウンタイムゼロのアーキテクチャを実現する最も費用対効果の高い方法です。

HAまたはFTの設計は、テストの質によって決まります。AWSでは、AWS Fault Injection Simulator（FIS）を使用して、インスタンスの終了、APIのスロットリング、ネットワーク障害の注入など、制御された実験を行うことを推奨しています。フェイルオーバーが実際にRTO以内に完了すること、RPOを超えてデータが失われないこと、アラームが正しく発火することを検証する必要があります。定期的なゲームデーやカオスエンジニアリングの演習によって、本番インシデントが発生する前に、レジリエンスに関する前提の抜け漏れを明らかにできます。

このレッスンで学んだAWS Solutions Architect（SAA-C03）の概念を確認しましょう。

このレッスンでは、高可用性は自動復旧によってダウンタイムを最小化する（RTOは数分）こと、フォールトトレランスはアクティブ冗長化によってダウンタイムをなくす（RTOはゼロ）こと、そしてレジリエンスのレベルが上がるごとにコストが大幅に増加することを学びました。単一障害点の排除は、どちらのアプローチにおいても基盤となります。次は、ステートフルサービスのマルチAZパターンについて学びます。