結果
2問選択形式で3択から絞れないパターンが多かった。
あと前回と合わせてRoute53、CloudFront、Lambda、Kinesis辺りが苦手なのを確認した。
復習
ユーザー数増加に対応するためのアーキテクチャ構造
A. 負荷分散処理のためにELB及びRoute53での加重ルーティングを採用する
EBSボリュームの選択
Q. 大規模ビックデータ向けの処理が多数発生する場合は？
A. 低レイテンシーを優先するならプロビジョンド、コスト最適化であるならスループット最適化HDD
S3のストレージオプションの罠
Standard-IAは処理中のデータの一時的な保存場所には不適切。
ユースケースで言えば例えばある画像データをリサイズするとか高解像度にするなどの処理を加える際、元データを一時的に保存して作業が完了すれば元データは削除するというケースになるわけだが、作業中は元データにアクセスし続けることになるので、IAは向かないということなのだろう。
ちなみにRSSは非推奨なのでこの場合はStandardを選ぶのが正解。
EC2インスタンス間のネットワーク遅延を少なくしたい
A. プレイスメントグループを設定する。
プレイスメントグループは単一のAZ内のインスタンスによる論理的なグループ。
EC2インスタンス間でのネットワーク待機時間の短縮、スループット性能の向上を期待したい場合はこれを選択する。
この場合、インスタンスタイプは拡張ネットワーキングをサポートするものを選択する。
特定のサービスへのアクセスに限定したい
Q. 例えばEC2インスタンスのアクセスを特定のS3バケットへのアクセスのみに限定したい場合はどうする？
A. EC2インスタンス側でIAMロール(ポリシー)を設定する
このようにアクセスを限定させたい方のサービスでポリシーを設定する。
逆にS3からのアクセスを特定のEC2インスタンスに限定したい場合はバケットポリシーを設定する。
EC2インスタンスに対してELBを設定し行うヘルスチェックについて
以下3つを使い分ける。
- インスタンスが正常かどうか……TCPヘルスチェック
- トランスポート層(TCP/UDP)が正常かどうか……UDP/TCPヘルスチェック
- アプリケーションの稼働が正常かどうか……HTTPヘルスチェック
SQSってキューに優先順位つけることできるの？
A. 優先度付きキューを使えば設定したキューの処理のアクセス優先度を高くすることができる
VPCにおいたEC2インスタンスがインターネットからアクセスできない
A.以下の4点を確認する
- インターネットゲートウェイがサブネットに設置されているか？
- ネットワークACLでアクセス許可しているか？
- セキュリティグループでアクセス許可しているか？
- インスタンスにパブリックIPアドレスは付与されているか？
ECSを利用したDockerアプリケーションを構築した場合、DynamoDBへの権限付与は？
A.ECSタスクに直接DynamoDBへのアクセス権限をIAMロールで付与する。
例えば読み取り処理を許可したいなら読み取り権限を付与したロールをタスクに付与する。
従来はEC2コンテナインスタンスに付与だったが、この場合だとタスク別にロールを付与することができない(正確にはこの場合にロールに付与するポリシーはコンテナ、同一クラスタが実行するすべてのタスクへの権限を含んだものになる。例えば、S3へのアクセスは別のタスクに付与されるべきなのに、DynamoDBアクセスのタスクにも結果的に付与されてしまう)。
現在は、タスクごとにロールを付与できるようになったことで必要十分の権限の付与ができるようになった。
Auto Scalingの設定順序
AMIは必須
- AMIの準備
- 起動テンプレート作成(ここでAMIのIDが必要)
- Auto Scalingグループを設定する
EBSのデータ保持に関して、最もデータの回復性が高くかつ即時復旧可能な方法は？
A. ミラーリング
EC2インスタンスから接続できて、数百万IOPSかつ一貫したミリ秒未満のレイテンシーの高速パフォーマンスを実行でき、多数のデータ転送に耐えられるストレージは？
A. Amazon FSx for Windows
ログ解析等で膨大なデータを蓄積した上で、後続のデータ解析を処理するためには？
A. Kinesis FirehoseでS3へのログ配信を行い、S3で蓄積しつつその後ログの解析処理を実行させる
ちなみに、リアルタイム性が必要ならDynamoDBにDAXクラスターを準備するという手段もある。