読者です 読者をやめる 読者になる 読者になる

kentana20 技忘録

技術ネタを中心に、セミナー、勉強会、書籍、会社での出来事を綴っていきます。不定期更新。

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

勉強会 ツール インフラ デブサミ

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

エンジニアの方には説明不要という噂もありますが、Developers Summit翔泳社さんが主催する開発者向けのイベントでDeNAGREEMicrosoftOracleといった大きな会社から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日目)

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

2/14(金) (2日目)

  1. やる気を引き出す組織風土のつくり方 by 藤田 晋 〔サイバーエージェント
  2. グリーを支えるデータ分析基盤の過去と現在 by 橋本 泰一 〔グリー〕
  3. IMPACT MAPPING~インパクトのあるソフトウェアを作る by 平鍋 健児 〔チェンジビジョン〕
  4. DeNAにおけるゲーム以外の新規事業の立ち上げ方 by 沖津 貴智 〔ディー・エヌ・エー
  5. エンジニアだからできる
自由な生き方 by 増井 雄一郎 〔ミイル/トレタ〕
  6. 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の自分でもとても楽しいセッションでした。