2020.05.14 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による作業のみで完結することが可能となりました。

今後の対応と課題

CloudFormationを利用して、「利用しない期間コストの削減」と「再構築作業の簡略化」を実施できましたが、それ以外にもインフラをコード管理することによる「構成管理」もできるようになりました。

また、今回はサーバ内部への適用や、継続的デリバリーサービスであるCodePipeline/CodeBuild/CodeDeploの利用は見送りましたが、これらを組み合わせることでリリースプロセス全体を自動化することが可能となり、リリーススピードを早めることが可能となります。

関連サービス

おすすめ記事

導入のお問い合わせはこちら

AWSやAmazon WorkSpacesの導入から接続回線、運用・保守まで何でもお任せください。

お問い合わせ・資料請求