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