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