DevOpsでエンジニアを解放できるか
エクシードは、最近では珍しい、社員のおそらく90％以上がインフラエンジニアという会社である。その中でもベテランである千葉則行氏は「インフラエンジニアの数は少ないのに、要求されることは多い」と感じている。例えば「明日までにシステムを用意して欲しい」と言われても、限られた人数ではできることに限界がある。
それでも5年ほど前までは、がんばれば何とかなったが、近年ではいよいよ無理になってきた。その背景には、IT技術の進化、複雑化がある。一人のエンジニアがすべてのスキルセットを持つことが困難になり、専門化が進んでいる。その中で、開発vs運用、エンジニアvs営業、企画部門vs技術部門といった組織、グループ間で、「どちらかが喜べば、一方が泣く」というような一種の対立構造が生まれている。千葉氏は「会社の中で対立していても不毛なだけで、何も解決しない。前向きに考え、ハードルを越えたい」と語る。
そこで必要になってくるのが「関係する人がコラボレーションする仕組みであり、それこそがDevOpsなのではないか」というのが千葉氏の考えだ。
DevOpsで重要とされているのは、Culture、Lean、Automation、Measurement、Sharingだ。コラボレーション実現が大事という文化を醸成した上で無駄をなくし、自動化し、取り組みや測定した情報を共有する。
Chef、Mcollectiveの特徴と使用例
最近、DevOpsというと、Chef、Puppet、CFEngineなどが話題になる。特にChefは、Facebookがデータセンター自動化ツールとして最新バージョンを全面採用するなど、すごく盛り上がっている。ただ、Chefの認知度は確実に上がっているが、実際に使っているエンジニア数は伸びていない。
千葉氏はChefを実際に使ってみて「よく考えて作られている」と思っている。例えばChefの手順書ともいえるクックブックには、大きなくくりがある。
例えばMySQLをインストールする場合、まずRecipeという単位で、どういう目的なのか、ただのクライアントとしてなのか、それともサーバなのかなどを管理する。Templateは設定ファイル。Resourceではインストール、バージョン管理を行い、Attributeでサーバ固有の情報を管理する。
では具体的にはどうか。Apacheのインストールであれば、『package "apache2" do action :install end』だけ書けば完了する。同様にイネーブル、自動起動を設定して起動するのは『service "apache2" do action [ :enable, :start ] end』。設定値（attribute）は…『Listen <%= port %> NameVirtualHost *:<%= port %>』…というように、非常に簡単だ。
Chefでは、スクリプトよりも簡単、確実に記述できる。例えばどこかからパッケージを取ってきてインストールする操作をスクリプトで書くと、『インストール済みかどうかを確認してから』と書くことが一般的だが、Chefでは一回実行されていると自動的にスキップしてくれる。そうした細かいことを考えなくても書くことができる。
また、必ず期待した通りの結果が戻る“べき等性”がある。Apacheが起動している状態が正として返ってくるのであれば、Chefを実行したタイミングでApacheが必ず起動し、落ちれば再起動する。1つのクックブックで書けばよく、一つ一つスクリプトを書く必要はない。ただ千葉氏は「Chefは、柔軟性はあるのだが、分かりにくい部分があるのは確か」とも語る。
Chefに続き、千葉氏はPuppet labsのプロダクト、Mcollectiveを紹介した。これは条件にマッチする複数のサーバ群に対して任意のオペレーションを一括実行できるツールで、非同期でメッセージをデリバリーできるという特徴がある。実際はメッセージを投げる前に一度、activeMQに入れておき、ノード側がそこにキューを取りに来る形になるため、大きくスケーラビリティがある。
例えば実際のMcollectiveのコマンドで、『Apacheのサービスリスタートを10台ごとにバッチして、2秒間のスリープで、26台同時に実行する』を書くと以下のとおりになる。
% mco service restart httpd --batch 10 --batch-sleep 2 Discovering hosts using the mongo method .... 26 * [=============================> ] 26 / 26 Finished processing 26 / 26 hosts in 6897.66 ms
または、
% mco rpc service restart service=httpd -W country=uk
というように、『W country=uk』と書けば、ukに属するノードにだけこのコマンドを配布し、実行できる。
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のような取り組みを成功させるポイントになる。
最後に千葉氏は「まず大変なことを共有することから始めてみよう」とメッセージを発し、セッションを閉じた。
