大規模基幹サーバーに gRPCを導入した過程での学び

ペパボ & GO 〜夏のGo祭り2025、あの夏〜 で登壇した資料です。

https://pepabo.connpass.com/event/363869/

Transcript

1. © GO Inc. 大規模基幹サーバーに gRPCを導入した過程での学び
2. © GO Inc. 2 自己紹介 GO株式会社 バックエンドエンジニア/ もぎ 新卒でGOに入り、2年目となりました。 技術も趣味も広く浅く、色々なことに興味を持って活動しています。 最近は新規事業のプロダクトの検討から開発までがメイン。 好き: コーヒー / サウナ / MARVEL / 乃木坂46 （今年ライブ4回行ってしまった...） @manattan_me
3. © GO Inc. 20人以上で保守運用しているAPIサーバーに、ノリで gRPCを入れてみようとしたのですが、実際には想像以上 に試行錯誤がありました。 導入にあたり何をしたのかと、実際にどういうしくじりや 発見があったのかについてお話しします。 今回の発表では... 3
4. Index © GO Inc. 4 1. タクシーアプリ『GO』のアーキテクチャの概要と、gRPCを入れることにした背景 2. 実際にどのような形で入れることになったか（技術的説明） 3. 推進過程で得られた合意形成と進め方の学び 4. まとめ
5. © GO Inc. 既存アーキテクチャと導 入背景 01
6. © 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万ダウンロード突破！
7. © GO Inc. ▪ タクシーアプリ『GO』では、一つの大規模なAPIサーバーと、数十個のマイクロサービスで 成り立っている 導入の背景 7
8. © GO Inc. ▪ マイクロサービス間の通信は gRPCが基本だが、マイクロサービス→GO-API の通信は http ▪基幹サーバーだけ、「内部通信でもhttp」になっている 導入の背景 8
9. © GO Inc. ▪ マスターとなっているドキュメントが存在していない ▪ Redoc は微妙に導入されているが保守されていない（APIの本数が多すぎて重すぎる、とか） ▪ 各案件のspecに、APIの差分が記述されている状態 ▪ どの階層にフィールドが追加されたのかパッとわからない/そのフィールド名が本当に正しいのか良く わからない 存在していた課題1: API ドキュメントの乱立 9 →protoファイルのPRベースの管理によって、スキーマ駆動開発を実践することができる
10. © 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
11. © GO Inc. ▪コード生成 ▪.proto ファイルから、Go, Python, Ruby などの複数言語のIFコードを生成することがで きる。より型安全に・楽に実装できるようになるため、開発効率が上がる ▪双方向ストリーミング ▪ Pub/Subの実装が楽になる ▪セキュリティ観点 ▪ GETリクエストの場合、クエリパラメータがログに出力されてしまう。緯度経度などの 個人情報が含まれると良くないが、grpcは全てPOSTなのでその懸念がない 実課題はこの程度だったが、他にもいくつかメリットがある 11
12. © GO Inc. 実践 02 12
13. © GO Inc. ▪SREによる技術ブログ: Protocol Buffersの一元管理方法 ▪社内のprotoファイルを管理するリポジトリが存在している ▪開発者はそこにPRを作る→マージする→複数言語のコードがパッケージとして生成される ▪Internal 通信に閉じた、kubenetes Service を新しく定義 結論: 社内の運用が整っているため、そこに乗っかっただけ 13
14. © GO Inc. ▪既存の main.go にて DB/外部API クライアント初期化と HTTP サーバ起動が密結合になっていた→暫定対応に main.go に環境変数による分岐を追加 14
15. © GO Inc. やればよかったなと思うこと 15 [より良い例] ▪main.go の責務過多：初期化と分岐ロジックが肥大化し可読性・保守性低下が現れた ▪別バイナリ化：cmd/http_server/main.go と cmd/grpc_server/main.go を用意（共通コードは 別に集約） ▪依存注入：NewClients(config) などのファクトリの実装をし、複数エントリーポイントで共通化 [既存]外部クライアント初期化の書き方
16. © 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/ ... ▪全体的に、どこまで主体的に進めていくべきか迷 いながらの暫定対応になってしまった →あるべき状態の模索はできているので、ど しどし主体的にリファクタしていきたい気持ち
17. © GO Inc. 推進過程で得られた 合意形成と進め方の学び 03 17
18. © GO Inc. 背景 18 ▪「どこまで丁寧に合意を取るか」「どこまではサクッと決めちゃって進めていくか」の勘所が不足していた ▪技術方針そのものは賛同多数 → 一方で進め方の期待値がバラバラ ▪「とりまgRPC入れちゃいますね〜！」を宣言したが、期待のズレを招き迷走してしまった感がある （こんなヘラヘラが許容される会社なのは本当に素晴らしいです‼）
19. © GO Inc. 実際に推進していく中での課題 19 ▪雑談っぽく「とりまgRPC入れちゃいますね〜！」を宣言した ▪Aさん「design doc を先に作ってちゃんと合意とってからにしてほしい」 ▪Bさん「いいね！まず小さく導入しちゃえば良さそう」 ▪深掘りしていくと、検討するべきことはたくさん存在する ▪既存のhttp endpointはいつ/どう移行するのか？移行しないのか？ ▪他チーム/関係者への通知・調整はどう設計するのか？ ▪適用範囲と使い分けの基準をどこに置くのか？ 成功条件（いつ何が出来ていればOKか）が曖昧 → 議論が循環
20. © GO Inc. 正しい進め方の理解 20 ▪事前に“課題を洗い出し→暫定解”をセットで用意しておく ▪用意してはいたが、軽い気持ちで「導入しちゃいます！」と言わない（） ▪ミニマムドキュメントを用意しておく ▪目的/スコープ/レビュー観点 etc… ▪いきなり全体合意に行かず、小さく相談し仲間を作る ▪小規模チームでレビュー→仲間を増やして段階展開 →当たり前のことだが、率先して挑戦することで改めて意識するきっかけになった
21. © GO Inc. まとめ 04 21
22. © GO Inc. ▪運用に乗りつつあるので、一旦やりたいことはできた ▪コストが削減できたか・レイテンシがよくなったか について今後着目していきたい ▪ディレクトリ構成や、ロギング対応など、諸々暫定対応になってしまった点がある ▪小さくスピード感を持って導入できたことは良かったが、適切に長期設計も含めて前もって検 討しておくことが重要 ▪どんなにカジュアルな環境であっても、適切なコミュニケーションを心がける・責任持って推進して いく まとめ 22
23. © GO Inc. 23 https://hrmos.co/pages/g oinc/jobs タクシーアプリ『GO』の開発を一緒にしませんか
24. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 © GO Inc.