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
10
大規模基幹サーバーに 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
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入するまで~
mot_techtalk
0
380
GPT-5と寿司合戦を攻略する
mot_techtalk
1
61
Grafanaスタックをフル活用したオブザーバビリティ基盤の紹介
mot_techtalk
7
980
オンデマンド交通のための車両ルーティング問題
mot_techtalk
0
120
Open-Vocabularyオブジェクト検出
mot_techtalk
0
56
Grafana Loki によるサーバログのコスト削減
mot_techtalk
1
860
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
830
GAEログのコスト削減
mot_techtalk
0
790
『GO』アプリ バックエンドサーバのコスト削減
mot_techtalk
0
840
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Designing for Performance
lara
610
69k
Practical Orchestrator
shlominoach
190
11k
Balancing Empowerment & Direction
lara
4
680
Designing for humans not robots
tammielis
254
25k
Building Applications with DynamoDB
mza
96
6.6k
Mobile First: as difficult as doing things right
swwweet
224
10k
How to train your dragon (web standard)
notwaldorf
96
6.3k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
610
Side Projects
sachag
455
43k
RailsConf 2023
tenderlove
30
1.2k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
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.