おしらせ
2021/06/27 の Drecom SRE Sunday にて、 この記事にかかれている EKS 移行に関する情報共有を行います、ぜひご参加ください！
はじめに
こんにちは！
enza SREチームのmendと申します！
先日の安藤さんの記事「古き良きRailsアプリケーションをコンテナ化してKubernetes上で動かす」にもある通り、運用しているプロダクトをAmazon EC2からAmazon EKSに移行しました。
プロダクトをダウンタイムなしにEC2からEKSに移行しましたので、今回はダウンタイムなしを実現したインフラ側の構成について紹介させて頂きたいと思います。
背景
まず背景としましては、私の関わっているプロダクトはこれまでEC2で動作しておりました。
EC2上でdockerコンテナを起動しているのではなく、capistranoでデプロイされ直接Railsを実行する一般的なスタイルになります。
インフラ構成は図にすると以下のようになります。
Route53で管理しているドメインの後ろにApplication Load Balancer(以下ALB)を置き、ALBのアクセス先としてターゲットグループを用意してある形になります。
移行方法の候補
初期段階で考えていた方法では、ALBに紐づくターゲットグループを切り替える案がありました。
しかしこの案だと、ALBがターゲットグループと紐付けされてからターゲットとなるインスタンスのヘルスチェックを行うため、切り替え直後はヘルスチェックが完了していないインスタンスが存在する時間が発生します。
結果として切替時にサーバーの負荷が急激に上昇しアクセスが処理できなくなってしまうため一時的にアクセスを遮断する対応、すなわちダウンタイムが必要でした。
しかしダウンタイムの発生はビジネス的な面で損失が大きいため、ダウンタイムを出さない、かつ段階的な移行を実現する方法として、2つの案が候補として挙がりました。
Route53の加重ルーティングポリシー
Route53のルーティングポリシーの一つである加重ルーティングポリシーを設定し、任意の割合でRoute53のエイリアスを振り分ける設定になります。
動作例
example.comのレコードのエイリアスとして、A：ALB1のドメイン名、B:ALB2のドメイン名を設定したとします。
A:Bの重み付けを4:6にした場合、example.comの名前解決時に40%の確率でALB1のドメイン名を返し、60%の確率でALB2のドメイン名を返す動作となります。
加重ルーティングのメリット
Route53のルーティングポリシーを変更するだけのため、割合変更のために操作するリソースがRoute53だけで済むというメリットがあります。
併せてEKSで一般的に使用されるALB Ingress Controllerを使用できるため、一般的なEKSクラスターで使用しやすいメリットがあります。
加重ルーティングのデメリット
加重ルーティングはアクセスを振り分けるためのもう一つのALBを作成する必要があり、ALBとターゲットグループ等のようなALBに関連するリソースを作る必要も発生してしまいます。
併せてRoute53が返却するエイリアスを割合で変更する設定のため、Route53の振り分け割合設定がユーザーに反映されるまで時間がかかり、アクセスを任意の設定で振り分けるまでにラグが発生してしまう欠点があります。
この欠点は一方のアクセス先で問題が発生したときに切り戻しにかかる時間が長くなり、障害が完全に収束するまでの時間を伸ばしてしまう要因になることが考えられます。
ALBの加重ターゲットグループ
ALBのターゲットグループに複数のターゲットグループを設定し、加重ターゲットグループとすることで任意の割合でアクセスを受け取るターゲットグループを振り分ける設定になります。
動作例
ALBのターゲットグループとして、A:ターゲットグループ1、B:ターゲットグループ2の２つのターゲットグループを紐付けるとします。
A:Bの重み付けを4:6にした場合、ALBからターゲットグループに渡されるアクセスの40%がターゲットグループ1, 60%がターゲットグループ2に割り振られるようになります。
加重ターゲットグループのメリット
加重ターゲットグループはALBにターゲットグループを追加するだけのため、Route53の加重ルーティングと異なり同一のALBを使用することができるメリットがあります。
またRoute53のようなDNSでの切り替えではないため、アクセス割合設定の変更が即時反映される特徴があります。
このメリットは非常に大きく、障害が発生したときには一方のアクセス先のみに設定しますが、設定が即時反映されるため、障害発生から収束までスピーディに解決することが可能です。
加重ターゲットグループのデメリット
加重ターゲットグループの設定はALBに設定する内容のため、EKSで一般的とされるALB Ingress Controllerを使用できないデメリットがあります。
加重ターゲットグループで移行する
上記2つの方法のメリット・デメリットを考慮したうえで、ALB Ingress ControllerではなくNodePortを使用していること、振り分けの割合設定が即時反映されることから加重ターゲットグループを使用して移行を進めることにしました。
ここからはダウンタイムなしを実現するために構築したインフラについて紹介していきたいと思います。
移行時のインフラ
移行を行うにあたり、既存のALBのリスナーにEC2のターゲットグループに加え、加重ターゲットグループとしてEKSのターゲットグループを置きます。
図にすると以下のようになります。
こちらの図にあるように、ALBからアクセスする先のターゲットグループが複数存在するようになりました。
これらのターゲットグループにはアクセス振り分け割合を設定可能で、
例えば既存EC2側には90%, EKS内にあるターゲットグループには10%と任意の割合でアクセス先の変更をコントロールすることができます。
この割合変更はAWS マネジメントコンソールから手動で行うことができ、かつ設定した内容は即時反映されます。
そのため最初はEKS側に少ない割合のリクエストを振り分け、正しくリクエストが処理されることをPodのログ等から確認し、EKSへのアクセスの割合を徐々に増やしていくことでスムーズな移行が可能になります。
さらに徐々にアクセスの割合を増やすことによってクラスター全体のPodやワーカーノードの負荷を監視しながら移行できるため、万が一リソースが足りないといった問題は移行中に気づくことができるなどの恩恵もあります。
移行後のインフラ
EKSへ移行後はEC2のターゲットグループへのアクセス割合が0%になっている状態になります。
こちらはEKSに完全に移行した後の図になります。
こちらにあるように、EC2のターゲットグループにはアクセスが割り振られないため、完全なEKS移行が実現しております。
移行後はEC2側へのアクセスが割り振られていないため、ユーザーに影響を出さずに安全にEC2を終了させることが可能になります。
移行時に注意すべきこと
上記の流れで行うことでダウンタイムを生むことなく移行ができますが、1つ注意すべき点がありますので記載します。
EC2を停止するタイミング
ターゲットグループの仕様として、ターゲットグループ内のインスタンスが全てヘルスチェックに失敗している場合はヘルスチェックに失敗しているインスタンスにもアクセスが割り振られます。
ターゲットグループのヘルスチェックには以下のように記載されております。
ターゲットグループに異常な登録済みターゲットのみが含まれている場合、ロードバランサーノードは異常なターゲット間でリクエストをルーティングします。
このことから、もしEC2側のターゲットグループにアクセス割合を割り振っている状態でEC2インスタンスを全て停止してしまうと、停止しているインスタンスに対してもアクセスが流れてしまうので注意しましょう。
まとめ
今回は実際にプロダクトをダウンタイム無しでEC2からEKSに移行した際の方法を紹介させて頂きました。
ダウンタイムを出さずに移行する方法としてはRoute53の加重ルーティングポリシーとALBの加重ターゲットグループのパターンがあり、それぞれのメリット・デメリットを加味したうえでALBの加重ターゲットグループを使用してEKSへの移行を行いました。
これまでEC2で運用しているプロダクトもきちんと手順を正しく踏むことで、安全に夢のEKSに移行できるので、EKSに移行する際に参考なれば幸いです。
今後もk8s関連の情報を発信できればと思います。
ドリコムでは一緒に働くメンバーを募集しています！
募集一覧はコチラを御覧ください！
