アソビュー！でのEKSクラスターの今までとこれから

こんにちは、アソビュー！SREチームのkirimaruです。コロナも少し落ち着き、皆さんもGWは大いに満喫していたのではないでしょうか。残念ながら僕は本を読んで引きこもっていましたが......。

以前「アソビュー！がECSではなくEKSを選んだ理由」という内容でランサーズさんとのイベントでお話させていただきました。

今回はこの時から約2年、アソビュー！がEKSとどう向き合ってきたのか、どう向き合っていくのかを採用している技術とともにご紹介できればと思います。

Intro

前述のイベントでは「大量のAWSアカウントとECSクラスターの管理が辛いから、整理してEKSに統合していくぞ！」とお話させていただきました。このイベントは2020年ですが、2019年に試験的にEKSを導入し、2020年に本格移行の意思決定を行っています。SREチームはまだまだ人数が少なく他の業務と平行しながらではあるものの、既存のAWSリソースの移行とECSからEKSへのアプリケーションの移行、AWSアカウントの閉鎖を現在も行っています。

ではこれが実際どうだったのかというと、現在約7割程のアプリケーションがEKSで起動するまでに至っています。また、AWSアカウントやECSクラスターも整理が順調に進んでいます。

EKSクラスターは繁忙期にはPod数は200を超え、ノードはEC2のスポットインスタンスが100を超える大きなクラスターに成長しました。EKSクラスターはマルチテナント・シングルクラスターで進めており、クラスター内にはワーカータイプやバッチ、プロキシサーバーやAPIゲートウェイ、そしてもちろんWebアプリケーションなど様々なタイプのアプリケーションが起動しています。

この過程で、最初期に構築した試験的なクラスターでは運用に耐えられなくなり、2021年の初頭に大きなクラスターの再構築を経て、現在も継続的に改善を行っています。

再構築の大きな原因はPrivate IPの枯渇でした。今では広く知られている気がしますし直近IPv6への対応*1もありましたが、当時はaws-nodeの設定変更だけでは追いつかず、かといって構築済みのEKSクラスターに新しいサブネットも割り当てることができないため、大きく構成を変える結果になりました。

ここからはいくつかのトピックに分けて、再構築時の分岐点に焦点を当てつつ、今までとこれからをご紹介します。

Infrastructure as Code

2021年のクラスターの再構築に当たり、最も変化の大きかった部分がここになると思います。

それまではEKSクラスターもそれが利用するVPC等もTerraformで構築していました。特にEKSクラスターの構築にはTerraformのモジュール*2を利用していましたが、再構築に当たり下記の理由でeksctlを利用することにしました。

Kubernetesバージョンアップの容易性
公式ツールなので、今後の改善や知見の集約が高い確度で見込める
必要な機能がTerraform moduleで実装が遅い場合がある

eksctl.io

ただし、EKSクラスターとそれ以外のVPC等のAWSリソースのライフサイクルが異なること、バージョンアップの容易性の担保やクラスターの作り直しも加味して、EKSクラスターはeksctlで管理し、VPCなどそれ以外のリソースをTerraformで管理運用していく形に決めました。

少し話が逸れますがアソビュー！は2022年7月から11期に入る、ベンチャー企業の中では歴史を持っている会社です。この歴史の中でインフラが混沌としていったのは先のイベントでも触れさせていただきました。新しい技術もその有用性があれば積極的に導入をしていっているアソビュー！ですが、混沌期の急速なサービスの成長と拡大にIaCが完全には追いついていけてなく、一部分のみの適用になっていました。そこで、今後のIaCの利用の拡大を推進するためにも、eksctlの導入と同時にTerraformとeksctlを並行して使えるような形でIaC用のリポジトリとCICDの再設計を行いました。

これらの対応により直近あったEKSのバージョンアップ対応もスムーズに行え、IaCの利用も順調に加速していっています。積み重ねが多いので100%すべてできたぞ！とはまだいきませんが、この調子で進めばそう遠い未来でもないと感じています。

CICD

IaCの項目も一部含まれますが、CICDも2021年のクラスターの再構築で手を入れました。

これまでのCICDはCircleCIでビルドからデプロイまでを一気通貫で行っていました。所謂CIOpsと呼ばれるオペレーションです。この際のKubernetesのマニフェストの管理はアプリケーションとミドルウェアで分かれており、アプリケーションはアプリケーションリポジトリ内、ミドルウェアはミドルウェアを一括でまとめたリポジトリで行っていました。これにより見に行く箇所が多く、マニフェストの変更にトリガーされてビルドとデプロイが走るなど、管理運用に課題感を持っていました。前述のIaCの見直しに合わせて、この課題の解決のためKubernetesのマニフェストの管理も整理していくことにしました。

そこで目を付けたのが Argo CD です。

argoproj.github.io

CIOpsにはシンプルで理解しやすく容易に構築できるメリットがあります。しかし、カナリアリリースなどの高度なデプロイ手法の導入や、CIツールが過剰に権限を持つことによるセキュリティリスク、冪等性担保の難しさ等を鑑み、Kubernetesとの相性も良いGitOpsの導入を考えました。また、その中から検討当時UIを持っていることでの取っ掛かりやすさや、周辺エコシステムによる拡張性の高さから、アソビュー！ではArgo CDを導入することにしました。

導入当初はミドルウェア用のリポジトリを改修してミニマムに利用を開始していましたが、現在はアプリケーションにも適用して段々とその利用を拡大させています。同時に、Kustomizeを導入することによりマニフェスト管理自体も効率化させています。

今後はよりアプリケーションでのArgo CDの利用を拡大していくとともに、元々予定していた高度なデプロイ手法の導入や、Kustomizeのプラグインを利用した効率的なマニフェスト管理の導入を予定しています。

また、CI部分ではコンテナイメージのビルドに一部でCNBでのビルドも導入し始めました。こちらも今後利用の拡大を行っていく予定です。

ミドルウェア

最後に導入しているミドルウェアについて、一部ご紹介させてください。

Argo Workflows

argoproj.github.io

当初EKSクラスター上で起動するバッチはCronJobで定義していましたが、より複雑な条件を付けて実行する必要のある案件やPipelineの構築が必要になってきました。ワークフローエンジンはいくつか選択肢がありますが、アソビュー！ではArgo Workflowsを導入しました。

ざっくりとArgo Workflowsでできることを挙げると下記のようになります。

Kubernetes上にworkflow管理のためのUIとCRDを展開
workflowの各ステップそれぞれをKubernetesのmanifestとして定義、podで実行
マルチステップ、DAGなど複雑な依存を定義、UI上での操作、確認
EKS on Fargateでの実行

Argoのツール群のひとつであるArgo CDを導入していることもありますが、Argo Workflowsを選んだ理由はArgo Workflowsの方が開発者と管理者にとって学習・運用コストが低いと考えたことにあります。Kubernetesクラスター上で動かすだけであれば他にも選択肢はありますが、EKSを使っていく意思決定をしているため、アプリケーションと似たように設定できることや処理の全体感を確認できるUIを持っていることが導入の決め手になりました。管理しているcronの一覧が見られるだけでもワークフローエンジンは導入する価値あります。非常に便利です。

構成は下記のようになっています。

失敗したときの通知をDefault Workflow*3の機能を使ってSlack通知を行っている部分が工夫ポイントです。

今後利用を拡大させていく予定ですが、すでに既存の一部のバッチをArgo Workflowsに移行しているだけでなく、機械学習用のデータPipelineの構築も行っています。EKS on Fargateはログの扱いがやや難しいので、Firelensのこれからのアップデートにも期待したいところです。

AWS Load Balancer Controller

定番ではありますが、AWS Load Balancer Controllerも利用しています。

github.com

アソビュー！ではそれぞれのサービスと環境を分離させるため、それぞれに対して個別にNamespaceを区切って1つのクラスター内で同居させる構成をとっています。v2になってからNamespaceを跨いだ定義ができるようになったことで、非常に管理がしやすくなりました。以前は中間にNginx Ingress Controllerを挟んだ構成になっていたため特に痛感しています。

よく一緒に使われているExternalDNSですが、アソビュー！では利用していません。これはEKSクラスターとDNSのライフサイクルの差が大きいです。Load Balancerも含め、ライフサイクルを意識する機会がEKSを運用する中で何度もでてくると感じています。AWSの設計思想とKubernetesの設計思想の差異の中でどうそれぞれを管理運用していくか、面白い部分でもありつつ非常に難しい部分です。