参考文献

AWS Innovate Online Conference
AWS 認定 - 試験対策「ソリューションアーキテクト - アソシエイト」
セッション1：回復性の高いアーキテクチャを設計する

を視聴して、まとめた内容を記載しています。

1.1 信頼性と回復性に優れたストレージを選択する

EC2インスタンスストア

エフェメラルボリューム
特定のEC2インスタンスのみ
キャパシティ固定
ディスクタイプとキャパシティはEC2インスタンスタイプによって異なる
アプリケーションレベルの耐久性
無料で利用できる
一時的なストレージ
キャッシュや一時コンテンツなど、頻繁に更新される情報のストレージ

EBS

EC2で使用するためのボリュームタイプ
暗号化
スナップショット
プロビジョンドキャパシティー
EC2インスタンスに依存しないライフサイクル（永続的なストレージ）
EC2の料金とは別に、料金が発生する
データにすばやくアクセスする場合や継続性が必要な場合に推奨
ランダムや読み取り書き込みを行う
ユースケースに応じた4つのボリュームタイプから選択（特徴とユースケースを理解すべし）

EFS

AWSクラウド上のファイルストレージ
複数のEC2から同時にアクセスできる共有ストレージ
ギガバイトからペタバイトまで自動的にスケール
高い耐久性と可用性を考慮
NFS v4.0およびNFS v4.1プロトコルをサポート

Amazon S3

インターネット経由で利用可能なオブジェクトストレージ
信頼性が高く高速で安価なデータストレージ
容量は事実上無制限
99.999999999％の高い耐久性(9が11個)
リージョン内で複数の施設にまたがる複数のデバイスにデータを冗長的に格納→高い耐久性
S3上のデータ要件に応じてストレージクラスを使い分けることでコスト最適化
データの暗号化が可能
サーバサイドで暗号化が可能
- HTTPS
バージョニング
マルチパートアップロード機能（大規模データを分割してアップロード）

Amazon Glacier

データのバックアップおよびアーカイブ用のストレージ
低コスト
S3と似ているが、こちらはアーカイブ用のストレージ
データを取り出すことにコストと時間がかかる
データサイズに対するコストがS3より安い
データを取り出すことに時間がかかるが、3つの取り出しオプションがある
- 迅速
- 標準
- 大容量
暗号化
S3のライフサイクルポリシー
リージョン内の可用性
99.999999999％の高い耐久性(S3と一緒)

1.2 AWSのサービスを使用した疎結合化メカニズムの設計方法を決定する

1.3 多層アーキテクチャソリューションの設計方法を決定する

疎結合化のメリット
- 可用性を向上
- スケーラビリティ

Webサーバからメールを送信する場合

密結合の場合
- Eメールサーバが利用できなくなりメール送信が失敗
- Webサーバの処理に影響
疎結合の場合
- Webサーバからのメッセージをキューで受け止める
- 非同期でメール送信する仕組み
- Webサーバの処理に影響せず、システム全体で可用性を向上

Webサーバからdynamo DBにログを格納する場合

密結合の場合
- ログ記録サービスが過負荷な状態でスローダウン
- Webサーバの処理が遅延
疎結合の場合
- Webサーバからのログ送信は一旦キューに格納
- イベントログ記録サービスが非同期でdynamo DBに格納
- ログ記録サービスの負荷が足りなかったら、そのコンポーネントを増やすことでWebサーバに影響なくシステムをスケールさせることができる

クラウドは、オンプレミスと異なり、必要なインスタンスを短時間で起動してシステムを組めることがメリット

密結合の場合
- サーバを増やしてシステム処理をスケールした場合、結合相手に影響が出る
- 柔軟なスケーラビリティを確保できない
- 障害で停止したり、過負荷により反応が遅いと他コンポーネントに影響が出る
疎結合の場合
- 性能不足になった自身のコンポーネントを増強することが容易。
- システム全体のスケーラビリティを向上
- コンポーネント同士のやり取りを非同期で行い、他のコンポーネントをブラックボックスとみなすことができる

疎結合に利用されるサービス

SQS
ELB
ELP
Route 53

1.4 可用性や耐障害性に優れたソリューションの設計方法を決定する

高可用性の観点では、いつ故障してもおかしくないという前提でシステムを設計／構築することが重要

高可用性とは

システムを構成するコンポーネントが故障しても、長時間停止することなく、自動的にすばやく復旧すること。

各コンポーネントをグループ化する
- 単一障害点を避ける

実現方法

複数のAZとリージョンを使用する。
オートスケーリングを使用する。
可用性の高いマネージド型サービスを利用する。

耐障害性とは

アプリケーション内のコンポーネントが備える冗長性。
アーキテクチャ内のいずれかのコンポーネントが完全に機能を失っても、アプリケーションはパフォーマンスを低下させることなく機能し続けること。
フォールトトレランスと呼ぶ場合もある。

コンポーネント同士を疎結合にすることで、高可用性に不可欠な対象外も向上する。

疎結合のシステムでは、1つのコンポーネントの障害はレイヤー内に完結して管理。
- ほかのインスタンスに飛び越えて障害が拡散することはない。

可用性の例

前提：SLAを満たすには4つのEC2インスタンスが必要。AZで障害あった場合を考える

2つのAZに2つずつEC2インスタンスを起動
AZ-aに障害が起きた場合、残るのはAZ-bに2つのインスタンスのみ
残ったAZ-bに、新しい2つのEC2インスタンスが起動してくるまではSLAが満たせない。（オートスケーリングで起動）
コスト的には、通常運用時は4インスタンス分のコストのみ

耐障害性の例

前提：SLAを満たすには4つのEC2インスタンスが必要。AZで障害あった場合を考える

2つのAZに4つずつEC2インスタンスを起動
AZ-aに障害が起きた場合でも、AZ-bに4つのインスタンスがある
SLAは満たし続けることができる
コストが通常運用でも8インスタンス分のコストが発生する

耐障害性の構成をとると、コストが高くなる傾向がある。

CloudFormation

システムの復旧には、必要なリソースを1から構成する必要があるが、手動だと時間がかかる。
そのため、自動構成する仕組みが重要。
CloudFormationは、必要なリソースをテンプレートとして定義し、実行させることで必要なリソースが自動構成される。
1つのテンプレートから作成されたリソースは、スタックによって一元管理される。
リソースへの更新が必要な場合は、テンプレートを変更する。

Lambda

回復性の高いアーキテクチャを構築／運用しやすくなる。
サーバレスアーキテクチャを実現できる。
コードを用意して、Lambda関数として登録すれば、AWSで管理している実行基盤で自動的に実行される。
実行タイミングは、様々なAWS上のイベントで紐付けることが可能。

メリット
- 運用上の様々な操作を自動化できる。
- 障害などのシステム上のイベントを契機にして、自動化するような処理を実装しておけば、Lambdaが自動実行される。
- 運用者が可用性やスケーラビリティを管理する必要がない（マネージド型サービスで、コードの実行環境はAWSが全て管理しているため。）

まとめ

「単一のAZ」が正解ではないという前提で考える
AWSマネージド型サービスの使用を常に優先する
耐障害性と高可用性は同じではない