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

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

Check these out next

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

Recommended

More Related Content

Recently uploaded(20)

Featured(20)

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