siプロジェクトでのインフラ自動化の事例（第1回 puppetユーザ会...

Copyright © 2015 NTT DATA Corporation

第1回 Puppetユーザ会

発表資料

2015年10月28日株式会社ＮＴＴデータ落合秀俊

SIプロジェクトでのインフラ自動化の事例

2 Copyright © 2015 NTT DATA Corporation

はじめに自己紹介

名前: 落合秀俊

所属: 株式会社NTTデータ

技術革新統括本部基盤システム事業本部

経歴:

• 社内のSIプロジェクトに対して、オープンソースミドルウェアの技術支援を実施

• 2009年以降は、HadoopのSI案件を複数担当

Hadoopの大量(数百台～数千台)のスレーブサーバ構築で Puppetを活用、Puppetのノウハウを蓄積してきた


はじめに今回伝えたいこと

インフラの自動化に関して、 • 世の中ではWeb系企業での事例は多いが、 • エンタープライズ領域ではほとんどない。

大規模プロジェクトでのインフラ自動化事例を紹介 1. なぜ自動化を行うのか、インフラの課題と解決策 2. SIプロジェクトでのPuppet活用方法

インフラ自動化に取り組む人を増やしていきたい

今後目指す方向 • 品質/柔軟性の高いITインフラを日本のSIプロジェクトに広めることで、 • 3K,7Kと言われるIT業界の苦労を少しでも軽減し、 • より創造的な仕事に注力できるようにしたい

Copyright © 2015 NTT DATA Corporation 4

１．なぜインフラの自動化を行うのかインフラの課題と解決策


Puppetを活用した「事例プロジェクト」の概要と、インフラの抱える課題

システムの特徴解決策

①社会基盤を担う重要な大規模システム

②当社にとって新規顧客、新規システム

③お客様所有データセンタに設置

①大量/多種/複数面のサーバ

• 効率的かつ不整合なく構築

• 不整合なく変更を反映する必要がある

②変更要求に対して柔軟かつ正確な対応が求められる

③お客様データセンタでは短期間で確実な構築/試験が求められる

インフラの課題効果


システムの特徴①社会基盤を担う重要な大規模システム

商用環境 80台

DR環境 80台

サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP

開発環境 (お客様所有)

190台サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC

… AP AP DB バッチ

サブシス内結合面

サブシス間結合面

サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


総合テスト面 …

外部システム結合面

現行システム維持面

非機能テスト面

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

開発環境 (自社内)

80台

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

…

単体テスト(新規)面

単体テスト(現行)面

30種類

16面

サーバのバリエーションが多く、種類ごとに内部構成が異なる

400台超

商用環境は80台だが、トータルだと5倍以上に膨れ上がる

プロジェクト最大の山場であるテスト工程で試験の並走度が高く、開発環境に多数のテスト面がある。


インフラの課題①大量/多種/複数面のサーバ構築時の課題

商用環境 80台

DR環境 80台

サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP



AP DB バッチ

サブシステムB

DB

サブシステムC




サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC






サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…


80台

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

…



30種類

16面

400台超

大量のサーバを効率的に構築する必要あり

不整合なく構築する必要あり • 同種のサーバ同士 • 面、面、面…の間


インフラの課題①大量/多種/複数面のサーバ変更作業時の課題

商用環境 80台

DR環境 80台

サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP



AP DB バッチ

サブシステムB

DB

サブシステムC




サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP

AP AP AP AP AP AP

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC






サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC

… AP DB バッチ

AP

…


80台

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

…



30種類

16面

400台超

AP

AP AP

AP AP

AP AP

1台の変更 ↓

変更対象が16面(20台以上)に膨れ上がる


インフラの課題①大量/多種/複数面のサーバ変更作業時の課題

商用環境 80台

DR環境 80台

サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP



AP DB バッチ

サブシステムB

DB

サブシステムC




サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP

AP AP AP AP AP AP AP AP

AP AP

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC






サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC

… AP DB バッチ

AP

…


80台

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

…



30種類

16面

400台超

AP

AP AP

AP AP

AP AP

AP AP

AP AP

AP AP

1台の変更 ↓

類似サーバへ展開すると変更対象がさらに

2倍(40台)、 3倍(60台)、

：

不整合なく変更を行う必要あり


インフラ課題の解決策①大量/多種/複数面のサーバ

大量のサーバを効率的に構築する必要あり

不整合なく構築する必要あり • 同種のサーバ同士 • 面、面、面…の間

不整合なく変更を行う必要あり

Puppetで構築、維持管理を実施 • OS設定 • ミドルウエアの構築

ミドルウェア試験の自動化 (今回の発表では詳細は割愛)

• サーバ単体テスト: serverspec • 振る舞いテスト: 内部独自ツール

課題

対策

効果

品質向上: 作業ミス等でのサーバごとの差異が発生がない

学習効果、知識の蓄積: 初期の面の経験をフィードバックできるため、後の面になるほど失敗が少なく、精度が上がる。

スケジュール確度向上: 後の面になるほどトラブルが減るため、スケジュール通りに進む確度が高まる。結果、スケジュール圧縮も可能になる。



商用環境 80台

DR環境 80台

サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP



AP DB バッチ

サブシステムB

DB

サブシステムC




サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP

AP AP AP AP AP AP AP AP

AP AP

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC






サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC

… AP DB バッチ

AP

…


80台

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

…



30種類

16面

400台超

AP

AP AP

AP AP

AP AP

AP AP

AP AP

AP AP

Puppet Manifest

Puppetで変更を一元管理




構築回数

環境/面 Puppetでの構築期間

構成

1回目開発環境/ サブシス内結合面

4週間/面

2回目開発環境/ 非機能テスト面非機能テストDR面

3週間/2面 =1.5週間/面

3回目開発環境/ サブシス間結合面開発環境/ 外部システム結合面

2週間/2面=1週間/面

：：

5回目商用環境 DR環境

4週間/2面 =2週間/面

サブシステムA AP DB

バッチ

サブシステムB DB

サブシステムC



バッチ


サブシステムC


サブシステムA AP

DB

バッチ

AP

DB

バッチ

サブシステムB

DB DB

サブシステムC AP

DB

バッチ

AP

DB

バッチ … AP AP


バッチ


サブシステムC



DB

バッチ

AP

DB

バッチ

サブシステムB

DB DB


DB

バッチ

AP

DB

バッチ … AP AP


DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB


DB

バッチ

AP

DB

バッチ … AP

AP AP AP


DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB


DB

バッチ

AP

DB

バッチ … AP

AP AP AP

×新規なので準備(モジュール作成等)に時間が掛かった

△冗長構成(HA,負荷分散)が初登場で難易度が高くなった

○1回目と同じ構成なので、ほぼノートラブル、4倍効率化

○商用ながら、2回目から台数が増えたのみ当日の作業延長なし、期間内に終了


シンプル構成

冗長構成

シンプル構成

冗長構成



公式な環境

うちは小規模だから自動化してもしょうがない？？

ところで、

「うちは小規模だから自動化してもしょうがない」

とお思いのあなた、

ちゃんと数えると思っている以上にサーバ数、面数はありますよ！

業務Aチーム内サーバベンダ検証センタ検証環境

商用環境

野良サーバ系一時的環境

Aさん席足元のサーバ(PC)

業務Bチーム内サーバ

開発環境(単体テスト)

開発環境(結合テスト)

ベンダ検証センター

パッケージソフト検証環境

環境によって再現しないバグが出ることも

統制かけて公式環境化するのはどうか？

検証期間は短いので、素早く作りたい


システムの特徴②当社にとって新規顧客、新規システム











Puppetで構築、維持管理を実施

ミドルウェア試験の自動化

品質向上

学習効果、知識の蓄積

スケジュール確度向上


システムの特徴②当社にとって新規顧客、新規システム

新規顧客

開発に入った後に初めてわかることも多い

新規システム

当然、要件定義は厳格に行うのだが……

お客様の独自文化 • 独自用語(各種識別子が変更になる) • 明文化されていない暗黙のルール

(後から知っても、守る必要がある) • 全システム共通の運用システム

(監視、ジョブ、ログ等へ合わせこむ) 等

連携先システムの詳細仕様

詳細設計を進めて気づく仕様 • 例外的な処理 • 異常時の処理 • DR切り替え時の処理等

インフラ構築後の変更が避けがたい変更要求に対して柔軟かつ正確な対応が求められる


Puppetで維持管理を実施 • OS設定 • ミドルウエアの設定

課題

対策

効果

インフラ課題の解決策②変更要求に対して柔軟かつ正確な対応

インフラの変更要求に対して柔軟かつ正確な対応が求められる


変更のトラッキング: 変更は、テキストファイルとしてリビジョン管理ができる

変更の敷居を下げる: 次ページで解説


インフラ課題の解決策②変更要求に対して柔軟かつ正確な対応

商用環境 80台

DR環境 80台

サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ…AP

AP AP AP

開発環境(お客様所有)


AP DB バッチ

サブシステムB

DB

サブシステムC

…AP AP DB バッチ



サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ…AP

AP AP AP

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


総合テスト面

…外部システム結合面



サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

開発環境(自社内)

80台

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

…



30種類

16面

400台超

Puppet担当者

VM

商用環境 80台

DR環境 80台

サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ…AP

AP AP AP

開発環境(お客様所有)


AP DB バッチ

サブシステムB

DB

サブシステムC




サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ…AP

AP AP AP

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


総合テスト面

…




サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

開発環境(自社内)

80台

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

…



30種類

16面

400台超

Puppet Manifest

構築対象の環境

Puppet検証環境

変更要求１

２

３

４

Puppet Manifest

変更の敷居を下げる: 変更しやすさと正確性が保てる

手元の自由に使える環境で変更の検証を行う

課題: 業務の各種テストで使用中変更は慎重さが必要

(テストを止めたくない)

Dockerコンテナで実現 • 台数が多くても、コンテナなら少

ないリソースで何とか動かせる • あくまでPuppet検証用途限定 • ミドルの動作はリソース上困難

メモリ多めのPC

検証済みのPuppet Manifestで変更を実施


システムの特徴③お客様所有データセンタに設置













品質向上



変更のトラッキング

変更の敷居を下げる



開発拠点

システムの特徴③お客様所有データセンタに設置

厳格なセキュリティ管理

5月 6月 7月 8月

商用

DR

データセンタ商用

ラック電源工事

機器設置 OS/ミドル設定

商用ミドル設定

ミドル単体テスト

ミドル可用性テスト

データセンタ DR





ミドル結合テスト



× データセンタ商用入館申請日時: 8/7 10:00～17:00 作業内容: ミドル結合テスト入館者: A社田中一郎

A社佐藤二郎 B社鈴木花子

ネットワークは完全独立 (開発環境と商用環境

はつながらない)

入館日、作業者、作業時間の事前申請が必要

×

お客様立会い管理下での作業


開発拠点

インフラの課題③データセンタでは作業場所/期間/時間に制約

厳格なセキュリティ管理

5月 6月 7月 8月

商用

DR

データセンタ商用






データセンタ DR








× × 作業場所/期間/時間に制約が大きい

場所: 商用環境はデータセンタでの作業が必須

期間: スケジュール通りで構築・テストを終える必要がある • 作業内容に合わせたお客様

担当者が立ち会う。急に立会い日をずらせない。

時間: トラブル発生時でも時間延長は容易ではない (お客様にも残業を強いる)


インフラ課題の解決策③データセンタは作業場所/期間/時間に制約

Puppetで構築、維持管理を実施 • OS設定 • ミドルウエアの構築

ミドルウェア試験の自動化 (今回の発表では詳細は割愛)

• サーバ単体テスト: serverspec • 振る舞いテスト: 内部独自ツール

課題

対策

効果




作業場所/期間/時間に制約が大きい

構築時と同じ効果が顕著に効く


インフラの課題と解決策まとめ













品質向上



変更のトラッキング

変更の敷居を下げる

品質向上







SIプロジェクトでのPuppet活用方法

• Puppetの使い方

• Puppetの構成、Puppet適用スタイル

• Puppet manifest構成

• 商用ソフトのPuppet対応

• Puppetの使い方での工夫は多岐にわたるが、今回はかいつまんで一部のみ紹介

• 残りは、今後のPuppetユーザ会等で順次紹介していきたい


Puppetのシステム構成: Master-Agent構成

商用環境

DR環境

サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP

開発環境 (お客様所有) サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC




サブシステムA

AP

DB

バッチ

AP

DB

バッチ

サブシステムB

AP

DB

AP

DB

サブシステムC

AP

DB

バッチ

AP

DB

バッチ … AP

AP AP AP

サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


総合テスト面

…




サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


サブシステムA

AP DB バッチ

サブシステムB

DB

サブシステムC


…

…


単体テスト(現行)面 Puppet Master

Puppet Master Puppet Master

Puppet Master

Puppet Master

(非機能テスト面用)

Master-Agent構成 • 各環境ごとにPuppet Masterを設置 • Puppet Manifestはgitに一元管理し、各Masterに配布して使用する

Manifest git


Puppetのシステム構成: 適用スタイル

Agentを手動起動させ、常駐(自動適用)させない

• 適用タイミングをコントロールしたい(試験の進捗に合わせて適用したい)

• 差分内容を確認したい(不用意に変更してしまわない)

サーバ

Agent

サーバ

Agent

Puppet Master

Manifest

サーバ

Agent

1. --noopオプションを指定して、diffを表示させる # puppet agent --noop --onetime --no-daemonize

2. diff内容が、意図する内容のみであることを確認

3. agentコマンドで適用する # puppet agent --onetime --no-daemonize


Puppet Manifest構成

PuppetlabsのBest Practiceに従う

• 「The Puppet Language Style Guide」

• 「Module Fundamentals」

• Puppet Manifest設計方法の議論を内部で散々行ってきたが、結局Best Practiceと同じになった

Node定義 Module

DR環境

開発環境サブシス間結合面 …

… 開発環境単体テスト(現行)面

オープンソースミドルA

オープンソースミドルB

オープンソースミドルC

開発環境サブシス内結合面

商用環境

開発環境単体テスト(新規)面

商用ミドルD

商用ミドルE

商用ミドルF

できる限り単純化 • if文など制御を極力排除 • テンプレートは値の穴埋めのみ使用

面依存はNode定義に記載する途中でhieraに乗り換えた


商用ソフトのPuppet対応

商用ソフトは自動化の敵 • 対話型インストーラはPuppet化が困難

コマンドラインインストール、サイレントインストールあり

対話型しかない

Puppet化

オープンソースミドルウェア

商用ソフト

インストール前提条件のみPuppet化

＋手動インストール

インストール前提条件 • ユーザ、ディレクトリ作成 • 依存ライブラリインストール • カーネルパラメタ設定等

前提条件の整備だけでも一定の効果あり • 条件がそろうので、手動インストールが

失敗しにくい • 単純インストール時間のみで済む

Puppet化の考え方 • 全サーバに導入するソフトを優先する

• 運用エージェント(ジョブ、監視等) • アンチウィルス等セキュリティ

• ライセンス費用の高い重要ソフトウェアは、専任担当者が付くので手動インストールでもそれほど問題にならなかった


おわりに


おわりに

今後、Puppetユーザ会を通じて話していきたい内容

• Puppet Best Practice

• PuppetをSIプロジェクトで適用する場合のノウハウ、テクニック

• インフラテスト自動化

等、皆さんに情報提供しつつ議論を深めていきたい

SIプロジェクトでインフラ自動化は非常に役立つ。積極的に推進していきたい。

大規模プロジェクトでのインフラ自動化事例を紹介 1. なぜ自動化を行うのか、インフラの課題と解決策 2. SIプロジェクトでのPuppet活用方法

siプロジェクトでのインフラ自動化の事例 （第1回 puppetユーザ会...

Technology

siプロジェクトでのインフラ自動化の事例（第1回 puppetユーザ会...