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

Transcript

1. Copyright © OPTiM Corp. All Right Reserved. 大規模IoTシステムにおける キャパシティプラニングの実践
2. Copyright © OPTiM Corp. All Right Reserved. 2 熊野(Kumano) 2019年4月OPTiM入社 経歴: フィーチャーフォンのアプリケーション・プラットフォーム開発 -> スタートアップ企業のIoTクラウドプラットフォームのテックリード -> Cloud IoT OS 時系列DB開発プロジェクトPM -> Cloud IoT OS 開発チームマネージャー兼スクラムマスター 得意領域 PaaSの設計・開発 アジャイル開発 Learning 大規模な組織におけるアジャイル開発 趣味 ロードバイク (ロングライド)
3. Copyright © OPTiM Corp. All Right Reserved. 3 We’re Hiring! AI/ IoTで今までになかった新しい価値を一緒に創造し ていく仲間を募集しています！ ご興味を持っていただけましたらご連絡ください。まず はカジュアルにお話だけでも。
4. Copyright © OPTiM Corp. All Right Reserved. 4 キャパシティプラニングの目的 IoTシステムの特徴 キャパシティプラニングの流れ サービスの立ち上げ時からキャパシティプラニングを実施す ることの重要性 キャパシティプラニングの実践的テクニック(基本編) キャパシティプラニングの実践的テクニック(性能編) アジェンダ
5. Copyright © OPTiM Corp. All Right Reserved. 5 キャパシティプラニングの目的
6. Copyright © OPTiM Corp. All Right Reserved. 6 人の欲求:  利用者はできるだけ多く  利用者は毎月どんどん増える  あれもできる、これもできる、それも  システムはいつでもサクサク動く  システム障害は絶対に起こすな  運用コストはできるだけ安くしたい 現実の制約:  想定する利用者の数がわからないとコストは見 積もれない  利用者の数に応じて最適な構成が変わる  機能・性能・可用性・コストにはトレードオフ がある  予算  期間 人の欲求をすべて叶えるシステムを作ることはできない。 現実の制約は、物理的な制約や現在の技術の制約であり、 短期間で制約がなくなることは期待できない
7. Copyright © OPTiM Corp. All Right Reserved. 7 キャパシティプランニングの目的 現実の制約の中で本当にやりたいこと ができる、最も効率的と考えられるシ ステムの姿を明確にする 叶えられる願いは ３つだけです 何を願いますか？
8. Copyright © OPTiM Corp. All Right Reserved. 8 IoTシステムの特徴
9. Copyright © OPTiM Corp. All Right Reserved. 9  デバイスから自動的にデータが蓄積される • 一定の頻度でデータをアップロードする • 負荷は予想しやすいが高負荷になりやすい • デバイスが同じ周期でアップロードできるレスポンス速度が求められる  最新のデータだけでなく、過去データも利用されるため大量のデータが蓄積され る • 保管コストの最適化が必要 • 階層型データストア • 新しいデータは早く取り出せるようにしたい • 古いデータは安いストレージに移動  データの更新は少ない デバイスが自動的に動くため 人間の利用頻度が低くてもコ ストが発生する 想定するビジネスモデルで収 益化できるかの評価が必要に なることが多い
10. Copyright © OPTiM Corp. All Right Reserved. 10 キャパシティプランニングの流れ
11. Copyright © OPTiM Corp. All Right Reserved. 11 要求の整理 アーキテクチャ設計 性能評価 コスト見積もり システム構築時: • 要求を実現する最適なシステムについての理解が浅い • トレードオフを机上の計画だけで見極めるのは困難 • 反復的なプロセスで、仮説立案・検証を繰り返して学習する
12. Copyright © OPTiM Corp. All Right Reserved. 12 継続的な監視 将来の要求整理 システム運用時: • 継続的な監視で、利用状況・傾向を把握する • 将来に備えて構成変更を実施するか決める 構成変更
13. Copyright © OPTiM Corp. All Right Reserved. 13 ケーススタディの題材
14. Copyright © OPTiM Corp. All Right Reserved. 14 10万台のデバイスから計測データを毎秒アップロード ・遅延なく永続化 ・負荷の水平分散によりデバイス台数に応じて構成を増減可能なアーキテクチャ データの欠損はNG 各デバイスの最新情報を「グループ」単位で一括取得 ・10万台のデバイスからのデータ取得に対して0.2s（90 percentile）のAPI応答性能 1年間の過去データ保持で200~300円/月・デバイスの運用コスト ・利用しなくなったデータはグループ単位でアーカイブを実施。必要な時に復元して解析可能とする。 ・99.9%の可用性 IoT クラウドプラットフォーム時系列データストア: 初期の要求
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による一括アッ プロードのサポート デバイスの台数に応じて 水平スケールするため 最適な費用で運用可能 プラットフォーム上の複数のアプリケションで データを活用
16. Copyright © OPTiM Corp. All Right Reserved. 16 OPTiM Cloud IoT OS における時系列データ管理サービスという位置づけ
17. Copyright © OPTiM Corp. All Right Reserved. 17 サービス立ち上げ時から キャパシティプラニングを行うことの重要性
18. Copyright © OPTiM Corp. All Right Reserved. 18 アーキテクチャ上の制約をステークホルダと共有する 重要な要求を低コストで実現するためのアーキテクチャを選択すると、そのアーキ テクチャに固有の制約が発生します。アーキテクチャはサービス開始後は容易には 変更することができませんので採用したアーキテクチャによる制約をステークホル ダに理解してもらうことで、要求の追加や変更を実現可能性を考慮して行えるよう になります RDB Replica Replica DB選択における例 結果整合性 NoSQL NoSQL NoSQL ・アトミックなトランザクションによる一貫性の保証 ・スケールアウトしにくい ・スケールアウトしやすい ・整合していないタイミングがある 厳密な一貫性 NoSQL VS
19. Copyright © OPTiM Corp. All Right Reserved. 19 ケーススタディ RDB Replica Replica 結果整合性 NoSQL NoSQL NoSQL 厳密な一貫性 NoSQL VS 今回のケースでは厳密な整合性が求められていなかったため、NoSQLのDynamo DBを選択しました Dynamo DBの制約 ➢ RDBと比較すると検索機能には制限がある。時系列データの集計処理や、位置情報での絞り込み 等が必要な場合は、アプリケーションレイヤで別途実装する必要がある ➢ データ取り出し時に整合性のある読み込みを行うことは可能。整合性のある読み込みはレイテン シが増える可能性がある。(結果整合性での読み込みも可能) ➢ 時間あたりの読み込み・書き込み回数・データ量による課金体系
20. Copyright © OPTiM Corp. All Right Reserved. 20 アーキテクチャ上の制約を考慮したマネタイズ計画 採用したアーキテクチャによってコストが発生する要因が決まります この要因に対応して収益が増えるビジネスモデルになっていないと利用者が増えて もマネタイズできません 売上 経費
21. Copyright © OPTiM Corp. All Right Reserved. 21 今回のケースではデバイス数と管理用ダッシュボードに同時アクセスする管理ユー ザー数がコスト発生の主要なファクターとなることがわかりました。管理ユーザー 数はデバイス数に比例して増えることが想定されるビジネスモデルであったため、 当初予定していたデバイス台数での課金モデルが、採用するアーキテクチャと整合 することを確認してから開発を進めることができました ケーススタディ デバイス 10万台 管理ユーザー 1万人 平均10台/ 管理ユーザー ・・・・ ・・・・ 同時アクセスする 管理ユーザー 1000人 最大10%が同 時アクセス ・・・・
22. Copyright © OPTiM Corp. All Right Reserved. 22 実践的なテクニック 基本編
23. Copyright © OPTiM Corp. All Right Reserved. 23 前提となる条件は仮置でも決める デバイス 10万台 (目標) 管理ユーザー 1万人 (仮置) 平均10台/ 管理ユーザー ・・・・ ・・・・ 同時アクセスする 管理ユーザー 1000人 (仮置) 最大10%が同 時アクセス ・・・・ 前述のデバイス数、管理ユーザーと同時アクセスする管理ユーザーの比率は顧客も 予想することはできませんでした。 しかし数値を置かないとコスト試算や、性能評価はできません。 顧客やビジネスドメインのエキスパートの直感を頼りにしてまずは仮置でもコスト 試算や性能評価ができる前提をスピーディに決めましょう。数値が実際の値とは異 なってもコスト・性能・可用性をモデル化できていれば、柔軟に対応できます。
24. Copyright © OPTiM Corp. All Right Reserved. 24 可用性や信頼性は障害シナリオと方策に合意する 稼働率やデータロストの確率は数値で表す事ができますが、実際のシステムでの見 込みを確率で表現することは実は困難です。クラウドインフラストラクチャを利用 する場合、プロバイダーはSLAに稼働率を定義している場合がありますが、実際の 可用性ではなく、ダウンが発生した場合にSLAで定められた行為(返金等)を履行す るかどうかの閾値です。 公開されているSLAから計算した稼働率が目標とする稼働率を下回る場合はアーキ テクチャの見直しが必要ですが、上回っていたとしてもステークホルダーが安心で きる材料にはなりません システムに発生する障害のシナリオと対応する方策について理解してもらうことが 重要です。
25. Copyright © OPTiM Corp. All Right Reserved. 25 マルチアベイラビリティゾーンでの冗長化 • 対応できる異常シナリオ: データセンターの 障害 • 対応できない異常シナリオ: リージョンの障 害 • 対応コスト: 低 ケーススタディ① クラウドインフラストラクチャの冗長性のレベルとコストに合意する マルチリージョンでの冗長化 • 対応できる異常シナリオ: データセンターの 障害、リージョンの障害 • 対応できない異常シナリオ: 複数リージョン をまたぐ障害 • 対応コスト: かなり高い (正確に見積もる前 に対応の規模感を伝える) マルチリージョン対応すると、アプリケーション側 での対応工数がかかるのと、ランニングコストも上 がる可能性ありますが見積もりますか？ そこまでは必要ないです。 マルチアベイラビリティーゾーンでの冗長化はお願 いします 顧客
26. Copyright © OPTiM Corp. All Right Reserved. 26 ケーススタディ② データロストのシナリオと回避策を明確にする APIサーバー 計測データ Kinesis Data Stream Dynamo DB S3 バックアップ用S3 (別リージョン) エラー発生時は デバイスがリトライ エラー発生時は デバイスにエラー伝達 デバイスがリトライ エラー発生時はリトライする が回復しない場合はバック アップ用S3に退避 バックアップ用S3がダウンして いる場合はデータロスト (エラーを監視して、Kinesisから 削除される前に保全することは 可能) エラーの場合 ※レスポンスタイムが優先のためAPIサーバーでリトライはしない
27. Copyright © OPTiM Corp. All Right Reserved. 27 フィジビリティを確認するフェーズを設ける 性能、可用性、コストの目標とその前提となる条件をスピーディに決めて評価を始 めることは重要ですが、フィジビリティを確認せずにステークホルダーと約束して しまうと、実現できなかった時にトラブルになります。 ケーススタディのプロジェクトでは半年間でフィジビリティを確認して、その後に 実開発を進める形で顧客と契約をしました。
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円/デバイス月 アーキテクチャやコストに影響のある要素は 検討を進めていくうちに変化するので、変 数・モデルを更新していく
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 コスト(円) 線形に水平スケールでき ているので 台数が増えてもコスト要 求を実現できそうです
30. Copyright © OPTiM Corp. All Right Reserved. 30 実践的なテクニック 性能編
31. Copyright © OPTiM Corp. All Right Reserved. 31 IoTのWebシステムを構成する各サービスの性能は様々な要因でばらつきます。リアルタイムシス テムのようにばらつきをコントロールすることはできないため、「必ずXXms未満でレスポンスし ます」という目標を設定すると、かなり大きな値を設定しなければ目標を満たせなくなります。こ れでは目標を満たしていても、快適な利用体験を提供できてるかどうか判断できません 「全リクエストのうち90%のリクエストがXXms未満でレスポンスできます」のようにパーセンタ イル値で目標を設定することで、快適な利用体験を提供できてるかどうかの指標を現実的に定義す ることができます 性能目標はパーセンタイル値で設定する
32. Copyright © OPTiM Corp. All Right Reserved. 32 レスポンスタイムは複数サービスのレスポンスタイムにより決まります 各サービスはDBなどのインフラ、自社で開発しているサービスの場合もあります。性能目標を満た すためにどのサービスでどれだけの時間を使えるのかを仮置することで、これから開発するサービス、 既存の自社サービス、インフラにどの程度のレスポンスタイムが求められるのかの目安がわかります。 サービス単体での評価が可能となり、システムの結合前にフィジビリティに関してより多くの知見を 得る事ができます。 サービスごとに細分化した性能目標を仮置する 権限チェックサービスAPI呼び 出し KinesisへのPublish 計測データUpload APIでの処理内訳 目標: 200ms未満(p90) 目標: 100ms未満(p90) 目標: 100ms未満(p90) サービスごとの目標を細分化 して設定することで、分担し てサービスの性能評価を実施 できるようになる 権限チェックサー ビス見るよ！ Kinesis見るよ！
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) 単体評価実績 単体評価 実績 権限チェックサービス の性能改善が必須！
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秒くらい遅れるけど 気にならないな
35. Copyright © OPTiM Corp. All Right Reserved. 35 性能を計測できる仕組みを最初のデプロイから実装しておくことで、結合後すぐに性能試験を始めることが可能 になります。デプロイが終わるとステークホルダーの関心が別のプロジェクトに移ってしまうこともあります。 サービス開始後も性能を継続的に監視できるため、素早く問題に対処したり、問い合わせに対して迅速に対応す ることが可能になります 最初のデプロイから性能を計測できる仕組みを実装する Open TracingとDatadogによる可視化
36. Copyright © OPTiM Corp. All Right Reserved. 36 結合性能試験では、単体試験の結果の積み上げが実際に正しいか、単体試験では評価が難しいアプリ ケーション・サーバーの性能や構成の確認、結合状態でのチューニングなどを行います 結合性能試験 Node Container Container Pod Pod Node Container Container Pod Pod ・・・・・ 結合性能試験検証すること ・Nodeに割り当てるVMのスペックと費用 ・Pod数/ Node ・コンテナの配置(スケジューリング) Kubernatesを用いたアプリケーション・サーバーの構成
37. Copyright © OPTiM Corp. All Right Reserved. 37 結合評価も無事終えて、サービスのデプロイにこぎつけました！ まだ終わりではありません！ サービスの利用状況は日々変化します。利用状況の変化に応じて、スケール(in, out, up, down)を 実施することで性能の維持とコストの最適化を行う必要があります。 そのためには継続的に利用状況を監視する必要があります 継続的な監視 Datadogを用いた監視 Alert/ Warning
38. Copyright © OPTiM Corp. All Right Reserved. 38 まとめ
39. Copyright © OPTiM Corp. All Right Reserved. 39  サービスの立ち上げ時からキャパシティプランニングを行うことを検討する • クライアントサイドでの処理がメインなど、サービスの特性によっては不要な場 合もある  すべてを理解してから行動しようとしない。直感も駆使して素早く仮定を置き、観 測、改善のサイクルを回す  最初から１００点を目指さない。観測と改善を繰り返してアーキテクチャ、コスト モデルを改善する  結合前に単体の検証を行う  ステークホルダーに伝わる言葉で、トレードオフを説明しよう。後で必ずお互いの 役に立つ  性能を可視化・監視できる仕組みを最初のデプロイから作っておく  サービス提供後も継続的に監視する