TopSE.20121119
- 1. クラウドにおける自动化の现状 と今後の可能性 羽深 修 @habuka036 NTTデータ先端技術株式会社 Eucalyptus Users Group Japan 2012/11/19
- 2. 自己绍介 ●日本Eucalyptusユーザ会のチェアマンやってます。 ◇ 気付いたら「日本でEucalyptusやってる奴」 ◆ 「No Eucalyptus, No Life」とか言ってるので仕方ない… ◇ Eucalyptusの本を出してます ◆ もちろん絶賛発売中ですよ ◇ 「ユーカリプタス入門」という連載をクラウドWatchさ んでやってます 1
- 3. 自己绍介 シャーマンらしいです… ●日本Eucalyptusユーザ会のチェアマンやってます。 ◇ 気付いたら「日本でEucalyptusやってる奴」 ◆ 「No Eucalyptus, No Life」とか言ってるので仕方ない… ◇ Eucalyptusの本を出してます ◆ もちろん絶賛発売中ですよ ◇ 「ユーカリプタス入門」という連載をクラウドWatchさ んでやってます 2
- 4. 「え？Eucalyptus以外は？」 ●dodai projectに関わっています ◇これについてはあとで少し触れます ●それ以外は…？ ◇Eucalyptusがキッカケで人前に出るようになっ ただけの普通の人です ◆ キーボードはIBM Space Saver II 英語配列 ◆ ノートPCはThinkPadのXシリーズ ◆ IMはSKKっぽいのが好き - Emacs使えないのでSKKは未経験 なので、Eucalyptusがなければただの一般人です 3
- 6. 环境构筑の自动化
- 7. 「環境構築」の対象 ●ところで「環境構築」ってどこからどこま で？ ◇BIOSやファームウェアの更新および設定 ◇OSのインストールおよび設定 ◇アプリケーションのインストールおよび設定 ◇データの投入 ◇付随作業 ◆ 設定値の確認 (間違ってない？) ◆ 動作確認 (ちゃんと動く？) ◆ ドキュメントへの反映 (実環境との差異を訂正)
- 8. 「環境構築」の対象 ●ところで「環境構築」ってどこからどこま で？ ◇BIOSやファームウェアの更新および設定 ◇OSのインストールおよび設定 ◇アプリケーションのインストールおよび設定 ◇データの投入 ◇付随作業 ◆ 設定値の確認 (間違ってない？) ◆ 動作確認 (ちゃんと動く？) ◆ ドキュメントへの反映 (実環境との差異を訂正) 「付随作業」なのにボリュームは本作業と同等もしくはそれ 以上の作業量が発生
- 9. 「環境構築」の対象 ●ところで「環境構築」ってどこからどこま で？ ◇BIOSやファームウェアの更新および設定 ◇OSのインストールおよび設定 ◇アプリケーションのインストールおよび設定 ◇データの投入 ◇付随作業 ◆ 設定値の確認 (間違ってない？) ◆ 動作確認 (ちゃんと動く？) ◆ ドキュメントへの反映 (実環境との差異を訂正) 「付随作業」なのにボリュームは本作業と同等もしくはそれ 以上の作業量が発生 → 「なぜ？」
- 10. ところで蛇足ですが… 「自動化≠省力化」ですが、当然ながら産業 の世界では省力化という目的のために自動 化という手法を選びます。 → 自動化するより人海戦術のほうがトータ ルコストが低い場合、自動化によるメリッ トをコスト以外に求める必要があります。 なぜいきなりこんな話をするかと言うと、いくら知識や経験 で自動化が優れていることがわかっていても、実際に現場に おいてはトータルコストにより自動化が実現できないことが あるため、自動化を推進する際にはトータルコスト以外のメ リットも考える必要があります。 9
- 11. 環境構築の省力化 ●BIOSやファームウェアの更新や設定 ◇各ベンダーやメーカー毎に方法が色々ある ◇そもそも設定用ツールが公開されておらず、手 動による設定しか方法がない場合もある ◇ハードウェアやそれに対するデバイスドライバ が色々とあってOSやOSのバージョンよっては利 用できない場合がある ◇「こんなに千差万別なものに対する自動化なん て無理」ヽ(`Д?)? 10
- 12. 環境構築の省力化 ●BIOSやファームウェアの更新や設定 ◇各ベンダーやメーカー毎に方法が色々ある ◇そもそも設定用ツールが公開されておらず、手 動による設定しか方法がない場合もある ◇ハードウェアやそれに対するデバイスドライバ が色々とあってOSやOSのバージョンよっては利 用できない場合がある ◇「こんなに千差万別なものに対する自動化なん て無理」ヽ(`Д?)? 「プラットフォームの仮想化」による「抽象化」で解決 11
- 13. 環境構築の省力化 ●OSのインストールおよび設定 ◇OSのインストール省力化は以下の2つが代表的 ◇イメージ焼き込み方式 ◆ 仮想アプライアンス方式やJEOS方式 ◇自動インストール方式 ◆ RedhatのKickstartやFAI(Fully Automatic Installation)やOPSI 12
- 14. 環境構築の省力化 ●OSのインストールおよび設定 ◇OSのインストール省力化は以下の2つが代表的 ◇イメージ焼き込み方式 ◆ 仮想アプライアンス方式やJEOS方式 ◇自動インストール方式 ◆ RedhatのKickstartやFAI(Fully Automatic Installation)やOPSI ◆ その気になればGentoo LinuxでBashスクリプトで自動 化とか 13
- 15. 環境構築の省力化 ●OSのインストールおよび設定 ◇OSのインストール省力化は以下の2つが代表的 ◇イメージ焼き込み方式 Clonzillaで環境 の複製が便利 ◆ 仮想アプライアンス方式やJEOS方式 ◇自動インストール方式 Kickstartを利用 ◆ RedhatのKickstartやFAI(Fully Automatic Installation)やOPSI したCobblerが有 名 ◆ その気になればGentoo LinuxでBashスクリプトで自動 化とか 14
- 16. 環境構築の省力化 ●OSのインストールおよび設定 ◇OSのインストール省力化は以下の2つが代表的 ◇イメージ焼き込み方式 Clonzillaで環境 の複製が便利 ◆ 仮想アプライアンス方式やJEOS方式 ◇自動インストール方式 Kickstartを利用 ◆ RedhatのKickstartやFAI(Fully Automatic Installation)やOPSI したCobblerが有 名 ◆ その気になればGentoo LinuxでBashスクリプトで自動 化とか 「仮想化」を活用した「クラウド」で解決策を模索中 15
- 17. 環境構築の省力化 ●ちょっと脱線して…「クラウド基盤(≒仮想環 境管理基盤)」って何があるの？ (順不同) ◇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
- 18. 環境構築の省力化 ● アプリケーションのインストールおよび設定 ◇ アプリケーションのインストールおよび設定を省力化する方 法としては前述した以下の2つの方式がある ◆ 仮想アプライアンス方式 ◆ JEOS方式や自動インストール方式 ◇ 上記のうちJEOS方式や自動インストール方式で欠かせないの が、いわゆる「デプロイメントツール」による自動化 ◆ ちなみにここではいわゆる「統合システム運用管理」であるJP1や Tivoliなどは取り上げません ◇ デプロイメントツールと言っても、複数台で構成された環境 へのデプロイメントが一元的にできることが重要 ◆ ただの「インストール省力化ツール」ではあまりメリットがない 17
- 19. 環境構築の省力化 ● アプリケーションのインストールおよび設定 ◇ アプリケーションのインストールおよび設定を省力化する方 法としては前述した以下の2つの方式がある ◆ 仮想アプライアンス方式 ◆ JEOS方式や自動インストール方式 ◇ 上記のうちJEOS方式や自動インストール方式で欠かせないの が、いわゆる「デプロイメントツール」による自動化 ◆ ちなみにここではいわゆる「統合システム運用管理」であるJP1や Tivoliなどは取り上げません ◇ デプロイメントツールと言っても、複数台で構成された環境 へのデプロイメントが一元的にできることが重要 ◆ ただの「インストール省力化ツール」ではあまりメリットがない ここ近年は「継続的インテグレーション」 「継続的デプロイ メント」 「継続的デリバリ」とかが有名 18
- 20. 環境構築の省力化 ●データの投入 ◇「環境構築」において初期データを必要としな い環境であれば考える必要がありませんが、大 抵の環境は何らかの初期データを必要とします データの投入の自動化は前述のアプリケーションのインス トールおよび設定と一緒に自動化されるべき 19
- 21. 環境構築の省力化 ●付随作業 ◇設定値の確認、動作確認、ドキュメントへの反映、 これらのうち「ドキュメントへの反映」以外はこれ までの省力化を実現することにより対応可能 ◇ドキュメントに対する省力化としては、以下が考え られる ◆ 環境定義書(パラメータシート)の廃止 - 他の作業に転用できない「たんに人が見るためだけの資料」とし ての環境定義書は、合理化という観点からは「害悪でしかない」 という思い切った割り切りが必要 ◆ 構築手順書の簡素化 - 环境构筑の自动化が進めば進むほど、構築手順書の記述内容は簡 素化されていく ◆ チェックシートの廃止 - 未だに環境構築の場で根強い人気をほこる「紙によるチェック シート」はどうしても必要ならば紙ではなく電子的なチェック方 式にしたほうがよい 20
- 22. クラウドがもたらした自動化 ●クラウドによって环境构筑の自动化は半分 以上が実現されています ●「なぜ100%実現」でないのか？ アプリケー ドキュメントに 環境構築に関し ションに関す 関する自動化が て人間の手が介 る自動化がま 「省力化」を目 在すること前提 だ発展途上で 標としていない とした手順が ある 残っている 21
- 23. 环境运用の自动化
- 25. ルーティンワークの自動化 ●ルーティンワークに関しては最も自動化が 進んでいる業務であり、自動化ができない 部分は以下のような人の手による作業があ ります ◇物理デバイス(ハードディスクやテープ)の交換 ◆ チェンジャーを利用しても全行程が自動化できない ケース ◇定型化したばかりの業務 ◆ 人の目による判断が求められているケース
- 26. 障害対応の自動化 ● 障害発生時に実施することとして主に以下の作業があります ◇ 関係者への一次報告 ◇ 問題発生箇所の特定 ◇ 関係者への二次報告 ◇ 問題の切り離し ◆ 例えばサーバを停止したり、ネットワークから除外したり ◇ 代替リソースの追加 ◆ 完全に代替できる場合や、急遽用意した代替機で補う場合など様々 ◇ 復旧作業 ◇ 問題解析 ◇ 関係者への三次報告 ◇ 今後の対応策の検討 ◇ 代替リソースの切り替え ◆ 代替リソースが応急処置的な場合など ◇ 関係者への最終報告
- 27. 障害対応の自動化 ●障害発生に対してあらかじめ想定した障害 対策マニュアルなどを作成し、避難訓練的 に平時から障害対応訓練をするなどの方法 が一般的 ◇つまり自動化をしない省力化 ●自動化するために必要なこと ◇リソース監視 ◇検知機構 ◇代替リソースへの自動切り替え (HAなど)
- 28. 障害対応の自動化 ● 障害発生時に実施することとして主に以下の作業があります ◇ 関係者への一次報告 リソース監視と検知機 ◇ 問題発生箇所の特定 ◇ 関係者への二次報告 構で自動化 ◇ 問題の切り離し ◆ 例えばサーバを停止したり、ネットワークから除外したり ◇ 代替リソースの追加 HA構成で対応 ◆ 完全に代替できる場合や、急遽用意した代替機で補う場合など様々 ◇ 復旧作業 ◇ 問題解析 ◇ 関係者への三次報告 現状のままでは人手が ◇ 今後の対応策の検討 必要不可欠 ◇ 代替リソースの切り替え ◆ 代替リソースが応急処置的な場合など ◇ 関係者への最終報告 このままを自動化する のはナンセンス
- 29. リソース変化に対する自動化 ●以下の観点を事前に押えておくことが肝心 ◇「リソース変化」の対象 ◆ 主なターゲットはCPU,メモリ、データストレージ、ネット ワーク帯域などの有限リソースが不足することによる不利 益が発生するもの ◇「リソース不足」を判断するための閾値 ◆ リソース不足を解消するために必要な作業にかかる時間の 間を凌げる余裕を持たせた閾値の設定が必要 ●リソース変化に対応するための方法 ◇オートスケール & オートシュリンク クラウドによって実現性が以前よりは容易になった 28
- 30. 環境移行の自動化 ● クラウド、とりわけプライベートクラウドに関しては「オンプ レミス」という形態が多いため、データセンタを変更する場合 やデータセンタが法定停電でサービスの継続ができない場合が ある ◇ もちろん色々とお金をつぎ込んで回避するところもあるが… ● また、クラウドAからクラウドBへのデータの移行(例えばAWS上 の環境の一部を自前のプライベートクラウドに移行するなど)が 発生する場合 ● 基盤的に互換性がある場合 ◇ 例えばAmazon EC2上のデータをEucalyptusに移行する場合は、比較 的単純にマシンイメージやEBSボリュームやEBSスナップショットの データを移行するだけで対応可能 ● 基盤に互換性がない場合 ◇ 移行元の環境と互換性のあるアプリケーション環境を作成し、アプ リケーション上のデータなどを移行する 29
- 31. 環境移行の自動化 ● クラウド、とりわけプライベートクラウドに関しては「オンプ レミス」という形態が多いため、データセンタを変更する場合 やデータセンタが法定停電でサービスの継続ができない場合が ある ◇ もちろん色々とお金をつぎ込んで回避するところもあるが… ● また、クラウドAからクラウドBへのデータの移行(例えばAWS上 の環境の一部を自前のプライベートクラウドに移行するなど)が 発生する場合 ● 基盤的に互換性がある場合 自動化が容易 ◇ 例えばAmazon EC2上のデータをEucalyptusに移行する場合は、比較 (事例も多数) 的単純にマシンイメージやEBSボリュームやEBSスナップショットの データを移行するだけで対応可能 ● 基盤に互換性がない場合 後付けで対応しようと ◇ 移行元の環境と互換性のあるアプリケーション環境を作成し、アプ すると大変 リケーション上のデータなどを移行する 30
- 32. 環境移行の自動化 ● クラウド、とりわけプライベートクラウドに関しては「オンプ レミス」という形態が多いため、データセンタを変更する場合 やデータセンタが法定停電でサービスの継続ができない場合が ある ◇ もちろん色々とお金をつぎ込んで回避するところもあるが… ● また、クラウドAからクラウドBへのデータの移行(例えばAWS上 の環境の一部を自前のプライベートクラウドに移行するなど)が 発生する場合 ● 基盤的に互換性がある場合 自動化が容易 ◇ 例えばAmazon EC2上のデータをEucalyptusに移行する場合は、比較 (事例も多数) 的単純にマシンイメージやEBSボリュームやEBSスナップショットの データを移行するだけで対応可能 ● 基盤に互換性がない場合 後付けで対応しようと ◇ 移行元の環境と互換性のあるアプリケーション環境を作成し、アプ すると大変 リケーション上のデータなどを移行する 今のところインテリジェンスな方法を模索している状況 31
- 33. 環境移行の自動化 ● クラウド、とりわけプライベートクラウドに関しては「オンプ レミス」という形態が多いため、データセンタを変更する場合 やデータセンタが法定停電でサービスの継続ができない場合が ある ◇ もちろん色々とお金をつぎ込んで回避するところもあるが… ● また、クラウドAからクラウドBへのデータの移行(例えばAWS上 の環境の一部を自前のプライベートクラウドに移行するなど)が 発生する場合 ● 基盤的に互換性がある場合 自動化が容易 ◇ 例えばAmazon EC2上のデータをEucalyptusに移行する場合は、比較 (事例も多数) 的単純にマシンイメージやEBSボリュームやEBSスナップショットの データを移行するだけで対応可能 ● 基盤に互換性がない場合 後付けで対応しようと ◇ 移行元の環境と互換性のあるアプリケーション環境を作成し、アプ すると大変 リケーション上のデータなどを移行する 今のところインテリジェンスな方法を模索している状況 32
- 34. 自動化 ≠ 省力化 クラウド ≠ 万能 33
- 35. 使っているフォント ●タイトルとか ◇しねきゃぷしょん ◆ http://chiphead.jp/font/htm/cinecaption.htm ●本文とか ◇ゆたぽん(コーディング) ◆ http://net2.system.to/pc/font.html ●箇条書きの記号 ◇こくばん ◆ http://falseorfont.web.fc2.com/ 34