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
2k
複数環境でマイクロサービスを共用するためのプロトコル非依存なコンテクスト伝播 / 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
2k
PiCoP en
hiroyaonoe
0
2.1k
Other Decks in Research
See All in Research
LLM時代の半導体・集積回路
kentaroy47
1
380
大規模言語モデルを用いた日本語視覚言語モデルの評価方法とベースラインモデルの提案 【MIRU 2024】
kentosasaki
2
390
SSII2024 [TS2] 深層学習に潜むバイアス
ssii
PRO
0
580
論文紹介/Expectations over Unspoken Alternatives Predict Pragmatic Inferences
chemical_tree
1
220
Active Adaptive Experimental Design for Treatment Effect Estimation with Covariate Choices
masakat0
0
160
20240719_第2回熊本の交通を語る会
trafficbrain
0
360
工学としてのSRE再訪 / Revisiting SRE as Engineering
yuukit
18
8.3k
"多様な推薦"はユーザーの目にどう映るか
kuri8ive
3
340
SSII2024 [OS2] 大規模言語モデルとVision & Languageのこれから
ssii
PRO
5
1.4k
Generative Predictive Model for Autonomous Driving 第61回 コンピュータビジョン勉強会@関東 (後編)
kentosasaki
0
160
Weekly AI Agents News!
masatoto
20
16k
SSII2024 [PD] 30周年記念特別企画SSII 技術マップ / LLMサーベイ
ssii
PRO
0
720
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
220
8.8k
How GitHub Uses GitHub to Build GitHub
holman
472
290k
GitHub's CSS Performance
jonrohan
1029
450k
Building Flexible Design Systems
yeseniaperezcruz
324
37k
Scaling GitHub
holman
458
140k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
22
580
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
190
16k
For a Future-Friendly Web
brad_frost
173
9.3k
The Power of CSS Pseudo Elements
geoffreycrofte
71
5.2k
Producing Creativity
orderedlist
PRO
340
39k
A Modern Web Designer's Workflow
chriscoyier
690
190k
Building Adaptive Systems
keathley
36
2.1k
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