[セッションレポート]Infrastructure as Code – CloudFormationの活用 #reinvent

[セッションレポート]Infrastructure as Code – CloudFormationの活用 #reinvent

Clock Icon2014.11.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

この記事は AWS re:Invent 2014、ARC307-JT - Infrastructure as Code - Japanese Trackのレポートです。

スピーカーはAWSのDevid WinterとAlex Corley、そしてSimple.comのTom Wanielista。

DSC_0016

レポート

DSC_0013

David Winter。

DSC_0017

AWSの前はテキサスの会社でSASアプリケーションの構築を行っていた。 様々なクラウドオプションを検討した結果、AWSに辿り着いた。 そして私はAWSが好きになり、SASアプリケーションの構築をすぐに実験できるようになった。 そして手作業でシステムを構築し始めた。しかしこれではスピードが出ない。

DSC_0018どうしたらいいのか?bashスクリプト(+AWS CLI)によって構築を始めた。手作業と比べるととても効果的。

DSC_0020

その後サービスが成長し、様々なアイデアが生まれた。 Alexが入社し、bashスクリプトをPythonスクリプト(+AWS SDK)に変換した。

DSC_0021

これは素晴らしいものだった。いいものだと思った。しかし悪い事態が...失敗が発生した。 なにか?1つは私はAWSのセキュリティホワイトペーパーを読んでおらず、スクリプトにACCESS KEYを埋め込んでしまっていた。 もう1つ。ある日、サイトへ全くアクセスできなくなってしまった。 様々な調査をした結果、一つの示唆があった。 「セキュリティグループはちゃんと設定されているの?」 そう、セキュリティグループの設定が失敗しており、サイトへのアクセスが全部遮断されてしまっていた。

私たちは是正措置を考えた。まずは管理者権限を渡さないということ。 もう1つ。私たちはVPCなどは手で、PyhonスクリプトでEC2などのインスタンスを作っていた。 しかしこれでは手間がかかる。そこで全てをコード化した。 私たちはインフラストラクチャをコードにしたことで、全てを管理者が管理できるようになった。

Grace Hopperについて。有名な海軍の女性将軍。コンピュータサイエンスでもある。 彼女の有名な言葉がある。「We've always done it this way」 開発、構築、運用。これらは大抵協業せず、責任を押し付け合ってしまう。 このような縦割りがあると皆が不満に思ってしまう。 私は提案したい。インフラを全てコードにしAWSにしてしまえば、新しい働き方が出来る。 みんなが幸せになれる。

ここでAlexから、CloudFormationについて紹介してもらう。

Alex。Infrastructure as Code。全てをコード化することで複雑なシステムのデプロイ、アップデートが簡単になる。 私たちに必要なのは、何がどうなっているべきか、という定義。 CloudFormationを使うというのはAWSのリソースを使う理想的なやり方。 CloudFormationを使うにはJSONにするだけ。JSONにすれば操作は誰にだって出来るようになる。 インフラをコード化することで何が出来るか?バージョンコントロールが出来る。リポジトリ管理が出来る。 ソフトウェアのlife cycleでインフラを管理できるということ。 また同じコードを使って瞬時にインフラを拡大出来る。離れた地域にも同じインフラを一瞬で作れる。 複数のテンプレートをチェーンにすることもできる。自分で並列な操作をプログラムにする必要はない。 テンプレートをカプセル化して、ネットワーク、コンピュート、ストレージに分けることもできるし、 Dev環境、Stage環境、Prod環境を分けることもできる。とてもシンプル。

Simple.comのTom。新しい銀行のサービス。最初からAWSで構築した。Infrastructure as Codeを実現している。 Simpleが一番最初に創業したときは、全てのAWSリソースを手作業で作っていた。 しかしサービスが拡大し、色々な機能が増え、エンジニアが増えると、手作業では限界が出てきた。 私たちはPCIを取得する必要があったので、どうしたらいいのかを考えた。これは苦難では無くチャンスだと思った。 そこで4つの観点が重要だと気付いた。Security、Insight、Growth、Speed。 結果、CloudFormationで全て実現できると気付いた。

DSC_0024

しかし更に一つレベルを上げる必要があった。 私たちはpyhonでcloudbankというツールを作った。これは非常に重要なツール。 cloudbankにシンプルなコードを書けば、あとはCloudFormationが全てうまくやってくれる。便利。

DSC_0025

Infrastructure as Codeにはどういったメリットがあるか?一目瞭然。毎日コードを書くだけでいい。 コードを見れば何が起きているのかわかる。テストも出来る。接続試験も出来る。 コードはプログラマブル。新しい問題、新しい課題が出た場合にもコードで対応出来る。 最も重要なのは、コードというのは慣れているということ。なんでもコード出来る。とても楽。

最後にAlexからデモ。 Unit Testで問題ありとなっているものを、コードを書き換えることで青くなっていく。 コードになっているのはWebコンテンツ、CloudFormationなど。 CloudForimationはgit commitすることでShell Scriptが自動的に実行され適用される。

DSC_0027

デモでやったことは? 問題を発見し、問題を修正し、本番にpushする。スタンダードな手法を使ってバグを直す。 一般的なアプリケーション開発手法でインフラの問題を解決出来る。

DSC_0028

CloudFormationは何のために、誰のためにあるのか?スタートアップ?エンタープライズ? 全てです。どちらにでも適用出来る。どちらにとっても問題解決の手法になる。 スタートアップでは、素早く、デベロッパーライクにインフラを構築出来る。 エンタープライズにとっては、たくさんのシステムを移行する際にテンプレート化することで簡単にデプロイできるようになる。同じような構成を適用できる。

DSC_0029

私たちはこの仕組みを推進していきたい。

DSC_0030

まとめ

クラスメソッドではCloudFormationを活用し、必要に応じてお客様に提供しています。弊社の考え方がAWSの考え方と一致していることが確認できたセッションでした。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.