【aws】アーキテクト⑥レジリエンシー

今回はawsのレジリエンシーについてみていきます。教材はこれまで同様、「ガバメントクラウド利用における推奨構成（AWS編）.pdf」です。

レジリエンシー構成
1. 事業継続性(BCP:Business Continuity Plan)
参考資料

レジリエンシー構成

アーキテクチャは以下の通りです。基本的にはBCPの観点に焦点を当てたアーキテクトのようです。

引用元：ガバメントクラウド利用における推奨構成（AWS編）.pdf（デジタル庁）P.31

図に記載しているコンポーネントは、これまでの記事で紹介してきたため、差分のみ記載します。

アイコン	名称	機能
	Route-53	DNSサーバー。登録したサーバーのヘルスチェックも実行する
	Elastic-Load-Balancing	ロードバランサ。自動スケーリングに対応したアクセス分散のほか、故障サーバーの自動切り離しやSSL終端装置として機能したりします
	Auto-Scaling-group	アプリケーションへの負荷に応じて、内部のEC2インスタンスの数を自動増減させる単位。Route53、Elastic Load Balancingと組み合わせて利用する
	Aurora	aws独自のRDS。レプリケーション機能などが標準で付属する
	Backup	バックアップサービス。AMI(EC2のマシンイメージ)や、データのSnapshotのバックアップをスケジュール実行する。内部的なバックアップ先はバックアップボールトと呼ばれるS3となるが、通常のS3画面からは確認できない
	CloudWatch_Synthetics	アプリケーションの動的検査機能。URL/APIをたたくだけでなく、見えないブラウザを起動して検査するため、画面のスクリーンショットを保存したりすることも可能

事業継続性(BCP:Business Continuity Plan)

BCPについては、各コンポーネントを冗長化することで対応しているようです。

まずリージョンについては、データの国内保持の観点からTokyoとOsakaを選ぶことになると思います。ただし、ガバメントクラウドでは、Tokyoをメインとする場合にOsakaはホットスタンバイ/コールドスタンバイすることなく、バックアップデータを保管するリージョンとして利用するようです。東京被災時に大阪側にすぐに切り替わるみたいなことは想定していなさそうで、数日のうちに復旧できる体制を整えるというサービスレベルみたいです。

AZ(アベイラビリティゾーン)による耐障害性はよくある構成と思います。

Elastic Load Balancing（ロードバランサ）で、アクセスを各AZに分散させる
AZは推奨３つ立ち上げ、webサーバー/アプリケーションサーバーを冗長化させる
RDSの冗長化についてはレプリケーションを利用する

RDSの冗長化について詳細な記載はありませんが、リードレプリカ機能を利用していそうです。リードレプリカ機能では、１つの書き込み可能なマスタと、複数の読み取り専用のレプリカのいずれかが各AZに存在し、すべてのRDSが活性の状態で稼働します（対して、マルチAZ構成の場合は、１つのAZのRDSだけが活性で、障害発生時に他のAZのRDSが稼働することになる点が異なる）。Amazon Auroraにおいては書き込み可能転送を利用することで、Updateコマンドをシームレスに書き込み可能なマスタに転送する形を想定していそうです。Amazon Aurora以外の場合は、アプリケーション側で書き込みと読み込みを分けてアクセスする形になります。

参考資料

ページ中で利用しているAWSアイコンは、以下のページからダウンロードしたものを利用しています。

AWS アーキテクチャアイコン