1. 基礎からわかる DevOps アマゾンデータサービスジャパン株式会社 吉⽻羽⿓龍龍太郎郎
2. ⾃自⼰己紹介 ! 名前：吉⽻羽⿓龍龍太郎郎 • アマゾン データ サービス ジャパン株式会社 • シニア・コンサルタント ! ソーシャル • @ryuzee • www.ryuzee.com 個⼈人の著作・翻訳
3. ! 最近出ました! • よろしくお願いします!
6. DevOpsの起源 Velocity 2009での当時Flickrに所属 していた2名による発表が起源
8. 開発者と運⽤用者の壁 ! 開発者は新しい機能をどんどん作る ! 運⽤用者は安定した運⽤用を提供する ミッションの違い Itʼ’s not my business. サイロ化 オーバーヘッド
9. よくある光景 なんでアプリケーション ちゃんと作らないんだ？ 運⽤用でなんとかするのが 仕事でしょ？
10. 同じ話は組織のあちこちに このコード書いたのは××さんなので分かりません この作業は××さん担当なので僕のせいじゃないです それ規則で決まってるんです ○○部⾨門がいつもギリギリに⾊色々指摘するせいで遅くなるんです こっちにも都合というものが…
11. サイロ化によるオーバーヘッド Dev Ops 価値を⽣生む 際のオー バーヘッド 価値を⽣生む 際のオー バーヘッド 価値を⽣生み 出すのに使 う時間 価値を⽣生む作業に時 間を使えていない・ ムダがある！ ! この話はDevとOps間に限らない話！ 価値を⽣生み 出すのに使 う時間
15. Amazonの3つのコアビジネス セラー向け ビジネス コンシューマ向け ビジネス 1億を超えるアクティブなア カウント ８カ国で展開 : ⽶米国, 英国, ドイツ, ⽇日本, フ ランス, カナダ, 中国, イタリア アマゾンの ウェブサイト上で販売 ⾃自社⼩小売ウェブサイトに Amazonの技術を利利⽤用 アマゾンフルフィルメント センター（物流流センター） の活⽤用 IT インフラストラクチャ ITインフラ ビジネス スケーラビリティ 2006年年開始 ウェブスケールでの クラウド基盤の提供 ⾼高可⽤用性 190以上の国において、数⼗十 万に及ぶ登録アカウント
17. システムの機能の利利⽤用割合 Standishの2000年年の調査より
19. 本当に必要なものがわかるか？ 顧客が説明した要件 顧客が本当に必要 だった物
21. ビジネスはうまくいかないこともある ! 1発1中は⽬目指さない ! うまくいっていないこ とを把握できる仕掛け ! ダメなものをやめる選 択肢
23. フィードバックループ ! 顧客とビジネスの間のフィードバックループを加速する ! 顧客の期待に応え続ける
24. AWSのイノベーションのペース 159 82 61 48 24 9 2007 2008 2009 2010 2011 2012
26. DevOps is not Framework ! DevOpsは考え⽅方でプロセスやフレームワークではない ! 実装は現場によって異異なる
27. DevもOpsもビジネスの成果達成を⽀支える
28. DevOpsとはDevとOpsが ビジネスの成果を 継続的に達成できるように お互いが協⼒力力しあう という考え⽅方
29. ⽂文化よるサポート ! ! ! ! お互いの尊重 お互いの信頼 失敗に対する健全な態度度 お互いを⾮非難しない
30. ツールによるサポート ! ! ! ! ! ! インフラ構築⾃自動化 バージョン管理理 継続的インテグレーション デプロイ⾃自動化 監視 情報共有 • Wiki、チャット、BTS ! ダッシュボード このツール群はあくまで代表的なもので、全部必須なわけではない
31. あるべき姿 Dev Ops オーバーヘッド オーバーヘッド 価値を⽣生み 出すのに使 う時間 ゴールの共有 お互いの協⼒力力 ツールの活⽤用 によって価値を⽣生み 出す時間を増やし、 時間効率率率も改善 価値を⽣生み 出すのに使 う時間
33. DevOpsは ⽂文化とツールを通じて、 変化に対応し、 変化のリスクを減らす
34. DevOps＝⾃自動化ではない ただし⾃自動化はリスク低減と アジリティ向上に⼤大きく寄与
36. インフラ構築のアジリティ ! ビジネスチャンスを逃さない ! 調達期間と多⼤大な初期投資は許容できるか？ ! ビジネスの変化に対応できるか？ ! 変化への追随のボトルネックになることをさける ! かなりのケースでサイジングはあたらない
37. インフラ構築のアジリティ 本稼働 予定⽇日 ■オンプレミスの場合 要件 定義 詳細設計 基本 設計 機器調達 結合テ スト 開発 ↑ リスク防⽌止のため、 過剰スペックの投資 ■AWSの場合 要件 定義 基本 設計 ↑ サンプルアプリ でサイズ検証 機器調達と 機器設計に係る 期間の短縮 アジャイ ル開発＆ テスト 総合テ スト 総合テ スト 移⾏行行運⽤用テスト 機器調達 ↑ 性能テストの結果 サイジング失敗 本稼働 予定⽇日 移⾏行行運⽤用 テスト 稼働⽇日の短縮 本運⽤用 ↑ ↑ 性能テストの結果 稼働⽇日に間に合わない サイジング失敗 リスクの低減 →リソースを増やせば良良い 本運⽤用 ↑ 稼働⽇日に 間に合わない
38. クラウドコンピューティング ! ! ! ! ! ! 初期投資不不要 利利⽤用した分だけの低額な費⽤用 伸縮⾃自在性・柔軟性 速度度・アジリティの向上 コアコンピタンスへの集中 ワールドワイド
39. Design for Failure ! ! ! ! Web +DB EC2 ここが壊れたら？ サービス停⽌止 夜間コール (-‐‑‒_̲-‐‑‒)zzz 多⼤大な遺失利利益 Web App DB AZ② AZ① AWS Cloud 全てのものは壊れる 前提で構築する
40. Design for Failure ELB Web Web Web Web ! SPOF(単⼀一障害点)の排除 ! リクエスト要求量量にあわせて 伸縮 ! 壊れたものは⾃自動で切切り離離し て新しいものを作ったり、 フェイルオーバー ! ⼈人⼿手による作業を極⼒力力排除 Auto Scaling Group RDS AZ① AZ② AWS Cloud 伸縮性や⾃自動でのサービス 継続を実現するにはステー トレスであることが必要
41. 疎結合アーキテクチャー Web Web Web Web Auto Scaling Group AP AP AP AP Auto Scaling Group AZ① AWS Cloud AZ② ! コンポーネント間の結合度度を 下げる(疎結合アーキテク チャ) ! 疎結合にすることで、伸縮性 の確保、保守容易易性の確保が 可能になる ! インスタンスに再⽣生不不能なリ ソースを配置しない (S3,RDS,DynamoDBなどへ) ロードバランサーやキュー の利利⽤用によって 疎結合を実現
42. インスタンスの種類 High I/O 4XL 60.5 GB 35 EC2 Compute Units 16 virtual cores 2*1024 GB SSD-‐‑‒based local instance storage 256 Memory (GB) 32 16 8 4 2 1 Hi-‐‑‒Mem 2XL 34.2 GB 13 EC2 Compute Units 4 virtual cores Hi-‐‑‒Mem XL 17.1 GB 6.5 EC2 Compute Units 2 virtual cores Medium 3.7 GB, Units 1 virtual core M3 XL 15 GB 13 EC2 Compute Units 4 virtual cores EBS storage only Large 7.5 GB 4 EC2 Compute Units 2 virtual cores Small 1.7 GB, 1 EC2 Compute Unit 1 virtual core Extra Large 15 GB 8 EC2 Compute Units 4 virtual cores 2 EC2 Compute Hi-‐‑‒Mem Cluster Compute 8XL 244 GB 88 EC2 Compute Units 16 virtual cores 240 GB SSD 10 GB Inter-‐‑‒ Instance Network Hi-‐‑‒Mem 4XL 68.4 GB 26 EC2 Compute Units 8 virtual cores 128 64 High Storage 8XL 117 GB 35 EC2 Compute Units, 24 * 2 TB ephemeral drives 10 GB Ethernet High-‐‑‒CPU Med 1.7 GB 5 EC2 Compute Units 2 virtual cores M3 2XL 30 GB 26 EC2 Compute Units 8 virtual cores EBS storage only Cluster Compute 8XL 60.5 GB 88 EC2 Compute Units Cluster Compute 4XL 23 GB 33.5 EC2 Compute Units Cluster GPU 4XL 22 GB 33.5 EC2 Compute Units, 2 x NVIDIA Tesla “Fermi” M2050 GPUs High-‐‑‒CPU XL 7 GB 20 EC2 Compute Units 8 virtual cores Micro 613 MB Up to 2 ECUs (for short bursts) 1 2 4 8 16 32 64 128 256 EC2 Compute Units
43. インフラのスケール ! インスタンスタイプを変更更することで より多くのリソースを利利⽤用できるよう になる ! ただしいつか限界にたどり着く ! スケールアップよりスケールアウト ! RDBMSはボトルネックの典型 ! 規模拡⼤大によって抜本的なアーキテク チャの⾒見見直しが必要になることも…
44. DRY原則 Don’t Repeat Yourself
46. Infrastructure as Code ! サーバーの台数が増えると作業に多くの時間がかかる ! 単純作業の繰り返しになるため間違いを誘発しやすい ! ⼿手順書やチェックリストが時間の経過とともにメンテ ナンスされない ! ⼿手順書やチェックリストが正しいかどうか分からない ! 作業の順番を間違えるとサーバーの状態が変わる ! このように⼈人⼿手による作業のため間違いやすい ! さらに間違えたことに気づく仕掛けがないため、ある ⽇日障害という形でその問題が顕在化する
47. Infrastructure as Code ! ! ! ! ! ! ! コードによるインフラの記述 サーバーの台数が増えても構築に時間がかからない コード＝⼿手順書となるのでコードを常にメンテナンスしておけば良良い ⼿手順を抜かしたり⼿手順を間違う⼼心配がない 同じコードを動かせば同じサーバーが出来上がる コードで記述されているので再利利⽤用が容易易である 他のプロジェクトでコードを使いまわすことで無駄を省省ける
48. Programmable http://aws.amazon.com/tools/
49. いくつでも同じ環境を！ Dev QA CloudFormation 性能試験 バグ調査 テンプレートに基づき 各サービスが起動 スタック ElasticLoadBalancing テンプレート S3 Cloud Formation SNS EC2 EC2 AutoScaling http://aws.amazon.com/cloudformation/ CloudWatch
53. http://www.agilemanifesto.org
54. http://www.agilemanifesto.org/principles.html Agileソフトウェア開発の原則 12個の原則 54
55. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
56. プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 外部から開発チームを守る ステークホルダー 開発チーム (6±3⼈人) 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする デイリースクラム プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 毎⽇日開発チームが以下の３つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート 完了了の定義 何をもって「完了了」とするかを 定義したリスト スプリント計画会議 スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする スプリント プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない タスク 時間で⾒見見 積もり 毎⽇日の繰り返し スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する レトロスペクティブ スプリントの中での改善事項 を話合い次に繋げる 出荷可能な 製品の増分 複 数 回 ス プ リ ン ト を 繰 り 返 す
57. 優先順位をつけて１つづつ確認 1番⽬目にほしい 2番⽬目にほしい 3番⽬目にほしい 4番⽬目にほしい 5番⽬目にほしい よし頼んだ通りなのでOKです。 完了了だ！ あれ、ここクリックすると遷移先 が違うね。これは未完了了 あ、こうなるのか。頼んだ通りだ から完了了だけど、次のスプリント で機能追加しようか！ 99番⽬目にほしい 100番⽬目にほしい 確認が完了了したものから リリースしちゃえばお客 様は喜ぶはずだなぁ…
58. XP – 19個のプラクティス 反復復 テスト駆動開発 責任 ストーリー作成 メタファー ペアプロ 擁護 リリース計画 作業空間 リファクタリング 四半期毎の ⾒見見直し 受け⼊入れテスト ふりかえり コードの 共同所有 ミラー 短期リリース 継続的インテグ レーション 持続可能な ペース YAGNI
60. 共通理理解 ! 完了了の定義を作り、何をもって出荷可能かを定める ! 定義はビジネス＋Dev＋Opsで作成 • ⾃自動でチェックできるものを増やせばサイクルタイム短縮 • 開発や運⽤用での知⾒見見を定義に反映する コード レビュー チェックイン ユニット テスト カバレージ ドキュメント セキュリティ 性能 デプロイ などなど
61. 品質の作りこみ フェーズ 修正までの時間 要求や設計 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1⽇日 ! 早く⾒見見つけて速く直す
63. テスト⾃自動化アンチパターン ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 頻繁にバージョン管理理システムにコミットしない テストコードを書かない テストコードと製品コードを同時にコミットしない 定時ビルドのみでコミットビルドがない・夜間ビルドしかない 帰り際にコミットしてそのままCIの結果を⾒見見ずに帰る CIでテストを通すために⼿手作業の準備が必要 メインラインのみで⼤大きなブランチをCI対象にしていない 様々な種類のテストをまとめて⾏行行っている ビルドの失敗に気付かない / ビルドに失敗しても放置している ビルドの失敗に気づいても、修正コード以外のコードをコミットする 何も変更更していないのにビルドが落落ちたり落落ちなかったり 頻繁にビルドが失敗するので、失敗するのが普通だと思う CIからの通知メッセージが⼤大量量すぎる / CIが落落ちても何も通知しない CIサーバのリソースが貧弱 ビルドが肥⼤大化して結果が出るまでに時間がかかる 本番環境やステージング環境と⼤大幅に環境が異異なる コードの静的解析をCIで⾏行行わずに⼈人⼿手で⾏行行う CIサーバがおかしくなったときに直せる⼈人がいない ずっとCIでのチェック内容が変わらない、プロセスが変わらない
64. 継続的デリバリー 繰り返し型の 開発 継続的 インテグレーション 継続的 デプロイ Scrum u 要求に順位付け u タイムボックス による制御 u 検査と適⽤用によ る継続的改善 u 透明性の確保 u ⾃自⼰己組織型チー ム u 技術的プラク ティスの定義な し Scrum＋XP u xUnit等による テスト⾃自動化 u テスト駆動開発 u コーディング規 約 u ペアプロ等 u 常時出荷可能な 品質を保持 u 主に技術的プラ クティスから構 成される Lean u Just in Timeで 顧客が必要なも のを必要なとき に。 u サイクルタイム を測定し改善す る。 u ビジネス活動そ のもの u 全体最適
65. フィーチャー単位で完了了 フィーチャー フィーチャー フィーチャー フィーチャー フィーチャー フィーチャー フィーチャー コードレビュー コードレビュー コードレビュー コードレビュー コードレビュー コードレビュー コードレビュー チェックイン チェックイン チェックイン チェックイン チェックイン チェックイン チェックイン ユニットテスト ユニットテスト ユニットテスト ユニットテスト ユニットテスト ユニットテスト ユニットテスト カバレッジ カバレッジ カバレッジ カバレッジ カバレッジ カバレッジ カバレッジ 静的解析 静的解析 静的解析 静的解析 静的解析 静的解析 静的解析 結合テスト 結合テスト 結合テスト 結合テスト 結合テスト 結合テスト 結合テスト 受け⼊入れテスト 受け⼊入れテスト 受け⼊入れテスト 受け⼊入れテスト 受け⼊入れテスト 受け⼊入れテスト 受け⼊入れテスト クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ ドキュメント ドキュメント ドキュメント ドキュメント ドキュメント ドキュメント ドキュメント セキュリティ セキュリティ セキュリティ セキュリティ セキュリティ セキュリティ セキュリティ 性能 性能 性能 性能 性能 性能 性能 デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ
66. ⼿手動デプロイ ( ﾟ皿ﾟ)ｷｰｯ!! Day1 Day2 Day3 Day4 DayN
67. ⼿手動デプロイのリスクとコスト (^_^;) ( ﾟ皿ﾟ)ｷｰｯ!!
68. ⾃自動デプロイ メンテ中ページに 差し替える LBから切切り離離す 新規環境構築 データベースの マイグレーション アプリケーションの デプロイ アプリケーションの デプロイ アプリケーションの デプロイ スモークテスト スモークテスト スモークテスト LB対象に戻す LB切切り替え メンテ中ページから 戻す アプリケーションの デプロイ
69. Deploy on AWS ! AWS上での効率率率的なデプロイ⽅方法 http://slidesha.re/19yqQlR
70. DEPLOYMENTS AT AMAZON.COM 11.6s 1,079 Mean time between deployments (weekday) Max number of deployments in a single hour 10,000 30,000 Mean number of hosts simultaneously receiving a deployment Max number of hosts simultaneously receiving a deployment
71. ⾃自動化による時間の使い⽅方の変化 ! ! ! ! ! ! 頻繁な変化を⼈人⼿手で⾏行行うことは限界がある いままでは⼿手作業に多くの時間を テスト⾃自動化、インフラ構築⾃自動化へ 本質的に価値を⽣生む箇所に時間を使う これは開発だけでなく運⽤用も同じ 品質を作りこみ続ける
73. DevOpsいつやるの？ いまでしょ！ の前にやることがあります
75. カイゼンすべき箇所はどこなのか？ ! ! ! ! ! ! ! ! ! Just in Time かんばん ムダ 平準化 アンドン ポカヨケ ⾃自働化 改善 ⾒見見える化 ! ! ! ! ! ! ! 作りすぎのムダ ⼿手待ちのムダ 運搬のムダ 加⼯工のムダ 在庫のムダ 動作のムダ 不不良良をつくるムダ 付加価値を⾼高めない各種現象や結果をムダと呼ぶ
77. ⼩小さく始める ! ! ! ! ! ! いきなり⾃自分たちのプロセスを⼤大きく変えない ⼀一度度に沢⼭山変えると変化に耐えられない ⼩小さな取り組みを継続的におこなう 取り組みの成果を確認しつづける ⼩小さな成功を早期から繰り返す 組織やプロセスを着実に成⻑⾧長させる
80. 当たり前のことを当たり前に ! ! ! ! ! ! バージョン管理理 コーディング規約 コードレビュー テスト⾃自動化 ドキュメント … 基礎なくして応⽤用のテクニックを⽬目指さない まず当たり前のことから当たり前に
83. 組織づくり ! 単にDevOps専任組織を作ってもうまくいかない ! 既存チームにDevOpsという名前をつけても変わらない ! 全員が同じゴールに向かって進めるか • チームのゴールと個⼈人のゴールが相反したらどうなる？ • ⼈人事考課が個⼈人の成果に⼤大きな⽐比重を置きすぎると？
85. DevOpsは銀の弾丸ではない ! ⼤大事なことなので2度度⾔言いました…
86. ⾃自分の組織にとっての DevOpsとは何なのか？どう なれば成功かを考え、着実に ⼩小さい成功を積み上げる
87. Drive Your Business!!
