Copyright © 2013 NTT DATA Corporation
「OpenStack Swift」をPuppetで数百台自動構築
して見えた課題と現状のベストプラクティス
2014年6月22日
株式会社NTTデータ
システム方式技術事業部
柿沼基樹
クラウドストレージを
自前で構築できる

1Copyright © 2014 NTT DATA Corporation
アジェンダ
1 OpenStack Swiftとは
2
OpenStack Swiftを数百台
自動構築して見えた今後の課題
3
これからのインフラプロビジョニング
ベストプラクティス

2Copyright © 2014 NTT DATA Corporation
自己紹介
 氏名：柿沼基樹
 所属：株式会社NTTデータ 基盤システム事業本部
システム方式技術事業部
 経歴：
 自社クラウドサービス(BizXaaS)の開発等を担当。
 OpenStackと出会い、Swiftの評価を担当。
 OpenStack Swiftの自動構築を担当。
 現在はImmutableなインフラを検討するR&Dを実施。

3Copyright © 2014 NTT DATA Corporation

4Copyright © 2014 NTT DATA Corporation
米国RackSpaceのオンラインストレージ
サービスで使われていた基盤ソフト
IaaS (nova)で使うなら VMイメー
ジのバックアップストレージ
世界中でエンタープライズ用途での
適用が進行中

5Copyright © 2014 NTT DATA Corporation
技術概要
利用者端末
ストレージ
サーバ
ストレージ
サーバ
ストレージ
サーバ
プロキシ
サーバ
外部NW
PUT/GE
T
/DELETE
○
○ ○ ○
○ リングファイル
ユーザデータ
（オブジェクト）
2 2
712
105
2
パーティション
ストレージ
サーバ
○
2
a b c d
 Proxyは振分け、Storageはデータ格納
1 2 3 … 2^n
格納先ディスクID ① a b c … z
格納先ディスクID ② b c a … q
格納先ディスクID ③ c d d … w
退避先ディスクID ① d a b … a
… … … … … …
退避先ディスクID x y z … d
乱数表
（リングファイル）
パーティション
パーティション番号(n=1…32)
シ
ス
テ
ム
内
の
全
物
理
デ
ィ
ス
ク
物理ディスク
/swift/2
∟ 0241.data
∟ 0432.data
/swift/105
∟ 0314.data
∟ 0431.data
/swift/712
∟ 0324.data
∟ 0531.data
∟ 0621.data
オブジェクト
（=ファイル）
パーティション
（＝ディレクトリ）

6Copyright © 2014 NTT DATA Corporation
技術概要
利用者端末
ストレージ
サーバ
ストレージ
サーバ
ストレージ
サーバ
プロキシ
サーバ
外部NW
PUT/GE
T
/DELETE
○
1 2 3 … 2^n
格納先ディスクID ① a b c … z
格納先ディスクID ② b c a … q
格納先ディスクID ③ c d d … w
退避先ディスクID ① d a b … a
… … … … … …
退避先ディスクID x y z … d
乱数表
（リングファイル）
パーティション
パーティション番号(n=1…32)
シ
ス
テ
ム
内
の
全
物
理
デ
ィ
ス
ク
○ ○ ○
○ リングファイル
ユーザデータ
（オブジェクト）
2 2
712
105
2
物理ディスク
パーティション
/swift/2
∟ 0241.data
∟ 0432.data
/swift/105
∟ 0314.data
∟ 0431.data
/swift/712
∟ 0324.data
∟ 0531.data
∟ 0621.data
オブジェクト
（=ファイル）
パーティション
（＝ディレクトリ）
ストレージ
サーバ
○
2
退避
a b c d
監視
＆
検知
 故障に備えて複数のレプリカを書き込む

7Copyright © 2014 NTT DATA Corporation
技術概要
(1)定期的にお互いのオブジェクトを監視
(4) ディスク復旧時の回復
(3) オブジェクトの退避
(2) ディスク障害発生と検知
Swiftプロセス ディスク
(５) 退避オブジェクトの削除
Node 1 Node 2 Node 3 Node 4
Node 2 Node 3 Node 4
Node 1 Node 2 Node 3 Node 4
通常
障害
復旧
Node 1 Node 2 Node 3 Node 4
Node 1
Node 2 Node 3 Node 4Node 1
 ディスク故障時やデータ復旧時は自動復旧

8Copyright © 2014 NTT DATA Corporation
技術概要
Proxy
Stora
ge
Stora
ge
Stora
ge
Proxy
(増設)
（１） プロキシサーバ増設 （２） ストレージサーバ増設
①
②
 Proxyを増やせばスループットが増える
 Storageを増やせば容量が増える
Proxy
Stora
ge
Stora
ge
Stora
ge
Proxy
Stora
ge
(増設)
リバランス
①
②
③
④

9Copyright © 2014NTT DATA Corporation
Swiftを使うのはどんなとき？
• スモールスタートしたい
• 終局の見積が難しい／見積したくない
スケールアウト型
• ハードベンダを非依存にしたい
• 激甚対策したい
長期保存型
• １つのファイルにアクセスが集中する
• 利用対象ユーザが多い
高速・性能重視

10Copyright © 2014NTT DATA Corporation
利用例：階層型ストレージ
システムイメージ・利用イメージ 背景・ニーズ
① 過去の資料を廃棄できない
・部門ファイルサーバなど
② 頻度は多くないが閲覧は必要
・複数年分保存が必要な場合が大半
・厳しい容量制限はやりづらい
概要
現行のストレージに加え、前年度以前のデータをSwiftに格納するタイプ
選定ポイント
① スモールスタート
・最小限の初期投資
② データ増量に応じて拡張
・上限は（ほぼ）なし
・ 拡張時も無停止で実施可能
※ あくまで一般的なお話です。当社顧客とは一切関係がございません。
windows
explorer
Swift用
explorer
エンドユーザ
システムA
システムB Connecter(FUSE/ISCSI)
Swift
現行サーバ

11Copyright © 2014 NTT DATA Corporation

12Copyright © 2014 NTT DATA Corporation
自動構築に至った理由と目標
構築サーバ
検証／本番環境
品質
メンバ
…よし、自動構築しよう
数百台
合計6セット
高水準
少人数
目標
・品質/期限は守る（基盤・Swiftの試験は全部やる）
・構築期間は定時に帰る（社内で成功例を！）

13Copyright © 2014 NTT DATA Corporation
自動構築で主に利用したもの
# 利用項目 利用用途
1 kickstart OS・パッケージのインストールを自動化
2 Puppet
設定ファイルのデプロイを、マニフェストに
従って一括デプロイ
3 Subversion マニフェスト及び構築資材の配布
4 pssh 並列シェルの実行(並行でファイル転送、取得)
5 IPMI 電源管理。リモートから電源をONするため。

14Copyright © 2014 NTT DATA Corporation
Puppetとは
ツールの概要 システムを事前定義に従って構成するプロビジョニングツール
開発元 Puppet Labs.
ライセンス Apache 2.0 (ver2.6以下はGPLv2)
開発言語 Ruby
マニフェスト
記法
独自DSL
利用例
１）ファイルをデプロイする
例）/etc/puppet/hoge/hostsを、
/etc/hostsに
パーミッション644
グループ、オーナをroot:root
で配置
２）プロセスを起動する
例) /etc/puppet/hoge/httpd.confを
/etc/httpd/conf/httpd.confに
パーミッション644
グループ、オーナをroot:root
で配置したのち、
httpdプロセスを起動する
・実行の都度毎回確認
・何度実行しても同じ（冪等性）

15Copyright © 2014 NTT DATA Corporation
Puppetを利用する上での懸念
Puppetはサーバ／クライアント構成で利用できない
初期：数百台
・・・
・・・
終局：千台以上
Puppetマスタサーバ
 終局見積もりが千台を超える。Puppetマスタは耐えられるか？
いつか限界を逢えるのは必至・・・

16Copyright © 2014 NTT DATA Corporation
ローカルデプロイ方式
クライアント／サーバ方式
✖故障があると、SSL証明書の削除手順が発生
✖台数が増えるとレスポンスが悪くなる
ローカルデプロイ方式
○故障があっても手順が増えない
○台数が増えてもスケールする
○メンテ時は差分しか送信されないため、負荷
軽減が可能
Puppet
Master
Puppet
Client
Puppet
Client
……
証明書DB
マニフェスト
デプロイ資材
各ホスト毎必要な資材を
Masterが判断してデプロイ
する
構成管理
Puppet
Client
Puppet
Client
……
マニフェスト
デプロイ資材
psshで各ホストに
全資材を配布
(subversion)
各ホストで必要な資材を
判断してデプロイSSL
 Puppetの利用方式をクライアント／サーバ方式から、ローカルデ
プロイ方式（分散方式）とした

17Copyright © 2014 NTT DATA Corporation
自動構築のフロー
構成管理
SVN
Proxy Storage
(1)IPMIで全台電源ON
(2)KickstartでOSインストール(自動)
(3)資材とマニフェストを一括チェックアウト(pssh)
(4)Puppetを使って一括ファイルデプロイ(pssh)
構築完了！！
(0)構成管理サーバ構築（手動）
 わずか４ステップ、３手順で一括構築を実現！

18Copyright © 2014 NTT DATA Corporation
自動構築するのなら、自動試験も
 OpenStack Swiftの自動試験ツールを利用：Tempest
 コミュニティ版は網羅性が不足しているため、独自で試験を追加。
 基盤試験はお手製のツールで。

19Copyright © 2014 NTT DATA Corporation
コミュニティ版との違い
コミュニティ版 NTTデータ版
差
異
各APIに対して1パターンの試験を実施 各APIに対して、複数(網羅できるだけの)パターンの試
験を実施
例 【1】
試験名：オブジェクトPUT
試験内容：オブジェクトＸＸＸをPUTする
期待結果：HTTPレスポンス 201
【1】
試験名：オブジェクトPUT+メタデータ付与
試験内容：オブジェクトＸＸＸをメタデータ付きでPUTする
期待結果：HTTPレスポンス 201
【2】
試験名：オブジェクトPUT+Invalid Contentlength
試験内容：不正なContent-lengthを設定してオブジェク
トをPUTする
期待結果：HTTPレスポンス400 (BadRequest)
・・etc
試
験
数
例
オブジェクトPUT試験:1 オブジェクトPUT試験:103
Tempest全体で416項目の試験を自動で実施

20Copyright © 2014 NTT DATA Corporation
【注意】Tempestでは出来ないこと
Proxy
Storage#1 Storage#2 Storage#3
Tempest
proxy-server
acc/con/obj-
server
acc/con/obj-
replicator
con/obj-updator
account-reaper
acc/con/obj-
auditor
acc/con/obj-
server
acc/con/obj-
replicator
con/obj-updator
account-reaper
acc/con/obj-
auditor
acc/con/obj-
server
acc/con/obj-
replicator
con/obj-updator
account-reaper
acc/con/obj-
auditor
Tempestで
試験できる
Tempestで
試験できない
 Swiftのバックグラウンド処理の試験はできない
 バックグラウンド処理の試験は、事前に別途実施した

21Copyright © 2014 NTT DATA Corporation
自動構築＆自動試験の効果
目標
・品質/期限は守る（基盤・Swiftの試験は全部やる）
・構築期間は定時に帰る（社内で成功例を！）
品質は守れたか？
【結果】
全部で一万項目以上の試験
結果を報告
品質水準の充足達成！
定時に帰れたか？
【結果】
構築期間は定時前に作業完
了。サクサク帰宅。
WLBの充足達成！
一見すると大成功のサクセスストーリー。しかし・・・

22Copyright © 2014 NTT DATA Corporation
遭遇したトラブル
 構築直後のアップデート作業（運用作業）にて、トラブルに遭遇
トラブル①
検証環境のファイルを間違って本番環境へデプロイ
してしまった
トラブル② 別の理由で停止していたプロセスが、Puppetの実
行により意図せず起動してしまった
トラブル③ ファイルは正確にデプロイした。しかし、設定が反映さ
れていなかったため、想定外の事象が発生した

23Copyright © 2014 NTT DATA Corporation
なぜ起きるか？ ～今後解決すべき課題～
【仮説】本番環境へのプロビジョニング運用は、正しくないのでは？
検証環境のファイルを間違って本番環境へデプロイしてしまった
別の理由で停止していたプロセスが、Puppetの実行により意図せず起動してしまった
ファイルは正確にデプロイした。しかし、設定が反映されていなかったため、想定外の事象が発生した
Puppetは環境差分を管理してくれるわけではない。
Puppetは定義された通り起動しただけ。
Puppetは設定の反映までは面倒みてくれない。
本番環境へプロビジョニング運用し続けることはやめたい！

24Copyright © 2014 NTT DATA Corporation

25Copyright © 2014 NTT DATA Corporation
これからのインフラ ～Immutable Infrastructure～
「１度構成したサーバには２度と変更を加えない。変更時は新たな環境に差し替える。」
• 運用している間にシステムがつぎはぎになり、管理が難しくなるという課題に対する答えのひとつ
– Chef/Puppetなどのコード化によって軽減はされるが、本質的な難しさは軽減されない
• 「Blue Green Deployment」という考え方を一歩進めた考え方
– 環境を２面用意した上で、バージョンアップ時にロードバランサをもう片方の環境に切り替える方式
• 必須条件は「環境をまっさらなOSイメージから再現できること」
– インフラがコード化されている今、可能になった
@IT「継続的デリバリ／デプロイを実現する手法・ツールまとめ (2/2)」 http://www.atmarkit.co.jp/ait/articles/1312/03/news033_2.html
**ポイント**
本番環境へプロビ
ジョニングしない！

26Copyright © 2014 NTT DATA Corporation
Immutable Infrastructureを実現するプロビジョニング
本番環境へのプロビジョニング運用はやめる。
デプロイ毎に、プロビジョニングで作り直す。
ただし、今までのプロビジョニングツールをそのまま使うと・・
OSの設定はプロビジョニングツールで
コード化できるけど…
OSのイメージ作成から一貫
してプロビジョニングできないの
だろうか？
マルチプラットフォームイメージ作成ツール
Packer
Linuxコンテナ管理アプリケーション
Docker
あります！今、ちょうど話題の！

27Copyright © 2014 NTT DATA Corporation
packer
Packerとは
ツールの概要 複数プラットフォームに対応した仮想マシンイメージのビルドツール
開発元 HashiCorp
ライセンス Mozilla Public License Version 2.0
開発言語 Go
仮想マシン
定義
ファイル
(json)
【プロビジョニング】

28Copyright © 2014 NTT DATA Corporation
Packer：ユースケース①
検証環境 開発環境 本番環境
Virtual BOX
packer
検討初期やデバッグ作業は
デスクトップ上で
開発中の環境は
リーズナブルに
本番環境でも開発環境と
全く同じイメージをデプロイ
.qcow2.box AMI
仮想マシン
定義
ファイル
(json)
 開発環境構築の効率化と本番環境との差異解消

29Copyright © 2014 NTT DATA Corporation
Packer：ユースケース②
初期 中期 後期
導入初期は安価な
パブリック・クラウド
規模が大きくなってきたら
プライベートクラウドへ移行
利用者の減退に伴い
再度安価なクラウドへ移行
.qcow2 AMIAMI
packer
仮想マシン
定義
ファイル
(json)
 利用形態の変遷に伴うクラウド横断的なマイグレーション

30Copyright © 2014 NTT DATA Corporation
Dockerとは
ツールの概要 Linuxコンテナ(LXC)を用いたコンテナ管理アプリケーション
開発元 Docker Inc
ライセンス Apache License 2.0
開発言語 Go
Linux標準の機能(cgroups, namaspaces)を用いて、
ホスト上のコンテナ間のリソースを隔離している

31Copyright © 2014 NTT DATA Corporation
Dockerの特長
API ・Docker Hub APIによる外部サービスとの連携
ポータビリティ
・サイズが軽量なため、別環境への移行が簡単
・Dockerリポジトリを利用した移行
バージョニング ・コンテナをバージョン管理できる
1
2
3
http://blog.docker.com/2014/06/announcing-docker-hub-and-official-repositories/

32Copyright © 2014 NTT DATA Corporation
仮想サーバ
Packer + Dockerの使い分け
 基本はPackerを使っておく。(Dockerfileでビルドしない)
 Dockerはあくまでもプラットフォームとみなす。
packer
Docker
リポジトリ
2面用意が難しい
物理環境にもってこい
S3
container
物理サーバ
AMI
json

33Copyright © 2014 NTT DATA Corporation
これからのプロビジョニングのベストプラクティス
 コード化したインフラ／アプリ／テストコードをCIと連携してプロ
ビジョニングする。
CIツール
(jenkins)
Docker
①ビルド
独自
レポジトリ
③war取得
ソースコミット
アプリ開発者
レシピ
コミット
インフラ開発者
Packer
③ベース
コンテナ取得
④コンテナ登録
②レシピ＆テスト
コード取得
【検証環境】
container
【本番環境】
テストコード
コミット
④ビルド＆テスト
【机上環境】
連携
本番運用中！

34Copyright © 2014 NTT DATA Corporation
今後取り組むべき課題
 Linuxコンテナ(Docker)の利用はまだ課題がある
【現場の声】
 DBとかImmutableにできるのか？DBaaSにすべき？
 ログ管理はどうする？集約型？Fluentd?
 RHEL7から対応！？まだ現場はRHEL5のみ対応アプリとか結構
あるけど、ちゃんと動くか？
 プライベートリポジトリの管理…誰がやるの？・・・etc
いきなり全部をImmutableにするのは難しい。
まずは徐々に改善ベースでやるのが最適。

35Copyright © 2014 NTT DATA Corporation

36Copyright © 2014 NTT DATA Corporation
まとめ
 OpenStack Swiftを数百台自動構築しました。
 構築は成功したものの、運用段階でトラブルが起き、プロビ
ジョニングツールだけでの本番環境の運用の限界を感じました。
 本番環境に直接プロビジョニングしない、”Immutableなイ
ンフラ”を実現してくれるPackerとDocker、その使いドコロを
ご紹介しました。
 しかし、これらの要素技術はまだ課題もあります。引き続き注
意しながら、いいところは段階的に使っていきましょう。

Copyright © 2011 NTT DATA Corporation
Copyright © 2014 NTT DATA Corporation