CloudFormationで【パラメータのみ】のアップデートが可能に!

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

よく訓練されたアップル信者、都元です。むしろCloudFormation信者かと自問する日々が続いておりますがw

育てるインフラ

クラウドの売りの一つは「スケーラビリティ」です。これは単純に、HTTPリクエスト処理要求の増加に伴ってWebサーバの数を増やすだけの話ではありません。昨日ご紹介したように、ロードバランサ、キュー、ワーカー、そして(RDSであれば限定的ですが)データベースのように、システム内の各コンポーネントについて、スケールアウトできる構成が期待されます。

しかしそれだけでもありません。システムというのは運用しながら、キャパシティ要求だけでなく、機能要求の増加にも応えていく必要があります。単純なスケールアウトだけではなく、必要に応じてコンポーネントの追加 *1を行い、場合によってはアプリケーションの改修を伴うアップデートを行います。

そんな時にも、実はCloudFormationが大きく活躍します。CloudFormationと言うと「1回テンプレートを作っておけば同じ環境を何度でも作れます」と説明されることが多いと思います。しかし、1個しかつくらない環境に対しても、CloudFormationは有効です。

CloudFormationにおいて、テンプレート *2に基いて構築した実際に動くコンポーネント群のことをスタックと呼びます。そしてスタックは、「元のテンプレートを書き換えたもの」でアップデートができます。それがUpdate Stackです。アップデートリクエストを受け取ると、CloudFormationは「現在の状態」を「新しい状態」に更新します。つまり、削除された(要らない)コンポーネントがあれば消しますし、パラメータが変わっていれば書き換えます。書き換えができないパラメータ *3が変更されていた場合は、古いコンポーネントを消して、新しいコンポーネントに置き換えます。置き換えたことにより波及する他のコンポーネントへの影響 *4も自動的に吸収してくれます。

というわけで、CloudFormationテンプレートをgit等で構成管理し、アプリケーションと同時に管理することによって、インフラの変遷を全て記録していくことができるようになります。これは、クラウドインフラの進化的設計という仕組みの礎となります。

オペレーションの簡素化

構成の変化に追従するためにCloudFormationが使えることがわかりました。が、もっと小さいところで、オペレーションの簡素化にもCloudFormationが活躍します。例えば、Webサーバのインスタンスタイプや、スケールアウトで横に並べる数などは、進化ではなく運用のフェーズでも変化するものです。このような変化が起こるたびにテンプレートを書き換えて、アップデートを行うのは大変です。

このような「インスタンスタイプ」や「インスタンス数」などは、CloudFormationテンプレートのパラメータとして定義して、テンプレートの外から値を受け取るようにしておきます。具体的には、【AWS】VPC環境構築ノウハウ社内資料 2014年4月版でご紹介したテンプレート https://gist.github.com/miyamoto-daisuke/10446903を御覧ください。

このようにしておくことで、運用担当者はテンプレートの中身に触れず、パラメータを更新するだけでスケールの調整ができるようになるわけです。とりあえず、開発時のテンプレートアップデートに対して、これを本エントリーでは「運用アップデート」と呼びます。

本日のCloudFormationアップデート

なんていう論述をつらつらと書いて参りましたが、実は本記事はアップデート速報ですw 先ほどCloudFormationに嬉しいアップデートがありました。

従来、前述のような「運用的アップデート」を行う際にも、毎回テンプレートを指定する必要がありました。運用担当者が、常に最新のテンプレートをローカルに持っておいて毎回アップロードを行うか、まはた、最新のテンプレートを指し示すS3上のURLを把握しておく必要があったのです。

が、本日からは「Use existing template」を選択するだけで大丈夫です!

ぉぉ。これは便利ですね。 アドレスを辞書登録して、毎回変換して入力していましたw

このアップデートをいち早くお伝えしたお客様の声

では、簡単に手順を見ていきましょう。アップデートの例として、先ほど↑でご紹介したVPCノウハウのテンプレートを使います。このテンプレートで、まずはスタックを作っておきます。(この手順は省略しますね)

2014-05-13_1113-1

下記の通り、Webサーバは2台で構成されています。(もう一台は踏み台)

2014-05-13_1113

このスタックを選択して「Update Stack」ボタンをクリックすると、下記のような画面になります。ここに「Use existing template」が出てきたのが嬉しいアップデートです。しかもデフォルトで選択状態になってますね! というわけで、これを選んだまま「Next」です。

2014-05-13_1113-2

次に現れるのがパラメータ設定画面です。既存の値がリストアップされています。ここでは、Webサーバの台数(WebFleetSize)を2から4に変更してみました。また、DBPasswordはNoEchoとして表に表示されないようにしているため、既存の値が何なのか分かりませんが、これは直下の「Use existing value」にチェックをしておくことで「変更しない」ことを指定できます。運用担当者がパスワードを知らなくても困りませんね。

2014-05-13_1115

その他、変更したいパラメータをいじって *5、あとは「Next」連打です。操作が終わると、スタックのステータスが「UPDATE_IN_PROGRESS」となりました。今頑張って変更適用中です。

2014-05-13_1115-2

EC2の管理コンソールを覗いて見ると、新しいインスタンスを増やしているのが見てとれます。

2014-05-13_1116

最終的に、スタックのステータスは「UPDATE_COMPLETE」となり、運用アップデートが完了します。

2014-05-13_1135

変更が思い通りに適用されていることを確認してみてください。

まとめ

いや、CloudFormationいつ使うの!? いm

脚注

  1. 例えば、S3のバケットを増やしたり、新たにCloudFront Distributionを配備したり。もっと小規模だと、DB等既存のコンポーネントのパラメータを変えるだけだったり。
  2. これ自体は動かない、ただの "記述" です。
  3. 例えばEC2インスタンスのキーペア名など。
  4. 例えばそのインスタンスについていたEIPの付け替え等。
  5. 興味のあるかたはWebInstanceTypeを変えてみてもいいでしょう。