なみひらブログ

学んだことを日々記録する。~ since 2012/06/24 ~

「DevOpsDay Tokyo 2013」に行ってきました

開発(Development)と運用(Operations)の集いである、「DevOpsDay Tokyo 2013」に行ってきました。
Tokyo 2013 - welcome

開催概要

  • 2013/09/28(土) 9:30-18:00
  • Yahoo!JAPAN@東京ミッドタウン
  • 参加者数 約300人
  • 開発(Development)と運用(Operations)の集い

会場雰囲気

f:id:Namihira:20130928152448j:plain

セッションメモ

Making Operations Visible

  • Making operations visible - devopsdays tokyo 2013 - SSSSLIDE
  • 運用ツールは現在いいものがたくさんあるが、結局、ヒトとヒトとのコミュニケーションだ。
  • 運用/デプロイは、事業主・マネージャー・上司から見えない。それは存在しないと同じで、価値がないとされる。
  • 運用データの見える化は大切だ。会社の運営まで影響を与えることができる。
  • コミュニケーションのため、データの見える化、ダッシュボード化する。
  • ほとんどの企業がグラフィック化しているが、運用のデータで経営視点のデータにマッシュアップできていない。変換できていない。
  • 「経営者はデータを見ても理解できない」と言われるが、実際にデータを見せれば理解できるものだ。
  • statsD、graphiteの紹介。RRD tool、ganglia。収集したデータを変換しグラフィック化するツール
  • statsD(データ収集)→ graphite(グラフ化)
  • 運用データをQAやセキュリティの人が分かる情報へ変換する必要がある。

プラットフォームベンダーから見たオープンクラウド設計と運用のポイント

An open source monitoring framework designed for the "cloud"

  • 監視ツールsensuの紹介:Sensu - Open Source Monitoring Framework.
  • シンプル、拡張性を重視した。
  • もともとNagiosを使っていたが、使いにくいため作った。
  • Nagiosは、サーバ構成を変えると設定ファイルを変えなければいけない。特に自動登録機能が必要だった。
  • sensuはRabbitMQ、Railsを使っている。
  • Rubyは運用ツールで多く使われているため、みんなに自由に拡張できるようにRubyを選んだ。
  • 設定ファイルがjson形式
  • pagreduty。障害が発生したら、メールや電話で通知してくれるサービス。

インフラ屋から見たEnterprise DevOPS のための基盤

  • ドキュメント作成は大切だが、それはゴールではない。
  • system centerの紹介。性能劣化の検知し、その劣化原因に関連するソースコードの場所も特定してくれる。
  • operations managerの紹介
  • Orchestratorの紹介。自社開発アプリの管理ができる。
  • 管理者と開発者と営業がコラボレーションすべき。リアルタイム重視すべき。
  • 社内課金の2段階方式を採用し、社内で利用してもらう努力をしている。1.確保する容量で低額な課金。2.利用した分で追加課金。
  • 各極からのレスポンスを確認することもしている。
  • システムテスト開始から稼働テストを実施すべき。セキュリティとか応答性能など早期に測定する。
  • 障害が発生すると運用者が開発者をアサインする。開発者は”受け付けたぞ”マークをつける。
  • データインサイト。データからビジネス開発をするべき。

5min demonstration

  • クックパッド

muninの紹介:Munin
chankoの紹介:プロトタイプ開発用のRailsプラグイン「Chanko」を2.0.0にアップデートしました | クックパッド開発者ブログ

  • VOYAGE GROUP

ポイントビジネスしている会社。

Puppet eco system

  • 発表者Max Martin。Puppetの開発部長。
  • Puppet lab.の実績紹介。
  • たくさんの製品をだせました。Puppet 3.X、puppetDBなど。
  • Puppet 3.X の改善点は速度(2倍)と拡張性(2.7倍)。
  • geppettoの紹介。PuppetのIDE。
  • PuppetDBの紹介。Puppetで生成されるデータを格納できる。PostgreDBをベースにしている。JVM上でJARとして動作している。
  • MCollectiveの紹介:大規模システム運用でpuppetやchefだけでは解決しづらいことを解決するMCollective! - よかろうもん!
  • Puppet Forgeの紹介。Puppetのモジュールリポジトリ。コミュニティが活用している。探しやすく。Puppet のinstallは簡単だ。探してきて、コマンド打つだけ。

DevOps at Gengo: the whys and hows

  • knife-solo、vagrantを使った事例紹介。

Ops for Everyone

  • Ops for Everyone // Speaker Deck
  • github社の教育担当者で開発者
  • 企業理念と同様に開発理念が存在する。1.同じことを2回するな。2.作業の分散化しろ。
  • boxenの紹介:ビルドを初日からできる仕組みを実現する。コマンド一つで開発環境自動作成できる(2~4時間)。設定ファイルで全てのアプリケーション(githubやfirefoxなど)をセットアップできる。mac版Puppetのような位置づけ。OSS。
  • hubotの紹介:チャットに駐在するbotに呼びかけて、そのbotに作業をしてもらう(ChatOpsという表現)。作業ターミナルを他の人に見せる。共有されるコマンドラインという位置づけ。新人も熟練者のコマンド操作を見て勉強する。(ビルド回数63万回だった。。。)。パスワードがChatに表示されるときは、hubotが自動で非表示してくれる。自分でコマンドを拡張できる。
  • ログがたくさんの出てチャットが使えなくなるので、チャットルームをたくさん作った。競合などで問題はこれまで起こっていない。
  • 参考:hubotで快適BOT生活

DevOps時代のインフラ構築と開発プロセス

迷ったら健全な方へ

  • Being healthy dev and ops in Cookpad // Speaker Deck
  • クックパッドのひと。
  • クックパッドのリリースプロセス。非公開→ユーザ限定→全体公開。
  • Opsは権威的になってはいけない。
  • 権威的になると、1.開発者個人のオーナーシップが減衰(自分のモジュールを自分の意思でリリースできない)。仕事が楽しくなくなる。2.承認を通すテクニック、政治が発生(承認を通すことが目的になり、ユーザを見ていない)3.コミュニケーションで解決する部分はギリギリまでそうするべき。
  • 完璧ではなく健全さが大切。ユーザ・組織に利益なほうをビジネス観点で考える。
  • クックパッド(開発者60人:開発者43人、環境整備12人、インフラ5人)は現在できているが、組織が大きくなるとエンジニア個人の意思決定ができなくなる可能性がある。
  • ログの扱いは例外がでたら、fluentd→mongoDBに格納する。大体はデプロイ後に発生しているので、開発者がデプロイ後1時間見守るルールがある。障害を見逃したらそのヒトのせい(責任)。

Effective Monitoring with statsD

所感と雑記

  • 全体的に楽しかった。お弁当美味しかった。
  • 英語の発表があったが、翻訳があったので助かった。英語わかんなかった\(^o^)/
  • 翻訳者の一人の方が、めちゃくちゃ丁寧・綺麗な翻訳をしていてすごいと思った。専門用語を多かったのに。翻訳者にお話聞きたかっった。
  • Ops側の話が多く、普段聞けない事例やツールの話が聞けたのでよかった。hubot試してみたい。
  • デプロイ/リリースの話を聞くと、自社とだいぶスピード感・自由度が違う気がした。組み込み製品とWebサイトだからしょうがないか?Web系ではQA評価などが無い印象を受けた。機能実装完了→微調整→コードFix→リリースっていう流れ(全体で1ヶ月程度)。
  • GitHub Inc.のレベルの高さを感じた。ツールの作りこみ感、拡張性がすごかった。自由な拡張性で、開発者が楽しんで作業をしている姿が目に浮かんだ。毎週一人新しいヒトが入ってくるという流動性がすごい。
  • 今回、クックパッド関連の発表が所々にあり印象に残った。存在感がすごかった。勢いを感じる(開発者絶賛募集中らしい)。
  • クックパッドもそうだが、徐々に成長(改善)していった感がある。自社は成長過程を飛ばして、最初から大規模開発を行っているが。。。クックパッドもそうだが、徐々に成長(改善)していった感がある。クックパッドは最初一人でDevもOpsもやっていた。それからメンバーが集まって作業が分散化された。「最初はだれでもDevOps」。

お昼

お昼ごはんについては、Microsoft様から無料のお弁当が提供されました(´・ρ・`)感謝。
f:id:Namihira:20130928125044j:plain