こんにちは、freee SRE Platform Teamのmatsumoto(frauniki)です。
普段はKubernetes周りのプラットフォーム周りをメインに運用や改善を行っています。 freee 基盤チーム Advent Calendar 2023 の14日目を担当させてもらいます。
今回はfreeeがサービス提供に使用してるプラットフォーム周りの話と、最近調査と検証を行ったAWS Gravitonのお話をしようと思います。
freeeのPlatformについて
まずはfreeeのプラットフォーム周りの仕組みについて簡単に説明しようと思います。
現在freeeで提供しているサービスの殆どはAWS EKSを使用したKubernetes上で稼働しています。 freeeではKubernetesの基本的なテナント戦略にシングルテナントマルチクラスターを採用しており、一部の例外もありますが、基本的には各サービスごとのKubernetesのクラスターが分離されています。 Kubernetesクラスターの数としてはおおよそ100 Cluster程が稼働しています。
それぞれのKubernetesクラスターはAWSが提供するAmazon EKSのSelf-managed Nodeを使用する形で構築されています。 Self-managed Nodeということなので、基本的にはEKSコントロールプレーンとEC2インスタンスのセットでKubernetesクラスターが構成されていますが、freeeのサービス規模の拡大とともにEC2インスタンスの数も右肩上がりで増加しており、インフラコストの中でも大きな割合を占めているという現状があります。
そこで、これらコスト削減に対する1つの対応策として、AWS Gravitonの調査と検証を行いました。
AWS Graviton
AWS GravitonというのはAWSが独自開発しているARMアーキテクチャベースのクラウド向けプロセッサー（CPU）のことです。
ご存じの方も多いかと思いますが、最初にCPUに関して簡単におさらいします。
x86_64
現在、一般向けPCなどのコンシューマー用途やサーバといったエンタープライズ向けの用途で広く採用されているのが、x86アーキテクチャを64bitに拡張したx86_64/amd64と呼ばれる命令セットを使用しているCPUです。
主にIntel/AMDが開発、設計、製造を行っています。
arm64
それに対して、現代のスマートフォンといったモバイル端末やIoT機器で広く採用されているのが、ARMベースの命令セットを使用しているCPUです。 ARMアーキテクチャの中でもいくつかの種類がありますが、現在広く普及しているのは64bit命令セットをサポートしているarm64(arm/v8)になると思います。
ARMアーキテクチャのCPUはARM社のライセンスを使用する形で、様々な企業が開発、製造を行っています。 有名所でいうとQualcomm製のプロセッサーや最近のMac/iPhoneにも搭載されているApple Siliconなどです。
ここで改めて AWS Graviton
AWS GravitonはARMアーキテクチャでAWSが独自開発しているプロセッサーで、ARMアーキテクチャのワットパフォーマンスの良さを活かした、パフォーマンスと省電力性を兼ね揃えたCPUです。 簡単にメリット/デメリットをまとめると以下のような感じです。
メリット
- ARMアーキテクチャ譲りの電力効率の良さ
- CPU自社開発によるコスト圧縮とそれに伴うコストパフォーマンスの良さ(予想)
- これは直接聞いたわけではないので真実はわからないですが、クラウド事業者としてもIntelやAMDのプロセッサーを購入して使用するのと比較すると、多少は調達コストが下がるのではないかと筆者は予想してます
デメリット
- 現状、クラウド/サーバ用途で広く普及しているx86_64とは一切互換性がない
- x86_64の方が性能は良いとされている
- ただこれは諸説あって、結局のところCPUの性能というのは命令セットだけで決まるわけではないのでなんとも言えない
- ソフトウェアやミドルウェアによっては最適化がx86_64ほど進んでおらず、性能面で劣ることはある
性能面は単純比較できないところも多くてなんとも言えないですが、今はARMでも十分パフォーマンスは出ます。 Apple Siliconなんかが良い例です。
ただ、今回の記事では性能面の説明は割愛します。というのも現状freeeでは幅広い世代のインスタンスタイプが使用されており、比較対象となるインスタンスタイプが多すぎるのと、Gravitonプロセッサーのベンチマーク等は他の記事で紹介されていると思うため、そちらを参照していただければと思います。 私個人としてはGravitonプロセッサー自体、通常用途のバックエンドアプリケーションを実行するだけであれば十分なパフォーマンスを提供してくれていると思います。
AWS Graviton にすると何が嬉しいのか
これは単純にEC2のコストが（めちゃくちゃ）下がる（はず）。コレに尽きます。
freeeの SRE Cloud Governance Team の試算では、freeeで使用されているEC2インスタンスをすべてGravitonインスタンスに移行できた場合、EC2インスタンスのコストを15%程度削減ができる可能性があるということです。 15%と言われるとそうでもないように見えますが、EC2インスタンスの課金コスト全体の15%を金額の絶対値でみるとなかなかの金額になります。
あくまでこの計算は概算であるのと、すべてのインスタンスが移行できた場合であるため、実際に削減できるコストもう少し少なくなると思いますが、それでもなかなかなの金額です。それを12ヶ月で考えると尚更です。
あとは現行のGravitonプロセッサーが比較的新しい世代のプロセッサーということもあり、旧世代のインスタンスタイプを使用している場合と比較しても性能を維持または向上させながら、コスト削減ができるという点も大きいです。
実はこの記事を執筆している数週間前に最新のGraviton4プロセッサーが発表されたばかりだったりします。 Graviton4ではarm/v9アーキテクチャのARM Neoverse V2ベースになるようですね。
Join the preview for new memory-optimized, AWS Graviton4-powered Amazon EC2 instances (R8g)
前世代から性能と省電力性がさらに向上しているということで期待です。
少し脱線してしまいましたが、このような背景もあり現状freeeのEKS Clusterで大量に使用されているEC2インスタンスをGravitonインスタンスに移行できれば、かなりのコストインパクトがあるのではないかと思っています。
AWS Graviton移行までの道筋
Container Imageのarm64対応
対応しないといけないことはいくつもありますが、サービスを開発しているエンジニアの方に一番やっていただかないといけないのは、Container Imageのarm64対応です。
EKSでGravitonインスタンスを使用する場合、当然ですが使用するContainer Imageもarm64用のものを準備する必要があります。 現状freeeで開発されているサービスとそのContainer Imageはほぼすべてがx86_64での実行しか考慮されていません。
今回Gravitonを検証する過程で、GitHub Actions上でマルチアーキテクチャContainer Imageを簡単にbuildできるActionを用意しました。 中身としては既存の setup-buildx-action や docker/build-push-action、aquasecurity/trivy-action を組み合わせたものです。 元々はfreee内で独自開発されていた別のActionを再開発した形にはなりますが、AWS Graviton導入への第一歩だと思っています。
サービスの拡大に伴いサービスの数やContainer Imageの数も増加しており、一度にすべてのContainer Imageでarm64対応を行うのは難しいため、まずは環境を整え徐々に移行が進めれていければ良いと考えています。
具体的な移行プランについて
実際に移行する場合のプランも少し考えてみます。
Kubernetesは nodeAffinity や Taint/Tolerations といった仕組みを使用することにより、アプリケーションを特定のNodeにスケジューリングさせるといった操作が比較的容易にできます。
この仕組みを活用し、予め1つのClusterにx86_64とARM系のNodeを追加しておき、arm64への対応が完了したアプリケーションからARM系Nodeでのスケジューリングも許可するようにするといったことが可能です。
移行コストや万が一のリスクも考慮し、いきなりすべてをGravitonインスタンスに移行するのではなく、段階的にアプリケーションの対応をおこないつつ、徐々にGravitonインスタンスの比率を上げていくというのが一番良い方法なのかなと考えています。
まとめ
Gravitonインスタンスへの移行はやるとしてもかなりの時間とコストが掛かることが予想されますが、仮にその移行が行えた場合のコストインパクトは非常に大きいです。 SREチームでも前述のContainer Imageのarm64対応含め、できるところから少しずつ準備をできればと思っています。
また、freeeのSRE Platform Teamでは一緒に働く仲間を募集しています。 freeeのプラットフォームにはまだまだ改善が必要な部分がたくさんあります。直近では、広範囲のEKSマルチクラスター環境でIstioによるサービスメッシュ導入などを進めていこうとしています。 これらの分野にご興味のある方は是非ご応募ください！
次回のAdvent Calendar担当はTomoaki Nakagawaさんになります。 ぜひご覧ください！
ではここまでお付き合いいただき、ありがとうございました！
