gRPC アプリケーションを AWS で動かすときの注意点 | はったりエンジニアの備忘録
freee ではプロダクトの拡大に合わせて、汎用的な機能をマイクロサービスに切り出していこうとしています。すでにマイクロサービス化されているところは REST API による通信を行なっているのですが、これから新しく作るところはデフォルトで gRPC を採用しようとしています。 freee のサービスはすべて AWS 上で動いていますが、本格的に採用する前に gRPC アプリケーションを AWS で動かすときに注意することを調べてみました。 ALB では gRPC の HTTP/2 通信を負荷分散できない gRPC はデフォルトで HTTP/2 で通信します。 ALB (Application Load Balancer) は HTTP/2 に対応していますが、対応しているのはあくまでクライアントと ALB のフロントエンド側（リスナー）であり、ALB と EC2 のバックエンド側（ターゲ
gRPCのロードバランシング - はこべにっき ♨
先日の記事から引き続きgRPCについて勉強してる。 gRPCのサーバをプロダクトで利用する場合に気になるのが、ロードバランシングをどういう風にやったら良いのかということで、その部分について調べてみた。 TL;DR: gRPC Load Balancing を読めばだいたいわかる gRPCのロードバランシングのポイントとしては、gRPCが基本的にはHTTP2上に構築された仕組みである*1ことに注意して考えると良さそうだった。 プロキシ によるロードバランシング まず考えられるのは、gRPCのサーバとクライアントの間にプロキシを設置してロードバランシングを行う方法だ。 よくあるHTTP/1.1の世界で考えると、複数のWebアプリケーションサーバの前段にnginxのようなリバースプロキシを設置してロードバランシングする方法になる。 gRPCはHTTP/2を利用するので、この方法の場合リバースプロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
