Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
複数環境でマイクロサービスを共用するためのプロトコル非依存なコンテクスト伝播 / PiCoP ja
Search
Hiroya Onoe
July 05, 2023
Research
0
2.1k
複数環境でマイクロサービスを共用するためのプロトコル非依存なコンテクスト伝播 / PiCoP ja
Hiroya Onoe
July 05, 2023
Tweet
Share
More Decks by Hiroya Onoe
See All by Hiroya Onoe
net/httpからnet.Connを掘り起こす
hiroyaonoe
1
2.1k
PiCoP en
hiroyaonoe
0
2.2k
Other Decks in Research
See All in Research
SSII2024 [OS3] 企業における基盤モデル開発の実際
ssii
PRO
0
570
[CV勉強会@関東 CVPR2024] Visual Layout Composer: Image-Vector Dual Diffusion Model for Design Layout Generation / kantocv 61th CVPR 2024
shunk031
1
340
【ICASSP2024】音声変換に関する全論文まとめ【Parakeet株式会社】
supikiti
0
720
大規模言語モデルを用いた日本語視覚言語モデルの評価方法とベースラインモデルの提案 【MIRU 2024】
kentosasaki
2
450
言語処理学会30周年記念事業留学支援交流会@YANS2024:「学生のための短期留学」
a1da4
1
210
Kaggle役立ちアイテム紹介(入門編)
k951286
13
4.2k
「Goトレ」のご紹介
smartfukushilab1
0
540
SSII2024 [OS2] 大規模言語モデルと基盤モデルの射程
ssii
PRO
0
480
JMED-LLM: 日本語医療LLM評価データセットの公開
fta98
4
1k
Weekly AI Agents News!
masatoto
22
19k
第 2 部 11 章「大規模言語モデルの研究開発から実運用に向けて」に向けて / MLOps Book Chapter 11
upura
0
110
Online Nonstationary and Nonlinear Bandits with Recursive Weighted Gaussian Process
monochromegane
0
200
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
87
5.6k
RailsConf 2023
tenderlove
28
830
The Language of Interfaces
destraynor
154
24k
Why Our Code Smells
bkeepers
PRO
334
57k
Building Better People: How to give real-time feedback that sticks.
wjessup
360
19k
Practical Orchestrator
shlominoach
185
10k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Happy Clients
brianwarren
97
6.6k
Fashionably flexible responsive web design (full day workshop)
malarkey
403
65k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
5
210
The World Runs on Bad Software
bkeepers
PRO
65
11k
The Pragmatic Product Professional
lauravandoore
31
6.2k
Transcript
複数環境でマイクロサービスを共用するための プロトコル非依存なコンテクスト伝播 尾上 寛弥 小谷 大祐 岡部 寿男 京都大学 https://speakerdeck.com/hiroyaonoe/picop-ja 1
背景:本番環境を模倣した環境 継続的インテグレーション/継続的デリバリーにおいて テスト/ステージング/デバッグ/プレビュー環境が必要 →本番環境よりアクセスが少なくリソースが無駄になりやすい マイクロサービスアーキテクチャ 1つのアプリケーションが 複数のマイクロサービスで 構成される →サービス数が多い分 さらにリソースの無駄が大きい
2
背景:コンテクスト伝播を用いたマイクロサービス共用 本番環境から変更されたサービス・状態を持つサービス以外は共用可能 →複数環境で同じマイクロサービスを共用することでリソース削減 (Wantedly, Mercari, Lyft, Ambassador Labsがそれぞれ提案) 1. 環境を識別するコンテクストをリ
クエストに付与して伝播 2. プロキシがリクエストを 適切な環境に振り分け 3
背景:コンテクスト伝播を用いたマイクロサービス共用 HTTPヘッダやgRPCメタデータにコンテクスト付与 1. OpenTelemetryを用いてコンテクスト伝播 2. EnvoyやIstioを用いてリクエスト振り分け 課題 伝播・振り分けが 特定のプロトコルに依存 -
他プロトコルでは利用不可 - プロトコルごとに計装が必要 4
関連研究:コンテクスト伝播 分散システムのトレーシング コンテクストを実際のリクエストに付与して伝播することでトレース (Dapper, Pinpoint, X-Trace, Pip, Canopy) コンテクスト伝播の共通化 様々なトレーシング手法におけるコンテクスト伝播の仕組みを
共通化することでシステムへの計装を軽減する提案 (Tracing Plane, Canopy, Pivot Tracing, Pythia) →いずれも特定の通信プロトコルやプラットフォームに依存 5
提案手法:PiCoP アプリケーション層プロトコルに非依存で コンテクスト伝播・リクエスト振り分けをするフレームワーク プロトコル アプリケーション層プロトコルを解釈 せずコンテクストを伝播 プロキシ プロトコルを利用しリクエスト を適切な環境へ振り分け 6
提案手法:PiCoPプロトコル TCPペイロードの先頭にコンテクストを付与 →アプリケーション層プロトコルの種類に関係なく利用可能 PROXY Protocol V2のシグネチャを利用 →アプリケーション層プロトコルと競合しない PROXY Protocol リバースプロキシサーバーを介した際の送信元クライアント情報を
プロトコル非依存で伝播可能にする →本提案の目的と似ている 伝播すべき情報の内容・形式が異なることから そのままは利用せず、参考にしている 7
提案手法:PiCoPプロトコル OpenTelemetryが定めた規格に準拠 →アプリケーションへの計装が容易 →他の目的でのコンテクスト伝播に利用しやすい OpenTelemetry 分散トレーシングに関連する規格・ライブラリを整備している コンテクスト伝播の仕組みを標準化する規格・ライブラリを提供 PiCoPプロトコルを用いて 環境を識別するID(環境ID)を リクエストに付与して伝播
8
提案手法:PiCoP プロキシ 任意のアプリケーション層プロトコルのリクエストを 環境IDに基づいて適切な環境へと振り分け 環境IDと振り分け先の対応関係(経路情報)を事前に受け取る デフォルトの経路を 共用のサービスに設定 環境固有のサービスがあるなら 固有のサービスに設定 9
実装 プロキシコントローラー プロキシと経路情報をDBで管理 管理者から情報を受け取る 各プロキシに情報を送信 プロキシのスケールアウトに対応 →大規模なクラスタでの使用 10
評価・考察:プロキシの通信遅延 11 nginxサーバーに対してペイロード1kBのHTTPリクエストを送信 10秒間で合計10000リクエストの応答時間を計測 同時コネクション接続数を1~64まで変化させる HTTPヘッダ or PiCoPプロトコルに”Env-Id:Main”のコンテクストを付与 4つの条件 PiCoPプロキシがある
vs. ない PiCoPプロキシ vs. Istioプロキシ
PiCoPプロキシがない場合との比較 (base vs. base+picop) 評価・考察:プロキシの通信遅延 12 3.2ms~12.3ms 遅い 6.7ms~13.3ms 遅い
Istioプロキシとの比較 (base+gw+istio vs. base+gw+picop) 既存手法で広く利用されるIstioとほぼ同等 →PiCoPプロキシによる遅延は実用的な範囲内 評価・考察:プロキシの通信遅延 13 ほぼ同等 0.3~2.7ms遅い
nginxサーバーに継続的にHTTPリクエストを送信して負荷をかける 全てのコンテナのCPU使用率が80%以下になるようにスケールアウト プロキシとnginxサーバーの合計コンテナ数を比較 各コンテナのリソース制限量は vCPU数0.1、メモリ128MiB 環境数は1~100で変化させる 環境数と同じ数のクライアント からリクエスト送信 全環境合計の秒間リクエスト数 100と1000で計測
14 評価・考察:共用によるリソース削減
一定以上の環境数だと共用した場合の方が削減 環境数が大きいほど削減量も大きい 15 評価・考察:共用によるリソース削減
評価・考察:プロトコル非依存の程度・制約 サービス間伝播 オプションデータを付与できないものを含む任意のアプリケーション層プロトコ ルで、共通の仕組みを用いたコンテクスト伝播が可能 コネクションの再利用に制約あり(例:HTTPの持続的接続) TCPコネクションを毎回確立するオーバーヘッド トランスポート層プロトコルごとにプロキシを実装する必要あり TCP以外にもUDPやQUICなどで利用可能 16 オプションデータを付与できないプロトコル
オプションデータを付与できるプロトコル MySQL, PostgreSQL, Memcached, Redis, MongoDB Wire Protocol, MQTT, Kafka Wire Protocol, TDS(Microsoft SQL Server) HTTP, gRPC, AMQP, Cassandra Native Protocol
サービス内伝播 アプリのリクエスト処理の途中にあるサービス(例:Webサーバー)には 既存手法と同様に計装が必要 評価・考察:プロトコル非依存の程度・制約 17 プロトコルごとに計装用ライブラリが必要 共通のOpenTelemetryライブラリを用いて計装可能
評価・考察:プロトコル非依存の程度・制約 サービス内伝播 アプリのリクエスト処理の末端にあるサービス(例:データベース)には 計装の必要なし 18 非同期処理(例:メッセージキュー) では処理の特性に合わせて 環境を分離するためにPiCoPプロキシ を拡張する必要あり プロキシを
拡張
まとめ・今後の課題 まとめ - プロトコル非依存でのマイクロサービス共用を実現するPiCoPを提案 - アプリケーション層プロトコルを解釈せずコンテクストを伝播する プロトコル - プロトコルを利用してリクエストを適当な環境へ振り分ける プロキシ
- 通信遅延やリソース削減の点で実用性を示した - コネクション再利用や非同期処理における制約を示した - OSSとして公開( https://github.com/picop-rd ) 今後の課題 - 上記の制約の改善 - 大規模なクラウドスケールでの評価 - PiCoPプロトコルが他の目的にどの程度応用可能かの評価 https://speakerdeck.com/hiroyaonoe/picop-ja 19