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

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

セッションスピーチはほとんどが各社製品紹介みたいな感じだったので割愛しますが、その後に行われた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なんて何かあるわけじゃなくて「問題意識の共有からの議論ができる場」を提供するのが一番の価値だなぁと思いました。今回は参加者が自分とは違う界隈の方々が多かったのでお題出しは遠慮しましたが、話したい人達がいる環境で話したいことを自発的に話せるというのは実に楽しいので、次回はぜひとも。

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