AWS re:Invent と Immutable Infrastructure

f:id:mirakui:20131114082411j:plain

先日 Las Vegas で開催された AWS re:Invent 2013 に参加してきました。非常に活気あふれる大規模なカンファレンスで、大変刺激を受けました。

今日は、いま何かと話題になっている Immutable Infrastructure に関連した発表を2つ紹介します。

Stop Worrying about Prodweb001 and Start Loving i-98fb9856

slideshare: Stop Worrying about Prodweb001 and Start Loving i-98fb9856 (ARC201) | AWS re:Invent 2013

AWS の Chris Munns 氏による発表です。タイトルからして面白いですね。エモいです。

この発表は以前から目をつけていたんですが、スケジュールの都合で出られず、残念でした。こうしてスライドを見てみるとやっぱり期待通りの面白さがあります。

この発表では、サーバに名前をつけるという行為を「Server Hugging」と揶揄しており、「サーバはペットじゃないんだ」と言っています。

サーバに名前をつけるという行為はもはや古い慣習であり、クラウドネイティブな思考を妨げる足かせになります。

クラウドでは、サーバはソフトウェアのように扱われます。いつでも必要に応じて立ち上げ、不要になれば簡単に削除することができます。そのような状況で、サーバ1台1台に手動でユニークな名前をつけていくことは、オートスケールをはじめとするクラウドの恩恵を失うことになります。

ではどのようにサーバを管理するべきかというと、DNS で名前をつけるのではなく、 EC2 のタギング機能を使ってサーバの属性を記述し、識別するべきである、と述べられています。

感想

Immutable Infrastructure の文脈で、サーバ名について語られているのをまだ見たことがありません。サーバ群を手動セットアップではなく、自動的に作るならば、確かに hostname をどうすればいいのかという問題には突き当たると思います。古典的には、サーバ名はロギングや監視において、サーバを識別するための重要なものとして扱われてきており、多くのツールがサーバ名をあてにしています。真に Immutable な環境を目指すならば、思考をクラウドネイティブに切り替えるだけでなく、そういった環境ごと作り替える必要があるかもしれません。

ちなみに、クックパッドではまさに EC2 インスタンスをタグによって管理しており、そのためのツールも公開しています。

Deploying the 'League of Legends' Data Pipeline with Chef

f:id:mirakui:20131114150107j:plain

slideshare: N/A

この発表は生で見ましたが、とても面白かったです。しかし残念ながら、発表資料は公開後すぐに削除されてしまっているようです。

人気ゲーム "League of Legends" を開発運営している Riot Games の Trotter Cashoin 氏による発表です。発表概要の意訳は以下のとおりです。

この一年、 Riot Games のデータチームは Chef を使って EC2 インスタンスおよび AMI を作成してきました。これまで Chef を用いて、 Data Pipeline 用のインスタンス数千台をオートスケールさせてきた中で、 Chef はオートスケールと短命なインスタンスの世界においては完璧には活用できない場合があることを発見しました。この発表では、 Chef で何がうまくいったか、何が失敗したかについて、また AWS の世界における Chef のベストな活用方法について説明します。

（原文） Over the past year, the data team at Riot Games has been using Chef to both configure instances in Amazon Elastic Compute Cloud (EC2) and build AMIs. With Chef as an integral part of the workflow, we've autoscaled thousands of instances in support of the data pipeline for League of Legends and have found that Chef doesn't always play perfectly in the world of autoscaling groups and ephemeral instances. In this talk, we cover what's worked and what's failed and explain how to best utilize Chef in the world of Amazon Web Services.

この発表では、彼らがデプロイ方法について試行錯誤してきた、 chef-solo や chef-server などを使った方法のメリット・デメリットを紹介していました。

重要なのは、彼らが Immutable Infrastructure を実践しているということです。 Immutable Infrastructure では、サーバを一度セットアップしたら二度と再設定を行わないため、 chef や puppet の特徴である冪等性や、リソースの依存関係を記述する能力は不要です。彼らは chef-server を使って複数人で cookbook を書いて DevOps していたところ、お互いのリソースの依存関係が衝突してしばしば混乱が発生したと述べていました。

chef-solo

cookbook を tar で固めて S3 に上げておき、EC2 インスタンスの起動時にそれをダウンロードして untar し、 chef-solo で実行するというパターンを紹介していました。

メリット
- 速い
- 簡単
- SPOF が無い
デメリット
- サービスディスカバリ（全サーバを把握した上でそのサーバ固有の設定を決める）が難しい
- 設定変更に弱い（Immutable なら良いよね）
- たまにこける（？）

chef-server

彼らはあまり chef-server のことを好きではなさそうでした。

メリット
- （聞き逃した）
デメリット
- rolling deploy に影響が出る
- ロールバックが難しい（特に言及はされていませんでしたが、彼らはアプリケーションコードも chef で配布しているようでした）

複数のアプリケーションを管理している場合には chef-solo より chef-server が向いているという話をしていました。

Golden Images

Golden Images とは、アプリケーションの各バージョンごとに AMI を作り、デプロイ時にはその AMI を立ち上げることで、すぐに望みのバージョンのアプリケーションがサービスインできるという手法を指しているようです。彼らは、EC2 でオートスケールを行うならばこの手法は必須であると述べていました。ただし、サーバ構築のためには chef などのツールを使ったパターンと別途組み合わせる必要があります。 Golden Images パターンを実践する場合には、 Netflix の Asgard, Aminator, Archaius と言ったツールを使うことを推薦していました。