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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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による一括アップロードのサポートデバイスの台数に応じて水平スケールするため最適な費用で運用可能プラットフォーム上の複数のアプリケションでデータを活用

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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円/デバイス月アーキテクチャやコストに影響のある要素は検討を進めていくうちに変化するので、変数・モデルを更新していく

Slide 29

Slide 29 text

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 コスト(円) 線形に水平スケールできているので台数が増えてもコスト要求を実現できそうです

Slide 30

Slide 30 text

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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) 単体評価実績単体評価実績権限チェックサービスの性能改善が必須！

Slide 34

Slide 34 text

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秒くらい遅れるけど気にならないな

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Slide 39

Slide 39 text

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