グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～@デブサミ2014
2/13(木)、14(火) に目黒の雅叙園で開催された「Developers Summit 2014」の参加レポート#2です。
グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～
グリーにおけるChef導入事例 ～既存の資産を活かし新しい技術を導入する～ // Speaker Deck
グリー開発統括本部インフラストラクチャ部 荒井さんによるChef導入事例のセッション。Chefについては伊藤直也さんの「入門Chef Solo」（電子書籍）を読んだ程度の知識ですが、DevOpsやInfra as a Codeといった最近のインフラ界隈を賑わせているツールなので注目していました。GREEではサーバの構成管理は手動＋自前の管理ツールで結構「頑張っていた」のをChefを導入して運用負荷を減らした、というお話。
Chefとは
ChefはChef社（旧OpsCode社）が開発するOSSのサーバ構成管理ツール。OSをインストールしたサーバに対して、Rubyで記述されたレシピ（クックブック）を読み込んで、Webサーバ（Apache, Nginx）やデータベース（MySQL）などのミドルウェアをインストールし、「Port80でlistenする」とかの設定をすべて自動で行ってくれる。いわゆる「Infra as a Code」を司るツールの一種。ImmutableなInfrastructureを作る上では欠かせない存在。
導入背景（Chef導入以前のお話）
Debianパッケージを使って手動で運用していた。設定ファイルはpostinstを使っていたが、パッケージ内にあったり、サーバ管理システム（後述）にあったりと構成管理がかなり煩雑になっていた。サーバの増減に応じてインフラエンジニアがサーバをセットアップして開発者に渡す、みたいな事を繰り返しており
- 非効率
- オペミスのリスク
- セットアップコスト（サーバ提供速度）
などの面で、課題を抱えていた。
サーバ管理システム
社内のサーバ情報を一元管理しているシステム。管理している情報は「サーバ名」「DCの場所」「稼働ステータス（本番稼働中、構築中、故障中...）」などなど。運用スクリプト・ツール・Debianパッケージがこのツールに依存している。
お話から察するに、このサーバ管理システムにかなり依存しているサーバ構成であることが推測できました。
Chef導入方針
サーバ管理システムへの依存度が高いため、Chefへの全面移行はかなりハードルが高く、コスト的な面も考慮して以下の様な方針とした。
- 新規サーバはChefで構築し、既存サーバはサーバ管理システムを利用する並行スタイルをとる
- サーバ管理システムは残し、既存のスクリプト・ツール類は動作する状態で移行する
GREEさんのように数千台というサーバを抱えている状態ではサーバ管理システムを廃棄し、全面的にChefへ移行するというアクションはリスク・コストの両面で高すぎて、取ることができなかったという印象です。（正しい選択だと思います。。）
Chef Solo と Chef Server
Chefを導入するにあたり、Chef ServerとChef Soloのどちらを採用するかで悩んだ。Chef Soloを使う場合、ロールやクックブックを各サーバに配置しなければならず、大規模システムでは導入しずらかったため、ロールやクックブックを一元管理できるChef Serverで検討を進めたが、いくつかの問題があり、"Chef Solo + α"という選択肢となった。
Chef Bridge と GREE Chef Client
"+α"の部分に対応するために、内製で開発した。Chef Bridgeはサーバ管理システムとノード（各サーバ）の間に介在し、クックブック・ロールを一元管理して、管理対象ノードにそれらを届けるためのRailsアプリケーション。REST APIでクックブック・ロールを参照できるようにしている。
GREE Chef ClientはChef Soloのラッパーで、Chef Bridgeからクックブック・ロールを取得してChef Soloを実行し、正常にセットアップできているかをテストする。
クックブック
OpsCode Communityで色々なクックブックをダウンロードできる。汎用的に作られているため、結構中身は複雑なので、基本的にはクックブックは内製。クックブックを内製できるようになるために、Chef使いを育成した。「入門Chef Solo」→「初心者Chefアンチパターン」→社内用チュートリアルの順で学習させる。
入門Chef Solo - Infrastructure as Code
- 作者: 伊藤直也
- 出版社/メーカー: 伊藤直也
- 発売日: 2013/03/11
- メディア: Kindle版
- 購入: 16人 クリック: 1,027回
- この商品を含むブログ (16件) を見る
作成したクックブックはTDDアプローチで必ずテストを書く。これにより、リグレッションを早めに検知できるし、クックブック自体がドキュメント代わりにもなる。以下を使用している
- serverspec / Test Kitchem : ブラックボックステスト。RSpec風にテストが書ける。
- chefspec : ホワイトボックステスト。これもRSpec風にテストが書けるUnitTestフレームワーク。
- Foodcritic : Lint（静的解析ツール）
課題（ハマったところ）
- Jenkinsサーバに繋がらなくなった
- ルーティングの問題だった。これは気づきにくそうだと思いました。解決方法としてVMだけのInternal Networkを構成するように変更した。
- Mutable Infrastructure問題
- 繰り返し、サーバに変更を加えているので、新規に作成した場合に同じになる保証がなかった。冪等性を確保できないという問題ですね。これもあるあるだと思いました。対策として、根本的ではないが、本番環境に対してもserverspecを流すようにした。
- テストに時間がかかる
- ここはどこも似たような問題を抱えていると思いますが、運用がこなれてくるとテストの数が増えてきてそこがボトルネックになり、デプロイに時間が掛かるというお話。テストの網羅性が落ちるといった悪い作用も出てくるようです。対策については聞きそびれましたが、「サーバスペックを上げるとか、テストを分散させるという方法以外にあるんだろうか」とも思いました。
ノードの属性（サーバの情報）
- どのクックブックを利用するか
- どのロールを使用するか
- サーバの設定値（サーバ名、Listenポート、MySQLのバインドするアドレスなどなど）
を持っている。設定値はクックブックによって異なるため、クックブックに設定項目のバリデーションルールを持たせてChef実行時にチェックを行うようにした。また、ノードの設定をYAMLで記述することで記法の統一や冗長性の排除ができるようになった。
ログの話
運用していくと、ログが欲しくなる。
- Chef導入前
- script / screenでログを取ってWikiに貼ったりしていた
- Chef導入後
- Report Handlerを使ってFluentdを経由してMongoDBへ保存している
- 各ノードにはログを持たせないようにした（Immutableにしたかったから）
所感
GREEさんでのChef導入奮闘記をかなり細かく語っていただきました、あれだけ大規模なWebアプリケーションの裏側を大きく変える事は、かなりの決断力が必要だったことと思います。決断し、実際にやりきった方々は本当に素晴らしいと思います。導入前と導入後の検証結果（導入前よりも管理コストがどれくらい減ったとか、オペミスで発生していた障害がこれだけ減ったとか）も聞きたくて、Ask the speakerに行ったのですが、会社の同僚と話していて出遅れてしまい、機会を逃してしまいました。
一休ではChefは本格導入していませんが、前回のエントリでも触れたようにImmutableな世界に向かって行かなければ、インフラの未来はないのではないかと思います。ぜひ、開発周りで改革が進んできたら、サーバ管理も改革に乗り出したいと感じた、とっても良い発表でした。
