[レポート] AWSで実現するマルチリージョンIoT 〜Analog Devicesの事例を添えて〜

おつかれさまです。新井@サーバーレス開発部です。

最近マルチリージョンIoTの実現方法に関して調べており、 ちょうど先日YoutubeでAWS re:Invent 2018のImplementing Multi-Region AWS IoT, ft. Analog Devices (IOT401)を見たので、遅ればせながらセッションレポート投下します。

内容がとても濃く、発散しがちなレポートになってしまったので、必要な部分をピックアップして見てもらうのが良いかと思います。

セッション概要

Your devices are being shipped across the globe. You have consumers who use their hardware across different countries. How can you build an IoT application that reflects the geographic reach of your devices? In this session, we walk you through the stages of going multi-region with AWS IoT. We first tackle common challenges around setting up your accounts and permissions for AWS IoT. We then dive into different modes of multi-region deployments using multiple AWS services. We also cover the nuances of moving devices across locations and how you can plan, monitor, and execute on your IoT application. Throughout this session, we dive into code and architectures that show the good, the bad, and the ugly of multi-region deployments in IoT, and we share how best to tackle them on day 1 as you take your applications global. We also highlight a customer example from Analog Devices.

和訳(意訳)

あなたのデバイスは、世界中に出荷され、さまざまな国でそのデバイスを使用する顧客がいます。この様なシチュエーションで、デバイスの地理的状況を反映したIoTアプリケーションをどのように構築すればよいでしょうか？ このセッションでは、AWS IoTを利用してマルチリージョン移行をする際のいくつかの段階について説明します。最初に、AWS IoT用にアカウントとアクセス許可を設定することへの一般的な課題に取り組みます。次に、いくつかのAWSサービスを使用して、さまざまなモードのマルチリージョンデプロイメントに取り組みます。また、デバイスが場所を超えて移動することでの微妙な違い、およびIoTアプリケーションでの計画、監視、実行方法についても説明します。このセッションを通して、私たちはIoTでマルチリージョンデプロイメントを実施する際の、良い・悪い・酷いコードやアーキテクチャについて掘り下げます。そして、あなたがアプリケーションのグローバル展開を考える初日に、どのように取り組めばよいか最善の方法を共有します。また、Analog Devicesの顧客事例も紹介します。

アジェンダ

• なぜマルチリージョンを行うのか
• マルチリージョンを行う際のテーブルステーク
• 事例紹介 ~ Analog Devices, Inc. ~
• マルチリージョンアーキテクチャの紹介

なぜマルチリージョンを行うのか

いくつか理由が挙げられます

• レイテンシ Latency
• 弾力性/回復力 Resiliency
• 災害時の復旧 Disaster Recovery

顧客の一番の要望は、Latencyだそうです。 たとえば、デバイスをアジアまで輸送していたとして、わざわざus-east-1のリージョンに繋ぎたいですか？とても非効率ですよね？インターラクションで遅延しますよね？という話

続いて、

リージョンをまたいで、resiliencyを達成したい

災害時などに、デバイスの状態や証明書を自動入力して別リージョンに再配置するなど

IoT 固有の問題はなにか？

Websiteにユーザがアクセスする場合と比較すると、デバイスによる制約や考慮事項が多いのがわかります。

• リカバリを考慮した事前のプログラミング
• グローバルな物流とプロビジョニング

IoTを考える時のレイヤー分割

• Edge: sdk, greengrass, freertos
• Provisioning: セキュリティ, ID
• Communication: AWS IoT Coreだとpub/subプロトコルみたいなもの
• Ingestion: データの収集

下２つのレイヤーはIoTとは独立しています。 (RDSのデータを他のリージョンにレプリケートするとか、ビッグデータ解析のために別リージョンのS3にデータ転送するとか)

IoTでは、上４つのレイヤーが固有の問題であり、多くの時間はこの部分に割かれます。

マルチリージョンを行う際のテーブルステーク

ポーカーとかで席に座ったらとりあえず払わなきゃいけない掛け金のこと (= 先行投資的な意味？と理解)

これらがないと、もっと困難な課題にぶちあたるでしょう

Single region resiliencyに関しては、マルチリージョンを行う前にシングルリージョンの冗長構成をベストプラクティスに則ってしっかり考えましょうという意味

アカウントとリージョン分割

1. 1アカウントで全リージョン

• このパターンを採用しているケースは結構多い (割とスタンダード)
• レプリケーションが楽です

2. 地域ごとに別々のアカウント

• 例えば、アメリカで1アカウントとか
• オススメパターン (セグメント化、アカウントの独立化)
• 管理が楽　（わかりやすいから）
• デプロイはアカウント(リージョン)ごとにおこなう
• アカウントごとに、プライマリ/バックアップを分割可能
• ジオロケーション的なインパクトを受けない

ブートストラップと初期設定

• IoTのエンドポイントをハードコードすることを避ける

• 2つの要素

  • エンドポイント
  • それぞれのエンドポイントで利用可能なトピック

Why user your own CA?

• 独自CAを利用

AWS IoT が作成する証明書はリージョン依存だが、顧客が独自に作成する証明書はマルチリージョンにプロビジョニング可能 (Just In Time Registration)

OTA

• 積極的にOTAを行える仕組みを作るのが重要
• スライドの図のように、クラウド側でファイルオーバー出来る設計にしましょう

シングルリージョンでの回復力

• AWS IoTのルールエンジンを利用して、エラーアクションを定義しましょう。
• 複数のアップストリームを用意しましょう。 （たとえば、DynamoDBにだけデータ挿入するのではなく、S3にもアップストリームしてデータをアーカイブしましょうってこと。DynamoDBでデータ消えた場合に、少なくとも後から取り出せるから。）
• マルチAZは実施しましょう。
• リトライ処理はクラウド・デバイスの両方で実施しましょう。 (たとえば、エクスポネンシャルバックオフとか)

事例紹介 ~ Analog Devices, Inc. ~

マルチリージョンでIoTを展開しているセミコンダクターカンパニー

同社が展開しているArgus Mマシンヘルスモニタリング製品

• デバイスとAWS IoTを接続
• センサー感でローカルメッシュメットワークを構築
• 低消費電力
• マルチリージョン
• リアルタイムデータではない
• 物理的に過酷な環境にデバイスがある(人が頻繁に立ち入りできない)
• 動的なOTAが必要

マルチリージョンのキーポイント

1. アプリケーションの全体インストールを物理的に行う部分を最小限にする
2. 待ち時間と接続失敗の可能性を最小限に抑えることは、リアルタイムデータを扱っていないとしても非常に重要
3. 地域によって異なるデータ法に準拠する
4. 複数の地域で鍵や証明書を再発行する必要のないパターンを採用することが非常に重要 (デバイスの鍵や証明書はリージョンを跨いでも一意にしたい)

Registration and Claiming パターン

RegistrationとClaimingの2つのフローに分離している

Registration Flow

• デバイスの登録
  • デバイスは初期状態で、接続を行うだけでRegistrationが可能
  • ジャストインタイム登録を採用 (= 接続できれば登録ができる)
  • 全てのリージョンで利用できるように事前にCAが登録されている必要がある
  • 接続だけ可能な制限されたポリシーが重要

Claiming Flow

• デバイスのプロビジョニング
  • デバイスの属性を変更 (未登録 -> 登録済み)
  • Policyのリプレース (登録完了したので、権限を緩和する必要がある)

Summary

• mqttトピック名にリージョン名を含めるのがいい
• multi-region iot やる場合は JITR がいい。 = 証明書を共通で使えるので、ロール切替の必要ない
• RegistrationとClaimingをわけることで柔軟な設計をおこなえる
• iot job は良い。 = リージョン間のマイグレーションやフェイルオーバー設定の更新を支援してくれる
• 何年も課題になっていたマルチリージョンIoTがAWS IoTで実現可能
• レイテンシー&回復力&ディザスタリカバリという3つの側面を実現可能

マルチリージョンアーキテクチャの紹介

2パターンが考えられる

• Active/Passive パターン
  • DR シナリオ, Resiliency
  • Pilot Light Infrastructure
• Active/Active パターン
  • デプロイ中もダウンタイム無しで動く

いずれにせよ証明書等のレプリケーションは必要になってくる

Active/Passive パターン

プライマリとスタンバイリージョンを用意するパターン

レジストリイベント

• DynamoDBのグローバルテーブルをつかって、レプリケーションを行うパターンの紹介
  • Active/Passive パターン
  • AWS IoTのルール起動にイベントレジストリのトピックを指定する
  • トリガーされるアクションにStep Functionを指定して、DynamoDBに対してデバイス情報の更新をおこなう
  • 別リージョンのDynamoDB Streamで、更新されたデバイス情報を元にAWS IoTに対してレプリケートをおこなう
  • DynamoDBが使えない場合は、Kinesis StreamsのオープンソースライブラリのCross Region Replicationでも同様のことは可能

証明書の登録をクロスリージョンレプリケーションしてみる

• ジャストインタイム登録で証明書のレプリケーションを考えてみる
• トピック名: $aws/events/certificates/registered/<caCertificateID>

• Custom iot event
  • JITRを行ってもすぐに使えない
  • 他のリージョンへの反映まで少し時間かかる
    • Policy Event/Certificate Event をStep Function内で実行する必要がある
    • 証明書の登録、ポリシーのアタッチなどやることたくさんあるため、リトライロジックを組めるStep Functionはとても相性がいい。
  • CA Global TableというのDynamoDBを使う
• JIRT eventの後に、cert eventとpolicy eventもある
  • プログラマブルにターゲットリージョンに反映する必要がある
  • delete/update もあるので少し大変

Demo

デモでは、クロスリージョンレプリケーションを行っている様子を実際に見せてくれます。

ルール起動やStep Functionの設定は事前に行われており、中身の詳細についても解説してくれます。

US-Eastで新しく作成したモノのタイプ・グループが、US-Westに5~10秒程でレプリケーションされている様子が確認できます。

Active/Active パターン

• なぜActive/Activeやりたいのか？
  • シームレスなDRを実現したいから
  • 何処のリージョンにアクセスしてもいい

上2つはActive/Passiveパターンと同様のため、 あとは下の3つにフォーカスすればいい

1. Dual Infrastructure
2. Devices pinned to a region
3. Process Data Once

1. Dual Infrastructure

同じインフラを用意する (= あるリージョンで動作するデバイスは、別リージョンでも同じよに動作するよう)

2. Devices pinned to a region

デバイスシャドウなど、必要な情報をレプリケートする必要がある

3. Process Data Once

データの種類によって何処のリージョンで処理を行うか考慮する必要がある

• リージョン切替したとしても、データ処理は基本的にデバイスが接続されているリージョンで実行されるべきである。(いちいち転送するのを待てないから)
• 一方で、テレメトリ情報とかはKinesis Streamなどを利用して、特定リージョンへの転送が必要な場合がある (特定リージョンで利用している顧客がいるはずだから)

まとめ

事例も紹介されていたので、こちらが今後マルチリージョンでIoTを考えるときのガイドラインになるのではないでしょうか。

どなたかのお役に立てれば幸いです。

以上遅めのレポートでした。