こんにちは。クルーズ株式会社CTOの鈴木です。
前回の投稿「WebインスタンスのOS/PHPバージョンを最新安定版にあげた話」の最後で少し触れましたが、今回Webおよびバッチインスタンスについては各セール開催の都度、いちいち手動でEC2インスタンスを作成しなければならず、急にサーバを増やす際に、EC2のイメージを元にインスタンスを作成し、ソースコード同期を行いバランサーに追加する作業が必要で非常に面倒でした。
そのため、Webインスタンスについては、起動テンプレートの構築とEC2 Auto Scaling上でのインスタンス管理を行う方式に切り替えを行っています。
Auto Scaling導入の進め方
Auto Scalingの導入は目的ごとに大きく３つのフェーズに分けて進めていきました
① 既定のインスタンス台数分を常に稼働できるようにすること
⇒ 仕組みとしてのAuto Scalingの導入。
要するに必要台数のうちインスタンス障害で1台死んでも、自動で1台がスケールアウトして、トータルで必要台数を確保できる状態を維持すること。
② 負荷に応じて自動で増強/縮退運転できるようにすること
⇒ 負荷対策/サービスダウン防止のための導入
要するに本来のAuto Scalingの機能を活用して、サービスダウンを防ぎ、機会損失を防ぐこと。
③ 負荷＋時間に応じて自動で増強/縮退運転できるようにすること
⇒ コスト最適化のための導入
要するに需要量に応じて運転制御をすることでコスト削減を行うこと。
実施する際に苦労したこと
サービスとしてはAutoScalingは非常にうまくできているのですが、今までEC2で運用していたシステムをそのままAutoScalingで運用しようとすると、いろいろ運用面で苦労することがあります。
その一つがIPアドレスなど、インスタンス情報がスケーリング実行都度に代わってしまう問題です。
いままで当社だと、SSHでサーバにログインする際やZabbixなどの監視エージェントが監視サーバにログを送るときのホスト名はEC2インスタンス構築後に社内の命名規則に従い、Linuxのホスト名および社内DNS(Active directory）上にAレコードとして登録し、その名前でSSH接続を行ったり管理サーバにログ送信する運用をしていました。
今回Auto ScalingでEC2の運転を管理することによって、上記の運用ができなくなり、ホスト名でSSH接続ができなくなる。監視システム上でどのインスタンス化の把握が困難になるなどの問題あり、緊急時に問題が発生しているインスタンスの特定が困難になるのではという懸念がありました。
根本の話だと、そもそもSSHでWebインスタンスに都度接続する運用自体に問題があるのですが、一方でアクセス集中でWebプロセスが固まった際にkillするためにSSH接続を行う必要がありその際に接続先の特定に手間取るのはリスクであり対処として、踏み台サーバ上でaws ec2 describe-instancesコマンドを実行して、tagとインスタンスIDとプライベートIPを表示するシェルスクリプトを用意し、そのシェルで接続先IPを検索できるようにして踏み台サーバ上で接続先のインスタンスのIPアドレスを検索できるようにする仕組みを準備し運用に備えました。
２．実環境上で実際のサーバ増強/縮退運転のテストを安全に行うのが結構手間な問題
これは結構地味に大変な話なのですが、
- 閾値を調整して強制的にスケールアウト/スケールインできても、本当に負荷が都合よくかかってくれてスケールアウトしてくれることがあまり発生しない。
- SHOPLISTほどの規模になると、テスト上問題なく動作しても簡単に本番導入させづらい。
という問題はあり、地味に苦労しました。
進め方としてはにはALBのTarget Group 毎にASGを準備しているので、負荷変動の少ないASGから順に導入し、閾値を調整してスケールアウト/スケールインが頻繁に発生するような状況を作り、1カ月ほど運用を行い、通知含み問題が無いことを確認してから負荷変動の大きいASGも導入していく形で進めていきました。
３．Auto ScalingのSNS 通知が読みづらい問題
こちらも地味な話なんですが、SNSの通知の内容が分かりづらく…
というか、Auto Scalingに関係なく、監視目的でSNS通知を使うとだいたい、内容が分かりづらく、経験則的に「あー、この通知だと多分こんなこと起こってるｗ」みたいな感じの対応をしています。
まあ、頑張ればカスタマイズできるのかもしれないのですが、優先度としては低い話なので今は静観しています。
実施してみて
導入を開始して約半年たっていますが、今のところ問題の発生はなく順調に動作しています。
また、今作成している「AWS AutoScaling とEC2のスポットインスタンスを組み合わせてWebサーバのコスト削減した話」でも触れますが、変動分のインスタンスの起動時間が短ければ変動分のインスタンスをスポットインスタンスで構成すればWebインスタンスのコストとしては約2～3割ほどは実績としては減っておりコスト面でのメリットはありました。(当社の場合Compute Savings Plans で全額前払および一部前払で購入しているため、コストの削減効果としては導入直後にすぐは出ず、契約更新時となりました。)
今後AWS Auto Scalingを導入する方へのアドバイス
AWS Auto Scalingは素晴らしい仕組みではあるものの、当社のようにオンプレから仮想サーバに移行する形でクラウド化したシステム（簡単に言うと仮想サーバとしてEC2を使ってクラウド移行を行っているシステム）の場合、インフラの運用設計や監視設計がインスタンス名やプライベートIPが固定で運用されているケースが多く、オペレーションの見直しも含めて実施を検討してみてください。
ということで、今回はAWS Auto Scaling によるインスタンス管理に切り替えた話について書いてみました。
次回は、続編として「AWS AutoScaling とEC2のスポットインスタンスを組み合わせてWebサーバのコスト削減した話」について投稿したいと思います。
-------------------------------------------------------------------------------------------------
※2020年の内容を記事にしており、2020年11月以降PHP7サポート切れをはじめとした脆弱性リスクへの対処は完了しております。
