大規模IoTシステムにおけるキャパシティプランニングの実践 / capacity-planning-iot

Copyright © OPTiM Corp. All Right Reserved.
大規模IoTシステムにおける
キャパシティプラニングの実践

View Slide

Copyright © OPTiM Corp. All Right Reserved. 2
熊野(Kumano)
2019年4月OPTiM入社
経歴:
フィーチャーフォンのアプリケーション・プラットフォーム開発 ->
スタートアップ企業のIoTクラウドプラットフォームのテックリード ->
Cloud IoT OS 時系列DB開発プロジェクトPM ->
Cloud IoT OS 開発チームマネージャー兼スクラムマスター
得意領域
PaaSの設計・開発
アジャイル開発
Learning
大規模な組織におけるアジャイル開発
趣味
ロードバイク (ロングライド)

View Slide

We’re Hiring!
AI/ IoTで今までになかった新しい価値を一緒に創造し
ていく仲間を募集しています！
ご興味を持っていただけましたらご連絡ください。まず
はカジュアルにお話だけでも。

View Slide

キャパシティプラニングの目的
IoTシステムの特徴
キャパシティプラニングの流れ
サービスの立ち上げ時からキャパシティプラニングを実施す
ることの重要性
キャパシティプラニングの実践的テクニック(基本編)
キャパシティプラニングの実践的テクニック(性能編)
アジェンダ

View Slide

キャパシティプラニングの目的

View Slide

人の欲求:
 利用者はできるだけ多く
 利用者は毎月どんどん増える
 あれもできる、これもできる、それも
 システムはいつでもサクサク動く
 システム障害は絶対に起こすな
 運用コストはできるだけ安くしたい
現実の制約:
 想定する利用者の数がわからないとコストは見
積もれない
 利用者の数に応じて最適な構成が変わる
 機能・性能・可用性・コストにはトレードオフ
がある
 予算
 期間
人の欲求をすべて叶えるシステムを作ることはできない。
現実の制約は、物理的な制約や現在の技術の制約であり、
短期間で制約がなくなることは期待できない

View Slide

キャパシティプランニングの目的
現実の制約の中で本当にやりたいこと
ができる、最も効率的と考えられるシ
ステムの姿を明確にする
叶えられる願いは
３つだけです
何を願いますか？

View Slide

IoTシステムの特徴

View Slide

 デバイスから自動的にデータが蓄積される
• 一定の頻度でデータをアップロードする
• 負荷は予想しやすいが高負荷になりやすい
• デバイスが同じ周期でアップロードできるレスポンス速度が求められる
 最新のデータだけでなく、過去データも利用されるため大量のデータが蓄積され
る
• 保管コストの最適化が必要
• 階層型データストア
• 新しいデータは早く取り出せるようにしたい
• 古いデータは安いストレージに移動
 データの更新は少ない
デバイスが自動的に動くため
人間の利用頻度が低くてもコ
ストが発生する
想定するビジネスモデルで収
益化できるかの評価が必要に
なることが多い

View Slide

キャパシティプランニングの流れ

View Slide

要求の整理
アーキテクチャ設計
性能評価
コスト見積もり
システム構築時:
• 要求を実現する最適なシステムについての理解が浅い
• トレードオフを机上の計画だけで見極めるのは困難
• 反復的なプロセスで、仮説立案・検証を繰り返して学習する

View Slide

継続的な監視
将来の要求整理
システム運用時:
• 継続的な監視で、利用状況・傾向を把握する
• 将来に備えて構成変更を実施するか決める
構成変更

View Slide

ケーススタディの題材

View Slide

10万台のデバイスから計測データを毎秒アップロード
・遅延なく永続化
・負荷の水平分散によりデバイス台数に応じて構成を増減可能なアーキテクチャ
データの欠損はNG
各デバイスの最新情報を「グループ」単位で一括取得
・10万台のデバイスからのデータ取得に対して0.2s（90 percentile）のAPI応答性能
1年間の過去データ保持で200~300円/月・デバイスの運用コスト
・利用しなくなったデータはグループ単位でアーカイブを実施。必要な時に復元して解析可能とする。
・99.9%の可用性
IoT クラウドプラットフォーム時系列データストア: 初期の要求

View Slide

Copyright © OPTiM Corp. All Right Reserved.
IoT クラウドプラットフォーム時系列データストア概要
AWS Kinesis
グループ
REST
API
Stream
API
(Output)
Stream
Consumer
管理者/分析者
IdM
10万件/秒の計測
データアップ
ロード
分散Stream処理基盤
リアルタイム性・信頼性の高いシ
ステムを構築
Stream
Consumer
Kineisis
Consumer
過去データは、グループ
単位でS3にアーカイブ。
必要な際にリストア可能
大量に蓄積されるデータを
階層型DBで効率よく保存
・最新データはキューから直接配信可能
・グループ単位のChannelによる全デバイ
スの最新位置情報一括取得
10万件/秒のInsert
3万件/秒の参照
最新データ (Mongo DB)
- 到達から保存までLatency1秒
以内
- 取り出しレスポンス0.2秒
時系列データ (Dynamo DB)
- 分散DBを採用し、データ数
の増加しても劣化しないパ
フォーマンス
10万件/秒のInsert
水平分散に
よる高速化・
可用性担保
グループ単位でのアクセス制御
閲覧者
Bulk Uploadによる一括アッ
プロードのサポート
デバイスの台数に応じて
水平スケールするため
最適な費用で運用可能
プラットフォーム上の複数のアプリケションで
データを活用

View Slide

OPTiM Cloud IoT OS における時系列データ管理サービスという位置づけ

View Slide

サービス立ち上げ時から
キャパシティプラニングを行うことの重要性

View Slide

アーキテクチャ上の制約をステークホルダと共有する
重要な要求を低コストで実現するためのアーキテクチャを選択すると、そのアーキ
テクチャに固有の制約が発生します。アーキテクチャはサービス開始後は容易には
変更することができませんので採用したアーキテクチャによる制約をステークホル
ダに理解してもらうことで、要求の追加や変更を実現可能性を考慮して行えるよう
になります
RDB Replica Replica
DB選択における例
結果整合性
NoSQL NoSQL NoSQL
・アトミックなトランザクションによる一貫性の保証
・スケールアウトしにくい
・スケールアウトしやすい
・整合していないタイミングがある
厳密な一貫性
NoSQL
VS

View Slide

ケーススタディ
RDB Replica Replica
結果整合性
NoSQL NoSQL NoSQL
厳密な一貫性
NoSQL
VS
今回のケースでは厳密な整合性が求められていなかったため、NoSQLのDynamo
DBを選択しました
Dynamo DBの制約
➢ RDBと比較すると検索機能には制限がある。時系列データの集計処理や、位置情報での絞り込み
等が必要な場合は、アプリケーションレイヤで別途実装する必要がある
➢ データ取り出し時に整合性のある読み込みを行うことは可能。整合性のある読み込みはレイテン
シが増える可能性がある。(結果整合性での読み込みも可能)
➢ 時間あたりの読み込み・書き込み回数・データ量による課金体系

View Slide

アーキテクチャ上の制約を考慮したマネタイズ計画
採用したアーキテクチャによってコストが発生する要因が決まります
この要因に対応して収益が増えるビジネスモデルになっていないと利用者が増えて
もマネタイズできません
売上
経費

View Slide

今回のケースではデバイス数と管理用ダッシュボードに同時アクセスする管理ユー
ザー数がコスト発生の主要なファクターとなることがわかりました。管理ユーザー
数はデバイス数に比例して増えることが想定されるビジネスモデルであったため、
当初予定していたデバイス台数での課金モデルが、採用するアーキテクチャと整合
することを確認してから開発を進めることができました
ケーススタディ
デバイス 10万台管理ユーザー 1万人
平均10台/
管理ユーザー
・・・・・・・・
同時アクセスする
管理ユーザー 1000人
最大10%が同
時アクセス
・・・・

View Slide

実践的なテクニック
基本編

View Slide

前提となる条件は仮置でも決める
デバイス 10万台 (目標) 管理ユーザー 1万人 (仮置)
平均10台/
管理ユーザー
・・・・・・・・
同時アクセスする
管理ユーザー 1000人 (仮置)
最大10%が同
時アクセス
・・・・
前述のデバイス数、管理ユーザーと同時アクセスする管理ユーザーの比率は顧客も
予想することはできませんでした。
しかし数値を置かないとコスト試算や、性能評価はできません。
顧客やビジネスドメインのエキスパートの直感を頼りにしてまずは仮置でもコスト
試算や性能評価ができる前提をスピーディに決めましょう。数値が実際の値とは異
なってもコスト・性能・可用性をモデル化できていれば、柔軟に対応できます。

View Slide

可用性や信頼性は障害シナリオと方策に合意する
稼働率やデータロストの確率は数値で表す事ができますが、実際のシステムでの見
込みを確率で表現することは実は困難です。クラウドインフラストラクチャを利用
する場合、プロバイダーはSLAに稼働率を定義している場合がありますが、実際の
可用性ではなく、ダウンが発生した場合にSLAで定められた行為(返金等)を履行す
るかどうかの閾値です。
公開されているSLAから計算した稼働率が目標とする稼働率を下回る場合はアーキ
テクチャの見直しが必要ですが、上回っていたとしてもステークホルダーが安心で
きる材料にはなりません
システムに発生する障害のシナリオと対応する方策について理解してもらうことが
重要です。

View Slide

マルチアベイラビリティゾーンでの冗長化
• 対応できる異常シナリオ: データセンターの
障害
• 対応できない異常シナリオ: リージョンの障
害
• 対応コスト: 低
ケーススタディ①
クラウドインフラストラクチャの冗長性のレベルとコストに合意する
マルチリージョンでの冗長化
• 対応できる異常シナリオ: データセンターの
障害、リージョンの障害
• 対応できない異常シナリオ: 複数リージョン
をまたぐ障害
• 対応コスト: かなり高い (正確に見積もる前
に対応の規模感を伝える)
マルチリージョン対応すると、アプリケーション側
での対応工数がかかるのと、ランニングコストも上
がる可能性ありますが見積もりますか？
そこまでは必要ないです。
マルチアベイラビリティーゾーンでの冗長化はお願
いします
顧客

View Slide

ケーススタディ②
データロストのシナリオと回避策を明確にする
APIサーバー
計測データ
Kinesis Data Stream
Dynamo DB
S3
バックアップ用S3
(別リージョン)
エラー発生時は
デバイスがリトライ
エラー発生時は
デバイスにエラー伝達
デバイスがリトライ
エラー発生時はリトライする
が回復しない場合はバック
アップ用S3に退避
バックアップ用S3がダウンして
いる場合はデータロスト
(エラーを監視して、Kinesisから
削除される前に保全することは
可能)
エラーの場合
※レスポンスタイムが優先のためAPIサーバーでリトライはしない

View Slide

フィジビリティを確認するフェーズを設ける
性能、可用性、コストの目標とその前提となる条件をスピーディに決めて評価を始
めることは重要ですが、フィジビリティを確認せずにステークホルダーと約束して
しまうと、実現できなかった時にトラブルになります。
ケーススタディのプロジェクトでは半年間でフィジビリティを確認して、その後に
実開発を進める形で顧客と契約をしました。

View Slide

コスト、性能、可用性、前提条件をモデル化する
前提条件を変数とし、性能目標、可用性目標を満たすアーキテクチャにおけるコス
トを出力するモデルを作る
Dynamo DB単価 Dynamo DB WCU (USD/ Unit) 0.000742
Dynamo DB RCU (USD/ Unit) 0.0001484
Dynamo DB Storage (USD/ GB) 0.285
継続的バックアップ (USD/ GB) 0.228
サービス要求稼働日数 (Days/Year) 365
稼働時間 (Hour) 8
アップロードのInterval (秒) 1
データサイズ (Bytes) 300
デバイス台数 100000
時系列データ履歴(1デバイス・1日分)API並列数 1000
年間データサイズ (GB) 315360
月間平均データサイズ (GB) 26280
S3単価 Storage (USD/ GB月) 0.025
PUT (USD / 1000 Req) 0.0047
S3 まとめて書き込むレコード数 100
為替 USD ( 円) 110
Mongo DB Atlas 時間単価 (USD/Hour) 16.97
Kinesis単価シャード時間 (USD/ Hour) 0.0195
PUT ペイロードユニット、 USD/1,000,000 0.0215
拡張データ保持期限シャード時間ごと (USD/ Hour) 0.026
拡張ファンアウトでのデータ取り出し (USD/GB) 0.0169
拡張ファンアウト、コンシューマーのシャード時間
(USD/ Hour)
0.0195
Kinesis 拡張ファンアウト数 5
データ保持期間(日) 7
シャード時間 730
変数: X コストのモデル
Dynamo DB月額料金: F(X) = 0.000742 * …
Kinesis月額料金 G(X) = 0.0198 * 8 * …
…
…
…
Mongo DB 月額料金 O(X) = …
月総額 = T(X) = F(X) + G(X) + … + O(X)
評価式 = T(X) / 100000(台) < 300円/デバイス月
アーキテクチャやコストに影響のある要素は
検討を進めていくうちに変化するので、変
数・モデルを更新していく

View Slide

線形にスケールすることを確認する
10万台が毎秒アップロードできることを直接的に確認するのは大変です。
ケーススタディのプロジェクトでは実際にはいきなり10万台が導入されるわけでは
なく、将来を見据えての目標だったため、1000台、2000台、5000台の性能・コス
トを確認して10万台における実現性を確認する方法を取りました
0
200000
400000
600000
800000
1000000
1200000
1400000
1600000
0 1000 2000 3000 4000 5000 6000
コスト(円)
線形に水平スケールでき
ているので
台数が増えてもコスト要
求を実現できそうです

View Slide

実践的なテクニック
性能編

View Slide

IoTのWebシステムを構成する各サービスの性能は様々な要因でばらつきます。リアルタイムシス
テムのようにばらつきをコントロールすることはできないため、「必ずXXms未満でレスポンスし
ます」という目標を設定すると、かなり大きな値を設定しなければ目標を満たせなくなります。こ
れでは目標を満たしていても、快適な利用体験を提供できてるかどうか判断できません
「全リクエストのうち90%のリクエストがXXms未満でレスポンスできます」のようにパーセンタ
イル値で目標を設定することで、快適な利用体験を提供できてるかどうかの指標を現実的に定義す
ることができます
性能目標はパーセンタイル値で設定する

View Slide

レスポンスタイムは複数サービスのレスポンスタイムにより決まります
各サービスはDBなどのインフラ、自社で開発しているサービスの場合もあります。性能目標を満た
すためにどのサービスでどれだけの時間を使えるのかを仮置することで、これから開発するサービス、
既存の自社サービス、インフラにどの程度のレスポンスタイムが求められるのかの目安がわかります。
サービス単体での評価が可能となり、システムの結合前にフィジビリティに関してより多くの知見を
得る事ができます。
サービスごとに細分化した性能目標を仮置する
権限チェックサービスAPI呼び
出し KinesisへのPublish
計測データUpload APIでの処理内訳
目標: 200ms未満(p90)
目標: 100ms未満(p90) 目標: 100ms未満(p90)
サービスごとの目標を細分化
して設定することで、分担し
てサービスの性能評価を実施
できるようになる
権限チェックサー
ビス見るよ！
Kinesis見るよ！

View Slide

Mongo DB, Dynamo DB, S3などのデータストアや、Kinesis等のメッセージキューについては実
サービスで利用するデータ構造やテーブル構造が決まれば単体で評価が可能です。
また依存関係のある自社のサービスについてもAPIの呼び出し条件が決まっていれば単体で評価でき
ます。
結合前に単体で性能評価できる部分を先行して評価することで、最適なサービスを選択したり、自社
のサービスの性能を評価して改善が必要かどうかを判断することが可能になります
結合前に単体で性能評価できる部分を評価する
権限チェックサービスAPI呼び
出し KinesisへのPublish
計測データUpload APIでの処理内訳
目標: 200ms未満(p90)
目標: 100ms未満(p90) 目標: 100ms未満(p90)
単体評価実績
単体評価
実績
権限チェックサービス
の性能改善が必須！

View Slide

Kinesis Data StreamなどのPub/ SubフレームワークではMessageがPublishされてからSubscribe
されるまでのレイテンシ(End to Endレイテンシ)が快適なユーザー体験に影響を及ぼす場合があり
ます。
End to Endレイテンシを性能目標に含めて監視できるようにすることで、Pub/ Subフレームワー
ク利用メリットの享受と快適なユーザー体験を両立することができるようになります
Pub/ SubフレームワークのEnd to Endのレイテンシを性能目標に含める
APIサーバー
①計測データ
Kinesis Data Stream
②Publish
③Upload OK
[③非同期] Subscribe＆永続化
[③非同期] Subscribe＆永続化
目標: Publishから永続化まで1秒(p90)
Dynamo
DB
1秒くらい遅れるけど
気にならないな

View Slide

性能を計測できる仕組みを最初のデプロイから実装しておくことで、結合後すぐに性能試験を始めることが可能
になります。デプロイが終わるとステークホルダーの関心が別のプロジェクトに移ってしまうこともあります。
サービス開始後も性能を継続的に監視できるため、素早く問題に対処したり、問い合わせに対して迅速に対応す
ることが可能になります
最初のデプロイから性能を計測できる仕組みを実装する
Open TracingとDatadogによる可視化

View Slide

結合性能試験では、単体試験の結果の積み上げが実際に正しいか、単体試験では評価が難しいアプリ
ケーション・サーバーの性能や構成の確認、結合状態でのチューニングなどを行います
結合性能試験
Node
Container Container
Pod Pod
Node
Container Container
Pod Pod ・・・・・
結合性能試験検証すること
・Nodeに割り当てるVMのスペックと費用
・Pod数/ Node
・コンテナの配置(スケジューリング)
Kubernatesを用いたアプリケーション・サーバーの構成

View Slide

結合評価も無事終えて、サービスのデプロイにこぎつけました！
まだ終わりではありません！
サービスの利用状況は日々変化します。利用状況の変化に応じて、スケール(in, out, up, down)を
実施することで性能の維持とコストの最適化を行う必要があります。
そのためには継続的に利用状況を監視する必要があります
継続的な監視
Datadogを用いた監視
Alert/
Warning

View Slide

まとめ

View Slide

 サービスの立ち上げ時からキャパシティプランニングを行うことを検討する
• クライアントサイドでの処理がメインなど、サービスの特性によっては不要な場
合もある
 すべてを理解してから行動しようとしない。直感も駆使して素早く仮定を置き、観
測、改善のサイクルを回す
 最初から１００点を目指さない。観測と改善を繰り返してアーキテクチャ、コスト
モデルを改善する
 結合前に単体の検証を行う
 ステークホルダーに伝わる言葉で、トレードオフを説明しよう。後で必ずお互いの
役に立つ
 性能を可視化・監視できる仕組みを最初のデプロイから作っておく
 サービス提供後も継続的に監視する

View Slide

大規模IoTシステムにおけるキャパシティプランニングの実践 / capacity-planning-iot

大規模IoTシステムにおけるキャパシティプランニングの実践 / capacity-planning-iot

optim

More Decks by optim

Other Decks in Programming

Featured

Transcript