サクッとIoTシステムを構築する

こんにちは！

aptpod Advent Calendar 2023 12月15日担当サーバーサイドエンジニアの宮内です。

普段はサーバーアプリケーションを実装しているのですが、今日はフロントエンドのUI含んだintdashシステム全体の構築方法について書こうと思います。どれだけ簡単に構築のできるかという点をお伝えしていきます。

リリース前の情報なので、現状でお伝えできる範囲内での内容となります。

背景編
構築編
まとめ

背景編

実際の構築に入る前に今から構築しようとしているIoTシステムである「intdash」について簡単におさらいしていきます。

intdashシステムとは

intdashシステムを構築する前に簡単にintdashとその周辺についておさらいしておきます。

IoTシステムを作ろうとすると、考えなければならないことがいろいろあると思います。例えば

どうやってデバイスからのデータを伝送するか
サーバーソフトウェアはどう構成するか
どこにデータを保存するか
保存したデータをどう活用するか
デバイスの管理をどうするか
etc...

などなどです。一つひとつ検討し、さらに構築していくのは骨の折れる作業です。大手クラウドベンダのサービスを組み合わせればそれぞれの要求に応じたIoTシステムを構築することが可能ですが、そのためには高い経験値やそれなりにノウハウが必要で容易なことではありません。

intdashとは前述のような一般的なIoTシステムで必要とされる、データの伝送、収集、連携などのユースケースに対応したワンストップソリューションです。通常のIoTデータ伝送にももちろん使用可能ですが、intdashが特にその真価を発揮するのは、一つのデバイスから送信するデータが秒間、数百や数千といった大量データでかつ複数データソース時刻同期が必要なユースケースです。また、intdashは独自のプロトコルにより帯域の細いモバイル回線でも確実にデータ収集を行い、かつレイテンシを低く抑えリアルタイムにデータ伝送が可能です。

intdashの詳細は是非 https://www.aptpod.co.jp/products/software/intdash/ のページから参照ください。

intdashの課題

2023年12月現在、intdashを利用するには基本的には弊社がクラウド上に構築運用している環境を利用してもらう必要があります。いわゆるサービスとしての利用がメインストリーム*1です。これまでのブログでもintdashの紹介はありましたが、実際にintdashを試す場合は弊社と契約を結んだあと、弊社で環境を構築し弊社のクラウドに構築されたintdashを使用するという流れになります。

一方で、クラウドベースのサービス展開のみだと事業的なスケールが難しく実行環境をより自由にする必要がありました。これは、intdashがあくまでもミドルウェアであり、独自のIoTプラットフォームの構築やクローズドな社内システム構築などといったユースケースに対応する必要があることに起因します。一般的なデータベースなどと思想は近く、独自のプラットフォームや社内システムを構築できるようにするには、サービス提供にとどまらずプロダクトのポータビリティよくすることは必要不可欠です。

例えば、独自のデータセンターであったり、もっとカジュアルな自前で用意したサーバーなどにも構築することが想定されます。時には開発者のローカル環境に構築するユースケースも考えられます。

そこでこれまでのサービス利用に加え、オンプレミスや手元のローカル環境でも実行できるポータビリティの高いプロダクト提供方法の検討と整備をしていました。結構前から始めていたのですが、ようやく運用ノウハウも少しずつ溜まってきており、提供に必要な情報もまとまってきて、近日中に公開できるところまで来ています。

本記事の主題

前述の通りIoTシステムを構築するには容易ではありません。 intdashも単純ではなく、下図のような複数のコンポーネントで構成されています。

構成は決まっているので、０から考えるよりはいくらかましですが、それでも構築は大変な作業であることには変わりありません。

図中の

intdashのコア機能を提供するAPI（intdash Core Services）
intdash環境管理のためのWebインターフェイス（intdash Web Console）
多彩なデータ可視化を実現するWebダッシュボード（Visual M2M Data Visualizer）

に加えて、図では表現されていませんが、データベースなどの各種ミドルウェア群をサクッと構築していきましょう！というのが今回の記事の主旨です。

つまり、この記事を読んだあとには、

手元で簡単にintdashを構築できる！
適当な物理サーバーにintdashを構築できる！
自社AWSアカウント上にintdashを構築できる！

といった内容をより具体的にイメージ出来るようになります。

以降、具体的にどんな環境へどんな手順でデプロイができるかという点を少しだけ紹介します。すごく簡単に構築できる！といったところを体感していただけたら幸いです。

構築編

提供物について

一体どんなものがどういった形態で提供されるのか説明します。現状は次のようなものを提供する予定です。

ライセンス（システム構築には製品のアクティベーションが必要です）
プロダクト（コンテナイメージ/RPMパッケージ）
構築運用ガイド
構築を補助するスクリプト類

プロダクトの提供はコンテナとRPMパッケージの２つの提供を目指しています。実行環境や要求に合わせていずれかの方法が選択可能です。

構築可能な環境

基本的にはいくつか前提となる条件はありますが、その条件を満たせば任意の環境でintdashシステムを構築することができます。例えば次のような環境です。

AWS EKS
Kubernetes(EKS以外)
Docker Compose
オンプレミスの物理サーバー
IaaS(EC2など)

提供までのワークフロー

こちらについては未整備な部分もありますが、基本的には次のような流れになります。

ライセンスを購入します。
構築運用ガイド参照し、任意の場所に構築します。

ライセンス購入し、構築ガイドを参照すれば誰でもどこでも構築が可能というわけですね。現状、少しだけ利用までの敷居が高いので、将来的にはもっとシンプルに商品を提供できるような販売チャネルも検討中です。

構築

RPMとコンテナによる構築方法がありますが、今回はコンテナによる構築方法をご紹介します。

intdashは複数のAPIサーバーアプリケーションやフロントUI、データベースなどの各種ミドルウェアで構成されています。ですから、現状は単一イメージの提供ではなく、アプリケーションごとのコンテナイメージとその構成ファイル（docker-composeやHelmチャートなどのことを指しています）を使用して構築する必要があります。もちろんアプリケーションごとのコンテナイメージを組み合わせて独自にマニフェストなどを作成し、intdashシステムを構築することも可能ですが、かなり面倒なのであまり現実的ではありません。今回はdocker-composeによる構築とHelmチャートによる構築の大きく２つをご紹介します。また、今回紹介する内容はintdashシステムに加え、intdashが依存する各種ミドルウェアもコンテナで一緒に構築します*2。

今回ご紹介する内容はあくまで手軽に立てて簡単に機能を確認したい方向けです。プロダクション環境など、比較的非機能面の要求が高い場合は、ここで紹介した内容を参考にして要求に応じた構成で構築する必要があります。その内容の詳細については今回は割愛させていただきます。

各構築方法の説明に入る前に、構築を補助するスクリプト群が格納されたファイル(ここでは deployment.zip とします)をライセンス購入後にダウンロードし、解凍しておきます。以降はこの解凍されたファイル群を使用します((deployment.zipは使用しなくても製品購入時に提供される構築運用ガイドに沿って進めれば構築は可能です。その場合は deployment.zip 内のファイルはリファレンスとして参照することができます。))。

# 構成ファイル群を入手して解凍する。
unzip deployment.zip
# deploymentに移動します。 以降deploymentがカレントディレクトリという事を前提に説明します。
cd deployment

ここで紹介する内容は正式な手順ではありません。製品提供時に同梱する構築運用ガイドの内容が正式なものとなります。ガイドの内容が本記事の記載と異なる可能性があることをご容赦ください。

docker-compose

docker-composeを使用して構築します。わざわざ章立てしましたが、ただ構築するだけであれば deployment.zip に起動スクリプトがあるのでほとんどやることはありません。他の構築方法も同様です。細かい設定などももちろん可能ですが、ここでは割愛します。

起動に必要なツールがあるのでそれぞれインストールします。

aws cli
docker(docker compose)
openssl
mkcert

次のコマンドを実行します。

export IMAGE_REPOSITORY_BASE=イメージのリポジトリ
# AWSへログインしておきます。イメージの取得に必要です（イメージの配布方法は未だ検討中なので変わる場合があります。）
aws sso login
aws ecr get-login-password | helm registry login --username AWS --password-stdin "$IMAGE_REPOSITORY_BASE"
aws ecr get-login-password | docker login --username AWS --password-stdin ${IMAGE_REPOSITORY_BASE}

# 起動！
./scripts/quick-start.sh localhost

起動ログが流れ始め、遅くても数分程度でアプリケーションが起動します。標準出力されたアクセス情報を元に https://localhost へアクセスして確認します。

ちなみに、ここで例えば次のようにLAN内のアドレスなどを指定すれば一瞬でLAN内にintdashを構築することも可能です。

./scripts/quick-start.sh 192.168.x.x

終了する場合は次のコマンドを実行します。

./scripts/destroy.sh
# または
docker compose down
docker compose down -v

スクリプト内では次の処理を順番に行っています。

アプリケーションで使用する秘密鍵の生成
証明書の作成
アプリケーション郡の起動(docker compose up)

Kubernetes(AWS EKS)

AWS EKS(Elastic Kubernetes Service)へ構築する場合も基本的には同じ流れです。起動スクリプトを実行します。 docker-composeの時と同様に起動に必要なツールがあるので、それぞれインストールします。

次に起動スクリプトを実行します。

# 環境変数の設定
# 必須項目
export AWS_ACCOUNT_ID=<AWS ACCOUNT ID:例 111111111111>
export IMAGE_REPOSITORY_BASE=<リポジトリ:例 <アカウントID>.dkr.ecr.<リージョン>.amazonaws.com>
# オプショナル
export REGION=<リージョン: ap-northeast-1>
export CLUSTER_NAME=<クラスタ名: intdash-demo>
export NAMESPACE=<ネームスペース: intdash>

# AWSへログインしておきます。イメージの取得に必要です（イメージの配布方法は検討中なので今後変更の可能性があります。）
aws sso login
aws ecr get-login-password | helm registry login --username AWS --password-stdin "$IMAGE_REPOSITORY_BASE"
aws ecr get-login-password | docker login --username AWS --password-stdin ${IMAGE_REPOSITORY_BASE}

# 起動！
./scripts/quick-start-eks.sh

数分（場合によっては数十分）待つとEKS上にintdashクラスタが構築されます *3。起動が成功するとアクセス情報が標準出力されます。表示されたアクセス方法に従ってintdashのコンソールにアクセスします。

スクリプト内では次の処理を順番に行っています。一度構築した後は基本的には helm コマンドを通してintdashの更新を行います。

EKSクラスタの作成
EKSのOIDCプロバイダの有効化
ALBロードバランサーコントローラーの有効化
EBS/CSIドライバーのアドオン追加
各種ミドルウェアの追加（Postgres/Nats/InfluxDBなど）
Helmチャートを使用したintdashのインストール
ドメイン設定*4
証明書設定

Kubernetes(kind)

最後にkindにintdashを立ててみます。 kindとはKubernetesクラスタをDockerコンテナとしてローカルで実行するためのツールです。大手クラウドベンダーが展開するマネージドKubernetesサービスに依存しないため、比較的構築しやすい構成*5となります。

こちらについても起動スクリプトがあるので実行するだけです。例によって起動に必要なツールがあるのでそれぞれインストールします。

それでは、同様にintdashを構築していきます。

# 環境変数の設定
export IMAGE_REPOSITORY_BASE=イメージのリポジトリ
export NAMESPACE=<ネームスペース: intdash>
export DOMAIN=<ドメイン: example.127.0.0.1.nip.io>

# AWSへログインしておきます。イメージの取得に必要です（イメージの配布方法は検討中なので今後変更の可能性があります。）
aws sso login
aws ecr get-login-password | helm registry login --username AWS --password-stdin "$IMAGE_REPOSITORY_BASE"
aws ecr get-login-password | docker login --username AWS --password-stdin ${IMAGE_REPOSITORY_BASE}

# 起動！
./scripts/quick-start-kind.sh

EKS同様に数分待つとkind上にintdashクラスタが構築されます。起動が成功するとアクセス情報が標準出力されます。

スクリプト内では次の処理を順番に行っています。

kindクラスタの作成
各種ミドルウェアの追加（Postgres/Nats/InfluxDBなど）
ingress-nginxの追加
イメージプル用のシークレットリソース追加
クラスタに証明書のシークレットリソースの追加

まとめ

今回はコンテナによるintdashの構築方法についてご紹介しました。「簡単に構築できそう！」と思っていただけたら幸いです。もしintdashをローカルや手元のサーバーに構築することができれば、過去テックブログで紹介された記事なども比較的簡単にに確認することができるのではないでしょうか？ご興味があればこちらからお気軽にお問い合わせください。

繰り返しになりますが今回紹介した内容はあくまでも起動するまでに必要な最低限の内容に絞ってご紹介しています。プロダクション環境などに導入する場合は今回紹介した起動方法を参考に堅牢なシステムを構築する必要があります。

*1:パートナー企業様が独自に構築するケースもありますが主流はサービス利用です。

*2:本番稼働などを想定する場合、データベースなどは必ずしもコンテナで構築する必要はありません。例えば、RDBであればAmazon RDSなど大手クラウドベンダのマネージドサービスを使用することも可能です。

*3:eksctl のほぼデフォルト設定で起動します。必要に応じてnodegroupやVPCなどの設定は変更します。

*4:AWSから自動に払い出されたドメイン名に対して、無理やり証明してACMに登録する力技が含まれています。あくまでも確認用です。

*5:AWSに構築する場合は、DockerがインストールされたEC2でkindを実行します。kindは主に開発やテストの目的で利用されるため、本番環境ではEKSなどクラウドベンダーのマネージドKubernetesを利用いただくことを推奨します。

aptpod Tech Blog

株式会社アプトポッドのテクノロジーブログです