会社情報
採用情報
お問い合わせ
Article

gRPCを本番で3年使って分かった、RESTに戻りたくなる瞬間

高田晃太郎
gRPCを本番で3年使って分かった、RESTに戻りたくなる瞬間

公開ベンチマークでは、gRPCはp95レイテンシーの短縮や帯域・CPU使用の削減につながる傾向が繰り返し示されています。 一方で、導入初期の重大インシデントにおける検知から復旧までの平均時間が悪化しうる、という現場の報告もあります⁹。公開情報から読み取れる、この相反する現実は、gRPCの適用が性能を押し上げる一方で、運用の摩擦を増やし得ることを示しています¹⁴⁶⁷。CNCFの周辺動向でもサービス間通信の手段としてgRPC採用は伸びていますが、すべてのユースケースを置き換える万能薬ではありません³。

RESTに戻りたくなる瞬間はどこに潜むか

最初に触れておきたいのは、戻りたくなる衝動は情緒ではなく、再現性のある状況から生まれるという点です。現場では、ブラウザや外部公開、キャッシュ、インシデント対応、そしてストリーミングの4つの局面で強くそれを感じることが少なくありません。

ブラウザと外部公開の壁が高く感じられたとき

gRPC-WebやEnvoy/grpc-gatewayのトランスコードでブラウザ対応は可能ですが、トレイラー（HTTPレスポンス末尾のメタデータ）非対応、双方向ストリーミングの制約、企業プロキシ下でのHTTP/2やALPN（プロトコル交渉）の挙動など、プロダクション品質での“最後の20%”に想定外の工数が乗りがちです²¹⁴。ALBや一部CDNの設定制約も加わると、単純な公開APIであっても「JSON/RESTでさっと出す」ほうが市場投入は早い、という判断が現実的になります。外向けの開発者体験も重要で、curl一発で動くことがサポートコストを下げる側面は過小評価できません¹⁴。

キャッシュと分析の現実に直面したとき

gRPCは多くの場合POSTで運び、CDNの標準的なキャッシュ機構やETag/If-None-Matchの活用がそのままでは効きません⁵。読み取り中心のリスト系エンドポイントをREST/GETに切り戻すと、CDNヒット率が大きく改善し、外向きのエグレスが削減されるケースは珍しくありません¹⁴⁵。さらに、JSONでのログ・分析はスキーマレスな探索性が高く、プロダクト分析チームの反応速度が上がります⁴。もちろんProtocol Buffers（protobuf）のディスクリプタを噛ませて可観測性基盤でデコードすることも可能ですが、仕組みを用意するまでの速度がビジネスでは効きます。

インシデント対応で“打てる手”が減ったと感じたとき

mTLS（相互認証TLS）や双方向ストリーミング、HTTP/2特有の挙動は、現場のオンコールが手持ちのcurlとtcpdumpだけで切り込むことを難しくします²⁹。grpcurlやgRPC Health Checkは強力ですが、証明書やALPNの罠で足を取られると、初期消火のスピードが落ちます。導入初期はMTTD/MTTRが悪化しがち、という声もあります⁹。EnvoyでのTLS終端統一、grpcurlスニペットの整備、ヘルス/リフレクションの有効化、そしてステータスコードの運用ルール化（INVALID_ARGUMENTは4xx相当、UNAVAILABLEは5xx相当など）を進めると、インシデント対応時間は着実に短縮できます²。

チャットネスとストリーミングがSLOを侵食するとき

gRPCは小粒なRPCを高速に打つのに向きますが、設計しだいでN+1の雪崩（集約を欠いたオーケストレーションで呼び出し数が線形に増える問題）を招きます⁸。さらに双方向ストリーミングはロードバランサのアイドルタイムアウト、コネクションのヘッドオブラインブロッキング（同一コネクション内での詰まり）、フロー制御のチューニングなど、SRE視点での考慮点が増えます²。ページング可能な取得はREST/GETへ寄せ、ストリームは本当にストリームであるべき更新通知だけに絞ることでSLO（合意したサービス品質目標）の安定化が図りやすくなります。

gRPCかRESTかを決める、現場の実用基準

抽象論ではなく、業務要件と非機能要件に引き付けて判断した基準を共有します。内部のユニタリな処理で、低レイテンシ要件が強く、クライアントが社内サービス、CDN不要、言語間の相互運用が必要という条件では、gRPCをデフォルトとするのが理にかないます。公開ベンチマークでも、こうした条件下ではCPUと帯域の節約効果や安定したレイテンシ特性が期待できると示されています¹⁶⁷。逆に、公開APIでドキュメント即時公開、ブラウザ/パートナー接続、キャッシュ前提の読み取り、curlで再現可能なサポート体験という要件が立つなら、REST/JSONを第一候補にします。契約の分かりやすさ、オンボーディングの速さ、運用デバッグのしやすさが勝るためです¹⁴。

ストリーミングは「二者間で状態を共有し続ける価値が定量化できるか」を問いました。高頻度でバッチ化できず、厳しい低遅延が求められ、再接続時のギャップ再送が設計済みであるならgRPCストリーミングを選びます²。そうでなければ、イベントをキューに積み、取得はRESTでポーリングまたはSSEに寄せるほうが運用は素直です。さらに、監査やレギュレーションの観点で人間可読なログが重要な領域では、JSONの可観測性の優位が決め手になる場面もあります⁴。

このように機能の粒度、通信の方向、キャッシュ性、クライアントの多様性、可観測性の要件を並べ、**SLOとコスト（egress/CPU/開発者時間）**で最適化すると、gRPCとRESTの住み分けは自然に定まります。一本化を目指すよりも、方針を明文化し、チームが判断を再現できる状態を目標にすると、設計レビューの摩擦も減ります。

“戻らずに済ませる”ための設計と運用の工夫

それでも私は、できるだけgRPCを活かす道を探ります。まず、エッジはREST、コアはgRPCというファサード戦略を定着させます。Envoyやgrpc-gatewayでのJSONトランスコードにより、外部にはREST/JSONを見せつつ、社内はスキーマ化されたgRPCで結ぶ構成です²¹。これにより、公開面のキャッシュやドキュメント、SDK生成は従来資産をそのまま活用し、内部のスループットと型安全性の恩恵を維持できます。

次に、protobufの進化規約をCIで強制します。フィールドのreserve、oneofの取り扱い、enum値の固定、unknownフィールドの温存などを自動チェックし、互換性違反をブロックします²。インターフェース破壊の未然防止は、戻りたくなる瞬間を劇的に減らします。さらに、ステータスコードのマッピング、デッドラインとリトライのデフォルト、メタデータでの相関ID付与をクライアント/サーバともにインターセプタで共通化し、分散トレーシングが初期状態で機能するように標準化します（OpenTelemetry対応を推奨）。

可観測性では、OpenTelemetryでgRPCのスパンを拾い、ログ側でprotobufをデコードして構造化出力するパイプラインを用意します。これにより、JSONの探索性とgRPCの効率の両取りが可能になります。オンコール向けには、grpcurlのワンライナー、証明書の取り扱い、Health/Reflectionの手順をRunbookに統一し、開発環境のDev Containerにツール一式を同梱すると、初動のばらつきが目に見えて減ります²。

最後に、チャットネスを抑える設計を徹底します。集約APIでN+1を潰し、ページングやサマリを積極的に導入し、ストリームは本当にストリームであるべきイベントに限定します⁸。これらの方針により、gRPC導入後の総合コストは中長期でプラスに転じやすく、運用負債の増加を抑えながら性能目標を達成できます¹⁶⁷。

コストとROIの総括——3年運用の帳尻

数字で断定するのは避けますが、内部サービス間の主要経路をgRPC化した組織では、恒常的なCPU/帯域コストが下がり、ピーク時のレイテンシ特性が改善する傾向が広く報告されています¹⁶⁷。 一方、初年度は学習とツール整備に開発者時間の追加投資が必要で、オンコールの負荷も一時的に上がりがちです⁹。2年目には可観測性と標準化が効き始め、読み取り中心のエンドポイント群をREST/GETに寄せたCDNオフロードと合わせて、全体のSLO遵守率やインシデントあたりの対応時間が改善するケースが多い。結論として、gRPCは“常に正解”ではなく、正しく適用すれば高いROIを生む選択肢です¹。公開向けの読み取りや外部連携はRESTで堅実に、コアの高頻度内部通信はgRPCで効率的に、という住み分けが、ビジネスと技術の両面で最も健全でした。

まとめ——あなたの組織で、どこから見直すか

性能の良さに惹かれて一気にgRPCへ、あるいは慣れ親しんだRESTへ固執、どちらも極端です。まずは自組織のAPIを棚卸しし、公開/内部、読み取り/書き込み、キャッシュ可否、SLOと可観測性の要件を整理してみてください。エッジはREST、コアはgRPCという出発点を置き、例外はSLOとコストの数字で説明する。この「gRPC vs RESTの比較」視点だけで設計議論は前に進みます。次のスプリントでやれることとして、gRPCサービスのHealth/Reflectionを有効化し、grpcurlのRunbookを整え、ひとつの読み取り系エンドポイントをREST/GETに切り出してCDNを当てる小さな実験から始めるのはどうでしょうか。運用の痛みは、小さな勝ちを積み上げるうちに確実に薄れます。関連する設計指針は、社内標準のガイドに落とし込み、継続的に更新していきましょう。

参考文献

  1. AWS. The difference between gRPC and REST. https://aws.amazon.com/jp/compare/the-difference-between-grpc-and-rest/
  2. gRPC Official Documentation. https://grpc.io/
  3. Palark. CNCF cloud-native projects usage stats 2022. https://blog.palark.com/cncf-cloud-native-projects-usage-stats-2022/
  4. LogRocket. gRPC vs REST: A comparison. https://blog.logrocket.com/grpc-vs-rest/
  5. GitHub Issues. Caching with gRPC over HTTP/2 (#7945). https://github.com/grpc/grpc/issues/7945
  6. International Journal of Electronics and Telecommunications (2024). Performance comparison of REST and gRPC. https://ijet.ise.pw.edu.pl/index.php/ijet/article/view/10.24425-ijet.2024.149562
  7. Auth0 (Bruno Krebs). Beating JSON performance with Protobuf. https://auth0.com/blog/beating-json-performance-with-protobuf/
  8. SharpEcho. Microservices and the N+1 problem. https://www.sharpecho.com/microservices-and-the-n1-problem/
  9. Cloud Native Computing Foundation. Integration challenges in microservices architecture with gRPC & REST (2022-02-11). https://www.cncf.io/blog/2022/02/11/integration-challenges-in-microservices-architecture-with-grpc-rest/