Analytics Teamの山内健二です。RevCommの解析基盤に導入されているAmazon EKSクラスタでBlue/Greenアップグレードを導入し、合わせて今後の工数削減のために自動化を行ったので、その内容をご紹介します。

RevCommの解析基盤の概要

アップグレードの内容の前に、簡単にRevCommの解析基盤を簡単に紹介します。RevCommはMiiTel、MiiTel Meetingsなど、複数のプロダクトを提供しておりますが、文字起こしなどの解析を実施する基盤は共通して単一のものとなっています。この解析基盤は単一のアプリケーションから動いているのではなく、音声認識など解析機能等の単位で分割された複数のアプリケーションから構成されており、現在これらが1つのEKSクラスタの中にホストされています。

EKSクラスタを含めたAWSリソースや、AWS Load Balancer ControllerなどのミドルウェアはTerraformによりIaC化して管理しています。また、クラスタ内で稼働しているアプリケーション用のKubernetesマニフェストは別途リポジトリを用意して管理しており、クラスタ内で動いているArgo CDでmainブランチを参照させてデプロイしています(Pull型のGitOps)。

EKSのアップグレード方針

RevCommの解析基盤では、EKSを導入してからこれまでin-place方式、すなわち既存クラスタのバージョンを直接アップグレードしていました。前述したようにRevCommの解析基盤はIaC化しているため、いくつかの設定値の変更のみで簡便に行えるのですが、欠点もあり、今回Blue/Green方式でのアップグレードを導入することにしました。

具体的にはin-place方式ではEKS Best Practices Guideでも解説があるように順次ノードグループ等のリソースをアップグレードします。そのため、サービスのダウンタイムが発生する可能性があり、また、アップグレード後に問題が発生しても切り戻しができません。さらに、クラスタ内で稼働しているノード数の増加に伴い、アップグレード自体の時間も最大数時間に及んでいました。

一方、Blue/Green方式では現在のクラスタとは別に新しいバージョンのクラスタを用意し、こちらへトラフィックを順次誘導していきます。問題が起きないことを確認してから古いバージョンのクラスタを破棄するため、前述したような問題は起こりません。しかし、新しいクラスタの用意が必要なため、その分の工数が必要です。今回RevCommでは工数を考慮してもin-place方式で述べた欠点の克服にメリットがあると考え、Blue/Green方式を採用しました。

実装方法

クラスタ切り替えの概要

今回の実装にあたっては、構成が類似していることもありAmazon EKS Blueprints for TerraformのBlue Green Migrationを参考にしました。基本的には下記の流れで行います。現行クラスタがバージョン1.25で、新規クラスタをバージョン1.28で実施する際の例を図で示しています。

新規のクラスタ作成とミドルウェアのインストールをTerraform側で実施
- 新規クラスタにArgo CDでアプリケーションをデプロイ
マニフェスト側の変更
- external-dnsを利用し、Ingressのアノテーション経由でRoute 53の加重ルーティングによりトラフィックを分配
  - set-identifierとaws-weightを設定します
- これらの変更はマニフェストのリポジトリのフィーチャーブランチとして作成し、新規クラスタ側のArgoCDは一旦そちらを参照するようにします。現行クラスタはmainブランチを参照したままです。
新規クラスタでの挙動が問題ないことを確認したら現行クラスターを削除
- 前述したフィーチャーブランチをmainブランチへマージし、新規クラスタのArgoCDもmainブランチを参照するようにします

自動化

これらの流れはTerraformでのvariableの値やマニフェストの一部の調整のみで実施できるものの、手順が複数工程にまたがることもあり、オペレーションミスや属人化を防ぐためにGitHub Actionsなどにより極力自動化させました。具体的に実施した自動化は、主にクラスタ作成・削除の2つです。図に流れの概要を示しています。

前提として、解析基盤のTerraformのコードは図に示すように各環境(開発、ステージング、本番)ごとでbackendとvariableを管理するためのディレクトリ(以下単に環境設定と呼びます)をvarsディレクトリ以下に配置しています。各環境設定はcluster-YYYYMMのように、環境ごとの識別子をつけて管理しています。例えば図左ではcluster-202403が存在しています。また、現行クラスタ用の環境設定は、図左のclusterのようにシンボリックリンクで指すようにしています。

ここで新規クラスタを作るとき、新しい環境設定の生成・Terraformコードの適用によるクラスタ作成・シンボリックリンクの張替えが必要になります。逆に現行クラスタを削除する場合は、現行クラスタからのアプリケーションとミドルウェアの削除・現行クラスタの削除・現行クラスタの環境設定の削除を行う必要があります。これらを手作業で行うのはオペレーションミスを誘発するので、GitHub Actionsにて識別子やバージョンを入力として行えるようにしました。

このような自動化により、クラスタの作成から切り替え、削除までをローカルでの手作業なしにできるようになり、時間的にも新規クラスタとそこへのアプリケーションデプロイまで数十分でおこなえるようになりました。

まとめ

今回はRevCommの解析基盤のEKSクラスターのアップグレード方式をBlue/Greenに変更した際の紹介でした。

in-place方式と比べて工数を悪化させないための自動化や手順の確立は必要でしたが、IaC化の素地もあったため、メリットを最大限享受した上でBlue/Green方式を導入できたと感じています。解析基盤自体が、ステートフルな要素が少なく、アプリケーション側で考慮するべきことが少なかったのも親和性がありました。参考になれば幸いです。