BT

Config Management Camp: 構成管理を越えて

| 作者: Carlos Sanchez フォローする 0 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2015年3月1日. 推定読書時間: 4 分 |

原文(投稿日:2015/02/10)へのリンク

HashiCorpの創業者でVagrantの生みの親であるMitchell Hashimoto氏が,Config Management Campの最初の基調講演で,過去と現在のデータセンタの状況,そこに存在する問題とソリューションの概要,分散システムや故障耐性,コンテナの利用といった話題について語った。

氏にとって,2006年は転換の年だった。それまでのデータセンタは,おもに次のような特徴を持っていた。

  • APIの数は極めて少なく,インフラストラクチャ提供側とのインタラクトを自動化する手段が欠如していた。
  • 柔軟性がなく,新しいマシンを準備するのは大変な作業だった。
  • 大規模なマシンを使用し,同一マシンに複数のサービスをインストールしていた。
  • IaaSやSaaSの利用は少なかった。

その後になって,次のような問題への取り組みが行われた。

  • サーバの画一化によって,“雪の結晶(snowflake)”現象を回避。
  • 複数のマシンに対する変更を簡単にする,スケーラブルな変更管理。
  • サーバのパッケージや構成からのデータ収集による,サーバ状態の検査。
  • 迅速なサービスディスカバリ。

それらの問題は,PuppetあるいはChefなど,構成管理ツールに依存したソリューションと強く結び付いていた。そのベースとなっていたのは,次のようなものだ。

  • 手作業によるノード登録(および解除)。
  • 唯一のマスタサーバ。
  • チェックと修正の不一致。
  • 通常はRubyを使った,エージェントモデルへの準拠。

2011年初めになると,構成管理の限界を拡大しようとする企業が現れ始め,不変(immutable)で一時的(ephemeral)なインフラストラクチャへの移行や,サービスディスカバリやプロビジョニングといった機能が,レンダリングテンプレートやパッケージのインストールのようなインフラストラクチャ・アズ・コードの機能に代わって台頭するようになった。

今日のデータセンタは,まったく様相が違っている。

  • API駆動である。すべてのことが,基本的にAPIを通じて行われる。
  • 高い適用性を持つ。数多くのマシンを短時間で提供することができる。
  • 小規模で単一目的のサーバ。
  • DNSやメールなど,数年前は考えられなかったコアインフラストラクチャのSaaS化。
  • 仮想化とコンテナの利用。

現在では,仮想化よりもコンテナの方がハイプ(Hype)な状態にある。現在のデータセンタでは,仮想化なしには何もできないが,コンテナもそれと同じ道を歩もうとしている。

氏の意見によれば,今日のデータセンタの問題は,

  • インフラストラクチャの生成と削除。
  • サービスディスカバリ。今日の移り変わりの早いインフラストラクチャにおいては,サービスディスカバリも迅速であることが必要だ。
  • SaaS管理。外部のプロバイダから提供されるサービスは,ますます増えている。

    Luke Kanies(Puppet創業者)はかつて,“少数のサーバ構成に未来はない”と言いました。少数のサーバ構成に未来はありませんが,自分で運用するサーバが少ない構成には未来があります。特にPaaSについては。そこではAPIが最下位層なのです。

  • レイヤケーキ管理。仮想化上でコンテナを実行する,というように,複数の層を合わせて使用する。別のシステムレイヤとして,OpenStackなども使用する。

  • より早く,よりリアルタイム的な変更。

解決策について,氏の見解は次のとおりだ。

  • 分散システム。
  • 故障予測と故障耐性。例えばクラウドインスタンスには消失の可能性があるので,Chaos Monkeyのようなタイプのツールを活用する。
  • API駆動とAPIによる管理。例えばコンテナでは,ユーザに提供される機能として,APIによる管理がある。
  • スケールアップ時のリソース使用量の低減。高サーバ密度の処理が必要なコンテナを利用する場合,リソースの最適化が必要となる。
  • SaaSとのインタラクション。内部システムとSaaSプロバイダ間のインタラクション管理。
  • 仮想マシンとコンテナ。ソフトウェアがそれらのいずれかで動作するか,その可否を知っておく。

ソリューションの設計では,ビルドアウトおよびビルドアップという,2つのトレンドに従う。いずれも,同じ程度の数の人たちによって利用されている。ビルドアウトは新ツールの開発を行うもので,既存の開発基盤はもはや有効ではなく,さらにツールが必要になる,という仮定に基づいている。対してビルドアップは,既存の基盤を活用するもので,すでに存在するものは十分に信頼できる,という考えに立脚する。HashiCorpが採用しているのは,ビルドアウトのアプローチだ。

現実的に可能な,最高な技術的デザインは何でしょう?私たちはビルドアウトのアプローチに従って,問題解決のために新たなツールを開発します。本質的な関連性のないプロジェクトを実施したり,動作させたりすることはできません。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT