My External Storage

ソフトウェアエンジニア向けTips。Qiitaにもメモ

Developers Summit2014 [13-B-1] サーバプロビジョニングのこれまでとこれから

[13-B-1] サーバプロビジョニングのこれまでとこれから

宮下剛輔氏

アプリケーションをのせるための、OS以上のレイヤーの話。

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

Orchestration, Configuration, Bootstrappingという3レイヤーで考える。

  • Bootstrapping OSインストールを指すレイヤー。
  • Configuration ミドルウェアレイヤー
  • Orchestration システム全体をサービスとして動かすレイヤー。概念的に難しいので、このレイヤーおおざっぱな認識で良い

Bootstrapping

Bootはスコープ外なので今回は割愛

Configuration

このレイヤーをプロビジョニングと指すことが多い。Chef、Puppetなどの構成管理ツールを利用するのが最近の流れ。

Orchestration

広範囲を占めるので後述。

Infrastructure as Code

インフラ構成のコード化。2008年ほどからChefの製作者などが使い始めた。
源流は1993年登場のCFEngine。

CFEngineにより提唱された構成管理の要件

  • 宣言的　「何をするかを記述して、具体的なことは記述しない」
  • 抽象化　
  • 寡等性　「常に同じ結果が得られるか」
  • 収束化

ビジネスをぜロから再構築できるようにすることがInfra as Code
サーバ構築・運用におけるワークフローに変革をもたらすもの

テスト駆動インフラへ

コードで記述されることでアプリ開発と同じようにインフラ構築もできるようになった。

Chefがらみから流行ってきた。オライリーから書籍も出ていて、Test Kitchenというテスト・ツールも出てきた。

Chefが更に「コードでのインフラの記述」を推し進めた。
Chefは独自言語ではなくて、Rubyで記述できるのが大きい。
AmazonEC2などの台頭で簡単にインフラを構築、破棄できるようになった環境の影響も大きい。

みんながみんなChefを使っているわけではないので、SeverSpecを作った。JTF2013などの資料を見れば詳細が乗っている。

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

よってリファクタリング対象はインフラの状態を記述したコードであってインフラそのものではない。
インフラの状況をテストするという解釈を宮下氏はしていない。インフラの状態を記述した「コード」をテストするためのツール

インフラCI

コード化、テスト自動化ときたら次はCIでしょ！

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

GitHubとCIツールを連携して表はレビュー、裏でテストを通す。Github上なので、テストやレビューをクリアできていれば、そのままマージ。

Immutable Infurastructure(Disposable Components)

ブログエントリがきっかけになって話題になったワード。
ImmutableよりもDisposableのほうが重要と考える。

動いているサーバには変更を加えない(Immutable)
→全く新しいサーバを構築してロードバランサ等で切り替える。
うまく切り替え成功したら元のサーバは「破棄」。失敗したら元のまま。
ロードバランサによる切り替えはimmutable...という言葉が出る前に存在した手法。（Blue-Green Devlopment）
EC2のようなIaaSによってこのような運用が容易に。

メリット　変更に伴うトラブルが起こりにくい。新規のサーバで１から構成するのでトラブルが起こりにくい。
メリット　継続的改善がしやすい。トラブルばかりだとビビるようになる。トラブルが発生しにくいので、変更しやすい。
設計への良い影響は「The Twelve-Factor App IX. Disposability」9章を参照すること。

メリット　ChefやPuppetのようなツールがよりシンプルになる。
クリーンインストール前提の構築になるので、構成がシンプル、
もっと言えばシェルスクリプトでも十分になるかも

Immutableに出来ない部分（永続的なもの、画像ストレージ、データベース）はどうするか？
例としては、外部サービスに任せるとか！

コンテナベースデベロップメント

コンテナ？＝単機能・軽量なVMと便宜上定義。
コンテナまるごとアップロードして差し替える。

Dockerの持つポータビリティにより実現可能性が高まった。
メリット　ポータブルなので、ローカル環境と本番環境で同じに出来る。
ローカルで十分テストしたままそのままデプロイできる。

テスト駆動→CI→デプロイという流れができそう。

1コンテナ1機能と単純化し、組み合わせでサーバ構成。サーバ部品のコンポーネント化ができるのでは？
個別に差し替えやすくなり継続的改善に寄与。
単機能化するこｔでテスタビリティも向上。オブジェクト志向的な。

IaaS上じゃなくても、Blue-GreenDeploymentができる。

Mesos/YARN等との組み合わせで自動的なリソース配置最適化もできる。

Orchestration

複数のサーバが関連するものと捉えるとわかりやすいかも？

  • ロードバランサにノードついか
  • MuninやNagiosへのノード追加
  • アプリケーショデプロイ

旧来のOrchestration

Immutable前提ではなかったので、サーバの増減が頻繁ではないので、
Configuration領域でもやれてしまう。Command & Controlとなる。

新しいOrchestration

はImmutable選定 サーバの増減が頻繁なので、Configuration領域での対応はキツイ。
Autonomy/自立協調となる。

Serfの登場

サーバが追加されたというイベントがロードバランサに通知される。クラスタリングと通知しかまだ機能はない。

Serfでやれること/やるべきことをOrchestrationと捉えるといいかも

これから

  • テスト駆動でインフラ構築
  • インフラCIで継続的インフラテスト
  • テストが通ったらコンテナをまるごとデプロイ
  • ...とはいえまだ課題はある