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.2k
複数環境でマイクロサービスを共用するためのプロトコル非依存なコンテクスト伝播 / PiCoP ja
Hiroya Onoe
July 05, 2023
Tweet
Share
More Decks by Hiroya Onoe
See All by Hiroya Onoe
Tiaccoon: コンテナネットワークにおいて複数トランスポート方式で統一的なアクセス制御
hiroyaonoe
0
1k
net/httpからnet.Connを掘り起こす
hiroyaonoe
1
3.4k
PiCoP en
hiroyaonoe
0
3.4k
Other Decks in Research
See All in Research
Vision and LanguageからのEmbodied AIとAI for Science
yushiku
PRO
1
500
Computational OT #4 - Gradient flow and diffusion models
gpeyre
0
370
SSII2025 [TS1] 光学・物理原理に基づく深層画像生成
ssii
PRO
4
4.1k
数理最適化に基づく制御
mickey_kubo
6
720
時系列データに対する解釈可能な 決定木クラスタリング
mickey_kubo
2
900
Streamlit 総合解説 ~ PythonistaのためのWebアプリ開発 ~
mickey_kubo
1
1.4k
投資戦略202508
pw
0
350
日本語新聞記事を用いた大規模言語モデルの暗記定量化 / LLMC2025
upura
0
130
cvpaper.challenge 10年の軌跡 / cvpaper.challenge a decade-long journey
gatheluck
3
300
データサイエンティストの採用に関するアンケート
datascientistsociety
PRO
0
1.2k
2025/7/5 応用音響研究会招待講演@北海道大学
takuma_okamoto
1
170
不確実性下における目的と手段の統合的探索に向けた連続腕バンディットの応用 / iot70_gp_rff_mab
monochromegane
2
130
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
512
110k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Building Applications with DynamoDB
mza
96
6.6k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Thoughts on Productivity
jonyablonski
69
4.8k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
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