IoTデータプラットフォームの構築

IoT機器から収集したデータを一元集約し、分析・活用を可能にするプラットフォームを構築

プロジェクト概要

情報通信業の大手企業(連結従業員数 約10万人、東証プライム上場)が保有するIoT機器群のデータを一元集約し、分析・活用を可能にするプラットフォームの構築を支援しました。2024年8月のプロジェクト開始から同年11月のPoC(概念実証)まで、約3ヶ月という短期間でIoTデータの収集から可視化まで一貫して動作するプロトタイプをデリバリーしました。

アーキテクチャの設計においては、将来的な500万台規模・約2.8万件/秒のデータ処理を見据え、AWS IoT CoreとKubernetesを組み合わせたマイクロサービス構成を採用しました。また、FIWARE・PostgreSQL・Keycloakなどのオープンソース技術を中心に据えることで、コア部分のクラウドプロバイダー非依存率95%以上を目標とした可搬性の高いアーキテクチャを実現しました。

地球規模のデータネットワークのイメージ
95%以上
クラウド非依存率(設計目標)
500万台
IoTデバイス規模(設計想定)
秒間2.8万件
データ処理能力(設計想定)

課題

プロジェクト開始時に整理した技術・スケジュール上の論点

短期間でのPoC向けプロトタイプ構築

2024年8月にプロジェクトが開始されたが、同年11月のPoCに間に合わせる必要があった。それまでにIoTデータの一元収集と、収集データを可視化するサンプルアプリを動く状態で用意しなければならなかった。

大規模データと突発負荷へのスケーラビリティ

中継器・IoT機器から大量のデータが送られてくる想定のため、突発的な負荷にも耐えうるスケーラビリティの担保が求められた。マイクロサービスアーキテクチャの採用と、オートスケーリングの実装が必要だった。

クラウド環境のポータビリティ

特定のクラウドプロバイダーに依存しないアーキテクチャが求められた。将来的なクラウド移行やマルチクラウド運用に備え、コア部分のクラウドプロバイダー非依存性を確保する必要があった。

解決策

大規模体制・スケーラブルアーキテクチャ・OSSスタックによる段階的アプローチ

1

短期PoCに向けた大規模プロジェクト体制の編成

3ヶ月という短納期に対応するため、PM・PL・アプリTL・インフラTLの4層構造を軸に最大15名のプロジェクトチームを編成。各リーダーが緊密に連携しながら、採用技術の検証と実装を並行して進めた。お客様とは打ち合わせやチャットを含め頻回にやり取りし、アーキテクトの工数を手厚く確保することで、短期間でのデリバリーを実現した。

  • PM主導のもと、PL・アプリTL・インフラTLが各領域を並走
  • 技術検証と実装を同時並行で推進し、手戻りを最小化
  • 顧客との頻回コミュニケーションで仕様を迅速に確定
2

AWS IoT Core と Kubernetes による大規模スケーラビリティの実現

1,000台の中継器・その先にある500万台のIoT機器からのデータ(最大約2.8万件/秒)という高負荷に耐えるアーキテクチャを設計した。最もトラフィックが集中するMQTTS接続の受け口には AWS IoT Core を採用し、フルマネージドで信頼性の高いメッセージ処理を実現。後段の各サービスはマイクロサービスアーキテクチャで分割し、Kubernetes 上で稼働させることでサービス単位でのオートスケーリングを可能にした。特定サービスへの負荷集中にも局所的にスケールアウトで対応できる構成とし、システム全体のリソース効率と可用性を両立した。

  • AWS IoT Core で1,000台規模のMQTTS接続を安定処理(フルマネージド)
  • マイクロサービス分割により、ボトルネック箇所のみをピンポイントでスケールアウト
  • Kubernetes のオートスケーリングで約2.8万件/秒の突発負荷に対応
3

OSSスタックと Kubernetes によるクラウドポータビリティの確保

コア部分のクラウド非依存性を高めるため、FIWARE Orion・Cygnus・IoT Agent をはじめ、PostgreSQL・Keycloak・Grafana・Next.js・NestJS といったオープンソース技術を中心に採用。これらをすべて Kubernetes 上で稼働させることで、特定クラウドへのロックインを回避した。さらにインフラ構成は Terraform でコード化し、GitHub Actions(self-hosted runner)と組み合わせることでデプロイを自動化。環境の再現性を確保しつつ、将来的なクラウド移行や環境複製にも最小限の変更で対応できる構成とした。

  • OSSを中心とした技術選定でクラウド非依存性を確保
  • Terraform によるIaCでインフラをコード管理し、環境の再現性を実現
  • GitHub Actions(self-hosted runner)+ Terraform でデプロイを自動化し、運用コストを最小化

導入成果

短期デリバリーと将来を見据えたアーキテクチャ設計の成果

約3ヶ月で
プラットフォーム全体のデモを実施

最大15名体制のプロジェクトチームを編成し、技術検証と実装を並行して進めることで、8月開始から約3ヶ月という短期間でプラットフォーム一通りのデモを実施。IoTデータの一元収集から可視化まで、構築した機能を11月に網羅的に披露することができた。

大規模IoTデータに耐えうる
スケーラブルなアーキテクチャを設計

1,000台の中継器・500万台のIoT機器から送られる約2.8万件/秒のデータを処理できるアーキテクチャを設計した。AWS IoT Core によるMQTTS接続の安定処理と、Kubernetes によるマイクロサービスのオートスケーリングを組み合わせ、突発的な負荷にも対応できる構成を設計した。

クラウドプロバイダー非依存率
95%以上のアーキテクチャを設計

FIWARE・PostgreSQL・Keycloak・Grafana・Next.js・NestJS など、OSSを中心とした技術選定により、コア部分のクラウドプロバイダー非依存率95%以上を目標としたアーキテクチャを設計。将来的なクラウド移行や環境複製にも最小限の変更で対応できる基盤を整えた。

Terraform + GitHub Actions による
デプロイ自動化で運用負荷を低減

インフラ構成をTerraformでコード管理し、GitHub Actions(self-hosted runner)と連携させることでデプロイを自動化。属人化を排除し、環境の再現性と運用コストの最小化を同時に実現した。

使用技術

本プロジェクトで使用した技術スタック

AWS

AWS IoT Core

Kubernetes

Terraform

GitHub Actions

FIWARE Orion

FIWARE Cygnus

FIWARE IoT Agent

PostgreSQL

Keycloak

Grafana

Next.js

NestJS

MQTTS

同様の課題をお持ちですか?

まずは無料相談から。お客様の課題を伺い、最適なソリューションをご提案いたします。