Linkerdを用いたAWSでのスループット向上の事例を読んで学ぶ

f:id:lirlia:20210520233417p:plain

はじめに

世の中にはすごいエンジニアや、よりよい物を作ろうと工夫しているエンジニアがたくさんいます。しかもその工夫や苦労をネットに公開してくれていることさえあります。

本になっているわけではないので体系的に学ぶことはできないのですが、そこで考えた工夫やエッセンス、調査内容は必ず誰かの糧になると思います。この記事では私が「読む価値がある！」と思った記事を引用しながら、自分の考えを追加して理解を深めていこうというものです。

素晴らしい記事をありがとうございます！

Entrainという世界的なスポーツベッディングにおけるAWSでのkubernetes利用時の課題です。ユーザはリアルタイムのイベントに対して賭けを行い、イベントの結果に応じて配当がきまるのでUXはレイテンシーに直結します。

AWSのスポットインスタンスとKubernetesを利用してマイクロサービスを運用しているが、マイクロサービス間でのgRPCのロードバランシングに以下の課題があった

(予想) インスタンス間のEast-West通信が多く発生し大きいインスタンスタイプを用意する必要があった(本文には書いてないがおそらくこういう意味だと思われる)
k8sのServiceでのロードバランシングは単純なラウンドロビンである振り分け先の状態を気にしないため、大量のトラフィックを捌くことに向いておらずノードをスケールアウトをしてもリクエストを想定以下しか捌けなかった
AZ跨ぎのk8sクラスタではAZ間通信によるレイテンシーやコストが問題になった(AWSではAZ跨ぎの通信に課金がされる、ロケーションが異なるのでレイテンシーが発生する)

Linkerdを導入した(OSSのServiceMesh)
LinkerdにはgRPC対応の負荷分散機能があり、リッチな負荷分散ができた
k8sのServiceによるLBはラウンドロビンを使っているがLinkerdはExponentially weighted moving average(指数加重移動平均) Beyond Round Robin: Load Balancing for Latency | Linkerdと呼ばれるレイテンシーベースでの分散を行ってくれるので問題になっていたAZ間通信を抑えることができた
Istioも検討したが、Istioを管理するだけでチームが必要になりそうだった
その点、Linkerdは簡単だったしCRDも少なかった

AZ跨ぎのレイテンシーをServiceMesh内のバランシングの仕組みで解決するナレッジを得た
ServiceMesh=Istioであったが、やりたいことに応じて選択の必要性を改めて感じた
Linkerdは簡単という認識になった
Exponentially weighted moving average(指数加重移動平均)はLinkerdではPeak-EWMA(ぴーくゆま)と呼ばれる機能、kube-proxyをバイパスしてPodから直接Serviceに通信できる。
- ロジックとして振り分け先へのRTTの移動平均を持ち、最小となる相手に分散を行うので、ラウンドロビンやリースとコネクションよりもパーセンタイルごとのレイテンシーが低くなる傾向にある。