Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

optim
March 11, 2021

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

optim

March 11, 2021
Tweet

More Decks by optim

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  5. Copyright © OPTiM Corp. All Right Reserved. 5
    キャパシティプラニングの目的

    View Slide

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

    View Slide

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

    View Slide

  8. Copyright © OPTiM Corp. All Right Reserved. 8
    IoTシステムの特徴

    View Slide

  9. Copyright © OPTiM Corp. All Right Reserved. 9
     デバイスから自動的にデータが蓄積される
    • 一定の頻度でデータをアップロードする
    • 負荷は予想しやすいが高負荷になりやすい
    • デバイスが同じ周期でアップロードできるレスポンス速度が求められる
     最新のデータだけでなく、過去データも利用されるため大量のデータが蓄積され

    • 保管コストの最適化が必要
    • 階層型データストア
    • 新しいデータは早く取り出せるようにしたい
    • 古いデータは安いストレージに移動
     データの更新は少ない
    デバイスが自動的に動くため
    人間の利用頻度が低くてもコ
    ストが発生する
    想定するビジネスモデルで収
    益化できるかの評価が必要に
    なることが多い

    View Slide

  10. Copyright © OPTiM Corp. All Right Reserved. 10
    キャパシティプランニングの流れ

    View Slide

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

    View Slide

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

    View Slide

  13. Copyright © OPTiM Corp. All Right Reserved. 13
    ケーススタディの題材

    View Slide

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

    View Slide

  15. 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

  16. Copyright © OPTiM Corp. All Right Reserved. 16
    OPTiM Cloud IoT OS における時系列データ管理サービスという位置づけ

    View Slide

  17. Copyright © OPTiM Corp. All Right Reserved. 17
    サービス立ち上げ時から
    キャパシティプラニングを行うことの重要性

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  22. Copyright © OPTiM Corp. All Right Reserved. 22
    実践的なテクニック
    基本編

    View Slide

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

    View Slide

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

    View Slide

  25. Copyright © OPTiM Corp. All Right Reserved. 25
    マルチアベイラビリティゾーンでの冗長化
    • 対応できる異常シナリオ: データセンターの
    障害
    • 対応できない異常シナリオ: リージョンの障

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

    View Slide

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

    View Slide

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

    View Slide

  28. Copyright © OPTiM Corp. All Right Reserved. 28
    コスト、性能、可用性、前提条件をモデル化する
    前提条件を変数とし、性能目標、可用性目標を満たすアーキテクチャにおけるコス
    トを出力するモデルを作る
    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

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

    View Slide

  30. Copyright © OPTiM Corp. All Right Reserved. 30
    実践的なテクニック
    性能編

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  34. Copyright © OPTiM Corp. All Right Reserved. 34
    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

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

    View Slide

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

    View Slide

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

    View Slide

  38. Copyright © OPTiM Corp. All Right Reserved. 38
    まとめ

    View Slide

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

    View Slide