IoTだからこそ「サーバーレス」を活用すべき３つの理由 ― ServerlessDays Tokyo 2023 登壇レポート

カテゴリーイベント

こんにちは、ソラコム松下 (ニックネーム: Max) です。

この記事では、クラウド上で作るシステム構成の１つ「サーバーレス」を IoT で活用すべき３つの理由をご紹介します。

IoT のバックエンド(データ処理)において、レンタルサーバーや仮想サーバーを用いた構成とは異なる考え方としてサーバーレスがある事、そして、サーバーレスが IoT に実は適していることを解説します。

このブログは、先日(9/23 土)に開催されたサーバーレス・コミュニティのイベント「ServerlessDays Tokyo 2023」における、私の発表内容をレポートとしてお届けしています。

サーバーレスとは？

サーバーレスとは、クラウド上で作るシステム構成や考え方の１つです。サーバーの準備や運用の手間が不要なのが特徴です。サーバーの有無を指しているわけで無く、仮に構成内にサーバーがあったとしても、皆さんが準備・運用をしなければ (= クラウド事業者が肩代わりしてくれる)、サーバーレスと言ってもよいでしょう。

似た言葉に「マネージドサービス」があります。下の図では、IaaS(仮想サーバーやレンタルサーバー)から SaaS 、マネージドサービス、サーバーレスといった分類を私たちなりに整理してみました。

ポイントは横軸となっている「自由度」と「必要スキル」「開始までの時間」です。

IaaS は、Amazon Elastic Compute Cloud (Amazon EC2) や Azure Virtual Machines といった仮想サーバーになり、自由度やチューニングの幅はありますがその分スキルが必要で、また設定や準備の手間もかかります。反対側の SaaS は、例えば Dropbox や Microsoft 365 といったアプリケーションサービスです。カスタマイズの余地は少ないのですが、すぐに使い始められることが多いものばかりです。

サーバーレスは IaaS と SaaS の中間に位置します。サーバーレスも分類は大きく２つあり、コードの実行環境が提供されるものと、API を通じて “機能” が提供されて、皆さんのアプリケーションに組み込めるものがあります。代表的なサービスとして、前者には AWS Lambda 、後者には Amazon DynamoDB があります。

ちなみに “マネージドサービス” における「クラスタや AZ 配置をユーザーが設定」するものには、Amazon RDS があります。物理的なサーバーの準備や OS の設定は不要(= マネージド)ですが、”機能” を利用をするための設定、例えば可用性を上げるためのクラスタ構成や、運用は私たちが行う必要があるため、サーバーレスとは異なる位置づけになっています。

サーバーレスは「サーバーの準備や運用の手間が不要」な構成です。より詳しくサーバーレス自体を深堀したい方は、こちらの資料(Serverless Updates 2023)をご覧ください。

ここからは、IoTだからこそ「サーバーレス」を活用すべき３つの理由を紹介していきます。

理由１：費用の最適化 ― IoT とサーバーレスは相性がいい

まず、以下の動画をご覧ください。AWS Lambda を利用して “Hello from Lambda! Welcome to serverless !!” というテキストを返す HTTP REST サーバー¹の構築を 1分40秒で行っています。

これだけの時間で HTTP REST サーバーの実装ができたこともサーバーレスの凄味ではありますが、それ以上のポイントがあります。それは「待ち時間に課金が発生しない」ということです。
これが理由の１つ目「費用の最適化」がしやすい事につながります。

IaaS や一部のマネージドサービスは「稼働時間」で費用が発生します。常にデータを処理するワークロードが得意で効率的です。IoT のデータに着目すると、IoT のデータというのは、いつ発生するのか予測しづらいものが多いのです。IaaS で IoT のデータ処理をする構成では、データの待ち時間＝処理をしていない時間が生まれます。非効率ということです。

サーバーレスのサービスのほとんどが「処理量(回数)や処理時間」すなわち、データ処理をした時間にのみ費用が発生します。データの待ち時間には課金されないため、費用対効果の効率が最大になります。IoT とサーバーレスは相性がいいのです。

理由２：変化への対応 ― 新しいことを始める、不要なものを止めるが容易

変化への対応がしやすいことも、理由の１つとして挙げられます。

サーバーレスのサービスを組み合わせて作るアーキテクチャパターンに「ファンアウト(Fan-out)」があります。１つの入力データに対して、複数の出力をする設計のパターンです。複数の処理を並列で処理する際に使います。AWS の IoT ゲートウェイサービス「AWS IoT Core」を例にすると、以下のようになります。

このパターンのメリットは、処理の追加や停止が容易なことです。例えば、上図のルール B やルール C を停止しても、ルール A の処理には影響がありません。もちろん新たなルールを追加しても、A～C の処理への影響はありません。

IoT のシステム開発はゴールを模索しながら進めることも多いため、頻繁な機能改善や時には大きな機能追加も考えられます。その時に備える意味でも、ファンアウトは心強いパターンとなるでしょう。また、機械学習や生成 AI といった新たなテクノロジーを積極的に取り込むときにも役立ちます。

このようなパターンを堅牢に作ることができるのも、サーバーレスのメリットです。

IoT デバイスとサーバーレス連携を支援する SORACOM サービス群

IoTデバイスをサーバーレスに接続するには、デバイスにSDKの設定が必要です。クラウドの手間は少ないが、デバイスの設定で労力がかかってしまうと、サーバーレスのメリットが減ります。

SORACOM では、IoT デバイスから容易にサーバーレスが利用できるようになる「アプリケーション連携サービス」を提供しています。

SORACOM Beam：カスタムのエンドポイントへ転送（例：HTTPSやMQTTSなど）
SORACOM Funk：Function as a Serviceへ転送（例：AWS Lambdaなど）
SORACOM Funnel：クラウドサービスやSORACOM パートナースペース企業様（弊社パートナー企業様）のソリューションへ転送（例：Amazon Kinesis Data Streamsなど）

例えば先程ファンアウトパターンで紹介したAWS IoT Coreへの接続であれば、SORACOM BeamやSORACOM Funnelを使うことで、デバイス側からはTLS無しのMQTTや、HTTP/TCP/UDPといった簡素なプロトコルでIoT Coreとデータのやり取りが可能です。

どのように活用すると、より開発を減らしつつサーバーレスにつなげられるかは「IoTプロジェクトの課題から考えるSORACOM Beam・Funk・Funnelのメリットと選び方」をご覧ください。

理由３：ノウハウや仲間が集まる ― 次は君のサーバーレスを！

理由の３つめは、ノウハウや仲間が集まるコミュニティの存在です（スライド内では「イケてる」と表現していますが、実際その潮流があります）

サーバーレスは一時的な流行ではなく、すでに多くの事例があります。また、それらを積極的に公開する文化もあることから情報が多く出回っています。サーバーレスはそれ自体が目的ではなく手段であるため、ノウハウを公開しても自社ビジネスの損になりにくいためです。

同じ課題に挑む、組織を超えた仲間＝コミュニティが形成されており、課題解決の方法を共有しています。私が今回発表をしたサーバーレス・コミュニティのイベント「ServerlessDays Tokyo 2023」も、その１つです。(参考: ServerlessDays Tokyo 2023 で発表されたスライド一覧)

コミュニティは相互の助け合いで成り立っています。皆さんが持つノウハウを還元することで、コミュニティの一員になれるのです。還元というからには、もちろん最初はノウハウ入手でかまいません。その後、皆さんのサーバーレスを紹介することで、誰かの「還元のスタート」になると信じています。私の発表の最後はこのスライド＝願いで締めくくりました。