インフラコード化Tips ~AutoScaling編~
こんにちは、ベーシストエンジニアの福永です。
今回は、AWS環境をコードで構築する際に考えるべきことを書いていきたいと思います。あくまでも実務ベースなので記載していること以外にもたくさん考慮すべき点はあると思いますが、参考までに読んでいただけると嬉しいです。
インフラコード化
そもそもインフラをコード化したことがない方向けに説明しておきます。パブリッククラウド（AWS、GCPなど）で環境を構築する際、アプリケーションを作成するようにコードで構築することをインフラのコード化と表現しています。
AWSだとCloudformation、Terraformあたりが有名でしょうか。参考になりそうな記事を貼っておきます。
今回の記事では具体的な実装方法ではなく、どういうことに気をつけるべきかについて述べるので、前述した技術に詳しくない方も安心して読んでいただけます。
AutoScaling
今回の記事で述べるAutoScalingについても説明をしていきます。AWS環境でサーバを構築する際、サーバのCPU使用率などのリソース使用状況を検知し、サーバの台数を自動的に変更させる仕組みがあります。それがAutoScalingです。
サーバの最大容量・最小容量・希望する容量（「容量」と「サーバの台数」は同義です）を指定することで台数の増減をコントロールできます。
用途としては、サーバの障害時に障害が発生したサーバを終了し新規インスタンスを立ち上げる「オートヒール（自動回復）」とサーバのリソースが逼迫した際（事前にしきい値は定義）に台数を増やす、またはリソースに余裕がある歳に台数を減らす「オートスケール」があります。
AWSでは上記をコントロールする設定として「Auto Scaling グループ」「起動設定」というものがあります。インフラを構築するソースコードにはこの二つを記載することになります。
それでは、実際に注意すべき点を記載していきます。
1. サーバイメージ（AMI）ID
1点目は、AutoScalingにて起動するサーバのイメージについてです。AutoScalingグループの起動設定にて、起動するサーバのイメージを指定できます。ミドルウェアやサーバの設定値をあらかじめ設定しておくことで、毎回構築完了済みのサーバを自動で起動することが可能です。
このことで問題になるのが、サーバの設定値を直接SSH接続して変更することができなくなるということです。オンプレミスの運用に慣れている方はこの辺りが新しい部分かなと思います。正直インフラをコード化するしないに関わらず発生する問題ではありますが解説しておきます。
サーバの設定変更作業は以下の流れで実施します。
変更内容を決定 → イメージから変更作業用のサーバを起動 → 起動したサーバに対して変更を実施 → 変更したサーバからイメージを作成 → イメージのIDをソースコード上で変更 → コードを環境に適用 → インスタンスの更新（マネージドでコマンドが用意されている）
インスタンスの更新については以下を参照
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/asg-instance-refresh.html
実際に運用していて、最も発生する作業が上記です。ミドルウェア構成管理ツールを利用することで自動化できる部分も多そうなので、上手く自動化することが運用改善の鍵になりそうです。
2. 冗長化
Auto Scalingグループを利用すると、設定変更にサーバの入れ替えが生じるという話を述べたと思います。それに伴い、1台でサーバを運用していると設定変更の際ダウンタイムが生じてしまいます。オンプレの場合は再起動を伴う変更でもない限り、ダウンタイムは生じませんがAuto Scalingを利用する場合はこの辺りも検討しておくべきです。
サーバを2台以上で運用することでダウンタイムを0に抑えることが可能です（障害などの例外を除く）インスタンスの更新に伴い、サーバの最小正常率を指定することが可能です。この値は、全体のうち何台を正常に保ちながら入れ替えを実施するかという値です。
サーバ2台で運用している場合、最小正常率を50%に設定することで1台ずつサーバを入れ替えることが可能です。運用手順書を作成する場合、あらかじめ最小の台数を定義し、数値を指定するべきだと思います。
注意点としては、サーバの入れ替え時間です。全てのサーバを一気に入れ替える場合と1台ずつ入れ替える場合では作業時間が違うのはなんとなく想像がつくと思います。
作業を実施する時間（日中、深夜帯など）、作業体制（システム停止を前提とするのか）、システム要件（ダウンタイムをどのくらい許容するのか）によって運用をコントロールすることが重要になります。
3. デプロイ設定
CodeDeployなどを利用してデプロイを実施する際、Auto Scalingグループに対して「ブルーグリーンデプロイ」設定が可能です。
ブルーグリーンデプロイとは、現在動いているサーバ群とは別に新規でサーバ群を作成し、新規のサーバ群に新規のアプリをデプロイ、デプロイ後正常なことを確認しルーティングを新規サーバ群に振り分けるというものです。
https://xtech.nikkei.com/atcl/nxt/keyword/18/00002/070800077/
Auto Scalingグループにおけるブルーグリーンの挙動としては、自動で新規のAuto Scalingグループを作成し、そのグループを新規環境として利用します。一見問題なさそうですが、インフラソースコードで管理していないAuto Scalingグループが作成されるため、コードでの管理が難しくなります。プロジェクトごとの方針によるかもしれませんが、コードでインフラを管理するという観点から言うと、ブルーグリーンデプロイは利用しないのが無難だと思います。
上記を考慮し、開発環境などの検証で不安材料を潰し込むこと・環境差異を最小限に押さえることがより重要になってきます。
まとめ
今回の記事では、インフラコード化の際Auto Scalingについて注意すべき点を述べました。Auto Scalingは仕組みは単縦ですが、選べるオプションが多いので運用に合わせて色々なシナリオを検討し運用手順を整備することが重要です。そもそも、コンテナを利用する場合は参考にならないかもしれませんが、古くからのシステム会社ではコンテナへ対応するのはまだ難しくEC2サーバを利用するケースも多いと思います。システムのオンプレからパブリッククラウドへの移行の場合は既存システムと近い構成が求められるケースもあるので、そういった場合はAuto Scalingを利用してみると良いと思います。
コンテナ利用経験を積めたら、コンテナとEC2における拡張性の違いについて記事が書ければと思います。
この記事が気に入ったらサポートをしてみませんか？