You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Go 1.19が8/2に早々にリリースされました。個人的にはGo 1.19よりも楽しみだったのが、サービス間通信とIDL(インタフェース記述言語)連載の中でご紹介したgRPCのGo実装の新星、Connectのアップデートでした。そしてそれはやってきました。 詳しい内容は↑の記事を見ていただくとして、Connectがその開発元ブログの紹介記事で宣言していたのが次の2つのことでした。 Go 1.19が出たらconnect-goは1.0にして以後後方互換性を守るよ connect-webを出すよ 前者はまだ0.3だったのですが、connect-webはリリースされました。歴史のあるフロントエンドのコードジェネレータはTypeScript対応が後付けだったりするのですが、TypeScriptがファーストシチズンかつ、ネイティブというコードジェネレータなので、開発はかなりやりやすくなることが期待され
*1 最大値と最小値を除いた値の平均値 gRPC、REST API共に1回目のリクエストではコネクションの作成の影響かパフォーマンスの悪化が見られたものの、2回目以降のリクエストではgRPCがREST APIに比べ2倍以上速い結果となりました。 gRPCの実装の容易さ gRPCを採用した3つ目の理由は「実装の容易さ」です。 前項でgRPCの通信速度について紹介しましたが、この恩恵を.protoファイルから自動生成したソースコードを利用することで簡単に享受することができました。以下はGo言語とC#(Unity)それぞれのgRPCクライアントの実装例です。 【Go言語】 conn, err := grpc.Dial("localhost:8080", grpc.WithInsecure()) if err != nil { panic(err) } defer conn.Close() cli
こんにちは、ティアフォーで認証認可基盤を開発している澤田です。 最近取り入れたProtobufで、素晴らしいREST APIの開発体験をしたのでご紹介します。 なお、ティアフォーではマイクロサービスを支える認証認可基盤を一緒に開発いただけるメンバーを募集しています。ご興味のある方は下記ページからご応募ください。 herp.careers 実現したかったこと マイクロサービス間連携のAPI開発において、以下の条件を満たすやり方を探していました。 スキーマを最初に定義してリクエストとレスポンスの型が自動で生成される ドキュメント(openapi.yaml)が生成される バリデーションが定義できて、その実装が自動で生成される 実現方法 Go言語で開発する場合はgo-swaggerでも実現できますが、本記事では、Protobufで実現できるgRPC Gatewayとprotoc-gen-valid
Serving gRPC+HTTP/2 from the same Cloud Run container Ahmet Alp Balkan published on 03 June 2021 In this article I will show you how to code a Go server to serve both gRPC and HTTP/2 endpoints (h2c) from a single service. This is not trivial on Cloud Run so it warrants sample code. Normally, you could use the Go cmux package in your server app and multiplex h2c and grpc requests to the right http.
GoのgRPCサーバをGKEのIngressで使うために、GKEのHealth CheckがgRPCでないAPIを要求することの回避方法kubernetesGKEgrpGoogleCloud tl;dr Ingress の Health Check は HTTPS の GET リクエスト(gRPC ではない)で 200 を返さないといけない Go の gRPC サーバの実装に追加で、普通の HTTPS の GET リクエストで /healthz で 200 応答を返すようにする Pod の Readiness Probe を、HTTPS の GET リクエストのパス /helathz に設定すると、Health Check がそのパスに対して行われるようになる Ingress と gRPC の Health Check の問題とは GKE を使ってサービスを公開する場合、L7 Load B
gRPC client/server running loadbalanced/failover on Google Compute Engine and Google App Engine — salrashid123/gcegrpc cd gke_ingress_lb_backend_config kubectl apply -f .Wait for the Ingress and Loadbalancer configurations to allocate an IP and test as described below. How it works: Look at fe-srv-ingress.yaml file for the BackendConfig: --- apiVersion: v1 kind: Service metadata: name: fe-srv-ingr
GKE Ingress+Envoy+gRPC で、Ingress の Health Check をクリアして構築するGKEgRPCenvoy tl;dr GKE の Ingress (L7 Load Balancer) では、HTTP(S) の GET Request で、Health Check が行われる gRPC アプリで、gRPC の Health Check を用意する Envoy で Lua を使って、GET リクエストを Envoy の Health Check と繋げることで Health Check をクリアさせる ソースコード https://github.com/74th/try-envoy/tree/master/manifests/4_gke_ingress 問題点 GKE で、サービスを公開する手段として、L7 Load Balancer である Ingress
kubernetes(今回はGKE内)でgRPCの通信を場合にぶち当たる問題として、ロードバランシングの問題があります。 gRPCの通信は永続化されるので、そのままの状態で使うとバックエンドにあるサービスがスケールしても分散されないということになります。 具体例 上記のような構成でhoge-gateway(4pod)からhoge-app(10pod)に向けてコネクションプーリングが1で通信をする場合、hoge-appが最大4podしか使われない状態になります。 下記がその状態です。 GKE Container - CPU usage for hoge-app GKE Container - CPU usage for hoge-gateway 解決方法 これを解決する手段としてgRPCのclientLoadbalancingを使う方法がありますが、clientに依存する方法はあまりスマート
概要 gRPCサーバのヘルスチェック方法として HTTPサーバを別途立ち上げてHTTPでチェック tcpでポートがopenしたかチェック といった方法がありますが、前者はgRPCサーバなのにHTTPサーバを用意しないといけなかったり、後者はtcpのopenは実際にServe開始したタイミングではないといった課題があります。 そこでKubernetesでは3番目の手段として何かしらのヘルスチェックのgRPCをコマンドラインから呼んでチェックする方法を推奨しています。 ref: Health checking gRPC servers on Kubernetes - Kubernetes 環境 go 1.13.5 grpc-go 1.27.1 Kubernetes v1.15.5 GRPC Health Checking Protocol 3番目の手段ですが、実はgRPCの方でヘルスチェック用
※この投稿は米国時間 2020 年 11 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。 gRPC は Cloud Native Computing Foundation がホストする高性能なオープンソース RPC フレームワークです。GKE のお客様には、多くの場合マイクロサービスの作成に好んで使用されています。gRPC で構築したサービスでは、クライアントとサーバー側の実装言語を問わない効率的な相互通信が可能なためです。 ただし、Kubernetes はネイティブでは gRPC のヘルスチェックをサポートしないため、grpc-health-probe という名前のオープンソース プロジェクトを開発、リリースいたしました。gRPC サーバーのヘルスチェックを行うコマンドライン ツールであるこのプロジェクトは、これまで 180 万回ダウンロードされています
なにこれ? 昔どこかに書いた記事が吹っ飛んで悲しかったので、こちらに復帰。 Goを使ってgRPCのServer,Clientを実装する記事となります。 gRPC? gRPCは、Googleによって開発されたRPCフレームワークです。 HTTP/2を使用した通信部分のライブラリ(ProtocolBuffersでシリアライズ)とProtocolBuffers(標準)としたテンプレートコードの生成がセットで提供されています。 ざっくりと言っちゃうと、HTTP/2を使った手続き部分がばっくり提供されていて Server,ClientのコードはProtocみたいなエコシステムでgenerate できる、という省エネでHTTP/2に乗れる仕組みです。わーい。 HTTP/2のstreamもサポートしています。 gRPCのサポートするRPC方式は以下の通り。 Unary RPC (1リクエスト1レスポンス
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言語の公式サポートライブラリ、プロトコルバッファ(構造体みたいなもの)を定義することにより言語を問わずにデータ通信が可能、ヘルスチェック、ロードバランシングなどをサポート。 一言で言うと、簡単にアプリケーション間のデー
こんにちは、Wantedly の Infrastructure Team で Engineer をしている南(@south37)です。 今日は、WANTEDLY TECH BOOK 6 から「gRPC Internal」という章を抜粋して Blog にします。 「WANTEDLY TECH BOOK 1-7を一挙大公開」でも書いた通り、Wantedly では WANTEDLY TECH BOOK のうち最新版を除いた電子版を無料で配布する事にしました。Wantedly Engineer Blogでも過去記事の内容を順次公開予定であり、この Blog もその一環となっています。 Wantedly における Go 導入にまつわる技術背景 | Wantedly Engineer Blog (本記事は Go Conference 2019 Autumn にて無料配布した冊子『WANTEDLY TE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く