ChefとMcollectiveの特長を束ねたツール「cloudrop」を開発
実際のインフラエンジニアの仕事というのは、大きく分けて2つある。1つは設計、構築というような、一度達成したら、その状態を変えたくない静的な仕事だ。それに対して何らかのイベント、障害などに対応する仕事は動的ということになる。
その意味でChefとMcollectiveは対極にあるもので、Chefは『決まった形、決まった状態に置く』ことを目的に作られている。一方Mcollectiveは『このタイミングでこの条件にマッチするノードに対して実行したい』という要望に応えるものになる。
ChefとMcollectiveに、Chefと作りが似ているPuppet、複数サーバでスクリプトを実行するCapistranoの特徴について、千葉氏は以下の表のように整理している。
実際の運用は、静的だけでも動的だけでも回らない。そこで千葉氏らが取り組んだのが、両者を束ねたツール『cloudrop』の開発だ。
最上部にユーザーが操作するPortalがあり、ここからメッセージを投げるとMcollectiveのクライアントに入る。渡すのにはRestを使っているのだが、インターフェースがMcollective側に用意されていなかったので、作成した。
そしてメッセージを受け取ったMcollectiveクライアントは、その内容をactiveMQに、「どのノードで実行してほしい」というようなヘッダ部分をつけて放り込む。ノード側は常にactiveMQをチェックしており、自分宛のメッセージが来たら、それを拾ってChef-soloで実行する。
仕組みはシンプルで、pullでもpushでもなく、非同期でどんどんシステムを動かしていくことができる。また、すべての操作ログが残るため、あとから問題が発生したときに原因を突き止めることも可能となっている。さらにデプロイだけでなく、監視機能も含まれている。
ただ、エンジニアが毎回クックブックや手順を書いているようでは、目的としているシステム作成時間の短縮ができない。そこで、cloudropでは、一度作ったものは再利用する仕組みを取り入れている。そこで得られるのが『オペレーションの標準化』であり、cloudropによる仕方は、四段階に分けられている。
- タスク : 細分化された作業手順を作る。
- パッケージ : 関連するタスクを集めパッケージング。
- バインダー : パッケージを集めてシステムのひな型を作る。
- ライブラリ : 作成したバインダーをライブラリに保存し共有する。
オペレーション標準化の効能はスピード、コスト、品質だが、同時に『シニアエンジニアがタスク、クックブック生産に集中し、現場は作られた手順書を確実に実行する』というように、組織内に効率的なシステム構築のフローが生まれることになる。さらにライブラリにナレッジが蓄積されていくことも大きい。
またシステム構築も標準化できるので、どんな環境にでも同じ構成のシステムを作ることができるようになる。例えば手元で開発環境を作り、試して問題がなければ本番を構築という際、環境の差異によるトラブルがなくなる。また、システムを更新する場合、新旧2つのバージョンを用意した上で新しいものをリリースし、不具合があれば元に戻す、ということも簡単にできる。
DevOpsという言葉に戻ると、千葉氏は「開発と運用の対立構造の言葉になってしまっている」と感じている。
“ Dev => DevOps <= Ops “
というわけだ。しかし本来は、サービスを回し続けるための取り組みであって、開発か運用かという問題ではなく、そこにかかわる人すべてが関連するものなのである。つまり必要なのは共有であり、コラボレーションだ。
ただ千葉氏は、いろいろやってきて『共有』について気づいたことがある。それは「課題など辛いことは他人と共有しやすく、一方安楽を共有しようとすると、堕落の道に行ってしまう」というものだ。そこで、課題や辛いことを共有することが、DevOpsのような取り組みを成功させるポイントになる。
最後に千葉氏は「まず大変なことを共有することから始めてみよう」とメッセージを発し、セッションを閉じた。
