DevOps_新卒エンジニア研修.pdf

 DevOps_新卒エンジニア研修.pdf

07d2f262fd910920293599896683c2b2?s=128

Yoshinori Sasaki

May 13, 2018
Tweet

Transcript

  1. DevOps 2018.05.13 新卒エンジニア研修

  2. 佐藤 有花 Yuka Sato 株式会社ガイアックス 2015年4月入社 6月DCD配属 2016年6月RNDへ移籍 さきがけチーム所属 現在までTRUSTDOCK事業部で開発を担当

    スペシャリストではないけれど 事業を作っていきたい系エンジニアです
  3. 本講義の目的 • DevOps の本質を理解する • DevOps の文脈でよく登場するキーワードについて理解する ◦ 継続的インテグレーション、継続的デリバリー、継続的デプロイ ◦

    Immutable Infrastracture、Infrastracture as Code、Blue Green Deployment • DevOps のための主要なツールとその使い方を知り、事業配属後の導入や運用に 役立てる
  4. 本講義の内容 • DevOps とは ◦ 30min • DevOps の実践 ◦

    30min • 課題 ◦ 30min • Immutable Infrastracture / Infrastracture as Code / Blue Green Deployment ◦ 30min • 課題 ◦ 60min • TRUSTDOCK での DevOps ◦ 15min
  5. DevOps ってなに?

  6. DevOps ってなに? 開発と運用が連携すること?

  7. DevOps ってなに? ツールを使って自動化すること?

  8. DevOps ってなに? 1日に何度もデプロイすること?

  9. DevOps の定義を調べてみよう

  10. DevOps の定義 DevOps はソフトウェア開発手法の一つ。開発(Development)と運用(Operations) を組 み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法を さす。ソフトウェアのビルド、テスト、そしてリリースの文化と環境を以前よりも迅速に、頻 繁に、確実に発生する確立を目指している。(Wikipedia) DevOps とは、開発部門と運用部門が密に連携し、様々な手法と文化を取り入れ商品

    やサービスの改善にかかる時間を短縮し、迅速にビジネスニーズに応えること。 (DevOps導入指南)
  11. DevOps の定義 DevOps では、従来型のソフトウェア開発と、インフラストラクチャ管理プロセスを使用す るよりも速いペースで製品の進歩と向上を達成し、企業がアプリケーションやサービスを 高速で配信できるように、文化的な基本方針、プラクティス、ツールが組み合わされてい ます。この高速化により、企業は顧客により良いサービスを提供し、市場競争力を高め ることができます。(AWS) DevOpsとは、ソフトウェアの開発担当と導入・運用担当が密接に協力する体制を構築 し、ソフトウェアの導入や更新を迅速に進めること。(IT用語辞典

    e-words) DevOps の定義は、厳格には決められていないのが現状
  12. DevOps の定義 DevOps を調べると、働き方や文化、組織構造、ツール、アーキテクチャなどを内包する 広い概念であることが分かる ここで、DevOps という言葉の理解が皆バラバラだと • 自分たちに DevOps

    が必要なのか? • 自分たちは DevOps の何から始めるべきか?どこを取り入れるべきか? が判断しにくい だから、DevOps の本質を正しく理解する必要がある そこで、DevOps が誕生した背景を知り、DevOps が必要になった状況について考えて みよう
  13. DevOps が誕生した背景

  14. DevOps が誕生した背景 DevOps の誕生までの土壌として、以下の2点がある 1. アジャイル開発による継続的な改善への変化 2. 継続的な改善における運用課題

  15. アジャイル開発による継続的な改善への変化 ビジネスニーズの変化の早さに対応するため、ウォーターフォール開発からアジャイル 開発へシフトした結果、従来では考えられなかった頻度でのリリースに対応する必要が 生まれた • ウォーターフォール開発 ◦ 要件定義・開発・テスト・リリースの工程を一つ一つ時間をかけて作り上げていく • アジャイル開発

    ◦ 必要最小限の製品を作り上げ、その後も小さな変更を頻繁にリリースして改善していく そこで「効率化や自動化を行い、リリースまでにかかる時間を短縮しよう」という考え方 が生まれ、継続的に成果物を仕上げていく体制へと進化した
  16. 継続的な改善における運用課題 しかし、開発だけでは進められる効率化や自動化に限界があった 特にインフラの構築や設定変更には、開発チームと運用チームとが分断されていること で様々な問題が起こりやすかった 開発チームと運用チームが分断されていると... • 運用はアプリの影響範囲が分からないため、中 途半端な対応しかできず技術的負債を抱えや すい •

    開発はモニタリング・冗長化・バックアップ等の 非機能要件をチェックし忘れる
  17. DevOps の誕生 2009年に O'Reilly 主催のカンファレンス Velocity にて、Flickr のエンジニアが“10+ Deploys per

    Day” という発表を行い、ここで初めて「DevOps」という言葉が登場した 開発と運用で達成すべきミッションが異なるため、対 立関係が起こりやすいが... • 開発は「改善のために変更したい」 • 運用は「安定稼働のために変更したい」 開発も運用も「変化するビジネスニーズに応える」と いう同じミッションに向かおう 変更のリスクは手法と文化によって軽減しよう = DevOps だ!
  18. DevOps の本質 こうした背景から、開発と運用が「変化するビジネスニーズに応える」という同じミッション に向かって協力する、そのために様々な手法や文化を取り入れることが DevOps と言 える これを踏まえて、本講義では DevOps の定義を下記として進める

    DevOps とは、開発と運用が密に連携し 様々な手法と文化を取り入れ 迅速にビジネスニーズに応えること
  19. 自分たちに DevOps は必要?

  20. 自分たちに DevOps は必要? 正解はない が、新規事業の初期段階ではクラウドが当たり前であり 「開発と運用の対立」は少ないが「開発と運用の兼任」が多い 開発しか見えていないと、運用開始後に多くの問題が発生したり、継続的に改善を続け ることが難しくなったりするかもしれない 自分たちのその時の課題に合わせて、必要なところから取り入れよう

  21. DevOps の実践

  22. 開発サイクルの効率化

  23. 開発サイクルの効率化 変更をコミット→ビルド・テスト→テスト環境にデプロイ→本番環境にデプロイ この開発サイクルを効率化しよう

  24. 継続的インテグレーション (CI) とは、バージョン管理システムにコードをコミットしたタイミ ングで、自動的にコードのビルドとテストを実行すること 継続的インテグレーション

  25. • 早期に問題を発見できる • テストやビルドを変更の度に実行するコストが削減できる • テストやビルドの実行漏れを防げる • テスト結果が見える化され、チームで共有できる 継続的インテグレーション

  26. 継続的インテグレーション 1. 開発者は自分のローカル環境にコードをチェックアウトする 2. コードの変更が完了したら、変更をコミットし、リポジトリにプッシュする 3. CI サーバはリポジトリを監視し、変更が発生したときにチェックアウトする 4. CI

    サーバは設定ファイルに記されたとおりに環境を構築し、コードのビルド、ユニッ トテストと統合テストを実行する 5. CI サーバは成功をチームに通知する 6. ビルドまたはテストが失敗した場合、CI サーバは失敗をチームに通知する 7. チームはできるだけ早く問題を修正する 8. 継続的にプロジェクト全体の統合とテストを継続する
  27. CI ツール 自前で CI サーバを立てることもできるが、継続的インテグレーションを支援するツール を利用することで楽に導入できる - Jenkins - CircleCI

    - TravisCI
  28. 継続的デリバリー (CD) とは、継続的インテグレーションを拡張した概念であり、本番環 境へのリリースの手前までを自動化する セキュリティテスト、性能テスト、負荷テスト、障害テスト、受け入れテストなどのあらゆる テストの自動化を含む 継続的デリバリー

  29. 継続的デプロイ 継続的デプロイ (CD) はさらに拡張した概念であり、本番環境へのリリース完了までを 自動化する

  30. インフラ管理の効率化

  31. Infrastructure as Code Infrastructure as Code とは、インフラの設定変更手順を自動化するためにコード化す ること。これにより、ソフトウェア開発の手法をインフラの構築にも適用可能とすること • インフラの構成や設定を共有できる

    • 誰でも再現でき、属人性を排除できる • 自動化により迅速に確実に設定が適用できる • バージョン管理やテスト駆動開発などの開発手法を適用可能になる
  32. Infrastructure as Code Infrastructure as Code を実現するツールとして、プロビジョニングツール(構成管理 ツール)がある • Chef

    • Itamae • Ansible
  33. Immutable Infrastructure Immutable Infrastracture は、一度構築・稼働したインフラには手を加えないという考え 方。変更を加える際は古いサーバを破棄し、新しくサーバを一から構築する 変更の度に手動でサーバ構築するのは大変なので、Infrastracture as Code で自動化

    する 古いサーバから新しいサーバに切り替えるのにサービス停止が必要になるので、Blue Green Deployment を取り入れる
  34. Blue Green Deployment Blue Green Deployment とは、Blue と Green と呼ばれる2種類の環境を用意し、どち

    らか一方のみユーザが利用するようにする ユーザが利用していない環境にリリース作業を行い、Blue と Green の接続先を切り替 えることで、サービス停止なく切り替え完了させる トラブル発生時には、ユーザの接続先を戻すだけで復旧が可能となる。切り替え後、トラ ブルに対する調査や対応はもう一方の環境に対して行えば良い • サービス停止なしに変更をリリース可能 • ロールバックが簡単
  35. 応用課題 • CircleCI でプロジェクトを作り、ビルドしてみよう • Github と CircleCI を連携し、ビルドが通るまで master

    ブランチにマージできない ようにしよう • CodeDeploy を使って既存のサーバに最新のコードを自動デプロイしよう • CI でビルドが成功したら、CodeDeploy でデプロイが実行されるようにしよう • Ansible でサーバに設定を適用しよう • CodeDeploy を使って Blue-Green Deployment をやってみよう