03_AWS IoTのDRを考える

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
2021/06/09
AWS IoTのDRを考える
AWS IoT Deep Dive #4

⾃⼰紹介
名前︓
市川純（いちかわじゅん）
所属︓
アマゾンウェブサービスジャパン株式会社
デジタルトランスフォーメーション本部
プロトタイピングソリューションアーキテクト
担当︓
IoTに関係するプロトタイピングやお客様の⽀援

アジェンダ
• Disaster Recoveryとは︖
• DRの基本的な考え⽅
• IoTサービスの課題
• AWS IoTで実現する場合のサンプルアーキテクチャ
• そのDRは本当に必要ですか︖

Disaster Recoveryとは︖

Disaster Recoveryとは︖
ディザスタリカバリ、災害復旧 (英: disaster recovery)は、事業継続マネジメ
ントにおける概念のひとつで、⾃然災害または⼈為的災害後の重要な技術インフ
ラ、システム復旧、あるいは被害を最⼩限に抑えるための予防措置のことである。
ウィキペディアより抜粋
https://ja.wikipedia.org/wiki/ディザスタリカバリ

DRの基本的な考え⽅

Disaster Recovery(災害復旧)
REL 13: 災害対策 (DR) はどのように計画するのですか?
バックアップと冗⻑ワークロードコンポーネントを配置することは、DR 戦略の
出発点です。RTO と RPO は、可⽤性を回復するための⽬標です。これらは、ビ
ジネスニーズに基づいて設定します。ワークロードのリソースとデータのロケー
ションと機能を考慮して、⽬標を達成するための戦略を実装します。
AWS Well-Architected フレームワークの抜粋
https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.question.REL_13.ja.html

復旧目標時点(RPO)、復旧目標時間(RTO)について
サービス停⽌時間（ダウンタイム）
システム復旧時間
RPO RTO
トランザクション消失
Recovery Point Objective (RPO) Recovery Time Objective (RTO)
§ 該当サービス復旧にかけられる時間
§ 1分、15分、1時間、4時間、1⽇︖
§ データリストアや、システム再起動等の
技術選択に影響
§ ディザスタリカバリの復旧時点の⽬標値
バックアップ・データを取得するタイミング
や頻度のこと
§ どの程度のデータ損失が許容されるか︖
§ バックアップ・リストアの運⽤間隔や
データレプリケーションの技術選択に影響
災害
発⽣
サービス
再開

復旧⽬標を満たすための戦略
バックアップ
リストア
パイロット
ライト
ウォーム
スタンバイ
Active-Active
（マルチサイト）
§ 平常時はバックアップを取
得
§ RTOに応じて常時サブサイ
トへバックアップを転送
or 障害時に転送
§ 障害時に必要なデータをサ
ブサイトでリストア
§ 費⽤︓$
§ 平常時はコアサービスのみに
限定したサブサイトを運⽤
(例 DBのみ常時運⽤ etc.)
§ 障害時に、必要に応じてその
他サービスを起動
§ 費⽤︓$$
§ 平常時からメインサイト同
等機能をもち規模を縮⼩し
たサブサイトを運⽤
§ 障害時は⾃動フェールオー
バーし、流量を絞って業務
を継続
§ 費⽤︓$$$
§ 平常時からメインサイト同
等構成のサブサイトを運⽤
§ 障害時は⾃動フェールオー
バー
§ 費⽤: $$$$
Low High
RPO: 数時間以内
RTO: 24時間以内
RPO: 数分以内
RTO: 数時間以内
RPO: 数秒以内
RTO: 数分以内
RPO: なしor数秒
RTO: 数秒以内

IoTサービスの課題

AWS IoTを使ったよくあるアーキテクチャ例
AWS IoT
Core
IoT
Device
IoT
Device
IoT
Device
Amazon S3
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWS Lambda Amazon
DynamoDB
Amazon API
Gateway
AWS Lambda
Amazon Athena Amazon
QuickSight
業務/
User
アプリ

AWS IoT
Core
IoT
Device
IoT
Device
IoT
Device
Amazon S3
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWS Lambda Amazon
DynamoDB
Amazon API
Gateway
AWS Lambda
QuickSight
Thing/証明書
/Shadow
処理が終わって
いないデータ
データ
データ
DRで検討が必要となってくる部分
アプリケーション
業務/
User
アプリ
証明書/
接続先

デバイス接続部分の懸念点
IoT
Device
IoT
Device
IoT
Device
Amazon S3
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWS Lambda Amazon
DynamoDB
Amazon API
Gateway
AWS Lambda
QuickSight
業務/
User
アプリ
AWS IoT
Core
• デバイスが接続するエンドポイントの情報
• デバイスが持っているクライアント証明書
• AWS IoT Coreで持っている証明書
• Thingの情報(属性、Device Shadow等)
何らかの方法で、接続先の切り替え、証明書の登録
が必要

データのストリーミングの懸念点
IoT
Device
IoT
Device
IoT
Device
Amazon S3
AWS Lambda Amazon
DynamoDB
Amazon API
Gateway
AWS Lambda
QuickSight
業務/
User
アプリ
AWS IoT
Core
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
• まだストレージに保存されていないデータをど
うするか？

ストレージの懸念点
IoT
Device
IoT
Device
IoT
Device
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWS Lambda
Amazon API
Gateway
AWS Lambda
QuickSight
業務/
User
アプリ
AWS IoT
Core
Amazon S3
Amazon
DynamoDB
• ストレージに保存されているデータをどうする
か

アプリケーションの懸念点
IoT
Device
IoT
Device
IoT
Device
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWS Lambda
AWS IoT
Core
Amazon S3
Amazon
DynamoDB
Amazon API
Gateway
AWS Lambda
Amazon
QuickSight
業務/
User
アプリ
• 業務向けアプリケーションはどうするか
• ユーザー向けアプリケーションはどうするか
Amazon Athena

AWS IoTで実現する場合の
サンプルアーキテクチャ

Disaster Recovery for AWS IoT
https://aws.amazon.com/jp/solutions/implementations/disaster-recovery-for-aws-iot/

Disaster Recovery for AWS IoT
IoTデバイス
AWS IoT Core AWS IoT Core
Amazon DynamoDB
(global table)
AWS Lambda AWS Step
Functions
Amazon API
Gateway
Amazon Route 53
Amazon DynamoDB
(global table)
Amazon API
Gateway
AWS Lambda AWS Lambda
Primary Region Secondary Region

デモ

デバイス接続部分の懸念点
IoT
Device
IoT
Device
IoT
Device
Amazon S3
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWS Lambda Amazon
DynamoDB
Amazon API
Gateway
AWS Lambda
QuickSight
業務/
User
アプリ
AWS IoT
Core
• デバイスが接続するエンドポイントの情報
• デバイスが持っているクライアント証明書
• IoT Coreで持っている証明書
• Thingの情報(Device Shadow等)
何らかの方法で、接続先の切り替え、証明書の登録
が必要

エンドポイントの判定⽅法
AWS Lambda AWS Step
Functions
Amazon DynamoDB
(global table)
Amazon DynamoDB
(global table)
AWS IoT Core
Amazon API
Gateway
Amazon Route 53
Amazon API
Gateway
AWS IoT Core
IoTデバイス
Secondary Region
Primary Region
デバイスからAWS IoT Coreへ接続する前にエンドポイントを返してく
れるDNSの名前解決をして、接続可能なIoT Coreのエンドポイントを取
得します

エンドポイントの判定⽅法
Route 53のTrafic policyに
ヘルスチェック対象と返す
エンドポイントを作成します
このPolicyでPolicy recordを
作成します
この設定は、CFnテンプレートには含まれていません
https://docs.aws.amazon.com/solutions/latest/disaster-recovery-for-aws-iot/solution-
components.html#create-a-traffic-policy

デバイスのThing、IoT Policy、証明書の複製
Amazon API
Gateway
Amazon Route 53
Amazon API
Gateway
IoTデバイス
AWS IoT Core
Amazon DynamoDB
(global table)
Primary Region
• デバイスの登録には
• JITRを利用
• CLI/SDKを利用
AWS IoT Core
AWS Lambda AWS Step
Functions
Amazon DynamoDB
(global table)
Secondary Region
• IoT CoreのRuleでThing登録、shadow操作
EventをDynamoDBに保存
• SecondaryではDynamoDB streamsを利用し、
Step FunctionsでIoT Coreに反映
証明書の登録は
CA Lessで登録

デモの確認

ソリューションの注意点
• DNSを使ったフェールオーバーの部分は、独⾃のドメインが必要で、⼿動で
登録する必要があります
• セカンダリー側にThingの登録やシャドゥの変更をしてもPrimaryには反映さ
れませんので、実装する必要があります。
• CA less(マルチアカウント)登録された証明書の場合は、IoT Coreの
Credential Providerはできません
• https://docs.aws.amazon.com/iot/latest/developerguide/authori
zing-direct-aws.html

そのDRは本当に必要ですか︖

AWS IoT
Core
IoT
Device
IoT
Device
IoT
Device
Amazon S3
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWS Lambda Amazon
DynamoDB
Amazon API
Gateway
AWS Lambda
QuickSight
証明書
処理が終わって
いないデータ
Global Table
Cross-Region
Replication
その他、検討が必要となってくる部分
業務/
User
アプリ
証明書/
接続先
アプリケーション

許容できるケースはありませんか︖
• スマートホームデバイスであれば、リモコン、デバイス⾃体にボタン、ス
イッチなどで操作できる
• デバイス側にデータをデータを貯めておいて、次回の接続時に送信できる
• 可視化のための業務アプリは復旧後まで待てる
サービスを提供する際にSLAを定義し、
ユーザーに理解していただくことも大切

許容できないケース
• ⼈命に関わるような場合
• 社会的なインフラとなるようなシステムの場合
• ライフラインに関連するようなシステムの場合
• 停⽌することで⼤きな損害が発⽣してしまう場合
このようなユースケースでは、DR対応や可用性を上げる
アーキテクチャの検討が必要になってきます

まとめ

まとめ
• 可⽤性を上げたり、DRに対応することはコスト(料⾦、⼈的)増につながる為、
本当に必要かをビジネスサイドと認識を合わせる必要がある
• サービスによっては多少の停⽌が許容できるのであれば、無理に作りこまな
いという判断も必要
• 部分的に対応する⽅式も検討する

Thank You!

03_AWS IoTのDRを考える

More Related Content

What's hot

Similar to 03_AWS IoTのDRを考える

More from Amazon Web Services Japan

03_AWS IoTのDRを考える