InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example

HTTP2 のフロー制御 この記事は HTTP2 Advent Calendar の 1 日目の記事です。 初回は、執筆時点での最新ドラフトである HTTP2-draft16 のフロー制御(Flow Control) について解説します。 余談ですが, 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称です. 更新 @kazu_yamamoto さんに指摘頂いた点を反映しました。 @kiri__n さんに指摘頂いた点を反映しました。 詳細については 更新履歴 をご覧下さい。 フロー制御 HTTP2 では、同じホストへの複数のリクエストを、同一の TCP コネクション上にストリームという単位で多重化することができるようになりました。 フロー制御とは、例えばひとつのストリームがリソースを占有してしまうことで、他のストリームがブロックしてしまう

For past few months we’ve been working on improving gRPC-Go performance. This includes improving network utilization, optimizing CPU usage and memory allocations. Most of our recent effort has been focused around revamping gRPC-Go flow control. After several optimizations and new features we’ve been able to improve quite significantly, especially on high-latency networks. We expect users that are

背景・やりたいこと c++で開発中、clang-formatを実行しわすれてコミットしてしまうことがあった git-clang-formatや、ここに書かれているhookを使えば解決するかもしれないが、この先他者にも使ってもらう場合を考えると、極力コマンドをインストールすることは避けたい そこでgit commit時にclang-formatを走らせ、変更されるファイルがあればcommitを失敗させるhookを作った 個人の好みだが、git logを見たときに「こんな書き方したっけ？」とならないよう、ソースの修正は自身でやったほうがいいと思っている。 この理由から、git commit時にファイルの修正依頼のみ出力し、ファイルの修正は行わない。 動作確認環境 $ lsb_release -a No LSB modules are available. Distributor ID: Ubu

概要 以前 christina04.hatenablog.com こちらの記事で、アプリケーション内でのレイヤ間のエラーハンドリングについてまとめました。 ではマイクロサービス間でそのエラーコードを伝播していくのはどうすれば良いのか、というのが今回の主題です。 課題 gRPCはレスポンスコードを持っています。 しかしこれだけでは下記のようなケースをハンドリングできません。 フォームのvalidationエラーを伝える際に、どのフィールドの不備が原因か カード決済時のエラーで、カードの何が問題でエラーが起きているのか このような詳細なエラーをクライアントに伝えられない場合、クライアントは抽象的なエラー文言しかユーザに出せず、結果としてユーザは問題を解決することができなくなります。 解決案1) エラー文言をparse gRPCは以下のようにレスポンスコード以外にもメッセージ（文字列）を返すこと

背景 gRPCでは主に Proxy Model Balancing-aware Client External Load Balancing Service といったLBアプローチがあります。 それぞれの特徴や実装方法を調べてみました。 Load Balancingアプローチ こちらで定義されてます。 grpc/load-balancing.md at master · grpc/grpc · GitHub 主な負荷分散のアプローチとしては以下です。 Proxy Model LBと言われて最初に浮かぶイメージですね。 ref: https://grpc.io/blog/loadbalancing/ メリット クライアントと独立しているため、クライアントは自身のアプリケーション実装にのみ集中できます。シンプルでPolyglot向きでもあります。 またProxy側に様々な拡張ができます（メトリ

概要 gRPCでは１つのHTTP/2コネクション上でstreamを多重化します。 しかしidleなコネクションは、LBなど間に介在するネットワーク機器によって気づいたら切断されているケースがあります。 そうならないよう、定期的にパケット（PINGフレーム）を流して「idleではないよ」とコネクションを維持しようとするのがいわゆるkeepaliveという仕組みです。 gRPCではデフォルトの設定では無効になっている＆地味に設定が細かいので１つ１つ説明します。 gRPCのkeepaliveの役割 大きく２つあります。 １つ目は先に述べたようにidleコネクションを維持するためです。 ２つ目は死んだコネクション（TCPハーフオープン）があったら切断し、再接続するためです。 例えばNLBでは350秒以上idleなコネクションが切断される仕組みがあり、これによって普段あんまりトラフィックの無いサービ