なめらか&リアルタイムな 動態管理を支えるCariotのAWS基盤 / cariot-xtech-jaws

第9回のX-Tech JAWS「祝2周年！神様、クラウドをありがとう！」で発表した時のスライドです（一部校正してあります）

レポート：
X-Tech JAWSで聞いたコネクテッドカーサービスのAWS活用術
https://ascii.jp/elem/000/004/012/4012192/

Transcript

1. 1 なめらか&リアルタイムな 動態管理を支えるCariotのAWS基盤 Cariot 事業部　製品開発部 遠藤　匠
2. 2 自己紹介 名前 遠藤　匠 Cariot歴 2015.05〜（Cariotと名前がついたのは2015.6） 好きなAWS サービス AWS CodeBuild AWS Cost Explorer Amazon Athena
3. 3 Agenda ▪ Cariot紹介 ▪ Cariotの特徴〜なめらか＆リアルタイム〜 ▪ なめらか＆リアルタイムを支えるAWS基盤
4. 4 Cariot紹介 〜コネクテッド・カー・サービス〜 シガーソケットタイプ ドライブレコーダータイプ スマホタイプ（Cariot Mobile） 車両管理 ドライバー情報管理 運転車両日報／走行履歴 予約管理・運行予実 車両管理レポート ダッシュボード 危険運転検知・動画記録 ルート配送の最適化 運行状況の リアルタイム可視化 駐車イベントマップ DriveCast
5. 5 Cariotの特徴　〜なめらか＆リアルタイム〜 コネクテッド・カーアプリケーションの機能別比較（株式会社フレクト調べ） Cariotビジネスのきっかけ 「シャトルバスのリアルタイムナビゲーションの案件」 バスの位置がリアルタイムに検知できるからこそ、無駄な バスの待ち時間の削減に メッセージアプリなどでも、メッセージが読まれたらすぐ に『既読』と表示されるなど、クラウドを介してリアルタ イムに状況が把握できるからこその安心感や、成立するコ ミュニケーションが多数。 コネクテッド・カーでもリアルタイムに繋がっているから こそ、これまでとは違った価値・体験が実現できるはず！ 到着予測 到着・出発検知 DriveCast 走行履歴 解像度の高い なめらかな 正確な 見逃さない
6. 6 なめらか＆リアルタイムのためのインフラ要件 ▪ データの損失をなくすこと ▪ なるべくマネージドなサービスを使って運用負荷を下げる ▪ スケールしやすい構成 ▪ リアルタイム性を担保する（データは3秒に1回送信）
7. 7 リアルタイム性 ▪ そもそもリアルタイムとは ▪ 今回は「データが発生してから、一定時間以内に処理されること」とします ▪ リアルタイム性を保つためには ▪ データの詰まりが起きないこと ▪ いつでも「データの流入量 ＜ 処理可能な量」を保つこと ▪ Cariotの場合、遅延が30秒を超えたら要注 意、10分を超えたら重大インシデント 流入量 処理可能な量
8. 8 Cariotは、AWSで構築されたIoTプラットフォーム 収集 処理・分析 保存 活用 Amazon Athena EC2 AWS Lambda Amazon Kinesis Data Streams Amazon DynamoDB Amazon RDS Amazon API Gateway Amazon QuickSight アプリケーション (Salesforce Platform)
9. 9 Amazon Kinesis Data Streams AWS Lambda Amazon DynamoDB リアルタイムデータ処理を支える メインのパイプライン
10. 10 初期の頃はこれでうまく行っていたが… Amazon Kinesis Data Streams AWS Lambda Amazon DynamoDB
11. 11 サービスの成長に伴い、リアルタイム処理が求められる機能が増えてきた 急制動（急ブレーキなど） 検知 方向判定 ジオフェンス （到着・出発・通過） 判定 到着時間予測 拠点内速度超過検出 累積走行距離 計算 Webhook送信 Salesforce連携
12. 12 Lambda単体で、現実的な時間内にリアルタイム処理をやり切るのは厳しい Kinesis Data Streams Lambda 外部サイト（Webhook送信先） Google Maps Platform DynamoDB RDS ElastiCache (Redis) etc. • 複雑化するビジネスロジック • 様々な外部リソースへの依存
13. 13 リアルタイム処理のための 三種の神器(Kinesis, Lambda, DynamoDB)の 限界性能を引き出したい！ なめらか＆リアルタイムは CariotのDNAなので・・・
14. 14 各サービスの特性をよく知り、 ワークロードに合った構成・パラメータを選び、 設計する
15. 15 Kinesis Data Streams編
16. 16 Kinesis Data Streams 〜特性〜 ▪ 1シャードの上限は、1秒間あたり、1MB or 1,000レコード ▪ デバイスからのデータは、サイズの小さく、多量のデータなので、大体1,000 レコードの制限が先に引っかかり、ムダが多い ▪ 足りなくなったら、シャードを増やす（スケールアウト）が基本だが、シャー ド時間に対して課金がかかるため、コストに影響する
17. 17 Kinesis Data Streams 〜少ないシャードで効率的に収集する〜 ▪ 集約(aggregation)を利用する ▪ 要するに1レコードにいっぱい詰め込む ▪ AWS謹製のAmazon Kinesis Producer Libraryにバンドルされているので、組み込んで使うだ け ▪ 集約が効き始めるのは、最初のレコード書き込みから少し経ってから（ちょっとハマった話） ▪ 少ないAPIコール数で済むため、余分なTCP接続のオーバーヘッドを減らせるので、処理時間 的にも有利 item1 item2 item3 item4 item5 1MB Record Protobuf Header Protobuf Footer
18. 18 Lambda編
19. 19 Kinesis × Lambda EC2 (receiver) 1回の呼び出しで渡される レコードの最大値＝バッチサイズ 同時実行数は シャード毎に常に1 シャード毎の順番保証 1秒に1回の ポーリング Shard1 Shard2 ShardN GetRecords
20. 20 Lambda 〜特性〜 ▪ Lambdaのコンピューティング性能 ▪ メモリサイズに比例して、CPUパワー・コア数が決まる ▪ 128MB〜3008MBの範囲で、基本的に3008MBを選んだ時の性能で頭打ち ▪ アップデートにより、上限は10240MBに ▪ Lambdaの処理が正常終了しない限り、同じレコードで何度もリトライされる ▪ アップデートにより、リトライ時の動きをカスタムできるように ▪ 課金対象の実行時間は100ミリ秒単位で切り上げられるが、実際の呼び出しはそれより短い頻度で行われ る。 ▪ アップデートにより、1ミリ秒単位に
21. 21 Lambda単体だと頭打ちするので、スケール可能なEC2に流す（ファンアウト） Kinesis Data Streams Lambda ALB EC2 Backend DynamoDB Lambdaは基本的に 横流し リアルタイムデータ処理は全て バックエンド側のEC2が行う
22. 22 Lambda〜設定の勘所〜 適切なバッチサイズ 適切なメモリ 適切なタイムアウト • バッチサイズ分のレコードが溜まるまで、Lambda関数が呼ばれないわけ ではない • 理想は、タイムアウトせずに処理可能な限界値（最大10,000） • Kinesisのレコード集約を使っていると、これより大きい数を処理しなけ ればならなくなることがあるのは注意 • コストを無視すれば、大きいほどよい • 実際のリアルタイム処理部分をEC2にオフロードしているとは言え、 HTTPS通信部分がCPU時間を使う • Cariotでは、バランスをとって512MBを選択 • 基本的にタイムアウトが起きる事自体が好ましくないので、地 道にチューニングを重ねる
23. 23 DynamoDB編
24. 24 DynamoDB 最初が一番大事
25. 25 DynamoDB ▪ 後からできること ▪ 有効期限(TTL)属性の設定 ▪ インデックスの作成と削除 ▪ キャパシティコントロール ▪ など ▪ 後でできないこと ▪ テーブル名の変更 ▪ プライマリキーの変更 ▪ 分割されたパーティションの再統合、というよりパーティション操作全般 ▪ アダプティブキャパシティが即時利用可能になったので、改善された ▪ 後でできるけど、すごい大変なこと ▪ 既存レコード（項目）のメンテナンス
26. 26 DynamoDB ▪ 後からできること ▪ 有効期限(TTL)属性の設定 ▪ インデックスの作成と削除 ▪ キャパシティコントロール ▪ など ▪ 後でできないこと ▪ テーブル名の変更 ▪ プライマリキーの変更 ▪ 分割されたパーティションの再統合、というよりパーティション操作全般 ▪ アダプティブキャパシティが即時利用可能になったので、改善された ▪ 後でできるけど、すごい大変なこと ▪ 既存レコード（項目）のメンテナンス
27. 27 DynamoDB 〜既存レコードのメンテナンス〜 ▪ 容量は無制限だけど、ストレージ単価はそれなり ▪ スタンダードの場合、S3標準ストレージの10倍以上 ▪ 古いデータはパージすることを前提にする ▪ TTLを設定しておけば、WCUを使うことなく削除してくれるので、最初から仕込んでおく ▪ テーブル内の既存レコード全体に更新、削除するのは大変 ▪ 後悔しないためにも、最初にしっかりテーブル設計しておくのが吉 ▪ 「Amazon DynamoDB Advanced Design Pattern」がおすすめ
28. 28 DynamoDB 〜キャパシティコントロール〜 ▪ プロビジョニングとオンデマンドを使い分ける ▪ リアルタイムを保つためには、スロットルは大敵 ▪ オンデマンドにすれば、スロットルを気にしなくてよくなるが、割高にはなる ▪ 書き込み、読み込みが多ければ、未だプロビジョニングの方がよい（リザーブドキャパシティ も使える） ▪ プロビジョニングの場合のオートスケーリングが、いい具合に効かないこともあ る ▪ スロットル発生＝キャパシティアップ、とは限らない
29. 29 まとめ Kinesis Data Streams Lambda ALB EC2 Backend KPLによるレコード集約 ワークロードに応じた メモリサイズ、バッチサイズの選択 デバイスごとに 振り分け＆ ファンアウト 最初の設計を 慎重に DynamoDB
30. 30 まとめ ▪ 個人的な教訓 ▪ なにかトラブルがあった時、札束で解決してすぐに原状復帰できるなら、それは強いアーキテ クチャ ▪ 処理するデータの数が1桁変わったら、アーキテクチャの再検討時期 ▪ 流行りに乗るだけでなく、ワークロードに合った選定が大事 ▪ 制限や性能はAWSのアップデートによって解消されるかもしれないので、適宜 ウォッチ ▪ 実際、Cariotのローンチ後に起きた、AWSの様々なアップデートに助けられまし た、ので… 神様、クラウドをありがとう！