連続画像処理による位置情報計算を支えるマイクロサービスアーキテクチャ

JJUG CCC 2022 の登壇資料です。

Transcript

1. 連続画像処理による位置情報計算を支える マイクロサービスアーキテクチャ
2. 本山 要 ◉ 2017年ウルシステムズに新卒入社（6年目） ◉ 主に開発案件を担当 ‒ 業務アプリ、 B to Cアプリ、コンピュータビジョン ‒ 開発もPMも ‒ Golang、Unity、JavaScript、C#、Java ◉ 得意技は技術要素の爆速キャッチアップ ◉ 新卒研修や採用活動にも従事 2
3. アジェンダ ◉ 実現したかった事 ◉ アーキテクチャ紹介 ◉ まとめ 3
4. 1. 実現したかった事
5. 壁にぶつからないルンバ 5 with 位置情報計算エンジン 壁にぶつかってから方向転換する 壁にぶつらずに方向転換する
6. ざっくりシステム要件 6 作成物 1. 画像を撮影し、サーバー に送る 2. クライアントの位置情報を レスポンスとして返却する 3. 位置情報を基に処理を 実行する
7. システム要件と制約 7 ◉ ターンアラウンドタイム（以下、TAT）は33ミリ秒以下 ◉ 遅延を確実に解消 ◉ 位置情報の計算は1プロセスで同時に1回のみ可能
8. TAT33ミリ秒とは？ ◉ TAT ‒ リクエストを開始する直前とレスポンスを受け取った直後の時間差 ◉ 日本人が画像を見てなめらかに感じるフレームレートは30FPS ◉ 30FPS = 1/33（回/ms） ◉ 測定環境はオンプレ 8 TAT
9. システム要件と制約 9 ◉ ターンアラウンドタイム（以下、TAT）は33ミリ秒以下 ◉ 遅延を確実に解消 ◉ 位置情報の計算は1プロセスで同時に1回のみ可能
10. システム要件と制約 ◉ スケーラブル ◉ マルチプロトコル ◉ 受信画像を保存可能 ◉ 容易に拡張可能 10 ◉ ターンアラウンドタイム（以下、TAT）は33ミリ秒以下 ◉ 遅延を確実に解消 ◉ 位置情報の計算は1プロセスで同時に1回のみ可能 画像処理に 直接関係する 画像処理に 直接関係しない
11. アーキテクチャを特徴づける要素 ◉ マイクロサービス ◉ Redis Pub/Sub でサービス間通信 11
12. 2. アーキテクチャ紹介
13. アーキテクチャ紹介 ◉ マイクロサービス ◉ Redis Pub/Sub でサービス間通信 ◉ 特徴 13
14. 概要 14
15. 2. アーキテクチャ紹介 ～マイクロサービス～
16. スケーラビリティを確保したい ◉ クラウド環境ではコストをかければスケールできる ‒ 仮想サーバーでもサーバーレスでも ◉ オンプレ前提なのでコンテナでスケーラビリティを確保する 16
17. 機能をブレイクダウンしてみる ◉ リクエストの受け取り/ レスポンスの返却 ‒ request/response ◉ 画像の前処理 ‒ preprocess ◉ 位置情報の計算 ‒ location 17
18. ◉ 全部入り マイクロサービス化の方針 18
19. ◉ 全部入り マイクロサービス化の方針 19
20. ◉ 全部入り ◉ 全部別々 マイクロサービス化の方針 20
21. ◉ 全部別々 ◉ location だけ別 マイクロサービス化の方針 ◉ 全部入り 21
22. ◉ 全部別々 ◉ location だけ別 マイクロサービス化の方針 ◉ 全部入り 22
23. マイクロサービスを採用 23
24. 「スケーラブル」を達成 ◉ Location を増やすことで位置情報の計算プロセスの制約を乗り越えてスケール 可能に 24
25. 「マルチプロトコル」を達成 ◉ Preprocess に渡すデータの形が一致していれば、Connector のバリエーション を複数用意できる 25
26. 構成図とシーケンス図 26
27. システム要件と制約 ✓ スケーラブル ✓ マルチプロトコル ◉ 受信画像を保存可能 ◉ 容易に拡張可能 27 ◉ ターンアラウンドタイム（以下、TAT）は33ミリ秒以下 ◉ 遅延を確実に解消 ✓ 位置情報の計算は1プロセスで同時に1回のみ可能 画像処理に 直接関係する 画像処理に 直接関係しない
28. 2. アーキテクチャ紹介 ～Redis Pub/Sub でサービス間通信～
29. Redis とは ◉ NoSQLデータベース ◉ インメモリで動作 ◉ データの永続化も可能 ◉ Pub/Subのメッセージブローカー機能も 29
30. Pub/Sub とは ◉ お互いを知らずにメッセージを届ける仕組み ◉ 非同期通信 ◉ 発行者と購読者を疎結合にできる 30
31. Pub/Sub とは ◉ 複数チャンネルからメッセージを受け取ることもできる 31
32. 構成図 ◉ 各サービスは Pub/Sub で連携 32
33. シーケンス図 ◉ サービス間が非同期通信に 33
34. ところで異常系は？ ◉ ERROR チャンネルを用意しておく ◉ Connector は ERROR チャンネルからメッセージを受け取ったらエラーレスポンス を返却する 34
35. 拡張性も高い ◉ 他システムへのリアルタイムデータ連携は Subscribe で可能 35 Subscribeするだけ
36. システム要件と制約 ✓ スケーラブル ✓ マルチプロトコル ✓ 受信画像を保存可能 ✓ 容易に拡張可能 36 ◉ ターンアラウンドタイム（以下、TAT）は33ミリ秒以下 ◉ 遅延を確実に解消 ✓ 位置情報の計算は1プロセスで同時に1回のみ可能 画像処理に 直接関係する 画像処理に 直接関係しない
37. 2. アーキテクチャ紹介 ～特徴～
38. 特徴 ◉ リクエストのスキップ ◉ ストリーミング通信可能なインターフェース ◉ 低レイテンシ 38
39. 2. アーキテクチャ紹介 ～特徴～ リクエストのスキップ
40. リクエストをスキップしてもよい？ ◉ スキップしない ◉ スキップする 40 残高 100 残高 400 残高 900 残高 0 残高 100 残高 100 残高 600 残高 0 スキップ スキップ
41. リクエストをスキップしてよい世界もある ◉ スキップしない ◉ スキップする 41 現在地 (1, 1, 1) 現在地 (4, 4, 4) 現在地 (9, 9, 9) 現在地 (0, 0, 0) 現在地 (1, 1, 1) 現在地 (1, 1, 1) 現在地 (9, 9, 9) 現在地 (0, 0, 0) スキップ
42. 遅延とは何か？ ◉ 「遅延が発生する」=「クライアントが実際に見ている画像とサーバーで処理してい る画像がずれる」 ◉ 遅延が蓄積するとクライアントにとって古い位置情報を提供してしまい、誤作動の 原因となる 42 Ct: 時刻 t のクライアントの位置
43. 遅延が発生するメカニズム ◉ モノリスだと思って考えてみる ◉ 同時に捌けるリクエストは1リクエストのみ ‒ ただしタイムアウトするまでの時間は無限とする（タイムアウトを考えない） 43
44. 遅延が発生するメカニズム ◉ モノリスだと思って考えてみる ◉ 同時に捌けるリクエストは1リクエストのみ ‒ ただしタイムアウトするまでの時間は無限とする（タイムアウトを考えない） 44
45. 遅延が発生するメカニズム ◉ モノリスだと思って考えてみる ◉ 同時に捌けるリクエストは1リクエストのみ ‒ ただしタイムアウトするまでの時間は無限とする（タイムアウトを考えない） 45
46. 遅延が発生するメカニズム ◉ モノリスだと思って考えてみる ◉ 同時に捌けるリクエストは1リクエストのみ ‒ ただしタイムアウトするまでの時間は無限とする（タイムアウトを考えない） 46
47. 遅延が発生するメカニズム ◉ モノリスだと思って考えてみる ◉ 同時に捌けるリクエストは1リクエストのみ ‒ ただしタイムアウトするまでの時間は無限とする（タイムアウトを考えない） 47
48. 遅延が発生するメカニズム ◉ モノリスだと思って考えてみる ◉ 同時に捌けるリクエストは1リクエストのみ ‒ ただしタイムアウトするまでの時間は無限とする（タイムアウトを考えない） 48
49. 遅延が発生するメカニズム ◉ モノリスだと思って考えてみる ◉ 同時に捌けるリクエストは1リクエストのみ ‒ ただしタイムアウトするまでの時間は無限とする（タイムアウトを考えない） 49
50. 遅延が発生するメカニズム ◉ モノリスだと思って考えてみる ◉ 同時に捌けるリクエストは1リクエストのみ ‒ ただしタイムアウトするまでの時間は無限とする（タイムアウトを考えない） 50 遅延は発生しないのでTATは一定 遅延が蓄積し、 TATが徐々に増加
51. 遅延が発生するメカニズム ◉ モノリスだと思って考えてみる ◉ 同時に捌けるリクエストは1リクエストのみ ‒ ただしタイムアウトするまでの時間は無限とする（タイムアウトを考えない） 51 実際はマイクロサービスなので 処理が開始されている
52. サーバー内の動きを詳しく見てみる ◉ どのサービスも処理は1プロセスで同時に1回のみ可能 ◉ クライアントは6ミリ秒ごとにリクエストする ‒ Connector の処理が6ミリ秒ごとに開始する ◉ N回目のリクエストに対する Connector の処理を NConnector とする 52
53. サーバー内の動きを詳しく見てみる ◉ どのサービスも処理は1プロセスで同時に1回のみ可能 ◉ クライアントは6ミリ秒ごとにリクエストする ‒ Connector の処理が6ミリ秒ごとに開始する ◉ N回目のリクエストに対する Connector の処理を NConnector とする 53
54. サーバー内の動きを詳しく見てみる ◉ どのサービスも処理は1プロセスで同時に1回のみ可能 ◉ クライアントは6ミリ秒ごとにリクエストする ‒ Connector の処理が6ミリ秒ごとに開始する ◉ N回目のリクエストに対する Connector の処理を NConnector とする 54
55. サーバー内の動きを詳しく見てみる ◉ どのサービスも処理は1プロセスで同時に1回のみ可能 ◉ クライアントは6ミリ秒ごとにリクエストする ‒ Connector の処理が6ミリ秒ごとに開始する ◉ N回目のリクエストに対する Connector の処理を NConnector とする 55
56. サーバー内の動きを詳しく見てみる ◉ どのサービスも処理は1プロセスで同時に1回のみ可能 ◉ クライアントは6ミリ秒ごとにリクエストする ‒ Connector の処理が6ミリ秒ごとに開始する ◉ N回目のリクエストに対する Connector の処理を NConnector とする 56
57. サーバー内の動きを詳しく見てみる ◉ どのサービスも処理は1プロセスで同時に1回のみ可能 ◉ クライアントは6ミリ秒ごとにリクエストする ‒ Connector の処理が6ミリ秒ごとに開始する ◉ N回目のリクエストに対する Connector の処理を NConnector とする 57
58. サーバー内の動きを詳しく見てみる ◉ どのサービスも処理は1プロセスで同時に1回のみ可能 ◉ クライアントは6ミリ秒ごとにリクエストする ‒ Connector の処理が6ミリ秒ごとに開始する ◉ N回目のリクエストに対する Connector の処理を NConnector とする 58 遅延が蓄積し、TATは徐々に増加
59. サーバー内の動きを詳しく見てみる ◉ どのサービスも処理は1プロセスで同時に1回のみ可能 ◉ クライアントは6ミリ秒ごとにリクエストする ‒ Connector の処理が6ミリ秒ごとに開始する ◉ N回目のリクエストに対する Connector の処理を NConnector とする 59 遅延が蓄積し、TATは徐々に増加 Preprocess と Location の間隔は 1 ずつ広がる
60. サーバー内の動きを詳しく見てみる ◉ いつかこの状況になる 60
61. サーバー内の動きを詳しく見てみる ◉ いつかこの状況になる 61 1Location がなければ すぐに開始できる
62. 遅延を解消する ◉ 1Location をスキップする 62 スキップ
63. 遅延を解消する ◉ アルゴリズム ‒ メッセージを受け取ったときに他にメッセージがないか確認する ‒ 他にメッセージがあれば、受け取ったメッセージは最新の画像でないと判断し、スキップする ‒ 他にメッセージがなければ、受け取ったメッセージは最新の画像であると判断し、処理を開始する 63 スキップ
64. 遅延を解消する ◉ Connector, Preprocess, Locationすべてでスキップできるよう実装する 64 スキップ
65. サービス間通信に Redis Pub/Sub を採用 レスポンスをどうするか 65
66. 2. アーキテクチャ紹介 ～特徴～ ストリーミング通信可能なインターフェース
67. リクエスト用APIとレスポンス用APIに分ける ◉ Request API ‒ リクエストを受けたら RAW_IMAGE に Publish ‒ Publish 後、すぐに空のレスポンスを返す ◉ Response API ‒ ロングポーリングの前提 ‒ Connector がメッセージを受け取ったら、 位置情報のレスポンスを返す 67
68. シーケンス図 68
69. 構成図とシーケンス図 69
70. システム要件と制約 ✓ スケーラブル ✓ マルチプロトコル ✓ 受信画像を保存可能 ✓ 容易に拡張可能 70 ◉ ターンアラウンドタイム（以下、TAT）は33ミリ秒以下 ✓ 遅延を確実に解消 ✓ 位置情報の計算は1プロセスで同時に1回のみ可能 画像処理に 直接関係する 画像処理に 直接関係しない
71. 2. アーキテクチャ紹介 ～特徴～ 低レイテンシ
72. 性能評価 ◉ 前提条件 ‒ 指標はTAT ‒ スキップされたリクエストは評価対象外 ‒ 10クライアントから同時に5分間リクエストを継続 ‒ オンプレ環境にデプロイ ‒ クライアントとサーバーはLANケーブルで接続 ◉ 結果 ‒ TAT(90%tile)で約31ミリ秒 ‒ スキップされたリクエストは0 72 TAT
73. システム要件と制約 ✓ スケーラブル ✓ マルチプロトコル ✓ 受信画像を保存可能 ✓ 容易に拡張可能 73 ✓ ターンアラウンドタイム（以下、TAT）は33ミリ秒以下 ✓ 遅延を確実に解消 ✓ 位置情報の計算は1プロセスで同時に1回のみ可能 画像処理に 直接関係する 画像処理に 直接関係しない
74. 3. まとめ
75. まとめ ◉ 壁にぶつからないルンバを実現するアーキテクチャ ◉ マイクロサービス と Redis Pub/Sub を採用 ◉ スケーラビリティと低レイテンシを両立 75