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
3.4k
複数環境でマイクロサービスを共用するためのプロトコル非依存なコンテクスト伝播 / PiCoP ja
Hiroya Onoe
July 05, 2023
Tweet
Share
More Decks by Hiroya Onoe
See All by Hiroya Onoe
Tiaccoon: コンテナネットワークにおいて複数トランスポート方式で統一的なアクセス制御
hiroyaonoe
0
1.2k
net/httpからnet.Connを掘り起こす
hiroyaonoe
1
3.5k
PiCoP en
hiroyaonoe
0
3.6k
Other Decks in Research
See All in Research
Towards a More Efficient Reasoning LLM: AIMO2 Solution Summary and Introduction to Fast-Math Models
analokmaus
2
870
とあるSREの博士「過程」 / A Certain SRE’s Ph.D. Journey
yuukit
11
4.3k
SNLP2025:Can Language Models Reason about Individualistic Human Values and Preferences?
yukizenimoto
0
180
Minimax and Bayes Optimal Best-arm Identification: Adaptive Experimental Design for Treatment Choice
masakat0
0
180
snlp2025_prevent_llm_spikes
takase
0
350
電通総研の生成AI・エージェントの取り組みエンジニアリング業務向けAI活用事例紹介
isidaitc
1
1k
不確実性下における目的と手段の統合的探索に向けた連続腕バンディットの応用 / iot70_gp_rff_mab
monochromegane
2
180
EarthSynth: Generating Informative Earth Observation with Diffusion Models
satai
3
360
最適化と機械学習による問題解決
mickey_kubo
0
180
Combinatorial Search with Generators
kei18
0
900
EarthDial: Turning Multi-sensory Earth Observations to Interactive Dialogues
satai
3
210
カスタマーサクセスの視点からAWS Summitの展示を考える~製品開発で活用できる勘所~
masakiokuda
2
210
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
37
3.4k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.7k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
For a Future-Friendly Web
brad_frost
180
9.9k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Writing Fast Ruby
sferik
629
62k
The Invisible Side of Design
smashingmag
301
51k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
Making the Leap to Tech Lead
cromwellryan
135
9.5k
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