クラウドマネジメント勉強会に参加してきた。今が旬なのか定員140名が埋まっていま した。クラウドフェデレーションサービス各種の話が聞ける貴重な勉強会の場でした。
場所 : スクエアエニックスさん
日程 : 2013年4月5日 19:00 -
少し長くなるので、早速。
クラウド運用管理研究会
クラウド利用推進機構が運営するクラウド運用管理研究会は下記の3つに分別されるそ うです。今回は一項目の ‘クラウドマネジメントツール研究会’ にあたるそう。別の研 究会も既に勉強会を実施しているそうです。
- クラウドマネジメントツール研究会
- デザインパターン研究会
- 運用管理・監視研究会
AWS OpsWorks
アマゾンデータサービスジャパン AWS 片山さん, 船崎さん
OpsWorks は最近話題になった AWS 利用者に無料で提供されるクラウドフェデレーショ ンサービス。Web UI で操作し簡単デプロイを実現するサービスです。
OpsWorks が自動化するモノ
- サーバ設定
- ミドルウェア構築
特徴
- Chef フレームワークを利用 (chef-solo を内部的に利用)
- 任意の cookbooks を利用可能
- LB, AP, DB などをレイヤ化, 任意のレイヤも作成可能
OpsWorks の流れ
- Stack 作成
- レイヤ作成 (LB, AP, DB, 任意)
- レシピの作成
- レイヤにインスタンス作成
下記をレイヤ化で区別する
- Package インストール
- OS 設定
- アプリデプロイ
所感
AWS OpsWorks の登場で他のクラウドフェデレーションサービスがどうなるの?とさえ 思った。AWS はインターネット・ホスティング業界のあらゆるサービスを押さえようと している感がある。もう隙間がない!w OpsWorks に関してまだ問題は残っているそう だ。VPC, micro 現在未対応など。が解決に向けて作業しているそう。
Aeolus Conductor
RedHat 中井さん
概要
複数クラウドに対応したイメージ作成・アプリケーション環境構築の自動化ツール
- アプリのデプロイ機能にフォーカス
- Red Hat CoudForms が商用版
- マルチクラウド (ユーザにクラウドが割り当てられる, Hybrid, EC2, RHEV)
自動化について中井さんの案 (手作り)
- libvirt キック
- kickstart 実行
- post script にて puppet 実行
- manifest は github で管理
これらは単一のサーバのみで実施できて、複数台構成等を前提に出来ない等の問題があ る。それらを解決するのが Aeolus Conductor。
Aeolus Conductor の要素
- システムテンプレート用意 (XML) : OS 構成内容が記されている
- マシンイメージ JEOS
- アプリケーションブループリント (アプリデプロイ設計書) shell script である。puppet, chef を呼び出しても OK.
- Config サーバを介して VM 間の構成を管理している : インテグレート! DB, Web
Aeolus Conductor の不便な点
- 特定のクラウド特有の機能には未対応
- 複数 VM デプロイ時のワークフロー処理が不十分
所感
画面を見させてもらったが AWS EC2, RHEV (RedHat の仮想化ソフト) とマルチクラウ ドに対応していた。ユーザにどのクラウドを割り当てるか?等の権限委譲が出来るもの ユニーク。
Scalr
Scalr ユーザ会 梶川さん (IDC フロンティア)
概要, 特徴
- オープンソースのマルチクラウド管理ツール
- 利用出来るクラウド : AWS, Eucalyptus, RackSpace, nimbula, OpenStack, …
- 冗長化・オートスケール可能
- モニタリングも自動で開始
- DNS 管理, オートスケール時、自動的に修正が行われる
- スクリプト実行 (任意のタイミングで可能、またタイミングを作成可能)
- 各サービスのコンフィグプリセット管理 (ミドルウェアのパラメータ?)
所感
Scalr ユーザ会のメンバ募集中だそうだ。個人的にオープンソースの Scalr を試そう と思ったことがあるのだが、手順の wiki が解りづらかった。商用サービスを使わせる ためにわざと解りづらくしているのか?と思うほど。ユーザ拡大のために是非ドキュメ ントの整備をお願いしたい。
RightScale の利用効果と苦労話
So-net エンタテインメント 成田さん
利用効果
- 1つのスクリプトを複数台に対して実行可能
- 手作業が自動化へ
- ベストプラクティスの利用が可能に
- モニタリングの自動化へ
- サーバ台数のスケジューリング化
- セキュリティグループはマクロで作成
- 権限分離による開発者・プロデューサに役割移譲
- 履歴管理の自動記録
- chef recipe が right スクリプトとして走らせられる
苦労話
- Alert 設定のミスでメール大量受信
- 自動化スクリプトのエラー対応
- 計画メンテナンスの後は要注意 (仕様変更)
- RightScale 上の表示を過信しない, 詳しくはクラウドサービス側を確認
- LANG=ja_JP.UTF-8 するとコケる
- メンテナンスは金曜日日中 (月に一回)
所感
実際に運用している方の話はとても貴重。特に苦労ネタはなかなか知ることが出来ない ので。自動化のためにスクリプトを書くのがインフラ系エンジニアの仕事になると知ら せてくれた。Right スクリプトには Chef のレシピも走らせることが出来る、というも が魅力。またインフラ系エンジニア以外の職種の人にも権限委譲し UI を操作してもら える辺りは、業務の最適化のために大いに利用できると感じた。
Chef の話
Engine Yard @yando さん
Engine Yard とは
- PaaS
- AWS + Chef + サポート, 監視
- chef-solo をキック
- chef recipe の管理は Engine Yard が行う
Chef へのモチベーション
- 冪等性
- シェルスクリプトだと構築直後の状態しか保証されない
chef-solo の話
- knife-solo でノードに SSH せずに実行
利用するにあたって直面する課題
- レシピの実装 -> github 上のレシピを参照・利用
- Vagrant の利用でレシピの複数プラットフォーム上でのテスト
- レシピの配布方法 -> github, berkshelf, knife solo, nfs, chef-server
- レシピの反映 -> capistrano, chef-client, cron
Engine Yard Local
- クラウドと同じレシピでローカルに開発環境を構築出来るツール
- クラウドはコストが掛かるし遅いので出来る事ならローカルで、という発想
所感
Chef 流行ってますね。うんうん、(・∀・)イイ!! 個人的には Chef の Cookbooks 開発 はインフラエンジニアにしてもらいたい。Engine Yard のような PaaS 使うならアレだ けどクラウド使うなら運用は引き続き必要だし、運用を意識した Cookbooks 開発は絶 対に必要になってくるからだ。Chef の関連技術がものすごいスピードで進化している のも魅力。より便利で旬な技術をすぐに利用し貢献する、という良いサイクルをうちの 会社でも実現したい。だって楽しいから。chef-solo 使うの?chef サーバ使うの?と いう話はここでも挙がってた。どこかでブログにしようかな。僕は chef サーバ使わな い理由がないと思ってる。