yuya-takeyama/README.md

モチベーション

とりあえずは gRPC のロードバランシングさえできればそれでよし
- 現状 gRPC は新規サービス含めトラフィックの少ないサービスでしか使われてない
- とはいえそれらのサービスの成長だったり、トラフィックの大きいサービスで使うときに当然困ることになるので
Circuit Breaker 的な仕組みが社内で運用できていないので、その辺にも使っていけたらと思ってる (そのうち検証する)
- 現状は @ujihisa さんが作った Dark Launch で手動で落とすとかしている
- そもそも現状は partial outage 可能なマイクロサービス化された部分が限定的だし、特に問題も起きていないのでそれがないことで日々障害が起きている！なんてこともない
  - Production readiness checklist 的には Circuit Breaker 入れるか、少なともなんかあったら切り離せるように、ということにはしてある https://quipper.hatenablog.com/entry/2019/06/07/080000
ゆくゆくは AWS App Mesh なり Istio なりでサービスメッシュしたいと思っているが、いきなりそこに行くのはリスクが大きいのでまずは Envoy 単体に慣れたい
- 現状は別にサービスメッシュないと辛い、みたいな感じではない
  - Tracing は欲しいケースがちらほら出てきてはいるものの (それも別にサービスメッシュなしでも一部できているし)
- アプリケーションの Pod に手動で Envoy 差し込んでいくのが辛くなってきたらその辺の管理の効率化のために考えればいいかな、ぐらい

構成

基本的にこれの Example 2: Round Robin LB with statically configured Envoy proxy (deployed as sidecar) の通り https://github.com/jtattermusch/grpc-loadbalancing-kubernetes-examples#example-2-round-robin-lb-with-statically-configured-envoy-proxy-deployed-as-sidecar

登場人物

API Gateway (図中 API GW)
- バックエンドに gRPC のマイクロサービスが 4 つほどいる
- そいつらを集約するだけの Rails API
gRPC Services (図中 MS)
- API Gateway の後ろにいるマイクロサービス

変更箇所

リクエスト元の Pod 内に Envoy を入れてそれ経由でアクセスするようにした
Kubernetes の ClusterIP Service から Headless Service に変更
- 当然 ClusterIP では全くロードバランシングされてなかったが、トラフィック的に特に問題起きてなかった
- 接続元の Pod 数に応じて、起動時に確率的にバランスされていた
  - 運が悪いと gRPC 側の単一の Pod に完全に偏ったりもしていたけどそれでも問題にならない程度の規模感

ポンチ絵

その他

メトリクスは Datadog で収集
- Pod に annotation 書くだけで勝手に収集してくれて便利
  - https://docs.datadoghq.com/integrations/envoy/
  - https://docs.datadoghq.com/agent/autodiscovery/

      annotations:
        ad.datadoghq.com/api-gw-envoy.check_names: |
          ["envoy"]
        ad.datadoghq.com/api-gw-envoy.init_configs: |
          [{}]
        ad.datadoghq.com/api-gw-envoy.instances: |
          [
            {
              "stats_url": "http://%%host%%:10000/stats"
            }
          ]