こんにちは。技術二課の永田（@nagaaki46）です。
皆さんの一番欲しい物って何ですか？
五年前、私が一番欲しかった物といえばAragostaの車高調。
そして今年、一番欲しい物は衣類乾燥機に。
大人になるって、こういうことでしょうか。
そして、遂に我が家に導入されたガス式衣類乾燥機ィィィィィィィ！（リースやけどな）
人類の永遠の憧れ、仕事の「自動化」。
この衣類乾燥機と共に過ごせる私は最高に幸せ者です。
というわけで今回は、
サーバーワークスのAWS導入支援業務における
構築自動化の取り組みについてご紹介します。
サーバーワークスらしい構築の仕方って？
私は2014年8月からサーバーワークスにジョインしました。
最先端のAWSに触れ、古い体質が無いサーバーワークスの仕事のやり方に
「ウヒョ〜」と刺激を受ける日々を過ごしてきました。
刺激って大事ですよね〜。
一方で、インテグレーター業にありがちな泥臭いところがあるのも現実でした。
まだまだ属人性が高い設計フェーズ
サーバーワークスのAWS導入支援業務での設計フェーズ。
AWSエンジニアが構築対象AWSのパラメータ値をwikiに表形式で記載し、
お客様と共有・詰めていきます。
方眼紙ファイルを共有する昔ながらの方法に比べると、すこぶるスムースですね。
ですが、この方法でも100点ではありません。
AWSには沢山のパラメータが存在します。
社内で推奨のwikiのパラメータ表の雛形はあるものの、
どこまできっちり抑えられるかはエンジニア依存でした。
特に厄介なのが、暗黙値の存在とノウハウの共有です。
「いつも通りで」、「デフォルト値で」という認識で突き進み、迎えた構築フェーズ。
これらの暗黙値に何を設定すべきか再確認しなければなりません。
誤った認識のまま構築すると、一部再構築の可能性もあり得ます。
また、サーバーワークスには280社 / 460プロジェクト（*2015年6月末現在）を超えるAWS導入実績があり、
あらゆるノウハウが蓄積されています。
しかし、全エンジニアが完璧にノウハウを活かせているかというと、
流石に難しいですね。
まさに"作業"の構築フェーズ
そして構築フェーズ。
AWSマネジメントコンソールを使って構築していきます。
wikiのAWSパラメータ表を参照しながら
AWSマネジメントコンソールで値を選択したり、
AWSマネジメントコンソールにコピペ、コピペ・・・。
設計書と同じ内容を手作業で設定・入力していくことの違和感。
人手を投入しても期間短縮と作業精度向上には限界があります。
これはAWSらしい、そしてサーバーワークスらしい構築の仕方とは言えないですね。
この状況は打破しなければならない。そこで、
「労働力ではなく価値を提供するため、構築業務から"作業"を根絶する」
こんなテーマを掲げた自動化タスクフォースチームが立ち上がったわけです。
仕事の仕方、変えていこうず
実現したい要件は3つです。
- 漏れ、手戻りなく確実に設計が行えること
- サーバーワークスの設計構築ノウハウを集約・展開できること
- 設計通りのAWS環境が、AWSマネジメントコンソールと同等、もしくはそれ以上の早さで構築できること
これらの要件を満たしつつ、どのプロジェクトでも適用できるように、
そしてどのエンジニアでも扱えるようにするには、どうしたら良いのか？
行き着いたのは、
「定義書から構築用プログラムを自動生成し、実行する」
という古典的なアプローチです。（下記イメージ参照）
ポイントは3つです。
1)AWSパラメータ設計は定義書YAMLファイルに記載
一般に"設計書"というものは自由度が大きく、自動生成のインプットとするには難しいです。
設計書のフォーマットには強制力がなく、プロジェクトやエンジニア毎にカスタマイズされてしまいますからね。
設計書を自動生成のインプットにすると破綻するのは経験上わかっていたので、
YAMLファイルの定義書をインプットとするスタイルとしました。（下記サンプル参照）
#### RDS #### #See http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-properties-rds-database-instance.html RDSInstances: - db_name: mysql01 #STR engine: MySQL # MySQL | oracle-se1 | oracle-se | oracle-ee | sqlserver-ee | sqlserver-se | sqlserver-ex | sqlserver-web | postgres engine_version: 5.6.22 license_model: general-public-license master_username: hogehoge master_user_password: password #Must be at least 8 characters option_group_name: mysql01 db_parameter_group_name: mysql01 db_instance_identifier: mydb db_snapshot_identifier: null source_db_instance_identifier: null tags: - Name: mysql01 ## Security and Network ## availability_zone: ap-northeast-1a vpc_security_groups: subnet_rds db_subnet_group_name: subnet_rds publicly_accessible: false port: 3306 ## Instance and IOPS ## db_instance_class: db.t2.micro storage_type: standard #standard or gp2 or iol iops: null allocated_storage: 5 storage_encrypted: false kms_key_id: null ## Availability and Durability ## multi_az: false ## Maintenance Details ## allow_major_version_upgrade: false auto_minor_version_upgrade: false preferred_maintenance_window: sat:17:00-sat:17:30 backup_retention_period: 5 preferred_backup_window: 16:00-16:30
YAMLファイルは設計書と違いスキーマ構造が明確であるため、
構築に必要なパラメータ項目は確実に定義されることになります。
2)定義書YAMLファイルから設計書Markdownを生成
今までのように、エンジニアがwikiにAWSパラメータ表を記載することはしません。
かと言って、定義書YAMLファイルをお客様と共有するのは無理があります。
そこで、定義書YAMLファイルから変換スクリプトを介してAWSパラメータ表のMarkdownを生成します。（下記イメージ参照）
なお変換スクリプトは、エンジニアのセットアップの手間を省き、
常に最新版を使えるようWEBアプリケーションとして配置しています。
次に、生成されたMarkdownをwikiに貼り付ければAWSパラメータ表の出来上がりです。（下記イメージ参照）
もちろんAWSパラメータ表には、構築に必要なパラメータ値は全て埋まっています。
3)構築はCloudFormationで一気に
自動構築の機構として、今回はCloudFormation（以下、CFn）を選びました。
一般にCFnは、決まった構成を何度も繰り返し構築するケースに向いています。
我々のAWS導入支援サービスはオーダーメイド型であり、CFnが想定するケースとは外れます。
しかしCFnは、構築するAWSリソース間の繋ぎの処理・エラーハンドリングを考慮しなくて良いこと、
構築処理スクリプトを配備しやすい（CFnではテンプレートJSONファイルひとつでOK）ことから、
今回の自動生成方式には向いているとも言えます。
どのようにしてCFn用テンプレートJSON（構築したい内容が詳細に記載されたファイル）を用意するのか。
定義書YAMLファイルからテンプレートJSONを生成します。（下記イメージ参照）
そして、生成されたテンプレートJSONをAWSに流し込みます。
(えーAWSマネジメントコンソール使ってるやん、ていうツッコミはナシで)
数分待てば、設計と全く同じ環境の出来上がり〜。
実は、生成したCFn用テンプレートJSONには、
サーバーワークスの経験上盛り込んでおきたい設定値がはじめから定義済みです。
例えば、cloud-initによるOSの初期セットアップ作業など、推奨の振る舞いが定義されているので、
確実に社内のノウハウを共有することができます。
構築自動化への飽くなき挑戦
さてさて、AWSマネジメントコンソールは素晴らしいツールです。
今回の取り組みで、あらためて見直しましたね。
極めて小さな学習コスト、親切なバリデーション、詳細パラメータ値の隠蔽、、
AWSマネジメントコンソールと同等の構築スピードが出せる仕組みは、並大抵では作れないです。
でもここで諦めると、サーバーワークスの未来はありません。
今回のアーキテクチャに至るまでの紆余曲折、開発・ドッグフーディングの時間を如何にして確保してきたか、
CFnとの格闘（※）といった苦労話は、今回は割愛します。
※CFnの機能制約をどうカバーするかという技術的なお話しは、また別のところで設けたいと思います。
今回お話ししておきたいのは、以下2点です。
良いやり方が見つかれば、この仕組みは捨てる
CFnをベースにここまできましたが、世の中には似たような自動構築のツールは山ほどあるわけですよ。
車輪を再開発している感は否めません。
でもサーバーワークスの導入支援サービスにおいては、
今回ご紹介した構築方法が今はベストだと私は考えています。
はじめからゴールが見えているわけではありません。
今正しいと思う方向へ向かうのみです。
そして、より良い方法が見つかれば、苦労して構築してきた今の仕組みは捨てます。
この潔さはとても大事です。
数カ月後、今回ご紹介した内容と全く違う取り組みをしていたら、順調に歩んでいるんだな〜と捉えてください。
（例えば設計書なしでいきなり構築を行うなど、そもそも仕事の仕方の改革が必要なのかもしれませんね。）
本気で変えたいマインドがあるか？
そして個人的に最も大事だと感じているのが、
自動化の仕組み云々よりも、"現状を打破したいというマインド"です。
慣れたやり方をやめること、新しい仕組み・文化を取り入れることは、誰にでも抵抗があるものです。
どんなに良い仕組みを用意したとしても、使わなければ無意味です。
「今回のプロジェクトはXXXという事情だから、従来のやり方でいく」というスタンスだと、
いつまで経っても変わらないでしょう。
変化しないということに危機感を持てるか
そこに尽きるのではないでしょうか。
最後に
SIにおける自動構築の取り組みは、結果が出ないケースが多いのではないでしょうか。
サーバーワークスは、なぜ自動化の取り組みを推進できるのか。
それは、サーバーワークスにとっては『スピード』が重要な価値のひとつだからです。
「手作業での工数」と、「自動化の仕組みを作る工数」＋「自動作業での工数」を天秤にかけ、
コストメリットがあればやる、、といったことは考えません。
自動化してコストメリットがある作業は意外と少なく、局所的な自動化に留まったり、
機能制約だらけの自動化になったりします。
そして、人手を増やすほうが安いんですよね。
でも、私達は違います。
作業を人手でカバーするようなことは目指しません。
冒頭にご紹介した我が家のガス式衣類乾燥機。
洗濯物を干す工数を費用換算すると、採算が合わないのはのは理解しています。
でも、私は自分の時間を買ったのです。（リースやけどな）
サーバーワークスでも、スピードを得るために投資し、
その仕組にはエンジニアの情熱を注ぎ込んでいます。
クラウドらしく超短納期が求められるプロジェクトも増えてきました。
望むところです。
「え、もう構築できたの？」とお客様を驚かせることができれば幸いです。
※後日談は、こちらの地道にAWS構築自動化に取り組んでいるお話し〜第2話『哀しみのROLLBACK_IN_PROGRESS』〜へ。
そして、こんなサーバーワークスにグッときた貴方をウォンテッド！
