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

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

IT

期待通り、面白い話だったのでメモを残しておく。

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

  • 宮下 剛輔 氏
    • mizzy
    • @gosukenator
  • paperboy&co.
    • テクニカルマネージャ

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

プロビジョニングは3つのレイヤがある。

  • orchestration
    • application service orchestration
  • configuration
    • system configuration
  • bootstrapping
    • cloud or vm image launch
    • os install

あまり厳密に捉えすぎる必要はない。とのこと。

Bootstraping

今日は割愛

Configuration

  • ミドルウェアのインストールとか設定とか
  • いわゆる構成管理ツール
  • CFEngine, Puppet, Chef, Ansibleなど

会場は、Chef利用者多数っぽい。Puppetは少。

Orchestraion

インフラの概念と共に意味が変わって来ている。
詳しくは後で。

Infrastructure as Code

インフラをアプリケーション開発のようにコードで記述する。
この言葉が出始めたのはおそらく2008年ぐらい。

  • Puppet Next-Generation Configuration Managementという論文にも近い内容が記載。
  • 源流は1993年登場のCFEngine
  • 構成管理の4つの宣言
    • 宣言的「何をしたいかであって、どうするかではない」
    • 抽象化「あなたの代わりに詳細の面倒を見てくれる」
    • 冪等性「必要なときだけ実行する」
    • 収束化「放っておけばどうにかなる」

Infrastructure as Codeとは

  • ソースコードリポジトリ
  • アプリケーションバックアップ
  • サーバリソース

これらをゼロから再構築できるようにすること。
サーバ構築・運用におけるワークフローに変革をもたらすもの。

Infrastructure as CodeかたTest-Driven Infrastructure

  • テスト駆動インフラはChef周辺が盛り上がっている
  • Test-Driven Infrastructure with Chefという書籍もある
  • Test KitchenというツールもChef界隈から出てきている
  • Infrastructure as Codeを推し薦めてきたのがChef
  • Puppetに比べて、よりRubyっぽく記述できる
  • IaaSの台頭により、アプリ開発者がインフラを触れる機会が多くなってきた背景

みんながみんなChefを使っているわけではない。
そこで作ったのがserverspec。
serverspecの詳細は、WEB+DB PRESSのVol.76で！

テスト駆動インフラが駆動するのはインフラそのものではなくインフラを記述したコードを書くこと

テスト駆動インフラによるリファクタリング対象は、インフラの状態を記述したコード
インフラの状態を記述した「コード」をテストするためのツール

インフラCI

  • インフラのコードかとテストの自動化ときたら次はCI
  • ペパボはserverspecでテスト書いてJenkinsでまわしている
  • サービス例としてはとしては、WerckerとかTravisとか。今ホットになってきている

GitHub Flowによるインフラワークフロー

GitHub Fがインフラにも適用できるんじゃないか？ペパボでも取り組み始めている。
puppetマニフェストとかも、プルリクベースで。

Immutable Infrastructure (Disposable Components)

  • ImmutableよりもDisposableの方がむしろ重要
  • Immutableは不変という意味
  • 動いているサーバには変更を加えない
  • まったく新しくサーバを構築してロードバランサ等で切り替え
  • 成功したら元のサーバは「破棄」
  • Blue-Green Deploymentという名でも以前からテクニックとして存在する

Immutable Infrastructureでは

  • 変更に伴うトラブルが起こりにくい
  • 継続的改善がしやすい
  • 設計へのよい影響 "The Twelve-Factor App" / IX. Disposability
  • ChefやPuppetのようなツールがよりシンプルになる
    • 冪等性や収束化に従うために複雑になりがちだが、クリーンインストール前提だと考慮が少なくなる

Immutableにできないところ(永続的可変データを持つところ)はケースバイケース。
こういうところは、S3とかRDSのような外部に委ねるのも1つの手。

Container Base Deployment

  • コンテナ？＝単機能・軽量なVM (とここでは便宜上定義)
  • コンテナをまるごとアップロードして差し替えること
  • Dockerの持つポータビリティによって実現可能性が高まった
  • ポータブルなのでローカル環境と本番環境で同じ環境が使える
  • つまりローカルで十分テストした後に、そのままでプロイすることができる
  • テスト駆動 -> CI -> デプロイ
  • 1コンテナ1機能と単純化して、サーバ部品のコンポーネントして扱う
  • コンポーネント化が進むことで個別に差し替えやすくなるので継続的改善がしやすくなる
  • 単機能かにより、テスタビリティも向上
  • IaaSじゃなくてもBlue-Green Deploymentができる
  • 今後、Mesos/YARN等の組み合わせで自動的なリソース配置最適化もできるようになってくる

Orchestration

  • Configuration
    • 単一のサーバで完結するもの
      • Apacheのインストール設定など
  • Orchestration
    • 複数のサーバが関連するもの
      • ロードバランサへのノード追加
      • muninやnagiosへのノード追加
      • アプリケーションデプロイ

旧来のOrchestraion

  • Immutable Infrastructure前提ではない世界
  • サーバの増減が頻繁ではないので、Configurationの領域でもやれてしまう
  • Command & Control

新しいOrchestraion

  • Immutable Infrastructure前提の世界
  • サーバの増減が頻繁なので、Configurationでの対応はきつい
  • Autonomy/自律協調

Serfの登場

  • ノードが追加されたら、＊＊にノード追加が実現できる
    • 例: ロードバランサ、監視ツール等
  • 特徴
    • ノードのクラスタリング
    • ゴシッププロトコル
    • イベントプロパゲーション

SerfでやれることやるべきことをOrchestrationと捉えるとわかりやすい。
それによりOrchestration/Configurationの区別が明確になる。
OrchestrationをSerfに任せるとConfigurationがシンプルにできるかも。

追記: 資料が公開されました

rx7 読者になる

関連記事
コメントを書く