NTTデータに、統合開発クラウド基盤でPuppetを採用した理由と注意点を聞いた：今、なぜPuppet Enterpriseを採用するのか

NTTデータは、全社のシステム開発環境をクラウド上に集約する「統合開発クラウド」を構築している。この開発クラウドでは、インフラ自動化のためのツールとして「Puppet Enterprise」を採用している。その理由と、自動化における注意点を、NTTデータの菅原亮氏に聞いた

[PR／＠IT]

PR

　NTTデータは、全社のシステム開発環境をクラウド上に集約し、システム開発の生産技術向上を目指す「統合開発クラウド」の運用を、2017年4月を目途に開始すると、2017年1月25日に発表した（ニュースリリース）。この開発クラウドでは、これまで2〜3カ月要していたシステム基盤の構築を、自動化の推進によって1日以内に短縮する。インフラ自動化のためのツールとして「Puppet Enterprise」を採用している。

NTTデータ システム技術本部 方式技術部 第三統括部 統合開発クラウド担当 課長代理の菅原亮氏

　今回の開発クラウドにおけるインフラ自動化部分の開発リーダーを務めるシステム技術本部 方式技術部 第三統括部 統合開発クラウド担当 課長代理の菅原亮氏は、Puppetによる自動化を、全社、全プロジェクトに広めることを目指していると話す。

　「最初はできる範囲から始め、使えるアプリケーションやバリエーションを増やしていきたいと考えています」

　日本最大級のシステムインテグレーターとして知られるNTTデータでは、常時、多数のソフトウェア開発プロジェクトが進行している。だが、日本におけるほとんどの組織と同様、開発環境は、各プロジェクトがそれぞれ構築し、維持・運用してきた。インフラチームを内部に持つプロジェクトでは、こうしたチームが担当。持たない場合は、菅原氏の所属するシステム事業本部や社外の業者に依頼している。

　全社的に見ると、あちらこちらで重複する調達および作業が繰り返されてきており、NTTデータのように多数の開発プロジェクトを走らせている組織では、潜在的に大きなコスト無駄が生じている。

　また、冒頭に述べた通り開発環境の構築に時間がかかる他、開発チームが「インフラのパラメータを1つ変えたい」と思っただけでも、インフラチームの作業申請を出し、承認を受けるなどのプロセスで1週間かかってしまうといった課題があった。最近のソフトウェア開発では、トライアル＆エラーや「継続的インテグレーション（Continuous Integration：CI）」と呼ばれる考え方が主流になろうとしている。だが、インフラ関連プロセスで大きな時間や手間がかかっている状況を変えられないままでは、開発における新たな取り組みを阻害する要因になりかねない。

NTTデータの統合開発クラウドでは、なぜPuppet Enterpriseを選んだのか

　菅原氏たちは、構成自動化ツールの適用範囲を、当面は仮想化環境上の仮想マシンにおけるOSやミドルウェアの設定とし、各開発プロジェクトのインフラチーム、そしてゆくゆくはソフトウェアエンジニア自らが、インフラの構成を行える環境を整備していこうとしている。

　構成自動化ツールとしてNTTデータが選択したのはPuppet Enterpriseだ。選定理由について菅原氏は、次のように説明している。

インフラ担当者にとっての扱いやすさ

　「Puppetが当社に最も適していると考える点は、インフラの設定を記述するドメイン固有言語（DSL）が、設定ファイルを基にしているため、非常に分かりやすいということにあります」

　構成自動化ツールの中には、プログラミング言語を使って記述するものがある。これは柔軟性が非常に高く、プログラマーにとっては親しみやすいという利点がある。だが、NTTデータのようにインフラ／基盤担当とアプリケーション開発担当の役割が明確に分かれている組織では、これが利点とならない。

　自動化ツールを扱うのは基本的にはインフラ担当者であり、こうした人々にプログラミング言語を習得しろと押し付けるのは無理がある。だが、Puppetの場合、設定ファイルの延長線上にあるため、受け入れやすい。

　「シェルスクリプトを書ける人なら、数日でPuppetを使えるようになります。プログラミング言語だとそうはいきません。インフラ担当者にとっては、従来の手順書を多少特殊な記述方法にしたものという言い方もできます。Puppet社は『エンタープライズに注力している』と言っていますが、ツールの根本的な考え方が、弊社のような大規模組織に適していると思います」

セキュリティ面で安心できる

　とはいえ、さらに読みやすい言葉を使っているというツールも存在する。だが、例えばSSHで直接管理対象にアクセスするような手法では、セキュリティ的な懸念が出てくる。

　Puppetではやり取りするデータを暗号化した上で、httpsにより通信経路についても暗号化している。バンク・オブ・アメリカのような大手金融機関や政府機関が採用していることを考えても、安心できると菅原氏はいう。

あるべき姿を記述するスタイルによる分かりやすさ

　構成自動化ツール間で違いが出るもう1つのポイントとして、「プロセスを書く」のか、「最終形を書く」のか、がある。Puppetは後者に属する。プロセスを書くタイプのツールは、アドホックで構成自動化を行うには楽だが、維持・運用を考えると逆に面倒になる側面があると、菅原氏は指摘する。

　「多数のノードを構築するケースが最近増えています。例えば1000台に対して『このシナリオに沿って実行しろ』というのと、『このシナリオの状態にしろ』というのでは、大きな違いが出てきます。分かっている人にはプロセスをたどれる記述方法が好まれるでしょう。しかし、知らない人にとっては暗号のように見えてしまいます。こうした意味で、Puppetは可読性が高いと思います」

品質を担保しやすい

　Puppetのデメリットとして、自由度が低いと指摘されることがある。しかし菅原氏は、「弊社のように大規模だと、制約の多い方が楽だといえます。プログラミング言語を使うツールでは、極端にいえば星の数ほど書き方が出てきてしまいます。一般的なプログラムでは、プログラマーのスキルで品質が左右されますが、これと同じことが構成自動化でも起こりがちです。一方、Puppetの場合は、制約が多い一方で、誰が書いてもある程度同じものになり、そのことで品質が担保しやすくなります」と話している。

構成自動化の社内推進における注意点とは

　では、Puppetのような構成自動化ツールを社内で推進していく際に、気を付けるべき点とは何か。これを尋ねると、菅原氏は「夢を見ないこと」だと断言した。

　「構成自動化ツールでは、ストレージやネットワークの設定を含め、多様な自動化ができます。そこで、『全てを自動化してしまえばいいのではないか』という誘惑にかられます。これが最大の罠です」

　自動化によるメリットは、プロジェクトや会社によって千差万別であり、いくらモデルケースが存在していても、個々のプロジェクトや組織で役立つとは限らないという。

　「何でもかんでも自動化しておけば後で使うかもしれない」と考えて、PuppetでいえばManifestを多数開発したとしても、膨大な工数にかかわらずほとんど使われなかったという例はたくさんあります」

　では、どうしたらいいのか。

　「自分はどこを自動化したいのか、どの機能を使い、何を変えていく可能性があるのかを的確に見極め、範囲を絞ることです。基盤関連の日常的な作業で、明確に『この部分が大変だ』というものがあれば、それは自動化の候補になります。こうした作業の自動化を少しずつ試し、自社あるいは自らのプロジェクトに適した使い方を、自分たちで探る必要があります。何らかの作業を構成自動化ツールで自動化したとしても、それを使いやすいと感じるかどうかは人によります。万人に受けるものはありません。Puppetのようなツール以外にも、例えば仮想化基盤にはこのための自動化ツールが存在します。どのツールを使うと一番効果があるのかを、冷静に見極めることが重要だと思います」（菅原氏）

「インフラの継続的インテグレーション」を目指す

　NTTデータの統合開発基盤で、Puppetを直接使うことになるのは誰か。当初は開発プロジェクトに属する基盤チームの人々たちだ。だが、その後は、基盤チームを持たないプロジェクトの人たちが自分たちで使えるように、Webインタフェースなどを整備していくという。

　全社標準的な基盤構成については、Manifestをシステム技術本部で用意する。一方、プロジェクト側でManifestを作り、自らのプロジェクトで展開できるようにしていく。プロジェクト側でManifestを作るのは、当初はインフラエンジニアの人々だ。この人たちは、従来手作業でやっていたことを自動化できるようになり、アプリケーションエンジニアに対して、より迅速な対応ができるようになる。

　その次には、アプリケーションエンジニアが直接Manifestを書くような世界が見えてくる。今までこれらの人々は、インフラ環境の構築や変更ができなかった。ちょっとしたことでも、基盤チームやシステム技術本部などに頼まなければならなかった。今後は基盤に関する知識が豊富でなくとも、自らがタイムラグなしに、インフラのパラメータを自動設定するなどができる。

　「これまで基盤分野は、ドキュメントや手順書でしか管理できませんでした。ところがPuppetのようなツールでは『Infrastructure as Code』という言葉があるように、インフラがコードとして表現でき、アプリケーションのソースコード管理と同様な、バージョン管理が実行できるようになります」

　「私たちが目指しているのはインフラにおける継続的インテグレーションです。先進的な企業では、基盤とアプリの境はなくなりつつあります。NTTデータは大規模な、エンタープライズ系企業ではありますが、こうした企業でも、DevとOpsの壁を低くしていくことはできると考えていますし、その先には素晴らしい未来が開けると信じています。そういった最終形を思い浮かべながら、統合開発クラウドの構築を進めていこうとしています」