リリース時のリスクの最小化

NTTデータ先端技術では以前、システム開発に問題を抱えていた。具体的には、アプリケーション開発部隊とインフラ開発部隊で意思の疎通ができないことがあり、システムを開発するうえで「どのように作るのか」、「誰がどこまで作るのか」といった課題に悩まされることがあった。インフラ開発部隊とは、カットオーバー後に運用を担当する役割も担う。

また、以前に導入していたウォーターフォール開発では、1回のリリースでアプリケーションをインフラ環境に移行することに大きなリスクを抱えることも課題だった。

そこで同社はアジャイル開発プロセスのスクラムを導入し、各人の役割分担を明確にしたうえで、1日の中で細かいリリースを繰り返すことにした。1回のリリース時のリスクを低減する措置をとったのである(図1)。

図1 : リスク低減の措置

このアジャイルな開発プロセスを運用にまで適用することで開発と運用を一体化させ、リリース時のリスクを減らす開発手法こそが同社の目指すDevOpsである。

NTTデータ先端技術は、2013年の初めからDevOpsに取り組んでいる。その中心となっているのは、落田征士氏(ソリューション事業部クラウド基盤ビジネスユニット長)と志田隆弘氏(ソリューション事業部クラウド基盤ビジネスユニットクラウドグループシニアエキスパート)である。

NTTデータ先端技術 ソリューション事業部 クラウド基盤ビジネスユニット長 落田征士氏(右)と、同クラウドグループシニアエキスパート 志田隆弘氏(左)

DevOpsを実現するための開発側の課題として、「アジャイルに開発したアプリケーションをどうやってアジャイルに運用チーム(主にインフラ開発部隊)に引き渡すかにあります」と落田氏は語る。この課題が近年のクラウドによるインフラ自動化によって解決できるようになった。

また同氏は、DevOpsにおける重要な3つの自動化として、(1)インフラ構築の自動化、(2)ソフトウェアのデプロイの自動化、(3)ソフトウェア開発プロセスの自動化を挙げる。

インフラ構築の自動化は、IaaS(Infrastructure as a Service)などによって実現できる。またデプロイの自動化は、JenkinsやCloudifyなどのツールによって実現できる。さらに開発プロセスの自動化は、アジャイル開発で用いる各種のツールによって実現できる。つまり課題となる3つの自動化については、すでに解決策となるツールが存在しているのだ。これらを活用し、DevOpsを実現しようとするのが同社の取り組みである。

「これまでもテスト環境までは自動化できていました。そこにクラウドが登場したことで本番環境の構築までを自動化できるようになったのが、DevOpsが注目されるひとつの要因だと思います」(志田氏)

ツールをどう組み合わせるか

DevOpsを実現するには、開発から運用までの各フェーズで自動化のノウハウが欠かせない。NTTデータ先端技術の強みは、どのフェーズにおいても自動化の技術とノウハウを持っている点にある(図2)。ただしデプロイに関しては、現在でも試行錯誤を繰り返しているという。

図2 : 運用を含めた自動化ツール

同社は現在、アプリケーションのデプロイにCloudifyというツールを活用している。採用した理由はGUIが優れており、使いやすい点である。ただしこのツールの採用が本当に正しいのか、今でも議論があるという。

「デプロイに関しては、世間一般に『これがよい』というデファクトスタンダードがありません。その部分にまだ課題が残っていると思います」(落田氏)

また落田氏は、DevOpsに関する課題に対してどのように取り組んでいるか、同社が考慮している点を次のように語る。

「私たちは、個別のアプリケーション開発部隊とは別に、各開発部隊を俯瞰する立場にいます。自動化に対するナレッジを蓄積し、展開する体制を敷いているのです。こうしたチーム間でのフィードバックループを繰り返すことにより、まずは当社なりのDevOpsのやり方を確立したいと思います」(落田氏)

同社は、クラウド黎明期である2008年の時点からクラウド構築ソフトでのビジネスを進めてきた。DevOpsを推し進めるにあたり、インフラ自体に機能を拡張するための技術やノウハウを持っている点は大きな強みになっている。

かつて同社で行っていたウォーターフォール型の開発では、先にインフラ開発部隊がハードウェア部分の設計を実施し、その後、アプリケーション開発部隊がアプリケーションを開発し、さらにその後、インフラ開発部隊とアプリケーション開発部隊が協力して運転試験用の環境を整備して試験するといった流れになっていた。アジャイル開発が浸透してもなお、適用される範囲はアプリケーション開発に留まるのみで、システム構成などは設計した後に開発を始めるというスタイルだった。

そこにDevOpsの考え方を適用することにより、またクラウドの技術を適用することにより、インフラ開発部隊とアプリケーション開発部隊の作業を並行して実施することを実現しようとしている。インフラに対する設計変更も、近年のクラウド技術の浸透によって時間と手間を掛けずに実施できるようになっている。そのためアプリケーションの観点からインフラ側へ改善を提案する、インフラの観点からアプリケーションへ改善を提案するといった連携が実現できる。

「DevOpsを実現するための土壌は整っています」と志田氏は言う。同社の今後の目標は、すべての開発案件をDevOpsでやることだ。

繰り返すが、同社ではインフラの構築までを含めたアジャイル開発の適用がDevOpsと考えている。開発側は通常の開発と同じようアプリケーションを開発し、そのアプリケーションの試験を実施する。この時、試験をするための環境は自動化ツールによって開発者の望むどおりのタイミングと構成で準備される。運用チーム側もまた、自動化ツールによって望むどおりの構成でインフラを含めたアプリケーション全体が準備される。これにより、わざわざアプリケーション側でのリリースを待つことなくシステムを試験することができる。

また自動化ツールによってシステム再構築のためのコストが限りなくゼロに近いものになる。そのためシステム運転試験などの環境に大きく依存する試験も、反復型プロセスに取り入れることが可能になる。

「私たちのミッションは、新しい技術やパラダイムを用いてブレイクスルーを図ることです。DevOpsは新しいパラダイムですが、あくまでも手法です。DevOps自体がビジネスになるとは考えていません。ただ、私たちはクラウド基盤を構築するサービスを提供しており、DevOpsはそのサービスの幅を広げるものになると考えています」(落田氏)

日本のSIerの間でもDevOpsを推進する機運が高まっている。また現状でもツールはすでに出揃っている。問題はそれらをどう組み合わせて使うかという点である。これをクリアできればDevOpsは一気に加速するのかもしれない。