はじめに
こんにちは！リプレイスチームの野口と @inosy22 です！
今回のブログは GameWith のロードバランサーを AWS の CLB から ALB に変更した背景や変更手順、詰まったところや解決方法について書いていきたいと思います！
リプレイスに関してはこちらの記事で紹介しています！
ALB(Application Load Balancer)とは
サービス概要
ALB は、アプリケーションレイヤー (L7) でルーティング決定を行い、パスベースのルーティングをサポートしている高機能なロードバランサーです。
メリット
- パスベースルーティング
- URLのパスによって Lambda や EC2, ECS などに振り分けることができます！
- 例：
/apiの時にAPIサーバー、/appの時にアプリケーションサーバーに振り分ける
- リスナールール
- URL のパス以外にも、IP や UserAgent で振り分けることもできます！
- AWS WAF (Web Application Firewall) が利用できます！
なぜ CLB から ALB に変更をしたのか
主な理由はパスベースルーティングでリプレイスしたサービスに段階的に振り分けることをしたかったからです。
GameWIthが利用していた CLB では上記のような柔軟な振り分けが難しかったので、ALB に変更することにしました。
それ以外にも ALB だけでメンテナンス画面を表示する対応が完結したり、リスナールールで IP 制限など、メリットが多かった為です。
移行方法
1. ALB を作成する
ALB は ALB の作成画面で簡単に作れます。
しかし、CLB から ALB に移行する場合、CLB の画面から移行ウィザード経由で作る方法があります。
GameWith は独自のスケーリングシステムを構築しているので、CLB の移行機能ではなく、ALB 作成画面から ALB を作りました。
2. 独自のスケーリングシステムの改修
GameWith は EC2 の台数を独自のスケーリングシステムによって増減させています。
www.slideshare.net
このシステムを ALB に対応させるため改修を行いました。
詰まったところ
独自のスケーリングシステムは、ALB のリクエスト数によってスケールの基準を変更しています。（例：20万アクセスだったら20台）
CLB の時と同様に実装をしたところ、リクエスト数の取得を安定して行えませんでした（例：たまに取得できなかったり、取得できても0アクセスだったりなど）
CLB の場合は1〜2分前のリクエスト数であっても安定的に取得ができていたのですが、ALB ではそれがうまく動きませんでした。
そこで、リクエスト取得の時間を5〜6分前に変更してみたところ安定して値が取得できるようになりました。
いろいろと調査をしているなかで似たような問題を Google フォーラムで取り上げられているのを発見でき、解決の糸口となりました。
3. 移行前に ALB の暖気申請をする
暖気申請とは、予めスパイクが来そうな時間を AWS に伝え、CLB から ALB の切り替えによって瞬間的に増える大量の接続をさばけるように ALB のキャパシティを事前に上げておいてもらう申請のことです。（AWS サポートプランのビジネス・エンタープライズに入っているのが条件です）
今回の暖気申請の理由としては、GameWith はアクセス数が多いサービスなので、切り替えの瞬間などで落ちないように申請をしました。
実は暖気申請の存在を知らず、移行リリースギリギリに知りました。
知った当日に申請をしましたが、リリース日には間に合わず、リリースの予定を後ろにずらしました。
詰まったところ
ALB の暖気申請をする場合はマルチ AZ で配置をする必要があります。
GameWith の場合はシングル AZ だったため、暖気申請のためにマルチ AZ 配置をしました。
終わりに
これからサービスが成長する際に、パスベースルーティングが使えるようになりマイクロサービス化がしやすくなりました！
独自スケーリングシステムがブラックボックス化していたので、リファクタリングしバージョンアップができたのでよかったです！
暖気申請は忘れずに！（2回目）
GameWithのDeveloper向けTwitterアカウントも開設しました。
ブログの更新情報などを発信するので良かったらフォローよろしくお願いいたします！
