工場長のブログ

日々思ったことを書いてます。

CloudFormationとChefを使って拡張Stampパターン

こんばんは!
今回はCDP Advent Calendarへの投稿です。
今日はStampパターンの拡張の話について書いてみます。

きっかけは「MongoDBのクラスタがAMIくらいお手軽に試せたらいろいろ触ってみるんだけどなぁ」という声を頂いたこと。

はじめに
今回やってみるのは、タイトルの通りだけどCloud FormationとChefを使ってMongoDBのクラスタをデプロイしてみるということ。いろんなサードパーティーベンダーさんが提供している彼らの製品が乗っているAMIのごとく、さっとクラスタをデプロイして、ベンチして、終わったら捨てる、みたいなことができることを目指します。

まず、Cloud Design Patternには、Stampパターンというのがあって、AMIという仮想マシンのイメージを使って同じ構成のサーバーを、あたかもスタンプを押すように複製するデザインパターンです。

更に、CloudFormationでシステムスタックをデプロイするStack Deploymentパターンというのもあって、今回の話はこれと似ています。というか技術的には変わりはありません。

じゃあ何が違うのかというと
f:id:imai-factory:20121222200235p:plain
Stack Deploymentパターンでは、こんなかんじで、どちらかというとLBがあって、WEBサーバーがあって、DBがあって、みたいな一連のシステムスタックをデプロイの対象としている感じ(あくまでイメージであって、厳密な定義はありません)。今回はこういうのではなくて、イメージ的には
f:id:imai-factory:20121222200916p:plain
こんなかんじで、一つのアプリケーションのクラスタ(MongoDBとかMySQL Cluserとか)をAMIみたいに簡単に取り扱いたいということ。もっというとこんな感じ
f:id:imai-factory:20121222210825p:plain
外からみたら一台に見えるところを目指します。ということは、複数の役割(マスタやスレーブなど)のサーバーから成り立つクラスタであっても、例えばベンチ&チューニングをする際に、いちいちそれぞれのサーバーにログインしてコンフィグ修正して再起動して・・・みたいなことはしたくないよね。APIのエンドポイントも設定のチューニングも一台のサーバーで完結するようにしたい。

何をするのか
ということで、今回はこういうものを作ってみようと思いました。
#ちなみに実装が間に合ってなくて、今回はお話だけです。。。。orz
f:id:imai-factory:20121222230716p:plain
箇条書きで説明するとこんな感じ

■起動Procedure

  1. CloudFormationでManagement Hostを起動。ここで受け取る入力は以下のとおり。
    • Instance Type, Shard数, ShardごとのReplica set内のホスト数, DBファイルの格納パス
  2. Management HostがCloud Formationを使ってconfig serverとmongosを起動。
    • このときInstance TypeとDBのディレクトリを渡してそのとおりの設定でサーバーを起動する。
    • また、サーバーのRole(config, mongos)をuserdataで渡す。
    • 立ち上がったサーバー群はgitとchef-soloをインストールしたあと、githubからchefのcookbookを取ってきて、渡されたroleにしたがって自分を構成する
  3. Management Hostが今後はShard nodeをCloud Formationで起動
    • だいたい上と同じ操作が実施される。
    • ひとつのCloudFormationでは、ひとつのShardだけを作成する。指定されたShard数の分、この操作は繰り返される。
    • Replica setで指定された台数を起動するのには、Auto Scaling Groupを利用する。
  4. 指定されたShard数のぶん、3を繰り返す

■その他備考

  • AMIはすべて素の状態で利用。chefとgit、それからuserdataだけで自己構成される。
  • すべてのホストは起動時にgitとchef-soloがインストールされる
  • まだ実装までちゃんと考えてないけど、github側のアップデートと同時にchef-soloを使って各種設定ファイルなどをデプロイしなおせるようにしたい。
  • これもまだ実装はちゃんと考えてないけど、Management Hostのterminateにhookして、子供のCloudFormation Stackを削除するようにしたい。

そうすると・・・
という感じ。これがちゃんと動くと、以下の様な機能が実現されます

  • 台数とハードウェアスペックを指定して簡単にMongoDBのクラスタを起動する
  • 検証などして、終わったらスタックをまるっと捨てる

EMRでHBaseを動かすみたいなイメージですね!
こうなると、以下の様なことができるわけですね!

  1. 来週からクリスマスとお正月でサイトのアクセス数が激増する!!!時間がない!!!!
  2. 拡張Stampパターンを作って複数の条件でMongoDBのクラスタをサクサクつくって、どれくらいの規模のクラスタつくればいいか検証!
  3. 規模感がわかったら検証用のクラスタはぜんぶ綺麗にすてちゃう。
  4. で、最後に本番用のクラスタをつくって本番に備える
  5. 割りと複雑な検証がサクサクやれたのでなんとか本番間に合ったぜ!

まとめ
・・・と、そんなにうまい話になったらいいですが、せっかくサーバーの調達が簡単なクラウド環境があるのでもっとカジュアルにクラスタアプリケーション動かしてみようぜというお話でした。ただし、CloudFormationとChefを使う以上、ある程度の柔軟性は犠牲にしています。なので、どちらかというと本番向きではなく、あくまで機能や性能検証、もしくは開発環境向けかなーと思っています。Chefは本番でも使えると思いますが、おそらく本番はより柔軟な設定ができるようなChefの組み方が必要になると思います。

まあとにかく、まだ実装できてないので、冬休みの宿題で作って見ることにします!
#どこかの会社も、まずはプレスリリースから出すっていうしね。
#MySQL Clusterとか、他のクラスタアプリケーションへの対応もそのあと考えます。