オンプレミス Kafka を置き換える MQTT データ収集基盤
スマート農業サービスを提供する企業は、全国の圃場に設置した約 15,000 台の土壌センサーから MQTT (Message Queuing Telemetry Transport) プロトコルで計測値を収集しています。現在はデータセンターに置いた Apache Kafka サーバーがデータを受け取り、Kafka に接続された別のプロセスが変換処理を行って結果を Amazon S3 バケットにオブジェクトとして保存しています。先日 Kafka サーバーに障害が発生し、復旧作業を行っていた数時間の間に届いたセンサーデータが失われました。ソリューションアーキテクトは、同じ事態を繰り返さないために、可用性と拡張性に優れた新しい設計を AWS 上に構築する必要があります。運用上のオーバーヘッドが最も少なく、これらの要件を満たすソリューションはどれですか。
解説を読む（正解: B）
AWS IoT Core は MQTT を標準でサポートするフルマネージドのデバイス接続サービスで、リージョン内で自動的に冗長化・スケールし、数万台規模のデバイスからのメッセージを受け付けられます。ルールエンジンを使うと、受信したメッセージを SQL ライクな条件で選別し、Kinesis Data Firehose をはじめとする各種 AWS サービスへ直接ルーティングできます。Amazon Kinesis Data Firehose もまたサーバーレスの配信ストリームで、AWS Lambda による変換処理を組み込んだうえでバッファリングし、Amazon S3 へ自動的に書き出します。この組み合わせは、センサー側のプロトコルを変えずに、管理すべきサーバーをゼロにしたまま可用性と拡張性を確保できるため、運用オーバーヘッドが最小という要件に最も合致します。AWS IoT Core と EC2 上の Kafka を組み合わせる案は、結局 Kafka サーバーを自前で運用し続けることになり、単一インスタンスであれば障害の再発リスクもそのまま残ります。Amazon MSK へ移行する案は Kafka の運用負荷を下げますが、クラスターのサイジングやトピック運用は残り、加えて MSK は MQTT を話さないためセンサーからそのまま接続できず、Network Load Balancer を挟んでもプロトコル変換を担う仕組みが存在しません。EC2 2 台のアクティブ/スタンバイ構成と Route 53 フェイルオーバーを使う案は、Kafka のインストール・パッチ適用・レプリケーション設計をすべて自社で抱えることになり運用負荷が最大です。さらに DNS フェイルオーバーは切り替わりまでに TTL 分の遅延が生じるため、その間のセンサーデータは同じように失われます。
IoT センサーデータの低コストな S3 取り込みパイプライン
農業テック企業が、全国の圃場に設置した数千台の土壌センサーからのデータを収集する基盤を構築しています。デバイスは AWS IoT Core にデータを送信し、最終的には Amazon S3 上のデータレイクに蓄積します。S3 に格納する前に、各レコードへ圃場マスタと気象情報を突き合わせた属性を付与する必要があります。センサーは 10 秒間隔で送信し、収集から 45 分以内に S3 で参照できれば業務要件を満たします。AWS IoT Core に届いたデータを購読して処理している他のアプリケーションは存在しません。この要件を最もコスト効率よく満たすソリューションはどれですか。
解説を読む（正解: D）
AWS IoT Core の課金は、接続、メッセージング (パブリッシュ/サブスクライブ)、ルールエンジンの評価などに分かれています。ルールにしか流さず、他のサブスクライバーが存在しない場合は Basic Ingest を使うことで、パブリッシュ/サブスクライブのメッセージング料金を発生させずに直接ルールへデータを送れるため、取り込み段階のコストを大きく削減できます。さらに、10 秒間隔の小さなレコードを 1 件ずつ Lambda で処理して S3 に書くと、Lambda の呼び出し回数と S3 の PUT リクエスト数がそのままコストになり、大量の小さなオブジェクトも生成されます。正解の選択肢は、ルールアクションから Amazon Data Firehose へ流し、バッファリング間隔を 900 秒 (15 分) に設定してレコードをまとめ、Firehose のデータ変換機能で Lambda をバッチ単位で呼び出して拡充し、S3 へ配信します。バッファ時間を含めても 45 分の鮮度要件に十分収まり、呼び出し回数と PUT 回数を大幅に削減できます。1 件ごとに Lambda を起動して S3 に書く選択肢は、機能的には動作しますが呼び出し回数とリクエスト数が最大になりコスト効率で劣ります。Timestream を経由する選択肢は、S3 に格納するだけの用途に時系列データベースの書き込み・保存・クエリ費用が上乗せされ、実装も複雑になるため不適切です。Kinesis Data Streams を使う選択肢は、シャードの時間課金が常時発生し、コンシューマー Lambda が個別に PutObject を呼ぶため、Firehose のフルマネージドなバッファリングと比べてコストと運用負荷の両面で不利です。
IoT テレメトリのリアルタイム取り込みと可視化基盤の選択
洋上風力発電を運営する事業者が、各風車に取り付けた振動・温度・回転数センサーからテレメトリを収集する基盤を AWS に構築します。データはセンサーの世代によって項目が異なる JSON で、1 件あたり数 KB と小さいものの、風車の台数増加に応じて流量が伸び続けます。要件は、(1) 異常の予兆を捉えるため取り込みからダッシュボード表示までの遅延を秒未満に抑えること、(2) リアルタイム異常検知と可視化という 2 つの独立した処理が同じデータを同時に読み取れること、(3) 障害調査のため直近 24 時間分のデータを何度でも再読み取り (リプレイ) できること、(4) 取り込んだデータを即座に全文検索・集計できることです。最も適した構成はどれですか。
解説を読む（正解: B）
ストリーミング基盤を選ぶときは、配信サービス (デリバリーストリーム) と本来のストリームの違いを理解しておく必要があります。Amazon Data Firehose はバッファサイズまたはバッファ間隔の条件が満たされてから宛先へまとめて配信する仕組みで、OpenSearch 宛てのバッファ間隔は既定で 60 秒から設定します。またデータを保持しないためリプレイができず、同じデータを複数の独立したアプリケーションが個別のペースで読むこともできません。一方 Amazon Kinesis Data Streams はシャードにレコードを保持する真のストリームで、書き込み後ほぼ即座にコンシューマーが読み取れるため秒未満の遅延要件に適合します。保持期間内であれば任意のシーケンス番号から何度でも再読み取りでき、異常検知と OpenSearch への取り込みという 2 つのコンシューマーがそれぞれ独立したチェックポイントで同じストリームを読めます。取り込み先の OpenSearch Service は動的マッピングにより項目が変わる JSON を扱え、OpenSearch Dashboards で即座に検索・可視化できます。よって B が要件をすべて満たします。A は構成としては単純ですが、バッファリングによる遅延、リプレイ不可、コンシューマーのファンアウト不可という 3 つの要件違反があります。C は Greengrass と MSK、EMR 上の Flink を自前で運用する重厚な構成で運用負荷が高く、DocumentDB は時系列テレメトリの全文検索・可視化に最適とは言えません。D は API Gateway と Step Functions によるリクエスト単位のオーケストレーションで高スループットのストリーミングには不向きであり、Neptune は関係性を扱うグラフデータベースでセンサー時系列の分析用途に合致しません。