プロダクト基盤を EKS に移行しました

こんにちは。Wantedly Infrastructure Squad 所属の @irotoris です。

Wantedly Visit を始めとする Wantedly のサービスのバックエンドシステムはほぼ全て Kubernetes クラスタの上で動いています。今まで kOps という OSS を使って AWS の EC2 インスタンス上に Kubernetes クラスタを自前で構築運用していましたが、2022年6月に AWS の Kubernetes Managed Service である Amazon Elastic Kubernetes Service (EKS) に移行しました。

この記事では Wantedly と Kubernetes の歴史を振り返るとともに、なぜ EKS に移行したか、移行した結果どうだったかをお伝えします。

Wantedly システム基盤としての Kubernetes の今
なぜ EKS に移行するのか
Wantedly と Kubernetes の歴史
どうやって移行したのか
移行してよかったこと・変わったこと
まとめと今後の展望

Wantedly システム基盤としての Kubernetes の今

最初に Wantedly の Kubernetes クラスタ構成やその活用について簡単に紹介しておきます。

Kubernetes クラスタ構成

Wantedly のサービスはマイクロサービスアーキテクチャで構成されています。すべてのマイクロサービスは、1つの Kubernetes クラスタ上に収納するマルチテナント方式で稼働しています。クラスタは

開発環境である sandbox クラスタ
QA環境である qa クラスタ
本番環境である production クラスタ

の3クラスタが展開されています。

フロントエンドやモバイルアプリから ALB Ingress で HTTP 通信を受け付けます。ALB Ingress で受け付けた通信は、API Gateway である Ambassador によってそれぞれのマイクロサービスにパスルーティングされます。（一部マイクロサービスでは直接 ALB Ingress で通信を受け付けているものも存在します。）マイクロサービス間の通信は gRPC を基本とし、Envoy Proxy を介して通信が行われます。

開発者プラットフォームとしての Kubernetes の活用

Infrastructure Squad では、プロダクト開発チームがオーナーシップを持って開発、テスト、CI/CD、Ops （Monitoring + On-Call）を行えるように、システムインフラをプラットフォーム化し、開発者がプラットフォームを利用・接続するインターフェースとしてツール、ライブラリ、プラクティスを提供する戦略を取っています。

その戦略の1つとして、Kubernetes の操作を Wantedly のマイクロサービス開発のユースケースに合わせて抽象化した kube という CLI を開発し、各マイクロサービス開発者に提供しています。Kubernetes の標準 CLI ツールである kubectl の機能に加え、deploy や reload いった独自の便利機能とサブコマンド、および権限に応じたアクセス制御の仕組みが実装されています。

kube の詳細についてはこちらもぜひ御覧ください。

Kube - The core tool at Wantedly https://speakerdeck.com/potsbo/kube-the-core-tool-at-wantedly
kube - Wantedly Engineering Handbook https://docs.wantedly.dev/fields/dev-tools/kube

より具体的な例として、Kubernetes の設定プラクティスの提供を紹介します。Kubernetes ではアプリケーションのための CPU、メモリといったリソースやスケールのための設定を行うことが可能ですが、一般的にこれらを適切に使いこなすには学習コストがかかります。その解決として、 Wantedly におけるアプリケーションの Kubernetes 設定プラクティスをテンプレート化してコマンドで生成・管理できる機能を kube に組み込んでいます。Infrastructure Squad の日々の SRE 業務から得られた知見や Kubernetes の新機能を元に、その設定テンプレートを継続的にアップデートすることで、すべてのマイクロサービス開発者に対して最新のプラクティスを提供しつつ、各マイクロサービスの開発者自身でも必要な設定を行えるようにしています。

※ Infrastructure Squad の他に、開発者体験の向上に特に注力している DX(Developer Experience) Squad も存在します。

例えば kube generate autoscale コマンドを実行すると、Wantedly のマイクロサービス運用で得た知見を盛り込んだ Deployment、Service、HPA の manifest の雛形が生成されます。さらに生成された manifest に対して kube generate --update を実行すると、最新の設定プラクティスに更新しつつ、開発者が個別で行った設定をマージする機能を備えています。

$ kube generate --help
Generate manifest files

Usage:
  kube generate [flags]
  kube generate [command]

Aliases:
  generate, g

Available Commands:
  autoscale          Generate manifest files for Deployment with Autoscale
  cronjob            Generate manifest files for Cronjob
  grpc               Generate manifest files for gRPC Deployment
  ingress            generate manifest files for Ingress to web pod
  internal-ingress   generate manifest files for Ingress resource for internal only
  namespace          Generate manifest files for Namespace
  rbac-kube-sh-by-ci Generate manifest files for resources to enable `kube sh` from CI
  redis              Generate manifest files for redis statefulset
  sidekiq-exporter   Generate manifest files for sidekiq-exporter
  worker             Generate manifest files for worker deployment

$ kube generate autoscale --clusters sandbox
generated "/Users/shoji/Desktop/work/test/kubernetes/sandbox/deployment-vpa.yaml"
generated "/Users/shoji/Desktop/work/test/kubernetes/sandbox/deployment.yaml"
generated "/Users/shoji/Desktop/work/test/kubernetes/sandbox/hpa.yaml"
generated "/Users/shoji/Desktop/work/test/kubernetes/sandbox/pdb.yaml"
generated "/Users/shoji/Desktop/work/test/kubernetes/sandbox/service.yaml"

なぜ EKS に移行するのか

ここから EKS の話です。

EKS に移行する一番のモチベーションは「Kubernetes クラスタの管理コスト削減」です。

いままで kOps で構築した Kubernetes クラスタでは Control Plane (つまり master node) も自分たちの EC2 上で動作するため、Kubernetes のバックエンドストレージである etcd のような複雑な分散キーバリューストアも自分たちで面倒を見ないといけません。一方 EKS はこの Control Plane 管理を AWS が行ってくれるサービスで、自分たちからは見えないところで管理され、勝手に Control Plane の security update や backup、高可用性構成をとってくれます。これにより、Kubernetes バージョンアップにおける Control Plane の検証作業の容易化を見込んでいました。

また副次的な効果として、AWS の各サービスとの連携強化・簡易化が見込まれました。たとえば Kubernetes の操作ログはいままで自分たちでロギングのコンポーネントをいれて BigQuery に転送していましたが、EKS では設定一つで CloudWatch Logs に格納することができます。

なぜ2022年の今なのか

いくつかモチベーションがある中で過去何回か EKS への移行を検討しましたが、移行に際して技術的なブロックがありました。また、kOps での Kubernetes 自前構築運用も日々工夫を凝らして運用していたため、この技術的なブロックを無理やり突破してまで移行するメリットが見いだせていませんでした。

EKS のリリースから時が経ち、AWS のアップデートによってその技術的な問題が低減されたされたため、満を持して移行プロジェクトを開始することにしました。

また過去 2018〜2021年に EKS に移行された他社さんの事例を調べていると、Wantedly で移行のブロックになっていた問題の他にも現在までで EKS はかなりの機能が追加(※)され、使いやすくなっていると感じます。結果論にはなりますが、EKS の検証・設計した身としては今やって良かったなと思っています。

※ Managed Node Group の taint や Launch Template のサポートされたのは特に大きかったです。

Wantedly と Kubernetes の歴史

Wantedly が最初に Kubernetes を検証し始めてから EKS に移行するまでの主な出来事と、EKS 移行における検討事項やブロッカーの解消を時系列で並べました。

2011 ~ 2016 Heroku から始まり、AWS EC2 で CoreOS + Docker を動かしていた時代
2015/11 マイクロサービスアーキテクチャの検討が始まる
- モノリスな Rails アプリによる開発速度や耐障害性、技術選定の幅を広げたい、などといった課題感から、マイクロサービスアーキテクチャへの移行検証が始まる
- このマイクロサービス基盤として Kubernetes を検証し始めた
2016/11 Kubernetes 本番導入
- Kubernetes v1.4, クラスタ構築ツールとしては kOps を利用
- 当時 AWS を作るツールとして公式の bootstrap script, kOps, kubeadm があったが、kOps がユースケースにあってそうということで採用
- 当時 Kubernetes のマネージドサービスは AWS にはなかった
- GKE はすでに GA (2015/08) だったが、インフラはすでに AWS を利用していたため候補から外れている
2018/07 EKS GA
- Preview が出たのは 2017/11、東京リージョンはまだなかったため検討せず
2019/02 EKS 東京リージョン Release
- Wantedly では authn, authz に Webhook token Authenticator plugin 利用した GitHub Account 認証を実装しており、EKS だと利用できなくなるため移行は検討はされていなかった
2020/02 etcd2 to etcd3 対応のためにクラスタの引っ越しによる Kubernetes upgrade を実施
- Kubernetes の裏側のデータストアである etcd の upgrade で破壊的変更があり in-place upgrade が難しく、新規 cluser にバックアップからリストアして切り替える upgrade 方法を整備した
- ここでクラスタの引っ越しの知見が得られ、後の EKS 移行でも同様の手順を取ることになった
2021/01 EKS への移行を検討し始める
- AWS EKS specialist の方とディスカッションを実施
- クラスタの管理のコストの低下、信頼性の向上あたりが移行のモチベーション
2021/02 EKS OIDC support
- OIDC を利用した既存 GitHub Account による auth, authz が採用できるため、クリティカルな移行のブロッカーがなくなった
2021/09 EKS 移行プロジェクト開始
- 検証 → クラスタ設計 → 運用設計 → 移行設計
2021/12 sandbox クラスタの EKS 移行失敗
- 移行した sandbox EKS で API Gateway のパスルーティングが動作しなくなるという問題が発生し、旧クラスタに切り戻し
2022/01 Kubernetes の version up のために EKS 移行プロジェクトを pending
- EKS における Kubernetes version の EOL が 2021/2 に迫っており、version up を優先
2022/02 - 03Kubernetes の version up (1.18->1.20)
2022/06 EKS 移行プロジェクト再開
- 切り戻しの原因となった問題を修正
2022/06 末に移行の完了

どうやって移行したのか

旧クラスタの Kubernetes リソースをバックアップから新クラスタにリストアする、お引越し方式で行いました。新クラスタと旧クラスタの切り替えは DNS レベルで行いました。おおよそこんな感じです。

kOps クラスタの横に EKS クラスタを構築する
- Cluster Addon をインストールする
kOps クラスタのバックアップから EKS クラスタにリストアする
- バックアップ・リストアツールとして velero を使用
- CronJob など、新旧クラスタで重複して起動して困るものは旧クラスタで停止後、新クラスタにリストア
サービスの DNS を旧クラスタの Ingress から新クラスタのものに切り替える
- DNS の設定は Terraform で一括変更

切り戻しは DNS 設定を旧クラスタに向けるように戻す方式で行いました。

クラスタのアップグレード戦略やお引っ越し方式については、過去に弊社メンバーが登壇した資料があるのでよかったらぜひ御覧ください。

Kubernetes Cluster Migration - https://speakerdeck.com/bgpat/kubernetes-cluster-migration

移行してよかったこと・変わったこと

もともと Control Plane の管理コスト削減を目指した移行でしたが、移行後しばらくして改めてよかったこと・変わったことをお伝えします。

クラスタ構築スクリプト -> Terraform

いままで kOps によるクラスタ構築をしていましたが、それをラップした wkops というシェルスクリプトを自前で書いていました。これはローカルマシンから実行するクラスタ管理スクリプトになっており、手作業と手順による運用でした。

EKS 移行ではクラスタ管理を Terraform で行うように変更しました。Terraform による Infrastructure as Code と CI/CD パイプラインはすでに GitHub Actions 構築されたものがあり、EKS もその管理に寄せた形になります。この変更によりクラスタ管理における手作業がなくなり、またスクリプトのメンテもまるっとなくなりました。心なしかクラスタの設定変更に対する心理的ハードルも減ったように思います。

OSS のコードを追う -> AWS に聞く

クラスタ管理ツールである kOps は OSS なので、クラスタ構築や変更で詰まったら細かい挙動や設定はコードを読んだり、ログを追っていました。しかし EKS ではそういった操作や管理コンポーネントは AWS 側で隠蔽されているため、これからはドキュメント調査や AWS Support に聞くことになります。

これは楽になった点でもあり、こちらでコントロールできるものが減ったという側面もあります。（少し寂しくもあります）

クラスタ管理のためのコンポーネントがいくつか減った

クラスタの Audit log や master node 監視のために導入していたコンポーネントなど、いくつかの Cluster addon が AWS マネージドな機能に置き換わり不要になりました。こういう管理コンポーネントも導入した時点で運用が発生するので、管理コンポーネントが減ることは運用負荷的にもかなり嬉しいことでした。また EKS では AWS IAM Role と Kubernetes Service Account のフェデレーション機能を持っているため、IAM User とアクセスキーの管理をしなくて良くなるのも嬉しいポイントです。

Kubernetes バージョンアップがボタンポチポチになった（？）

新しい EKS バージョンが利用可能な場合、EKS のコンソール画面には『今すぐ更新』というボタンが現れます。ワンクリックで EKS バージョンを in-place upgrade できる便利ボタンです。

もちろん実際にはしっかり CHANGELOG を確認して、非互換な API の対応や設計変更を考えた上で sandbox クラスタで in-place upgrade で壊れたりダウンタイムが発生しないかは検証しないといけないのですが、「もしかしたらこのボタン押すだけで今回はいけるのでは！？」という期待が持てることは嬉しいです。

実際にこれで upgrade が楽になるか、Control Plane の管理コスト削減がどの程度のものかは今後答え合わせをすることになるでしょう。

EKS は version EOL が来ると強制的に upgrade が走ります。つまり塩漬け作戦はできず、何もしなければサービスが壊れる可能性があります。チームとして upgrade の優先度が勝手に上がるので、これは良いことだと思っています。また Wantedlty では AWS Enterprise Support に加入しているため、AWS SA（ソリューションアーキテクト）の方との定例での version EOL や情報のキャッチアップやサポートの恩恵が、自前構築クラスタのときと比べて格段に増えています。

まとめと今後の展望

Wantedly の2022年 EKS 移行は『EKS のアップデートによって移行工数と移行メリットが釣り合ったことをトリガーに実行した、 Kubernetes クラスタ管理コストの削減のため』のものでした。今後は削減できたコストを使い、 EKS の便利な機能を使い倒してプラットフォーム化戦略と開発により力を注いでいくつもりです。

この辺興味ある方、同じプラットフォーム開発を実践されていたり Enabling SRE などの推進に悩んでるエンジニア諸兄姉、もしよかったらディスカッションしませんか。
👉 @irotoris - Twitter