セッション

概要

試験で全体の34%をしめるもっとも出題率が高い分野
4 つのベストプラクティスに基づいたポイントを紹介

EC2インスタンスストア
- 一時ストレージ
- EC2インスタンスタイプによっては無料
EBS
- 永続的ストレージ
- 同じAZ内のEC2にアタッチ可能
- EC2インスタンスと別料金(利用した量に応じて課金される)
- 4種類のボリュームタイプがある
EFS
- 複数のEC2から同時にアクセス可能
- データを自動でスケーリングすることが可能
- 耐久性/可用性に特化
S3
- オブジェクトストレージ
- EC2やWebから任意のデータを格納可能
- 柔軟なアクセスコントロール
- 暗号化可能(転送中はhttps)
Glacier
- S3に似ている
- アーカイブ用のストレージ
- データの取り出しに時間がかかる
- ストレージ料金的にはS3より安い

コンポーネントの状態の疎結合化(システムの可用性向上)
- Webサーバからのメール通知を一旦キューに溜める
- メールサーバに問題があってもWebサーバには影響がない
スケーラビリティの疎結合化
- Webサーバが使用するログ記録サービスを使用する
- ログ記録サービスが過負荷でスローダウン
  - Webサーバの処理が遅延する
- 疎結合の場合はログ記録サービスへのアクセスを一旦キューに格納する
  - ログ記録サービスが非同期にキューのアクセスを処理する
  - ログ記録サービスのコンポーネントを増やすだけで対処可能になる
- オンプレと異なりクラウドは必要なインスタンスの準備を容易に行うことができる
- 相互に密接に依存しない構成にすることでスケーラビリティな対応を容易に行える
- コンポーネント間を非同期で処理する
- 密結合だとコンポーネントの障害や負荷によって処理に影響が出る

高可用性
- あらゆるものはいつ故障してもおかしくない
- いずれかのコンポーネントが故障しても短時間で復旧できる様にする
- 複数AZ、複数リージョン、オートスケーリング、マネージドサービスを使用する
耐障害性/フォールトトレランス(コスト: 高)
- アプリケーション内のコンポーネントが持つ冗長性
- LBを挟むなどしてコンポーネント間を疎結合な構成にする
- コンポーネントが死んでもアプリケーションは問題なく機能し続ける
  - SLAを満たし続ける必要がある
CloudFormation
- システム全体が停止してしまった場合に復旧できるのか
- 必要なリソースの構成を準備する必要がある
- 1つのテンプレートから全体構成(スタック)を作ることができる
- テンプレートを直すことでスタックを直せる
Lambda
- サーバレスアーキテクチャ
- 様々なAWSサービスから呼び出せる(トリガー設定容易)
- 可用性やスケーラビリティを運用者は気にする必要がない
  - コードの実行環境はAWSが提供しているため