始めから終わりまで : DevOps の変革を成し遂げるには

DevOps 革命はグローバル経済で広がりをみせているデジタル化の重要な基盤です。DevOps はソフトウェア開発、展開、イテレーション処理を始めから終わりまで企業規模で改革することであり、より良いソフトウェアをより速く市場に送り出すことを目的としています。このホワイト ペーパーでは、現代の企業環境において「始めから終わりまで」が何を意味するかに答えることを目指しています。適切に計画、実装、および管理されたDevOps プロセスは顧客や企業の関係者にとって価値を創出する主要手段となるため、この概念は重要になります。さらにその答えは「どのようにそれを成し遂げるか?」という次の質問につながります。

企業は 1 つ 1 つ異なるため、どんな企業にも通用するような万能なソリューションはありません。「始めから終わりまで」という質問に対する一連の考え方を以下に提示し、これを企業全体での DevOps 戦略に関する重要な決定を下す際の初期の土台としたいと考えています。

これらのアプローチでは、「始めから終わりまで」をそれぞれ異なる意味で解釈しています。この表現は開始点と終着点を意味しています。異なる地点で開始することで、企業は技術だけではなく考え方を近代化することが可能です。

評価と戦略計画

まず、組織の成熟度、能力、および技術の点において自社がどの位置にあるかを評価することから始めます。そこからロードマップを作成できます。答えるべき質問は以下のとおりです。

# 01

適切な人材が揃っているか

いろいろな面で、これは IT だけではなく事業単位や組織全体に大きな影響を及ぼす文化改革です。DevOps ではチームや別部門間での協同作業とコミュニケーションが今まで以上に必要とされ、人のスキルがより重要になります。開発者は個々のプロジェクトで与えられた作業を 1 人でこなすのではなく、多様なチームの一員となってコミュニケーションを取りながら作業をスムーズに進めていく必要があります。チームは IT だけではなく組織の別部門の人員から構成されることもあります。DevOps チームの編成を考えている管理者は、処理スキル、ソフト スキル、職務スキル、および技術スキルを持つ候補者をバランスよく選定する必要があります。

この文化的転換の舵を取り、新しいやり方で生産的に運用していくには、IT スタッフ間で新しいスキルが必要になります。コーディングは常に重要ですが、この新しい環境ではアーキテクチャ スキルに重きが置かれます。モノリシック アプリケーションを最も効率的で生産的なサービスに構築し直すことは、その企業に固有の新しい学習分野となります。(たとえば、小売業と製造業ではやり方が異なることが考えられます。) マイクロサービス アーキテクチャ (MSA) 内で新しいアプリケーションを作成する際、構成要素は手動でコーディングするのではなく、大部分があらかじめ作成されています。大規模なアプリケーションのさまざまな必要コンポーネントを念頭に置き、これらのコンポーネント間でのデータの流れを思い描くことができるスキルが大変貴重になります。

# 02

プロセスをどのように変更する必要があるか

大部分ではないにしても、DevOps プロセスの多くは自動化されるため、組織とビジネス ニーズにとって最適な枠組みを構築することが重要です。初期段階では指標の確立と追跡を話し合う必要があります。計測すべきデータ項目として、以下が挙げられます。

  • 品質
  • 納入速度
  • 展開の頻度
  • リード タイムの変更
  • 成功率/失敗率の変更
  • パイプライン障害から復旧する際の平均時間
  • セキュリティ テストの合格率

上記の (または自社で選定した) 指標を経時的に追跡することで、パイプラインとアプリケーションの 2 つの進化に伴って発生する難所を特定できます。

考慮すべき点として、自動ビルドまたは自動展開のトリガーに関する規則を確立することが挙げられます。このトリガーは、いくつか実践を重ねることで変化していくことが考えられます。最終的な目標としては、あらゆるアプリケーション イテレーションを 1 回だけ作成することです。バージョン管理と追跡には、全体的なパイプラインのパフォーマンスを最適化することに加え、ビルドのトリガー要因に関する規則が必要です。

# 03

DevOps の実装にセキュリティをどのように組み込むか

高レベルで取り組みを開始する際、セキュリティ計画を含める必要があります。事前に行う計画戦略には、セキュリティ チームにも参加してもらうようにします。アプリケーションの内部プロセスを 1 つずつ切り離すことが可能なコンテナ化がセキュリティの構成要素になります。コンプライアンス テストと共に自動セキュリティ テストも優先させる必要があります。

すべてのプロトコルに準じているかをリリース前に人の手で確認できるよう、パイプラインにセキュリティ ゲートを組み込むことは賢明です。速度を落とさずセキュリティを最適化するために、こうしたセキュリティ制御を配置するには十分な計画が必要です。他の実装例から最も効率的な方法を学ぶことで、この 2 つをうまく両立させることができます。

環境とパイプライン

DevOps のプロセスは、MSA とコンテナ化によって定義された環境の上に構築することで最も効果を発揮します。この枠組みを構築する際に必要となる重要な技術は以下のとおりです。

コンテナ ツールは、実行する必要がある追加データおよびコンポーネント (OS カーネルなど) でマイクロサービスをパッケージ化します。このようなツールを使用する際に重要なポイントは、そのツールが環境全体にわたってコンテナを構築するプロセスを標準化するという点です。コンテナ ツールで群を抜いて人気を誇るのが Docker です。Docker はコンテナ内でアプリケーションを開発、展開、および実行するプロセスを自動化するオープン ソースのプロジェクトです。このツールはチーム全体に一貫した開発環境を提供するため、開発者たちから幅広い支持を集めています。

オーケストレーションは、個々のコンテナどうし、およびコンテナをその場で構築される最終的なアプリケーションに結び付ける管理層です。オーケストレーション層は、サービス品質保証 (SLA) の維持およびホスト上の最適な実行リソースへのサービスの組み入れを担当します。オーケストレーションは MSA モデルの “疎結合” 作用を実装しており、個々の構成要素が独立して動作することを許容しつつ必要な連携をすべて維持しています。Google のオープン ソース ツールである Kubernetes が最も広く採用されているオーケストレーション技術ですが、Docker Swarm もよく知られたツールです。

監視ツールを使用すると、マイクロサービスがどのように利用されているかを確認できます。モノリシック アプリケーション モデルの従来の監視ツールは、MSA やコンテナの疎結合、コミュニケーション、および複数コンポーネントといった性質を解するように作られていません。監視ツールはどこでエラーが発生したか、およびどのマイクロサービスが原因かを正確に示すことができます。Prometheus が監視ツールとして高い評価を得ています。

環境が新しい開始点を提示するとするなら、この見解での終着点は継続的インテグレーション/継続的デリバリー (CD/CD) パイプラインの構築になります。CI/CD 技術を組織のニーズに合わせるという点では、どんな組織にも通用するような万能なソリューションはありません。技術評価を開始するにあたって、候補となるツールの適性を計るための枠組みを確立するためにいくつかの質問に答える必要があります。

# 01

自社でカスタマイズをどの程度行いたいと考えているか、またはどの程度行うことができるか

これは重要なトレードオフとして考慮すべき点です。費用、実装のタイミング、および自社またはコンサルタントなどの他社 (追加費用がかかります) で必要なリソースなどを勘案して答えを出す必要があります。その結果、評価段階において特定のツールに傾いていくこともあります。

# 02

カスタマイズと関連して、目的の環境でどの程度の統合レベルを必要としているか

パイプライン環境全体でツールがどの程度簡単に統合できるか。この 2 つの質問は、ツールを実際に使用するときにどの程度手間を掛けるかという問題につながっていきます。最後に、より大きな構造上のニーズ (モノリシックから MSA への転換のどの位置にいるか)、採用しているワークフロー、およびスタッフのスキルにそのツールがどの程度うまく溶け込んでいくか、という質問にも答える必要があります。

# 03

CI/CD パイプラインをどこにホストするか

サービス プロバイダーが既に技術を提供していたり、特定のフローにより有効な環境を運用している場合があります。また、マルチ クラウド技術の普及に伴い、アプリケーションが依存しているデータがどこにホストされているかも重要です。新しいリンクの構築が必要になることも考えられ、少なくとも API 呼び出しをフローに組み込む必要が生じます。採用を検討しているツールはこうしたリンク作業を処理しつつ、必要なパフォーマンスを維持できますか?

# 04

どの程度の自動化を求めているか

CI/CD のカギは当然、可能な限り自動化することですが、ボタンひと押しで行う自動化にするか、パイプライン フローで確認と調整を行うかどうかは重要な問題です。

こうした問題の多くは、マネージド サービスおよびクラウド ホスティングに加えて、統合スイートを採用することで解消できます。統合の大部分はスイート間で既に行われていますが、これらのソフトウェアはオープン ソースがベースとなっているため、DevOps ツール エコシステムの中核であるその他の技術とより簡単にリンクできます。

たとえば、Atlassian 社は CI/CD パイプライン関連の技術を提供しています。Atlassian Bitbucket は Git と統合してコードのプルと発行を行います。Atlassian ツールは自社運用サーバーにインストールするか、またはクラウドにホストできます (クラウドでは Bitbucket は Bitbucket Pipelines と呼ばれます)。Atlassian Bamboo は新しいソフトウェアのビルド、テスト、およびデリバリーを行い、Bitbucket とも統合できます。また、機能を追加するためのサードパーティ製プラグインや特定のテスト スイートを利用できるオンライン マーケットプレイスにもアクセスできます。

オーケストレーション ツールとしては Jenkins が事実上の標準です。Jenkins は DevOps の開発側と運用側の双方のほとんどのツールセットと連携します。CloudBees 社は Jenkins のオープン ソース コミュニティの主要メンバーであり、CI/CD のデリバリーと展開の側面に特化した幅広いツール群を提供しています。Jenkins には、自動化機能およびパイプラインのどこにボトルネックがあるかを判断するための分析機能が備わっています。CloudBees Core はツール群を利用する複数のチームとアプリケーションの管理を支援します。

これらの統合スイートではすべて、マネージド クラウド ホスティングおよびマネージド サービスを利用できます。こうした技術の日々の管理をプロバイダーに任せたとしても、利用者側の制御の余地を減らすことにはなりません。単に、チームがライセンスの管理やクラウドの準備に煩わされることなく本来の仕事に注力できるというだけのことです。プロバイダーを選定する際、現在利用している技術に対する経験が豊富な提携会社と、ホスティングに選んだクラウド プロバイダーを探します。AWS、Microsoft Azure、Google Cloud などはすべて、異なる手法でプロビジョニングや共有セキュリティ プロトコルなどの作業を行っています。作業をすべて請け負ってくれるマネージド サービス会社を選択するようにします。

今日を開始点として未来を見据える

検討すべき最後の点ですが、おそらくこれが最も重要な点です。「始めから終わりまで」は、今日に始まり未来につながっていくことを意味すると解釈できます。となると、また別の質問が沸き上がります。自社のビジネスはどのように進化していくのか? 成長や吸収合併、新しいやり方に対応していくにはどのような選択肢があるか?もはやハードウェアやソフトウェアの管理にとどまらず、未来へのロードマップが必要になります。

顧客満足度、組織の効率性、および企業の価値創出構造を下支えする IT 運用を戦略的に計画するには、新しい考え方が必要であることを経営幹部に印象付けることが重要です。変化の速いグローバル経済では、自社の DevOps ニーズを絶えず評価し続けることになります。自社と似たような環境からの事例情報を集めつつ、DevOps 技術に関連するオープン ソース コミュニティでの開発状況にも継続的に気を配る必要があります。実務サポートにのみならず、社外の知識ややり方を授けてくれる信頼できるアドバイザーが、この新しい世界での IT チームの重要な一部になります。

結論 : 革命から旅路へ

DevOps は企業に新しいソフトウェア構築方法をもたらします。DevOps が成熟すると、顧客と関係者に価値を創出する手段となります。始めから終わりまで、技術はこうしたことをどのように行うべきかを明確にしてくれます。

しかしながら、戦略計画から技術の展開や管理のロードマップ作成に至るまで正しく行ったとしても、移り変わりの速い世の中で競争力の高いプレイヤーになるための道のりは厳しいものです。終着点のない旅を進んでいくには信頼できるアドバイザーが必要です。その旅の計画の 1 つは、誰と旅を共にしたいかを決定することです。

ゴーツーグループにご相談を

ゴーツーグループは、製品ライセンス購入、導入支援、運用支援、ユーザー研修など、貴社がアトラシアン製品を活用して業務の効率化を図るお手伝いをします。

お問い合わせ