所属が技術一課に変わりました、鎌田(兄の方)です。
Active Directoryネタがどうしても多いワタクシですが、スクリプトをゴリゴリ書いて、自動で処理が流れていくのを眺めているのも好きです。
そんな中、日経クラウドファーストの12月号に、「環境構築自動化」に、AWSでの構築自動化に関して、当社白鳥との共同執筆にて寄稿いたしました。
詳しい「構築自動化」のエッセンスはそちらをお読みいただいて、こちらでは紙面の都合上、やむを得ずページを割けなかった内容について、ご紹介します。
構築のためのコードってどうしている？
記事では、CloudFormationやOpsWorksで利用するコードのサンプルを紹介しているのみですが、当然、コード書くことが必要になります。
私たちは普段、CloudFormationを利用し、構築の自動化を実施していますが、CloudFormationは、少し前までjsonしか対応していませんでした。
会社で標準的に取り込むべきパラメタは、意図があってこの設定だよ、と書いておきたくても、jsonにはコメントを挿入できないため、できません。
そこで私たちは、Yamlファイルという中間コードを用意し、どういったパラメタを書けば良いか、各エンジニアでも分かるような内容のものを用意し、jsonファイルとmarkdown形式の出力が出来るツールを開発しました。
記事のプロフィールでも紹介している、Yambdaという社内ツールです。
※是非、プロダクトオーナーである永田のインタビューもご覧ください
標準パラメタや設定に関するコメントを挿入することで、実際にコードを書く際に迷うことがないようにしています。
また有志のメンバーで、書き方に困った際のフォローアップを行っています。
以下はコードの一部ですが、このような形のコードを用意しておくことで、誰でも自動化に取り組めるように努めています。
ELBs:
- name: elb01 #必須。半角のみ可。
subnets: [subnet-elb-a, subnet-elb-c] #必須。yml内のSubnet名または既存SubnetID。ある複数のSubnetを指定する場合、異なるAZに所属するSubnetを指定すること。
cross_zone: true #必須。true or false。trueの場合、AZ間でバックエンドインスタンスへ負荷分散します。
構築のコード化はいいけど…チェックはどうする？という問題
インフラの構築が自動で出来るのはいいけれど、コードのチェックはどうするのか、という問題があります。
作成したインフラ自動化のコードは、特定のAWSでなければ構成できない、というものではないので、お客様環境のAWSアカウントで実行する前に、テスト用のAWSアカウントで確認を実施しています。
(お客様によっては固有のAMIを使われるケースがあるため、またVPNは構成できないため、その部分は差し替えてテストしています。)
構成しようとする構成に問題がないか、事前に確認が出来る。これも、自動化で得られる一つのメリットです。
自動化に関わるサービスは他にもある
自動化に関わるサービスは、今回記事で紹介したCloudFormationやOpsWorksだけではなく、ElasticBeanstalkやCodePipelineなど、AWSにもいくつかのサービスがあります。
以下の図がの青い部分がCodeを書いてから実際に環境を作るまでの流れ、その下がAWSの自動化に関わるサービスで、オレンジ色を付けた部分が今回記事で取り上げているサービスです。
いくつかのサービスはあるものの、どれか一つでは不十分であると、お分かりいただけるのではないでしょうか。
このため、自動化はどれか一つのサービスのみで実現するのではなく、サービスを組み合わせて、自動化を実現する形を推奨します。
まとめ
アーキテクトの眼でも触れていますが、最初に投資は必要です。
しかし、インフラをコード化することで、コードなのでバージョン管理が可能になり、ある時点のインフラに戻したい、同じ環境を作りたい、インフラを強化したい、などの場合でも、きちんと履歴が残りますし、過去との差分を確認できるようになります。
「何が変わったのか分からない」インフラに悩む機会が、減っていきます。
また、構築自体が自動化しているため、ヒューマンエラーといった細かいミスが減り、投資に対する効果を得られるようになっていきます。
是非、記事も参考に、自動化に取り組んでいただきたいと思います。
