TopSE.20121119

クラウドにおける自動化の現状
と今後の可能性

羽深修
@habuka036
NTTデータ先端技術株式会社
Eucalyptus Users Group Japan
2012/11/19

自己紹介

●日本Eucalyptusユーザ会のチェアマンやってます。
◇ 気付いたら「日本でEucalyptusやってる奴」
◆ 「No Eucalyptus, No Life」とか言ってるので仕方ない…
◇ Eucalyptusの本を出してます
◆ もちろん絶賛発売中ですよ
◇ 「ユーカリプタス入門」という連載をクラウドWatchさ
んでやってます

1

自己紹介

シャーマンらしいです…
●日本Eucalyptusユーザ会のチェアマンやってます。
◇ 気付いたら「日本でEucalyptusやってる奴」
◆ 「No Eucalyptus, No Life」とか言ってるので仕方ない…
◇ Eucalyptusの本を出してます
◆ もちろん絶賛発売中ですよ
◇ 「ユーカリプタス入門」という連載をクラウドWatchさ
んでやってます

2

「え？Eucalyptus以外は？」

●dodai projectに関わっています
◇これについてはあとで少し触れます
●それ以外は…？
◇Eucalyptusがキッカケで人前に出るようになっ
ただけの普通の人です
◆ キーボードはIBM Space Saver II 英語配列
◆ ノートPCはThinkPadのXシリーズ
◆ IMはSKKっぽいのが好き
- Emacs使えないのでSKKは未経験

なので、Eucalyptusがなければただの一般人です

3

ここでのお題目

●環境構築の自動化
●環境運用の自動化
◇日次、週次、月次業務の自動化
◇障害対応の自動化
◇リソース変化に対する自動化
◇環境移行の自動化

4

「環境構築」の対象

●ところで「環境構築」ってどこからどこま
で？
◇BIOSやファームウェアの更新および設定
◇OSのインストールおよび設定
◇アプリケーションのインストールおよび設定
◇データの投入
◇付随作業
◆ 設定値の確認 (間違ってない？)
◆ 動作確認 (ちゃんと動く？)
◆ ドキュメントへの反映 (実環境との差異を訂正)


で？
◇付随作業
「付随作業」なのにボリュームは本作業と同等もしくはそれ
以上の作業量が発生


で？
◇付随作業
「付随作業」なのにボリュームは本作業と同等もしくはそれ
以上の作業量が発生 → 「なぜ？」

ところで蛇足ですが…

「自動化≠省力化」ですが、当然ながら産業
の世界では省力化という目的のために自動
化という手法を選びます。
→ 自動化するより人海戦術のほうがトータ
ルコストが低い場合、自動化によるメリッ
トをコスト以外に求める必要があります。
なぜいきなりこんな話をするかと言うと、いくら知識や経験
で自動化が優れていることがわかっていても、実際に現場に
おいてはトータルコストにより自動化が実現できないことが
あるため、自動化を推進する際にはトータルコスト以外のメ
リットも考える必要があります。

9

環境構築の省力化

●BIOSやファームウェアの更新や設定
◇各ベンダーやメーカー毎に方法が色々ある
◇そもそも設定用ツールが公開されておらず、手
動による設定しか方法がない場合もある
◇ハードウェアやそれに対するデバイスドライバ
が色々とあってOSやOSのバージョンよっては利
用できない場合がある
◇「こんなに千差万別なものに対する自動化なん
て無理」ヽ(`Д´)ﾉ

10


●BIOSやファームウェアの更新や設定
◇各ベンダーやメーカー毎に方法が色々ある
◇そもそも設定用ツールが公開されておらず、手
動による設定しか方法がない場合もある
◇ハードウェアやそれに対するデバイスドライバ
が色々とあってOSやOSのバージョンよっては利
用できない場合がある
◇「こんなに千差万別なものに対する自動化なん
て無理」ヽ(`Д´)ﾉ

「プラットフォームの仮想化」による「抽象化」で解決

11


●OSのインストールおよび設定
◇OSのインストール省力化は以下の2つが代表的
◇イメージ焼き込み方式
◆ 仮想アプライアンス方式やJEOS方式
◇自動インストール方式
◆ RedhatのKickstartやFAI(Fully Automatic
Installation)やOPSI

12


◇イメージ焼き込み方式
Installation)やOPSI
◆ その気になればGentoo LinuxでBashスクリプトで自動
化とか

13


◇イメージ焼き込み方式 Clonzillaで環境
の複製が便利
Kickstartを利用
Installation)やOPSI したCobblerが有
名
化とか

14


◇イメージ焼き込み方式 Clonzillaで環境
の複製が便利
Kickstartを利用
Installation)やOPSI したCobblerが有
名
化とか

「仮想化」を活用した「クラウド」で解決策を模索中

15


●ちょっと脱線して…「クラウド基盤(≒仮想環
境管理基盤)」って何があるの？ (順不同)
◇OpenStack http://www.openstack.org/
◇CloudStack http://incubator.apache.org/cloudstack/
◇Eucalyptus http://www.eucalyptus.com/
◇Wakame-VDC http://wakame.jp/
◇OpenQRM http://www.openqrm.com/
◇mYouVan http://www.cross-m.co.jp/myouvan/
◇OpenNebula http://opennebula.org/
◇Karesansui http://karesansui-project.info/
◇Nimbus http://www.nimbusproject.org/
◇他にも色々…っていうか書ききれない
16


● アプリケーションのインストールおよび設定
◇ アプリケーションのインストールおよび設定を省力化する方
法としては前述した以下の2つの方式がある
◆ 仮想アプライアンス方式
◆ JEOS方式や自動インストール方式
◇ 上記のうちJEOS方式や自動インストール方式で欠かせないの
が、いわゆる「デプロイメントツール」による自動化
◆ ちなみにここではいわゆる「統合システム運用管理」であるJP1や
Tivoliなどは取り上げません
◇ デプロイメントツールと言っても、複数台で構成された環境
へのデプロイメントが一元的にできることが重要
◆ ただの「インストール省力化ツール」ではあまりメリットがない

17


● アプリケーションのインストールおよび設定
◇ アプリケーションのインストールおよび設定を省力化する方
法としては前述した以下の2つの方式がある
◆ 仮想アプライアンス方式
◆ JEOS方式や自動インストール方式
◇ 上記のうちJEOS方式や自動インストール方式で欠かせないの
が、いわゆる「デプロイメントツール」による自動化
◆ ちなみにここではいわゆる「統合システム運用管理」であるJP1や
Tivoliなどは取り上げません
◇ デプロイメントツールと言っても、複数台で構成された環境
へのデプロイメントが一元的にできることが重要
◆ ただの「インストール省力化ツール」ではあまりメリットがない

ここ近年は「継続的インテグレーション」「継続的デプロイ
メント」「継続的デリバリ」とかが有名
18


●データの投入
◇「環境構築」において初期データを必要としな
い環境であれば考える必要がありませんが、大
抵の環境は何らかの初期データを必要とします

データの投入の自動化は前述のアプリケーションのインス
トールおよび設定と一緒に自動化されるべき

19


●付随作業
◇設定値の確認、動作確認、ドキュメントへの反映、
これらのうち「ドキュメントへの反映」以外はこれ
までの省力化を実現することにより対応可能
◇ドキュメントに対する省力化としては、以下が考え
られる
◆ 環境定義書(パラメータシート)の廃止
- 他の作業に転用できない「たんに人が見るためだけの資料」とし
ての環境定義書は、合理化という観点からは「害悪でしかない」
という思い切った割り切りが必要
◆ 構築手順書の簡素化
- 環境構築の自動化が進めば進むほど、構築手順書の記述内容は簡
素化されていく
◆ チェックシートの廃止
- 未だに環境構築の場で根強い人気をほこる「紙によるチェック
シート」はどうしても必要ならば紙ではなく電子的なチェック方
式にしたほうがよい
20

クラウドがもたらした自動化

●クラウドによって環境構築の自動化は半分
以上が実現されています
●「なぜ100%実現」でないのか？

アプリケードキュメントに環境構築に関し
ションに関す関する自動化がて人間の手が介
る自動化がま「省力化」を目在すること前提
だ発展途上で標としていないとした手順が
ある残っている

21

環境運用の対象は？

●「環境運用」と一口に言っても以下の様々な業
務があります
◇日次、週次、月次業務などのルーティンワーク
◇障害対応などの突発的作業
◇リソース変化に伴うキャパシティプランニング
◇ロケーションの変更や他拠点展開に伴う環境移行
●これらの業務を省力化するために以下の自動化
が考えられます
◇ルーティンワークの自動化
◇障害対応の自動化
◇リソース変化に対する自動化
◇環境移行の自動化

ルーティンワークの自動化

●ルーティンワークに関しては最も自動化が
進んでいる業務であり、自動化ができない
部分は以下のような人の手による作業があ
ります
◇物理デバイス(ハードディスクやテープ)の交換
◆ チェンジャーを利用しても全行程が自動化できない
ケース
◇定型化したばかりの業務
◆ 人の目による判断が求められているケース

障害対応の自動化

● 障害発生時に実施することとして主に以下の作業があります
◇ 関係者への一次報告
◇ 問題発生箇所の特定
◇ 関係者への二次報告
◇ 問題の切り離し
◆ 例えばサーバを停止したり、ネットワークから除外したり
◇ 代替リソースの追加
◆ 完全に代替できる場合や、急遽用意した代替機で補う場合など様々
◇ 復旧作業
◇ 問題解析
◇ 関係者への三次報告
◇ 今後の対応策の検討
◇ 代替リソースの切り替え
◆ 代替リソースが応急処置的な場合など
◇ 関係者への最終報告


●障害発生に対してあらかじめ想定した障害
対策マニュアルなどを作成し、避難訓練的
に平時から障害対応訓練をするなどの方法
が一般的
◇つまり自動化をしない省力化
●自動化するために必要なこと
◇リソース監視
◇検知機構
◇代替リソースへの自動切り替え (HAなど)


● 障害発生時に実施することとして主に以下の作業があります
◇ 関係者への一次報告
リソース監視と検知機
◇ 問題発生箇所の特定
◇ 関係者への二次報告構で自動化
◇ 問題の切り離し
◆ 例えばサーバを停止したり、ネットワークから除外したり
◇ 代替リソースの追加 HA構成で対応
◆ 完全に代替できる場合や、急遽用意した代替機で補う場合など様々
◇ 復旧作業
◇ 問題解析
◇ 関係者への三次報告現状のままでは人手が
◇ 今後の対応策の検討必要不可欠
◇ 代替リソースの切り替え
◆ 代替リソースが応急処置的な場合など
◇ 関係者への最終報告
このままを自動化する
のはナンセンス

リソース変化に対する自動化

●以下の観点を事前に押えておくことが肝心
◇「リソース変化」の対象
◆ 主なターゲットはCPU,メモリ、データストレージ、ネット
ワーク帯域などの有限リソースが不足することによる不利
益が発生するもの
◇「リソース不足」を判断するための閾値
◆ リソース不足を解消するために必要な作業にかかる時間の
間を凌げる余裕を持たせた閾値の設定が必要
●リソース変化に対応するための方法
◇オートスケール & オートシュリンク

クラウドによって実現性が以前よりは容易になった
28

環境移行の自動化

● クラウド、とりわけプライベートクラウドに関しては「オンプ
レミス」という形態が多いため、データセンタを変更する場合
やデータセンタが法定停電でサービスの継続ができない場合が
ある
◇ もちろん色々とお金をつぎ込んで回避するところもあるが…
● また、クラウドAからクラウドBへのデータの移行(例えばAWS上
の環境の一部を自前のプライベートクラウドに移行するなど)が
発生する場合
● 基盤的に互換性がある場合
◇ 例えばAmazon EC2上のデータをEucalyptusに移行する場合は、比較
的単純にマシンイメージやEBSボリュームやEBSスナップショットの
データを移行するだけで対応可能
● 基盤に互換性がない場合
◇ 移行元の環境と互換性のあるアプリケーション環境を作成し、アプ
リケーション上のデータなどを移行する

29


ある
発生する場合
● 基盤的に互換性がある場合自動化が容易
(事例も多数)
● 基盤に互換性がない場合後付けで対応しようと
すると大変

30


ある
発生する場合
(事例も多数)
すると大変

今のところインテリジェンスな方法を模索している状況
31


ある
発生する場合
(事例も多数)
すると大変

今のところインテリジェンスな方法を模索している状況
32

自動化 ≠ 省力化
クラウド ≠ 万能
33

使っているフォント

●タイトルとか
◇しねきゃぷしょん
◆ http://chiphead.jp/font/htm/cinecaption.htm
●本文とか
◇ゆたぽん(コーディング)
◆ http://net2.system.to/pc/font.html
●箇条書きの記号
◇こくばん
◆ http://falseorfont.web.fc2.com/

34

TopSE.20121119

More Related Content

Similar to TopSE.20121119

More from Osamu Habuka

TopSE.20121119