EBS
Q1. 古典的なバッチで利用するDBをマイグレーションしたい。450GBのEBSを選択して、rootボリュームとしても使うようにした。最もコスト効率の良いボリュームタイプは？
A1. General Purpose SSD
Q2.EBSのスナップショット取得中に障害発生し、インスタンスもEBSも変更を加えなければいけなくなった。この場合はどうする？
- スナップショット取得中でもEBSは利用できる。
- 取得が終わるまでEBSは利用できない
- デタッチ・アタッチができない
- リードオンリーで利用できる。
A2. 1
Q3. EBSスナップショットのもっともコスト効率の高い運用は？
A3.
Q4. 高頻度でアクセスされる、高スループットが必要なログ収集アプリケーションをコスト効率のいいアーキテクチャで構築したい。どのタイプのEBSボリュームタイプが最適か？
A4. EBS Throughput Optimized HDD(st1)
- EBSのボリュームタイプを検討するときは、下記の切り口で整理する。
| Features | SSD | HDD |
|---|---|---|
| ワークロード | 小規模、ランダム | 大規模、シーケンシャル |
| bootボリュームにできる？ | Yes | No |
| ユースケース | トランザクショナル、クリティカルなビジネス、大規模DB | ストリーム、BigData、DWH、ログ収集、低頻度アクセス |
| コスト | 高め | 安め |
| 得意 | IOPS | Throughput |
S3
Q1. S3にセンシティブなデータを置いており、ユーザはインターネット経由でこのデータにアクセスしている。セキュアな方式にするためにはどうすれば良いか
- Gateway VPCエンドポイント
- VPN コネクション
- Custom VPCエンドポイント
- Interface VPCエンドポイント powered by AWS PrivateLink
A1. 1
- はいはいVPCエンドポイントね、って思ってると詰む
- VPCエンドポイントの種類はサービス依存。ほとんどがInterface、DynamoDBとS3だけGatewayと覚えればOK
第7夜参照
Q2. ピーク時に秒間2000PUTと３０００Getのリクエストを受けられるようにするにはどうすればよいか
A2. Do Nothing(2020/3現在)
- S3はadd:3,500rps / retrieve:5,500rpsを保証している
- 追加コストはなし
- S3 prefixごとに上記性能を満たす
- よってアプリケーションのカスタマイズなしに、単純にコンピュート性能をスケールすることでS3パフォーマンスをスケールできる
Q3. 10TBの頻繁にアクセスされないデータはどのように格納するのが最も経済的か？ただし、監査の時期が来るとそれらのデータは必要になり、24時間以内に抽出できる必要がある。
A3. Glacierにブッコム。典型的には(10TBなら？)Glacierの抽出時間は5-12時間なので、24時間の猶予があるなら、コスト的にS3-IAよりも優位性あり。
Q4. 作成から3ヶ月以上経過した監査用のドキュメントを保管したい。コストは低く抑えつつ、抜き打ちで実施される監査の際には速やかにデータを取り出したい。最も適したオプションは何か？
A4. S3 Standard - Infrequent Access(S3 Standard-IA)
- Q3参照すると、Glacierは低コストだが抜き打ちの監査に対応できないためNG
Q5. 世界中に営業所がある企業で、年度末に一斉にレポートがS3にアップロードされる。アクセスが集中するため、アップロードに時間がかかる問題を解決するためにはどうすればよいか
- Transfer Acceleration
- Cross-Region Replication
- Multipart Upload
- AWS Global Accelerator
A5. 1
- AWS S3 Transfer Accelerationが最適解
- CloudFrontのEdge locationを利用して、edgeに到着したデータを最適なパスでS3に送信する
- Global AcceleratorはTCP・UDPを最適化することでアプリケーションのパフォーマンスをあげる使い方が基本
- Multipart uploadは大きいファイルを分割してアップすることで、失敗した時のリカバリ範囲を小さくする。一般的に１００MBを超えるファイルをアップする場合は、MPUの利用を検討するとよいらしい
Q6. オンラインのトレーディングプラットフォームでS3を利用している。AZやRegionがダウンした場合でも、S3中のファイルが影響を受けないような作りにするためにはどうすればよいか。
- 何もしないでよい
- Cross-Region Replicationを有効化する
- S3バケットをGlacierに定期的にバックアップするLifecycle policyを設定する
- S3バケットをEC2インスタンスのEBSにコピーする
- Storage Gatewayを利用してバックアップする
A6. 2
- Do Nothing!（キリッ）て答えて無事死亡
- S3はデフォルトでマルチAZにレプリケーションされているが、Regionをまたいでは複製されない
ref1. S3の整合性モデルを整理しよう
- 新規putについては書き込み後の読み込み整合性
- 新しいオブジェクトをS3に書き込み、すぐにバケット内のキーを一覧表示すると、変更が完全に反映されるまでオブジェクトがリスト表示されないことがある
- オブジェクトが作成される前にGET or HEADをリクエストして、直後にオブジェクトを作成した場合、結果整合性のために後続のGETがオブジェクトを返さない可能性がある。
- 上書きputおよびdeleteについては 結果整合性
- 既存のオブジェクトを置換し、すぐ読み取った場合、古いデータや更新されたデータが返されることがある
- 既存オブジェクトを削除し、すぐ読み取った場合、削除済みのデータを返すことがある
- 既存オブジェクトを削除し、すぐにバケット内のリスト一覧を表示した場合、削除済みのオブジェクトを一覧表示することがある
ref2. S3のLifecyclePolicyの整理
-
S3バケット関連の種類
- Standard S3
- Standard-IA(Infrequent Access)
- Onezone-IA
- Glacier
- Glacier Deep Archive
- Intelligent Tiering storage
- 自動でcost savingを行ってくれる
- アクセスパターンが分からない、よく変わる場合に有用
-
各種制約
- 128KB以下のファイルはコストメリットがないので、S3はStandard-IAやOnezone-IAへの移動はしない
- Standard-IAやOnezone-IAにオブジェクトを移動したい場合、S3に格納してから30日経過しないとできない（そのようなLifecyclePolicyが作れない）
- バージョンニングが有効な場合、30日経過したバージョンのみ移動可能