サーバプロビジョニングのこれまでとこれから@デブサミ2014

2/13(木)、14(火) に目黒の雅叙園で開催された「Developers Summit 2014」に参加してきました。

エンジニアの方には説明不要という噂もありますが、Developers Summitは翔泳社さんが主催する開発者向けのイベントでDeNAやGREE、Microsoft、Oracleといった大きな会社からCodeIQやCrowdWorksといったスタートアップベンチャーもスポンサーをしている大規模な開発者向けのお祭りみたいなもんですね。自分は2012年から参加をしていて、今回が3回目です。

f:id:kentana20:20140214183727p:plain

イベントの詳細はこちら。
http://event.shoeisha.jp/devsumi/20140213/
http://event.shoeisha.jp/devsumi/20140213/timetable/

参加したセッションは以下のような感じです。

2/13(木) （1日目）

サーバプロビジョニングのこれまでとこれから by 宮下剛輔〔paperboy&co.〕
グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～ by 荒井良太〔グリー〕
テスト自動化を見直そう！自動化への投資が開発チームをクリエイティブにする by 安竹由起夫〔コベリティジャパン〕
社内システムの構造と設計、実装のはなし by 田籠聡〔LINE〕
成功と失敗の狭間に横たわる2つのマネジメント by 中村洋〔DevLOVE関西〕
Mobageを支えるテストエンジニアリング by 中川勝樹〔ディー・エヌ・エー〕
何故クックパッドのサービス開発は日々進化しているのか by 庄司嘉織〔クックパッド〕

2/14(金) （2日目）

やる気を引き出す組織風土のつくり方 by 藤田晋〔サイバーエージェント〕
グリーを支えるデータ分析基盤の過去と現在 by 橋本泰一〔グリー〕
IMPACT MAPPING～インパクトのあるソフトウェアを作る by 平鍋健児〔チェンジビジョン〕
DeNAにおけるゲーム以外の新規事業の立ち上げ方 by 沖津貴智〔ディー・エヌ・エー〕
エンジニアだからできる 自由な生き方 by 増井雄一郎〔ミイル/トレタ〕
Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所 by 吉村総一郎〔ドワンゴ〕

盛りだくさんな内容なので、印象に残ったセッションをいくつかピックアップして複数回のエントリに分けて書こうと思います。本日は初っ端のペパボ宮下さんのセッション。

サーバプロビジョニングのこれまでとこれから

Future of Server Provisioning at Developers Summit 2014 // Speaker Deck

paper&boy テクニカルマネージャ宮下さんのお話。paper&boyは @shbt こと、柴田さんの記事などは見る機会があって知っていましたが、serverspecの開発者さんが所属されているとは知りませんでした。完全に勉強不足です。。宮下さんはテクニカルマネージャという肩書でpaper&boyではエンジニアの中で最も職位が高い役職のようです。発表内容は下記。

サーバプロビジョニングとは

サーバプロビジョニングは

orchestration : アプリケーションのプロビジョニング（capistrano, fabricなどのデプロイツール）
configuration : システム構成のプロビジョニング（chef, puppetなどの構成管理ツール）
bootstrapping : OSのプロビジョニング（vm, container, cloudなど）

の3つのレイヤーに分けることができる。

bootstrappingはサーバに対してCobblerで設定情報を外部から読み込んでOSをクリーンにインストールする。EC2、CloudStack、OpenStackなど。
configurationはいわゆる今流行りの構成管理ツール。Chef、Puppet、Ansible、Shellとかで実施。
orchestrationは概念の説明が難しいそうですがcapistrano, fabricなどを使ってアプリケーションのデプロイを自動化するというイメージでしょうか。

Infrastructure as a Code

言葉自体は2008年頃から登場していて、もっと前の2006年にPuppet LabsからPuppetが登場した。源流は1993年に登場したCFEngine。Infrastructure as a Codeとはコードを使って「サーバリソース」「アプリケーションデータ」「ソースコード（レポジトリ）」を用いて、ゼロからアプリケーションの動作環境を再構築できるようにすること。

テスト駆動インフラ / インフラCI / Github Flow

テスト駆動インフラ

Rubyの盛り上がりによって、Chef(Ruby)が注目を浴びているが、みんなが使っているわけではない。そこでserverspecを作った。テスト駆動インフラはインフラを駆動するのではなく、動かすサーバの設定情報で駆動する。serverspecの位置付けはインフラの状態をチェックするためのものではなく、インフラの状態を記述した「コード」をテストする仕組み。

インフラCI

serverspecでテストを書いて、CI（Jenkins, Wercker）を回している。

Immutable Infrastructure

動いているサーバには手を加えずに変更を反映する（AWS Re:Invent 2012で発表されたBlue-Green Deplymentという考え方）。現在稼働しているサーバ群をもう1セット用意し、新しいサーバ郡に新しいアプリケーションをデプロイしてロードバランサで切り替えてリリースとし、異常がなければ古いサーバ群をTerminateする。オンプレではなかなかできなかったことがIaaS（というかAWS EC2）の普及によって可能となった。変更を加えてトラブルが起こると、変更を行うことに対して躊躇してしまうので、変更を加えることに対する恐怖を減らすためにこういった考えが生まれた。この考えによってリリースへの恐怖がなくなり、継続的な改善を行いやすくなった。
Immutableにできない部分（消せないデータがあったりとか）はケース・バイ・ケースでやっていくしか、今のところはない（現状の課題と言える）

Container Base Deployment ←個人的にかなり刺さった部分

f:id:kentana20:20140215120603p:plain

コンテナとは軽量・単機能なVMと定義しておく。コンテナをまるごとアップロードして差し替える（サーバを切り替えるのではなく、同一サーバのListenPortを切り替えるだけとか）という方式。Dockerのポータビリティがそれを可能にした。ポータブルなので、ローカル・ステージング・プロダクションと環境を選ばずに動作する（これ、めちゃ良いと思いました）ので、十分にテストしたコンテナをそのままリリースできる。また、その他のメリットとして

1コンテナ1機能でシンプルサーバ内の構成管理を行うことで継続的改善がしやすくなる
単機能にすればテストもしやすい
IaaSを使わなくても、VM上でBlue-Green Deploymentが可能

なども挙げられる。超便利ですね。

Serf （新しいorchestration）

vagrant, packerの開発者が作ったオートスケールを加速させそうなプロダクト。複数ノードがLB配下にある状態で、ノードが追加されると追加イベントがLB、モニタリングツールなどに通知され、LB配下（監視配下）に組み込まれる。もちろん、削除や故障などにも対応できる。

まとめ

テスト駆動でインフラ構築
インフラCIで継続的インフラテスト
コンテナを活用してBlue-Green Deployment
Serfでorchestration

所感

2012年から参加しているデブサミですが、2013年のコンセプトだった「Action!」に対する「Story」というテーマで各社それぞれのアクションについてお話をされていました。一休もStoryを作って発表しに行きたいですが、まずはもう少し小さめのイベントで発表をすることが目標ですね。
paper&boyさんは色々な勉強会でも発表を目にする機会がありますが、Dockerなどの先端技術もしっかりとキャッチアップして導入を検討されているな、という印象を受けました。また、Dockerの件はかなり個人的に刺さったので（もともとVMが好きという話もある）、コンテナを使ったBlue-Green Deploymentを実際に試してみたいなと思いました。インフラレイヤー色が濃い発表ではありましたが、Devの自分でもとても楽しいセッションでした。