Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

今さら聞けない人のためのDevOps超入門

2,263 views

Published on

開発・運用の課題とDevOps
DevOpsを支える技術
DevOps実践のための課題

Published in: Technology
  • Be the first to comment

今さら聞けない人のためのDevOps超入門

  1. 1. 今さら聞けない人のための DevOps超入門 日本仮想化技術株式会社 代表取締役社長兼CEO 宮原 徹(@tmiyahar) http://VirtualTech.jp
  2. 2. 自己紹介 • 本名:宮原 徹 • 1972年1月 神奈川県生まれ • 1994年3月 中央大学法学部法律学科卒業 • 1994年4月 日本オラクル株式会社入社 – PCサーバ向けRDBMS製品マーケティングに従事 – Linux版Oracle8の日本市場向け出荷に貢献 • 2000年3月 株式会社デジタルデザイン 東京支社長および株 式会社アクアリウムコンピューター 代表取締役社長に就任 – 2000年6月 (株)デジタルデザイン、ナスダック・ジャパン上場(4764) • 2001年1月 株式会社びぎねっと 設立 • 2006年12月 日本仮想化技術株式会社 設立 • 2008年10月 IPA「日本OSS貢献者賞」受賞 • 2009年10月 日中韓OSSアワード 「特別貢献賞」受賞 • ガンダム勉強会主宰・好きなモビルスーツはアッガイ 2
  3. 3. 日本仮想化技術株式会社 概要 • 社名:日本仮想化技術株式会社 – 英語名:VirtualTech Japan Inc. – 略称:日本仮想化技術/VTJ • 設立:2006年12月 • 資本金:3,000万円 • 売上高:8,700万円(2015年7月期) • 本社:東京都渋谷区渋谷1-8-1 • 取締役:宮原 徹(代表取締役社長兼CEO) • 伊藤 宏通(取締役CTO) • スタッフ:8名(うち、6名が仮想化技術専門エンジニアです) • URL:http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術に関連したソフトウェアの開発 – 仮想化技術を導入したシステムの構築 – OpenStackの導入支援・新規機能開発 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 3
  4. 4. 情報サイト:EnterpriseCloud.jp • OpenStackで始めるエ ンタープライズクラウ ドの情報サイト • OpenStack導入手順 書のダウンロード • 各種プレゼン資料 • その他ブログ記事 4
  5. 5. 会社のご紹介 仲間募集のお知らせ
  6. 6. 日本仮想化技術株式会社は • 仮想化技術のエキスパート集団 • 進取の精神 • 豊富な検証機材で新技術を追求 • 自由な雰囲気の職場 6
  7. 7. 一緒に頑張ってくれる仲間を募集中 • サーバー、ネットワークエンジニア – 新卒からキャリアアップしたい経験者まで – クラウド技術、自動化技術に興味がある人 • コンサルタント – 通信系に強い人大歓迎 • 短期インターン – 学生はもちろん、社会人も可 7
  8. 8. お問い合わせ先 メールにて recruit@VirtualTech.jp 履歴書、職務経歴書をご用意ください ご紹介も是非。きっと何かいいことあります。 8
  9. 9. どんなオフィス? •渋谷駅より徒歩5分 •全員がゆったりデスク とアーロンチェア 9
  10. 10. オフィスは渋谷駅至近 10 日本仮想化技術 オフィス ハ チ 公 渋谷駅東 口 交差点信 号 渋 谷 駅 ヒカリエの中を通ると 雨の日にあまり濡れません 渋 谷 郵 便 局
  11. 11. 優れた環境が優れた成果を生む 渋谷駅徒歩5分の新オフィス 幅140cmのゆったりデスクとアーロンチェア MacBook Pro/Airと大型液晶モニタが標準 キーボード・マウスも自由 充実の検証環境 最新機材で作業 11
  12. 12. 充実の福利厚生 • マッサージチェア • 充実のフリードリンクコーナー – 各種お茶類、ネスプレッソなど各種取り揃え • 誕生日はケーキでお祝い • 雑誌年間購読制度 – 何でも好きな雑誌を年間購読 • 書籍購入支援制度 – 好きな書籍(漫画も可)を1万円/年購入 12
  13. 13. ケーキでお祝い 13
  14. 14. 書籍購入支援制度 活用例 14
  15. 15. 今週の課題図書的な 弊社外の人も読んでいたり15
  16. 16. という話をOSC北海道でしたら… 16
  17. 17. 北海道大学の学生が 来春新卒入社することになりました 17
  18. 18. 言ってみるものですね 18
  19. 19. 本日のアジェンダ • 開発・運用の課題とDevOps • DevOpsを支える技術 • DevOps実践のための課題 • クラウド環境を大きく活用するための方法論 を検討している中であらためてDevOpsに注目 • 自社のDevOps的な経験からエッセンスを抽 出し、今後DevOpSaaSを提供予定 • 私自身サービス化を目指して勉強中です 19
  20. 20. 開発・運用の課題とDevOps
  21. 21. よくある開発・運用環境の課題 • 開発チームと運用チームは分離されている – ウォーターフォール型 – 縦割り(横割り?)体質 • プロジェクト毎に体制が統一されていない – 隣のチームの業務内容がわからない – 良い方式を採用しているプロジェクトがあっても共 有されていない • ソースコード管理が曖昧なことも – 管理手法が標準化されていなく、最新版との同期 が取れていない 21
  22. 22. よくある開発・運用環境の課題 • 開発者は常に変化を求める(攻め) • 運用者は常に安定を求める(守り) ↓ • このままでは利用者のニーズに応えられ ず発展しない ↓ • 変化のリスクを組織改革とツールで低減 22
  23. 23. DevOpsとは? • 開発と運用が密に連携して協力しあう開発 手法 – DevOpsを支援する技術やツールを積極的に 利用 – 開発は新しい機能を安心してリリースできる – 運用は新しい機能を安心して受け入れられる ↓ 変化に対して前向きに進みやすくする 23
  24. 24. DevOpsの利点 • PDCAサイクルを早く回す – 開発・運用間のオーバーヘッドをなくす – コミュニケーションが円滑になる – プロジェクトの滞りを削減できる • ユーザーのニーズに迅速に応える – リリース期間を短縮することで要望に対し素早 く応えることができる – システムの価値が高まりビジネスへ繋げる 24
  25. 25. PDCAサイクル Plan Do Act Check DevOpsはPDCAを加速させる 25
  26. 26. DevOpsのビジネス的なメリット マネジメント層の視点から • 開発状況の可視化 – 進捗が分かる←チケット駆動開発 – 品質が分かる←テスト駆動開発 • 開発手法の標準化 – 自己流での開発からの脱却 – 生産性の向上 非技術的な観点からの納得感も重視
  27. 27. DevOpsを支える技術 テスト自動化を中心に
  28. 28. DevOpsを支える要素・技術 • 自動化 – テストの自動化 – インフラ構築の自動化 • 効率化 – 継続的インテグレーション(CI) – 継続的デリバリー(CD) • チーム開発(共有化?) – 運用モデルに基づくバージョン管理 – チケット駆動開発によるタスクの明確化 28
  29. 29. テスト自動化のメリット • 短時間でテストが可能 • 手動では困難なテストも容易に • リソースの有効活用 – システムリソース:夜間などに自動実行 – 人的リソース:繰り返し行うテストで省力化 • テストの品質向上 – 一貫性の保持(属人性の排除) – 再現性の確保(誰が行っても再現する) • テストツールの再利用、横展開 29
  30. 30. テスト自動化のデメリット • 初期コストは高い – 継続的に利用することで費用対効果が上がる – 要求される仕様に大きな変更が加えられると、 テストコードにも影響する • テスト自動化は万能ではない – テストコードを書くのは自分たち – 書いたコード以上のテストはできない 30
  31. 31. 代表的なテスト • 静的テスト – プログラムを実行せずコード解析のみでバグ、脆弱性、表記の揺れ等を チェック – レビューの自動化 – infer (C/Java/Objective-C) – RuboCop (Ruby/Rails) • 単体テスト・ユニットテスト – 実装した機能(メソッド、モジュール等)単体で仕様通りに動作するか チェック – JUnit (Java) – RSpec (Ruby) • 統合テスト・結合テスト・エンドツーエンドテスト – 実装した機能がうまく連携して動作するかチェック – Selenium (Webアプリ全般) – Turnip (Ruby/Rails) – Infrataster (インフラ周り) 31
  32. 32. インフラ構築の自動化 • 手順書ベースによる構築の課題 – 手間がかかる – 設定ミス等が起きやすい • 自動化ツールによる構築 – 仮想化、コンテナ化、クラウド化により容易に 実現できるようになった – 誰が何度実行しても同じ結果になる – 設計書との相違がおきにくくなる – 障害復旧が容易(再構築) 32
  33. 33. 継続的インテグレーション(CI) • ビルドやテストを短期間で繰り返し行い開発 効率を上げる手法 – 定期的に実行(デイリービルド) – バグを早期に発見(短期間で繰り返しテスト) – 他のツールと連動(進捗管理等) • 代表的なツール – Jenkins – Atlassian Bamboo – CircleCI (SaaS) – Travis CI (SaaS) 33
  34. 34. 継続的デリバリー(CD) • CIの仕組みをインフラ構築まで拡張 – テストした成果物を自動デプロイメント • インフラ構築自動化と組み合わせることで 短時間で構築可能 – テスト環境と本番環境を同等の構成で構築 – インフラを含めた結合テストを自動化 34
  35. 35. Gitを利用したバージョン管理 • ソースコード等の共有 – 変更履歴を記録、追跡 – 履歴の用途毎に分岐して管理(ブランチ) – 切り戻しが容易(リベート) • プルリクエスト機能によりレビューを可視化 • 他のツールとの連携 – Jenkins – Redmine 35
  36. 36. Gitを利用したバージョン管理 A successful Git branching model http://nvie.com/posts/a-successful-git-branching-model/ – リリース用と開発用の2つのメインブランチを 用意 – 機能追加、バグフィックス等Issue登録を行う毎 にメインブランチから切り出す – 問題が起きても本番用ブランチや他の人の開 発には影響しない – GitLabではプルリクエスト機能によりレビュー を可視化 36
  37. 37. 代表的なブランチモデル master hotfix-001 release-ver1 develop feature-001 feature-002 Ver.0.1 Ver.0.2 Ver.1.0 バグの修正 機能追加 Ver.1プロトタイプ 機能追加 37
  38. 38. バージョン管理とCI/CD • インフラ環境を自動構築しテスト – クラウドやコンテナを活用 – 本番同様のインフラ環境でテストが可能 • 本番環境へのリリース時も毎回新規構築 – リリース直後に問題が発生した場合でも、旧 環境へすぐに切り戻せる 38
  39. 39. 標準化によるメリット • プロジェクト毎に個別差がなくなる – 属人性が軽減される – 他のチームやマネージャが状況を把握しやす くなる • フットワークが軽くなる – 既存のモデルやテンプレートの活用で新規案 件をすばやく立ち上げられる 39
  40. 40. CI/CD/DevOpsの範囲 コード修正 静的テスト ビルド 単体テスト / 統合テスト インフラ構築 / デプロイメント 本番 運用 継続的インテグレーション(CI) 継続的デリバリー(CD) DevOps
  41. 41. DevOpsのモデルケース • 開発者には簡易的な実行環境 – VirtualBox+Vagrant、Dockerの利用 – 環境構築スクリプトもGit等で共有可能 • Jenkinsサーバーにテストツールと実行環境を構築 – テスト負荷が大きい場合はSlaveを用意 • テスト完了後ステージング環境へデプロイ – インフラの自動構築 – git pullコマンドで更新 • 問題がなければ本番環境へデプロイ – Blue/Green Deployment 41
  42. 42. モデル環境について コードの 修正 ローカル Git 本番環境 (Dockerコンテナ) master ブランチ develop ブランチ deploy ジョブ test ジョブ Webアプリ commit push テスト結果を 通知 merge mergeを 検知 コンテナの 作成 pushを 検知 1世代前の 本番環境 更新前の Webアプリ 旧コンテナを 切り替え 42
  43. 43. DevOps実践への課題
  44. 44. DevOps実践のために • 手段と目的を履き違えない – DevOps導入を目標にしない – 現状の課題をDevOps導入で解決 • 新技術を取り入れる柔軟さと協力体制 – DevOps導入により従来とは違う「文化」を取り 入れなければならない • 抵抗勢力も生まれやすい – トップダウンでスピード感のある改革が必要 44
  45. 45. Slackを使ったChatOps • 既存環境に影響を与えず導入可能 • メールと比較して意見を言いやすい – 心理的抵抗が下がる – チーム内のコミュニケーションが活発になる – LGTM (Looks Good To ME)=いいと思うよ 45
  46. 46. Radmineを使ったチケット駆動開発 • タスク一覧とガントチャートで進捗状況を 一括管理 • プロジェクト内の情報を共有、蓄積 • ChatOpsとの連動 46
  47. 47. Ansibleを使ったデプロイの自動化 • エージェントレスでの導入が可能 • 学習コストが低い • 定常作業のコード化、自動化 47
  48. 48. DevOpSaaSに向けて 48
  49. 49. DevOpsの想定される進め方 1. ToBeモデルの構築 2. 現時点での課題の抽出 3. 優先順位の策定 4. PoC環境の構築と運用 5. PoC環境からのフィードバックと改善 6. 小規模社内展開 49 自社だけではスピード感のある DevOps推進は困難
  50. 50. DevOpSaaSが解決する課題 標準リファレンスモデル提供によるDevOpsの加速 • 各種ツールの組み合わせテスト済みパッケージの提供 – 標準機能はあらかじめ設定済み • 各種ツールのバージョンアップ追従 – 既存開発・運用環境からの移行支援 • 独自機能の提供 – 可視化ツール、既存ツールのカスタマイズなど • 開発運用担当者の教育・サポート – 標準ドキュメント、教育コースの提供 • サンプルの提供 – 自動化・テストスクリプトのサンプル
  51. 51. 提供される主な機能 • チケット管理 • ソースコード管理 • テスト自動化 • デプロイ自動化 • プロジェクトマネジメント • コミュニケーション 51
  52. 52. ありがとうございました 52

×