クラスメソッド開発ブログ課外授業8日目『AWS管理を自動化する奥義』に参加してきた #cm_dev

103件のシェア(ちょっぴり話題の記事)

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

08_aws

どうも。出張ブロガーのしんやです。

最近こちらで(主に)AWSネタを書かせて頂いてますが、しばらく前にこちらの勉強会告知がされた時に『これはアツい!』と思い速攻で申込みを済ませ、この日参加して参りました。自分のブログでは嫌んなる位書いてきた *1レポートですが、こうした形で別ブログにレポートを書くのは今回初めてとなります。 *2 何卒宜しくお願い致します。

参加申込みサイトでは30人程の定員でしたが、申込人数はその定員を大きく上回る60人余。この数字を見るだけでもこれらテーマに関する関心の高さが伺えますね。

おおはしりきたけさんによるイベントの速報ブログレポートはこちらです!
【勉強会】AWS管理を自動化する奥義を開催しました! | Developers.IO

会場及び当日イベント概要説明

イベントハッシュタグは#cm_dev。こちらの『課外授業』シリーズ、このハッシュタグで情報発信される模様です。要チェックですね。

『クラスメソッドブログ課外授業』の主催をつとめておられるおおはしりきたけさんから、イベントや会社の事についての説明が冒頭になされました。

cm_dev01

そして、会社のFacebookページがもうすぐ『1000いいね!』を達成すると言う事で、『是非「いいね!」をお願いします』という告知もありました :-)
※(1000いいね!を)達成した暁には会社説明会が催されるらしいです。

classmethod_fb

「ChefとOpsWorksでEC2楽チンクッキング!」

AWSを使い始めた皆さん、最初は楽だったEC2の管理が最近大変になってきてませんか? AWSに限らず、システムの運用管理ツールとして注目されるChef。ChefをベースとしてEC2の管理に活用できるOpsWorks。 このChefとOpsWorksの関係、使いどころをご紹介します。

DSC_0163

当日のスライド資料はこちら。(※今回は事前(開始前)にスライド資料の周知がなされており、参加者の皆さんはじっくり資料見ながらお話を聞く事が出来ていました。このような形で準備が成されていると参加者にも嬉しいですね。)

ChefとOpsWorksで EC2 楽チンクッキング!

ChefとOpsWorksで EC2 楽チンクッキング! from クラスメソッド株式会社

事前にスライド資料が公開されていたのもありますので、メモは抜粋の形で気になった所を。

  • OpsWorksは現状ベータ版。なので今回はどのようなものなのか、雰囲気を掴んで頂ければ。
  • アンケート:皆さんのご職業は?(ざっくり以下の様な構成でした。)
    • アプリケーションエンジニア(会場の約6割)
    • インフラエンジニア(会場の3割ちょい?)
    • マネージャ、PM(お一方のみ)
  • 今日の講演は、どの方にも皆さんが幸せになる話!(...のはず。)

1.インフラ管理の自動化の歴史

  • Chef/OpsWorks以前は「手作業」「スクリプトバッチファイル」「構成管理ツール」の3段階に大別。
  • 前2段階のものについては、色々と困る点も多い。
  • 構成管理ツール:最近は「Provisioning Framework」等とも呼ばれたりしている。注目株はChefとPuppet。
  • 以下2点がChef/Puppetにあるため、注目している。

Infrastructure as Code

ootaki01

べき等性と収束

冪等性の確保 - Amazon Elastic Compute Cloud

  • 何度実行しても同じ状態となり、システムの「あるべき姿」を管理する。
  • シェルスクリプトの場合、1回実行した後にもう1回やるとインストールの手順を実行してしまい、複数回実行に対応出来ない。
  • Chef等はこの辺についてちゃんと考慮された仕組みとなっている。

Chef、puppetの心得

  • コマンドで直接作業するのはご法度。我慢する。
  • AWS EC2インスタンスの場合は色んな用途のインスタンスを共通のAMIイメージで作成・管理する。元は1個(のAMI)。chefを走らせて各種サーバを入れる、というイメージ。
  • 実現すれば夢の様な話だが、実際は茨の道。

Chefとpuppet、どっち?

  • どっちでも良いらしい。好みで選びましょう。
  • (大瀧さんの)個人的見解としても『どちらでも可』だと思う。同じように成長して行ってくれるのでは。

2.Chefとは

構成管理ツール。 Opscode社が開発。※サービス(名)とは完全別物です。

cheftop

構成

  • 以下2通りで実行が可能。
    • Chef Solo:スタンドアロンタイプ。chef自体はシンプルな仕組み。設定ファイルをchefsoloを使ってローカルシステムに適用して行く。
    • Chef Client & Chef Server:クライアント・サーバタイプ。サーバにある設定ファイルをダウンロード→ローカルシステムに適用。

WorkStationというものもあるのですが、今回のセッションでは割愛。

Install Chef 11.x on a Workstation — Chef Docs

Soloの方が仕組みとしては簡単。でもC/Sでしか使えない機能もある(この辺りは両者の差分を確認してみるのをオススメ)。双方規模によって使い分けましょう。また、Environment(大規模環境向け)というのもある。

About Environments — Chef Docs

主なChefの設定

幾つか挙げられるが、まずはこれらから。

Cookbook
設定をまとめる単位、実際はフォルダ。
Recipe
構成内容を記述するファイル。
システムのメイン構成。Rubyで書く。
Template
設定ファイルの雛型。erb形式

(実演デモ)

Linuxサーバにnginxを導入するChefのデモがここで入りました。

DSC_0171 DSC_0173

3.OpsWorksとは

AWSの新しい機能。買収したサービスを2013/02に再リリース。現在オープンβ版として提供されている。

  • 構成:Chef Solo + LifeCycleEvents
    • EC2の設定をするために内部的にChefを使っている。
    • Soloを使う。更にOpsWork独自の仕組みを適用。
    • デフォルトのクックブックを持ち込む事も可能。ただ手間が掛かる場面もあり。

4.で、どれを使いましょうか

Chefはプラグインが豊富。便利な機能が沢山ある。応用範囲が広い。一方、OpsはゆくゆくはAWSの諸機能との連携が深まっていくのではないか。ここはその連携強化に期待しつつ、今後を見守ろう。

cm_dev02

と言った形で、大瀧さんのセッションはこれにて終了。

大瀧さん然り当日イベントに来られていた方々の多くが、スライド最終ページでおすすめされていた「入門Chef Solo」を購入している、または読んでいるとコメントしてました。最近だとやはりまずはこの書籍から、という感じですね。(かく言う私も書籍は購入済みです。) OpsWorksについてはまだベータ版と言う事もあり、今後に期待する部分が多いような気がしますが、Chefは今すぐにでも触り始めて、使えるようにするべき/しておくべき要素の1つであるなぁと強く思いを新たにした次第です。

Amazon.co.jp: 入門Chef Solo - Infrastructure as Code eBook: 伊藤直也: Kindleストア

入門Chef Solo - Infrastructure as Code - 達人出版会

「Rudess(仮)を支える技術 ~ CloudFormationの活用事例と詳細解説」

先日弊社のブログにて、ちょっとした画像加工システムを公開しました。 このシステムの構築にあたっては、OSやミドルウェア等の知識はほとんど不要で、AWSのアカウントさえ持っていればだれでも簡単に、約30分で環境を構築することができます。 その秘密はCloudFormation。AWSのサービスラインナップの中では決してメジャーとは言えない目立たないサービスに見えるかもしれませんが、そのパワーは絶大です。 本セッションでは、実在のシステムを元に、その活用事例と、詳細なCloudFormationの使い方を解説します。

DSC_0176

スライド発表資料はこちら。

AWS管理を自動化する奥義 from クラスメソッド株式会社

Rudess(仮)って何だ

cloudformation01

  • オンデマンド画像リサイズサービス。
  • リサイズ作業、面倒なのでキャッシュを効かせて対応。
  • アクセス権は認証ファイル‥.ではなく、IAM Roleという仕組みを使っている。( AWS Identity and Access Management (IAM) Preview Beta | アマゾン ウェブ サービス(AWS 日本語) )
    • IAM Role:EC2のインスタンスに対するアカウントのようなものを発行し、APIアクセスを許可する。
    • Java版の場合、コンストラクタ引数のインスタンスを省略すると、自動的にこの機能を観に行くようになっている。
  • 上記図を見ても分かるように、結構大きな構成で出来上がるシステムとなっております。

アプリ導入にあたっての依存関係

ゴールとしては「Webアプリケーションが使えるようになる」事。しかしそれを実現するためには起動設定からアプリデプロイ設定から...最終的にはOSの準備までしないといけない。

結果、Rudessを使うためにやらなければいけない要素を洗い出すと、手間の掛かるものが沢山...

でも、CloudFormationを使うと、これらが全て自動化出来ます。

(実演デモ)

ここからは、各要素の解説を交えながらの実演デモ。ひと通りのデモを終えるまでに20数分掛かる見込みのようでこのタイミングでの実演デモ開始となったようです。

DSC_0195w2.png

キーワードとしては以下のようなものが挙げられておりました。途中内容やキーワードの解説が入る形に。

Parameter:
DynamoDBはキャパシティに対してお金を払う。能力を買うので結果キャパシティを満たす事が無かったとしても、その際の利用料金は変わらない。
CloudFormationではその辺りの設定値も対応している。
正規表現による制約等も可能。
また、空文字についてはどうやら許可されていない模様。
定義したパラメータは、"ref"というキーワードを使うことで参照が行えるようになる。

cloudformation02

Mapping:
連想配列を使った仕組み。refを使う事が出来る。
AWS上にELBを分散させた形で配置する、という仕組み。
AWSではMulti-AZで作るのが大原則。MultiAZにしとけば普通にサービスを続けられる。
設定値の違いを吸収するための仕組み。

最終的には数十分の時間を経てサービスが立ち上がり、画像変換処理の確認まで到達。初回処理実行については若干時間を食いますが、以降の表示についてはかなり早く表示がされている事を確認出来ました。

DSC_0197y

質疑応答

[Q]. CloudFormation、一式作るのに長い手間がかかると思いますがどうやってデバッグしてますか?
(A).最低限Jsonとしてvalidかどうか、必須パラメータがあるかどうかはある程度まで検出することは可能。
途中失敗すると、それまで作っていたものを破壊して...いやロールバックして戻りますw ( ※この点、最終的には作成過程で作ったものは全部消える流れになるので、この点は残ったまま処理が終了してしまうよりかは遥かに良い、と都元さんはコメント。)
コマンドでコンパイルエラーチェック程度の間違いは検出出来、あとは発生した例外の内容に応じて対応。
[Q].S3の名前、CloudFormationF使うと名前が自動的にランダム表記になってしまいますが、そこは何か作成側の方で対処出来ないものなのでしょうか?
A.出来ません!その辺りは作成する要素の名称をワールドワイドで重複しないように制御する為には止むを得ないのでしょう。
ELBの名前等もCFを使うと制御出来ない模様です。
となるとやはりこの部分は、ユーザーデータとして渡して構成する方が良い。ここは各自皆さんで工夫してください。

以上で課外授業2コマ、終了。※都元さんの当セッションに関連するその他のエントリは以下をご参照ください。

まとめ

…という訳で、トピック的にも「AWS管理の自動化」というホットなテーマとなった今回の勉強会、本編も去ることながらその後の懇親会も大いに盛り上がる形となりました。

キーワード的にも「自動化」というものは響きは良いですが、そこに至るまでの道のりは決して平坦なものではないと言う事は今回の課外授業でも改めて実感する事となりました。Chef然り(Puppet然り)、今回紹介されたAWSの両機能(OpsWorks,CloudFormation)は「自動化」への心強い武器となるものですので、しっかりマスターして行きたいところですね。

関連資料URL:

脚注

  1. 個人ブログ。最新2013年度のものについてはこちらから諸々辿れます。
  2. 2013年02月のデブサミ2013では寄稿もしましたが、載せた形態も若干異なるのでこの"ノリ"で他に書くのは今回が初めてです。