ミッションクリティカルシステム on AWSの可用性を更に高める方法

はじめに

金融機関をはじめ様々な業界においてアマゾン ウェブ サービス（AWS）の利活用が進んできていますが、昨今ではよりビジネス上の重要度や可用性要件が高いシステムのAWS移行も進んできています。
そんな中、クラウド移行が減速してしまう理由のひとつに「クラウドの障害で止まったとは言えないような基幹系システムをAWSに本当に移行してよいのか」企業の経営層などから疑問の声があがるケースがあります。ビジネス上重要度の高いシステムで障害が発生したり、動作が中断・停止されたりすると、業務に大きな支障をきたす恐れがあるため、当然のことです。

今までシステムの可用性要件やRTO、RPO目標に従いマルチアベイラビリティゾーン（AZ）、マルチリージョンなど対策をしてきましたが、更に可用性やレジリエンス（復元力）を高めるのにはどうしたらよいのか。本記事では、筆者が取り組んできた経験をもとに可用性を更に高める方法をご紹介していきます。

結論

先に結論を述べておきますが、以下の点と考えています。

• 可用性を更に高めるための課題は2点、AWSグローバルサービス障害とAWS DirectConnect障害に対する対策
• AWSが提供する障害分離境界を生かした構成・設計としワークロードを障害から保護する
• 静的安定性の考え方を取り入れ、障害に依存した可用性設計としない
• インフラだけで可用性向上を考えるのは限界があり、アプリケーションと連携して対策する（今後の課題）

可用性を更に高める上での必要な対策

マルチAZ、マルチリージョンに加え、更に可用性を高めるためにはどのような対策が必要なのか、次のアプローチを取ります。

1. システムで利用しているAWSサービスのサービスタイプを確認し主にマルチAZ、マルチリージョンの対策では障害影響が発生してしまうもの、つまり複数リージョン同時障害が発生するものがないのか。
2. 過去発生したAWSの障害の中から主にマルチAZ、マルチリージョンの対策で障害影響が発生してしまうものがないのか、比較的大規模な障害の一覧が参照できるAWS Post-Event Summariesと独自にWeb検索で調べた著名な障害から調査する。

※参考：AWS Post-Event Summaries  https://aws.amazon.com/jp/premiumsupport/technology/pes/

1.AWSサービスタイプから調査する： AWSグローバルサービス障害

AWSのサービスタイプは、Zonal services、Regional services、Global servicesに分類されます。Amazon EC2などデプロイするAZを指定するサービスがZonal servicesで、Amazon DynamoDBのようなAZをグループ化し、単一のリージョンのエンドポイントを提供するようなサービスがRegional servicesです。
また、Amazon Route53やAWS IAMなどリージョンで独立しておらず、一部の機能がリージョン共通で構成されているようなサービスがGlobal servicesです。当然このグローバルサービスで障害が発生した場合、複数リージョンで同時に稼働中のシステムに影響が出ると考えられます。更なる可用性を高めていくには、グローバルサービス障害への対策を予め実施していく必要があります。

2.過去発生した障害から調査する： AWS DirectConnect障害

2017年以降の過去5年間の障害事例を調査しましたが、上述の「1.AWSサービスタイプから調査する」と同様にグローバルサービス関連の障害のみ対策が必要と考えます。（インターネット障害など外部要因による事例はオンプレミスシステムも同様のため省きます）
但し、過去障害を調査して唯一追加で対策が必要と思われるのが、2021年9月2日に東京リージョンで発生したAWS DirectConnect障害です。AWS上だけで稼働しているシステムは問題ないですが、AWS DirectConnect経由でオンプレミスのシステムと連携していた場合、AWS DirectConnect障害はオンプレミスとの通信ができずシステム全体の停止となってしまいます。

リージョン切替えで対処できますが、リージョン切替えは一般的に切替え時間も長くなるのと場合により複数システムを同時に切替えすることになります。影響の大きさを考えるとネットワークが正常に動いていることは重要なため可用性要件に応じてしっかりと点検や対策を行うべきと考えます。本記事では少しだけ対策について触れていきたいと思います。

AWSの障害分離境界と静的安定性

続いて、可用性の更なる向上を考える上で、以下2点が重要なため解説します。

1. AWSグローバルインフラストラクチャが提供する障害分離境界を理解する
2. 静的安定性（Static stability）

1.AWSグローバルインフラストラクチャが提供する障害分離境界を理解する

（１）アベイラビリティゾーン、リージョン
アベイラビリティゾーンは、AWSリージョン内の独立した冗長電源インフラストラクチャ、ネットワークなどを備えた1つ以上の個別のデータセンターです。リージョン内のアベイラビリティゾーンは、相互に関連する障害を防ぐために最大60マイル（約100km）離れていますが、1桁のミリ秒のレイテンシーで同期レプリケーションを使用するのに十分な距離にあるとのことです。これらは、洪水、地震などの災害などにも同時被災しないためマルチAZにすることで可用性も高められます。
AWSリージョンは、世界中に地理的に分離したデータセンター群で3つ以上のアベイラビリティゾーンで構成されています。リージョンは他のリージョンから分離、独立しており、サービス障害が発生した場合、単一のリージョンに制限されます。

（２）コントロールプレーンとデータプレーン
AWSでは、ほとんどのサービスをコントロールプレーンとデータプレーンの概念に分けています。コントロールプレーンは、リソースの作成、読み取り/記述、更新、削除、一覧表示に使用される管理 API を提供します。データプレーンは、サービスの主要な機能を提供するもので、実行中のAmazon EC2自体やAmazon S3バケットへのオブジェクトの配置、DNSクエリの実行応答などワークロードで利用される機能を提供しています。
イメージとしてコントロールプレーンはリソース作成や管理を担い、通常は複雑で集約システムになる傾向があるようです。一方で、データプレーンは意図的に単純化されています。これにより、コントロールプレーンよりもデータプレーンで障害イベントが統計的に少ないこと、またそれらは別個のコンポーネントとして分離していることを理解するのは可用性観点では重要と考えます。

Amazon EC2などのZone servicesの場合、下記図の通り各AZでコントロールプレーンもデータプレーンも独立して配置されており、他のAZの障害にも依存しない構成となっています。尚、リージョンコントロールプレーンは、エンドポイントを提供しサービスとのやり取りを容易にするだけでなく、ゾーンコントロールプレーン上のアグリゲーションおよびルーティングレイヤーとしても機能します。

▼Zone servicesのデータプレーンとコントロールプレーン

※引用：AWS Fault Isolation Boundaries
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html

2.静的安定性（Static stability）

静的安定性とはAWSサービスの最も重要なレジリエンスの特徴の1つで、システムが静的な状態で動作し、依存関係の障害または利用不能の際に変更を加える必要なく、通常どおり動作し続けることです。つまりコントロールプレーンで障害が発生しても、データプレーンは既存の状態を維持し動作し続けます。リソースへのデータプレーンアクセスは、一度プロビジョニングされるとコントロールプレーンに依存しないため、コントロールプレーン障害の影響を受けません。つまり、リソースを作成、変更、または削除する機能が損なわれても、既存のリソースは引き続き使用できます。

マルチAZ構成の例

Amazon EC2インスタンスを起動は、コントロールプレーンでの処理となるため、AZ障害が発生した際に別のAZでインスタンスを起動することは、望ましくありません。それは障害に依存した設計となるため、復旧を実現するために必要な変更が最も少ないものが望ましいです。そのため、以下例のように追加の容量を事前にプロビジョニングしておくことで、静的安定性が実現できます。

例1：2つのAZにデプロイしたAmazon EC2インスタンスのAWS Auto Scaling構成（4つのインスタンスが必要な場合）

AWS Auto Scalingによる新しいインスタンスのデプロイはAmazon EC2コントロールプレーンに依存しており、単一のAZが失われたときに別のAZでデプロイすることは障害に依存した設計で静的安定性とは言えません。

例2：事前に十分な数の Amazon EC2インスタンスをプロビジョニングする構成（4つのインスタンスが必要な場合）

単一のAZが失われても静的に安定するには、AWS Auto Scalingに頼って新しいインスタンスをプロビジョニングするのではなく、障害のあるAZから移動した負荷を処理するために、他のAZに十分な数のAmazon EC2インスタンスを事前にプロビジョニングします。追加の費用が必要となるためコスト面とトレードオフですが静的安定性がある構成と言えます。

筆者の考えでは、もし更なる可用性を向上させる場合は静的安定性の考え方を取り入れて障害時の運用やオペレーションについて、変更や登録などコントロールプレーンへの操作がないこと、最も変更が少ない構成や運用になっているか見直すことが重要と考えます。

障害時の対策について

AWSグローバルサービス障害への対策

1.AWS IAMのコントロールプレーン、データプレーン

グローバルサービスの中でも認証機能を提供し非常に重要なAWS IAMサービスの例で解説します。
AWS IAMはグローバルサービスですが、コントロールプレーンとデータプレーンを分離して設計されており、コントロールプレーンは米国東部 (バージニア北部) リージョンに1つ設置されています。また、データプレーンは各リージョンに分散配置されています。ロールやポリシーなど、認可に使用されるAWS IAMリソースは、コントロールプレーンに保存されますが、AWS IAMのデータプレーンは、基本的にAWS IAMコントロールプレーンの設定データの読み取り専用レプリカで、予期しない障害が発生した場合でもデータプレーンでサービスは認証されます。

▼Global servicesのIAMデータプレーンとコントロールプレーン

2.AWS Security Token Service （AWS STS） のエンドポイント

認証認可のAWS STSリクエストはデフォルトで単一のグローバルエンドポイントに送信されますが、リージョナルAWS STSエンドポイントを使用して冗長性や可用性を高めることができます。AWS STSリージョン別サービスエンドポイントでは、少なくとも24時間、新しい一時的な認証情報を要求することができます。

東京と大阪リージョンのサービス別エンドポイントの例

3.可用性の更なる向上策

AWS IAMのサービスにおいてもコントロールプレーン、データプレーンの概念に分けられており、データプレーンはリージョナルで分散配置されて予期しない障害が発生した場合でもデータプレーンでサービスは認証されることが分かりました。そのため次の通り、インフラストラクチャの障害分離境界を認識し、静的安定性の考え方を取り入れ設計することで、更なる可用性向上が実現します。

• 静的安定性の考え方を取り込み、通常の業務処理および障害時の復旧処理などで、権限登録や更新などコントロールプレーンへのAPI発行をしないよう設計する。
• デフォルトのSPOFとなるグローバルエンドポイントではなく、AWS STSリージョン別サービスエンドポイントを使用するよう変更する。

また経験上、ワークロードで仕様しているほとんどのAPIではデータプレーンへのリクエストであり問題ないことが多いように思います。但し、AWS STSエンドポイントはグローバルエンドポイントになっていることが多いため確認します。併せて、サードパーティ製品でワークロードに影響あるような処理のAPIが静的安定性になっているか忘れずに確認しましょう。また、全てのAPIをインフラとアプリケーションが共同で確認し、テストフェーズにおいて静的安定性になっていることを確認することも重要です。

尚、AWS IAM同様にグローバルサービスで重要なサービスであるAmazon Route53も、コントロールプレーン、データプレーンに分かれており同様の考え方や対策が可能です。

※参考：Amazon Route53コントロールプレーンとデータプレーンの概念
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-control-and-data-plane
※参考：Global services in the edge network
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-fault-isolation-boundaries/global-services.html

AWS DirectConnect障害への対策

少しだけAWS DirectConnect障害の対策についても触れておきます。

2021年9月2日のAWS DirectConnect障害は、東京リージョンに向かうトラフィックについて断続的な接続の問題とパケットロスの増加が午前7時30分から午後1時42分まで発生していました。AWS Direct Connectの回復性に関する推奨事項に従い、次のような対策が有効と考えます。本記事では詳細は割愛しますが、別の記事で今後ご紹介したいと思います。

• AWS DirectConnectサービスのSLA99.99％要件を満たす2つのロケーションに各2つの接続
• 回復性を高めるためにバックアップとして、AWS Transit Gateway で終端する AWS Site to Site VPNを使用し、回線の冗長化も行う
• AWS Transit Gateway Cross Regionピアリングと AWS Direct Connect Gatewayを使ったマルチリージョンフェイルオーバーの実装
• 断続的な接続問題など不安定事象に対処するため、End to Endでの通信経路の監視

※参考：Direct Connect の回復性に関する推奨事項 https://aws.amazon.com/jp/directconnect/resiliency-recommendation/

今後の課題

可用性の要求レベルが向上してくると、マルチリージョンのDisaster RecoveryのRTO、RPOも厳しい要件になってくる場合があるかと思います。
筆者は現状以下課題と感じています。

• AWSにはリージョン障害というイベントがないため、リージョン切替えのトリガーや自動化がインフラだけでは難しい。(対応例：アプリケーションの稼働状況から切替え判断)
• Amazon Aurora Global Databaseはリージョン間では非同期のため、リージョン切替え後にグレーデータ^※1が発生する場合がある。(対応例：アプリケーションで切替え後のグレーデータ対応)

上記は一例でシステムの要件などにより対応は異なってきますが、インフラだけでは当然可用性の更なる向上を目指すのは難しいため、アプリケーションとより密接に連携して対策していく必要があります。場合によりAWSとオンプレミスのハイブリットクラウドを実装する場合もあるかもしれません。ビジネス継続性に貢献する信頼性の高いアプリケーションサービスを提供するためには、エラーや障害に耐え、データを失うことがないようにしなければなりません。また、重要なアプリケーションは、コンポーネントが故障した場合でも良好なパフォーマンスを維持する必要があります。インフラだけではレジリエンスに十分な能力を発揮できない場合もあるので、インフラとアプリケーションが相互に関連しながら設計していく必要があると考えます。

※1:グレーデータ：障害によりスタンバイリージョンへのレプリケーションが部分的に欠損し切替え後に論理的に不正となるデータ。

最後に

本記事では、AWSのグローバルインフラストラクチャが提供する障害分離境界と静的安定性についてご紹介し、マルチAZ、マルチリージョンに加え更に可用性を向上するための方法を解説しました。
全てのシステムでここまで対策が必要である訳ではありませんが、ビジネス上重要度の高いシステムや社会インフラと言えるようなシステムの移行が加速する中、よりAWSが提供するサービスや仕組みを理解して対応するケースが増えてくるかと考えています。AWSの柔軟で信頼性の高いスケーラブルなサービスが様々なビジネスに活用できるのに加え、更に重要度の高いシステムにおいても利用者側で可用性の目標に従って対応することで依存関係を意図的に選択でき、よりワークロードの可用性を向上できます。本記事が皆様の何かの一助になれば幸いです。

著：TIS株式会社
IT基盤技術事業本部 IT基盤技術事業部
IT基盤エンジニアリング第3部 エキスパート
宇井 真