前提条件
本記事では以下のバージョンを前提としています。
- EKS(EC2) 1.28
- Cluster Autoscaler 1.28.2
- Horizontal Pod Autoscaler
- Argo CD
概要
サービスの成長に伴い、AWSのコストが増加するのは避けられないことですが、想定していた予算を超える状況になっていたため、インフラチームでコスト削減に注力することにしました。
最近、いくつかの効果的なコスト削減を実現できたのですが、今回は「DataTransfer-Regional-Bytes」の削減について、原因の特定から改善、効果測定までの事例をご紹介します。
次回記事では「NatGateway-Bytes」の削減について紹介予定です。
AWS Cost Explorer で削減できそうな項目を特定する
AWS Cost Explorer を活用し、細かい改善点がいくつか見つかりましたが特に大きい値となっていたのが、「EC2 その他」で、その中でも特に以下2つが高額であることが判明しました。
- DataTransfer-Regional-Bytes
- 同一リージョン内の別ゾーンとの通信に対して発生するコスト
- $0.01/1GB
- NatGateway-Bytes
- NAT Gateway を介した通信に対して発生するコスト
- $0.062/1GB
DataTransfer-Regional-Bytes の発生箇所を特定する
まず、DataTransfer-Regional-Bytes がどの通信で膨らんでいるのかを特定します。
候補はいくつかありましたが、弊社では Datadog を活用しているので、Datadog の機能のネットワークパフォーマンスモニタリングを使い調査することにしました。
ネットワークパフォーマンスモニタリングを有効化して、Auto-rouped traffic フィルターをつけて1時間の通信量を降順に並べ替えたところ以下の結果となりました。
kube_app_name:argocd-application-controller › kube_app_name:argocd-redis-ha-haproxy: 31.06%
kube_app_name:argocd-redis-ha-haproxy › short_image:redis: 30.88%
kube_app_name:fluent-bit › service:aws.kinesis: 11.18%
kube_app_name:datadog › domain:intake.profile.datadoghq.com: 7.52%
kube_app_name:datadog › domain:trace.agent.datadoghq.com: 2.52%
どうやら Argo CD と Argo CD 内部で使われている Redis 同士の通信が全体の6割ほどを占めているようです。
当初はサービス同士の通信などが多いと予想していたため、Argo CD が大部分を占めていたのは意外でした。
Argo CD の通信が AZ を跨いでいるのかどうか調査する
Argo CD の通信がどれくらい AZ を跨いでいるのかどうか、ネットワークパフォーマンスモニタリング機能を使い調査していきます。
調査方法は以下の通りです。
- 検索条件を
(client_kube_app_name:調査対象の名前 OR server_kube_app_name:調査対象の名前)のようにすることで対象を絞り込む - View clients as と View servers as を
availability-zoneにすることで結果に AZ を表示させる
argocd-application-controller に絞り込んだ結果
argocd-redis-ha-haproxy に絞り込んだ結果
以上の結果から、どちらも AZ を跨いでいることが分かりました。
通信量も多いことから、DataTransfer-Regional-Bytes が高い主な原因は Argo CD の Redis にあると考えました。
Argo CD の Redis の通信量について類似事例を調査
類似事例に関しては以下の2つを見つけることができました。
- Context for High data transfer between argocd application controllers and redis
-
Document cost considerations
2つ目の Issue に記載されてある通り、Redis に保存されているデータが大きいのが原因なので、それを圧縮することができれば通信量を削減できるのではというヒントを得ることができました。
Argo CD の Redis データの圧縮について調査
Argo CD の Redis データの圧縮は v2.5.0 から実装されていました(2022/10/26リリース)。
実装時のPRは以下です。
chore: support gzip compression for data stored in redis
この時点ではデフォルトで有効ではないため明示的に有効化する必要がありました。
デフォルトで圧縮が有効になったのは以下PRで、2.8.X 以降のバージョンに適用されているようです。
feat: enable gzip compression in Redis by default (#13458)
意図的に Gzip 圧縮を無効化していた件
調査の結果、弊社で利用している v2.11.3 では既に Redis の Gzip がデフォルト有効化されていることが分かりました。
しかし、弊社環境では以下のように Gzip 圧縮の無効化設定をデフォルト値に上書きする実装をしているのが原因で圧縮されないようになっていました。
configs:
params:
redis.compression: "none"
意図的に Gzip 圧縮を無効化していた理由は、Gzip 圧縮を有効にした場合、argocd コマンドの --core オプションが正常に動作しなくなるというバグがあったためです。
下記 Issue にもある通り、redis.compression: "none" とすることで、エラーが回避できるというワークアラウンドが提示されています。
argocd app actions list doesn't work with login --core
因みに現在でも根本解決はされておらず、--core オプションを使う場合は Gzip圧縮を諦めるという選択になりそうです。
また、更に先のバージョン(大体ですが v2.11.2 以降)で --core オプションを利用すると NOAUTH Authentication required. エラーが発生するバグがあります。
arogcd cluster add command reports error
こちらの問題は現在修正中とのことですが、--core オプションを使った時に Gzip圧縮が使えない件は直される見込みがないことと、バグが起きた時にどうしても後回しにされやすい傾向にあるように見えるので、--core オプションを利用した実装はなるべく避けるのが良さそうです。
弊社では kubernetes マニフェストの変更を push した際に、argocd app diff --core で本番環境との差分を取得して表示する CI を実装していましたが、今回 --core オプションで問題が起きたため、現在では --core オプションを利用しない形に改修しています。
Gzip 圧縮有効化による通信量削減効果
Gzip 圧縮有効化前後のデータをそれぞれ2時間取得して比較しました。
圧縮有効化前
application-controller
発生通信量: 21.09GiB
redis-ha-haproxy
発生通信量: 41.74GiB
圧縮有効後
application-controller
発生通信量: 1.92GiB
redis-ha-haproxy
発生通信量: 3.1GiB
通信状況など、同じ条件下での比較ではないので参考程度ですが、Gzip 圧縮の効果が出ていることは明らかです。
AWS コストの削減量に関して
DataTransfer-Regional-Bytes の料金が1日あたり平均$30だったのに対して、Gzip 圧縮有効化後には平均$5にまで削減することができました。
DataTransfer-Regional-Bytes の料金は $0.01/1GB ですので、通信量にすると 平均2500GB ほどの削減となりました。
Argo CD だけで 1日2500GB も通信していたなんて恐ろしい話です。
まとめ
- Argo CD Redis の Gzip圧縮は基本的に有効化して損はない(コスト面・性能面ともに)
- argocd CLI の
--coreオプションは何かとバグが多い(Gzip圧縮有効化状態だと--coreオプションが動作しないなど)ので、可能な限り使用を控える - Datadog のネットワークパフォーマンスモニタリングを活用することで DataTransfer-Regional-Bytes の内訳を簡単に調べられる
Discussion