学習の狙い

このプロジェクトは、REST APIとgRPCの性能の違いを学ぶことを目的としています。

REST/gRPC 高負荷試験レポート

実行環境

• ハードウェア: Raspberry Pi 4 (4GB RAM)
• OS: Raspbian/Linux
• テスト対象: REST API（Go製）/ gRPC API（Go製）
• 監視: Prometheus + Grafana

負荷試験条件

• 総リクエスト数: 10,000
• 並列数: 1,000
• リクエスト内容: {"name":"Taro"}
• REST: hey
• gRPC: ghz

主な結果比較

指標	REST API (hey)	gRPC (ghz)
合計時間	約1.3秒	約0.4秒
平均応答時間	約50ms	約40ms
最速応答時間	約0.4ms	約15ms
最大応答時間	約1,000ms	約100ms
リクエスト/秒	約7,800	約23,000
エラー	0	0
中央値(50%)	約14ms	約36ms
90%以内	約122ms	約56ms
99%以内	約423ms	約85ms

評価・考察

• スループット（リクエスト/秒）: gRPCはRESTの約3倍のリクエスト/秒を処理でき、より高いパフォーマンスを発揮。
• 平均・最大レイテンシ: gRPCの方が平均応答時間が短く、最遅応答もRESTより大幅に速い。
• 安定性: 両者ともエラーは発生していないが、gRPCの方がレイテンシのばらつきが小さく安定。
• プロトコルの違い: gRPCはバイナリ通信・HTTP/2ベースで効率が良く、REST（HTTP/1.1・テキストベース）よりも高負荷時の性能が出やすい。

結論

• gRPCはREST APIよりも高スループット・低レイテンシで、同条件下でより高いパフォーマンスを示した。
• 高負荷・高並列環境ではgRPCの優位性が明確。
• RESTも十分な性能を発揮しており、用途や互換性を考慮して選択すると良い。
• Prometheus+Grafanaでリソース・アプリ指標を可視化し、限界性能やボトルネックも把握できた。

まとめ

• Go製APIは、今回のような1万リクエスト・1,000並列程度であれば、比較的低スペックなサーバー環境でも十分に安定して捌けることが確認できた。
• gRPCは高負荷用途で特に有効。
• 今後はさらに高負荷・長時間テストやリソース監視を組み合わせて、より詳細な性能評価・チューニングが可能。

---

補足情報（将来見返す際のために）

テスト目的・背景

• RESTとgRPCのAPI方式の性能差を比較し、システム設計やスケーラビリティ検討の参考とするため。

テスト実施日

• 2025年9月

使用ツール・バージョン

• Go: 1.23
• hey: v0.1.4
• ghz: v0.110.0
• OS: Raspbian/Linux

サーバー・クライアント構成

• テスト実行マシンとAPIサーバーは同一（Raspberry Pi 4）
• ローカルネットワーク内で実施

API仕様

• テスト対象エンドポイント: /sayhello（POST, JSON: {"name":"Taro"}）
• レスポンス例: {"message":"Hello, Taro"}
• gRPC: Greeter.SayHello（proto/greeter.proto）

主要な設定ファイル

• Prometheus: pi1/prometheus.yml
• Docker: pi3/rest-sample/docker-compose.yml など

注意点・前提条件

• テスト時は他の重いプロセスなし、ネットワーク安定状態
• サーバーリソース監視はPrometheus+Grafanaで実施

今後のTODO・改善案

• さらに高負荷・長時間テストの実施
• サーバースペックやネットワーク構成を変えた場合の再検証
• 複雑なAPIシナリオや複数エンドポイントでの比較