AWS SAA模擬試験を受けて間違えた箇所をメモします。
まだまだAWSの知らないサービスや浅い理解しかできていない概念が多いのでしっかり勉強していきます。
EC2のPlacement Groupで同時にfailureにならないようにするにはSpread Placement Groupにする
そもそもPlacement Groupについてよくわからなかったので調べました。
新しい EC2 インスタンスを起動する場合、EC2 サービスは、相関性のエラーを最小限に抑えるために、すべてのインスタンスが基盤となるハードウェアに分散されるようにインスタンスを配置します。プレイスメントグループを使用することで、ワークロードのニーズに対応するために独立したインスタンスのグループのプレイスメントに影響を与えることができます。
Placement Groupには以下の種類があるとのこと。
クラスター – アベイラビリティーゾーン内でインスタンスをまとめます。この戦略により、ワークロードは、HPC アプリケーションで典型的な緊密に組み合わされたノード間通信に必要な低レイテンシーネットワークパフォーマンスを実現できます。
パーティション – インスタンスを複数の論理パーティションに分散させ、1 つのパーティション内のインスタンスのグループが基盤となるハードウェアを別のパーティション内のインスタンスのグループと共有しないようにします。この戦略は、Hadoop、Cassandra、Kafka などの大規模な分散および複製ワークロードで一般的に使用されます。
分散 – 相関性のエラーを減らすために、少数のインスタンスを厳密に基盤となるハードウェア全体に配置します。
グループ内のインスタンスが同時に落ちないようにするには分散タイプが最適とのこと。
Placement Groupでレイテンシーを減らすことが優先される場合はクラスターが最適
Placement Groupでクラスタータイプは同じラックにインスタンスがあるので、10Gbpsで接続されているとのこと。
プライベートサブネットにアクセスするリソースのIPアドレスを取得するにはVPC Flow Logsを使う
VPC Flow LogsはVPCを行き来するIPトラフィックのキャプチャを取得できる機能とのこと。
VPC Flow Logsを作成すると、そのデータをCloudWatch Logsで見ることができる。
Lustreファイルシステムをコストを抑えて構築するにはAmazon FSxを使用する
そもそもLustreとAmaxon FSxがよくわからなかったので調べました。
LustreファイルシステムはHPC(high-performance computing)アプリケーションなどで使われるとのこと。
Amazon FSxのドキュメントはこちらです。
aws.amazon.com
Amazon FSx を使用すると、一般的なファイルシステムを AWS がフルマネージドで簡単かつ優れたコスト効率で起動して実行できます。Amazon FSx では、ハードウェアプロビジョニング、ソフトウェア設定、パッチ適用、バックアップなどの時間のかかる管理タスクを回避しながら、広く使用されているオープンソースと商用ライセンスファイルシステムの豊富な機能セットと高速パフォーマンスを活用できます。
Amazon FSxはLustreファイルシステムもサポートしているとのこと。
また、LustreファイルシステムはEBSを通しても使えるが、Amazon FSxを使うほうがシンプルに構築できる。
NATインスタンスとNATゲートウェイは別のサービス
問題文でNATインスタンスという言葉が出てきて、NATゲートッウェイとの違いがわからず混乱しましたが、別のサービスのようです。
NATゲートウェイの別の言い方でインスタンスって言うのかと勘違いしました。
Auto Scaling groupでCPU使用率を見てスケーリングさせたい場合はTarget tracking scaling policyを使う
Auto Scaling groupにもいくつかタイプがある。
Target tracking scaling — 特定のメトリクスのターゲット値に基づいて、グループの現在の容量を増減させます。これはサーモスタットで家の温度を管理する方法と似ています — 温度を選択すれば、後はサーモスタットがすべてを実行します。
Step scaling — アラーム超過のサイズに応じて変動する一連のスケーリング調整値 (ステップ調整値と呼ばれる) に基づいて、グループの現在の容量を増減させます。
Simple scaling — 1 つのスケーリング調整値に基づいて、グループの現在の容量を増減させます。
インスタンスのCPU使用率によってスケーリングを行う場合はTarget tracking scalingが最適とのこと。
EBSのスナップショットを別のリージョンでも使えるようにするには、スナップショットを作成して、それを別のリージョンにコピーする
そもそもEBSのスナップショットを作成できることを初めて知ったのでまずはドキュメントを読みました。
そして別のリージョンでも使えるようにするには、S3などを介す必要はなく、そのままコピーできるとのことです。(このあたりまだ理解が浅いので要勉強)
全てのリージョンでAPIの状況をチェックするにはCloudTrailが全リージョンで有効になっていることを確認する
CloudTrailsは全リージョンで使えるようです。
AWS Resource Managerを使ってAWS Organizations内のAWSアカウントでリソースを共有できる
そもそもResource Access Managerがわからなかったので調べました。
AWS Resource Access Manager (RAM) は、AWS のリソースを任意の AWS アカウントまたは AWS 組織内で簡単かつ安全に共有できるサービスです。
スケーリングについての問題でELBの種類は関係ないはず
スケーリングについての問題で解答の選択肢にClassic ELBをApplication ELBに変更する、という選択肢があって、Classic ELBはあんまり使われること無さそうだから変えた方がいいんじゃないかなと思って選択しましたが、不正解だったのでメモ。
確かにELBの種類はスケーリングの観点ではないと思いました。
Route 53でランダムにリクエストを振り分ける時はMultivalue Answer with health checkを選択する
Route 53のルーティングポリシーの種類がよくわかっていないので調べました。
シンプルルーティングポリシー – ドメインで特定の機能を実行する単一のリソースがある場合に使用します。たとえば、example.com ウェブサイトにコンテンツを提供する 1 つのウェブサーバーなどです。
フェイルオーバールーティングポリシー – アクティブ/パッシブフェイルオーバーを構成する場合に使用します。
位置情報ルーティングポリシー – ユーザーの位置に基づいてトラフィックをルーティングする場合に使用します。
地理的近接性ルーティングポリシー – リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する場合に使用します。
レイテンシールーティングポリシー – 複数の AWS リージョンにリソースがあり、レイテンシーの最も小さいリージョンにトラフィックをルーティングする場合に使用します。
複数値回答ルーティングポリシー – ランダムに選ばれた最大 8 つの正常なレコードを使用して Route 53 が DNS クエリに応答する場合に使用します。
加重ルーティングポリシー – 指定した比率で複数のリソースにトラフィックをルーティングする場合に使用します。
正常なインスタンスからランダムに振り分けたいときは複数値回答ルーティングポリシーが最適なようです。
わからない問題があったら新しい知識を得るチャンスと思って、ちゃんと調べて次に繋げていきたいと思います。
