無限ノック › SAP 練習問題一覧 › 問題
SAP新しいソリューションのための設計複数選択

製造業の大企業が、世界15カ国の工場からIoTデータを収集・分析する新しいプラットフォームを構築しています。現在の状況と要件は以下の通りです: 【現在の状況】 ・各工場にオンプレミスのSCADA(Supervisory Control and Data Acquisition:監視制御・データ収集システム)システムが存在 ・工場ごとに10,000〜50,000台のセンサーが稼働 ・センサーデータは1秒間隔で送信(1センサーあたり約200バイト) ・一部の工場ではインターネット接続が不安定(帯域幅1Mbps未満、断続的な切断) ・工場ネットワークは厳格なファイアウォールルールで管理されており、インバウンド接続は一切許可されていない 【要件】 ・エッジでのリアルタイム異常検知(レイテンシ1秒以内) ・クラウドへのデータ収集と長期保存(7年間) ・工場ごとのデータは当該工場が所在する国のクラウドリージョンに保存(データ主権要件) ・工場のネットワーク障害時も最低24時間分のローカルバッファリングが必要 ・機械学習モデルのデプロイと更新をエッジデバイスに対してリモートで実施 ・エッジデバイスのフリート管理(設定、パッチ適用、監視)を一元化 どのアーキテクチャがこれらの要件を最もよく満たしますか?(2つ選択)

A
AWS IoT Greengrassをエッジコンピューティングプラットフォームとして各工場に展開する。Greengrass CoreデバイスがSCADAシステムからデータを収集し、エッジでLambda関数を実行して異常検知を行う。クラウドへのデータ転送にはAWS IoT Core(MQTT over TLS)を使用し、各国のリージョンエンドポイントに接続する。ネットワーク障害時はGreengrassのローカルメッセージブローカーがデータをバッファリングし、接続回復後に自動送信する。ML(機械学習)モデルのデプロイはGreengrass ML Inference(SageMakerとの統合)で実施する。フリート管理はAWS Systems Manager(Fleet Manager)とAWS IoT Device Managementを組み合わせて使用する。
✓ 正解
AWS IoT Greengrassをエッジコアとして採用することで、アウトバウンドのみのMQTT接続でインバウンド不可要件を満たし、ローカルメッセージブローカーによる24時間以上のバッファリングとエッジLambdaによる1秒以内の異常検知が実現できます。
B
AWS Outpostsを各工場に設置し、工場内でAWSサービスをフルに実行する。Amazon Kinesis Data Streamsをエッジで実行して高スループットデータ収集を行い、AWS Lambdaで異常検知ロジックを実行する。データはOutposts上のAmazon S3(S3 on Outposts)にバッファリングし、AWS Direct Connect経由でクラウドに同期する。ML(機械学習)モデルはAmazon SageMaker(Outposts対応)でデプロイし、フリート管理はAWS Systems Managerで実施する。各国のデータ主権要件は対応するAWSリージョンへのOutpostsからのレプリケーションで対応する。
AWS Outpostsは工場レベルに設置する大型ハードウェアであり、設置コストが数百万ドル規模となるため15工場への展開は現実的ではなく、IoTエッジ処理の用途にも適していません。
C
AWS IoT SiteWiseをSCADAデータ収集のゲートウェイとして使用し、IoT SiteWise Edgeを各工場に展開する。SiteWise EdgeはOPC-UA(OPC Unified Architecture:産業機器向け通信プロトコル)などの産業プロトコルでSCADAシステムに接続し、エッジでのデータ変換・集約・異常検知を実行する。収集データはAWS IoT SiteWise(クラウド)に送信し、各国リージョンのAmazon S3にエクスポートする。ネットワーク障害時のバッファリングはSiteWise Edgeのローカルストレージで対応する。フリート管理とMLモデルデプロイはAWS IoT Greengrassと統合したSiteWise Edgeコンポーネントで実施する。
AWS IoT SiteWise EdgeはOPC-UA等の産業プロトコルでSCADA統合に有利ですが、フリート管理やMLモデルデプロイにGreengrassとの統合が前提となるため、単独での要件充足は不完全です。
D
Amazon Data Firehoseをクラウド側の収集エンドポイントとして使用し、各工場のSCADAシステムから直接Data Firehoseにデータを送信する。エッジの異常検知はAWS Lambda@Edgeを使用してCloudFrontのエッジロケーションで実行する。ネットワーク障害時のバッファリングはオンプレミスのApache Kafkaクラスターで対応する。MLモデルのデプロイはAWS CodePipeline + AWS CodeDeployを使用してKafkaコンシューマーアプリケーションを更新することで実施する。データ主権要件はData Firehoseのリージョン別エンドポイントで対応する。
Lambda@EdgeはHTTPリクエスト処理向けのサービスであり、IoTエッジデバイスでのリアルタイム異常検知には設計されていません。Kafkaのオンプレミス構築も複雑性とコストを増大させます。
E
AWS IoT CoreとAWS IoT Device Shadowを使用してデバイス状態管理を行い、各工場のゲートウェイデバイスからMQTT(Message Queuing Telemetry Transport:軽量メッセージングプロトコル)でデータを送信する。エッジ処理はAWS IoT GreengrassのMLコンポーネント(Amazon SageMaker NeoでコンパイルしたモデルをGreengrassコンポーネントとして配布)でエッジでのML推論と異常検知を1秒以内で実行する。データはAWS IoT Coreのルールエンジンでリージョン別のAmazon Kinesis Data Streamsに転送し、AWS Lambdaで処理後に各国リージョンのAmazon S3に保存する。フリート管理はAWS IoT Device Management(Jobs、Fleet Indexing、Tunneling)で一元管理し、MLモデル更新はSageMaker NeoコンパイルモデルをGreengrassコンポーネントデプロイメントとしてOTA(Over-the-Air:無線経由のリモート更新)で自動化する。ネットワーク障害時のバッファリングはIoT Greengrassのストリームマネージャーで24時間分以上対応する。
✓ 正解
AWS IoT CoreのルールエンジンとGreengrassのMLコンポーネントでSageMaker Neoモデルをエッジ推論でき、ストリームマネージャーで24時間以上のバッファリング、IoT Device ManagementのJobsでOTAモデル更新と一元フリート管理が可能です。

解説

選択肢AとEは共にAWS IoT Greengrassをエッジコアとして採用し、アウトバウンドのみの接続(インバウンド不可要件を満たす)、Greengrassストリームマネージャーによる24時間以上のローカルバッファリング、エッジML推論(1秒以内)、リモートフリート管理をすべてカバーします。 選択肢BのOutpostsは工場単位の設置コストが数百万ドル規模となり非現実的です。 選択肢CのSiteWise EdgeはOPC-UA対応でSCADA統合に有利ですが、フリート管理とMLデプロイ機能がGreengrass統合前提となるため単独では不完全です。 選択肢DのLambda@EdgeはIoTエッジ処理には設計されておらず、Kafkaのオンプレミス別途構築が複雑性を増大させます。

ドメイン別正答率・予想スコアでリアルタイムに実力把握

無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。

無料で演習を始める →
← SAP の問題一覧に戻る