Amazon Web Services ブログ
マルチアカウント戦略を用いて AWS 上にスケーラブルなマルチテナント IoT SaaS プラットフォームを構築する方法
この記事は How to build a scalable, multi-tenant IoT SaaS platform on AWS using a multi-account strategy の日本語訳です。IoT Specialist Solutions Architect の新澤雅治 が翻訳しました。
はじめに
モノのインターネット (IoT) の普及に伴い、多くのソリューション提供者は、既存のサービスとして Software-as-a-Service (SaaS) と統合する IoT アプリケーションの構築と管理を望んでいます。 IoT デバイス群を含む SaaS サービスを検討する場合、そのアーキテクチャはテナント管理だけでなく、フリートの関連付けと隔離も考慮に入れる必要があります。このブログでは、AWS Control Tower をマルチアカウント戦略とともに使用して、マルチテナントの IoT SaaS プラットフォームを実装するリファレンスアーキテクチャについて説明します。
アーキテクチャの設計には、さまざまなデプロイメントモデルを用いる方法がいくつかあります単一の Amazon Web Services (AWS) アカウントにデプロイすることも、 AWS アカウントの制限、テナントの隔離、リージョン固有のデプロイメント制限、またはその他のアーキテクチャ上の考慮事項のために、複数の AWS アカウントにまたがってデプロイすることもできます。
AWS でマルチアカウント戦略を確立することは、新しいアプリケーションバージョンの迅速なテストとデプロイを可能とし、環境を安全に管理するのに役立ちます。マルチアカウントデプロイメントモデルは、特にクラウドワークロードがデバイスフリートの動作と一致する必要がある IoT ワークロードの技術的課題を解決します。これについては、次のセクションで詳しく説明します。
マルチテナント型 IoT SaaS プラットフォームの課題への対応
顧客がデバイスを作成して展開するマルチテナントの IoT SaaS プラットフォームサービスを構築する際には、実装を成功させるために解決しなければならない次のような課題があります。
- データ分離 – マルチテナント構造では、 SaaS プロバイダーは、規制や顧客の要件に基づいてデータ分離境界をどのように設定するかを考慮する必要があります。IoT ワークロードの場合、多くのデバイスとゲートウェイがさまざまなデータタイプをさまざまなスキーマで接続して送信します。 AWS アカウントごとに境界を定義しておくと、さまざまなアカウントレベルのポリシーを設定できるため、クォータや個々の顧客フリートのニーズを管理しやすくなります。
- データプライバシー – IoT は世界中で多くの業界で使用されています。さらに、データプライバシー規制は業界や地域によって異なります。テナントごとに要件に基づいて個別の IoT エンドポイントを用意することで、グローバル SaaS プラットフォームとして柔軟に運用できます。
- デバイスプロビジョニングとオンボーディング – 現場で複数のセンサを束ねるルートデバイスの ID を変更することなく、デバイスを複数のテナント・エンドポイントにオンボーディングする戦略が必要です。 IoT セキュリティのベストプラクティスでは、各 IoT エンドポイントで認証される固有の暗号化 ID を使用してデバイスをプロビジョニングすることを推奨しています。デバイスのルート ID のプログラミングと確立は、通常、製造時などのコントロールされた顧客環境で行われます。デバイスがグローバルサプライチェーンを経て現場に設置されるまでに数か月から数年かかる場合があります。製造時にデバイスの ID をテナントアカウントの IoT エンドポイントに緊密に結合してしまうと、柔軟性に欠けるサプライチェーンとなってしまいます。また、メーカーにとって SKU の断片化の原因にもなります。IoT エンドポイントへのデバイス ID のオンボーディングは、デバイスのライフサイクルの後半で行われる可能性があることを考慮する必要があります。
このブログのリファレンスアーキテクチャは、上記の課題に対処し、導入と運用を簡素化し、データガバナンスを強化します。
以下では、アーキテクチャの重要なポイントについて説明します (図 1)。
- プラットフォーム作成の自動化 – 新しいテナントをオンボーディングすると、このアーキテクチャでは新しい AWS アカウントを作成し、テナント専用およびリージョン固有の AWS IoT Core エンドポイントを確立します。その後、新しいアカウントごとに、他の関連する AWS サービスとアプリケーションをデプロイします。この自動化されたプロセスは、データの分離、プライバシー、クォータ管理の課題の一部を解決するのに役立ちます。
- デバイスのプロビジョニングとオンボーディング – 一元化されたオンボーディングサービスを使用して、IoT デバイスを要求し、指定されたテナント IoT エンドポイントにルーティングします。これにより、製造時のテナント固有のデバイスプロビジョニングの課題やテナントバインディングの遅延を解決できます。
図 1 — AWS アカウントレベル別の IoT マルチアカウントアーキテクチャの概要
AWS Control TowerとAWS Service Catalog を使ったテナント環境構築の自動化
自動化とスピードは、より良いカスタマーエクスペリエンスの鍵となります。特に、テナントのオンボーディングの際には、AWS Control Tower と AWS Service Catalog を使用して、 AWS アカウント作成を含むテナントオンボーディングプロセスを自動化しましょう。これらのサービスは、顧客のプロセスを改善し、製品の市場投入までの時間を短縮します。
AWS Control Tower を有効にすると、Control Tower – Master というランディングゾーンがリージョンにデプロイされます。AWS Control Tower は、監査アカウントとログアーカイブアカウントも作成します（図2）。AWS Control Tower は、セキュリティとコンプライアンスのリスクをスキャンするための設定、またはシステムコントロールを提供します。これらのコントロールは policy-as-a-code として管理し、新しく作成された AWS アカウントに適用することができます。
図2 – AWS Control Tower サービスコンソールの組織ビュー
AWS Control Tower が有効になると、AWS Control Tower Account Factory を使用して新しい AWS アカウントを作成し、 IoT アプリケーション（エンドポイント）をデプロイできるようになります。 Account Factory は、新しい AWS アカウントの作成プロセスを自動化し、セキュリティとコンプライアンスのベストプラクティスのコントロールを適用します。また、アカウント作成プロセス中に AWS IoT Core を使用するテナントアプリケーションインフラをデプロイします。
AWS Control Tower コンソールを見ながら、主要な設定ポイントを理解していきましょう。
- AWS Control Tower コンソールで、ナビゲーションペインの Account Factory を選択します。
- Create Account ボタンを選択すると、Create account ページが表示されます。
- このページで、アカウントマスターのメールアドレス、 AWS IAM Identity Center の識別情報、組織情報などのアカウントの詳細を指定します(図 3)。
図 3 – AWS Control Tower Account Factory でのアカウント作成
- ページを下にスクロールして、 Account factory customization (AFC) セクションを見つけます。(図 4) このセクションでは、AWS アカウント作成後にデプロイする製品またはアプリケーションを指定します。 注：ドロップダウンリストに表示するには、すべての製品を Service Catalog 製品として登録する必要があります。Service Catalog 製品は自分でテンプレートを開発するか、構成済みのライブラリを使用して作成できます。詳細については「Getting Started Library」を参照してください。図のシナリオでは、製品は「テナント用 IoT アプリケーション」と名付けられ、製品として事前登録されているため、AFC はアカウント作成プロセス中にデプロイをトリガーできます。詳細については、「 Account Factory Customization （AFC）によるアカウントのカスタマイズ」を参照してください。.
- 最後に、製品を配置する場所を選択します。Account Factoryは、ホームリージョン (AWS Control Tower を有効にしたリージョン） 、または ” All Governed Regions “にデプロイします。このシナリオでは、ホームリージョンであるバージニア北部にデプロイします。
図 4 – AWS Control Tower の Account Factory Customization での設定
- アカウント作成後、AWS Control Tower に登録・管理されているアカウントが表示されます。
図 5 — AWS Control Tower によってデプロイおよび管理される AWS アカウントのリスト、組織構造、およびアカウント作成に使用されたブループリント (テンプレート)
テナントアカウントへの IoT デバイスのプロビジョニングとオンボーディング
IoT アプリケーションがデプロイされた AWS アカウントが用意できたので、次にデバイスのプロビジョニングとオンボーディングに移りましょう。製造中のデバイスプロビジョニングを個々のテナントアカウントから切り離すために、AWS Control Tower を使用して、専用の AWS アカウント内に集中化されたデバイスオンボーディングサービスを作成します。このシナリオでは、QR コードを使用して IoT デバイスを AWS IoT Core にオンボードする方法を提供する 「Device Lobby」 リファレンスアーキテクチャを使用します。
図 6 – AWS Device Lobby アーキテクチャ
ビルやキャンパスの物理的なロビーが訪問者のための公開エントランスポイントを提供するのと同様に、 IoT Device Lobby は、バインドされていない IoT デバイスのための AWS へのエントリーポイントを確立します。このアプローチにより、テナントデバイスの柔軟なオンボーディングが可能になり、クレーム処理を通じてユニークなデバイス識別子をテナントの IoT コアエンドポイントに関連付けます。サービスがデバイスをクレームすると、 Device Lobby サービスアカウントは、定義された MQTT トピックを介してテナントの AWS IoT Core エンドポイントにデバイスを送信するルーティング層として機能します (図 7) 。
このアーキテクチャは、デバイスのライフサイクル中のいつでも、テナントによって製造されたデバイスがそのエンドポイントにルーティングされることをサポートします。また、IoT Device Lobby アーキテクチャーは、デバイスを再プロビジョニングすることなく、あるリージョンやアカウントから別のリージョンまたはアカウントに移行することもサポートします。この状況では、サービスは Device Lobby サービスをホストする中央エンドポイントと、製造時にプラットフォームまたはテナントの公開鍵基盤（PKI）に基づく固有の認証情報でデバイスをプロビジョニングします。
詳細については、 IoT Device Lobby Architecture を参照してください。
図7 – Device Lobby アーキテクチャによる IoT デバイスのルーティングとテナントアカウントへの登録
Device Lobby アーキテクチャをデプロイするには、サービスをホストする専用の AWS アカウントを作成します。Device Lobby サービスのインスタンスは1つしか必要ないので、デプロイガイドに従って直接専用アカウントにデプロイできます。必要に応じ、AWS Service Catalog から製品を作成することにより、開発、テスト、ステージングアカウント全ての環境で同じ構成を実行できます。詳細については、 Device Lobby Configuration を参照してください。
図8 – サービスカタログに追加された Device Lobby サービス製品
IoT SaaS プラットフォームの Device Lobby サービスアカウントを確立したら、テナント IoT アプリケーションのアカウント設計図には、クロスアカウント信頼ポリシーを含める必要があります。このポリシーにより Device Lobby サービスがデバイスを登録し、テナントアカウントの IoT エンドポイントに接続できるようになります。
Device Lobby を使用することで、IoT SaaS プラットフォームは任意のテナントアカウントやリージョンにデバイスをオンボードする際の柔軟性が大幅に向上し、デバイスを特定の単一テナントアカウント用にプロビジョニングする必要がなくなります。デバイスの構築と現場への配備には時間がかかるため、このアプローチでは既存のデバイス SKU を再利用できるため、顧客の IoT 導入を大幅に加速できます。また、このソリューションは、デバイスのサプライチェーンにおける規模の経済性を高めることにもつながります。
まとめ
この投稿では、IoT SaaS プラットフォームが、複数の顧客の IoT デバイス群をホスティングする際に、データの分離、プライバシー、サービスクォータ管理の課題にどのように対処できるかについて説明しました。AWS Control Tower は、 SaaS プラットフォームを構成する可能性のある複数のアカウントを管理するための手作業や潜在的にエラーを起こしやすいプロセスを取り除くのに役立ちます。テナントの IoT ワークロードをホストする複数の AWS アカウントへのデバイスオンボーディングを、Device Lobby アーキテクチャのような一元化されたサービスで管理できます。さらに、マルチアカウント戦略を採用することで、IoT SaaS サービスを構成する各テナントの AWS アカウントで、個別のさまざまな顧客デバイスフリートをホスティングすることができます。これにより、テナント・フリート間の分離が向上し、テナントごとに異なるサービスのクォータとポリシーの管理が容易になり、 AWS 上でより堅牢でスケーラブルな IoT SaaS プラットフォームを実現します。
AWS Control Tower の詳細については、AWS Control Tower Workshop をご覧ください。 AWS IoT サービスを始めるには、AWS IoT Immersion Day Workshop をご覧ください。
著者について
Tomo Sakatoku
シアトルの Amazon Web Services のプリンシパル・エンタープライズ・アーキテクトです。顧客と協力して困難な問題を解決することに情熱を注いでいます。また、趣味はテニスと家族旅行です。
Ben Cooke
テキサス州オースティンの Amazon Web Services のシニア IoT ソリューションアーキテクトです。IoT システムアーキテクチャに注力しています。趣味は、家族とのアドベンチャーやガレージでの物づくりです。
この記事は Ben Cooke と Tomo Sakatoku によって書かれた How to build a scalable, multi-tenant IoT SaaS platform on AWS using a multi-account strategy の日本語訳です。この記事は ソリューションアーキテクト の新澤雅治が翻訳しました。