耐障害性を考慮したアーキテクチャ on AWSを考える

はじめに

この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧はこちら。

この記事では耐障害性を考慮したアーキテクチャ超詳細解説しています。

具体的には以下流れで説明します。

• AWSにおけるマルチAZアーキテクチャ
• AWSにおけるマルチリージョンアーキテクチャ
• AWSにおけるBlue/Greenアーキテクチャ

AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。

この記事を読んでほしい人

• 耐障害性を考慮したアーキテクチャのベストプラクティスを説明できるようになりたい人
• AWS Certified DevOps Engineer Professionalを目指している人

AWSにおけるマルチAZアーキテクチャ

AWSにおけるマルチAZアーキテクチャは、可用性を重視するアプリケーションやサービスにとって重要な要素であり、慎重な計画と設計が求められます。

マルチAZアーキテクチャの概要

AWSにおけるマルチAZ（Availability Zone）アーキテクチャは、耐障害性を高めるために複数の物理的に分離されたデータセンターゾーンにアプリケーションを展開する設計手法です。
これにより、単一の障害点に対する影響を軽減し、高い可用性を確保します。

マルチAZに展開すると一般的にはシングルAZと比較してコストが約2倍になるため、非機能要件とコストを天秤にかけながらアーキテクチャを検討するとよいでしょう。

ちなみに実プロジェクトでは開発面をシングルAZ、試験面と商用面をマルチAZとすることが多いです。

特徴と利点

1. 冗長性の向上
   マルチAZアーキテクチャでは、同一のリージョン内に複数のAZが存在します。
   アプリケーションが異なるAZに展開されることで、一部の障害に対して冗長性が向上します。

2. 自動フェイルオーバー
   マルチAZを利用するサービス（例: Amazon RDS）では、自動フェイルオーバーがサポートされています。
   一部のAZで問題が発生した場合、システムは自動的に別のAZにトラフィックを切り替え、アプリケーションの可用性を維持します。

3. データの冗長性
   マルチAZ構成では、データは複数のAZにレプリケーションされます。
   これにより、データの損失を最小限に抑えながら高い信頼性を実現します。

4. 高いSLA（Service Level Agreement）
   多くのAWSサービスはマルチAZ構成での利用を奨励し、それに基づいたSLAを提供しています。
   これにより、顧客は高い可用性に期待できます。

利用例

Amazon RDSのマルチAZ構成

Amazon RDSでは、マルチAZ構成が主にリレーショナルデータベースの冗長性と可用性を向上させるために利用されます。以下はその一例です。

1. プライマリDBとセカンダリDB
   マスター（プライマリ）DBとリードレプリカ（セカンダリ）DBが異なるAZに配置され、同期的にデータがレプリケーションされます。

2. 自動フェイルオーバー
   プライマリDBに障害が発生した場合、Amazon RDSは自動的にリードレプリカをプライマリに昇格させ、アプリケーションへの影響を最小限に抑えます。

3. データの安全性
   データはマルチAZで冗長に保存され、耐障害性が向上。また、リードレプリカを使用して読み取り負荷を分散することが可能。

ベストプラクティス

1. マルチAZを活用するサービスの選択
   マルチAZ構成がサポートされているAWSサービスを選択し、耐障害性を高める。

2. SLAの確認
   サービスごとのSLAを確認し、マルチAZ構成がSLA向上にどれだけ寄与するかを理解する。

3. 自動フェイルオーバーのテスト
   定期的に自動フェイルオーバーを含む耐障害性のテストを行い、システムの動作を確認する。

4. リージョン間での冗長性検討
   マルチAZだけでなく、必要に応じて複数のリージョンに展開することで、より高い冗長性を確保する。

AWSにおけるマルチAZアーキテクチャは、可用性を重視するアプリケーションやサービスにとって重要な要素であり、慎重な計画と設計が求められます。

AWSにおけるマルチリージョンアーキテクチャの詳細解説

マルチリージョンアーキテクチャは、地域間の冗長性と高可用性を求めるグローバルなアプリケーションやサービスにとって不可欠な設計手法です。
適切な設計と運用により、AWSが提供するサービスの柔軟性と信頼性を最大限に引き出すことが可能です。

マルチリージョンアーキテクチャの概要

AWSにおけるマルチリージョンアーキテクチャは、アプリケーションやサービスを複数のAWSリージョン（地理的に離れた場所）に展開する設計手法です。
このアーキテクチャは、単一のリージョンに依存せず、地理的な冗長性と高い可用性を実現します。

ディザスタリカバリを考えるとマルチリージョンアーキテクチャとすることが必須ですが、実プロジェクトでの採用はあまり多くありません。

一番大きな理由はコストです。
マルチリージョンアーキテクチャで増えるコストはマルチAZアーキテクチャ同様、リソースが2セット必要になることだけが原因ではありません。
マルチリージョンにするとリージョン間通信のコストがさらに上乗せになるため、常時マルチリージョンで展開しているプロジェクトは少ない印象です。

もちろん、ディザスタリカバリの中でRTO、RPOともに高い水準を求められるときにはマルチリージョンを選択します。
例えばSAP on AWSではマルチリージョンとすることが多いです。

特徴と利点

1. 地理的冗長性
   マルチリージョンアーキテクチャでは、異なる地理的な位置にリソースを展開することで、天災や地域的な障害に対する冗長性を確保します。

2. 可用性の向上
   複数のリージョンに展開することで、ユーザーへのサービス提供が継続され、一部のリージョンでの障害が他のリージョンに影響を及ぼすことを回避します。

3. 低レイテンシー
   ユーザーに近いリージョンにリソースを配置することで、低レイテンシーの提供が可能。
   これは特にグローバルなアプリケーションにおいて重要です。
   ただし、リージョン間通信はレイテンシーが大きくなるので注意が必要です。

4. データのレプリケーション
   マルチリージョン構成では、データのレプリケーションが必須となります。
   AWSが提供するレプリケーション機能を活用してデータの同期を実現します。

利用例

グローバルなウェブアプリケーションのマルチリージョン展開

1. 静的コンテンツの配信
   Amazon S3を利用して静的なコンテンツを複数のリージョンに配置し、Amazon CloudFrontを使用して低レイテンシーでの配信を実現します。

2. データベースのレプリケーション
   マルチリージョンに広がるデータベース（例: Amazon Aurora）でデータを同期し、ユーザーがどのリージョンからでも一貫性のあるデータを利用可能にします。

3. グローバルなトラフィックの分散
   Amazon Route 53のグローバルロードバランサーを使用して、ユーザーからのトラフィックを最適なリージョンに分散し、負荷を均等に配分します。

ベストプラクティス

1. アプリケーションのデザイン
   マルチリージョン展開を考慮したアプリケーションのデザインが必要です。
   例えばデータの同期や処理の一貫性を確保するための設計が重要です。

2. データの暗号化とセキュリティ
   マルチリージョンでデータを移動する場合は、データの暗号化とセキュリティの確保が必要です。
   暗号化には一般的にAWS Key Management Service（KMS）を活用します。

3. 冗長性の設計
   マルチリージョンアーキテクチャでは、各リージョンに冗長な構成を構築し、サービスの可用性を向上させることが大切です。

4. 地域間の通信コストの最適化
   AWS Direct ConnectやAmazon CloudFrontを使用して、地域間の通信コストを最適化する必要があります。

AWSにおけるBlue/Greenアーキテクチャの詳細解説

Blue/Greenアーキテクチャは、アプリケーションの変更やアップデートを迅速かつリスクを最小限に抑えて行うための効果的な手法です。
特にクリティカルなプロダクション環境において、高い可用性と安全性を確保するために利用されます。

Blue/Greenアーキテクチャの概要

Blue/Greenアーキテクチャは、アプリケーションの新バージョン（Green）を既存のバージョン（Blue）とは異なる環境にデプロイし、切り替えることで、アプリケーションのアップデートやデプロイメントを効果的かつ安全に行う手法です。
これにより、ダウンタイムの最小化や問題が発生した場合の簡単なロールバックが可能となります。

ElasticBeanstalkやCodeDeployを利用しなくてもRoute53やAPI Gateway、ALBを用いたトラフィックの切り替えで実現できます。

特徴と利点

1. ゼロダウンタイムデプロイメント
   Blue/Greenアーキテクチャでは、新しいバージョンのアプリケーションが別の環境にデプロイされているため、切り替え時にダウンタイムが発生しません。

2. 簡単なロールバック
   デプロイ後に問題が発生した場合、切り替えを元に戻すことが容易であり、アプリケーションの安定性を確保します。

3. テストの容易性
   新しい環境にデプロイされたGreen環境で本格的なテストが可能です。
   問題が発生した場合ロールバックをすればBlue環境での運用が続けられます。

4. スケーリングとリソースの最適化
   新旧の環境を切り替えることで、必要なリソースを最適化し、スケーリングを行うことができます。

Blue/Greenアーキテクチャの手順

1. Blue環境の運用
   既存のアプリケーション（Blue）が運用中であることを確認し、ユーザートラフィックを処理しているのがBlue環境です。

2. Green環境へのデプロイ
   新しいアプリケーションバージョン（Green）を別の環境にデプロイします。
   これにより、新旧の環境が平行して存在する状態になります。

3. テストと検証
   Green環境でのテストや検証を実施します。
   問題がないことを確認し、新しいバージョンが適切に動作することを保証します。

4. トラフィックの切り替え
   ルーティングやロードバランサーなどを利用して、トラフィックをBlue環境からGreen環境に切り替えます。
   これにより、新しいバージョンが本番環境で受け入れられます。

5. モニタリングとロールバック
   トラフィックがGreen環境に切り替わった後もモニタリングを行い、問題が発生した場合はすぐにBlue環境にロールバックします。

利用例

AWS Elastic BeanstalkでのBlue/Greenデプロイメント

1. 環境のクローン
   既存の環境をクローンし、新しいバージョンのアプリケーションを新しい環境にデプロイします。

2. 新環境でのテスト
   新しい環境でテストを実施し、問題がなければトラフィックを新環境に切り替えに進みます。

3. トラフィックの切り替え
   AWS Elastic BeanstalkコンソールやAWS CLIを使用してトラフィックを新しい環境に切り替えます。

4. モニタリングとロールバック
   AWS CloudWatchなどで新環境のパフォーマンスをモニタリングし、問題が発生した場合は迅速にロールバックします。

ベストプラクティス

1. 自動化されたデプロイメント
   デプロイプロセスを自動化し、繰り返しデプロイが容易に行えるようにします。

2. インフラストラクチャのコード化
   インフラストラクチャをコードとして扱い、Blue/Green切り替え時にも一貫性を保つことが大切です。

3. ステージング環境の整備
   Blue/Greenアーキテクチャを実施する前に、ステージング環境で十分なテストを行いましょう。

4. トラフィックのモニタリング
   トラフィックの切り替え後もモニタリングを継続し、問題の早期発見と対応を行う必要があります。

まとめ

この記事では耐障害性を考慮したアーキテクチャ超詳細解説しました。

• AWSにおけるマルチAZアーキテクチャ
• AWSにおけるマルチリージョンアーキテクチャ
• AWSにおけるBlue/Greenアーキテクチャ

次回はAWSにおけるディザスタリカバリを考えます。