はじめに HTTP/3も出てきて今更感があるが、改めてHTTP/2についてまとめてみました。 HTTP1.1とその問題点 HTTP/2誕生前から使用されているHTTP/1.1では基本的には1つのリクエストが完了しレスポンスが返ってくるするまで、次のリクエストを送ることができません。 HTTPパイプラインという仕組みを使えばHTTP/1.1でも完了を待たずに、複数のリクエストを送信することが可能ですが サーバーはリクエストの順番通りにレスポンスを返さなければならないという制約があります。 3つのリクエストを送信して、 1つめのリクエストのレスポンスが最も重い場合は 2つめ以降のレスポンスが待たされる結果となります。 これをHTTP HOL Blockingといいます。 HTTP/1.1で速度を上げ場合には TCP接続を多重化するしかないです。では多重化する場合どこに問題があるのでしょうか？

作成者: James Newton-King gRPC は、高パフォーマンス サービス向けに設計されています。 このドキュメントでは、gRPC から最大限のパフォーマンスを得る方法について説明します。 gRPC チャネルを再利用する gRPC の呼び出しを行う場合は、gRPC チャネルを再利用する必要があります。 チャネルを再利用すると、既存の HTTP/2 接続を介して、呼び出しを多重化できます。 gRPC 呼び出しごとに新しいチャネルが作成された場合、完了までにかかる時間が大幅に増加する可能性があります。 呼び出しのたびに新しい HTTP/2 接続が作成されるため、クライアントとサーバーの間に次のような複数のネットワーク ラウンドトリップが必要になります。 ソケットを開く TCP 接続を確立する TLS ネゴシエーションを行う HTTP/2 接続を開始する gRPC 呼び出しを行う チ

背景 gRPCにはクライアントとサーバとの通信を抽象化したChannelという仕組みがあります。 GRPC_GO_LOG_SEVERITY_LEVEL=infoを有効にした際に出てくる [core] Channel Created [core] parsed scheme: "" [core] scheme "" not registered, fallback to default scheme [core] ccResolverWrapper: sending update to cc: {[{localhost:8080 <nil> 0 <nil>}] <nil> <nil>} [core] Resolver state updated: {Addresses:[{Addr:localhost:8080 ServerName: Attributes:<nil> Type:0 Meta

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

{ "posts": [ { "id": 1, "title": "json-server", "author": "typicode" } ], "comments": [ { "id": 1, "body": "some comment", "postId": 1 } ], "profile": { "name": "typicode" } } また、CRUD処理やソート、ページングなどもjson-serverの仕組みに乗ることで利用が可能です。 クライアント開発では、事前にjsonの定義でサーバ相当の機能を実現、開発し、サーバ開発が完了した時点で本物のサーバを利用するようにします。 gRPCのモックサーバ gRPCの開発スタイル gRPCにおける開発では概ね以下のフローで行います。 クライアント/サーバ間のインターフェイス定義 protocにより、クライアント/サーバの自動生成 サー

gRpcに関して勉強を始めてみたのですが、curlも使えないしpostmanも使えないしサーバ単体での動作確認が面倒でした・・・。なので、今回はgRpcサーバを単体で動作確認するためのgRpcテストクライアントツール「BloomRPC」の紹介です。 環境情報 OS: Windows10 BloomRPC: v1.41 Bloom RPC 私が今回のgRpcテストクライアントツールに求めていたのは以下3点 GUIツール　・・・　やっぱりGUIの方が使いやすい 設定項目がシンプル　・・・　高度な設定はできてもいいけど最初は簡単に使いたい 見た目がごちゃごちゃしていない　・・・　シンプルなのがいい というわけで「BloomRPC」というgRpcクライアントを見つけました。 BloomRPCのインストール homebrew caskに対応しているとのことなので、Macの方の場合以下コマンドでOKで

Introduction Hi I am Chung from System Engineering Department. I have been working on a project using microservices architecture and gRPC for a year and more. When providing technical supports to the project, especially on gRPC in Java side, I have found that web resources/discussions or even official documents are giving insufficient information to developers. This article is going to share about

後追いながら、HTTP2の勉強をしてます。 少しずつ理解できてきたような気がする。 間違っていたら詳しい方はご指摘ください。 +--------+ send PP | | recv PP ,--------| idle |--------. / | | \ v +--------+ v +----------+ | +----------+ | | | send H/ | | ,-----| reserved | | recv H | reserved |-----. | | (local) | | | (remote) | | | +----------+ v +----------+ | | | +--------+ | | | | recv ES | | send ES | | | send H | ,-------| open |-------. | recv H | | | /

A common question with gRPC is how to make it fast. The gRPC library offers users access to high performance RPCs, but it isn’t always clear how to achieve this. Because this question is common enough I thought I would try to show my thought process when tuning programs. SetupConsider a basic key-value service that is used by multiple other programs. The service needs to be safe for concurrent acc

By James Newton-King gRPC is designed for high-performance services. This document explains how to get the best performance possible from gRPC. Reuse gRPC channels A gRPC channel should be reused when making gRPC calls. Reusing a channel allows calls to be multiplexed through an existing HTTP/2 connection. If a new channel is created for each gRPC call then the amount of time it takes to complete

By Gráinne Sheerin (Google SRE) | Monday, February 26, 2018 TL;DR: Always set a deadline. This post explains why we recommend being deliberate about setting deadlines, with useful code snippets to show you how. When you use gRPC, the gRPC library takes care of communication, marshalling, unmarshalling, and deadline enforcement. Deadlines allow gRPC clients to specify how long they are willing to w

課題 gRPC のサンプルコードを Java 11 で動かそうとしたところ、コード生成はうまくいったものの、実行時に下記のようなエラーが出て止まってしまいました。 エラー: シンボルを見つけられません @javax.annotation.Generated( ^ シンボル: クラス Generated 場所: パッケージ javax.annotation 解決策 grpc/grpc-java のイシュー Java 11: cannot find symbol javax.annotation.Generated #5343 に書かれている通り、Javax Annotation APIを dependencies に追加します。（このイシュー自体は Java9 の条件分岐を入れたら動かなくなったという報告ですが、↓のように条件分岐を入れなければ動きます。） dependencies { im

はじめに しっかりと翻訳したり使い方を補足説明するものではありません。 自分が見やすいように言語ごとにテーブルを分けただけのものになります。 引用元の情報は下記リンクから。 参考）Language Guide (proto3) - Scalar Value Types Java .proto Notes Java

デジタル トランスフォーメーションを加速 お客様がデジタル トランスフォーメーションに乗り出したばかりでも、あるいはすでに進めている場合でも、Google Cloud は困難な課題の解決を支援します。

gRPCとは gRPCの概要については、こちらのエントリで記載しています。 このエントリでは、gRPCの運用で気になるポイントや、Javaで実装する場合を中心にまとめていこうと思います。 開発フロー 現代的なシステムではシステム間をAPIを通じて通信することが多くなってきています。 この場合、各システムのインターフェイスは以下のいずれかのパターンで開発が進む場合が多いです。 パターン1: 手動でインターフェイスのドキュメント(仕様書等)を記述し、サーバ、クライアントの開発者でその要件を満たす実装を行う パターン2: サーバ側のコードから、インターフェイスドキュメントを自動生成し、クライアントがその要件を満たす実装を行う パターン3: 手動でインターフェイスドキュメントを記述し、各システム用にサーバとクライアントのコードを自動生成する gRPCを用いた開発では上記の3のパターンで行います。

Send feedback Errors Stay organized with collections Save and categorize content based on your preferences. This chapter provides an overview of the error model for Google APIs. It also provides general guidance to developers on how to properly generate and handle errors. Google APIs use a simple protocol-independent error model, which allows us to offer a consistent experience across different AP