Uncategorized

#40

 

以下、問題1を指定の形式で整理・解説いたします。

■問題文（編集せずそのまま出力）

あるメディア企業では、30 TB のデジタル・ニュース・動画のレポジトリを保有しています。これらの動画はオンプレミスのテープライブラリに保存され、メディア・アセット・マネジメント（MAM）ソリューションによって参照されます。同社は、MAM ソリューションを使用して、これらの動画のメタデータを自動化された方法で付与して、検索可能なカタログを作成したいと考えています。また、動画内の情報に基づいて、モノ、人物、テキスト、シーン、アクティビティを識別したカタログを利用して検索できる必要があります。同社は、これらの動画を AWS に移行したいと考えています。オンプレミス と AWS 間は高速な AWS Direct Connect 接続を使用しており、MAM ソリューションの動画コンテンツを直接移行したいと考えています。

最小限の労力と既存のシステムの最小限の変更で、要件を満たす方法を選択してください。

■選択肢（編集せずそのまま出力）

A. Amazon Kinesis Video Streams を使用して動画取り込みストリームを設定します。顔のカタログを使用して、Amazon Rekognition でコレクションを作成します。MAM ソリューションから Kinesis Video Streams に動画をストリーミングします。ストリーミングされた動画を処理するように Amazon Rekognition を構成します。次に、ストリームコンシューマを使用して必要なメタデータを取得し、メタデータを MAM ソリューションに保存します。Amazon S3 に動画を保存するようにストリームを構成します。

B. OpenCV ライブラリを実行する Amazon EC2 インスタンスをセットアップします。動画、画像、および顔のカタログをオンプレミスライブラリから EC2 インスタンスにマウントされた Amazon EBS ボリュームにコピーします。必要なメタデータを取得するために動画を処理し、メタデータを MAM ソリューションに保存すると同時に、動画ファイルを Amazon S3 バケットにコピーします。

C. AWS Storage Gateway テープゲートウェイアプライアンスをオンプレミスでセットアップします。MAM ソリューションを使用して、現在のアーカイブから動画を抽出し、それらをテープゲートウェイに保存します。顔のカタログを使用して、Amazon Rekognition でコレクションを作成します。Amazon Rekognition がテープゲートウェイ上に保存された動画を処理し、必要なメタデータを取得し、メタデータを MAM ソリューションに保存するように、Rekognition Javascript SDK を呼び出す AWS Lambda 関数を作成します。

D. AWS Storage Gateway、ファイルゲートウェイアプライアンスをオンプレミスでセットアップします。MAM ソリューションを使用して、現在のアーカイブから動画を抽出し、それらをファイルゲートウェイに保存します。顔のカタログを使用して、Amazon Rekognition でコレクションを作成します。Rekognition Javascript SDK を呼び出す AWS Lambda 関数を構築し、Rekognition にファイルゲートウェイをバックアップする Amazon S3 上のファイルから動画を引き出し、必要なメタデータを取得し、メタデータを MAM ソリューションに保存します。

■問題文の要件の概要

  • 既存のオンプレミステープライブラリ上の動画を AWS に移行したい
  • MAM ソリューションを使った検索性の高いカタログ作成（AIによるモノ・人物・テキスト・シーンの識別）
  • Direct Connect 経由で高速接続あり
  • 最小限の労力・最小限のシステム変更で実現

■正解の選択肢と解説

  • 正解：D
    AWS Storage Gateway（ファイルゲートウェイ）をオンプレミスに導入すれば、ローカルファイルシステムのように AWS S3 に動画を保存可能です。これは 既存のシステム構成に最小限の変更で対応できます。
    Amazon Rekognition は S3 に保存された動画を解析して、モノ、人物、テキスト、シーン、アクティビティのメタデータを生成可能。
    Lambda 関数で処理を自動化すれば、MAM ソリューションとの統合も容易です。

■不正解の選択肢の理由

  • A：Kinesis Video Streams はリアルタイム処理向け。
    → 本ケースのように 既存のアーカイブからバルク処理するシナリオには不適で、構成変更も多いため不適。
  • B：EC2 + OpenCV は完全な自前実装。
    → Rekognition のようなマネージドな AI サービスを使わず、インフラ・ライブラリ管理の負担が大きい。MAM との統合も複雑。
  • C：テープゲートウェイはアーカイブ用途に最適化。
    → Rekognition のような頻繁なデータアクセス・解析処理には不向きで、リアルタイム処理やメタデータ生成には非効率。

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

  • **AWS Storage Gateway（ファイルゲートウェイ）**は、オンプレミスと AWS S3 の統合に非常に有効。特に「最小限の変更」でクラウド移行したいケースで選択されやすい。
  • Amazon Rekognition は画像・動画から高度なメタデータ（人物、モノ、テキストなど）を抽出でき、メディア管理に強力。
  • AWS Lambda + SDK 呼び出しにより、バッチやイベント駆動の自動処理を組みやすい。
  • SAP試験では、「最小限の労力」や「既存の構成の変更が少ない」というキーワードに反応して、マネージドサービスや統合容易な構成を選ぶのがポイント。

次の問題も引き続きどうぞ。対応可能です。

以下、問題2の内容を指定の形式で整理・解説いたします。

■問題文（編集せずそのまま出力）

企業は、Amazon EC2 と AWS Lambda でアプリケーションを実行しています。アプリケーションは、Amazon S3 に一時データを保存します。S3 オブジェクトは 24 時間後に削除されます。

同社は、AWS CloudFormation スタックを起動して、アプリケーションの新しいバージョンをデプロイします。スタックは必要なリソースを作成します。新しいバージョンを検証した後、同社は古いスタックを削除します。古い開発スタックの削除が最近失敗しました。ソリューションアーキテクトは、アーキテクチャを大幅に変更せずにこの問題を解決する必要があります。

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

■選択肢（編集せずそのまま出力）

A. S3 バケットからオブジェクトを削除する Lambda 関数を作成します。S3 バケットリソースを指す DependsOn 属性を使用して、Lambda 関数を CloudFormation スタックのカスタムリソースとして追加します。

B. CloudFormation スタックを更新して、S3 バケットリソースの DeletionPolicy 属性に Snapshot の値を追加します。

C. CloudFormation テンプレートを更新して、Amazon S3 の代わりに一時ファイルを保存する Amazon Elastic File System (Amazon EFS) ファイルシステムを作成します。EFS ファイルシステムと同じ VPC で実行するように Lambda 関数を構成します。

D. CloudFormation スタックを変更して、Delete の値を持つ DeletionPolicy 属性を S3 バケットにアタッチします。

■問題文の要件の概要

  • EC2とLambdaで構成されたアプリケーションがS3に一時データを保存
  • CloudFormationによるデプロイと削除の運用
  • 古いスタックの削除がS3バケット内のオブジェクトの存在により失敗
  • アーキテクチャを大きく変更せず、この削除エラーを解決する必要あり

■正解の選択肢と解説

  • 正解：A CloudFormationのスタック削除時にS3バケット内にオブジェクトが残っていると、バケットが削除できずにスタック削除が失敗します。これを防ぐには、事前にオブジェクトを削除する処理が必要です。 適切な方法は、Lambda関数をカスタムリソースとしてテンプレートに追加し、DependsOnで実行順序を制御することです。Lambda関数がバケット削除の前に実行されることで、バケットが空になり削除が可能になります。

■不正解の選択肢の理由

  • B：DeletionPolicy: Snapshot は Amazon S3 に対しては無効。
    → Snapshot は RDSやEBSなどのスナップショット対応リソース専用。S3はサポート外。
  • C：S3 → EFS への変更は「アーキテクチャの大幅な変更」に該当。
    → コストや構成も変わるため、要件の「アーキテクチャ変更なし」に違反。
  • D：DeletionPolicy: Delete を設定しても、バケット内にオブジェクトが残っていれば削除できない。
    → CloudFormationはリソース削除を試みるが、中身があるバケットは削除不可。

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

  • CloudFormation での削除失敗の典型パターン：S3 バケットにオブジェクトが残っている
    • 明示的に削除処理を組み込む必要がある
  • DependsOn 属性
    • 明示的にリソースの作成／削除順序を指定できる。リソース間の依存を制御する
  • カスタムリソースと Lambda 関数の活用
    • リソース作成・削除に合わせた自動処理を組み込む際のベストプラクティス
  • DeletionPolicy の適用範囲
    • S3は Retain または Delete のみ。Snapshot は非対応

次の問題も続けてどうぞ。すぐ対応可能です。

以下、問題3の内容を指定の形式で整理・解説いたします。

■問題文（編集せずそのまま出力）

ある会社が、Amazon EC2 Auto Scaling グループへのアプリケーションの CI/CD に AWS CodePipeline を使用しています。すべての AWS リソースは、AWS CloudFormation テンプレートで定義されています。アプリケーションのアーティファクトは Amazon S3 バケットに保存され、インスタンスのユーザーデータスクリプトを使用して Auto Scaling グループにデプロイされています。アプリケーションがより複雑になるにつれて、最近の CloudFormation テンプレートのリソース変更により、計画外のダウンタイムが発生しました。

ソリューションアーキテクトは、テンプレートの変更によってダウンタイムが発生する可能性を減らすために、CI/CD パイプラインをどのように改善する必要がありますか ?

■選択肢（編集せずそのまま出力）

A. デプロイを実行する際に CloudFormation のエラー状態を検出して報告するように、デプロイスクリプトを適合させます。本番環境の変更を承認する前に、テストチームが開発環境で実行するためのテスト計画を作成します。

B. 統合開発環境 (IDE) のプラグインを使用してテンプレートのエラーを確認し、AWS CLI を使用してテンプレートが正しいことを検証します。デプロイコードを適合してエラー状態を確認し、エラーに関する通知を生成します。テスト環境にデプロイし、本番環境の変更を承認する前に手動のテスト計画を実行します。

C. AWS CodeDeploy と CloudFormation を使用したブルー / グリーンデプロイパターンを使用して、ユーザーデータのデプロイスクリプトを置き換えます。オペレーターに実行中のインスタンスにログインしてもらい、手動のテスト計画を実行して、アプリケーションが期待どおりに実行されていることを確認します。

D. テスト環境で AWS CodeBuild を使用した自動テストを実装します。CloudFormation の変更セットを使用して、デプロイ前の変更を評価します。AWS CodeDeploy を使用して、ブルー / グリーンデプロイパターンを活用して評価を行い、必要に応じて変更を元に戻すことができるようにします。

■問題文の要件の概要

  • EC2 Auto Scaling + CodePipeline による CI/CD 環境
  • CloudFormation テンプレートの変更により 計画外のダウンタイムが発生
  • アプリケーションの複雑化に対応する必要あり
  • ダウンタイムを減らせるような改善策が求められている

■正解の選択肢と解説

  • 正解：D この選択肢では以下の3つの重要な対策を組み合わせています：
    1. AWS CodeBuild による自動テストの導入
      → 本番適用前に機能検証を自動化し、ヒューマンエラーや手動遅延を排除。
    2. CloudFormation の変更セットの活用
      → テンプレートの変更内容によって何が起こるかを事前にプレビュー可能。
    3. AWS CodeDeploy を使ったブルー / グリーンデプロイ
      → 本番環境を置き換えずに新バージョンを検証し、必要なら簡単にロールバック可能。
    これらの手法により、ダウンタイムの最小化と安全な展開が可能になります。

■不正解の選択肢の理由

  • A：CloudFormation のエラー検知と手動テスト計画はあるが、自動テストやロールバック戦略がない。
    → 自動化不足かつ影響評価の仕組みがないため対応力が低い
  • B：IDE や CLI による静的検証＋手動テストのみ。
    → テンプレートエラーの事前検知には有効だが、環境影響や可用性に対する検証が不十分
  • C：ブルー / グリーン導入は良いが、手動テスト依存で自動化されていない。
    → CI/CDの自動化利点を活かしきれず、運用負担が増大

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

  • CloudFormation 変更セット：デプロイ前に影響を可視化できる強力なツール。破壊的変更を防ぐ。
  • ブルー / グリーンデプロイ（CodeDeploy）：新旧環境を並行稼働させ、切り替え前に検証＆ロールバック可能。
  • CodeBuild を使った自動テスト：CI/CD パイプラインの信頼性を高めるための基本。
  • 手動テストや通知だけでは対応が不十分 → SAPでは「信頼性・自動化・可用性の担保」が評価される。

次の問題もお送りいただければ、同じ形式で整理・解説します。お気軽にどうぞ。

以下、問題4の内容を指定の形式で整理・解説いたします。

■問題文（編集せずそのまま出力）

ある企業では、オンプレミスで長期にわたって分析プロセスを実行しています。現在のインフラストラクチャは、低レイテンシーの光ファイバーネットワークで接続され高性能サーバーのクラスターで構成されています。このインフラストラクチャは、ハードウェアの大幅なアップグレードが予定されており、大幅な予算増が必要となります。

同社は、分析プロセスを AWS に移行することを検討しています。

ソリューションアーキテクトは、オンプレミスのアーキテクチャを AWS にレプリケートするソリューションを推奨する必要があります。

これらの要件を最も費用対効果の高い方法で満たすソリューションを選択してください。

■選択肢（編集せずそのまま出力）

A. スポットインスタンスを持つパーティションプレイスメントグループの Amazon EC2 フリートを作成します。

B. リザーブドインスタンスを持つパーティションプレイスメントグループの Amazon EC2 フリートを作成します。

C. スポットインスタンスを持つクラスタープレイスメントグループの Amazon EC2 フリートが作成します。

D. リザーブドインスタンスを持つクラスタープレイスメントグループの Amazon EC2 フリートを作成します。

■問題文の要件の概要

  • 現在はオンプレミスの高性能サーバークラスター + 低レイテンシー光ファイバー通信
  • 長期的な分析処理を AWS に移行したい
  • ハードウェア更新コストの増加回避が目的
  • AWS上で同様の構成（高性能・低レイテンシー）を費用対効果よく実現する必要あり

■正解の選択肢と解説

  • 正解：D クラスタープレイスメントグループは、EC2インスタンスを物理的に近接したハードウェアに配置することで、低レイテンシーかつ高帯域幅の通信を実現します。これはオンプレミスの光ファイバー接続＋高性能クラスターの構成に最も近いです。 また、リザーブドインスタンスを活用することで、長期的な稼働に対して最大75%のコスト削減が見込め、費用対効果も高い選択となります。

■不正解の選択肢の理由

  • A：スポットインスタンス + パーティションプレイスメントグループ
    → スポットインスタンスは中断リスクあり。長期実行には不向き。パーティション型は耐障害性重視で低レイテンシー通信は得意でない。
  • B：リザーブドインスタンス + パーティションプレイスメントグループ
    → 安定稼働は可能だが、パーティションプレイスメントグループでは高速なノード間通信に向かないため、オンプレミスの構成要件を満たせない。
  • C：スポットインスタンス + クラスタープレイスメントグループ
    → ネットワーク性能は優れているが、スポットインスタンスの中断リスクがあり、分析処理の継続性を担保できない。

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

  • プレイスメントグループの種類と特徴
    • クラスタープレイスメントグループ：低レイテンシー・高スループットが必要なHPC（High Performance Computing）向け
    • パーティションプレイスメントグループ：高可用性・大規模分散システム向け（Hadoop、Kafkaなど）
    • スプレッドプレイスメントグループ：少数インスタンスのハードウェア分散による障害リスク低減
  • スポット vs リザーブドインスタンス
    • スポット：短期的でコスト重視。中断される可能性あり
    • リザーブド：長期使用前提で大幅割引。分析処理のような常時稼働に最適
  • 長期分析やHPCワークロードには「クラスタープレイスメント × リザーブド」の組み合わせがベストプラクティス

次の問題も続けて送ってください。引き続き整理して解説いたします。

以下、問題5の内容を指定の形式で整理・解説いたします。

■問題文（編集せずそのまま出力）

ある会社が AWS クラウドで大規模なコンテナ化されたワークロードを運用しています。約 100 の異なるサービスがこのタスクを構成しています。このワークロードは、Amazon Elastic Container Service (Amazon ECS) を使用して会社によって調整されています。

最近、同社の開発チームは、ECS クラスターで Amazon EC2 インスタンスから AWS Fargate に切り替えました。以前は、ワークロードがアカウントの EC2 インスタンスの最大数を使い果たす危険な状態にまで達していました。

この組織は、ワークロードが ECS ジョブの許容数を超えてしまうことを懸念しています。ソリューションアーキテクトは、Fargate が最大タスク容量の 80% を超えたときに開発チームに通知するソリューションを構築する必要があります。

この要件を満たす最適な方法を選択してください。

■選択肢（編集せずそのまま出力）

A. AWS Config ルールを作成して、Fargate SERVICE_QUOTA が 80 より大きいかどうかを評価します。AWS Config ルールが準拠していない場合、Amazon Simple Email Service (Amazon SES) を使用して、開発チームに通知します。

B. Amazon CloudWatch を使用して、ECS クラスターの各サービスのサンプルカウント統計値を監視します。サンプルカウント / SERVICE_QUOTA (service) *100 の数式が 80 より大きい場合のアラームを設定します。Amazon Simple Notification Service (Amazon SNS) を使用して、開発チームに通知します。

C. Amazon CloudWatch を使用して、AWS/Usage メトリクスネームスペースで公開されているサービスクォータを監視します。metric/SERVICE_QUOTA(metric) * 100 の数式が 80 より大きい場合のアラームを設定します。Amazon Simple Notification Service (Amazon SNS) を使用して開発チームに通知します。

D. AWS Lambda 関数を作成して、ECS クラスターから詳細なメトリクスをポーリングします。実行中の Fargate タスクの数が 80 を超える場合は、Amazon Simple Email Service (Amazon SES) を呼び出して開発チームに通知します。

■問題文の要件の概要

  • Fargate ベースの ECS ワークロードに移行済み
  • 約100サービスによる大量のタスク実行
  • Fargate の サービスクォータ上限 に近づいていることを監視したい
  • 上限の80%を超えた時点で通知する仕組みが必要

■正解の選択肢と解説

  • 正解：C Amazon CloudWatch + AWS/Usage メトリクス名前空間を使うことで、Fargate タスク数が 割り当て上限（Service Quota）に対してどれくらい使われているかを割合で計測できます。 metric / SERVICE_QUOTA(metric) * 100 > 80 という数式で、80%超過をトリガーとするアラームを設定し、Amazon SNS を使って通知を送れば、要件を満たす監視が実現できます。 この方法は マネージドでオーバーヘッドが小さく、リアルタイムに近い通知が可能なベストプラクティスです。

■不正解の選択肢の理由

  • A：AWS Config は構成変更のコンプライアンスチェック用であり、リソースの動的使用量のしきい値監視には不向き。
    → SERVICE_QUOTAの超過をConfigルールで監視する仕組みはそもそも存在しない。
  • B：ECS サービスのサンプルカウント統計値はタスク数の割合を測る正確な手段ではない。
    → SERVICE_QUOTAと無関係なメトリクスに基づいたアラートは信頼性に欠ける。
  • D：Lambda によるポーリングは実装負荷・コスト・保守性の面で非効率。
    → CloudWatch に標準機能があるのに、カスタム監視を構築するのは非推奨。

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

  • AWS/Usage 名前空間は、CloudWatch でサービスクォータの利用状況を可視化できる重要なメトリクス群。
  • CloudWatch アラーム × SNS 通知は、リソース使用量のしきい値監視と通知を行う標準的かつ推奨される方法。
  • AWS Configは構成準拠や変更追跡向けで、動的使用量監視とは目的が異なる。
  • Fargateは「EC2ベースの容量制限」を回避できるが、**Fargateのタスク上限（クォータ）**には注意が必要。
  • SAPでは運用の自動化・アラートの仕組み・効率的なモニタリング設計を評価される。

次の問題もあれば、続けて送ってください。引き続きこの形式で整理します。

以下、問題6の内容を指定の形式で整理・解説いたします。

■問題文（編集せずそのまま出力）

あるエンターテイメント企業が、Auto Scaling グループ内にある一連の Linux Amazon EC2 インスタンスでチケット販売サービスをホストしています。チケット販売サービスでは、料金ファイルを使用します。料金ファイルは、S3 標準ストレージを持つ Amazon S3 バケットに保存されます。サードパーティがホストする中央料金ソリューションが料金ファイルを更新します。

料金ファイルは 1 ～ 15 分ごとに更新され、数千の明細項目があります。料金ファイルは、インスタンスの起動時に各 EC2 インスタンスにダウンロードされます。

EC2 インスタンスでは、古い料金情報が使用されることがあり、お客様への請求額が間違っている可能性があります。

この問題を最もコスト効率よく解決できるソリューションを選択してください。

■選択肢（編集せずそのまま出力）

A. 料金ファイルが更新されるたびに Amazon DynamoDB のテーブルを新しい料金で更新する AWS Lambda 関数を作成します。料金の検索に DynramoDB を使用するようにチケット販売サービスを更新します。

B. Amazon Elastic Block Store (Amazon EBS) ボリュームを作成します。EBS マルチアタッチを使用して、ボリュームをすべての EC2 インスタンスにアタッチします。新しい EC2 インスタンスが起動したら、新しいインスタンスを設定して、EBS ボリューム上の料金ファイルを更新します。チケット販売サービスを更新して、新しいローカルソースを指します。

C. Amazon Elastic File System (Amazon EFS) ファイル共有が更新されるたびに、料金ファイルを更新する AWS Lambda 関数を作成します。チケット販売サービスを更新して、Amazon EFS を使用して料金ファイルにアクセスします。

D. EC2 インスタンスの AMI に Mountpoint for Amazon S3 をロードします。料金ファイルを含む S3 バケットをマウントするように、Mountpoint for Amazon S3 を設定します。S3 オブジェクトにアクセスするためのマウントポイントとパスを指すようにチケット販売サービスを更新します。

■問題文の要件の概要

  • チケット販売サービスは EC2 インスタンス群で稼働（Auto Scalingあり）
  • 料金ファイルはS3上にあり、1〜15分ごとに更新される
  • 現状はインスタンス起動時に料金ファイルをダウンロード → 古いファイルが使われる問題あり
  • 最新の料金ファイルをコスト効率よく一貫して使えるようにしたい

■正解の選択肢と解説

  • 正解：D Mountpoint for Amazon S3 を使えば、S3 バケットをローカルファイルシステムとしてマウントでき、ファイルの都度ダウンロードなしに常に最新の料金ファイルを参照できます。これは：
    • Auto Scaling 環境でもインスタンス追加時に最新ファイルへ即アクセス可能
    • 定期ダウンロードやファイルコピーの手間が不要
    • S3の耐久性・可用性・コストメリットをそのまま享受できる
    という理由から、最も運用効率・コスト効率に優れた選択肢です。

■不正解の選択肢の理由

  • A：Lambda で DynamoDB を更新し、サービス側を DynamoDB 経由に変更
    → アプリの大幅な改修が必要。Lambda 実行・DynamoDB の更新・読み出しコストも継続発生し、費用・構成ともにオーバーキル。
  • B：EBS マルチアタッチを全インスタンスに適用
    → EBS マルチアタッチは用途・リージョン制限があり、Linux 限定かつ最大16台程度。更新管理も複雑でスケーラビリティに欠け、Auto Scaling向きでない。
  • C：EFS + Lambda 経由で料金ファイル更新
    → EFS の費用が高く、Lambda による更新処理も冗長。S3 + Mountpoint という軽量構成で十分であり、無駄に複雑化している。

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

  • Mountpoint for Amazon S3
    • Amazon S3 バケットをファイルシステムとして扱える新しいソリューション（2023年正式リリース）
    • 高スループット・読み取り専用だが、更新頻度の高い読み込みファイルに最適
    • Auto Scaling 環境やインスタンス横断でファイルの一貫性を保つ用途に強力
  • 共有ファイル参照方式の選定
    • EFS：高コスト・高性能・POSIX完全準拠（ただしオーバースペックになりがち）
    • EBS：ブロックストレージ。マルチアタッチ制限多数、Auto Scalingに不向き
    • S3：耐久性・可用性・コストで優れ、Mountpoint導入で動的参照が可能に
  • アプリ改修の有無・運用コストの抑制も設計判断の一要素として評価される

次の問題も続けてどうぞ。すべてこの形式で整理いたします。

以下、問題7の内容を指定の形式で整理・解説いたします。

■問題文（編集せずそのまま出力）

ある企業は、湿度や照度などの環境パラメータに関する情報を収集するセンサーを、自社のすべての工場に取り付けています。同社は、AWS クラウドでデータをリアルタイムにストリーミングし、分析する必要があります。いずれかのパラメータが許容範囲から外れた場合、工場の運用チームはすぐに通知を受け取る必要があります。

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

■選択肢（編集せずそのまま出力）

A. Amazon Managed Streaming for Apache Kafka (Amazon MSK) クラスターにデータをストリーミングします。Amazon MSK でトリガーを設定して、AWS Fargate タスクを呼び出してデータを分析します。Amazon Simple Email Service (Amazon SES) を使用して、運用チームに通知します。

B. Amazon Kinesis Data Firehose 配信ストリームにデータをストリーミングします。AWS Step Functions を使用して、Kinesis Data Firehose 配信ストリームのデータを消費して分析します。Amazon Simple Notification Service (Amazon SNS) を使用して、運用チームに通知します。

C. Amazon Kinesis Data Streams にデータをストリーミングします。Kinesis Data Streams を消費し、データを分析するために AWS Lambda 関数を作成します。Amazon Simple Notification Service (Amazon SNS) を使用して、運用チームに通知します。

D. Amazon Managed Service for Apache Flink アプリケーションにデータをストリーミングします。Amazon Elastic Container Service (Amazon ECS) で自動的にスケーリングされコンテナ化されたサービスを使用して、データを消費して分析します。Amazon Simple Email Service (Amazon SES) を使用して、運用チームに通知します。

■問題文の要件の概要

  • 工場に配置されたセンサーからリアルタイムでデータを収集
  • 湿度・照度などが許容範囲を外れたら即時通知
  • 分析と通知は低遅延で行う必要がある
  • スケーラブルで運用負荷の低いアーキテクチャが望ましい

■正解の選択肢と解説

  • 正解：C Amazon Kinesis Data Streams + AWS Lambda + Amazon SNS は、リアルタイムのストリーミング分析と即時通知を組み合わせる構成として最適です。
    • Kinesis Data Streams がセンサーデータをリアルタイムに取り込み
    • Lambda が各レコードをトリガーとして処理し、しきい値を超えたかを即時評価
    • 条件を満たす場合、SNS を使って運用チームに即通知
    この構成はサーバーレス・マネージドであり、コスト効率・運用効率・リアルタイム性をすべて兼ね備えたベストプラクティスです。

■不正解の選択肢の理由

  • A：MSK + Fargate + SES
    → Kafka（MSK）や Fargate は構成が複雑でオーバーヘッドが高く、リアルタイム性や即時通知には向かない。
  • B：Kinesis Firehose + Step Functions + SNS
    → Firehose は主に バッチ処理・ストレージ連携向けであり、リアルタイム処理には適さない。さらに Step Functions を挟むことで通知遅延が生じる。
  • D：Apache Flink + ECS + SES
    → Flink は強力なストリーム処理基盤だが、複雑なセットアップと学習コストがあり、通知用途に対して過剰設計。SES もリアルタイム通知には不向き。

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

  • Kinesis Data Streams はリアルタイムストリーミングデータの収集・処理に最適。
  • AWS Lambda は Kinesis ストリームからのイベントトリガーを通じてデータを即時分析できる。
  • Amazon SNS は通知の自動化・即時配信における定番ソリューション。
  • リアルタイム分析には Firehose や Step Functions ではなく、Data Streams + Lambda の構成が基本。
  • SAP 試験では「過剰設計になっていないか、最小の構成で最大の効果を出せているか」が常に問われる。

次の問題も引き続き、同様の形式でお任せください。

RELATED POST