この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは
IT推進室 畠山です。
今回、AWSで運用していたEC2のインスタンスをスケールダウンした際に発生した事象をご紹介します。
AWSの利用は、定期的に適切なインスタンスのキャパシティで運用する事で、コストを最適化しながら運用できることが大事なことです。
そんな中で、私が直面した事象をご紹介して、皆様の適切なインスタンスタイプの選択の助けになれば、幸いです。
c4.largeで動いていたEC2とロードバランサー
当初、c4.largeのEC2で、とあるパッケージソフトを運用しておりました。
その環境のほとんどのサービスをクラウドサービスに移行したためEC2のインスタンスをスケールダウンする事になりました。
ロードバランサーの使用に関しては把握していたものの、影響が出る部分とは認識していませんでした。
行なった作業
行なった作業は単純で、EC2インスタンスを停止して、インスタンスタイプをc4.largeからm3.mediumに変更、データベースのRDSも同時にm５からt3にスケールダウン。
RDSのインスタンスタイプ変更後の起動を待って、EC2を起動してCLIから対象のサービスを止めました。
その後、それらのサービスにアクセスできなくなった事と、残った一部のサービスにアクセスできることを確認して作業終了としました。
ロードバランサー経由でアクセスできない！！
一部のユーザから、「ロードバランサー経由でアクセスできない」という報告がありました。
早速、調査開始しましたが、どう見ても設定は間違っていない。
使用していたロードバランサーは、Network Load Balancer（NLB）で、特に特殊な設定をしていたわけでもなく、マネジメントコンソールで確認しても、ステータスは「healthy」となっています。
何度、見直してもおかしな点は見つからず・・・・・。
ん？？ 変なメッセージ発見！！
そもそも、自分には変更する権限がないためグレーアウトされていると思い込んでいた部分にカーソルを合わせると！！ なんだ、このメッセージは？
すぐさま、AWSのドキュメントを検索。
そうです。NLBが利用できるインスタンスタイプには制限があり、不用意にスケールダウンを行なったことで、NLBを動作させられないインスタンスタイプに変更してしまっていました。
まとめ
ロードバランサーをはじめ、様々なサービスを組み合わせて利用するAWSでは、サービスの組み合わせの制限も多く存在します。
利用しているサービスの構成をきちんと把握して、スケールアップ、スケールダウンの際に影響が出そうな部分を事前にしっかり調査した上で実施することが重要ということを身にしみて体験しました。
今回は、利用者も少ない環境だったため全社への影響はそれほど大きく無かったのが幸いでしたが、今後は事前の調査等をしっかり行って、運用を行なっていこうと思います。
AWSの運用やご相談は、当社までご相談下さい。 クラスメソッドメンバーズ（AWS総合支援）
256
