Uncategorized

#60

 

ありがとうございます！いただいたHTMLをもとに、指定いただいたフォーマットで整理しました。

問題文

季節労働者向けの求人情報サイトを提供している企業では、トラフィックと使用量が増加しています。バックエンドサービスは、Amazon DynamoDB をデータストアとして、 Application Load Balancer の背後にある 2 台の Amazon EC2 インスタンス上で実行されています。ピークシーズン中は、アプリケーションの読み取りと書き込みのトラフィックが遅くなります。どのオプションが、最小限の開発努力でピークシーズンを処理するためのスケーラブルなアプリケーションアーキテクチャを提供しますか？

選択肢

A：バックエンドサービスを AWS Lambda に移行します。DynamoDB の読み取りと書き込み容量を増やします。

B：バックエンドサービスに Auto Scaling グループを使用します。DynamoDB Auto Scaling を使用します。

C：バックエンドサービスを AWS Lambda に移行します。グローバルテーブルを使用するように DynamoDB を設定します。

D：バックエンドサービスに Auto Scaling グループを使用します。Amazon Simple Queue Service (Amazon SQS) と AWS Lambda 関数を使用して DynamoDB に書き込みます。

問題文の要件の概要

  • 現状：
    • EC2×2台 + ALB + DynamoDB
    • ピーク時に処理遅延が発生
  • 要件：
    • 最小限の開発努力でピークシーズンのスケーラブルなアーキテクチャを実現すること。
    • 読み取り・書き込みトラフィックの増加に対応できること。

正解の選択肢と解説

B：バックエンドサービスに Auto Scaling グループを使用します。DynamoDB Auto Scaling を使用します。

  • 既存のEC2ベースのアプリを維持したまま、Auto Scaling グループを導入することで、ピーク時にEC2の台数を動的にスケール可能。
  • DynamoDB Auto Scaling を組み合わせることで、アプリケーションコードの変更なしに読み書きスループットを自動調整できる。
  • **「最小限の開発努力」**という要件に最も合致する。

不正解の選択肢の理由

  • A：Lambda + DynamoDB 容量増加
    • Lambda へ移行するにはコード修正が必要。開発工数が大きいため「最小限の開発努力」の要件を満たさない。
  • C：Lambda + DynamoDB グローバルテーブル
    • グローバルテーブルはマルチリージョン高可用性が目的であり、単純なピークトラフィック対応には不要。
    • こちらもLambda移行の工数が大きく不適切。
  • D：Auto Scaling + SQS + Lambda 書き込み
    • SQSとLambdaによる非同期書き込みはシステムを複雑化させ、追加の開発が必要。
    • 「最小限の開発努力」要件に反する。

SAP試験で押さえておくべきポイント

  • 既存アーキテクチャの前提を崩さずにスケーラブルにするには「Auto Scaling」の適用が最優先。
  • DynamoDB Auto Scalingは、プロビジョンドスループットをトラフィックに応じて自動調整する機能 → 開発者の運用負荷を大きく軽減する。
  • 試験で「最小限の開発 effort」「アプリの変更を避けたい」とあれば → Auto Scaling + マネージド機能を優先的に考える。
  • Lambdaへの移行やSQS導入は「リファクタリングあり」シナリオに分類されるため、「短期間・低工数」では不正解になりやすい。

この整理でよろしいでしょうか？
次の問題も同じフォーマットで出力しますか？

了解しました！いただいた問題を整理しました。

問題文

ある企業では、すべての社内アプリケーション接続でプライベート IP アドレスを使用することを義務付けています。このポリシーを容易にするために、ソリューションアーキテクトは AWS パブリックサービスに接続するためのインターフェイスエンドポイントを作成しました。テスト時に、ソリューションアーキテクトは、サービス名がパブリック IP アドレスに解決され、内部サービスがインターフェイスエンドポイントに接続できないことに気づきました。

この問題を解決するためにソリューションアーキテクトが実行すべき手順を選択してください。

選択肢

A：インターフェイスエンドポイントへのルートでサブネットのルートテーブルを更新します。

B：インターフェイスエンドポイントでセキュリティグループを構成して、AWS サービスへの接続を許可します。

C：社内アプリケーション用の条件付きフォワーダーを使用して Amazon Route 53 プライベートホストゾーンを構成します。

D：VPC 属性でプライベート DNS オプションを有効にします。

問題文の要件の概要

  • 要件：
    • すべての社内アプリケーション接続は「プライベート IP アドレス」を利用しなければならない。
    • AWSパブリックサービスに VPCエンドポイント(Interface Endpoint, PrivateLink) を利用して接続したい。
  • 問題：
    • サービス名が パブリック IP に解決 されてしまい、プライベートエンドポイントに到達できない。
  • 求められる解決策：
    • DNS解決を プライベート IP に切り替える仕組み を有効化すること。

正解の選択肢と解説

D：VPC 属性でプライベート DNS オプションを有効にします。

  • VPCエンドポイントには「プライベートDNS名」オプションがあり、これを有効にするとサービス名（例: ec2.us-east-1.amazonaws.com）が インターフェイスエンドポイントのENIのプライベートIP に解決される。
  • これにより、社内アプリケーションはパブリックIPを経由せず、直接プライベートリンク経由でサービスに接続できるようになる。
  • 問題文の「パブリックIPに解決されてしまう」課題を根本的に解決する正しい手順。

不正解の選択肢の理由

  • A：ルートテーブル更新
    • ルートはネットワーク経路の問題を解決する手段であり、DNS解決の問題には無関係。誤り。
  • B：セキュリティグループ構成
    • SGはアクセス制御の役割であり、DNSの解決方法には影響を与えない。DNSがパブリックを返している現状では根本解決にならない。
  • C：Route 53 プライベートホストゾーン + 条件付きフォワーダー
    • 可能ではあるが、本来AWSが自動的に行う「プライベートDNS名有効化」で済む話を、わざわざ複雑にしてしまっている。要件に対する直接解決策ではない。

SAP試験で押さえておくべきポイント

  • VPCエンドポイント(Interface Endpoint / PrivateLink) を利用する場合：
    • デフォルトはサービス名がパブリックIPに解決される。
    • **「プライベートDNS名を有効化」**することで、同じサービス名を使ってもプライベートIPに解決され、内部から安全に利用可能になる。
  • 誤答パターンとして：
    • 「ルートテーブル」「セキュリティグループ」「Route53の複雑な設定」はDNS解決問題の根本解決にならない。
  • 本試験では「DNS解決の仕組み」と「PrivateLinkの動作」をセットで理解しているかを確認される。

この問題は 「プライベートDNSオプションの有効化 = PrivateLink経由の正しい解決」 を押さえているかどうかを確認する典型問題です。

👉 次の問題も同じ形式で整理しますか？

ありがとうございます！いただいた問題3を整理しました。

問題文

あるチームは、企業全体の行動データを収集し、ルーティングしています。この会社では、パブリックサブネット、プライベートサブネット、インターネットゲートウェイを備えたマルチ AZ 構成な VPC 環境を運用しています。各パブリックサブネットには、NAT ゲートウェイも含まれています。この会社のアプリケーションのほとんどは、Amazon Kinesis Data Streams から読み書きします。ワークロードのほとんどは、プライベートサブネットで実行されます。ソリューションアーキテクトはインフラストラクチャを見直す必要があります。コストを削減し、アプリケーションの機能を維持する必要があります。ソリューションアーキテクトは、Cost Explorer を使用して、EC2-Other カテゴリのコストが常に高いことに気づきました。さらに検討すると、NatGateway-Bytes の料金が EC2-Other カテゴリのコストを増加させていることがわかります。これらの要件を満たすために、ソリューションアーキテクトは何をすべきですか？

選択肢

A：VPC フローログと Amazon Detective を有効にします。Kinesis Data Streams に関連のないトラフィックの検出結果を確認します。セキュリティグループを設定して、そのトラフィックをブロックします。

B：VPC フローログを有効にします。Amazon Athena を使用して、削除できるトラフィックのログを分析します。セキュリティグループが高コストの原因となるトラフィックをブロックしていることを確認します。

C：Kinesis Data Streams のインターフェース VPC エンドポイントを VPC に追加します。アプリケーションがインターフェイス VPC エンドポイントを使用するための正しい IAM 権限を持っていることを確認します。

D：Kinesis Data Streams のインターフェース VPC エンドポイントを VPC に追加します。VPC エンドポイントポリシーがアプリケーションからのトラフィックを許可していることを確認します。

問題文の要件の概要

  • 現状：
    • マルチAZ VPC（パブリック/プライベートサブネット、NAT Gatewayあり）。
    • アプリは主にプライベートサブネット内で稼働。
    • データの入出力先は Amazon Kinesis Data Streams。
    • コスト分析の結果、NAT Gatewayの転送（NatGateway-Bytes）コストが高額。
  • 要件：
    • コスト削減しつつ、アプリがKinesis Data Streamsを利用できる状態を維持すること。

正解の選択肢と解説

D：Kinesis Data Streams のインターフェース VPC エンドポイントを VPC に追加します。VPC エンドポイントポリシーがアプリケーションからのトラフィックを許可していることを確認します。

  • Kinesis Data Streams は Interface VPC Endpoint (PrivateLink) をサポートしている。
  • これを利用すると、アプリケーションからのトラフィックは NAT Gatewayを経由せずにAWSサービスへ直接接続可能。
  • これにより、NAT Gatewayの「転送量課金（NatGateway-Bytes）」を大幅に削減できる。
  • VPCエンドポイントポリシーでアクセス制御を正しく設定する必要がある。

不正解の選択肢の理由

  • A：VPCフローログ + Detective で不要トラフィックを分析
    • フローログ分析は可視化に役立つが、NAT Gateway経由のKinesisトラフィックを削減する根本解決にはならない。
  • B：VPCフローログ + Athenaで分析
    • こちらもトラフィックの調査に留まり、コスト削減には直結しない。セキュリティグループの設定ではデータ転送料金を避けられない。
  • C：Interface VPC Endpoint + IAM権限確認
    • IAM権限は必要だが、根本的にエンドポイントでの接続許可は VPCエンドポイントポリシー で制御される。IAMだけに着目しているため不十分。

SAP試験で押さえておくべきポイント

  • NAT Gatewayの高額コスト（特にBytes課金）対策は、VPCエンドポイント導入が定番。
  • Interface VPC Endpoint (PrivateLink) を利用すると、プライベートサブネット内のリソースが直接AWSサービスへアクセスできる。
  • IAMポリシーはアプリの認可管理に使うが、VPCエンドポイントポリシーがエンドポイント利用時の主要制御となる。
  • 試験では「コスト削減」+「NAT Gateway課金」+「PrivateLink導入」というパターンをセットで覚えておくべき。

この問題は「NAT Gatewayコスト削減のためにVPCエンドポイントを導入する」パターンの典型例ですね。

👉 続けて問題4も整理しますか？

ありがとうございます！問題4を整理しました。

問題文

ある企業のメインのイントラネットページでは、ユーザーがエラーページを見たという報告はないものの、ユーザー数の増加に伴いレスポンスタイムが低下しています。このアプリケーションは、読み取り専用モードで Amazon DynamoDB を使用しています。成功したリクエストの Amazon DynamoDB レイテンシーメトリクスは、ユーザーが劣化を報告しているときでも安定した状態にあります。開発チームは、この問題をスキャン操作と読み取り操作を行う際にアプリケーションログにある ProvisionedThroughputExceeded 例外に関連付けました。 また開発チームは、個々のデータ項目の分散セットに対する読み取りアクティビティが定常的にスパイクのアクセスパターンを特定しました。最高技術責任者は、ユーザーエクスペリエンスを向上させたいと考えています。アプリケーションへの変更を最小限に抑えて、これらの要件を満たすソリューションはどれですか？ (2 つ選択）

選択肢

A：DynamoDB Accelerator (DAX) クライアントを実装し、アプリケーションの負荷を維持するために適切なノードタイプで DAX クラスターをプロビジョニングします。最適なユーザーエクスペリエンスを実現するために、項目とクエリのキャッシュ構成を調整します。

B：スロットリングエラーを処理するために、アプリケーションコードのエラー再試行とエクスポネンシャルバックオフを削除します。

C：クラスターモードを有効にして Redis 用 Amazon ElastiCache をプロビジョニングします。クラスターには、アプリケーションの負荷を分散し、シャードごとに少なくとも 1 つのリードレプリカノードをプロビジョニングするのに十分なシャードをプロビジョニングする必要があります。

D：DynamoDB テーブルのデータモデルを変更して、すべてのスキャンと読み取り操作が均一なデータアクセスの DynamoDB のベストプラクティスを満たし、DynamoDB テーブルにプロビジョニングされた完全なリクエストスループットに達するようにします。

E：DynamoDB Auto Scaling を有効にして、テーブルトラフィックの増加に応じてスループット容量を管理します。上限と下限を設定してコストを管理し、ピーク使用量とトラフィックの変化の速さを考慮して目標使用率を設定します。

問題文の要件の概要

  • 現状：
    • DynamoDB 読み取り専用アプリ。
    • レイテンシーメトリクス自体は安定しているが、アプリは ProvisionedThroughputExceeded（スロットリング） を多数記録。
    • 読み取りが一部の項目に集中 → スパイク的なアクセスが発生。
  • 要件：
    • ユーザー体感のレスポンス改善。
    • アプリケーション変更を最小限にすること。

正解の選択肢と解説

A：DynamoDB Accelerator (DAX)

  • 読み取り専用ワークロードでレスポンス改善に有効。
  • キャッシュレイヤーとして機能し、スパイク的なアクセスでも低レイテンシーを維持。
  • アプリケーション側はDAXクライアントを導入するだけで済み、大幅なコード変更は不要。

E：DynamoDB Auto Scaling

  • トラフィック増加に応じて プロビジョンドスループットを自動調整。
  • スパイクによるスロットリングを軽減。
  • 上下限や目標使用率を設定でき、コストと性能のバランスを取れる。

不正解の選択肢の理由

  • B：エラー再試行とエクスポネンシャルバックオフを削除
    • 再試行・バックオフは推奨されるベストプラクティス。削除すると信頼性が低下する。
  • C：Redis用ElastiCacheを導入
    • キャッシュとしては有効だが、アプリとDynamoDBの間に新たな設計を加える必要がある。
    • DAXの方がDynamoDB専用で統合されており、アプリ改修コストが小さい。
  • D：データモデルの変更
    • 効果的ではあるが、要件は「アプリケーションへの変更を最小限」。データモデル修正は大規模改修になるため不適切。

SAP試験で押さえておくべきポイント

  • DynamoDBスロットリング対応策：
    1. DAX導入（キャッシュによる読み取り性能改善）
    2. Auto Scalingでスループット調整
    3. 必要に応じて バックオフ & リトライ（AWS SDK標準機能）
  • 「最小限のアプリ改修で改善」＝ DAX + Auto Scaling が試験での定番解答。
  • Redis/ElastiCache は汎用キャッシュであり、DynamoDB専用キャッシュ（DAX）よりも追加工数がかかる。
  • データモデル最適化は本番環境改善には重要だが、試験シナリオの「短期・最小変更」では誤答となりやすい。

👉 この問題は 「DAX + Auto Scaling」 を組み合わせる典型パターンとして出題されていますね。

次の問題5も整理しますか？

ありがとうございます！問題5を整理しました。

問題文

メディア会社には、プログラムで生成される静的ウェブアプリケーションがあります。同社には、Amazon CloudFront が提供する Amazon S3 バケットにアップロードされる HTML コンテンツを生成するビルドパイプラインがあります。ビルドパイプラインは、ビルドアカウント内で実行されます。S3 バケットと CloudFront ディストリビューションはディストリビューションアカウントにあります。ビルドパイプラインは、ビルドアカウントの IAM ロールを使用してファイルを Amazon S3 にアップロードします。S3 バケットにはバケットポリシーがあり、CloudFront にはオリジンアクセスコントロール (OAC) を使用したオブジェクトの読み取りのみを許可しています。

テスト中に、CloudFront の URL を使用してアプリケーションにアクセスしようとすると、HTTP 403 Access Denied のレスポンスが発生しました。

CloudFront を介して Amazon S3 のオブジェクトにアクセスできるようにするには、ソリューションアーキテクトが会社に何を提案する必要がありますか？

選択肢

A：ディストリビューションアカウントに、S3 バケットへの読み取りアクセスを持つ新しい IAM ロールを作成します。CloudFront がこの新しいロールを OAC として使用するように設定します。ビルドアカウントからファイルをアップロードする際に、このロールを想定するようにビルドパイプラインを修正します。

B：ビルドアカウントの S3 アップロード処理を修正して、アップロード時のオブジェクトに bucket-owner-full-control ACL を追加します。

C：ディストリビューションアカウントに、S3 バケットへの書き込みアクセス権を持つクロスアカウントの IAM ロールを新たに作成します。ディストリビューションアカウントにファイルをアップロードするために、このロールを想定してビルドパイプラインを修正します。

D：ビルドアカウントの S3 アップロードプロセスを変更して、オブジェクトの所有者をディストリビューションアカウントに設定します。

問題文の要件の概要

  • 現状：
    • CloudFront + OAC 経由でS3を公開。
    • ビルドパイプラインは別アカウント（ビルドアカウント）からオブジェクトをアップロード。
    • S3オブジェクトの所有者はデフォルトで「アップロード元アカウント（ビルドアカウント）」になる。
    • そのため、バケット所有者（ディストリビューションアカウント）はアクセス権を持たず、CloudFront経由で403が返っている。
  • 要件：
    • CloudFront（OAC利用）からS3オブジェクトにアクセスできるようにする。

正解の選択肢と解説

B：ビルドアカウントの S3 アップロード処理を修正して、アップロード時のオブジェクトに bucket-owner-full-control ACL を追加します。

  • S3のデフォルト動作では、オブジェクト所有者はアップロード元アカウントになる。
  • そのままだと、バケット所有者（ディストリビューションアカウント）がそのオブジェクトを読み取れない。
  • bucket-owner-full-control ACL を追加することで、アップロード時にバケット所有者にフルコントロールを付与できる。
  • これにより、CloudFrontのOAC経由でアクセスが可能になる。

不正解の選択肢の理由

  • A：新しいIAMロールを作成しても、S3オブジェクト所有権の問題は解決できない。OACはIAMロールを使わない仕組み。
  • C：ビルドアカウントが直接S3にアップロードする仕組みをわざわざ変更する必要はない。根本的な所有権の問題が残る。
  • D：オブジェクト所有者を直接変更することはできない。可能なのはACLを使ってバケット所有者に権限を付与する方法。

SAP試験で押さえておくべきポイント

  • クロスアカウントS3アクセスの基本ルール：
    • オブジェクトをアップロードしたアカウントがオブジェクトの所有者になる。
    • バケット所有者はデフォルトではアクセスできない。
    • 解決策は「アップロード時に bucket-owner-full-control ACL を指定」すること。
  • CloudFront + OACの挙動：
    • OACは「バケットポリシー」と連動し、バケット所有者の権限でアクセスを行う。
    • したがって、バケット所有者にオブジェクトアクセス権を付与しておく必要がある。
  • 試験では「403 AccessDenied + クロスアカウントアップロード」→ bucket-owner-full-control ACL を追加する、と覚えておくと正解しやすい。

👉 この問題は S3オブジェクト所有者とバケット所有者の関係を理解しているかを問う典型パターンですね。

次の問題6も整理しますか？

ありがとうございます！問題6を整理しました。

問題文

ソリューションアーキテクトは、起動前にアプリケーションの復元力をレビューしています。アプリケーションは、VPC のプライベートサブネットにデプロイされた Amazon EC2 インスタンス上で実行されます。EC2 インスタンスは、最小キャパシティ 1、最大キャパシティ 1 の Auto Scaling グループによってプロビジョニングされています。アプリケーションは、Amazon RDS for MySQL DB インスタンスにデータを保存します。VPC には 3 つのアベイラビリティーゾーンで構成されたサブネットがあり、1 つの NAT ゲートウェイで構成されています。

ソリューションアーキテクトは、アプリケーションが複数のアベイラビリティーゾーンにわたって確実に動作するようにソリューションを推奨する必要があります。

この要件を満たすソリューションを選択してください。

選択肢

A：NAT ゲートウェイを NAT インスタンスに置き換えます。RDS for MySQL DB インスタンスを RDS for PostgreSQL DB インスタンスに移行します。他のアベイラビリティーゾーンで新しい EC2 インスタンスを起動します。

B：NAT ゲートウェイを仮想プライベートゲートウェイに置き換えます。RDS for MySQL DB インスタンスを Amazon Aurora MySQL DB クラスターに置き換えます。VPC 内のすべてのサブネットでインスタンスを起動するように Auto Scaling グループを設定します。Auto Scaling グループの最小キャパシティと最大キャパシティを 3 に設定します。

C：他のアベイラビリティーゾーンに追加の NAT ゲートウェイをデプロイします。ルートテーブルを適切なルートで更新します。RDS for MySQL DB インスタンスをマルチ AZ 構成に変更します。アベイラビリティーゾーン全体でインスタンスを起動するように Auto Scaling グループを構成します。Auto Scaling グループの最小キャパシティと最大キャパシティを 3 に設定します。

D：他のアベイラビリティーゾーンに追加の NAT ゲートウェイをデプロイします。ルートテーブルを適切なルートで更新します。RDS for MySQL DB インスタンスを変更して、自動バックアップを有効にし、バックアップを 7 日間保持します。VPC 内のすべてのサブネットでインスタンスを起動するように Auto Scaling グループを設定します。Auto Scaling グループの最小キャパシティと最大キャパシティを 1 に保ちます。

問題文の要件の概要

  • 現状の課題
    • EC2：Auto Scaling グループは「最小1・最大1」→ 単一AZ障害に弱い。
    • RDS：シングルAZ構成 → DB障害時の可用性に欠ける。
    • NAT GW：1つだけ → そのAZで障害発生時にプライベートサブネットのインスタンスが外部通信できなくなる。
  • 要件
    • アプリケーションを「複数AZ」にまたがって高可用に。
    • EC2、NAT GW、RDSの冗長化が必要。

正解の選択肢と解説

C：他のアベイラビリティーゾーンに追加の NAT ゲートウェイをデプロイし、RDS をマルチAZ構成に、ASG を3AZ分散にする。

  • NAT Gateway
    • 各AZに1つずつ配置し、ルートテーブルを更新することで、AZ障害時もプライベートサブネットからの通信が維持される。
  • RDS (MySQL)
    • マルチAZ構成にすることで、DB障害時に自動フェイルオーバー可能。
  • Auto Scaling Group (ASG)
    • 複数AZにまたがるように設定し、最小キャパシティ3、最大キャパシティ3とすることで、各AZに1台ずつ分散 → 高可用性を実現。

👉 この組み合わせで EC2・RDS・NATすべてがAZ障害に強い設計になる。

不正解の選択肢の理由

  • A：NATインスタンスはスケーラビリティ・可用性に劣り、RDSをPostgreSQLに移行しても冗長化は実現できない。
  • B：仮想プライベートゲートウェイはインターネットアクセスの代替にはならない。Aurora化は可用性改善になるが、NATの問題を解決しない。
  • D：NAT GWの冗長化は正しいが、RDSをバックアップ有効化するだけでは「高可用性」にはならない。ASGキャパシティ1も不十分。

SAP試験で押さえておくべきポイント

  • 高可用性設計の3本柱
    1. EC2 Auto Scaling Groupを複数AZに分散（最小=AZ数に設定することが多い）。
    2. RDSはマルチAZ配置で自動フェイルオーバーを有効化。
    3. NAT GatewayはAZごとに配置し、ルートテーブルを分散。
  • 「単一AZ依存」を排除するのが試験での正しい思考プロセス。
  • 「バックアップ」や「DBエンジン変更」は冗長化には直結しない。

👉 この問題は 「3要素をマルチAZ化せよ」 を押さえていれば一発で解ける典型パターンですね。

次の問題7も整理しましょうか？

ありがとうございます！問題7を整理しました ✅

問題文

ある会社が、Amazon EFS に保存された多数の共有ファイルを生成する密結合ワークロード用に、AWS にハイパフォーマンスコンピューティング (HPC) クラスターを構築しました。
クラスター内の Amazon EC2 インスタンスが 100 台のときは良好に動作していましたが、1,000 台に増やしたところ、全体のパフォーマンスが予想を大幅に下回りました。

HPC クラスターから最大パフォーマンスを発揮させるために、ソリューションアーキテクトが取るべき設計上の選択はどれですか？（3つ選択）

選択肢

A：HPC クラスターが単一のアベイラビリティーゾーン内で起動されるようにします。
B：Amazon EFS を Amazon FSx for Lustre に置き換えます。
C：Elastic Fabric Adapter (EFA) が有効な EC2 インスタンスタイプを選択します。
D：EC2 インスタンスを起動し、4 の倍数で Elastic Network Interface をアタッチします。
E：クラスターが複数のアベイラビリティーゾーンにわたって起動されることを確認します。

要件の概要

  • 密結合HPCワークロード → 低レイテンシー・高スループットが重要。
  • 100台ではOK → 1000台で性能低下 → ストレージ性能・ネットワーク性能・配置戦略がボトルネック。
  • HPCでは以下が必須：
    • 同一AZ配置（レイテンシー低減、Placement Group活用）。
    • 高性能ストレージ（FSx for Lustre推奨、EFSは高レイテンシー）。
    • 高性能ネットワーク（EFA）。

正解の選択肢

✅ A：単一AZ内に配置
→ HPCは超低レイテンシーが必要。複数AZに分散するとレイテンシー増大 → パフォーマンス悪化。
→ Cluster Placement Group を活用。

✅ B：FSx for Lustre に置き換え
→ EFSはスループットに制限があり、大規模HPCに不向き。
→ FSx for Lustre は数百GB/s級のスループットを持ち、HPCに最適。

✅ C：EFA対応インスタンスタイプを利用
→ EFAはMPI等の通信で超低レイテンシー・高スループットを実現。
→ 大規模HPCクラスターでは必須。

不正解の選択肢

❌ D：ENIを4の倍数でアタッチ
→ ENI数を増やしてもHPCワークロードの性能改善にはつながらない。

❌ E：複数AZにまたがって起動
→ HPCでは逆効果。AZ間レイテンシーにより性能が劣化する。

試験で押さえるポイント

  • HPCワークロード設計の鉄則
    1. 同一AZ＋Cluster Placement Group
    2. FSx for Lustreを使用（EFSは不向き）
    3. EFAで低レイテンシー通信を実現
  • 典型的なひっかけ：「複数AZに分散」や「ENIを増やす」→ HPCでは誤り。

👉 正解は A・B・C です。

次は、問題8（もし続きがあれば）も同じ形式で整理していきましょうか？

RELATED POST