log.fstn

技術よりなことをざっくばらんにアウトプットします。

Chef server の運用って結局なにが大変なの？使いたい場合はどうすればいいの？

Chef Chef server Infrastructure

はじめに

最近 Chef をよく使うようになり、必要に駆られて Chef server を構築することとなりましたが、「Chef serverの運用って大変だよね」って話をよく聞きます。 「大変」って聞いただけで敬遠するのはもったいないので、何が大変で、どうすればいいのか、をこの記事でまとめたいと思います。

大した運用経験がないので、気になる点や間違っている点がありましたらご指摘頂けると幸いです。

Chef server とは

f:id:foostan:20131201143519p:plainhttp://docs.opscode.com/chef_quick_overview.html より転載

簡単に言うと、Cookbook や 構築対象のサーバ(Nodes) の情報を一元管理しているサーバです。
Nodes にインストールされた Chef client からのAPIアクセスを受け付けて必要な情報を提供します。

Chef server の種類

Chef server は主に3つの種類に分類されます。

種類 概要
Enterprise Chef 有償版。冗長構成サポートあり
Hosted Enterprise Chef 有償版。Opscodeが提供しているChef server
OSS Chef OSS版。冗長構成サポートなし

詳しくはこちら http://www.opscode.com/chef/ の Which Chef is Right for You? を参照してください。 今回は OSS Chef を対象に話を進めます。

Chef server の構成要素

f:id:foostan:20131201153307p:plain http://docs.opscode.com/chef_overview_server.html より転載

種類 概要
Bookshelf Cookbookの管理を行う
Cookbooks 実ファイルとしてディスク上に保存される
WebUI Chef server の管理用インターフェース
Erchef Chef server のメイン。APIリクエストを受け付けて処理を行う
Message Queues Search(http://docs.opscode.com/essentials_search.html) リクエストを格納するためのキュー
Nginx リバースプロキシとして動作し、HTTPリクエストを WebUI、Erchef、Bookshelf にそれぞれ振り分ける
PostgreSQL Nodesの情報、Clientの情報(公開鍵など)、Cookbookへのパス等を保存するデータベース

詳しくはこちら http://docs.opscode.com/chef_overview_server.html を参照してください。

Chef server を運用する上で考慮しなければならない点

Chef server の運用というか、サービスを運用する上で重要なのはサーバを「落とさないこと」です。 OSS版の Chef server は冗長構成のサポートがないため、自力で冗長化をする必要がありますが、ここが運用で大変なポイントのひとつです。

落ちない Chef server を構築するには

一般的なサーバは

  • データを保持しないサーバ
  • データを保持するサーバ

の2種類に分類できると思います。

データを保持しないサーバとは、WebUI や Erchef のように、データを保持しているサーバからデータを取り出して処理するようなサーバです(実際のところキャッシュなどは保持しているかもしれませんが)。また、冗長化するためには同じサーバを複数台用意して、前段にプロキシサーバなどを挟むだけなので容易です。

データを保持するサーバとは、DBのようにデータを保存しているサーバであったり、Message Queues のようにリクエストを保持するようなサーバです。また、冗長化するためには同じサーバを複数台用意して、データを同期させないといけないため比較的難しいです。

Chef server の各要素を分類すると以下のようになります。

データを保持しないサーバ データを保持するサーバ
WebUI、Erchef、Nginx Bookshelf、Cookbooks、Message Queues、PostgreSQL

つまり、落ちない Chef server を構築するためには、

をいかにして冗長構成にするかが鍵となります。

Enterprise Chef Server における 冗長構成

実際 Enterprise 版ではどのようにして冗長構成にしているか調べてみました(間違っていたらごめんなさい)。

f:id:foostan:20140214213942p:plain http://docs.opscode.com/enterprise/server_high_availability.htmlより転載

下記の手段を利用して冗長構成にしていることがわかります。

種類 概要
Load balancer データを保持しないサーバ群の前段に設置し、冗長構成 + 負荷分散を行っています。
Shared VIP(Keepalived) VIP(Virtual IP)を付加することで、データを保持するサーバ群をPrimary-Secondary構成で冗長化します。また各プロセスを監視し、異常を検知した場合、VIPの切り替えを行います。
DRBD データをブロックレベルで複製し、Primary-Secondary構成で冗長化します。Keepalivedで障害を検知した際は、PrimaryとSecondaryを切り替えます。

で、結局なにが大変なの？

DRBD + keepalived の構築・運用が大変

ロードバランサを利用して、データを保持しないサーバ群を冗長構成にするのはよく見かける構成なので運用経験者は豊富にいると思いますが、DRBD + keepalived による冗長構成はあまり見かけません(少なくとも自分の周りでは)。 運用する人に DRBD + keepalived の構築・運用経験があれば問題ありせんが、ない場合は学習コストがかかるため構築・運用が大変だと言えます。

構成する要素が多すぎて、運用できる人材がいない

図を見て分かる通り、Chef server と一言で言ってもその実態は、複数の要素から成り立っています。 冗長構成をとって障害は免れても、なぜ障害が発生したのか？どうすれば障害を防げるのか？と追求するためには、各要素に詳しい人材が必要になります。 NginxやPostgreSQL、RabbitMQといった一般的に利用されているサーバについて詳しい人は多いかもしれませんが、Chef server で独自実装されている Erchef について詳しいという人はまずいないです(ちなみに実装は Erlang)。

Chef server が利用されない理由

上記のとおり運用が大変ってのも理由のひとつですが、Chef server を使わずとも Chef-solo、Knife-solo で十分って場合が多いんだと思います。 Chef-solo や Knife-solo を使えば、冗長構成について考える必要もありませんし、Cookbook は GitHub などで管理すれば事足ります。

それでも Chef server を使いたいって場合

Chef server には chef-solo にはない、Nodes の情報を集約して管理する機能があります。 よって、Chef server を利用したいというニーズはある程度あると思いますので、運用方法について少し考えてみました。

冗長構成にするにあたって優先すべきこと

「おちない」ことを意識すれば、Enterprise 版の構成で満足する結果を得られると思います。 しかし、構築や運用コスト(主に学習コスト)を考えると Chef server を冗長構成にするためには過剰すぎるのでは？と思いました。

そもそも Chef server は運用のためのツールであり、おちることにそこまで敏感になる必要もないかと思います(状況によるかもしれませんけど大抵の場合は)。 もちろん Chef server の使い方や環境によって優先すべきことは異なってくるので、一概には言えませんが、 Chef server を構築・運用するにあたって、「おちない」ことよりも「簡単・シンプル」である事のほうがメリットがあると思います。

今回紹介する構成は「簡単・シンプル」を優先した場合の選択肢の一つとして見てもらえればと思います。

冗長化の妥協点

簡単・シンプルを優先する代わりに、いくつかの冗長化を妥協する必要があります。
Chef server の各要素について冗長化の重要度を三段階にまとめてみました。 重要度は、データを保持するかしないか + α で独断と偏見で決めています。

種類 重要度 理由
Cookbooks 高 Cookbookの実データが保持されており、バックアップは必須。Enterprise版ではDRBDで冗長化している
PostgreSQL 高 Nodesの情報が格納されているため、バックアップは必須
Message Queues 中 失うことによる影響度は低め(だと思う)
Bookshelf 中 失うことによる影響度は低め(だと思う)
Nginx 中 データは保持していないが、APIリクエストが一切受け付けられなくなる
Erchef 中 データは保持していないが、APIリクエストが一切受け付けられなくなる
WebUI 低 データを保持しない上に、落ちても大して困らない

ここでどこまで妥協するかで構成がガラッと変わってきますが、今回はお手軽ということで、重要度 '高' だけ冗長構成にします。

ちなみに、Cookbooks はGitHub等で管理されていることが多く、復旧が容易に行えると思うかもしれませんが、 Chef server ではアップロードされた全てのバージョンの Cookbooks を管理しているため、復旧にはそれなりの手間がかかります(常に最新バージョンの Cookbooks だけ保持できていればいいのであれば重要度は低くなります)。

提案する冗長構成案

概要は以下のとおりです。

f:id:foostan:20131202021735p:plain

追加点は以下のとおりです。

種類 概要
Hot-standby replication PostgreSQL 9.0 から採用されたレプリケーション機能です
rsync + lsyncd 実ファイルを同期するための手法です。lsyncd によってファイルの変更をHookしてrsyncで同期します。

なるべくシンプルに冗長化できる方法を選択しています(使用するマシンも2台だけ)。 また、Primary と Secondary の切り替えを容易にするために、keepalived によって VIP を付加しています。

運用するためのポイント

妥協することだと思います。 きっちり冗長構成にして、ちゃんと運用するためにはコストが多くかかると思いますが、ある程度妥協すれば運用は楽です(妥協するので当たり前ですが)。 妥協したくない場合は、Enterpriseのような構成にして運用できる人材を育てるか、Enterprise Chef や Hosted Enterprise Chef を使うことを検討すると良いと思います。

まとめ

Chef server の運用って結局なにが大変なの？

  • DRBD + keepalived の運用が大変(冗長構成にするのが大変)
  • 構成する要素が多すぎて、運用できる人材がいない

使いたい場合はどうすればいいの？

  • 妥協する
  • 構築・運用を行える人材を育てる
  • Enterprise Chef や Hosted Enterprise Chef を使う

参考資料