DevOpsを通じてITを企業の武器にするために重視すべき3つのポイント：単なる自動化で終わらせない、DevOpsのすすめ

デジタルトランスフォーメーションが進む中で、DevOpsの重要性はさらに高まっているが、その導入にまで踏み切れていない企業は多い。開発部門と運用部門の認識のズレだけでなく、そもそもDevOpsで何を達成するのかという基本的な部分から焦点がブレやすく、結果として単なる自動化と違いが分からないというケースも散見される。自動化とDevOpsは密接な関係にあるが、自動化がDevOpsのゴールではなかったはずだ。では、DevOpsの本質とは何か。自動化の他に何を重視するべきなのか。システムインフラのみならずDevOpsの導入を支援する取り組みを提供するレッドハットに話を聞いた。

[PR／＠IT]

PR

開発現場と経営層の間でDevOpsに対する認識のズレがある

　近年、ITとビジネスの関係性は非常に密接なものになりつつあり、IT次第でビジネスの成功が左右されるケースも出てきている。もともと裏方の存在であったITがビジネスとの距離を縮め始めたのは、Google、Amazon、Facebook、楽天などのWebサービスが立ち上がってきた2000年頃。既存ビジネスのWeb化が進み、ITがビジネスに欠かせないインフラへと変化していく。2006年頃からは、Web上で展開されるビジネスが拡大・多様化するとともに、UberやAirbnb、ExpediaといったWebならではの新たなビジネスも誕生。現在では、IoTの進展に伴い、ITがビジネス価値に直結する領域はさらに広がっている。

　こうして、ビジネスにおけるITの重要度が高まるのに従って、企業にとって大きな課題となってくるのが、ITサービスをいかにスピーディにリリースできるかという点だ。また、リリースするだけでなく、ユーザーからのフィードバックを基に、ITサービスを継続して改善し、そのビジネス価値を高めていくことも求められる。

レッドハット サービス事業統括本部 DevOpsリード シニアアーキテクト 山田義和氏

　「例えば、スタートアップ企業から生まれる新しいビジネスアイデアの成功確率は、4％程度といわれている。つまり、アイデア（試行錯誤）の数が重要な成功要因であり、そのために、ITサービスの構築・リリースから、効果の計測、学習、改善までのフィードバックループを高速に回すことがカギになる。1カ月間で1回しかループを回せない企業と4回できる企業では、成功確率が大きく変わってくる。また、競合企業から新たなITサービスがリリースされた際、これに素早く対応するような場合も、フィードバックループを高速に回せる体制が重要になる。そして、こうしたITビジネスのフィードバックループを高速化するために、DevOpsへの取り組みが必要不可欠になってくる」と指摘するのは、レッドハット サービス事業統括本部 DevOpsリード シニアアーキテクトの山田義和氏。

　一般的にDevOpsは、開発担当者と運用担当者が連携してITサービスをアジャイルで開発、リリースしていく手法とされているが、山田氏は、「開発担当者と運用担当者が連携するだけではなく、経営層も巻き込んで、Biz、Dev、Opsが一体となってITサービスのデザインから開発、テスト、運用、計測や分析、改善までのプロセスをアジャイルで回していくのがDevOpsの本質であると考えている。つまりDevOpsは、単なる開発手法ではなく、ビジネスの価値や競争力の向上や成長を目的とした、ITサービスのリードタイム短縮および継続的改善のためのIT運営プラクティスといえる」との考えを示す。

　「現在は、Webサービス系の企業を中心に、DevOpsへの取り組みが進んでいるが、今後、IoT時代が本格化すれば、業種を問わずあらゆる企業がDevOpsを実践する必要性に迫られる可能性がある」と、デジタルトランスフォーメーションが進む中で、DevOpsの重要性はさらに高まってくると予測する。

　しかし、いざDevOpsを実践しようとした際、多くの企業では、旧来の企業文化や既存の開発プロセスが障壁となり、DevOpsの導入にまで踏み切れていないのが実状だ。トップダウンアプローチにしても、特に「DevOpsの本質的な目的であるビジネス価値や競争力の向上をどのように実現するのか」を経営層へうまく説明できずドラスティックに切り込めない。結果として単なる自動化で終わってしまうこともあるという。

DevOpsを進める上で重視すべき3つのポイント

　では、こうした経営層の意識を変革し、DevOpsを進めるためにはどうしたらよいのか。山田氏は、そのための重点ポイントとして、「DevOpsのメトリクスを明確に定義すること」「CI／CD（継続的インテグレーション／継続的デリバリー）パイプラインを構築すること」「クラウドとコンテナ技術を活用すること」の3つを挙げる。

DevOpsのメトリクスを明確に定義すること

　まず、1つ目の「DevOpsのメトリクスを明確に定義すること」では、DevOpsの導入を検討する際に、経営層に対してDevOpsのメリットを漠然と伝えるのではなく、システムメトリクス、プロセスメトリクス、ソフトウェアメトリクス、ビジネスメトリクスの4つを定義した上で、DevOpsのロードマップを示すことが重要だという。

　「システムメトリクスは、CPUやメモリの使用率や可用性など、システムに関する評価指標。プロセスメトリクスは、開発サイクルや生産性を評価する指標。ソフトウェアメトリクスは、ソフトウェアの仕様や品質に関する評価指標。ビジネスメトリクスは、リリースする機能のビジネスへの貢献度を評価する指標。これらのメトリクスをベースに、DevOpsのロードマップを見える化することで、Biz、Dev、Opsが協調してサービス開発を行う文化が醸成され、経営層を含めた組織全体の意識改革につながっていく」と山田氏は説明する。

CI／CDパイプラインを構築すること

　2つ目の「CI／CDパイプラインを構築すること」については、DevOpsを効果的に実践するために、CI／CDのパイプラインを構築し、アジャイル開発で繰り返し行われる実装、ビルド、テスト、リリースの手順を自動化する必要があるという。これによって、ビルドやテスト、リリースにおける保守性・生産性を高め、DevOpsに求められる“継続的変更の効率化”と“変更スピードの向上”を実現することが可能となるのである。

　「一方で、DevOpsのプロセス全体を自動化するに当たっては、幾つかの技術的課題に直面することになる。特に、生産性や保守性、パフォーマンス、可用性、拡張性といった非機能要件を担保するインフラレイヤーの自動化は、技術面での高いハードルになっている」と山田氏は指摘する。

図1　自動化とインフラレイヤーの特性

　インフラレイヤーを自動化することで、例えば、サーバのCPU使用率がしきい値を超えたら自動でスケールしたり、サーバがダウンしたら自動で新しいサーバを立ち上げてロードバランスを行ったりといった処理が可能となる。しかし、これらを実現するためには、インフラ構築の自動化、非機能要件のコード化、インフラに依存するテストの自動化、インフラの構成管理の効率化という技術的課題をクリアする必要があるという。

クラウドとコンテナ技術を活用すること

　そして、この課題を解決するための重点ポイントとなるのが「クラウドとコンテナ技術を活用すること」である。「クラウドとコンテナ技術を活用することで、インフラ構築や非機能要件をコード化し、インフラ構築やテストの自動化、構成管理までを容易に行えるようになる。レッドハットでは、これに対して、IaaS（Infrastructure as a Service）の『Red Hat OpenStack Platform』（以下、OpenStack）と、CaaS（Container as a Service）プラットフォームの『Red Hat OpenShift Container Platform』（以下、OpenShift）を提供し、DevOpsに向けたインフラレイヤーの自動化を支援している」と山田氏は力を込める。

　「OpenStack」「OpenShift」によって実現されるDevOpsインフラの構成例としては、複数のサーバとスイッチによる物理環境上に「OpenStack」で仮想マシンを立ち上げ、仮想ネットワークで接続。そして、この仮想マシン上に「OpenShift」でコンテナを展開する。仮想マシンを含むインフラとコンテナには、それぞれ制御APIが提供され、インフラ構築や非機能要件をコード化できるとともに、インフラ周りのあらゆる情報やメトリクスを収集し、統合的な構成管理を実現する。

図2　DevOpsなインフラ

　また、「OpenShift」のコンテナ技術に着目すると、構成管理ツール上のリポジトリに、ソースコードとインフラ・コンテナコードを集約し、そこから必要なシステム構成のコードをコンテナイメージとしてパッケージングしてビルド。このコンテナイメージを開発環境からコンテナリポジトリに展開し、本番環境にリリースする仕組みとなっている。

　さらに「OpenShift」では、コンテナオーケストレーション機能を備えている点も見逃せない。通常、コンテナでは、複数のホスト上で動いているコンテナを連結させるのは煩わしい作業が必要になるが、コンテナオーケストレーション機能を利用することで、複数ホストをクラスターとして扱えるという。この他、非機能要件に対応するオートスケールやセルフヒーリングの機能も備えている。

質の高いテストを行うことも欠かせない

　ここまで、DevOpsの実践に向けて取り組むべき3つの重点ポイントを紹介してきたが、「この3つのポイントを押さえた上で、DevOpsを成功に導くためには、質の高いテストを行うことも欠かせない」と、山田氏はテストの重要性を訴える。

　「バグが発見できないテストを何回やっても意味がない。生産的なテストを行うためには、テストを分類し、それぞれにテスト戦略を設定するとともに、レビュープロセスをしっかり定義することが重要だ。テスト品質が高まることで、ITサービス開発におけるBiz、Dev、Opsの信頼関係が深まり、テスト後の余計な承認プロセスをなくすことにもつながる」（山田氏）

　さらに「OpenStack」「OpenShift」を活用したDevOpsインフラであれば、今まで難しかった非機能要件関連のテストも容易に行えるという。例えば、可用性のテストをする際は、コンテナを複数台立ち上げておき、制御APIによってネットワークを切断することで、新しいコンテナが立ち上がるかどうかを自動テストすることが可能だ。また、テストを並列化して行えるため、テストにかかるリードタイムも大幅に短縮できる。

　「質の高いテストを短時間で行えれば、経営層がテストに対して前向きになってくる。このことは、継続的変更を行うDevOps文化を根付かせていくためにも重要なポイントだと考えている」（山田氏）

DevOps時代に求められるエンジニア像

　なおレッドハットでは、DevOpsの導入ニーズに対して、「OpenStack」「OpenShift」を活用したシステムインフラをソリューションとして提案するだけではなく、DevOpsの堅実なスタートと実践を支援する取り組みとして「DevOps Discovery Session」を実施している。このセッションでは、DevOpsの目的や背景、主要成功要因、技術要素の解説を通じて、DevOpsへの理解度向上を図るとともに、現状分析を行い、成熟度判定から実践レポートを提供するという。DevOpsの導入を検討しながら、一歩が踏み出せない企業の担当者は、このセッションに参加してみてはいかがだろうか。

　また「OpenStack」「OpenShift」に関して、レッドハットはパートナープログラムを提供している。最新情報の提供、技術支援、エンジニアなどの育成が含まれており、システムインテグレーターはこのプログラムを活用することで、DevOpsなど新しいビジネスの立ち上がりを加速させるのも1つの方法である。

図3　DevOpsの実践モデル

　最後に山田氏は、DevOps時代に求められるエンジニア像について、次のような見解を述べた。「これからDevOpsが本格的に浸透してくると、チーム開発の重要度がさらに高まり、今まで以上にコミュニケーション力が求められてくるだろう。議論の場では、メトリクスを基にディスカッションできる能力が必要になってくる。また、自分の先入観に縛られないクリエイティブな発想で開発していく姿勢も重要だ。そして、あくまでもビジネスを実現するためのシステム開発であることを意識して、広い視野を持つエンジニアを目指してほしい。エンジニアが活躍する場はますます広がっている。ビジネスを意識することで、 むしろ仕事が面白くなるはずだ」