1.
基礎からわかるDevOps
アマゾンデータサービスジャパン株式会社
吉羽龍太郎
Summit
Developers #natsumi #natsumi1A

2.
自己紹介
名前：吉羽龍太郎
• アマゾン データ サービス ジャパン株式会社
• プロフェッショナルサービス事業本部
• シニア・コンサルタント
ソーシャル
• @ryuzee
• www.facebook.com/ryuzee.jp
個人の著作・翻訳

3.
このセッションでは開発や運用
における大きな方向性の話をし
ます。その理解なくして、自分
が楽だから○○使う！とか開発
チームの人たちが××だ！とか
運用チームが△△だ！とか言う
のはお互いのためになりません

4.
DevOpsの基礎

5.
ビジネス環境の変化
情報化
投資
投資内訳 情報化投資
指数
（2000年＝
100）
民間企業
設備投資
民間設備投資
にしめる情報
化投資（％）通信機器 計算機本体
同付属装置
ソフトウェア
1980年 720 258 300 162 5.7 30,997 2.3
1985年 2,204 731 745 728 17.5 42,614 5.2
1990年 6,833 1,100 2,409 3,324 54.2 70,683 9.7
1995年 8,109 2,156 2,558 3,395 64.4 60,304 13.4
2000年 10,668 2,438 2,745 5,485 84.7 64,674 16.5
2005年 12,598 2,170 3,016 7,412 100.0 70,069 18.0
2010年 14,785 3,087 4,155 7,543 117.4 64,174 23.0
総務省「ICTの経済分析に関する調査」(平成23年度版)より引用
金額は単位10億円
企業の設備投資におけるIT投資の割合が20%を超えている
企業の戦略実現のためにITを使うように状況が変化
ITを活用できる企業が厳しい生存競争を勝ち抜くことに

6.
Amazonの3つのコアビジネス

7.
Amazonの3つのコアビジネス
コンシューマ向け
ビジネス
1億を超えるアクティブなア
カウント
８カ国で展開 :
米国, 英国, ドイツ, 日本, フ
ランス, カナダ, 中国,
イタリア

8.
Amazonの3つのコアビジネス
セラー向け
ビジネス
アマゾンの
ウェブサイト上で販売
自社小売ウェブサイトに
Amazonの技術を利用
アマゾンフルフィルメント
センター（物流センター）
の活用
コンシューマ向け
ビジネス
1億を超えるアクティブなア
カウント
８カ国で展開 :
米国, 英国, ドイツ, 日本, フ
ランス, カナダ, 中国,
イタリア

9.
IT インフラストラクチャ
Amazonの3つのコアビジネス
セラー向け
ビジネス
アマゾンの
ウェブサイト上で販売
自社小売ウェブサイトに
Amazonの技術を利用
アマゾンフルフィルメント
センター（物流センター）
の活用
コンシューマ向け
ビジネス
1億を超えるアクティブなア
カウント
８カ国で展開 :
米国, 英国, ドイツ, 日本, フ
ランス, カナダ, 中国,
イタリア

10.
IT インフラストラクチャ
Amazonの3つのコアビジネス
セラー向け
ビジネス
アマゾンの
ウェブサイト上で販売
自社小売ウェブサイトに
Amazonの技術を利用
アマゾンフルフィルメント
センター（物流センター）
の活用
コンシューマ向け
ビジネス
1億を超えるアクティブなア
カウント
８カ国で展開 :
米国, 英国, ドイツ, 日本, フ
ランス, カナダ, 中国,
イタリア
スケーラビリティ
高可用性

11.
IT インフラストラクチャ
Amazonの3つのコアビジネス
セラー向け
ビジネス
アマゾンの
ウェブサイト上で販売
自社小売ウェブサイトに
Amazonの技術を利用
アマゾンフルフィルメント
センター（物流センター）
の活用
コンシューマ向け
ビジネス
1億を超えるアクティブなア
カウント
８カ国で展開 :
米国, 英国, ドイツ, 日本, フ
ランス, カナダ, 中国,
イタリア
スケーラビリティ
高可用性
ITインフラ
ビジネス
2006年開始
ウェブスケールでの
クラウド基盤の提供
190以上の国において、数十
万に及ぶ登録アカウント

12.
Amazonのビジネスモデル

13.
ビジネスのためにITを活用!!

14.
DevOpsの起源

15.
DevOpsの起源
Velocity 2009での当時Flickrに所属
していた2名による発表が起源

16.
Dev & ops cooperation

17.
開発者と運用者の壁
開発者は新しい機能をどんどん作る
運用者は安定した運用を提供する
ミッションの違い
It’s not my business.
サイロ化
オーバーヘッド

18.
よくある光景
なんでアプリケーション
ちゃんと作らないんだ？
運用でなんとかするのが
仕事でしょ？

19.
同じ話は組織のあちこちに
このコード書いたのは××さんなので分かりません
この作業は××さん担当なので僕のせいじゃないです
○○部門がいつもギリギリに色々指摘するせいで遅くなるんです
こっちにも都合というものが…
それ規則で決まってるんです

20.
サイロ化によるオーバーヘッド
価値を生み
出すのに使
う時間
価値を生み
出すのに使
う時間
価値を生む
際のオー
バーヘッド
価値を生む
際のオー
バーヘッド
Dev Ops
価値を生む作業に時
間を使えていない・
ムダがある！
この話はDevとOps間に限らない話！

21.
ビジネスは変化する

22.
システムの機能の利用割合
Standishの2000年の調査より

23.
システムの機能の利用割合
Standishの2000年の調査より

24.
本当に必要なものがわかるか？

25.
ビッグバンを避ける

26.
フィードバックループ
顧客とビジネスの間のフィードバックループを加速する
顧客の期待に応え続ける

27.
フィードバックループの高速化
要求
設計
開発
テスト
QA
リリース
フィード
バック
メトリク
ス
ビジネス

28.
9
24
48
61
82
159
2007 2008 2009 2010 2011 2012
AWSのイノベーションのペース

29.
DevもOpsもビジネスの成果達成を支える

30.
DevOpsとはDevとOpsが
ビジネスの成果を
継続的に達成できるように
お互いが協力しあう
という考え方

31.
DevOps is not Framework
DevOpsは考え方でプロセスやフレームワークではない
実装は現場によって異なる

32.
文化よるサポート
お互いの尊重
お互いの信頼
失敗に対する健全な態度
お互いを非難しない

33.
ツールによるサポート
インフラ構築自動化
バージョン管理
継続的インテグレーション
デプロイ自動化
監視
情報共有
• Wiki、IRC、BTS
ダッシュボード
このツール群はあくまで代表的なもので、全部必須なわけではない

34.
DevOpsは
文化とツールを通じて、
変化に対応し、
変化のリスクを減らす

35.
DevOpsは銀の弾丸ではない

36.
あるべき姿
価値を生み
出すのに使
う時間
価値を生み
出すのに使
う時間
オーバーヘッド オーバーヘッド
Dev Ops
ゴールの共有
お互いの協力
ツールの活用
によって価値を生み
出す時間を増やし、
時間効率も改善

37.
チームの能力を最大限発揮する

38.
DevOps＝自動化ではない
ただし自動化はリスク低減と
アジリティ向上に大きく寄与

39.
開発プロセスとの関係

40.
http://www.agilemanifesto.org

41.
41
Agileソフトウェア開発の原則
http://www.agilemanifesto.org/principles.html
12個の原則

42.
Our highest priority is to
satisfy the customer
through early and
continuous delivery of
valuable software.

43.
プロダクトバックログ
製品の機能をストーリー形式で記載
プロダクトオーナーが優先順位を付け、プラ
ンニングポーカーで相対見積もり。
項目の追加はいつでも自由だが実施有無や優
先順位はPOが決める。
開発チーム (6±3人)
プロダクトの開発を行う。
製品の成功に向けて最大限
の努力をコミットする
スクラムマスター
スクラムプロセスがうまく
いくようにする。
外部から開発チームを守る
プロダクトオーナー
製品に対して責任をもち機能
に優先順位を付ける
ステークホルダー
製品の利用者、出資者、管理職
などの利害関係者。鶏と称す
スプリントバックログ
そのスプリント期間中に行う
タスクのリスト
スプリント
最大4週間までのタイムボックス
各スプリントの長さは同一。この間は外部
からの変更を受け入れない
スプリントレビュー
スプリント中の成果である
動作するソフトウェアをデモ
する
レトロスペクティブ
スプリントの中での改善事項
を話合い次に繋げる
複
数
回
ス
プ
リ
ン
ト
を
繰
り
返
す
出荷可能な
製品の増分
スプリント計画会議
プロダクトバックログを再度分析・評価し、
そのスプリントで開発するプロダクトバック
ログアイテムを選択する。また選択した項目
をタスクにばらす
完了の定義
何をもって「完了」とするかを
定義したリスト
毎日の繰り返し
デイリースクラム
毎日開発チームが以下の３つの質問に答える
・昨日やったこと
・今日やること
・困っていること
バーンダウンチャート
スプリントタスクの「推定残り時間」を
更新してグラフにプロットする
タスク
時間で見
積もり

44.
優先順位をつけて１つづつ確認
1番目にほしい
2番目にほしい
3番目にほしい
4番目にほしい
5番目にほしい
・
・
・
99番目にほしい
100番目にほしい
よし頼んだ通りなのでOKです。
完了だ！
あれ、ここクリックすると遷移先
が違うね。これは未完了
あ、こうなるのか。頼んだ通りだ
から完了だけど、次のスプリント
で機能追加しようか！
確認が完了したものから
リリースしちゃえばお客
様は喜ぶはずだなぁ…

45.
XP – 19個のプラクティス
反復
メタファー
作業空間
ふりかえり
テスト駆動開発
ペアプロ
リファクタリング
コードの
共同所有
継続的インテグ
レーション
YAGNI
責任
擁護
四半期毎の
見直し
ミラー
持続可能な
ペース
ストーリー作成
リリース計画
受け入れテスト
短期リリース

46.
共通理解
コード
レビュー
チェックイン
ユニット
テスト
カバレージ
ドキュメント セキュリティ 性能 デプロイ
などなど
完了の定義を作り、何をもって出荷可能かを定める
定義はビジネス＋Dev＋Opsで作成
• 自動でチェックできるものを増やせばサイクルタイム短縮
• 開発や運用での知見を定義に反映する

47.
品質の作りこみ
早く見つけて速く直す
フェーズ 修正までの時間
要求や設計 5分
コードやユニットテスト 15分
結合テストやシステムテスト 1時間
ベータテスト 2時間
リリース後 1日

48.
継続的デリバリー
繰り返し型の
開発
継続的
インテグレーション
継続的
デプロイ
Scrum
 要求に順位付け
 タイムボックス
による制御
 検査と適用によ
る継続的改善
 透明性の確保
 自己組織型チー
ム
 技術的プラク
ティスの定義な
し
Scrum＋XP
 xUnit等による
テスト自動化
 テスト駆動開発
 コーディング規
約
 ペアプロ等
 常時出荷可能な
品質を保持
 主に技術的プラ
クティスから構
成される
Lean
 Just in Timeで
顧客が必要なも
のを必要なとき
に。
 サイクルタイム
を測定し改善す
る。
 ビジネス活動そ
のもの
 全体最適

49.
フィーチャー単位で完了
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー

50.
平均11.6秒ごとにデプロイ
1時間で最大1,079回のデプロイ
1回で平均1万台のホストへデプロイ
最大で3万台のホストへ同時にデプロイ

51.
自動化による時間の使い方の変化
頻繁な変化を人手で行うことは限界がある
いままでは手作業に多くの時間を
テスト自動化、インフラ構築自動化へ
本質的に価値を生む箇所に時間を使う
これは開発だけでなく運用も同じ
品質を作りこみ続ける

52.
テスト自動化

53.
テスト自動化アンチパターン
頻繁にバージョン管理システムにコミットしない
テストコードを書かない
テストコードと製品コードを同時にコミットしない
定時ビルドのみでコミットビルドがない・夜間ビルドしかない
帰り際にコミットしてそのままCIの結果を見ずに帰る
CIでテストを通すために手作業の準備が必要
メインラインのみで大きなブランチをCI対象にしていない
様々な種類のテストをまとめて行っている
ビルドの失敗に気付かない / ビルドに失敗しても放置している
ビルドの失敗に気づいても、修正コード以外のコードをコミットする
何も変更していないのにビルドが落ちたり落ちなかったり
頻繁にビルドが失敗するので、失敗するのが普通だと思う
CIからの通知メッセージが大量すぎる / CIが落ちても何も通知しない
CIサーバのリソースが貧弱
ビルドが肥大化して結果が出るまでに時間がかかる
本番環境やステージング環境と大幅に環境が異なる
コードの静的解析をCIで行わずに人手で行う
CIサーバがおかしくなったときに直せる人がいない
ずっとCIでのチェック内容が変わらない、プロセスが変わらない

54.
Infrastructure as Code
サーバーの台数が増えると作業に多くの時間がかかる
単純作業の繰り返しになるため間違いを誘発しやすい
手順書やチェックリストが時間の経過とともにメンテ
ナンスされない
手順書やチェックリストが正しいかどうか分からない
作業の順番を間違えるとサーバーの状態が変わる
このように人手による作業のため間違いやすい
さらに間違えたことに気づく仕掛けがないため、ある
日障害という形でその問題が顕在化する

55.
Infrastructure as Code
コードによるインフラの記述
サーバーの台数が増えても構築に時間がかからない
コード＝手順書となるのでコードを常にメンテナンスしておけば良い
手順を抜かしたり手順を間違う心配がない
同じコードを動かせば同じサーバーが出来上がる
コードで記述されているので再利用が容易である
他のプロジェクトでコードを使いまわすことで無駄を省ける

56.
環境構築自動化

57.
クラウドコンピューティング
初期投資不要
利用した分だけの低額な費用
伸縮自在性・柔軟性
速度・アジリティの向上
コアコンピタンスへの集中
ワールドワイド

58.
Design for Failure
全てのものが壊れる前提で設計する
サーバもアプリケーションも
1か所壊れても動くように
疎結合アーキテクチャー
自動復旧
自動伸縮

59.
DevOpsの進め方

60.
DevOpsいつやるの？
いまでしょ！
の前にやることがあります

61.
あなたの組織のゴールは？

62.
カイゼンすべき箇所はどこなのか？
作りすぎのムダ
手待ちのムダ
運搬のムダ
加工のムダ
在庫のムダ
動作のムダ
不良をつくるムダ
Just in Time
かんばん
ムダ
平準化
アンドン
ポカヨケ
自働化
改善
見える化
付加価値を高めない各種現象や結果をムダと呼ぶ

63.
小さく始める
いきなり自分たちのプロセスを大きく変えない
一度に沢山変えると変化に耐えられない
小さな取り組みを継続的におこなう
取り組みの成果を確認しつづける
小さな成功を早期から繰り返す
組織やプロセスを着実に成長させる

64.
1日にしてならず

65.
じゃあどこから始めるの？

66.
当たり前のことを当たり前に
バージョン管理
コーディング規約
コードレビュー
テスト自動化
ドキュメント
…
基礎なくして応用のテクニックを目指さない
まず当たり前のことから当たり前に

67.
よくある形

68.
推進役はだれ？

69.
組織づくり
単にDevOps専任組織を作ってもうまくいかない
既存チームにDevOpsという名前をつけても変わらない
全員が同じゴールに向かって進めるか
• チームのゴールと個人のゴールが相反したらどうなる？
• 人事考課が個人の成果に大きな比重を置きすぎると？

70.
成功を祝う
成功をみんなで祝う！

71.
DevOpsは銀の弾丸ではない
大事なことなので2度言いました…

72.
自分の組織にとっての
DevOpsとは何なのか？どう
なれば成功かを考え、着実に
小さい成功を積み上げる

73.
175を超えるセッション!
Gameday! Hackathon! Boot Camp!
ラボ! 展示会! パーティー!
re:Invent 2013 参加ツアーの申し込みはこちら!
http://bit.ly/reinvent2013japan
11月12日 (火) 〜 11月15日 (金) の4日間 !
ラスベガス・ベネチアンホテルで開催!
http://bit.ly/reinvent2013
基調講演 日本語同時通訳!
日本専用トラック! 懇親ディナー!
シアトルオフィス訪問!
※ツアー参加の特典です。