社内勉強会の資料です。

1. +
DevOps勉強会

2. +
DevOpsってなんなの？
 最近流行ってますよね？
 名前は聞くけど、それってなんなの、ってのを説明します。

3. +
DevOpsとは？
 Dev（開発）とOps（運用）が仲良くやろう
 ツールの話じゃないんだ、文化の話なんだ！
（本当は両方必要です）
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

4. +
なんとかしたいこと
新機能を追加しようとする開発部隊
VS
安定稼働を求める運用部隊
 でもどうしたらアプリケーションエンジニアとインフラエンジ
ニアが協力できるの？

5. +
そもそもなんで協力できないの？
 属人性が発生させる特権
 最終確認者、デプロイ担当、インフラ担当
 開発を邪魔する多くは「特権」
 特権は必ず腐敗する
 みんななかよくやりましょうよ！
 at Velocity 2009 , Flickr, J.Allspaw& P. Hammound
 DevOpsの１０ヶ条
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

6. +
DevOpsの10ヶ条
【意訳】
1. インフラを自動化しよう
2. バージョン管理を共有しよう
3. ビルドとデプロイを１ステップで
4. 機能毎にブランチを切ろう
5. システムの指標を見えるようにしよう
6. 現状をIRCにつぶやくbotを使おう
7. 他のメンバに敬意を払おう
8. 他のメンバを信頼しよう
9. 失敗に対して健全に対処しよう
10.非難は無視しよう
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

7. +
DevOpsの目指すところは？
 その前に、本当に必要な機能を作れていますか？
http://www.ryuzee.com/contents/blog/6729

8. +
DevOpsの目指すところは？
 「ビジネスにおいて試行錯誤を多数繰り返したい」
 アジャイルな開発、継続的デリバリー
http://www.ryuzee.com/contents/blog/4241

9. +
DevOpsの事例
 Obama for America（大統領選）
 ボランティア開発
 EC2でVM 4,000台規模 / Puppetで管理
 Githubですべて管理
 1日10回デプロイできますか？ @ Flickr , @cookpad
 1日1000回デプロイできますか？ @amazon
 日本でもWeb系で採用例がどんどん増えているみたいですよ
 Web系のスタートアップ企業はほとんどが採用しているようです。

10. +
再掲：DevOpsの目指すところは？
 「ビジネスにおいて試行錯誤を多数繰り返したい」
 アジャイルな開発、継続的デリバリー
http://www.ryuzee.com/contents/blog/4241

11. +
Continuous Deliveryをするためには？
 開発・運用プロセスをなるべく自動化してデプロイの苦痛を減
らしましょう
Infrastructure as Code
 そのためのツールがいろいろあります。
 でもその前に、、、

12. +
デプロイ・リリース手法いろいろ
その１
 デプロイ・リリースの方法にもいろいろあるようです。
 ブルー・グリーン・デプロイメント
 ２系統を持っておいて、１系統に新しい機能をデプロイして問題なければ切り替える
デプロイ方法
 AWSとか使うと安くなるみたいですよ？
１系統
２系統
ルーター
等 問題なし！切り替え！

13. +
デプロイ・リリース手法いろいろ
その２
 カナリアリリース
 最初に一部ユーザに先行して使ってもらって、問題なければ全体に
リリースする手法
アプリA
試用期間
アプリA’ _
アプリA’
大多数ユーザ
一部ユーザ
問題なし！
全員移行

14. +
デプロイ・リリース手法いろいろ
その３
 ABテスト
 一部ユーザに尐し違うAとBを使ってもらって、どっちのほうが結果が良くなるかをテストする手法。
 文字サイズが１ピクセル小さくなったら20%もクリック率が下がったってこともあるらしいですよ？
 UIの改善手法では公開前のユーザビリティテストと加えてデファクトスタンダートな手法みたいです
よ？
現行アプリA
アプリA’-1
アプリA’-2
大多数ユーザ
一部ユーザ
A郡
全員移行
一部ユーザ
B郡
アプリA’-2 良くなった
悪くなった

15. +
再掲：Continuous Deliveryをするために
は？
 開発・運用プロセスをなるべく自動化してデプロイの苦痛を減
らしましょう
Infrastructure as Code
 そのためのツールがいろいろあります。

16. +
ツール群
 インフラ周り
 OS仮想化(VMWare / KVM / Vagrant )
 クラウド構築（OpenStack / CloudStack / Eucaliptus）
 ネットワーク仮想化(OpenFlow)
 設定反映周り
 マシン状態管理(Chef / Puppet / Ansible)
 デプロイ(Capistrano / Fabric )
 テスト周り
 マシン状態 ( serverspec )
 アプリケーション( selenium / silktest )
 BDDツール( Cucumber )
 管理関連
 プロジェクト管理( Trac / redmine)
 CIツール( Jenkins )
 バージョン管理( git /mercurial / subversion )
 監視関連
 サーバ監視( Zabbix / Nagios / Hinemos )
 ロギング( fluentd )

17. +
インフラ周り
 VMWare / KVM
 OS仮想化基盤、OSの上にOSを載せましょう
 OpenStack / CloudStack / Eucaliptus
 仮想化基盤の管理。AWSみたいなのを作りましょう
 Vagrant
 仮想化基盤の操作をコマンド化/コード化しよう
 OpenFlow
 ネットワークを仮想化/コード化しよう

18. +
VMWare / KVM / Xen / VirtualBox
 皆さんご存知、OSの仮想化。
 OS on OS (Hyper-visor)
 メリットの出る場面例
 物理マシン1台のリソースを余すところ無く使いたい
 HWが今にも壊れそうなので移行したい
 物理マシンが1台しかないけど、いろんなテスト環境がほしい
 デメリット
 オンプレと比較するとオーバーヘッドが大きい

19. +
OpenStack / CloudStack / Eucaliptus
 クラウド環境構築・運用ソフトウェア
 OS仮想化したけど、台数増えるとコマンドとか1台1台Hyper-visorにロ
グインしてVMを操作するの大変ですよね？
 AWSみたいに使いたいですよね？
 メリットの出る場面
 人手で余るような大規模さや、そもそも人手でやっていてはどうしよう
もないときに効果を発揮する
 DCとかHDDが1日1個壊れる環境とか、アクセスが増えた時に自動的
にVMの台数を増やすとか
 GUIも一緒についてくるので、コマンド叩けなくてもなんとかなる！
 デメリット
 マシンが1台しかないのならESXiで十分

20. +
Vagrant
 開発でいちいちGUIなんて使いたくねぇよ。インストール作業も
面倒くさい！コマンドだけでVMたちあげたい！
 そんなあなたにオススメなVagrant。開発のお供に
 メリットの出る場面
 インストール環境をコマンド一発で準備（事前準備は必要）
 まっさらなVMが1分で立ち上がります@MBA。事前にVMコピー、リ
ソース設定は必要です。
 仮想環境を何度も壊すような検証作業や、まっさらな状態からインス
トールする手順を作るときとかに有効（失敗してもまっさらな状態に戻
すのに1分でできます）
 デメリット
 vagrantbox.esで誰が作ったかわからないVMを使う必要 or 専用のVMイ
メージを作成する必要がある
vagrant up

21. +
OpenFlow
 ネットワークの仮想化技術。インフラのコード化。
 OSも仮想化したらネットワークも仮想化したいですよね？
 メリットの出る場面
 同じ物理ネットワーク上でプライベートネットワークを作りたいと
き。いちいちDCに行くのが面倒くさい時。
 VLAN IDの壁を突破できるよ！
 東海地震起こった時に、ネットワークを北陸経由にできるよ！
 デメリット
 まだ実績がDCや国のプロジェクトに限られている

22. +
設定周り
 Chef / Puppet / Ansible
 サーバの状態・バージョン管理。サーバ状態をコード化しよう
 Capistrano / Fabric
 デプロイの自動化。デプロイ手順をコード化しよう

23. +
Chef / Puppet / Ansible
 サーバ構成自動化ツール。インストール後のパッケージ管理や環境設定な
どをコード化。何度実行しても同じ結果になる冪等性という特徴。
 ChefとPuppetはpush型、pull型(サバクラ)の両方ができますがサーバにイ
ンストールが必要です。Ansibleはpush型のみですが、サーバにSSHが
入っていれば利用できます。最近流行ってます。ChefはRubyでかけます。
 メリットの出る場面
 試験環境と同じアプリケーションをインストールしたいですよね？環境構築手順
書を書くなら、そのまま動く手順書を作りたいですよね？
 インストールとかでミスしませんか？私はよくします。マシン10台で初期設定し
ろとか言われたら泣きますよね？
 AWSでOS起動を自動化してもインストール手作業だったら意味ないじゃない！
 デメリット
 ChefとPuppetはリモートマシンに専用のインストールが必要。
 Linux専用です。WindowsにはSystemCenter？があるそうです。

24. +
Capistrano / Fabric
 デプロイの自動化ツール。リモートマシンで指定のコマンドを叩
きます。サーバにsshが入っていれば利用できます。
 CapistranoはRubyでかけます。FabricはPythonでかけます。
 メリットの出る場面
 テスト環境と同じデプロイ手順を行いたい場合。デプロイの手順書はい
つも最新化されていますか？
 幾つものサーバで同じ操作をする必要が有る場合
 あなたはデプロイでミスをしませんか？私はします
 開発環境をいちいち作るの面倒じゃないですか？
 デメリット
 Linux専用。Windowsでは「DevOps workbench」というのがでたそう
な。（capistranoはWinRDでWindowsでも使えるみたいなノリの表示は
出るけど、試してません）

25. +
テスト周り
 serverspec
 インフラのテストをコード化しよう。サーバのインストール状態、
サービス状態、リッスン状態など
 selenium / silktest
 ブラウザのテストツール。アプリケーションのテストをコード化し
よう
 Cucumber
 BDD用ツール。
 詳しく知らないものなので、パスします。動作を記述して、そのテ
ストを行うツールだそうです。

26. +
serverspec
 OS環境のテストツール。パッケージインストール状態やサービス
の起動状態、ポートのlisten状態などをテストできる。
 メリットのある場面
 chef/puppet/ansible/capistrano/Fabricなどを利用している場合、テスト
と一緒にどうぞ！
 本当にインストール・設定ができているか、証跡などを残したい場合に。
 デプロイチェックに。
 デメリット
 学習コスト
 Linux専用

27. +
selenium / SilkTest
 UIテスト自動化ツール。回帰テストなどの何度もテストを実施
するときのお供に。
 メリットの出る場面
 回帰テストがたくさん出るプロジェクト
 アジャイル/TDDをやっているプロジェクト
 リファクタリングするときに
 デメリット
 2度目以降のUIテストを自動化するツールなので、テストを1回しか
しないのであれば、手動の方が早いです。
 SilkTestは有料です。

28. +
デモ
 Vagrant + AWS ConoHa+ Capistrano + serverspec

29. +
管理関連
 Jenkins
 継続的インテグレーション(Continunious Integration)ツール。アプ
リケーション開発支援など。
 git / mercurial / Subversion
 コードのバージョン管理
 Trac / Redmine
 プロジェクト管理
 JIRA
 バグ・課題管理。詳しくは知らないので、パスします。

30. +
Jenkinsおじさん
 継続的インテグレーションツール。かなり簡単に導入できます。
 メリットの出る場面
 アジャイル/TDDのお供に。リポジトリにpushしたらテスト、pull
requestが来たらテスト！そしてデプロイ！
 クロスブラウザテスト。デプロイしたら/1日1回、ブラウザのイン
ストールされた仮想マシン4台でテストしてテスト結果を実施でき
ます。
 今まで説明した自動化ツール/テストツールと連携すると強力。
 デメリット
 仮想化するとうまく使えないことがあるらしい。

31. +
Git / mercurial / Subversion
 バージョン管理ツール。git/mercurialは分散型。subversionは中央
集中型。
 Githubとか有名ですよね？
 メリット
 コードのバージョン管理・開発の状態管理。
 先のインフラ自動化ツールを使えば、環境のバージョン管理や、デプロ
イ手順のバージョン管理が行える。
 Jenkinsおじさんと連携すれば、pull requestされた時にテストして結果
を返してくれる。
 デメリット
 学習コスト

32. +
監視
 Zabbix / Nagios / Hinemos
 サーバ監視
 fluentd
 ログ管理

33. +
Zabbix / Nagios / Hinemos
 監視システム。監視・通知をする運用ツール
 Zabbix/Nagiosはmunin/gangliaなどのリソースモニタリングツー
ルと一緒にどうぞ。
 Hinemosはジョブ設定などもできるらしいですが、皆さんのほう
が詳しいんじゃないんでしょうか？
 メリットのある場面
 商用環境なら入れましょう
 アクセス負荷などでサーバがやばい状態になったかどうかわかります。
通知とかできます。
 デメリット
 アプリケーションのインストールが必要

34. +
fluentd
 ログ収集基盤。インプットされたログをJSONに加工して出力
する。パイプライン処理のように多段階で処理し、リアルタイ
ムにアクセス解析をすることも可能。
 メリットのある場面
 アクセス分析をリアルタイムでしたいとき
 エラーが起こったすぐのタイミングで分析を始めたいとき
 デメリット
 fluentdにログを転送する設定が必要

35. +
ツールがいっぱい
 どうやって使えばいいの・・・？

36. +
例えば〜その１
 アクセスが増えてきたらVM増やそう！
アクセスリアルタイム集計
仮想マシン
①作成
②構成変更
③アプリデプロイ
ServerSepc
④構成テスト
現行系
発火する何か
⑤構成変更・VM追加

37. +
例えば〜その２
 新しい機能のPullRequestが来たら毎回テスト！
仮想マシン
③作成
④構成変更
⑤アプリデプロイ
ServerSepc
⑥構成テスト
①PullRequest
②PullReq通知
⑦構成テスト
⑧結果通知

38. +
例えば〜その３
 デプロイ失敗した！バージョン戻そう！
ServerSepc
①コード
clone
現行系
ローカル
マシンとか
②構成変更
②デプロイ
し直し
③構成テスト
④動作テスト

39. +
例えば〜その４
 新しい人が入ってきた？４０秒で支度しな！
 Chefで仮想マシンの準備
 １０分くらいあればできます。
 Mac向けですが、Boxenなんてものも最近流行ってます

40. +
他に嬉しい事は？
 サーバの状態って、今どうなってたっけ？がなくなる
 コードを見ればわかる
 デプロイが簡単になる
 テスト環境でデプロイ手順をコード化すれば、その通り動く。１コマン
ドデプロイとか夢じゃないですよ？
 手作業によるミスが減る
 コード化されているのでケアレスミスが減る
 手順が常に最新
 コードなのでお客様に出すの難しいかもしれない・・

41. +
理想は？
 インフラも、アプリケーションも、管理も、監視も
全部コード化！自動化！
 そのためには、
手作業は手順を作るとき以外はやらない。
と私は考えています。

42. +
まとめ
 開発と運用が仲良くしよう（DevOps）
 そのためにツールを色々使って文化を整えよう！
 いいもの届けていこう！
 目指せフルスタックエンジニア！

43. +
参考資料
 http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-
ops-cooperation-at-flickr
 https://speakerdeck.com/naoya/devopsfalsejin-tokorekara-
number-init-devops
 http://www.ryuzee.com/contents/blog/4241
 http://www.zusaar.com/event/838007
 http://www.slideshare.net/tomohn/10devops-20004973
 http://atnd.org/events/41286