参考文献
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上のデータ要件に応じてストレージクラスを使い分けることでコスト最適化
- データの暗号化が可能
- SSE-S3
- SSE-KMS
- SSE-C
- サーバサイドで暗号化が可能
- 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マネージド型サービスの使用を常に優先する
- 耐障害性と高可用性は同じではない