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
大規模基幹サーバーに gRPCを導入した過程での学び
Search
GO Inc. dev
October 08, 2025
2
22
大規模基幹サーバーに gRPCを導入した過程での学び
ペパボ & GO 〜夏のGo祭り2025、あの夏〜 で登壇した資料です。
https://pepabo.connpass.com/event/363869/
GO Inc. dev
October 08, 2025
Tweet
Share
More Decks by GO Inc. dev
See All by GO Inc. dev
GO Tech Talk #31 タクシーアプリ『GO』におけるNext.jsの活用
mot_techtalk
2
37
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入するまで~
mot_techtalk
1
480
GPT-5と寿司合戦を攻略する
mot_techtalk
1
77
Grafanaスタックをフル活用したオブザーバビリティ基盤の紹介
mot_techtalk
7
1.1k
オンデマンド交通のための車両ルーティング問題
mot_techtalk
0
130
Open-Vocabularyオブジェクト検出
mot_techtalk
0
80
Grafana Loki によるサーバログのコスト削減
mot_techtalk
1
910
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
860
GAEログのコスト削減
mot_techtalk
0
810
Featured
See All Featured
Scaling GitHub
holman
463
140k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Documentation Writing (for coders)
carmenintech
75
5.1k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Embracing the Ebb and Flow
colly
88
4.9k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
930
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
610
It's Worth the Effort
3n
187
28k
The Straight Up "How To Draw Better" Workshop
denniskardys
238
140k
The Cost Of JavaScript in 2023
addyosmani
55
9.1k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
Transcript
© GO Inc. 大規模基幹サーバーに gRPCを導入した過程での学び
© GO Inc. 2 自己紹介 GO株式会社 バックエンドエンジニア/ もぎ 新卒でGOに入り、2年目となりました。 技術も趣味も広く浅く、色々なことに興味を持って活動しています。
最近は新規事業のプロダクトの検討から開発までがメイン。 好き: コーヒー / サウナ / MARVEL / 乃木坂46 (今年ライブ4回行ってしまった...) @manattan_me
© GO Inc. 20人以上で保守運用しているAPIサーバーに、ノリで gRPCを入れてみようとしたのですが、実際には想像以上 に試行錯誤がありました。 導入にあたり何をしたのかと、実際にどういうしくじりや 発見があったのかについてお話しします。 今回の発表では... 3
Index © GO Inc. 4 1. タクシーアプリ『GO』のアーキテクチャの概要と、gRPCを入れることにした背景 2. 実際にどのような形で入れることになったか(技術的説明) 3.
推進過程で得られた合意形成と進め方の学び 4. まとめ
© GO Inc. 既存アーキテクチャと導 入背景 01
© GO Inc. ※ は当社の登録商標です。 6 タクシーアプリ『 GO』の事業成長 ー ダウンロード数推移
ー 2022年9月 1000万ダウンロード突破! 2021年11月 法人向けタクシー配車管理 『GO BUSINESS』リリース 2021年10月 500万ダウンロード突破! 2020年4月 Mobility Technologies誕生! 2023年4月 「GO株式会社」に商号変更 『GO』累積ダウンロード数 2020年9月 タクシーアプリ『 GO』 全国11エリアでスタート ダウンロード数 (25年7月) 3000万 利用可能エリア (25年9月1日) 46都道府県 ネットワーク事業者数 1100社以上 年間実車数 (22年6月-23年5 月) 6000万回 No1※タクシーアプリとして成長中 ※Sensor Tower調べ - タクシー配車関連アプリにおける、日本国内ダウンロード数( App Store/Google Play合算値) - 調査期間: 2020年10月1日~2025年6月30日 2024年4月 2000万ダウンロード突破! 2025年7月 3000万ダウンロード突破! 2024年10月 2500万ダウンロード突破!
© GO Inc. ▪ タクシーアプリ『GO』では、一つの大規模なAPIサーバーと、数十個のマイクロサービスで 成り立っている 導入の背景 7
© GO Inc. ▪ マイクロサービス間の通信は gRPCが基本だが、マイクロサービス→GO-API の通信は http ▪基幹サーバーだけ、「内部通信でもhttp」になっている 導入の背景
8
© GO Inc. ▪ マスターとなっているドキュメントが存在していない ▪ Redoc は微妙に導入されているが保守されていない(APIの本数が多すぎて重すぎる、とか) ▪ 各案件のspecに、APIの差分が記述されている状態
▪ どの階層にフィールドが追加されたのかパッとわからない/そのフィールド名が本当に正しいのか良く わからない 存在していた課題1: API ドキュメントの乱立 9 →protoファイルのPRベースの管理によって、スキーマ駆動開発を実践することができる
© GO Inc. ▪ 基幹サーバーは GKEで動いているが、他マイクロサービスは EKS で動いているものも多い → Cloud
NAT や Internet Data Transfer Out のコストがたくさんかかっている ▪ コスト削減文脈で、少しでも減らせると嬉しいという話がある ▪ gPRCにすると、protocol buffers によってバイナリにシリアライズされるため、通信コスト が少しでも削減できるという期待がある ▪ JSON(テキスト表現): {"id":123,"name":"taka"} → 24バイト ▪ Protobuf: 08 7B 12 04 74 61 6B 61 → 8バイト 08 … フィールド#1(wire type: varint = 整数) 7B … 123(varintエンコード) 12 … フィールド#2(wire type: length-delimited = 長さ付きデータ) 04 … 文字列の長さ 4 74 61 6B 61 …… "taka" 存在していた課題2: ネットワークのコストがかかっている 10
© GO Inc. ▪コード生成 ▪.proto ファイルから、Go, Python, Ruby などの複数言語のIFコードを生成することがで きる。より型安全に・楽に実装できるようになるため、開発効率が上がる
▪双方向ストリーミング ▪ Pub/Subの実装が楽になる ▪セキュリティ観点 ▪ GETリクエストの場合、クエリパラメータがログに出力されてしまう。緯度経度などの 個人情報が含まれると良くないが、grpcは全てPOSTなのでその懸念がない 実課題はこの程度だったが、他にもいくつかメリットがある 11
© GO Inc. 実践 02 12
© GO Inc. ▪SREによる技術ブログ: Protocol Buffersの一元管理方法 ▪社内のprotoファイルを管理するリポジトリが存在している ▪開発者はそこにPRを作る→マージする→複数言語のコードがパッケージとして生成される ▪Internal 通信に閉じた、kubenetes
Service を新しく定義 結論: 社内の運用が整っているため、そこに乗っかっただけ 13
© GO Inc. ▪既存の main.go にて DB/外部API クライアント初期化と HTTP サーバ起動が密結合になっていた→暫定対応に
main.go に環境変数による分岐を追加 14
© GO Inc. やればよかったなと思うこと 15 [より良い例] ▪main.go の責務過多:初期化と分岐ロジックが肥大化し可読性・保守性低下が現れた ▪別バイナリ化:cmd/http_server/main.go と
cmd/grpc_server/main.go を用意(共通コードは 別に集約) ▪依存注入:NewClients(config) などのファクトリの実装をし、複数エントリーポイントで共通化 [既存]外部クライアント初期化の書き方
© GO Inc. / ├─ main.go ├─ grpc_server.go ├─ handler/
├─ middleware/ └─ hoge_handler.go ├─ domain/ ├─ router/ ├─ infra/ … └─ grpchandler/ ├─ intercepter/ └─ hoge_service.go ディレクトリ構成も良くなるかもしれない 16 / ├─ cmd ├─ http_server.go └─ grpc_server.go ├─ gateway/ ├─ infra/ ├─ http_server/ ├─ router/ ├─ middleware/ └─ handler/ └─ grpc_server ├─ intercepter/ └─ hoge_service.go ├─ domain/ ... ▪全体的に、どこまで主体的に進めていくべきか迷 いながらの暫定対応になってしまった →あるべき状態の模索はできているので、ど しどし主体的にリファクタしていきたい気持ち
© GO Inc. 推進過程で得られた 合意形成と進め方の学び 03 17
© GO Inc. 背景 18 ▪「どこまで丁寧に合意を取るか」「どこまではサクッと決めちゃって進めていくか」の勘所が不足していた ▪技術方針そのものは賛同多数 → 一方で進め方の期待値がバラバラ ▪「とりまgRPC入れちゃいますね〜!」を宣言したが、期待のズレを招き迷走してしまった感がある
(こんなヘラヘラが許容される会社なのは本当に素晴らしいです‼)
© GO Inc. 実際に推進していく中での課題 19 ▪雑談っぽく「とりまgRPC入れちゃいますね〜!」を宣言した ▪Aさん「design doc を先に作ってちゃんと合意とってからにしてほしい」 ▪Bさん「いいね!まず小さく導入しちゃえば良さそう」
▪深掘りしていくと、検討するべきことはたくさん存在する ▪既存のhttp endpointはいつ/どう移行するのか?移行しないのか? ▪他チーム/関係者への通知・調整はどう設計するのか? ▪適用範囲と使い分けの基準をどこに置くのか? 成功条件(いつ何が出来ていればOKか)が曖昧 → 議論が循環
© GO Inc. 正しい進め方の理解 20 ▪事前に“課題を洗い出し→暫定解”をセットで用意しておく ▪用意してはいたが、軽い気持ちで「導入しちゃいます!」と言わない() ▪ミニマムドキュメントを用意しておく ▪目的/スコープ/レビュー観点 etc…
▪いきなり全体合意に行かず、小さく相談し仲間を作る ▪小規模チームでレビュー→仲間を増やして段階展開 →当たり前のことだが、率先して挑戦することで改めて意識するきっかけになった
© GO Inc. まとめ 04 21
© GO Inc. ▪運用に乗りつつあるので、一旦やりたいことはできた ▪コストが削減できたか・レイテンシがよくなったか について今後着目していきたい ▪ディレクトリ構成や、ロギング対応など、諸々暫定対応になってしまった点がある ▪小さくスピード感を持って導入できたことは良かったが、適切に長期設計も含めて前もって検 討しておくことが重要 ▪どんなにカジュアルな環境であっても、適切なコミュニケーションを心がける・責任持って推進して
いく まとめ 22
© GO Inc. 23 https://hrmos.co/pages/g oinc/jobs タクシーアプリ『GO』の開発を一緒にしませんか
文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 © GO Inc.