July techfesta2014 f30

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

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

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

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

技術概要
利用者端末
ストレージ
サーバ
ストレージ
サーバ
ストレージ
サーバ
プロキシ
サーバ
外部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
オブジェクト
（=ファイル）
（＝ディレクトリ）

技術概要
利用者端末
ストレージ
サーバ
ストレージ
サーバ
ストレージ
サーバ
プロキシ
サーバ
外部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
監視
＆
検知
 故障に備えて複数のレプリカを書き込む

技術概要
(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 4Node 1
 ディスク故障時やデータ復旧時は自動復旧

技術概要
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
現行サーバ

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

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

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プロセスを起動する
・実行の都度毎回確認
・何度実行しても同じ（冪等性）

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

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

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

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

コミュニティ版との違い
コミュニティ版 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項目の試験を自動で実施

【注意】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のバックグラウンド処理の試験はできない
 バックグラウンド処理の試験は、事前に別途実施した

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

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

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

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

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

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

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

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

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

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

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

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

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

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

July techfesta2014 f30

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to July techfesta2014 f30

Similar to July techfesta2014 f30 (20)

July techfesta2014 f30

Editor's Notes