べにやまぶろぐ

技術寄りの話を書くつもり

デブサミ2014 「サーバプロビジョニングのこれまでとこれから」 のメモ #devsumi

セミナー・勉強会 デブサミ2014

serverspec 開発者の 宮下 剛輔 (id:MIZZY) さんの発表。サーバプロビジョニングについて体系的にまとめていてくださって大変参考になった（講演概要 | 発表資料）。

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

  • ３つのレイヤ : Bootstrapping, Configuration, Orchestration

Infrastructure as Code

  • インフラをコードで書く、開発する
    • 2008年くらいから Chef の開発者のスライドで使われ始めており、Puppet については 2006年に USENIX に論文が出ている。源流は 1993年の CFEngine。
    • ソースコードレポジトリ、アプリデータのバックアップ、サーバリソースからビジネスをゼロから再構築できる
    • サーバ構築・運用におけるワークフローに変革をもたらすもの
    • Infrastructure as Code から Test-Driven Infrastructure（テスト駆動インフラ） へ
  • みんなが Chef を書けるわけではないので serverspec を作った
  • テスト駆動インフラが駆動するのはインフラそのものではなくインフラを記述するコードを書くこと
    • アプリケーションのコードを書くことを駆動するのが TDD
    • テスト駆動インフラがテストする対象はインフラの状態そのものではなくそれを記述したコード
      • serverspec はインフラの状態をテストするためのツールではない（そう使っても良いには良い）
  • インフラのコード化とテストの自動化ときたら次は CI
    • Wercker など
    • GitHub Flow によるインフラワークフロー
      • GitHub への pull request から Jenkins が走る、テストが通るとマージができるようになる

Immutable Infrastructure (Disposable Components)

  • ブログエントリー(これかな？)がきっかけ
  • Immutable より Disposable であることが重要
    • 動いているサーバーには変更を加えない (immutable infrastructure)
    • まったく新しくサーバを構築してロードバランサで切り替え
      • その後破棄、または元に戻す (2012 AWS re:invent)
    • 昔から Blue-Green Deployment としても知られている
    • EC2 のような IaaS によってこういうことが容易になってきた
  • メリット
    • 変更に伴うトラブルが起こりにくい
    • 継続的改善がしやすい
    • 設計への良い影響 (参考: The Twelve-Factor App IX.Disposability) : スケーラブルしやすいし、堅牢になる
    • Chef や Puppet のようなツールがよりシンプルになる
      • クリーンインストール前提であればよくわからない状態から任意の状態に収束させることを考慮する必要はない
    • 永続的ではない可変なデータをどう扱うか？ -> ケースバイケース

Container Base Deployment

  • コンテナ = 単機能・軽量な VM
  • コンテナをまるごとアップロードして差し替える
  • 同一サーバー内で複数コンテナを立ち上げて切り替える (LBで切り替え)
  • Docker の持つポータビリティによって実現可能性が高まった
  • ポータブルなのでローカル環境と本番環境で同じものを使える
    • ローカルで十分テストした後にそのままデプロイできる
    • テスト駆動 -> Ci -> デプロイ
  • 1 コンテナ 1 機能と単純化し組み合わせて使う、サーバ部品のコンポーネント化できるようになるのではないか？
    • 単機能化することでテスタビリティも向上するのでは？
  • IaaS 上でなくても Blue-Green Deployment ができる
  • Mesos/YARN などとの組み合わせで自動的なリソース配置最適化もできるのでは。

Orchestration

  • Configuration が単一のサーバで簡潔するものに対し、 Orchestration は複数のサーバが関連するもの
    • ロードバランサ、Munin/Nagios へのノード追加、アプリケーションデプロイなど
  • 旧来は Immutable Infrastructure 前提ではなく、サーバの増減が頻繁ではないので Configuration でもやれてしまう (Command and control : 指揮者が全てをコントロール)
  • Immutable Infrastructure 前提だと Configuration 領域での対応は厳しい、Autonomy/自律協調が重要
  • SERF の登場 (Vagrant/Packer 作者 Mitchell Hashimoto 氏作)、ただし現状は実用レベルではないらしい。。
    • ノードが追加されたら自動で Munin に追加など
    • 自分で作りこまないといけないのが現状
    • SERF でやれることやるべきことを Orchestration と捉えたらどうか？

所感

初めて宮下さんのお話を聞いたけど、こうやって周辺分野や技術の発展プロセスを体型立ててまとめられる方って非常に貴重だと思った。良い意味でアカデミックな匂いも感じて、現職に就いてから目の前のことだけこなすのに夢中になっていたような感じがしてこういう流れを作りだせる側に回らないといけないと反省。

あとは、serverspec を異常検知の方法に使うことは否定しないものの、インフラを記述するコードを書くことを駆動するのが主目的とおっしゃっていたのが印象に残った。何も考えないで Vagrant x Chef x Jenkins x serverspec とかで回していたけど、Infrastructure as Code の視点では TDD のためのツールなのだと改めて理解。

またこれまで Chef しか使ってこなかったけど結構いろいろあるとわかったので後で調べる (参考 : Review: Puppet vs. Chef vs. Ansible vs. Salt)