Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for GO Inc. dev GO Inc. dev
October 08, 2025
10

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

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

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

Avatar for GO Inc. dev

GO Inc. dev

October 08, 2025
Tweet

More Decks by GO Inc. dev

Transcript

  1. © GO Inc. 2 自己紹介 GO株式会社 バックエンドエンジニア/ もぎ 新卒でGOに入り、2年目となりました。 技術も趣味も広く浅く、色々なことに興味を持って活動しています。

    最近は新規事業のプロダクトの検討から開発までがメイン。 好き: コーヒー / サウナ / MARVEL / 乃木坂46 (今年ライブ4回行ってしまった...) @manattan_me
  2. © 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万ダウンロード突破!
  3. © GO Inc. ▪ マスターとなっているドキュメントが存在していない ▪ Redoc は微妙に導入されているが保守されていない(APIの本数が多すぎて重すぎる、とか) ▪ 各案件のspecに、APIの差分が記述されている状態

    ▪ どの階層にフィールドが追加されたのかパッとわからない/そのフィールド名が本当に正しいのか良く わからない 存在していた課題1: API ドキュメントの乱立 9 →protoファイルのPRベースの管理によって、スキーマ駆動開発を実践することができる
  4. © 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
  5. © GO Inc. ▪コード生成 ▪.proto ファイルから、Go, Python, Ruby などの複数言語のIFコードを生成することがで きる。より型安全に・楽に実装できるようになるため、開発効率が上がる

    ▪双方向ストリーミング ▪ Pub/Subの実装が楽になる ▪セキュリティ観点 ▪ GETリクエストの場合、クエリパラメータがログに出力されてしまう。緯度経度などの 個人情報が含まれると良くないが、grpcは全てPOSTなのでその懸念がない 実課題はこの程度だったが、他にもいくつかメリットがある 11
  6. © GO Inc. やればよかったなと思うこと 15 [より良い例] ▪main.go の責務過多:初期化と分岐ロジックが肥大化し可読性・保守性低下が現れた ▪別バイナリ化:cmd/http_server/main.go と

    cmd/grpc_server/main.go を用意(共通コードは 別に集約) ▪依存注入:NewClients(config) などのファクトリの実装をし、複数エントリーポイントで共通化 [既存]外部クライアント初期化の書き方
  7. © 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/ ... ▪全体的に、どこまで主体的に進めていくべきか迷 いながらの暫定対応になってしまった →あるべき状態の模索はできているので、ど しどし主体的にリファクタしていきたい気持ち
  8. © GO Inc. 実際に推進していく中での課題 19 ▪雑談っぽく「とりまgRPC入れちゃいますね〜!」を宣言した ▪Aさん「design doc を先に作ってちゃんと合意とってからにしてほしい」 ▪Bさん「いいね!まず小さく導入しちゃえば良さそう」

    ▪深掘りしていくと、検討するべきことはたくさん存在する ▪既存のhttp endpointはいつ/どう移行するのか?移行しないのか? ▪他チーム/関係者への通知・調整はどう設計するのか? ▪適用範囲と使い分けの基準をどこに置くのか? 成功条件(いつ何が出来ていればOKか)が曖昧 → 議論が循環
  9. © GO Inc. 正しい進め方の理解 20 ▪事前に“課題を洗い出し→暫定解”をセットで用意しておく ▪用意してはいたが、軽い気持ちで「導入しちゃいます!」と言わない() ▪ミニマムドキュメントを用意しておく ▪目的/スコープ/レビュー観点 etc…

    ▪いきなり全体合意に行かず、小さく相談し仲間を作る ▪小規模チームでレビュー→仲間を増やして段階展開 →当たり前のことだが、率先して挑戦することで改めて意識するきっかけになった