DevOpsは、アプリケーションを開発して公開し、サポートからのフィードバックを反映していく方法として主流になりつつあります。しかし、DevOpsを成功に導くには、組織面での複雑さやマシンデータの収集といった課題を克服する必要があります。
DevOps(デブオプス)とは、開発担当と運用担当が連携・協力し、フレキシブルかつスピーディーに開発するソフトウェアの開発手法です。DevOpsは、人、手法、ツールを連携させることで、開発チームと運用チームでのサイロ化を解消します。このアプローチを採用すると、アプリケーションやサービスの開発を加速できます。さらには、ITインフラ管理の対応を迅速化することで、変化の速い現在の市場に対応しながらIT製品の導入と更新を行うことができます。
Splunkは”高い拡張性、高度なインストリーム分析、ネイティブOpenTelemetryサポート”を提供し、リストで唯一の「アウトパフォーマー」のポジションを獲得しました。
クラウドオブザーバビリティのGigaOmレーダーレポート 2022年版 ~ Splunkが市場リーダーに認定
DevOpsの目的は、アプリケーションのコードを作成するソフトウェア開発(Dev)と、そのアプリケーションを稼働させてエンドユーザーに提供し、保守を行うIT運用(Ops)を隔てるギャップを埋めることで、それ以前のトレンドだったアジャイル開発とリーン生産方式から発展しています。アジャイル開発は、作業を短く区切って短い間隔で反復することに重点を置き、IT開発組織の即応性を向上させる手法です。リーン生産方式は、工場での無駄の最小化と生産性の最大化を図る手法です。
DevOpsは、従来サイロ化していたソフトウェア開発、品質保証、IT運用の各チームを統合して効率化する。
DevOpsは、アジャイル開発に伴うボトルネックを解消します。アジャイル開発では、開発者が新しいソフトウェアや更新コードを頻繁に作成します。しかし従来の運用チームでは、そのソフトウェアを迅速にテストして実稼働させることが難しく、高速開発の真価が失われてしまうのです。結果としてアジャイル開発の普及によりソフトウェアの設計や構築の反復性と柔軟性は向上したものの、ソフトウェア開発ライフサイクル(SDLC)全体に及ぶアプローチにはなりませんでした。
文化的もしくは哲学的アプローチであるDevOpsでは、継続的開発、連携、透明性を重視します。IT運用に対するDevOpsの視点は総合的であり、価値に重きを置きます。個々の業務サイロに注目するのではなく、発案から製品や機能の提供に至るまでのフロー全体を視野に入れ、その間のすべてを最適化することで、より大きなビジネス価値を迅速に得ることを目指します。DevOpsがうまく機能すると、コーディングの反復と導入が迅速化するだけでなく、新しいアイデアを市場に投入するまでの時間が短縮し、バグが減少し、インフラの安定性が向上します。
この記事では、DevOpsの主要な概念・意味を紹介し、組織にDevOpsの文化を導入する際の糸口を明らかにします。
DevOps：開発と運用
アジャイルソフトウェア開発の始まりは、2001年に17人の開発者たちが発行した「アジャイルソフトウェア開発宣言」という短い文章です。この宣言では次の4つの基本原則が掲げられました。
- プロセスやツールよりも個人と対話を。
- 包括的なドキュメントよりも動くソフトウェアを。
- 契約交渉よりも顧客との協調を。
- 計画に従うことよりも変化への対応を。
従来のウォーターフォール開発では、順序の厳守と文書化を徹底し、役割、ツール、プロセスを厳格に定義し、開発をすすめます。一方で、開発チームがアジャイル開発を実践し始めてソフトウェア製品の反復を迅速化し、要件などの状況変更へ俊敏に対応できるようになっても、IT運用チームは必ずしもこの新しいスピードに対応する準備ができているとは限りませんでした。
2008年にベルギーのPatrick Debois氏と米国のAndrew Clay Shafer氏が、ITインフラに「俊敏性(アジャイル)」をもたらすための課題について議論を始めました。その1年後、Debois氏はイベント「DevOpsDays」をベルギーのヘントで初開催しました。このイベント以降、「DevOps」という言葉がIT分野で使われるようになりました。
DevOpsの以下の3つの基本原則は、DevOpsの支持者であるGene Kim氏が初めて著したものです。
- 体系的な思考：ITに対して、より総合的にアプローチする。開発者からテスター、インフラ管理者、コードやソフトウェアの使用者までを視野に入れ、「業務や部門など、個々のサイロのパフォーマンスではなく、システム全体のパフォーマンスを重視」します。
- フィードバックループの強化：Kim氏は「ほとんどのプロセス改善活動の目的は、フィードバックループを短縮および強化して、必要な修正を継続的に行えるようにすること」だと述べています。
- 継続的な試行と学習：アジャイルソフトウェア開発宣言では即応性と連携を重視していましたが、DevOpsで重視するのは継続的な改善、すなわち、より優れた新しい方法を発見し続けることです。Kim氏は「継続的に試行しながらリスクを引き受けて失敗から学ぶこと、そして成熟には繰り返しと実践が必須だと理解すること、この2つを奨励する文化」を作り上げる必要があると述べています。
DevOpsの文化では、さまざまな専門分野のメンバーで構成されるチームがベースとなり、新しい機能やサービスの構築と導入を継続的に行います。DevOpsでは、開発者は自分たちが作成したコードの保守を担当します。そうすることで、インシデントを効率的に解決できるだけでなく、何を開発するときにも信頼性を重視するようになります。また、DevOpsを実践するチームは、新機能の作成や新しいWebコンポーネント設計といった個々の担当プロジェクトに集中するのではなく、製品のライフサイクル全体に目を向けるようになります。このプロダクト主義(「プロジェクトではなくプロダクト」と強調されることもあります)は、ITをビジネス価値に整合させる効果があります。ビジネスとエンドユーザーに貢献する業務を優先することで、普及と利用を促進し、顧客のロイヤルティを醸成し、収益を高めます。これがDevOpsを実践することで、得ることができる効果です。
DevOpsとアジャイルの違い
DevOpsは、ソフトウェアの開発を対象としていたアジャイルの原則をソフトウェアの展開まで拡大したものです。アジャイルソフトウェア開発宣言による変革では、ソフトウェア開発方法の改善を目指していたのに対し、DevOpsではアジャイル開発をリリースにまで拡大して、同様の原則と哲学をソフトウェア開発ライフサイクル全体に適用します。つまり、対象範囲の違いがアジャイルとDevOpsの違いになります。
DevOpsにおける継続的開発
継続的開発とは、DevOpsの概念である継続的インテグレーションと継続的デリバリー(CI/CD)、そして継続的導入を包含するものです。年に1度(またはそれ以下の頻度で)まとめて大きなリリースをするのではなく、小さな改善を頻繁に実施してリリースし評価することで、ITチームは製品やサービスを常に改善できます。市場では、革新的な新興企業がトップ企業はおろか市場全体を圧倒することも珍しくありません。NetflixやInstagramのようなソフトウェアベース企業のコア製品でも、WebサイトやITサービスの改善でも、DevOpsにおける継続的開発を行うことで、このような市場においても競争力を維持できます。
DevOpsにおける継続的インテグレーション
DevOpsにおける継続的インテグレーションとは、1つのタスクを終えるごとに新しいコードをメインのソースコードに組み込む手法です。新しいコードを中央の共有リポジトリにチェックインすると、そこで自動的にビルドされ、変更のテストと検証が行われます。そうすることで問題をすぐに検出し、開発者に速やかにフィードバックを送り、すぐに必要な変更に取り組んでもらうことができます。
DevOpsにおける継続的デリバリー
DevOpsにおける継続的デリバリー (CI／CD)とは、新しいコードを統合された状態でテストする手法であり、継続的インテグレーションがもたらすスピードを活かすことができます。継続的デリバリーでは新しいコードのテストとステージングを自動で行い、導入できる状態にします。
このプロセスでは状況に応じて、単体テスト、統合テスト、機能テスト、回帰テストが行われます。コードが承認されると、導入に向けて自動的にステージングされます。ただし、ソフトウェアの継続的デリバリーでは、チェック済みのコードを自動的に導入するところまでは行いません。それは継続的導入で行います。
DevOpsにおける継続的導入
継続的インテグレーションと継続的デリバリーによって新しいコードが統合および承認されてから、それを自動的にリリースするプロセスがDevOpsにおける継続的導入です。自動デリバリープロセスでテストに合格したコードがステージングされ、実稼働環境にリリースされると、エンドユーザーはすぐにその新機能を使用できます。
コードが開発者からエンドユーザーに到達するまで手作業が介在しないので、継続的導入にはリスクが伴います。基本的には、継続的導入はリスクの低い製品や機能に向いています。機密データの取り扱い、高いセキュリティリスク、規制関連の義務、重大な経済的リスクがある場合、DevOpsを実践していても継続的導入を行うことはあまりありません。こうした考慮事項はあるものの、継続的導入はスピードをもたらし、価値実現までの時間を最大限に短縮できるため、一般的にはDevOpsにおける重要な目標のひとつとみなされています。
継続的導入と継続的デリバリーは、どちらも「CD」と略すことが多く、よく混同されます。しかし、継続的デリバリーはリリース可能な状態のソフトウェアをデリバリーするところまで指すのであり、その新しいソフトウェアを実際にエンドユーザー向けの実稼働環境に配置するのは継続的導入(または手動導入)です。
DevOpsのアーキテクチャ：クラウドや仮想化など
一般的にDevOpsのアーキテクチャとは、DevOps文化の目標達成を促進するインフラを意味します。DevOpsには特定のアーキテクチャが定められていないため、IT組織がDevOpsを導入する際に既存のアーキテクチャを捨てる必要はありません。とはいえ、DevOps組織のアーキテクチャに関する主要な原則やベストプラクティスは存在します。
DevOpsの登場とクラウドプラットフォームの登場は同時期であり、クラウドやその他の仮想化テクノロジーは、DevOpsの成功に大きく貢献しています。DevOpsの基盤となりDevOps導入、実践する組織を支援する一般的なテクノロジーとしては、クラウドプラットフォーム、仮想化、マイクロサービスがあります。
- クラウド：クラウドプラットフォームにより、オンプレミスではなく仮想環境(クラウド)でリソースをプロビジョニングでき、ユーザーは迅速かつきわめて柔軟にリソースを利用できます(下の「DevOpsにおけるクラウドの役割」を参照してください)。
- 仮想化：仮想化が登場するまで、サーバーは現実に存在するハードウェアであり、2台目のサーバーが必要になった場合は実物を購入する必要がありました。仮想化のおかげで仮想サーバー(または仮想デスクトップなど)を作成できるようになったため、ハードウェアをもう1台手配する代わりに、ソフトウェアチームが既存のオンプレミスサーバーまたはクラウドサーバー上に仮想環境を作成すれば済むようになりました。そのためアジャイルに作業を進めたいチームにとっては、大きなボトルネックが解消されたことになります。また、プロビジョニングが自動化されたことで、開発者が必要なリソースを利用できるようになるまでの時間も数分に短縮されました。
- マイクロサービス：マイクロサービスのアーキテクチャは、疎結合された限定的な機能単位で構成されており、これらの機能単位が集まってシステム全体を構成します。大規模なシステムやアプリケーションの場合、こうした単機能で再利用可能なモジュールで構成されていたほうが、容易に構築および変更できます。こうした非依存コンポーネントを使用すれば、DevOpsを実践する各チームが依存関係への影響を抑えてアップデートを導入できるため、変更によって障害を起こすリスクを抑えながら迅速に移行できます。DevOpsの書籍「DevOps: A Software Architect’s Perspective (DevOps：ソフトウェアアーキテクトの視点)」において、著者のLen Bass氏、Ingo Weber氏、Liming Zhu氏は「マイクロサービスのアーキテクチャスタイルは、DevOpsの発端となった数々の問題を解決するために考案された」と述べています。
DevOps組織のアーキテクチャでは、クラウド、仮想化、マイクロサービスを使用します。また、DevOpsのワークフローを実現するために、テストの自動化、監視、セキュリティ対策の最適化も目指します。一般的に、DevOpsでは自動化が主要な要素とされ、クラウドファーストだけでなく、自動化を推進するという傾向もあります。こうした傾向やベストプラクティスによってDevOps組織のアーキテクチャが形成されます。
DevOpsにおけるクラウドの役割
DevOpsの文化を実現するためには、クラウドコンピューティングが不可欠です。クラウドがもたらすスピード、規模、効率性によって俊敏性がもたらされ、DevOpsを実践するチームは業務のスピードと質を向上させることができます。SaaS (ソフトウェアとしてのサービス)ツールによってソフトウェアチームは効率性と経済性を手にしました。そしてSaaSソフトウェア自体が、DevOpsアプローチを必要とする継続的な反復的製品開発を行う例でもあります。
アプリケーションをすべてクラウドに置く必要はありませんが、DevOpsを導入するなら、新しいアプリケーションについてはクラウドファーストで考えるのが妥当でしょう。新しいアプリケーションやサービスを計画する際には、「これをクラウドに置くべきか？」ではなく、「クラウドに置かない理由はあるか？」と考えます。場合によっては、クラウドのセキュリティや規制関連のニーズ、インフラ全体に関することなど、何らかの事情があるかもしれません。しかしDevOpsを実践する場合、クラウドは1つの検討要素ではなくデフォルトであるべきです。
詳しくは「DevOpsを成功に導くクラウドの活用」をご覧ください。
DevSecOpsとは？
DevSecOpsとは、DevOpsのプロセスにセキュリティ対策を組み込んだものです。プロセスの最後に別のセキュリティチームにコードを渡して済ませるのではなく、全員がセキュリティについて責任を持ちます。DevSecOpsでは、セキュアなソフトウェアを迅速に提供する一方で、最終段階での不具合の発見や、それによってリワークが発生するのを抑止します。
一般的には、DevSecOpsの3つの基本原則は以下のとおりです。
- 開発プロセスの初期からセキュリティ対策を導入する。
- セキュリティをあるチームだけの課題とするのではなく、開発時の重要な責任として考える。
- セキュリティプロセスを自動化して、DevOpsの効率的なフローを維持する。
2012年に投稿されたDevSecOpsの宣言には、DevSecOpsの原則が詳細に定義されています。
詳しくは、電子書籍「DevSecOps成功のための6つの柱」をご覧ください。
DevOpsの当初からの提唱者であるDamon Edwards氏とJohn Willis氏が使い始めたのが、開発における主要な原則を表すCAMSという略語です。CAMSは、文化(Culture)、自動化(Automation)、評価(Measurement)、共有(Sharing)を意味しています。
また、DASA(DevOps Agile Skills Association)はDevOpsの6つの原則を発表しています。その概要は以下のとおりです。
- 顧客中心の活動：短いフィードバックループにより、顧客の視点を理解して採り入れます。
- 目標を意識した創造：各自の役割を厳格に定義するよりも、組織全体としてIT製品を組織内外の顧客に向けてどのように創造するか考えることを奨励します。
- エンドツーエンドの責任：各自が自分の役割の責任だけを負う(開発者はインフラの障害に関与せず、運用チームはコードの不具合について責任を持たない)のではなく、DevOpsではこうしたサイロを解消して、チーム全体として目的と責任を持って成果を出すことを目指します。
- 機能横断的な自律型チーム：ITの生産物1つ1つについて、それを発案してから提供し、改善のサイクルを経て廃棄するところまでをカバーするために、あらゆるスキルを持ち責任を果たすチームを構築する必要があります。
- 継続的改善：DevOpsを実践するチームは、常にスピードと質の向上、無駄の排除を目指します。
- 自動化できるものはすべて自動化：業務のスピード、効率、有効性を向上させるためには、ITによる自動化を可能な限り活用することがきわめて重要です。そうすることでチームメンバーに余裕が生まれ、より価値ある業務に従事したり、人的エラーを削減したりすることができます。
DevOpsのツール
DevOpsのツールとは、コード開発、テスト、インフラの管理を行い、DevOpsの原則の実践を支援するものです。DevOpsとは本来、ソフトウェア製品の作成と提供に関する文化を表すものですが(後述の「導入方法」を参照)、その文化の発展を現実に活かすには、自動化ツールなどの製品が欠かせません。
DevOpsを容易に導入できると謳ったツールは数多くあり、ソース管理、構成およびリリース管理、監視などのツールが存在します。
最適なDevOpsツールとは？
最適なDevOpsツールとは、DevOps文化を形成するプロセスと人のためのツールです。DevOpsは製品を買ってきて配備すれば「DevOpsが導入できた」と言えるものではありません。DevOpsテクノロジストのAlex Honor氏は、DevOps誕生から間もないころに「People Over Process Over Tools (ツールよりもプロセスを、プロセスよりも人を)」という投稿を公開し、DevOpsはツールよりも文化に重きを置いていると明言しています。
とはいえ、DevOpsの業務を支援する有名な製品はいくつもあります。著名なツールに絞って、オープンソースと独自ツールの両方を以下に示します。
- ソースコード管理：Git (GitLab、GitHub)、Bitbucket
- 構成管理：Puppet、Chef、Ansible、CFEngine
- リリース管理：Jenkins、Travis、CircleCl、TeamCity、Gradle、Bamboo
- オーケストレーション：Mesos、Zookeeper、Kubernetes
- 監視、仮想化、コンテナ化：Nagios、Icignia、Monit、OpenStack、Vagrant、AWS、Docker、Kubernetes
- ログおよびアプリケーションライフサイクル分析：Splunkは代表的なログ管理ツールであり、DevOpsに最適です。
DevOpsを導入するには？
DevOpsを導入するには、まず自社の現在の文化について考えます。迅速な開発、導入、フィードバック、そして継続的な反復を妨げるサイロやボトルネックを明らかにすることで、何を改善すべきかを把握します。
著作者であり、Splunkの最高テクノロジーアドボケートを務めるAndi Mann氏は、DevOps導入のアドバイスとして、「DevOps実現の道のりは各組織の独自性に基づいて決めるべきだが、成功するための重要な指標となる中間地点は必ず押さえること」と述べています。指針となる原則は、あつれきを取り除いてボトルネックを解消すること、失敗を受け入れること(そして学習すること)、評価すること、継続的に進化することです。
代表的なDevOpsソフトウェアメーカーであるPuppet社とSplunkによるレポートでは、DevOps実践の発展過程を5段階に分け、CAMSモデル(文化、自動化、評価、共有)に従って進捗を評価しています。また、このレポートでは、DevOpsの普及と成功に不可欠な5つの基本的なプラクティスを明らかにしています。
- 監視とアラートは、サービスを運用するチームが設定できる。
- アプリケーションやサービスを構築するための導入パターンを再利用する。
- アプリケーションやサービスを構築するためのテストパターンを再利用する。
- あるチームが提供するツールの改善に他のチームが貢献する。
DevOpsのKPI
主なKPIは以下のとおりです。
- 導入の頻度：小さな導入を頻繁に行うことが目標。
- 導入失敗の頻度：低減を目指す。
- 1四半期あたりのリリース機能数：四半期でなくてもかまいませんが、多くのビジネスリーダーは四半期単位で考えることが多いようです。
- 平均検出時間(MTTD)：異常が発生してから、それに気づくまでの時間。
- 平均復旧時間(MTTR)：異常が発生してから、それが解決されるまでの時間。
- 平均リードタイム(MLT)：あるコードを要求されてから、それが実装されるまでにかかる時間。
- 稼働時間：計画保守によるダウンタイムと予定外のダウンタイムを両方とも測定することで可用性を追跡。
- 不具合の見逃し率：実稼働環境に持ち込まれた不具合数と、QAチームが捕捉した不具合数を比較。
- アプリケーションパフォーマンス：アプリケーションのパフォーマンスを変更後と変更前で比較。
課題が明確になり、進捗の評価方法が決まったら、新たなDevOps文化の形成を始められます。はじめに開発者、テスター、運用チーム、セキュリティアナリストを隔てているサイロを解消します。ビジネスアナリストにも会議に参加してもらいましょう。全員に対して教育を行い、各自のやるべきことを明確にすることだけでなく、ソフトウェアの作成およびデリバリー全体のスピードと品質について責任を共有することを目指します。プロセスとインフラの変更に合わせて、連携を促進するような教育の機会を設けましょう。
そして、DevOpsは半年や1年で成し遂げられるものではないと覚悟することが重要です。DevOps支持者であるJez Humble氏の言葉を借りると、「DevOpsはゴールではなく、終わりのない継続的な改善のプロセスなのです」。
DevOpsは一時的な流行ではありません。選択肢の1つというレベルも超えつつあります。「ITをビジネスに整合させる」という考えは10年以上前から、経営者はもちろん、組織全体に認識されています。より優れたITをより速く提供する方法であるDevOpsの哲学とそれに関連する手法は十分に確立されました。Netflix、LinkedIn、Facebook、Amazon、Googleのような「ユニコーン」企業はDevOpsの文化を導入することで、めざましい成功を収めています。従来の企業においてもDevOpsは主流になりつつあります。
現在ではどの企業も、市場での即応性を高めようとしています。公共機関でさえもサービスを向上させようとします。顧客の期待が高まり、データが急増する中で、ITは現状のままでとどまることはできないのです。そんな中で、DevOpsは最も活発なトレンドとなっています。
