サーバ側は単純にreturn nilするだけで、クライアントにio.EOFが飛ぶからいいんですけどねー。
Hori Blogフリーランスでバックエンドエンジニアとして活動している Ryota Hori のブログです。 最近はテック系記事より雑記ブログ気味。 先日発表された AWS の Network Load Balancer (NLB) を gRPC で使ってみたのですが、 idle timeout 周りで盛大にミスったので知見共有です。 経緯 先日、 NLB こと Network Load Balancer が AWS にてリリースされました。 新しい Network Load Balancer – 秒間数百万リクエストに簡単にスケーリング | Amazon Web Services ブログ NLB は TCP レベルでのロードバランシングができ、プレウォーミングなしで高パフォーマンスを発揮できるため既存の AWS の LB に比べ gRPC との相性が良いです。 マイクロサービス構成を取
Kubernetes上でgRPCサービスを動かすことが多くなってきている.が適切にロードバランスをする,リクエストを落とさずサービスをデプロイするためにいくつか注意することがあるので簡単にまとめておく. 以下の2つを意識する. Kubernetes ServiceはL4のLoad balancer(LB)であること gRPCはコネクションを使いまわすこと KubernetesのPodは死んだり作られたりを繰り返す.KubernetesのPodにはそれぞれ内部IPがアサインされるが,このIPはPodが新しく作成される度に変わる.IPが変わってもPodにアクセスするためにKubernetesではServiceをつくる.ServiceはPodを抽象化しVirtual IP(VIP)を提供する.VIPを使うことでPodのIPが変わってもPodにアクセスすることができる. VIPはNetwork i
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のサーバをプロダクトで利用する場合に気になるのが、ロードバランシングをどういう風にやったら良いのかということで、その部分について調べてみた。 TL;DR: gRPC Load Balancing を読めばだいたいわかる gRPCのロードバランシングのポイントとしては、gRPCが基本的にはHTTP2上に構築された仕組みである*1ことに注意して考えると良さそうだった。 プロキシ によるロードバランシング まず考えられるのは、gRPCのサーバとクライアントの間にプロキシを設置してロードバランシングを行う方法だ。 よくあるHTTP/1.1の世界で考えると、複数のWebアプリケーションサーバの前段にnginxのようなリバースプロキシを設置してロードバランシングする方法になる。 gRPCはHTTP/2を利用するので、この方法の場合リバースプロ
はじめに 最初にIngressについて説明する必要があるだろう。誤解を恐れずにいろいろと端折って文章にするならば、Kubernetesというコンテナーオーケストレーションシステムが用意しているIngressは、Kubernetesクラスタ内で稼働しているHTTPベースのサービスに対して、クラスタ外部からアクセスする手段を提供するものである。Kubernetesが定義するIngressは、ただのリソースであり、HTTPにおけるホストとパスでどのサービスへリクエストをフォワードすればよいかのルールを記述する。実際にリクエストをIngressリソースの通りにフォワードする機能は、Kubernetes本体では提供されていない。この隙間機能、すなわち、Ingressリソースを読んでいい感じにL7ロードバランサーを設定してリクエストが期待通りにフォワードされるようにする機能を提供するものこそが、Ing
Today, we’re excited to share the first native support for gRPC traffic, released in NGINX Open Source 1.13.10. NGINX Plus Release 15 includes gRPC support as well as the support for HTTP/2 server push introduced in NGINX 1.13.9. NGINX can already proxy gRPC TCP connections. With this new capability, you can terminate, inspect, and route gRPC method calls. You can use it to: Publish a gRPC service
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く