まず、Developers Summit 2013 Summer 開催情報は以下のとおりでした。
名称：Developers Summit 2013 Summer （夏サミ2013）
会期：2013年8月1日（木）
会場：ベルサール渋谷ファースト（東京・渋谷）
http://www.bellesalle.co.jp/bs_shibuyafirst/access.html
受付場所：総合受付（2F）
ちなみに参加した感想ですが、とても満足のいく内容でした。自分の Devops の理解が間違っていないことを確認できたので。
そして、Developers Summit は長いこと開催してきてるだけのことはあって、先日のAWS Summit とは違ってファシリテーションがかなりしっかりしていました。満員の会場でも椅子と椅子の間がかなりおおきく余裕がとられていたり、写真撮影を基本的にオッケイにしてくれていたり、と。これまで培ってきたナレッジを活かしているというのがよく分かる運営だったと思います。あと、「夏サミ2013」開催、講演関連資料のまとめ：CodeZine
書籍プレゼントのためのスタンプラリーイベントなどもよかったですね（まあ、わたしはもらえませんでしたが... ）
では以降に今日わたしがとってきた以下の Devops 関連の 5 セッションのメモを共有しておこうと思います。
- S1 DevOpsは開発現場とビジネスの間に何を生むか？
- A1 基礎からわかるDevOps
- A2 DevOps × Enterprise
- A3 Hadoopを使わない独自の分散処理環境の構築とその運用
- A5 黒帯デベロッパーたちにきく！「DevOpsって本当のところどうなのよ？」
#natsumiS1 DevOpsは開発現場とビジネスの間に何を生むか？
Devops とモバイルどちらも破壊的イノベーションカルチャーの変革が必須だという考えから今回はこの2つをテーマに
Devops ゴレンジャーをつくってみた Publickey の新野さんを筆頭に。
➤ 自己紹介
− IT ジャーナリスト / Publickey ブロガー
➤ Devops 国内で盛り上がりつつある
- 2010年頃 Devops の記事や勉強会の説明がはじまる
- 201103 Publickey で記事紹介
- 201202 Datadog & DevOps meet up
- 201205 DevOps Days Tokyo 2012
- 201210 国内で Chef の商用提供開始、クリエーションライン
- 201308 natsumi 2013 テーマ Devops & Mobile
➤ Devops の始まりと広がり
- 20090603 Oreilly の Velocity で 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
- Flickr は1日に10回 deploy してるんだぞ、と話題に
- 20091030 Devopsdays Ghent 2009
- コンサルタントの Patrick さんが主催
＊＊＊＊＊
- 2010にシドニーを皮切りにどんどんと世界に広まりを
➤ 最初は相手にされなかった Devops
- 開発と運用が協力するという考え方は馬鹿げているという風潮があふれていた
- Patrick Debois 氏が最初の Devops Days を振り返ってブログを書いている
＊＊＊＊＊
- Devops の大事なことは原点である
- 10 deploys per day dev & ops cooperation at Flickr
- に書いてある（読みたい）
- 今回はそれを3枚にまとめてみた
↓
＊＊＊＊＊
- 1枚目：
- ビジネスは変化を要求してくる
- 変化にともなうリスクを、ツールとカルチャーで低減する
- （あまり変化を要求されていないシステム、組織では Devops は要求されていないともいえる）
- 2枚目：
- カルチャーとは？
- Dev と Ops のラブが大事
- 3つ目：
- ツールとは？
- Automated Infrastracture (インフラの自動化)
- Shared version control （ git など )
- One step build and deploy （ボタンひとつでデプロイ完了）
- ツールとは？
➤ Dev と Ops なぜ協力しなければならないか
- 新機能をリリースしつづけることも、安定稼働も、ビジネスの観点からはどちらも大切
- なので協力しなければいかんと
➤ Dev と Ops の協力関係のあり方
- (Dev)
- 考え方：継続的デプロイメント
- ツール：
- アジャイル開発
- Git
- Jenkins
- 自動テストツール
↓ カルチャーがつなぐ
- (Ops)
- 考え方：Infrastructure as Code
- ツール：
- Cloud
- Chef
- Puppet
- Vagrant
＊＊＊＊＊
- 大事なのは、この協力の結果、ビジネスはうまくいっているのか？
- Devops うまくいきはじめると本番環境とおなじようなテスト環境が必要になったりするので、ビジネス側からみるとコスト増にみえたりしてしまうので。
- そしてそれを測るために
- ログ解析、メトリクス取得をして、ビジネス側との間のコンセンサスをとれるようにしておく
➤ メトリクスはすりあわせが肝心
- どんな情報がログから取り出せるのか
- その中のどれがメトリクスとして使えるのか
- メトリクス以外で評価すべきことはあるのか
- こうしたことを Dev, Ops, Biz ですりあわせることで、 Devops を効果的に実践していくことができる
➤ エンタープライズでの課題
- もともとスタートアップのなかで生まれた考えなので、
- 日本の SI ビジネスに Devops は適用出来るのか？
- ビジネス側の理解はかかせない
＊＊＊＊＊
- Biz と Dev, Ops は Devops のメトリクスを測れるのか？
- Biz はメトリクスを提示できるか？
- dev, ops はログを説明できるのか？
- メトリクスがなくてもビジネスは前進できるのか？
- 互いに共通理解が必要
＊＊＊＊＊
- 取捨選択が必要
- なにを Devops で解決するべきなのか？
＊＊＊＊＊
- そもそもアジャイルや Cloud の採用にハードルがあるのではないか？
- こうしたハードルを越えていくためにはどうしたらいいのか
- 実はこの課題に答えはないｗ
- それぞれケース・バイ・ケースで乗り越えて行かなければならないという認識をもってのぞんで行かなければならないということがいいたい
DevOps at ChatWork
スライドへのリンクは ➤ こちら
➤ 自己紹介：山本正喜氏
➤ チャットワークのコンセプトの説明
- クラウド型ビジネスチャットツール
- （チャット、タスク管理、ビデオ通話）
- 22万ユーザを突破した
➤ ChatWorkの規模感
- ユーザ数：22万
- 利用国数：130国
- メッセージ数：1億2千万
- チャットルーム数：1200万
- タスク数：530万
- ファイル数：420万(8.5TB)
＊＊＊＊＊
- わりとミッション・クリティカル
- ビジネス利用されているので
➤ Devops
- Devはどんどん機能追加したい、 Ops は安定運用したい
- 最初はピンとこなかった、なぜなら、上手く行っていると思っていたから
➤ Chatwork の Devops の考え方
- 極力運用しない
➤ ChatWorkの運用体制
- Dev: 11人にたいして
- Ops: 2 人
- しかし、運用は実質1名
↓では、これがなぜできるのか？
➤ 大規模チャットシステムにおける運用の勘所
- データベース： write heavy
- ファイルサーバ： 要スケールアウト
- リアルタイム通信： C10k問題
↓ - ハイブリッド Cloud で運用 (AWS と Google)
➤ 利用している SaaS
- 監視： New Relic
- ログ解析： sumologic
- ネットワーク監視： cedexis
- モバイル開発支援： TestFight, deploygate
- ソースリポジトリ： github
- 仕様企画書： mindmeister
- 課題管理： PIVOTALTRACKER
- コミュニケーション： ChatWork
➤ 利用している Product
- 障害監視： Nagios
- サーバモニタ： MUNIN
- メール通知： ChatWork
- ビルドデプロイ： 自作PHP, rsync, github, Jenkins
- 検索サーバ： mroonga
- タスクキュー： 自作 php, MySQL
- KPIトラッキング： 自作 php, MySQL
- ソーシャル監視： 自作 node0, MongoDB
➤ Lean なサーバアーキテクチャ移行
- 成長にともなって IaaS 比率をあげていく
➤ 障害発生時のフロー
- 障害発生時には、基本的に自動復旧（ PaaS なので）
- 自動復旧ができているかどうか Dev と Ops 両方に通知する
➤ DevOps + Biz
- ビジネス部門との協力は不可欠
➤ 全体的にみた Dev/Ops/Biz
- 全員のミッションは：顧客価値の最大化
- Dev: プロダクトの品質向上
- Ops: 安定したサービス展開
- Biz: リソース確保
➤ ChatWork で取り組んでいること
- コミュニケーションは基本的にチャットで
- これで言った言わないが発生しない
＊＊＊＊＊
- プロジェクトごとにグループチャットを作成し、関係者を全員いれる
＊＊＊＊＊
- タスクの生まれる背景を共有する。言われたことだけをする作業者はつくらない
➤ 経験の話
- トラブル発生時の Dev と Ops の協力関係
- 原因究明をして、原因が Dev 側にあるなら Dev が解決する
- 大抵の場合は Ops の側で解決するが。（原因究明は Ops 側が責任を担う）
Enterprise で Devops
スライドへのリンクは ➤ こちら
➤ ビジネスと戦略的な IT
- Enterprise ではビジネスサイドから Devops のニーズがでてきている
＊＊＊＊＊
- IT はビジネスにとってのコストセンターからビジネスの牽引役に
➤ Enterpriseでのユーザとは？
- お客様
- そして、従業員
➤ エンタープライズアプリケーションの進化
- 基礎体力づくりのための IT と攻めに出るための戦闘力としての IT を分けて考える
➤ Build - Measure - Learn
- lean startup のモデルにマッチする
➤ ビジネスにフォーカスした戦略的な IT
- アプリがきちんとうごいていれば、インフラのどこかに問題があってもビジネスに対する問題にはならなくなってきた
- 従来通りのセオリーで運用していては、ダメ
➤ Dev と Ops の協力関係
- サイクルタイムと MTTR のメトリクスの共有
- 共通のゴールをもつ
- 成果物の共同所有
- システムの自動化
➤ DevOps への主な課題のポイントと解決策のポイント
➤ MS と Devops
➤ QA
それぞれ短いにこしたことがない
- サイクルタイム：デリバリーまでの時間
- ビジネスにおける Devops 、ビジネスサイドに理解できることが重要
- MTTR：平均のシステム復旧するまでにかかる時間
- これからの時代、 IT 環境はこわれることを前提にしなければならないから
Devops Opscode Chef
- スライド回しが早すぎて、ほとんどメモするのはむずかしかった
- 基本は写真をみるが、なるほどな部分をメモしなおした。
➤ 自己紹介 @urasko 氏
➤ Opscode Chef
➤ Automated Infrastracture
➤ Configuration Management
➤ infrastructure as Code
➤ Repository Management
➤ Testable Infrastructure
➤ Idempotence, Convergence
➤ Cloud Management
➤ Continuous Delivery
➤ Code Can...
目的語はすべて
➤ Coded Business
➤ Dev + Ops + Change
➤ Demo.
➤ QA
- エンタープライズには売れていますか？
- 日本ではまだまだ
- エンタープライズで使われることを想定して機能追加はどんどんしていっているけれど
- 日本と米の違い
- ガバナンスの違い、カルチャーの違い（変化に柔軟か）
＊＊＊＊＊
- Opscode は hosted chef server を提供している
＊＊＊＊＊
- Chef はコードを書かないといけないが、マスターは敷居が高いか？
- Ruby に慣れているならとっつきやすいと思っている
サンドボックスから開放せよ！
➤ 自己紹介：藤井智弘氏
➤ エンタープライズ、 Devops
- アジャイルが Biz と Dev をつなげたよね
- Dev と Ops をつなげるのが Devops
＊＊＊＊＊
- エンタープライズにはふたつ
- サンドボックスタイプ：今日のこれまでのエンタープライズのタイプ
- BETAタイプ：ベタなという意味
➤ BETAなエンタープライズの特質
- しがらみ
- スキル低い
- 別にそんなに頻繁にリリースしない
➤ ギャップは BETA なればこそ
- （BETA、もう型ができてしまっている成熟したエンタープライズと解釈した）
- Ops が主導する Devops
- スピード＆ビジネス推進性ではなく、効率化と低コストの推進
➤ アクティビティベースの成熟度
- 後日、ブログに up されるとのこと
➤ リリース・プロセスの効率化
- 不適切なタイミングで不要なテストをやり過ぎてないか
- モデル駆動
- テスト環境の共有（プロジェクト単位ではなく、みなでスケジューリングして
➤ リリース・プロセスの成熟化
➤ サンドボックスから開放せよ
- リリースが頻繁でなくても Devops は必要
- 参考： hp.com/jp/alm
➤ QA
- リリースを成熟させる文脈のなかで Devops を適用すれば、 Devops の適用範囲は広がる
＊＊＊＊＊
- カルチャーを変えていくことが結局は肝
#natsumiA1 基礎からわかるDevOps
➤ 自己紹介 @ryuzee
➤ 開発や運用における大きな方向性の話をする
- ツールの話はでてこない。
- コンテキストによって使うツールは変わってくるから
➤ ビジネス環境の変化
- 総務省の ICT の経済分析に関する調査（H23）より：
- 設備投資の中における IT 投資の割合が2割をこえた
- 企業の戦略実現のためにITをつかうように状況が変化
- ITを活用できる企業が厳しい生存競争を勝ち抜くことに
- ソーシャルゲームのビジネスモデル
- 証券会社のアルゴリズム取引
➤ Amazonの3つのコアビジネス
- コンシューマ向けのビジネス
- セラー向けビジネス
- どちらも IT インフラの上でうごいている
- 求められているのは、スケーラビリティ、可用性
↓ - ITインフラビジネス
➤ Amazon のビジネスモデル
- ジェフ=ベゾスの描いた図
- loop: selection > customer experience > trafic > sellers
- IT にビジネスが依存している
➤ DevOps の起源
- Velocity 2009 での当時 Flickr に所属していた 2 名が発表したプレゼン
- Developer と Operator の協力の話をしている
➤ 開発者と運用者の壁
- 開発者は新しい機能をどんどんつくる
- 運用者は安定した運用をしないといけない
- それぞれミッションが違う
- そのために、それはオレの仕事じゃない問題が起こる（セクショナリズム）
- サイロ化が起こる
- （問題が起こった時ほど、責任のたらい回しをしてしまったりする）
➤ よくある光景
- なんでアプリをちゃんとつくらないんだ？
- 運用で何とかするのが仕事でしょ？
＊＊＊＊＊
- それが、組織のあちこちで
- このコードかいたのはオレじゃない
- この作業は hoge さんの担当です
- それは規則
- hoge 部門がいつもぎりぎりに
- こっちにも都合がある
＊＊＊＊＊
- 閉じた組織を最適化しても全体は最適化しない
➤ サイロ化によるオーバーヘッド
- 価値を生む際のオーバーヘッド
- 価値を生み出すのに使う時間
- 価値を生む作業に時間を使えていないということはムダがあるということ
➤ ビジネスは変化する
- startup ではじめたときから、ずっと同じビジネスをしている会社は稀
- 変化の方向性は無限。しかし、変化は避けられない。
➤ システムの機能の利用割合
- Standish の 2000 年調査
- システムの機能は 45% 全く使わないという結果
- 全く使わないとほとんど使わないで 64%
- それをもし作らなかったとしたら、コスト削減にだってなる
＊＊＊＊＊
- Devops 以前の問題
➤ では本当に必要なものがわかるのか？
- わからないから、全部入りを営業が提案してきたりする
- そうするとビッグバンが起こってしまう。
- それをさけるには？
➤ フィードバックループ
- 顧客とビジネスの間のフィードバックループを高速にまわす必要がある
➤ AWS の例：イノベーションのペース
- 2007: 9
- 2012: 159
- これも顧客との間のフィードバックループを高速にやれるようにしているための成果
➤ Devops とは？
➤ Devops はフレームワークではない
- 決まったやり方があるわけではない
- 実装は現場によって異なる
- そこは考えないといけないということ
↓しかし、それを支える考え方はある
➤ 文化によるサポート
- お互いの尊重
- お互いの信頼
- 失敗に対する健全な態度
- お互いを避難しない
➤ ツールによるサポート
- インフラ構築の自動化
- バージョン管理
- CI
- デプロイ自動化
- 監視
- 情報共有
- ダッシュボード
- ただし、全部やればいいわけではない
➤ Devops は銀の弾丸ではない
➤ あるべき姿
- 価値を生み出すオーバーヘッドを減らすこと
- そのために
- ゴールの共有
- お互いの協力
- ツールの使用
➤ Devops＝自動化ではない
- ただし自動化はリスク低減とアジリティの向上に役立つ
➤ Manifesto for Agile Software Development
- 12個の原則
- その中で一番大事なのは
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
↓その方法論のひとつが
- スクラム（やるべきことを優先順位をつけて1つづつ確認）
➤ XP 19 個のプラクティス
➤ 共通理解
- どこまで品質を追求するのか
- 何を持って出荷可能とするかを定義する
- 定義は Dev + Ops + Biz で作成する
- 自動でチェックできるものを増やせば、サイクルタイムが短縮される
- 開発や運用での知見を定義に反映させる
➤ 品質自体は作りこみが必要
➤ 継続的デリバリー
- 繰り返し型の開発（スクラム） -> CI（Scrum+XP) -> CD (Lean)
➤ Feature 単位に完了できるように
➤ Amazon の例で言うと
- 平均 11.6 sec ごとにデプロイ
- 1時間で 1,079 回のデプロイ
- 1回で平均1万台のホストへデプロイ
- 最大で3万台のホストへ同時にデプロイ
➤ 自動化による時間の使い方の変化
➤ テスト自動化（しかしアンチパターンもある）
➤ Infra as Code （しかしアンチパターンもある）
➤ Cloud
- 初期投資不要
- 利用した分だけ
- Elasticity
- Agility
- コアコンピタンスへの集中
➤ Design for Failure
- すべて壊れる前提で
- サーバもアプリも
- 1箇所壊れてもあがるように
- 疎結合アーキテクチャ
- 自動復旧、自動伸縮
➤ Devopsの進め方
➤ Devops いつやるの？
- 今でしょ？の前にやることがある
- 組織のゴールを正確に理解している必要がある
- トヨタ生産方式においてもムダについての言及がある（付加価値を高めない各種現象や結果をムダと呼ぶ）
- ムダはなくさなければならない
- 効果があるところからやる
➤ 小さく始める
- いきなり自分たちのプロセスを大きく変えない
- 小さな取り組みを継続的に
- 取り組みの成果を確認する（効果がないならやめればいい）
- 小さな成功を早期から繰り返す
- 組織やプロセスを着実に成長させる
➤ Devops 一日にしてならず
- アタリマエのことを当たり前にやる
- バージョン管理
- コーディング規約
- コードレビュー
- テスト自動化
- ドキュメント etc, etc...
- 基礎がないのにいきなりダンクは決まらない
➤ 推進するためには組織の中に推進役が必要
- 組織づくり
- 単に Devops 専門組織をつくってもしかたがない
- 全員が同じゴールに向かっているかどうかが大事
- チームのゴールと個人のゴールを一致させる
➤ そしてうまくできたら
- ちょっとのことでもみんなで讃え合う
- なによりも地道な改善が大事
➤ 自分の組織にとっての Devops とは何なのかを定義する。どうすれば成功なのか考え、着実にやっていく
➤ AWS: re:Invent の宣伝でおしまい
#natsumiA2 DevOps × Enterprise @tomohn
スライドへのリンクは ➤ こちら
- 今日の資料は後ほど、今日中に公開。
- できるだけ demo を多く。
➤ 戦略的な IT がビジネスの成功を左右する時代に
- なぜならエンタープライズのお客様からアジャイル、 Devops ってどうなの？という質問をよくうけるから
- そう、ビジネスからの要請
- いつまでもコストセンターと言われているようではダメです
➤ ビジネスと IT は融合している
- ビジネスのアジリティに対応する IT
- IT の力でビジネスをスケール
- もう、 IT はコストセンターではない（繰り返し）
- もはやどちらが先ということもなくなっている
➤ 意思決定はどうなのか？
- IT部門中心から、経営者中心、そして顧客中心へと変わってきた
➤ テクノロジーの観点からみると？
- クラサバから、 Web へそして Device & Service へ。
- 複雑化はより増してきている
➤ 2種類の IT
- 基礎体力と戦闘力（キーノートと同じスライド）
＊＊＊＊＊
- 基礎体力の部分は、他の会社もやっている。例えばパッケージとそのカスタマイズ。
- 隣もやってるからやろう、というのはスタートラインにたったに過ぎない
- 他社に勝つための部分に注力しなければ意味が無い（パッケージを買うのではなく、差別化できるものを自らつくる：カスタムアプリケーション）
➤ エンタープライズの IT ユーザ
- お客様と従業員
➤ ムーブメントはすでにエンタープライズに
- もはや Devops はスタートアップだけのものでははくエンタープライズにも波及してきている
- エンタープライズも
- 顧客にダイレクトに響く活動
- つながる商談の継続
- 先進的な業務環境
- 独自性と競合優位性
- に注力して競合に勝たなければならない
➤ 先進的なビジネスの要素
- アプリケーション
- アプリケーションライフサイクル
- データセンター
➤ MS が使い続けている Devops の図
- スピーカーの解釈で言う Devops は継続的に価値を提供しつづけるための仕組み
➤ Ops
- 仮想化からシステム自動管理へ
- 多くの業務アプリを運用
- アプリの質が課題
- 必ずしも開発が絡まないシステム
- 長期戦かつ、安定が責務
- 情報システム部門が担当
- ゴールキーパー、守護神
➤ Dev
- ブラックボックスからの脱却
- ビジネスに貢献するアプリを開発
- 開発サイクルの短期化への対応
- 運用がかならず伴う（つくっておわりのものはない）
- 短期戦、変化することが課題
- 開発ベンダーが担当
- ストライカー、特攻隊
➤ 自動化
- ムダ取り
- 共通ゴール
- 透明性
- そしてそれらを共同所有することが重要
- アジャイルは Devops の中でも活かされる
➤ Devops readiness
- Problem: 運用要件を満たしていない SW
- Solution: 早期の要求獲得と品質のつくりこみ
- Value: ビジネス価値に到達する SW
- 定期的に短い期間で継続的に価値を提供することが大事になってくる
➤ Mean Time To Repaira
- Problem: 運用中の障害検知と解決が極めて困難
- Solution: 本番環境でも開発プラクティスを実践
- Value: MTTR の短縮
- できるだけ本番に近い環境で常にテストをまわしている
➤ Devops とプラットフォーム
- Visual Studio と System Center を使った Demo
＊＊＊＊＊
- Team Foundation Server を使って、開発のトレーサビリティの高さを紹介
➤ これからは Ops 側からソースにアクセスしてデプロイするケースも増えてくると思います
➤ MS の製品をおっかていると開発のアプローチが勉強になるかも
- プラットフォームベンダーとして IT, Devops のプラットフォームを継続的デリバリーしていきます
➤ 宣伝： Team Foundation Service
- 今起きてることをすべて TL に載せたりできるようになっている
➤ 宣伝： Cloud OS
#natsumiA3 Hadoopを使わない独自の分散処理環境の構築とその運用
➤ 自己紹介： IIJ の 前橋孝弘氏
➤ 分散システムを開発した動機について
- ISP においてサービスの状態を把握するということが必須だった
- そのために大量のログデータを扱う必要があった
＊＊＊＊＊
- ISP における大規模データとは？
- トラフィックデータ
- 時系列 Web アクセス数
- ほぼすべて時系列のデータ
- 分析したい項目、抽出条件は多岐に渡る
- 定型的な分析はなかった
- e.g. トラフィック情報の解析：約30カラム、数億 record / day
- ルータ自体がログを吐き出してくる
＊＊＊＊＊
- 巨大なデータの処理といえば、 Hadoop がデファクトだが…
- HDFS, MR の軽い説明
- その Hadoop に相当するものを自作した
- ddd と pmuxa
- ddd (MRに相当) + ddfs (HDFSに相当)
- pmux (MRに相当) + GlusterFS (HDFSに相当)
＊＊＊＊＊
- Hadoop を使わずに自作した理由
- 一番の理由は、やってみたかったから！
- きちんとした理由としては
- Hadoop はバッチ処理に特化している
- 自社の要件はリアルタイム処理があった
- 自社開発でノウハウをためるため etc...
＊＊＊＊＊
- 分散処理の原理は難しくない
- データをあらかじめ各ノードに分散配置し、各ノードで並列実行
- 原理は簡単なので自分たちでできると思った（てこずったところももちろんあったが）
＊＊＊＊＊
- Cloudera の資料からの抜粋
- 最も速い MR job の時間でも 24 秒かかると書かれていた
つまり - Hadoop が向いているのは
- 24秒の遅延が気にならないような巨大バッチ処理
- やることが決まっている定形処理
＊＊＊＊＊
- 一方でやりたかったことは
- データ分析者が試行錯誤でデータ分析したかった
- 分析に必要なパラメータは多様であり、事前に網羅することは困難（非定型）
↓ - データをナマのままで保存し、オンデマンドで抽出したい
➤ 開発したものの機能と仕組み
- 開発したもの (1) ddd
- 大量の時系列データを蓄積し、短時間で検索・集約結果を返す
- UI をみせて、使い方を説明
- アドホッククエリが大半、それをグラフ化
＊＊＊＊＊
- ddd の特徴
- 時系列データに最適化した分散ファイルシステム
- 自動レプリケーションによるデータ冗長化
- 楽観的タスクスケジューリング（応答時間の短い MR）
- 大規模データ処理のための分散システムの実装と応用：論文
＊＊＊＊＊
- MR によるグラフ生成
- 要求があってから生データに対して分散処理を開始してグラフ化
＊＊＊＊＊
- 応答速度
- 極めて小さいデータを何もせずに素通しするのにかかる時間
- hadoop だったら 19 sec だったが ddd は 0.12 sec
＊＊＊＊＊
- 2000タスクの処理グラフ
- 台数が増えると処理時間が減少しているのが見て取れる
- 対数でみるとわかりやすい。そしてわかったのは台数が増えてくると多少オーバーヘッドがでてくる
- (Hadoop は台数が増えてもオーバーヘッドがそこまで大きくならないと思うが、とのこと)
＊＊＊＊＊
- 開発したもの(2) pmux
- pipeline multiplexer に由来
- OSS
- Github に公開している
- Gluster Forgeにもミラーされている（一応、 GlusterFS の公認）
＊＊＊＊＊
- 標準入出力を介して MR するための Commandline tool (hadoop streaming に相当)
＊＊＊＊＊
- GlusterFSとは？の説明
- FUSE で mount して普通の FS として見える
- フィアル名で分散する特徴がある
- IT検証ラボ - 分散ファイルシステムのGlusterFS：こんなとき、どうなる：ITpro
＊＊＊＊＊
- pmux の分散処理の原理
- $ grep PATTERN *.log
- の処理を分散して各ノードでやっているようなイメージ
＊＊＊＊＊
- 使い方の例： word count など
＊＊＊＊＊
- ddd と pmux に共通していること
- デバッグとテストが大変
- そのため、開発の初期の段階でシミュレーターをつくった
- ネットワークをモック化 (複数ノード環境をシミュレーション)
- テストへの組み込み (CIツールをつかって)
＊＊＊＊＊
- 実環境でないと分からないこと
- ノード間通信の集中に起因
- コネクション数の限界 (net.core.somaxconn)
- パケットの消失 (スイッチのバッファの限界を超えた？)
↓対策 - ノード間の通信をキューを使って制御した
＊＊＊＊＊
- やった甲斐はあったか？
- あった
- 社内のバックエンドで活躍中
- 分散処理のノウハウ取得に役立った
➤ その運用について
- 実は特別なことっていうのはやってない
＊＊＊＊＊
- 分散処理プラットフォーム dplat をつくった
- 社内向け PaaS
- サービスごとに SLA が違ったりするのでひとつの大きなクラスタではなく、複数もってる
- 東京、大阪、松江に DC
- 松江のはコンテナ型 DC
＊＊＊＊＊
- 運用の基本思想
- なるべく楽をする→なるべく自動化
- 機材は壊れることを前提→
- 監視とモニタリングはしっかりやってる
＊＊＊＊＊
- サーバはネットワークブート
- OSなどのシステムはメモリファイルシステム
- 再起動すると初期化される
- 起動後に Chef を使って必要なものがインストールされる
- 仮想化は使っていない
- HDD は搭載しているがデータの格納用途のみ (RAIDはつかってない)
- ddd や GluserFS で冗長化
- 故障はそれなりに起きることが分かった (HDD, NIC, memory, 電源 etc...)
→でも、適切に冗長化している結果、データが失われたことはない
＊＊＊＊＊
- 監視
- 死活監視、ポート監視
- ディスク残量監視
- MR のパフォーマンス測定
＊＊＊＊＊
- モニタリング
- ファイリティレベル (温度、消費電力)
- 各種リソース (disk, memory 使用量)
- アプリケーションレベル (各 API call 数など)
- 監視、モニタリングは内製している
- そういう文化だそう
➤ まとめ
- ISP はサービス状態の把握のために大量データを扱う必要あり
- 分散処理システムを独自に開発
- 運用はいまどきの普通のやり方をしている
#natsumiA5 黒帯デベロッパーたちにきく！「DevOpsって本当のところどうなのよ？」
- パネルディスカッションなので、気に留めた言葉だけ書いておきます。
＊＊＊＊＊
- Devops のダメ出しをスーツ派代表がして、 Devops を実際にやっている側のギークが反論をするという企画
＊＊＊＊＊
- 自己紹介：宍倉さん @orangesupporter
- 名刺管理app: Eight の開発エンジニア
- 自己紹介： いとうなおやさん
- 35 歳になったが、まだまだバリバリコードを書くと宣言
- 入門 chef Solo 買ってください (4,000 部ほど出た)
- 自己紹介： 大石良さん（大石蔵人之助）
- 持ちネタは切腹、今日のトークセッションで得るもの無かったら切腹します
➤ Devops って本当のところどうなのよ？
- やっぱり実際やってる二人に聞いてみよう
➤ Devops の成功例
- 宍倉さん(Eight)の場合
- 10名の開発スタッフ、 Ops は1名
- 明確な役割の分担はない
- ただ、最初から Devops していたわけではない。クローズドベータのときには、サーバエンジニアにサーバをつくってもらい、いちいちデベロッパーがデプロイしていた。
- 正式リリースを機に AWS に乗り換えることを決めたことを転機に、 EC2 のインスタンス構築を自動化しようと決めた
- そのとき使ったのは Capistrano
- Ops 側が作った Chef と Dev 側がつくった Capistorano 双方をコラボレーションできるように議論をした
- ツールは自前が多い
＊＊＊＊＊
- なおやさんの場合：
- これは Devops というものを紹介
- はてなのとき、 1000 台のサーバの管理を Ops 2-3 人しかいないなかで回していた
- Dev 側の要求に応えられるように速いデリバリーができることを意識した
- 当時やっていたのは PXE boot と Chef のようなツールの組み合わせを使い始めた
- その後、田中さんが Puppet をつかおうといいはじめた
- テスト駆動インフラ構築など 2009 の Velocity の前から動きはあった
- 自分は少なくともやってたぞ、と
➤ Devops の定義とはなんぞ？
- なおやさん：
- 広義では
- Dev と Ops がくっついて、アプリケーション開発の文脈で、自動化、簡略化を目指した
- 狭義では
- Chef や Puppet を使って作業を簡略化
- 広義では
＊＊＊＊＊
-
- 今は Cloud が当たり前になったので、大量の VM を一斉に準備するといったことが普通になった
➤ Devops のメリットってなんぞ？
- 宍倉さん：
- 開発の品質、スピードに大きなメリット
- Dev と Ops の相互理解のために努力していること：物理的にお互いの席を近くするとか
➤ Devops やってますか？という質問に本日挙手したのは
- 0 人！
- これが事実？
- 使われてないのには、理由があるはず
➤ 何が阻害要因なのか？
- 3つ考えてみたらしい
- ハードル高いんじゃないんか？
- コード書くのはインフラエンジニアにはハードル高いんじゃ？
- お客様からしてみたらDev と Ops をシームレスなんていう意識がないのでは？
- Devops をやることによって、開発者が運用までやることになると、退職のリスクが大きくなっちゃうんじゃないか？
➤ ハードル高いんじゃないんか？
- 宍倉さん：
- 大丈夫でしょう、むしろこれが醍醐味でしょう
- ノウハウは web に転がってる
- Dev 側がインフラエンジニアをサポートしてみたりしてもいいんじゃないか、例えばペアプログラミングしてみたり
- もちろん、うーんうーんと悩んだりはインフラエンジニアはするのだけれども
➤ お客様からしてみたらDev と Ops をシームレスなんていう意識がないのでは？
- なおやさん：
- ここはたしかにこういうことはあるかなぁと思う。
- アジャイルと一緒で、なんでもかんでも Devops ということではない
＊＊＊＊＊
-
- アジャイルで響かなくなってきたから今度は Devops というところもあるのかもしれない
＊＊＊＊＊
-
- Devops を導入する決め手は？
- webservice のようなもの
- どんどん新しいものをつくって、しかもそれを継続的に運用しなくてはいけないもの
- AWS などで HW の制約がなくなってきてる中で、従来通りのやり方をしてるほうがむしろおかしいんじゃないか
- Devops を導入する決め手は？
➤ Devops をやることによって、開発者が運用までやることになると、退職のリスクが大きくなっちゃうんじゃないか？
- なおやさん：
- むしろ逆でしょう
- 運用担当者の中にしかなかった暗黙知を全部コードで表現することによって全部外部化してしまいましょうというのが発想
- もし初心者がサーバ構築したかったら、 Chef のコード読めばいいでしょう
- ちゃんと動くんですか？の不安解消のためにテストを事前に書く
- こういうことをやらせてくれない会社のほうが退職するのでは？
➤ Devops が Dev と Ops と Biz のコミュニケーションの話しなら Biz の話きかないとだめじゃね？
- Biz側から、 Dev と Ops なんてどうでもいいんだが、 Devops わざわざやる意味なんかメリットあるの？と聞かれたら？
- 宍倉さん：
- 正直にいうと、会社一丸で開発すればいいじゃないか、とは思う
- 速くアウトプットすることが大事なので、そのためには Devops が必要
- しかもそれをすることで価値の創出にかける時間をより確保できる
- 宍倉さん：
- Devops 以外に方法はないの？
- 宍倉さん：
- 現状ではそれがベストだと思っている
- Dev と Ops がわかれていると、お互いにわからないことが多いのでどうしてもスピードがでなかった
- 宍倉さん：
- (1) Devops を実現するためには Dev と Ops が相互協力できるような組織になってないんといけないんじゃないの？ (2) Devops はサービスの開発にしか使えなくない？SI ビジネスにはつかえるの？
- なおやさん：
- ひとつめはそのとおりだと思う
- マネジメントの問題でもある。仮にマネジメント問題が解消されなくても Ops 側だけツールをいれるとかいったことはできるが、それでも最後のゴールはなんだ、ということがあやふやになるのは変わらない。Biz, Dev, Ops が同じ方向を向くことが大切だし、それはマネジメントが解決する
- ふたつめはそんなことはないと思う
- なおやさん：
たとえば、自分の開発環境そのものを devops 的につくることだってあるだろう、と
➤ じゃあ、どうするの？
- SI ビジネスの現場に Devops を導入するにはどうしたらいいの？
- 宍倉さん：
- 小さなことから少しづつやっていくしかない
- 全体を動かそうというのはなかなか難しい
- 会話の重要性
- なおやさん：
- お客さん側から AWS 使ってほしい、 Agile でやってほしいといってくるんだが、実際それでやっても満足してくれない
- なぜなら、それはもっと良いシステムにしてほしいというのがお客さんが望んでいることだから
- AWS へ移行してほしい、がやってほしいということではない
- 何をお客さんが望んでいるのかを理解することが大事
- Devops はあくまで目的を達するための手段
- 宍倉さん：
➤ Biz 側からの提案、メトリクスの定義
- クラウド利用でメトリクス取得が容易に
- Dev, Ops, Biz が共通の数字で語り合える基礎ができる
➤ まさか最後に本日のこのトークのねらいを公表
- これから Devops をやろうとするときに、 Biz からマネジメントから聞かれるであろう質問を疑似体験することで、今後に活かしてほしい
