SRE部の坂本です。
ChatworkはほぼすべてのアプリケーションをEKSで動かしています。そのEKSのノードは90%以上をSPOTインスタンスで動かしているので、i系インスタンスで動かしている状態でも、規模(日中で150ノード程度)の割には比較的安価に動かせている状態でした。
しかし円安だったり、通常のWebアプリケーションではそもそもGravitonのほうがパフォーマンスがいいらしい、など、インスタンス単体でのコストダウン + αのメリットを期待して、Gravitonへ移行することとしました。
SPOTインスタンスで稼働しており、かつ、Gravitonのインスタンスの種類が少ない状態では、Graviton移行へのモチベーションがあまり上がりませんでしたが、Gravitonのインスタンスの種類が増え、GravitionのSPOTインスタンスも安定してきた、とのことで、今回の移行に踏み切りました。
移行して2ヶ月程度経っていますが、大きな問題はなく、前年比でおおよそ$2000/month程度のコストダウンとなりました。
移行準備
各イメージのARMアーキテクチャへの対応
Gravitonで動くようにするには、EKSで動いている各imageをARMアーキテクチャに対応させる必要があります。 もともと対応されているものもありましたが、対応していないものは各チームにお願いしたり、手一杯とのことであれば、できるだけ一斉に切り替えを行いたかったため、SREのほうで巻き取って対応しました。
またCIもmulti archに対応する必要があったため、それらを修正していきました。
docker buildxがとても便利なので、それほど対応には時間はかかりませんでした。
SREが管理するアプリケーションに関しては、ほとんどがすでに対応されていたため、特に問題はありませんでした。 ↓はやや古いブログで、もう使っていないものや、新しく使っているものもありますが、参考までにリンクを貼っておきます。
移行方法
シビアなパフォーマンスを求められるアプリケーション
Chatworkではメッセージ周りなどで比較的パフォーマンス要件の高いアプリケーションがあります。 これらは数は少ないですが、オンデマンドインスタンスで稼働しています。
これらをビッグバン的に切り替えるのはちょっと勇気がなかったので、EKSのクラスタ移行をしつつ、切り替えました。
具体的には、i系インスタンスのみの旧クラスタからg系インスタンスのみで構成した新クラスタで、新旧並行稼働し、新クラスタ側で問題ないことを確認してから、100%の切り替えを行いました。
事前にパフォーマンス試験は行っているものの、本番データでの負荷試験ができる環境がないため、このようにして切り替えを行いました。
Chatworkのクラスタアップグレードは、Blue/Greenで行っており、今回のように構成変更を行う際、1つのクラスタの中ではなく別環境で行うことができます。
そこまでパフォーマンスは求められていないアプリケーション
1つめの切り替えとそこまでパフォーマンスに差があるか、と言われるとないのですが、端的に言うとSPOTインスタンスで稼働しているアプリケーションのPodです。 Podのほとんどはこちらのパターンでの切り替えです。
こちらに関しては、切り替えというより、割合を変えた、が正しいです。
具体的には、Cluster AutoscalerのPriorityにおいて、Gravitonインスタンスを優先させるようにすることで、リリースなど大幅にPodが入れ替わるタイミングで優先的にPodが入れ替わるようにしました(今回のために採用したわけではなくもともと利用していました)。
Priorityに関しては下記が詳しいです。
i系インスタンスよりg系インスタンスのノードグループの優先度を高くすることで、g系インスタンスへの入れ替えを行いました。 Managed Node Groupの入れ替えなどで一気に入れ替えを行ってもよかったのですが、Pod数が多く、drainはなかなか時間がかかるためこの方法を採用しました。
移行してみて
上記の準備から入れ替えを行って、2ヶ月ほど経過して、特に問題なく動いています。
おかげさまでライセンス数も順調に前年比で増えていますが、$2000/month程度コストダウンできました。
コストダウンの要因としては下記を考えています
- Gravitonインスタンスによりインスタンス単価が安くなった
- SPOTでもインスタンス単価がより安いです
- パフォーマンスが上がり、ノードの台数が減った
*7gで揃えたおかげか、各ノードのCPU使用率のバラツキがなくなり、結果的に全体として安定し、ノードの台数が減りました- i系のときは、SPOTでは、
*6iと*7iを使用していたので、やや比較しにくいところではあります
- i系のときは、SPOTでは、
下記はインスタンスの台数(インスタンスタイプ別)のグラフですが、Gravitonへの割合を増やした4月上旬以降、ノードの台数が減っているのがわかると思います。 3月はあるライブラリに問題があって、ノードの台数が増えてしまっているので、あまり参考にならないのですが、それ以前のノード台数と比較しても台数が減っているのが確認できると思います。
まとめ
少し前であれば、ARMアーキテクチャへの対応だけでもなかなか大変だったかもしれませんが、ARMアーキテクチャのCPUの広がりによって、アプリケーションとして対応することも比較的容易になりました。
変えるだけでパフォーマンスアップやコストダウンができるので、ぜひぜひGravitonへの移行を検討してみてください。
