オンプレミスからクラウドへの移行をはじめ、ハイブリッドクラウド環境をシームレスに保護しながら、クラウドの利点を実現します。 詳しくはこちら
Wire type は実際の型を示しているわけではないことに注意してください。Wire type はあくまでも値を読み取るための手がかりにすぎないため、読み取った値をどの型にするべきか知るためには descriptor を参照しなければいけません。 タグは次のようなロジックでエンコードされます。 fieldNumber << 3 | wireType たとえばフィールド foo の場合、フィールド番号は 1、Wire type は 0 なので 08 となります。これはエンコードされたバイト列の先頭バイトと一致しています。 fieldNumber := 1 wireType := 0 tag := fieldNumber<<3 | wireType fmt.Printf("%x", tag) // 08 タグの直後にはそのフィールドに対応する実際の値が続きます。 Wire type に基づい
はじめに 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接続を多重化するしかないです。では多重化する場合どこに問題があるのでしょうか?
Tonic: gRPC has come to async/await! I am pleased to finally announce a crate that I have been working very hard on for the past few months. tonic has finally hit the initial 0.1.0-alpha.1 release! Stable releases will follow in the coming months. What is Tonic? Tonic is a gRPC-over-HTTP/2 implementation focused on high performance, interoperability, and flexibility. This library was created to ha
gRPC リフレクションは、対象の gRPC サーバがどのようなサービス、メソッドを公開しているかを知るための機能です。 gRPC を使う上でリフレクションを有効にすると、gRPCurl や Evans といったツールを使う際に Protocol Buffers などの IDL を直接的に読み込まずにメソッドを呼び出すことができてとても便利ですが、gRPC リフレクションはなにをしていて、ツールは gRPC リフレクションをどうやって使っているのでしょうか? それなりに複雑でしばしば忘れるので記事にしておこうと思います。なお、この記事では gRPC の実装として grpc/grpc-go、Protocol Buffers の実装として protocolbuffers/protobuf-go を参照します。 gRPC リフレクションを有効化しているサーバの例 grpc/grpc-go に g
gRPC over HTTP/3のプロポーザルと、実装が出てきています。 プロトコル仕様: https://github.com/grpc/proposal/blob/master/G2-http3-protocol.md 実装 (.NET6): https://devblogs.microsoft.com/dotnet/http-3-support-in-dotnet-6/ 今回は、仕様を眺めつつ、Ubuntuで実装を動かすところまで試してみようと思います プロトコル仕様 プロポーザルは、現在 "In review" の状態となっています。 github.com HTTP/3の基本 HTTP/3はHTTP/2と機能上は大きな違いはありません。HTTPリクエストで通信が始まり、各HTTPリクエスト・レスポンスはQUICのストリームによって多重化されます。そのため、gRPC over HTT
調査する機会があったので、ブログにまとめてみました。 gRPCでは、データ通信にProtocol Buffersとよばれるシリアライゼーション形式を利用します。 Protocl Buffersは、データのシリアライゼーション形式として知られる一方で、シリアライズするためのスキーマ定義用として.protoファイルというインタフェース定義言語(IDL)を持っています。 実際の開発においては、この.protoファイルを先に作成することでスキーマファーストな進め方ができるのが大きな特徴です。 今回は、.protoファイルの作成~認可処理の実装~AWS環境へのデプロイまで一気通貫で紹介したいと思います。 せっかちな人へ GitHubリポジトリにすべて上げています。 構成図 ディレクトリ構成 $ tree -L 2 . ├── Dockerfile ├── go.mod ├── go.sum ├──
背景 以前gRPCのkeepaliveについて説明しました。 christina04.hatenablog.com keepaliveの目的は idleコネクションを維持するため 死んだコネクション(TCPハーフオープン)があったら切断し、再接続するため と書きましたが、どちらの検証もアクティブなRPCがなくなってからのkeepaliveの例であり、リクエストが続く中での挙動は検証できてなかったので今回はそれを行います。 環境 grpc-go v1.38.1 Ubuntu 18.04 (Linux Kernel 4.15.0-147-generic) PINGフレームはいつ送信される? Client-side keepaliveのパラメータであるTimeで送信間隔は設定できますが、いつ条件を満たして発火する(タイマーが開始する)かについては説明していませんでした。 Proposalでは i
Google が開発した RPC(Remote Procedure Call)システムです。 サーバとクライアント間で HTTP/2 を経由した関数呼び出しを実現します。 Go, JavaScript(Node.js), PHP, Python, Ruby, Java, C/C++, C#, Dart, Kotlin などで利用可能です。 Protocol Buffers と呼ばれるインタフェース記述言語(IDL)でインタフェースを定義します。 ストリーミング型のインタフェースを実装することもできます。 CentOS 8 + Python の場合の例を示します。インストールにはそこそこの時間がかかります。 # CentOS 8 + Python # yum -y install gcc-c++ python3 python3-devel # pip3 install grpcio==1.3
.NET Core になると WCF のサーバーサイドが消えて移行先として gRPC があげられてるのを何処かで見た気がします。OSS の WCF もあった気がするけど、そっちはよく見てない。 ということで、ASP.NET Core 3.0 Preview で gRPC 試してみようと思います。 プロジェクトの作成 今日は出先のカフェでコーヒー飲みながら Surface Go で書いてます。なので Visual Studio 2019 は入ってない(Surface Go には重すぎた)ので、Visual Studio Code でいきます。 適当なフォルダーで空の Web アプリを作ります。 $ dotnet new web -o GrpcServer ソリューションも作って追加しておきましょう。 $ dotnet new sln $ dotnet sln add GrpcServer/G
この記事はtraP Advent Calendar 2021 42日目の記事です。 こんにちは、20Bのxxarupakaxxです。 今回はgRPCについて解説していきます。 ※本記事ではgRPCのサンプルコードはございません。ただただgRPCについて話していきます。 自分が所属しているプロジェクトのミーティングでgRPCについて話題が上がり実際にgRPCで開発を進める方針になったので自分が調べた限りの知見をまとめて共有しようかなと思います。 gRPCってなんぞや gRPCって聞かれてもなんも思いつかないですよね.. gがついているから、Googleがなんか作ったんじゃないのって思うそこのあなた!そうです、Googleが開発したものなんです!!ですが、g + RPC.. RPCってなんだろうと思う方が多いかと思います。なのでまずRPCについて軽く説明していきます。 RPCってなに RPCと
ちょっと前にこんなニュースがありました。 www.publickey1.jp 公式はこの辺かな? dapr.io github.com Microsoft が OSS で、しかも golang で作ったという異色のライブラリです。 また最近は envoy を使ったサービスメッシュについて色々と調べていたこともあり、似たような問題を解決するものであるといこともあり、興味を持ちました。 サンプルやコンセプトページを見ているとなんとなく雰囲気がつかめてきます。 github.com github.com Isito のように、各サービスにサイドカーとして起動するDapr インスタンスとサイドカーインスタンスを管理するDaprサーバーから構成されている。 サイドカー経由でサービスにアクセスすることでアドレス解決を任せたり、プロトコル変換ができる。 例えば、HTTPしかないサービスをgRPC経由で呼
表題通りの記事です。 これからnode.jsを10->12に更新する方の助けになれば幸いです。 確認環境 Ubuntu: 18.04.3 LTS node.js: 10.16.0、12.14.1 ビルドツール: gulp (後述しますが4系へのアップデートが必須でした) やったこと(全体像) n をつかってローカル環境のnode.jsを10->12に更新 (参考: nodeとnpmのバージョン更新方法) npm ciして、出てきたエラーを潰す firebaseの更新 node-sassの更新 npm run buildして、出てきたエラーを潰す gulpを3系->4系へ移行 エラー1 (firebaseの更新により解消) 最初はイージーケースから。 事象 npm ciしたところ、大量(体感3分)のログが出力され、最後に以下のエラーが吐かれました。 # これ以前にも大量のエラーログが出る c
【gRPC】Connect が作られた背景概要/これまでの gRPC-Web/Connect でできること はじめに 何故 Connect が作られたのか? gRPC-Web とは proxy 層が必要な理由 gRPC-Web のソースを追う Envoy Proxy & gRPC-gateway 補足 Connect とは Connect-Web Connect-Web のソースを追う fetch api についての補足 Connect チュートリアル + α connect-go (サーバサイド) 初期構築 コード生成 ルーティング ERROR Interceptors Streaming Client-Side Streaming RPC Server-Side Streaming RPC 補足 (HTTP Trailer について) connect-web (フロントエンド) 初期構
概要 gRPCで4MB以上のデータ転送をしようとすると rpc error: code = ResourceExhausted desc = grpc: received message larger than max (xxxxxxx vs. 4194304) のようなエラーが出ます。この上限はデフォルト値なのでgrpc.MaxRecvMsgSize()やgrpc.MaxCallSendMsgSize()を使うことで変更可能ですが、ドキュメントでも以下のように Protocol Buffers are not designed to handle large messages. As a general rule of thumb, if you are dealing in messages larger than a megabyte each, it may be time to
Tubi streams thousands of free movies and series to millions of users and we hope to leverage technology to deliver happiness to our users. Over the last year, we combined gRPC and Elixir to run several mission critical services in production. These services are used to serve listings of titles, content metadata and other exhaustive details, all essential parts of the core viewing experience of Tu
Cloudflare launched support for gRPC® during our 2020 Birthday Week. We’ve been humbled by the immense interest in the beta, and we’d like to thank everyone that has applied and tried out gRPC! In this post we’ll do a deep-dive into the technical details on how we implemented support. What is gRPC?gRPC is an open source RPC framework running over HTTP/2. RPC (remote procedure call) is a way for on
この記事について GRPC は HTTP/2 の上に構築されているため、クライアントからサーバーのサービス呼び出しや、サーバーからクライアントへ戻り値やエラーの送信、といったやり取りは HTTP/2 のリクエストとレスポンスで実装されています(もうちょっと厳密に言うと HTTP/2 フレームを使って実装されている)。 この記事ではGo言語のGRPC実装(grpc-go)を用いて、以下についてまとめてみました。 GRPC が用いる HTTP/2 のリクエスト、レスポンスの流れと構造 その中でエラーがどう伝播されるか GRPC の Unary RPC のエラーハンドリング 扱いにちょっと悩む Streaming RPC のエラーハンドリング 環境等の情報 記事の作成に用いた環境: Go言語 : v1.15.6 grpc-go : v1.34.0 この記事で用いたソースコード grpc-erro
はじめに この記事は Google Cloud Japan Advent Calendar 2022 の「通常版」の 21 日目の記事です。 こんにちは、Google Cloud でデータベース系のプロダクトを担当している佐藤です。 TL;DR - 最初にまとめ 本記事では以下の内容が書かれています。今回は Cloud Spanner 用のアプリケーションの話で例示していますが、gRPC を使う他のアプリにも応用ができる内容になっています。 本記事の内容 アプリケーションが Cloud Spanner へ投げる SQL および mutation とパラメータは、gRPC レイヤーでまとめて取得することができる gRPC には Interceptor という、各 RPC のリクエストごとに任意の処理を割り込ませる仕組みがある Interceptor で Cloud Spanner 用のアプリ
本記事はRettyマイクロサービス強化月間の四つ目の記事です. engineer.retty.me RettyのtoB開発チームでエンジニアをしています鈴木です. 社会人エンジニアも早いことに1年が経ってしまい, “ピチピチエンジニア” の称号と権利を失ってしまいました. 今年は “深みと勢いのエンジニア” として活動しています. ピチピチエンジニアとして投稿した以前の記事では, その時おすすめの焼き芋を紹介したので今回も最近おすすめのお店としてMEARIを載せます. retty.me 今まで実家の焼き鳥が一番美味しいと思っていた自分に衝撃を与えたお店です. 早速本題に入りますが, RettyのtoB開発チームではtoC開発チームと同様にPHPで作られた大きいモノリスからGoで書かれたマイクロサービスへの移行が進んでいます. 現在, Rettyにおけるとても重要なシステムである予約APIの
作成者: James Newton-King gRPC は、高パフォーマンス サービス向けに設計されています。 このドキュメントでは、gRPC から最大限のパフォーマンスを得る方法について説明します。 gRPC チャネルを再利用する gRPC の呼び出しを行う場合は、gRPC チャネルを再利用する必要があります。 チャネルを再利用すると、既存の HTTP/2 接続を介して、呼び出しを多重化できます。 gRPC 呼び出しごとに新しいチャネルが作成された場合、完了までにかかる時間が大幅に増加する可能性があります。 呼び出しのたびに新しい HTTP/2 接続が作成されるため、クライアントとサーバーの間に次のような複数のネットワーク ラウンドトリップが必要になります。 ソケットを開く TCP 接続を確立する TLS ネゴシエーションを行う HTTP/2 接続を開始する gRPC 呼び出しを行う チ
TL;DR grpc-go v1.64.0からDial()やDialContext()がDeprecatedとなった 代わりに推奨されたNewClient()を使うとbufconnを使っているテストがUnavailable(name resolver error: produced zero addresses)で落ちる 初期化として resolver.SetDefaultScheme("passthrough") を突っ込むと動くよ 原因 gRPCクライアントを作成する際、従来のDial(), DialContext()ではデフォルトのネームリゾルバーは passthrough として作成されます。 これがNewClient()からは dns になったためです。 bufconnは passthrough であることが前提で作られているためエラーになります。 rpc error: code
※3つの方式ともに、シリアライゼーションには他の仕様を選択することも可能ですが、一般的なものを記載しています いずれかの方式に統一することもできますが、大規模なシステムに於いては、マイクロサービス間通信にgRPC、フロントエンドとの通信にGraphQL、外部公開するAPIにOpenAPIといったように、ユースケースに応じて使い分けるのも良いと思います。 gRPCを利用してみた感想ですが、パフォーマンスもさることながら、OpenAPIと比べて仕様が単純な分、IDLを元に生成される雛形(スタブ)の品質が高く複数言語での利用をスムーズに行うことができそうだと感じました。 gRPCの呼び出しスタイル gRPCの呼び出しスタイルには、単項RPCと3つ(サーバ/クライアント/双方向)のストリーミングRPCがあります。 詳しくはRPC life cycleをご覧ください。 本記事ではServer str
まえがき この記事は以下の順序で組み立てられています。 gRPC用のコードを自動生成する APIとして呼び出される関数の実装をする gRPCサーバーとして起動する CLIツールを使って呼び出してみる 記事を書くために動作確認をしている環境はUbuntu18.04です。 ただしMacやその他のOSでも、ツールのインストール周りを公式のドキュメントに差し替えて頂ければ動かせるかと思います。 間違いなどありましたら、コメントや編集リクエストなどを貰えると嬉しいです。 gRPC用のコードを自動生成する 1. リクエストとレスポンスの構造を定義する まずはProtocol Buffersと呼ばれる、構造を定義する為の言語を使って、リクエストやレスポンスを定義していきます。 example.proto syntax = "proto3"; package pb; message HelloReques
Internet RPC protocols have been notoriously inefficient, from XML stanzas to HTTP/JSON using unidirectional communications — gRPC to the rescue! Announced last year, gRPC is an open source RPC framework that came out of Google’s experience running much of our infrastructure using an internal version called Stubby. Not only is gRPC significantly more efficient than JSON/HTTP APIs, it supports most
Buf builds tooling to make schema-driven, Protobuf-based API development reliable and user friendly for service producers and consumers. Your organization shouldn't have to reinvent the wheel to work with Protobuf—our tools simplify your Protobuf management strategy so you can focus on what matters. Install the Buf CLI, try it out along with the Buf Schema Registry, and then peruse the documentati
フィードバックを送信 Envoy プロキシを使用して GKE 上で gRPC サービスのロードバランシングを行う コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このチュートリアルでは、外部パススルー ネットワーク ロードバランサと Envoy プロキシを使用して、Google Kubernetes Engine(GKE)にデプロイした複数の gRPC サービスを 1 つの外部 IP アドレスで公開する方法について説明します。また、Envoy が gRPC 用に提供している高度な機能の一部についても取り上げます。 はじめに gRPC は、HTTP/2 をベースとした、言語に依存しないオープンソースの RPC フレームワークです。プロトコル バッファを使用し、効率のよいデータ転送と高速なシリアル化を実現します。Google 内部の RPC フレームワークであ
goでgRPCを実装してみました。 gRPCの4つの通信方式を実際にやってみます。 ・Unary RPCs(SimpleRPC) ・Server streaming RPC ・Client streaming RPC ・Bidirectional streaming RPC この記事内容を上から行えば、Dockerで動く環境が作れます。 Dockerでこの4つの実装してる記事は少ないはず。 gRPCとは googleの「RPCのフレームワーク」です。 RPCは、アプリケーション間のデータ通信するためのプログラムのことです。 gRPCでは、以下を提供します。 HTTP/2、10言語の公式サポートライブラリ、プロトコルバッファ(構造体みたいなもの)を定義することにより言語を問わずにデータ通信が可能、ヘルスチェック、ロードバランシングなどをサポート。 一言で言うと、簡単にアプリケーション間のデー
Amazon Web Services ブログ 新規 – エンドツーエンドの HTTP/2 および gRPC についての Application Load Balancer のサポート その効率性と多数のプログラミング言語をサポートしていることから、gRPC はマイクロサービス統合およびクライアント/サーバー通信に人気のある選択肢となっています。gRPC は、HTTP/2 をトランスポートに使用し、インターフェイスを記述するためにプロトコルバッファを使用する、高性能なリモートプロシージャコール (RPC) のフレームワークです。 アプリケーションで gRPC を使用しやすくするために、Application Load Balancer (ALB) は HTTP/2 エンドツーエンドのサポートを開始しました。これにより、単一のロードバランサーを介して gRPC サービスを非 gRPC サービ
はじめにIDLやエコシステム、サービス間の通信(何かしらのRPC関連の技術)をテーマにした連載を始めます。 IDL(インターフェース記述言語: Interface Definition Language)と聞けばWSDL(SOAP)であったりJSON-RPCなどを思い出す人も多いかと思いますが、2022年時点で新規に技術選定するのであれば、よく選ばれるのは次のプロダクト群でしょう。 GraphQL Protocol Buffers(gRPC) OpenAPI Specification それぞれ長所・短所があるかと思いますが、それぞれエコシステムも成長も伴いどんどん使い勝手が上がっているように思えます。こういったIDLでスキーマを定義し、それを駆動にしてコミュニケーションの齟齬をなくしたり、コードやドキュメントを自動生成させるなどで、開発生産性を高めることも当たり前に行われつつあるように感
この記事について Dart Advent Calendar 2019 の 13 日目の記事です。 その後も読みやすい記事になるようたびたび改善してます。 対象者 gRPC を知らない人 少し知っているけれど使い方がわからない人 使いどころがわからない人 Dart での使い方を知らない人 目標 Dart で REST 等の Web API の代わりに gRPC を使う基本的な方法を把握する 他の使い方(双方向の通信が必要な用途など)もイメージできるようにする GitHub リポジトリ この記事のコードを GitHub に置いています(英語にして、他にも少しだけ変えています)。 kaboc/dart_grpc_examples gRPC とは Google によって開発されたオープンソースの RPC フレームワークで、今は Cloud Native Computing Foundation(C
Error handlingHow gRPC deals with errors, and gRPC error codes. Standard error modelAs you’ll have seen in our concepts document and examples, when a gRPC call completes successfully the server returns an OK status to the client (depending on the language the OK status may or may not be directly used in your code). But what happens if the call isn’t successful? If an error occurs, gRPC returns one
2024-05-22 アーキテクチャを突き詰める Online Conference https://findy.connpass.com/event/314782/ ■ 参考URL - コンパウンドスタートアップというLayerXの挑戦|福島良典 | LayerX - https://comemo.nikkei.com/n/n7332c93f50c7 - ビジネスドメインの拡大を実現する バクラクシリーズでのモノレポ開発 - Speaker Deck - https://speakerdeck.com/layerx/bakuraku-devsumi-2024-yyoshiki41 - Connect - https://connectrpc.com/ - gRPC - https://grpc.io/ - Protocol Buffers によるプロダクト開発のススメ - API 開発の
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く