今さら聞けない人のためのDevOps超入門 ODC2024 9月7日バージョン
Download as PPTX, PDF0 likes31 views
今さら聞けない人のためのDevOps超入門 ODC2024 9月7日バージョン
今さら聞けない人のためのDevOps超入門 ODC2024 9月7日バージョン
- 1. 今さら聞けない人のための DevOps 超入 門 日本仮想化技術株式会社 代表取締役社長兼 CEO 宮原 徹 (@tmiyahar) https://VirtualTech.jp
- 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. 日本仮想化技術株式会社 概要 • 社名：日本仮想化技術株式会社 – 英語名： VirtualTech Japan Inc. – 略称：日本仮想化技術／ VTJ • 設立： 2006 年 12 月 • 資本金： 3,000 万円 • 売上高： 1 億 8100 万円（ 2022 年 7 月期） • 本社：東京都渋谷区渋谷 1-8-1 • 取締役：宮原 徹（代表取締役社長兼 CEO ） • 伊藤 宏通（取締役 CTO ） • スタッフ： 11 名（うち 8 名が仮想化技術専門エンジニアです） • URL ： http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築・運用サポート – 5G 活用のためのインフラ・サービス研究開発 – DevOps 支援サービスの提供 – GPU を活用した超高速データ分析基盤「爆速 DB 」の提供 ベンダーニュートラル な独立系仮想化技術の エキスパート集団 3
- 4. 「かんたん DevOps 」とは • どんなツールを使うべきか、何を行うべきか を、汎用的な DevOps 環境と手順書として提 供します。 • それらの使い方や、 DevOps に関する改善を 行うためのサポートを提供します。 DevOps に関する経験やノウハウがなくても、プロジェクトの最初か ら DevOps で開発できるように支援いたします。 ツールとプラクティスで今すぐ始められ る DevOps 支援サービス フルマネージドで DevOps チームに参画する 「おまかせ DevOps 」も提供
- 6. Think IT に DevOps 連載あり ます 6 https://thinkit.co.jp/series/10843
- 8. 本日のアジェンダ • 開発・運用の課題と DevOps • DevOps を支える技術 • DevOps 実践のための課題と取り組み • DX の実現やクラウドの効果的な活用のため に DevOps の必要性が高まっている • 自社の DevOps 的な経験からエッセンスを抽 出し、 DevOps 支援サービスを提供 • サービス開発・提供で得られた知見を解説 8
- 10. よくある開発・運用環境の課題 • 開発チームと運用チームは分離されてい る – ウォーターフォール型 – 縦割り（上下に横割り？）体質 • プロジェクト毎に体制が統一されていな い – 隣のチームの業務内容がわからない – 良い方式を採用しているプロジェクトが あっても他チームに共有されていない 10
- 11. 開発と運用の質的違い • 開発者は常に変化を求める（攻め） • 運用者は常に安定を求める（守り） ↓ • このままでは利用者のニーズに応えら れず発展しない（改善されない） ↓ • 変化のリスクを組織改革とツールで低 減 11
- 12. DevOps とは？ • 開発と運用が密に連携して協力しあう開 発手法 – DevOps を支援する技術やツールを積極的に利 用 – 開発は新しい機能を安心してリリースできる – 運用は新しい機能を安心して受け入れられる ↓ 変化に対して前向きに進みやすくする 12
- 13. DevOps の利点 • PDCA サイクルを早く回す – 開発・運用間のオーバーヘッドをなくす – コミュニケーションが円滑になる – プロジェクトの滞りを削減できる • ユーザーのニーズに迅速に応える – リリース期間を短縮することで要望に対し 素早く応えることができる • システムの価値が高まりビジネスへ繋げ る 13
- 14. PDCA サイクル Plan Do Act Check DevOps は PDCA を加速させる 14
- 15. DevOps のビジネス的なメリッ ト マネジメント層の視点から • 開発状況の可視化 – 進捗が分かる←チケット駆動開発 – 品質が分かる←テスト駆動開発 • 開発手法の標準化 – 自己流での開発からの脱却 – 生産性の向上 非技術的な観点からの納得感も重視
- 17. モデル環境について 17 CircleCI テスト コンテナ ビルド デプロイ AWS ECR EKS コンテナ イメージ コンテナ イメージ Pod GitHub プルリク マージ Slack 通知 テスト JOB のみ実行 全 JOB 実行 テスト結果通知 Push デプロイ DevOps の 環境例 Visual Studio Code Push 各要素は 差し替え可能
- 18. DevOps を支える要素・技術 • 自動化 – テストの自動化 – インフラ構築の自動化 • 効率化 – 継続的インテグレーション (CI) – 継続的デリバリー (CD) • チーム開発（共有化？） – インフラ（ IaC ）も含めたバージョン管理 – チケット駆動開発によるタスクの明確化 18
- 19. インフラ構築の自動化 （ IaC ） • 手順書ベースによる構築の課題 – 手間がかかる – 設定ミス等が起きやすい • 自動化ツールによる構築 – 仮想化、コンテナ化、クラウド化により容 易に実現できるようになった – 誰が何度実行しても同じ結果になる – 設計書との相違が起きにくくなる – 障害復旧が容易（再構築） 19
- 20. 継続的インテグレーション (CI) • ビルドやテストを短期間で繰り返し行い開 発効率を上げる手法 – 定期的に実行（デイリービルド） – バグを早期に発見（短期間で繰り返しテスト） – 他のツールと連動（進捗管理等） • 代表的なツール – Jenkins – CircleCI (SaaS) ・ Travis CI (SaaS) – GitHub Actions ・ GitLab CI/CD 20
- 21. 継続的デリバリー (CD) • CI の仕組みをインフラ構築まで拡張 – テストした成果物を自動デプロイメント • インフラ構築自動化やコンテナと組み 合わせることで短時間で構築可能 – Kubernetes で構築されたコンテナ環境の活 用 – テスト環境と本番環境を同等の構成で構築 – インフラを含めた結合テストを自動化 21
- 22. Git を利用したバージョン管理 • ソースコード等の共有 – 変更履歴を記録、追跡 – 履歴の用途毎に分岐して管理（ブランチ） – 切り戻しが容易 • プルリクエスト機能によりレビューを 可視化 • 他のツールとの連携 – CI ツール連携や GitOps – チケット管理ツール（ Redmine など） 22
- 23. git-flow の例 main hotfix-001 release-ver1 develop feature-001 feature-002 Ver.0.1 Ver.0.2 Ver.1.0 機能追加 Ver.1 リリース準 備 機能追加 23 緊急バグ修正 バグ修正
- 24. テスト自動化のメリット • 人力に比べて短時間でテストが可能 • 手動では困難なテストも容易に • リソースの有効活用 – システムリソース：夜間などに自動実行 – 人的リソース：繰り返し行うテストで省力化 • テストの品質向上 – 一貫性の保持（属人性の排除） – 再現性の確保（誰が行っても再現する） • テストツールの再利用、横展開 24
- 25. テスト自動化のデメリット • 初期コストは高い – 継続的に利用することで費用対効果が上が る – 要求される仕様に大きな変更が加えられる と、テストコードにも影響する • テスト自動化は万能ではない – テストコードを書くのは自分たち – 書いたコード以上のテストはできない 25
- 26. 代表的なテスト • 静的テスト – プログラムを実行せずコード解析のみでバグ、 脆弱性、表記の揺れ等をチェック – レビューの自動化 • 単体テスト・ユニットテスト – 実装した機能（メソッド、モジュール等）単体 で仕様通りに動作するかチェック • 統合テスト・結合テスト・ End to End テスト – 実装した機能がうまく連携して動作するか チェック 26
- 27. 標準化によるメリット • プロジェクト毎に個別差がなくなる – 属人性が軽減される – 他のチームやマネージャが状況を把握しや すくなる • フットワークが軽くなる – 既存のモデルやテンプレートの活用で新規 案件をすばやく立ち上げられる 27
- 29. DevSecOps • システム開発・運用のプロセス全体において セキュリティを考慮する取り組み（広義） • 開発からリリースのサイクル（ CI/CD ）にセ キュリティ対策を織り込む（狭義） • 要点は「テスト自動化」と「迅速なリリー ス」 • DevOps を確立して改善、あるいは Sec を考慮 しながら DevOps を進めていく 29
- 30. SBOM 対応 • SBOM （ Software Bill of Materials ） – ソフトウェア部品表 – システムを構成するソフトウェアの管理 • SPDX （ The Software Package Data Exchange ）、 CycloneDX などのフォーマットがある – SPDX は ISO/IEC 5962:2021 として標準化 • DevSecOps 的にはコンテナ、ミドルウェアあたりを SBOM 化 • SBOM はあくまで管理情報フォーマットなので脆 弱性情報と連携した管理ツールが別途必要な点に 注意 30
- 31. 脆弱性管理クラウド yamory • DevSecOps に活用できる SaaS – パートナーとしてサービス提供します • アプリライブラリ（開発向け機能） – アプリケーションで使用しているミドル ウェアやフレームワークの脆弱性をスキャ ン • ホストスキャン（インフラ向け機能） – OS やコンテナなどの脆弱性をスキャン • 管理対象情報として SBOM 読込も可能 31
- 32. DevOps のモデルケース • 開発環境から本番環境まで一貫した実行環境 – コンテナベースでの実行環境で開発環境と本番環境の差異を最小化 – アプリケーションコードのみではなく、インフラ設定もコード化し、 GitHub で管理 • テストを自動化し、動かないソースコードが混入することを回 避 – プルリクエストが発行された場合、テストを自動実行。レビュー前に 単体テストが確実に通る状態を保証する。 – テストの結果はSlack に通知し、問題がある場合に即時対応可能にする • CircleCI を使用してCI/CDのパイプラインを実行 – ソースがマージされた場合にテストを実行した上で、GitHub で管理さ れた設定をもとにコンテナをビルド、デプロイを実行。 – AWS EKS を利用して、柔軟な環境構築を実現 32
- 34. DevOps 実践のために • 手段と目的を履き違えない – DevOps 導入を目標にしない – 現状の課題を DevOps 導入で解決 • 新技術を取り入れる柔軟さと協力体制 – DevOps 導入により従来とは違う「文化」 を取り入れなければならない • 抵抗勢力も生まれやすい – トップダウンでスピード感のある改革が必 要 34
- 35. CI ツールの導入 • CI ツールで開発の基本プロセスを自動 化 • 手動で実行していることを自動化する – ソースコードやコンテナのビルド – テストの自動化 • CD の実現まで – インフラ構築運用の自動化 35
- 36. Slack を使った ChatOps • 既存環境に影響を与えず導入可能 • メールと比較して意見を言いやすい – 心理的抵抗が下がる – チーム内のコミュニケーションが活発にな る – LGTM (Looks Good To ME) ＝いいと思うよ 36
- 37. Redmine を使ったチケット駆動開発 • タスク一覧とガントチャートで進捗状 況を一括管理 • プロジェクト内の情報を共有、蓄積 • ChatOps との連動 37
- 38. デプロイの自動化 • エージェントレスでの導入が可能 • 学習コストが低い • 定常作業のコード化、自動化 • 最近は Terraform も活用してます 38
- 39. まとめ • 開発と運用の一体化 • 手作業から自動化への意識変革 • 安心してリリースできるサイクルの確 立 • セキュリティ課題にすばやく対応 • テストへの取り組みは大きな課題 • まずは CI あたりから始めてみよう 39
- 40. 40 ありがとうございました