DevOpsDays Tokyo 2012に参加してきたので聞いたこととか思ったことまとめ

DevOpsDays Tokyo というイベントが行われていたので参加してきました。DevOps という単語やムーブメントを牽引する英語圏のゲストを招いての大規模なイベントでした。会場の GMO さんやスポンサー各社のご協力のおかげか、至れり尽くせりな感じですごかったです。

• Tokyo 2012 – welcome

セッションスピーチはほとんどが各社製品紹介みたいな感じだったので割愛しますが、その後に行われた OpenSpace が相当エキサイティングでした。これは海外のカンファレンスだとよくある形式なんですが、会場とコマだけ用意されているので、あとは話したい人が話したいテーマをその日に適当に入れてプレゼンとかディスカッションをするという感じのものです。その場で生まれる議論のダイナミズムは、普段から色々と頭を使って手を動かしているエンジニアにとってはとても刺激されるものではないかと思います。今回は 2 セッションありました。

OpenSpace1 インフラ CI

1 つ目は@marqs さんのお題で「インフラ CI」という話に参加しました。今回のカンファレンスは Chef が大流行だったんだすが、Chef で以前は動いていた cookbook 一式が今日実行してみたらエラーになってこけてしまうとかあるそうです(内部レポジトリとか立てればなんとかなるのかな？)。なので、定期的に VM なり EC2 なりインスタンス立てて実行してちゃんとサーバが作れるかどうかをチェックするといいのではないか、という頭出し。

僕のところでは、ちょっと違う方向の CI をすでに始めていて、Touryo という Yet Another Chef なツールのテスト機能を使って、1 時間に 1 回全サーバに対して設定のバリデーションを実行しています。その結果を Ukigumo という CI ツールに対してあたかもアプリのテストを行ったかのごとく「プロジェクト＝用途名、ブランチ＝サーバ名」としてぶん投げています。こうすることで、設定がおかしい人をまずは炙り出すことができています。

Chef は dry-run ができないのが問題で、結局稼働中のサーバに実行するのはだんだん躊躇われる様になってしまいますが、Touryo ではテストするだけなので問題ありません。Touryo はテストツールでもありセットアップツールでもあるので、正しい状態であるかのチェックと正しい状態へのセットアップを 1 つのフレームワークの中で行うことができるのが特徴ですが、Chef も近々 dry-run に対応するという噂を丁度聞きましたので期待ですね。ちなみに、正しい状態というのはセットアップ時だけ通ればいいものではありません。運用していく中で正しいパラメータがセットアップ時と変わることは往々にしてあります。そうした変更に対して、全サーバ網羅チェックみたいなの大抵やるとおもうんですが、Touryo みたいな仕組みがあれば炙り出しもできるので捗ると思います。

話を戻してサーバがちゃんと構築できてるかどうかの「テスト」というものは「セットアップ手順」から動的に作ることは不可能だと思います。アプリ開発における「テスト」がビジネスロジックから動的に作ることができない様に。それは当たり前で、だったらテストなんか要らないわけですよね。テストとセットアップはとても似ているけれども本質的には違うもので、それぞれ人間が頭を使って 1 度書いてあげる必要がある。Touryo でもこの発想からテストとセットアップはフレームワークは共通だけれどもそれぞれをどの様に書くかは人間に委ねています。Chef も dry-run 対応をするのであれば、こうしたテストフレームワークみたいなのも作るといいんじゃないかなと個人的には思ってます。

みたいな内容を勝手に少ししゃべらせてもらいました^^

話の中で出たので個人的にアリだなと思ったのは、日時で必要なファイルの状態を記録しておいて、前日の状態との比較を行って差分があったらアラートを出すというもの。後でも出てきますが、基本的に運用フェーズって「何か変更があったら」怪しいと思うわけですよね。そういう意味では一番シンプルな継続的なテストだと思います。

あと、marqs さんとか桑野さんと軽くしゃべったのがじゃあそもそもサーバがテストできたとしてそれをどういうフックで実行すればいいのか？今僕のところは定期実行にしてますが、細かく定期実行できるならまぁそれも 1 つの手だと思います。サーバの変更なんてプログラムの commit に比べれば圧倒的にスパンが長いので。ただ、もしフックするとしたら何がいいのかな？というのは気になるところでした。が、次のセッションで答え出てました。

OpenSpace2 Metrics Monitor

というわけで続いて Damon Edwards さんの「Metrics Monitor」の所に行きました。結局ここは Damon さんのお話をみんなで聴くだけになってしまいましたが、その分彼のアイデアを存分に見せてもらうことができました。要素要素で考えていることは自分と特に変わりなかったですが、アイデアのまとめ方というか見せ方というか、そういうのがうまいなと思いましたのでありがたくパクらせて頂きます:)

ロギング・可視化

Metrics として、「サーバの状態」「アラートの状態」「ビジネス KPI」を見やすくするというのはもはや当然というかまぁやってるでしょうが、運用という観点で一番必要なのはここには間接的にしか出てこない情報、つまり「オペレーション」なんですね。

• サーバにいつどんなコマンドを実施した？
• 修理対応のためにいつどういうオペレーションした？
• ファイルをいつ編集した？

これらを作業者に人力でロギングしてもらうなんてまぁ破綻が目に見えてるわけで、自動化するのが重要。1 つ目はサーバへのオペレーションを原則ラッパコマンド(例えば oinume さんのtomahawkとか！)経由にしてそれが自動でログを記録する、2 つ目はオペレーションをチケットベースにすることでその状態変更等でロギングする、3 つ目は tripwire の様な改竄検出で行うのが良いと。これ全部サーバのテストを走らせるためのフックポイントだなぁと思いました。多分これでほぼ過不足ないんじゃないかと思います。ちなみに 3 つ目とかは inotify とか使ってファイルの変更を push 型で検出してロギングするのがいんじゃないかなぁーとか思いました。

で、話はメトリクスに戻ってじゃあこういうロギング(&可視化)を「ちゃんと」行うには何が必要か？もちろんそもそもの仕組みづくりは必要なんですが、サーバの構築を自動化してないと新しく作ったサーバだけメトリクスが取れてませんでした、とかままあるわけですよね。というわけで自動化の話。

テスト

さて、構築自動化すると、ボタンひとつでサーバが追加できる！とかよく聞きますがまず引っかかるのは「追加したらやっぱりちゃんと設定できてなかったとかあったらどうするの？」ってところでしょう。そういうのを防ぐための仕組みというか”マインド”が「テスト」なんですよね。これについては上で書いた通り。テストがちゃんと書かれていて、テストを通ったサーバだけサービスインできるようにしておけばいい。それでもおかしいサーバが入っちゃうんであれば、それはテストが不足してるのが悪い。基本的にテスト駆動開発と同じですね。そういうマインドをちゃんと浸透させるのが重要。

自動化

んで、実際自動化についてですが、サーバの構築は 3 フェーズに分けられます。

• bootstrap

  • OS インストールやインスタンス起動など

• configuration

  • 必要なミドル・アプリのインストールや設定

• orchestration

  • 他のサーバや LB との連携を行って実際にサービスに入れる

それぞれのフェーズに対してすでに様々なツールが提案されていますので、お好きなものを使えば良いと思います。ちなみに Touryo はこういう分析を行った上で configuration に焦点を絞って開発しました。なので bootstrap や orchestration は別の手段でやる必要があります。うちの場合は bootstrap は別のツールで自動化されているので、それで OS 自動で入れたあとに Touryo を実行する感じです。orchestration の自動化はネットワークも絡むし、一番サービス影響を与えるところなので今のところは手動が中心ですが、いずれは自動化したいと考えています。という感じで、いきなり全てを自動化しようなんて思わなくていいんですよね(実際それって大変で、結局ひとつも自動化できずじまいになるか、全部置き換えて大障害とかになりがち)。今全部手動でやってるとしたら、どれか 1 つ自動化することから考えましょうと。

改善チーム

以上、3 つの分野が運用の質を上げるためには必要。

• ロギング・可視化
• テスト
• 自動化

これらをあなたの組織で実施するために、3 人集めてチーム作ってやりましょうと。3 つの分野は互いに連携とって進める必要があります。ただ、エンジニアがこういうのをゲリラ的に始めると無駄に高尚なものを考えていつまでたっても収束しないプロジェクトになりがちですね。そうなるとビジネスサイドから見たらエンジニアの道楽にしか見えません。本当は運用の質を上げるための重要な取り組みなのに。そういう不幸を防ぐためにも誰か 1 人プロジェクトマネージャ的に全体のスコープとか、スケジュール感とかをちゃんと交渉して決められる人が必要。

ちなみにこれ聞いて、「あー、俺全部 1 人でやってるわー。。。」とか思って泣きそうになりました。この意見参考にして、チーム作ってやれたらいいなぁと思ったので色々頑張ろうと思いました。

というわけで、非常に示唆的なセッションでした。

まとめ

DevOps というと、「開発と運用の壁」みたいのがちょっと前は定型的な謳い文句だったかなぁと思いましたが、そういうの言ってる人大抵プライド高い人で「だからあいつらはダメなんだ」みたいな意見も多くて辟易してたのですが、今回の DevOpsDays では上に挙げた様な継続的な〇〇に問題意識を持っている人がすごく多くて、運用サイドの人間からしてみるとテスト駆動開発という分野ですでに開発の方が先を行ってるわけですよね。なので、真摯に開発から学ぶべきだと思って、おお DevOps とはこういうことなんやーとか改めて思いました。サービスをよりよくしたいというのはみんな共通の目的なわけですから、協力して頑張りましょう！

「OpenSpace(・∀・)ｲｲﾈ!!」という声をかなり聞いたので、次回は OpenSpace 中心でもいんじゃないかなーとか思ったり。正直、DevOps なんて何かあるわけじゃなくて「問題意識の共有からの議論ができる場」を提供するのが一番の価値だなぁと思いました。今回は参加者が自分とは違う界隈の方々が多かったのでお題出しは遠慮しましたが、話したい人達がいる環境で話したいことを自発的に話せるというのは実に楽しいので、次回はぜひとも。

というわけで、すばらしいイベントを開催して頂いた関係各位とゲストスピーカー各位に感謝！ホントは英語でブログ書きたかったけど、ちょっと気力が無かったので日本語で勘弁してください＞＜