オンプレミスからEKSに移行した後日譚

当社ではSynergy! というSaaSサービスの開発・運営を行っています。
ローンチ19年に及ぶ老舗プロダクトで、筆者も10年近く開発に参加していますが、その中で一番印象に残っているのが、2022年に行った移行プロジェクトです。
オンプレミスの仮想マシンで稼働していたサービスをコンテナ化し、AWSのAmazon EKS へ移行する、という大きなプロジェクトでした。

このプロジェクトの概要や苦労話は当社コーポレートサイトの記事や AWS Summit Online 2022 の事例セッションにありますので、気になる方はご覧いただければと思います。

移行が終わって約2年たった今、一度振り返ってみようと思い筆をとりました。

効果はどうだったか？

基盤障害・運用負荷が激減

AWSへ移行したことで基盤要因の障害がほとんど発生しなくなりました。
オンプレミスで運用していたころは、ハイパーバイザーやロードバランサー、スイッチといった基盤起因の大きなトラブルが年間数回程度のペースで発生していましたが、移行後この2年間で発生した問題は「短時間のネットワーク障害が一度あったかな」という程度です。
この点については安定した基盤を提供してくれているAWSさんに大感謝。
オンプレミスでの運用では、障害に至らないハードウェア故障も都度検知、対応していましたが、移行後は、稀に通知されるEC2のリタイア予告を確認し、ノードを入れ替えるぐらいです。
心身共に負担が大きく削減されました。

新規アプリケーション構築が爆速に

これは、ほぼすべてのアプリケーションをコンテナ化しKubernetesで稼働させることによって得られたメリットです。
オンプレミス時代は、個々のサーバーの要件に合わせてオーダーメイドの仮想マシンが作られていました。
コンテナ化により単一のコンテナ稼働基盤ですべてのアプリを賄えるようになったため、基盤構築という作業は不要になりました。
移行プロジェクトにより様々なアプリケーションを稼働させ、ある程度のデザインパターン確立されたため、
また、基本的な監視はPrometheusを用いた監視の仕組みが出来上がっていることにより、社内の標準的な構成に従ってデプロイするだけで良く、ほとんど意識しなくても適切な監視が行われるのも大きな利点です。

苦労していることは

Kubernetesクラスタの定期的なバージョンアップ。これに尽きます。
Kubernetes（もちろん Amazon EKSも）は稼働中のクラスタに対し、ローリングアップデートでの更新を行うこともできますが、この方法は取っていません。
移行時には新しいバージョンのクラスタを構築し、ネットワークトラフィックを振り替える、いわゆるBlue/Greenデプロイメントで実施しています。
ローリングアップデートに比べて作業は多くコストはかかりますが、以下の要因を考慮しての判断です。

必然的に、構築・破棄を繰り返す前提として構築・運用手順が作成される
基盤の再構築を伴うため、導入しているオペレータなどを更新する良い機会になる
旧クラスタへの切り戻しが可能なため、稼働中のクラスタに対してバージョンアップを行うよりリスクが低い

Amazon EKSでのKubernetes各バージョンのサポート期間は約1年ほどで、年一回の棚卸だと思って実施しています。

Kubernetesがマッチするユースケースは？

では万人にお勧めするのか。というとそうでもありません。
とにかくコンテナ化したアプリケーションの環境をつくりたい。というだけであれば、ユースケースに応じて AWS Lambda / AWS App Runner / Amazon ECS などを使うとよいでしょう。
Kubernetesでの本番運用は、高い自由度の代償として、本番稼働に耐えうる環境の構築やバージョンアップの手間など大きなコストを必要とします。

Kubernetesがマッチするユースケースは