概要
- AWS Innovate onlineConference内の
AWS認定試験-試験対策「ソリューションアーキテクト・アソシエイト」のメモあくまでメモなので興味のある方は実際に視聴するのをお勧めします。
回復性の高いアーキテクチャを設計する
- 全体で34%出題
- 信頼性と回復性に優れたストレージを選択する
- AWSのサービスを使用した疎結合かメカニズムの設計方法を決定する
- 多層アーキテクチャソリューションの設計方法を決定する
- レイヤー間の疎結合
- 可用性や耐障害性に優れたソリューションの設計方法を設計する
信頼性と回復性に優れたストレージを選択する
-
EC2インスタンスストア
- EC2のインスタンスに付属するボリューム 再起動で消える
- エフェメラルボリュームは再起動できえるが高速
- EC2の料金に含まれる
-
EBS
- EC2で使用するブロックレベルのストレージボリューム
- 可用性、信頼性にすぐれたボリューム
- 永続性を持っている
- 利用したときだけEC2とは別途請求を受ける
- ランダムな読み込み、書き込み、高スループット読み込み、書き込み両方に適している
- ボリュームタイプの特徴とユースケースは理解する必要あり数値は不要
- S3,Glacierはブロックストレージではない
-
EFS
- EC2インスタンスで使用するファイルストレージの設定、スケーリングを簡単に行える
- 最低料金は不要使用した分だけかかる
-
S3
- インターネットからアクセスできるオブジェクトストレージ
- WEBベースのコンピューティングをできるようにしている
- 複数のAZに配置されるため高耐久性
- アクセスコントロールが設定か
- データの暗号化も可能
- バージョニング
- マルチパートアップロードもできる
-
Glacier
- 低コストでデータを保持できる
- アーカイブ用のストレージ
- データの取り出しに時間がかかる
AWSのサービスを使用した疎結合かメカニズムの設計方法を決定する
- 疎結合
- どこかで問題があってもほかに影響しないようにする
- メール送信なら送信前にキューにためる
- ログ記録ならログ送信前にキューにためる
- コンポーネント間で影響が出ないようにする
- どこかで問題があってもほかに影響しないようにする
- SQS,ELBが使える
多層アーキテクチャソリューションの設計方法を決定する
- いつ壊れてもおかしくないという考えで運用する
- 耐障害性(フォールトトレランス)
- アプリケーション内のコンポーネントが疎結合になっている
- SLAを満たすには4つのEC2インスタンスが必要
-
高可用性とk￥耐障害性の考え方の違い
前提 SLAを満たすには4つのEC2インスタンスが必要
AZが一つ落ちてしまう状態を考えてみる- 高可用性 *AZ2つに合計して４つインスタンスを立てる * 片方のAZが落ちたとき２つだけになってしまうので復旧までSLAは満たせない * オートスケールを設定してつねに４台動くようにすれば 起動まではSLAは満たせない
- 耐障害性
- AZ2つにそれぞれ４つ
- 片方のAZがおちてもSLAは満たせるがコストは高くなる
-
システムの自動構成CloudFormation
- テンプレートにリソースを指定
-
Lambda
- サーバレスのアーキテクチャを実現できる
原則
- 単一のAZは正確ではない
- AWSManagedServicesの使用を常に優先する
- 耐障害性(フォールトトレランス性)と高可用性はおなじではない
- あらゆるものは故障する前提
パフォーマンスに優れたアーキテクチャを定義する
高パフォーマンスなストレージおよびデータベースを選択する
- EBSのボリュームタイプ
- SSDがおすすめ
- プロビジョンドIOPSはコストが高いがパフォーマンスが高い
- 汎用は安いがパフォーマンスは並
- SSDがおすすめ
- S3
- 静的コンテンツの提供もできるコンテンツ配信でのパフォーマンスを気にしないで済む
- バケットはグローバルに１意にする必要がある
- データサイズ、リージョン外へのデータ送信、リクエスト数で料金が決まる
- S3へのデータ受信、同じリージョン内のやり取り、CloudFrontへのデータ送信は無料
-
RDS
- 万能なデータベースは存在しない要件に応じて使用
- 複雑なトランザクションやクエリ
- RDSリードレプリカ
- 伸縮自在にスケールアウトできる
- リードレプリカをサポートしているのは MySQL,MariaDB,PostgreSQL,Aurora
-
DynamoDB
- スループット性能の要件に応じたリソース割り当てができる
パフォーマンス向上のためキャッシュを使用する
- CloudFront
- 低レイテンシー
- キャッシュされていなければ取得、キャッシュされいればキャッシュから返すことで早くすることができる
- ElasticCache
- Memcached
- マルチスレッド
- メンテナンスが簡単
- 徐堂検出機能で水平スケーリングが簡単
- 永続化ではない
- Redis
- 複数のデータ構造をサポート
- 永続性 (シリアル化されたjsonなども保持できる)
- アトミックオペレーション
- Memcached
伸縮性とスケーラビリティに優れたソリューションを設計する
- 垂直スケーリングと水平スケーリング
- 垂直スケーリング
- スケールアップ/スケールダウン
- インスタンスのスペックの変更
- Javaで動いているアプリのメモリを増やす場合など
- サーバの再起動を求められる可能性も
- 水平スケーリング
- スケールイン/スケールアウト
- インスタンスの数の変更
- 垂直スケーリング
- Auto Scaling
- アプリの使用状況に応じてインスタンスの作成、終了ができる
- 複数のアベイラビリティゾーンでインスタンスの作成をできる
原則
- データが構造化されていない場合S3が一般的なストレージソリューション
- キャッシュ戦略を使用してパフォーマンスを向上させる
- AutoScalingを使用する場合と理由を確認する
- ワークロードとパフォーマンスのニーズに最適なインスタンスタイプとデータベースタイプを選択する