KEELチームの相原です。
前回のエントリは「LLMを利用したPlatform Engineering」でした。
www.lifull.blog
今回は、小さい経路最適化ミドルウェアを実装してAZ間通信を削減した話を書きたいと思います。
背景
我々KEELチームはKubernetsベースの内製PaaSであるKEELを開発しており、LIFULLのほとんどのサービスがこのKEEL上で動いています。
www.lifull.blog
そして、KEELは巨大なマルチテナントのKubernetesクラスタとしてAWSの複数のAvailability Zone(以下AZ)に展開されていて、多くのmicroservicesが互いに通信しあっています。
そのためAZ間通信はプラットフォームとして重要な関心事の一つです。
レイテンシやAWSのAZ間通信に対する課金を最小限に抑えるため、なるべくAZ間通信を減らしたいという要求があります。
我々のプラットフォームでは現在LLMのサポートを強めており、それに伴い扱うペイロードのサイズも増加傾向にあることからも対応の優先度が上がってきています。
www.lifull.blog
実際にKubernetesのTopology Aware Routingをプラットフォーム側で配布してデフォルトで有効にしたり、IstioのLocality Load Balancing をクラスタ全体で有効にして、クラスタ内の通信の経路最適化に努めてきました。
※Istioが有効になっているPodではTopology Aware Routingは機能しないため、全てのPodにIstioを導入できていない場合はクラスタ全体として両方を有効にする必要があります
一方で、KEELはステートレスなクラスタとして永続性が必要とされるデータストアは基本的にクラスタ外に依存しており、未だ最適化できていない経路も存在しています。
そこでその残されたAZ間通信も削減すべく、小さい経路最適化ミドルウェアを実装する判断に至りました。
- 背景
- 実装
- シンプルなConnection Pool
- 余談: Connection Storm
- Topology Aware Routing
- 注意点
- 最後に
続きを読む