yuya-takeyama/README.md

## README.md

      
    Raw
  

              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"
            }
          ]


## zu.png

      
    Raw
  

              zu.png