3 minute read

こんにちは。@jedipunkz です。

DevOps Day Tokyo 2013 に参加してきました。たくさんの刺激を受けたのでレポート書 いておきます。

開催日 : 2013年09月28日
場所   : 東京六本木ミッドタウン Yahoo! Japan さま
URL    : http://www.devopsdays.org/events/2013-tokyo/

Making Operation Visible

Nick Galbreath (@ngalbreath) さん

DevOps の拠点 Etsy に努めた経緯のある DevOps リーダ Galbreath さん。DevOps の 概略から何が必要でありどう行動に起こせばよいか説明してくださいました。

Making operations visible - devopsdays tokyo 2013 from Nick Galbreath

こちら、Galbreath さんの当日の資料。

DevOps が実行出来ない理由

  • Tool が足りない
  • 社風の影響
  • 見えないモノが価値がないと事業から考えられている

出来る事は、価値があるモノの社内への説明と、Tool を使った可視化。データの可視 化が重要。Ops の人は結構「データをどこそこの部署に見せても理解してもらえない」 だとか「データを閲覧させると万が一の時にシステムが破損する」等と考えがち。が、 ビジネス寄りの人にとって重要なグラフが含まれていたり、アカウント担当の人に役立 つものも含まれている。ましてシステムが破損することなど決して無い。

重要なのは “運用のメトリクスを公開する” こと!

Graphite

  • グラフ描画ツール
  • まず完成度が高いわけではない
  • 同類のソフトウェアでは行えないクエリが発行出来る
  • REST API
  • Flexible Input & Output
  • Simple UI & Dashboard
  • 3rd Party Custom Client Side Dashboard あり
  • URL 型なので Dashboard 開発が楽ちん
  • 稼働させるための物理インフラリソースは結構必要
  • apt-get install graphite できるよ

statd

  • UDP 使ってる
  • Event Data を Application から statd へ

下記は例。ログイン情報を送るためのコードはこれだけ。

StatD::increment('logins')

国別にも出来る。

StatD::increment('logins');
$kuni = geoip2country($ipv4);
StatD::increment('logins.$kuni')

後に DataDog の方から詳しく説明がある。

Sensu

Sean Porter さん

メモとりにくいプレゼンだったので思い出しながら….

Sensu は Nagios のプラグイン等がそのまま再利用できる監視ツール。API を介してア ラートの具合やクライアントのリスト・監視項目のリスト等が取得できます。Nagios を使った場合、ターゲットノードの追加のたびにコンフィギュレーションを生成しなく てはならなかったり不便だったのが Sensu を開発しようとした動機だとか。Chef との 親和性が高く、Chef Cookbook の公開もしている。私も実際に使っていますが、

  • Sensu サーバの構築
  • 監視項目の追加
  • ターゲットノードへのアージェントの追加

等はすべて Chef の Knife コマンドで出来ます。特に Chef からの影響だと思われる が Omnibus 形式のパッケージを採用していることもあり、エージェントのインストー ルは簡単です。パッケージの中に動作に必要な Ruby 一式も含まれています。

ドキュメントは下記のところにあります。

http://docs.sensuapp.org/0.10/index.html

puppet

max martin

for next level +++

  • Puppet 3.x
  • Hiera integration
  • PuppetDB
  • Mcollective 2.x
  • Geppetto : IDE
  • Puppet Forge : web site

Puppet が提供するソフトウェアやサービス達。DevOps の次のステップへの必要な技術 要素。

puppet 3.x

  • pupput2 に比較して speedup x 3
  • agents/server : 100% up
  • これらは理論値ではなく実効値!

Puppet2 と比較してかなりの性能アップらしい。処理速度3倍は実効値だそうです。

puppet3.0 = hiera functions + data bindings

  • hiera : hierarchical key value store with pluggable backend (json, yaml..)
  • keep site specific data out of puppet code
  • parameter values are now automatically looked up in hiera
  • data bind でコードがシンプルに : include ntp -> yaml, json..

json や yaml でパラメータを記述出来るのでコードがシンプルで綺麗になるよ、との こと。Chef でいう Attributes だと思われる。

puppetdb

  • puppet データすべてを格納 (facts, catalogs, reports,..)
  • replaces existing library is much faster and more faster
  • postgreSQL, Clojure, JVM -> JAR ファイルで展開
  • クエリシンタックスを自ら定義可能
  • API がシンプルなので dashboard などの開発も簡単

PostgreSQL が最近あちらの国ではイケてるっていう話はよく聞いていたけど Puppet3 は PostgreSQL, Clojur, JVM の組み合わせで構成されているらしい。Chef も Erlang に置き換わったあたりを見ての反応かなぁ?と想像。

MCollective

  • orchestration engine
  • ruby を使って独自のエージェント開発可能
  • mco rpc service restart service=httpd –nodes=hosts.txt # query a file
  • mco rpc service restart service=httpd -W country=uk -dm=puppetdb # discover
  • mco rpc rpcutil ping -I example.com # direct addressing
  • ruby のライブラリとして利用可能

query a file のサンプル

c = rpcclient("service")
c.discover :nodes => File.readline("host.txt").map {|i| i.chomp}
printrpc c.restart(:service => "httpd")

これはオーケストレーションツール。ホスト名の記述されたファイルから、それらのホ ストに対して一斉に指示を送ったり検索を行ったりコマンドの実行が出来る。これは Ruby ライブラリとして再利用出来るらしい。これは便利。

Geppetto

  • IDE for developing puppet modules and code
  • git & svn
  • Linux, Mac OSX, Windows

Linux, Mac, Windows 用の IDE まで提供してるんですね。驚き。Puppet ものすごい勢 い。

Puppet Forge

  • module repository
  • 1,500+ modules
  • puppet module install foo/foo
  • module のためのチームが内部にある

コミュニティの作ったモジュールを公開しているレポジトリ WEB サービス。1,500 以 上のモジュールが公開されているらしい。このためのチームも Puppet 社内にいるとか。

迷ったら健全な方を

Cookpad Naruta Issei さん

印象的なプレゼンでした。

現実に起こった問題を切り口に Devops について語っていました。リリース日当日 Ops が「今日リリースだと初めて知る」という事件。繰り返さないためにどうするか?

  • リリース日の決定に Ops の承認が必要なルールにする?
  • Ops 「ソースコードが fix してからリリース日まで3営業日必要?」

このようなルールを作りがちだけど、これでは Ops が権威になってしまう。Ops の立 場からしてこの「権威」になりやすいという特徴があるが、Ops はそう振る舞ってはい けない!という話。DevOps に必要なコミュニケーションで回避出来ると。DevOps であ る限り仕事は楽しくなくてはならない。承認を取るテクニック・政治が発生するのもこ れまた問題。

Cookpad はこれからもコミュニケーションでこういった問題をクリアしていく!と宣言 がありました。最後は若干 Ops 避難のようなプレゼンを Ops の前でするかのような状 況に Issei さんも声を震わせながらのプレゼンでしたが、逆にそれが僕には響きまし た。ぼくも Ops 出身だし、こういった問題は嫌になる程見てきているので、この訴え かけはガツンときた。プレゼン最高でした!

DataDog

Alexis Lê-Quôc さん

監視ツールにとっての重要な要素

  • Timely
  • Correct
  • Comprehensive (包括的)

これらを満たせなければ全く無駄。

  • 前提条件を元にメトリクスを決めている -> 不完全なメトリクスが多い
  • -> 最低限の条件でメトリクスに要素を追加できることが重要だと考える

statd types

  • gauges
  • counters
  • histgrams
  • timers
  • sets

参考資料

statd と graphite の連携

https://github.com/etsy/statsd/blob/master/docs/graphite.md

サポートされているバックエンド一覧

https://github.com/etsy/statsd/blob/master/docs/backend.md

まとめ

とても有意義だった。丸一日、最後まで聞いているのも辛かったけど、運営されている 側の方々はもっと大変だったでしょう。ありがとうございました。日本ではなかなか話 を聞けないめちゃホットな方々の話を直に聞けるなんて無いのでホント貴重でした。ま たディスカッションには参加出来なかったけど、久しぶりに会えた方がいてめちゃ良かっ たです。同じ方向向いている方々がこれだけ社外には居るんだという気付きもあったり。

皆さん、ありがとうございました!