Infrastructure as Codeで実現する運用のオートメーション化

オンプレミス環境と違い、AWSではインフラをコードで定義できます。
そのコードを活用し、複雑な構築作業を自動化する事で、時間、コストを大幅に削減する事例をご紹介します。

運用上の課題

毎年、一定の時期だけ開設するWebサイトについて、オンプレで構築すると利用しない期間でも、サーバやネットワーク機器を用意する必要がありました。クラウドサービスを利用するとオンデマンドで利用できるため、利用しない期間は、サービスを止めておくことでコストを下げることが可能です。しかしながら、その場合は年次で環境を再構築する作業を行う必要があります。毎年忘れた頃にやってくる再構築作業や、削除作業の漏れ、いざ始めようとするとコンソール画面が変わっていたりして、想像以上に運用上のコストがかさむことがありました。

Infrastructure as Codeの活用で課題を解決

AWSでは、CloudFormationというInfrastructure as Codeのサービスが提供されており、テンプレートを利用した環境の構築が可能です。これを利用することで、年次で行う作業の簡略化と作業量の大幅な削減が見込まれます。今回は、こちらを利用して運用コストの削減までAWSのサービスを利用して改善しました。

対象となるWebサイトは、よくあるWebサイトの構成で、ロードバランサー＞Webサーバ＞DBサーバの三層を想定しております。利用しているAWSサービスは下記になります。

ユーザがAWSにアクセスするとALBがEC2にアクセスを分散。EC2とRDSが連携している。ALBにはAWS WAFが割り当てられ、SSL証明書が適用されている。

1.利用しているサービス

VPC（Subnet, IGWなど）
EC2（Auto Scaling）
ELB（Application Load Balancer + Certificate Manager）
RDS（Aurora）
WAF

2.サービス毎の仕分け

これらのサービスから、CloudFormation化して利用しない期間のリソースを
①削除することでコストメリットが出せるものと、②削除してしまうと問題があるものに仕分けします。

今回は下記のように分けました。

①削除することでコストメリットが出せそうなもの

ELB（Application Load Balancer）
RDS（Aurora）→内部のデータは来年に引き継ぐ必要なし
WAF

②削除すると問題がでるもの

EC2（Auto Scaling）→元となるAMIは残す方針とした
Certificate Manager→自動更新のため削除は実施しない
VPC（Subnet, IGWなど）→残っていても費用が発生しないため年次での削除をしない

3.テンプレートの設計

CloudFormationではスタック単位で作成するリソースが管理されます。単一のテンプレートでも作成は可能ですが、一部だけ削除する際に使い勝手が悪いため、上記仕分けを元に2つのテンプレートで設計をしました。

CloudFormationを作成していると、あるリソースで作成された値を、別のリソースのパラメータとして利用したい時があります。同一スタック内であれば、組み込み関数である、「Ref」や、「Fn::GetAtt」を利用することが可能です。今回のように別スタックに分けた場合は、「Fn::ImportValue」を利用して、別のスタックによってエクスポートされた出力を利用することが可能となります。

今回の利用では、VPCのリソースIDやサブネットのIDをエクスポートしておき、別スタックでのELB作成時などに利用をしております。

常設するCloudFormationから、年次構築するCloudFormationに対して「Fn::ImportValue」を利用してVPCのIDやサブネットのIDを連携

両方のスタックをデプロイすることにより、サービスに必要なAWSリソースがすべて作成されます。利用しない期間は、ELBやRDSが属するスタックを削除することで、期間中の利用料を削減することが可能になりました。再開するときには、削除されたスタックを再デプロイすることで、サービス状態を戻すことが可能です。これらの作業をCloudFormationによる作業のみで完結することが可能となりました。