2012年1月16日月曜日

2012年1月3日火曜日

Amazon Linuxで使われてるcloud-initをCentOS6で使ってみる

新年あけましておめでとうございます。
年明け最初の更新をこんなに早くするとは自分でも驚きですが、今年もブログをゆるく継続していきたいと思います。

さて、AWSを使用している方はAmazon Linuxに興味を持った事があると思います。
Redhat系のディストリビューションを使用していた方は操作感も近くてスイッチしやすいのではないでしょうか?
私も何度かAmazon Linuxを使用しましたが、その中でcloud-initってとても便利だなと思いました。
cloud-initはもともとUbuntuに搭載されたクラウド環境でのセットアップツールみたいですが、Amazon Linuxではこの機能が標準で移植されております。
個人的にはChefとかよりもチャラく使えるようなイメージでしょうか。。。
AWSで提供されているUbuntuやAmazon Linuxはcloud-initを使って、指定したSSH公開鍵の設置や、セキュリティアップデートなどが行われているようです。
自前でCentOSなどのAMIを作成した経験がある方はSSHの公開鍵を設置するスクリプトを使った事があると思いますが、Amazon Linuxではcloud-init経由でec2-userに公開鍵を設置しているのですね。

『なるほどー、これはCentOSでも使ってみたいですよねー』というネタです。

■AmazonLinuxで使用されているcloud-initのsrpmを取得する

Amazon Linuxで以下のようにコマンドを実行すると/usr/src/srpm/debug/以下にsrpmが保存されるので、これをCentOSでビルドします。
■CentOSでcloud-initのrpmを作成する

ビルドに必要なライブラリをインストールします。
epelをyumのリポジトリに追加している方はPyYAMLとlibyamlもyumでインストールが出来ると思います。
次に事前に転送しておいたcloud-initのsrpmをビルドします。
一部specファイルを以下のように編集しています。
■インストール

作成されたcloud-initのrpmをインストールします。
specファイルを見ると分かりますが、インストールするとec2-userやsudoの設定が追加されます。
■動作確認

インストールしたインスタンスからAMIを作成し、以下のようなUserDataを指定して起動してみました。
無事にec2-userへの公開鍵登録と 指定したパッケージがインストールされていましたよ:)
こんな事するならAmazon Linux使った方が(ryという突っ込みはご勘弁下さい:D

2011年12月25日日曜日

Vyattaを使ってElastic Network Interfaceの動作確認をしてみる

先日、AWSから新しいサービスElastic Network Interfaceがリリースされました。
簡単に言うとAmazon VPC内のインスタンスにNICの二枚差しが可能になるサービスなようです。
今までAWSのインスタンスはeth0しか使えなかったので、これは便利になりそうです。
VPC内のネットワーク構成の幅が大きく広がるようなサービスなので、少しだけ触ってみました。

二枚差しって事はVPC内のルーティングテーブルを使わずにVyattaとかでルーティングしたりNATしたり出来るので、それを試します。
※ちなみにこちらにあるように、今までもNAT Addressingを使ってNATをする事は出来ました。
今回テストをした構成は以下のようなイメージとなります。

Vyattaは@j3tm0t0さんが作成されたAMIを使用させて頂きました。
※ENIはManagement Consoleからも作成可能で、インスタンス起動時/起動後どちらでも追加する事が出来ます。
※インスタンス起動後にChange Source/Dest CheckをDisableにする事をお忘れなく。

■割り当てたローカルIPと同じ設定をVyatta側に設定します
■Vyattaで行うNATの設定を行います
■確認用インスタンスAの起動直後のルーティングテーブルは以下のようになっています
■確認用インスタンスAに以下のようなルーティングを追加してみます
■設定後のルーティングテーブルは以下のようになります
■インスタンスBへの疎通テストを行ってみます
■インスタンスBへの経路を確認するとVyattaを経由している事がわかります
■インスタンスAからインスタスBにアクセスしてNATが動作しているかApacheのアクセスログを見て確認してみました
今回はインスタスAからインスタンスBでNATされていますが、NATせずルーティングのみさせた場合はNetwork ACLsも動作します。
まだ触り始めたばかりですが、ENIはVPCで色々なネットワークを構成出来るのでインフラエンジニア的にはとてもワクワクしますね!

2011年11月30日水曜日

RDSの自動停止、自動起動スクリプト(right_aws)を作る











前回から一ヶ月以上経過していて相変わらずブログの更新が滞り気味ですが、引っ越しなどをしていた訳です。
ちなみに、引越で一番大事にしたポイントはPC作業を行うための机と椅子これに限ります!

3月11日から数日は自宅でお仕事をしていたのですが、ちゃぶ台にPCとか腰が爆発しちゃいます(汗)
家で仕事したいわけじゃないですが、ブログ書いたり勉強したりする時には重宝しますよねー。
こうしてブログを書いている今も机と椅子のありがたさを実感しております。
そんな訳でこれからはブログの更新頻度がアップしないとかしないとか(汗)

今回もAWSネタなのですがRDSを使っているとどうしても一時停止が出来ない事に不便さを感じますよね。
RDSを使ってる方は既に同様の事をしているかと思いますが、私もスナップショットとリストアを組み合わせた停止/起動スクリプトを作ってみました。
パッと思いつく自動化したいポイントは以下のとおりです
  • RDSのスナップショットを作成した上での停止
  • 最新のスナップショットからの起動
  • スナップショットからRDSをリストアした時にセキュリティグループを割り当て
  • スナップショットからRDSをリストアした時にパラーメタグループを割り当て

※cronとかに登録すれば起動中、停止中を判断して自動で起動したり停止したりします。
※AWSSDK for Rubyを使いたかったのですが、RDSに未対応なのでright_awsを使っています


指定するパラーメタグループはMySQLのバージョンと合わせないとエラーになってしまいます。
また、現状ではスナップショットを削除する処理が入っていません。
入れた方が便利かなと思いつつ、どんな条件で削除するか悩み中。
スナップショットが特定の数以上になったら余分な数を消すって感じが一番事故がなさそうか。。。

ただ作っておいてなんですが、
そのうちRDSで停止がサポートされてこんなスクリプト必要なくなるんだろうなー。

2011年10月10日月曜日

Vyattaを使ってAmazon VPC内に独自NAT環境を作る

このブログでクラウド関連の話題というと、ほとんどRackspace Cloudばかりなのですが…
今回のエントリは珍しくAWSをテーマにしてみたいと思います。
Twitterを見ているとVyattaが最近アツく、個人的にも書籍を購入したのでAmazon VPCと連携させたいです。
AWSではVPCネットワークから外部へ接続するためのNATアドレッシングインスタンスが提供されておりますが、こちらをVyattaに置き換えて使ってみるという事です。
今回はNATを構成するだけですが、Vyattaは機能が豊富で様々な可能性をVPCに付け加える事が出来そうです。
ちなみに先日Vyatta社からアナウンスされた6.3のAMIはSubscription Editionということなので、今回はVyatta Core6.1のAMIを使用しています。



[ネットワーク構成]

[VPCの設定]
VPC内にはVyattaを起動する公開サブネットと、Webサーバを起動する非公開サブネットの2つを用意します。

[Vyattaインスタンスを起動]
今回はこちらのAMIを使用し、インスタンス起動後にはSouce/Dest. CheckをDisableとします。
この設定はVyattaインスタンスを起動後にインスタンスを選択して、右クリックのメニューから変更が出来ます。
VPC内でElastic IPを取得してVyattaインスタンスに割り当てる事も忘れずに!
このIPを使用してWebサーバは通信をします。

[ルートテーブル]
Management Console(VPC)のRoute Tableメニューで公開用/非公開用のルートテーブルを設定します。
公開用サブネットはデフォルトルートがインターネットゲートウェイとなり、非公開用はVyattaインスタンスのinstance-idを指定します。

[セキュリティグループ]
Vyattaに割り当てるセキュリティグループは、Webサーバからの必要な通信をブロックしなければ自由に設定可能です。
また、VPCで設定可能なネットワークACLも同じように自由に使えました。

[Vyattaインスタンスの設定]
起動したVyattaインスタンスにSSH接続し以下のような設定を行います。
[Webサーバインスタンスの起動]
それでは動作確認用に適当なインスタンスを非公開用セグメントで起動します。
インスタンス起動後は外部接続の動作確認を行い、Apacheをインストールしました。
[ブラウザから動作確認]
Vyattaに割り当てたElastic IPにポート8080番を指定してアクセスすると以下のようにWebサーバに転送されました。

※おまけ
実はこの構成でVPCのDHCP Options Setを無効にしてDHCPサーバも動かそうとしたのですが、VPCもブロードキャストの通信がサポートされてないという事なので断念しました(汗)

[投入を予定していたDHCP関連の設定]

AWSが提供しているNATアドレッシングインスタンスも便利ですが、Vyattaユーザやルータの設定経験がある方はこのような構成にした方が理解しやすい部分もありそうですね。

[参考資料]

2011年10月2日日曜日

MacからRackspace Cloud Filesに接続出来るFTPクライアント


つい先日会社のノートPCが新しくなりました。
ずっとThinkpadユーザーだったのですが…。ありがとうThinkpad、こんにちはMacBook Air

さて、セットアップ中のMBAにFTP(SCP)クライアントは何を使うべきか?と悩みました。
FTPクライアントといっても最近はクラウドストレージをサポートしていのもあるので、そんなタイプを使いたいです。

やっぱり多いですね!Amazon S3に対応しているものは!
そして、少ないですね!Cloud Filesに対応しているのは!

とはいってもアヒルちゃんことCyberduckはきちんとCloud Filesに対応済みなようですよ!
セットアップ&動作確認も以下のように簡単に出来ちゃいました!

起動したらRackspace Cloud Filesがすぐに見つかります。

こんな感じでAPIユーザーとパスワードを入力してログインです。

はい、無事に接続完了です。

適当なメモをアップロードしてみました。

無事にRackspaceの管理画面にも反映されていますね!


しかし…。
Cloud Filesに対応した、よりよいFTPクライアントがあるといいんだけどなぁ。Interarchyもピンとこなかった。
FTPクライアントという形にとらわれすぎだろうか…。

2011年10月1日土曜日

Cloud Load Balancers使用時にアクセス元IPをログ出力するテスト

こんにちはデース。
さて、以前Twitterで以下のようなつぶやきをしました。※どうやらバッチリ誤字してるようですね☆

こんなん
RackspaceのCloud Load Balancersを使用する場合、いわゆるリバースプロキシ型のロードバランサと同じように、分散先のサーバにはロードバランサのIPがアクセス元となります。
すると、本来のアクセス元IPが分からなくなってしまうのですが、リンクの記事によるとCloud Load BalancersもHTTPのX-Forwarded-Forヘッダに対応しており、こちらを取得する事でアクセス元IPを取得出来ます。
気がむいたのでApacheとnginxを使って動作確認をしてみました。
テスト環境は以下の通りです。
  • OS:CentOS5.6(Cloud Serversのimageから起動したもの)
  • Apache:CentOS標準のものをyumでインストール
  • nginx:EPELをリポジトリに追加してyumでインストール
ApacheはデフォルトだとX-Forwarded-Forヘッダをログに出力する設定にはなっていないので、以下のように設定ファイルを修正しました。 nginxは以下のようにデフォルトでログに出力する設定になっています。 以下の通り無事に確認出来ました。(アクセス元IP=>221.221.221.221 CloudLoadBalancerのIP=>10.183.252.25)
※アクセス元IPは適当な数字に置換しています

■Apacheでの確認 ■nginxでの確認 ログのフォーマットはデフォルトのままで分かりずらいですが、そこはご愛嬌という事で。

2011年9月20日火曜日

httpclient(ruby)によるログインチェックとyammerへの投稿

先日とあるサーバが不調になりました。
死活監視はしていたのですが、それだけでは満足な状況が把握出来なくなってしまったので、指定時間内にログインが完了するかチェックするスクリプトを急遽作ってみました。
早くビールが飲みたかったので状況をいち早くメンバーと共有するため、スピードと動く事を優先したスクリプトになってしまっていたので少しだけ整理しました。
当初はcurlでログインしてmailコマンドでローカルから、警告を出力すれば良いと安易に考えていたのですが…。
テストをするうちに以下のようなポイントが分かりました。
  • 失敗時のみアラート通知し、メールでyammerに投稿したい
  • yammerに投稿する場合、登録しているドメインからのみメール投稿が可能
  • アラートメッセージが同じないようだと、重複投稿としてyammerに拒否される
また、事前にyammerのアカウント設定>通知>メールでの投稿で承認しなくても投稿出来るようにしておきます。








そんな訳で以下がスクリプトです。
httpclient、tmail、tlsmailを使用しているのであらかじめgemでインストールしておいて下さい。
※ruby1.8.7で動作確認しています
実行権限与えてからcronに登録して完了。

2011年9月6日火曜日

第3回 さくらの夕べに参加してきました

こんばんは。
久しぶりの更新になりましたが、以前から参加したかった"さくらの夕べ"についに参加してきました!
田中社長曰く、『もともとはさくらの人と飲んで交流しよう!という事で始まった』という企画らしいので、なんでもっと早く参加しなかったのかと悔しい思いをしました。
しかも今回はさくらのクラウドについての話が聞けたので、とても有意義でした。

会場はこんな感じで、わくわく感満載でしたよ。

田中社長のお話しからも素晴らしいサービスだと痛感したので触ってみたいです。

懇親会はこんな感じでしたよ(私がラスト15分くらいまでぼっちだったのは内緒です)


ちなみにお土産にこんなんもらったけど、これが日本酒だったら尚よし。

私のメモにはこんな事が残っておりました。
  • クラウドEXPO出展から一年、明日Betaリリースされる
  • 何の変哲もないIaaS型クラウドを圧倒的なコストパフォーマンスで提供する
    • 開発者思考のシンプルクラウド
  • 実現したもの
    • 性能
    • 安定性
    • 低コスト
  • シンプルクラウドとは?
    • 性能はVPSのものよりも良いものを使用している
    • 拡張性があるネットワーク
  • 明朗会計の料金体系(使いたい分だけ払える)
  • 運用を楽にする機能やAPI(APIが標準実装=コンパネで出来る事はAPIで全部出来る)
  • デモ
    • AWSのAZに当たるものがゾーンとして提供されてる
    • ISOイメージからサーバを構築する事も出来る
    • AMIにあたるテンプレート機能がある
    • ハードディスクからスナップショットが作成出来る
    • 起動時に管理パスワードが指定出来る
    • SSH公開鍵を張り付けて使う事も出来る
    • インターネットに接続しないサーバも作成出来る
    • アイコン指定なども出来る⇒これは地味に良い
    • コンソール接続機能を使用する事が出来る(遅延がないぶんRackspaceよりさくさく)
    • ローカルネットワーク用みたいなスイッチ機能(ブリッジを作成してゾーンをまたいで通信出来る)
    • タグ管理機能もあるみたい
  • 感想
    • これは触ってみたいwwww
    • 正式版の価格見てみて個人の開発環境とか移行しよー。
  • 質問
    • ストレージはアタッチするとどう管理されるのか
      • これは全て完全にローカルのディスクの様に見れます
    • 仮想ディスクの付け替えとか出来るのか?
      • 出来ます
    • IPv6対応は?
      • Betaでは対応されません(IPv4のみ)
      • 対応予定です。
    • サーバの課金はどこから始まるのか
      • Betaは無料
    • HyperVはなに使ってるの?
      • KVMです
    • 仮想スイッチの実装は?
      • Vyattaではなく独自です
      • 後ろではタグVLANを使っています
      • ローカルIPの設定は自分でやる
    • 仮想マシンの高可用性やSLAは?
      • ありません(少なくとも現状はないみたい)
    • APIは?
      • Betaの公開時点ではまだありません
      • もちろん公開予定みたい
      • コンソールで出来てAPIで出来ない事はないみたい
    • メンテナンス時とかのライブマイグレーション機能とかはありますか?
      • 作成中です
というのが残ってました。
最後にサーバテンプレート使用出来るDVDイメージの一覧を激写したものを・・・


以上となります。
さくらのVPSのノウハウも生かされているそうなので、期待大ですね!
規約的にBeta時点で触れるか分かりませんが、正式公開されたら触る事は間違いなさそうです。

2011年8月7日日曜日

hbstudy × qpstudy × まっちゃ445 合同勉強会に参加してきました

本日はhbstudy × qpstudy × まっちゃ445 合同勉強会に参加して来ました。
というわけで勉強会の模様をブログに掲載しようと思います★
勉強会はブログを書くまで終わりません!というのを聞いた事がありますよ!

勉強会の会場はIIJさんが提供して下さっているとかで神田の三井ビルディングに行きました。
IIJさんGJですね!!会場として施設が整ってて快適でした。

合同勉強会の張り紙です。期待に胸が膨らみますね!

会場の雰囲気はこんな感じですよ
広い!奇麗!無線LAN早くて快適!

総勢100名くらい参加していたのですが、全員自己紹介タイムがあって凄かった!
私は声が小さい、噛み噛みでぐだぐだでしたよw
学生さんが多くて、なぜかGentooユーザーも多いとかww

hbstudyからは@matsuuさんのGentoo Linuxについてのお話!
新人教育に最適だという事で私がOJTしてる新人に触らせてみようかなw

休憩中にはスイーツなんて出ちゃって良いですね!プリン美味しかったっす★

qpstudyはリーダー不在という事態でも楽しいスタッフの方からLTを聞けてよかったす!
ザビたんとか何度聞いてもツボですねw

最後はまっちゃ445から緊急対策本部について!
まっちゃ445は参加した事がなかったのですが、今まで参加した勉強会とはまた違った内容を聞く事が出来て、とても刺激を受ける事が出来ました。
※たしかUstreamは停止していたようなので、私も写真とかは掲載しません。

最後はビアバッシュ形式の懇親会!
懇親会でのLTでもとても勉強になるお話しを聞く事が出来ました★

エンジニアたるもの日記を書きなさいというお話しがありましたが、ブログの中で見習っていきたいです。
LTも最近してないし、今回もビビって他の方と交流出来なかったので次回は克服せねば…

スタッフの皆様、お疲れ様でした!とっても楽しかったです★

2011年7月31日日曜日

qpstudy07 本当にあった怖い話 ~絶対に笑えないサーバ24時~に参加してきた

という夢を見た。。。

私は何も、誰も見てないし、何も覚えてない。
 
仮に覚えていても、身の安全の為にブログに書く事は出来ないw

2011年7月29日金曜日

RackspaceのサーバをChef(knife-rackspace)から使ってみる

なんか頻繁に更新とかするとちょっと不思議な感じがしますね。
昨日書いたブログ1周年の感想はともかく、今回もRackspaceの作業記録ネタです。
今回の主役となるChefや、Puppetというソフトウェアは以前から聞いてましたが、正直あまりさわれていませんでした。

Chefについては色々な方が情報提供しているので、ここではChefを使ってRackspaceのCloudServersを操作するログだけ記録しておこうと思います。
なんかChefを使ってAWSって話は誰かが?(汗)書くようです。
ちなみにChef0.10.0からknife-rackspaceというプラグインを使用する事になったみたいなので忘れずに入れて下さいね。

Chefってなんぞ!?という方は以下のリンクが参考になるのではないでしょうか。
ちなみに私のChefサーバはOpscodeのSaaSを使用させて頂いております。
ネットワーク構成を本番に近い形にも出来るし、何しろChefサーバを運用しなくて良いのは素敵ですもんね。
※アナタそういうサーバ運用するのがお仕事でしょっ!ていう突っ込みは割愛して下さいね(笑)

以下、作業記録です。

1)knife-rackspaceのインストール

Chefとknife-rackspaceをMacBookにインストールするのは簡単でしたよ。

2)Cloud Serversをknifeコマンドで操作する為にAPIの設定

APIの情報を以下のように設定します。

3)Rackspaceへの接続確認

使用出来るサーバイメージをリストで表示します
指定可能なサーバのスペックの一覧表示します

4)起動確認=>レシピ適用=>削除

Cloud Serversのサーバを起動し、apache2のレシピを適用します
起動したサーバは一覧で表示出来ます
削除もknifeコマンドで実行出来ます
以上のように管理画面にログインする事なくknifeコマンドから操作出来ます。
Chefに慣れた人にとっては良い運用の選択肢になりそうです。
以前このブログで書いたcloudlbcloudsrversとかと組み合わせると、さらに面白そう!

Rackspaceのロードバランサは外部のサーバも分散先に登録出来ます。
Chef経由でバランシング対象のRackspaceのサーバとEC2インスタンスに同じレシピを適用するなんて事も出来ますね。

あー、Rackspaceのデータセンターが日本にも出来ないかなー。出来ないだろなー。
Rackspaceを使って動く素敵なサービスは日本でもたくさん使われてるのになー。

2011年7月27日水曜日

ブログはじめて一周年を迎えた感想

7月前半でどうやらブログが1周年になった事に気付きました。
かなり思いつきで初めたブログなので振り返る事もありませんでしたが、せめて感想を残そうかと。
更新頻度は少ないけど、個人ブログを書く事についてネガティブに思った事はないから良かっ事だけのまとめ。
  1. 自分で調べた事の保存先として結構良い
    • 誰かが見る可能性があるので、それなりに奇麗にまとめる→自分の理解につながる
    • 以前は自分だけのWikiとか作ってみたけど、まったく更新しなくなってしまった
  2. ブログを書かなきゃ!ネタないかな?って気持ちから新しい技術に触れるきっかけになる事もある
  3. アクセス統計とかを見てると、こういうのがみんな興味あるのかって面白かったり
  4. 何かにのっかるのではなくゼロからブログやるって事自体が面白かった
  5. 自分個人だけで更新する事の楽しみとかもあったかも
意見を発する場とよりも自分が作業したログをまとめる場所としてやっているので、こんな感じです。
普段いろいろなブログ記事に助けられているので、感謝の気持ちはもちろんいっぱいです。
ただ、私がブログをするのは、まず自分の為、見てくれた人の参考になるかどうかは副産物みたいなもの。
一年後にこのブログがないかもしれないし、その時は思う事も変わってるでしょう。
最初から大風呂敷なんて広げない。それだけでやる理由としては十分ありそうなので、継続しよう。

※お酒を飲みながら書いてるもんですから、いろいろな部分をご容赦下さいw

2011年7月24日日曜日

Rackspace:Cloud Load BalancersをRubyからさわってみる

こんばんわ。
本日からアナログ放送が終了して、家でテレビが見れなくなってしまいました。
しかし、珍しく一ヶ月以内に更新が出来きたので今日は気分が良いです。

前回のブログでは珍しくAWSでしたが、今回は再びRackspaceネタ。
以前書いた、Cloud Load BalancersではCloud Serversと同様にPythonとRubyのインターフェースが提供されています。
Cloud Serversの時と同様にREADMEを参考に少しだけ使ってみました。
※ほとんどまんまですw

インストールはgemのソースとしてGithubが登録されていればとても簡単です。
$ sudo gem sources -a http://gems.github.com
$ sudo gem install cloudlb
Fetching: typhoeus-0.2.4.gem (100%)
Building native extensions.  This could take a while...
Fetching: cloudlb-0.0.1.gem (100%)
Successfully installed typhoeus-0.2.4
Successfully installed cloudlb-0.0.1
2 gems installed
Installing ri documentation for typhoeus-0.2.4...
Installing ri documentation for cloudlb-0.0.1...
Installing RDoc documentation for typhoeus-0.2.4...
Installing RDoc documentation for cloudlb-0.0.1...

動作確認した環境はMac OS X (not Lion)にインストールされたRuby 1.8.7です。
irbを使用して作業は行い、テスト用に起動したサーバのIPアドレスは以下の通りです。
  • 50.57.116.195
  • 50.57.116.80
さて、それでは確認してみます。
$ irb
# cloudlbを読み込みます
> require 'rubygems'
> require 'cloudlb'

# Rackspaceへの認証とリージョンの選択をします
> lb = CloudLB::Connection.new(:username => "okochang", :api_key => "*****************", :region => :ord)

# LBに追加するWebサーバ用にハッシュの配列を作成します
> node01 = [{ :address => "50.57.116.195", :port => "80", :condition => "ENABLED" }]

# LBを作成して先ほど作成したノードを作ります
> newlb = lb.create_load_balancer( :name => "newlb", :protocol => "HTTP", :nodes => node01, :algoristhm => "LEAST_CONNECTIONS", :virtual_ip_type => "PUBLIC" )

# LBのリストを参照して確認を行います(きちんとIPv6用のアドレスも割り当てられてるのも分かります)
> lb.list_load_balancers
=> [{:status=>"ACTIVE", :created=>{:time=>"2011-07-24T12:47:23Z"}, :port=>80, :virtualIps=>[{:type=>"PUBLIC", :address=>"184.106.100.221", :ipVersion=>"IPV4", :id=>168}, {:type=>"PUBLIC", :address=>"2001:4801:7901:0000:d4dc:6dbb:0000:0001", :ipVersion=>"IPV6", :id=>9000572}], :protocol=>"HTTP", :name=>"newlb", :id=>13924, :algorithm=>"RANDOM", :updated=>{:time=>"2011-07-24T12:48:12Z"}}]

# 先ほど出力されたIDを指定して、LBを選択します
> balancer = lb.get_load_balancer(13924)

# LBのバランシングアルゴリズムを変更します
> balancer.algorithm="ROUND_ROBIN"
=> "ROUND_ROBIN"

# 新しいWebサーバをLBのノードとして追加します
> node02 = balancer.create_node(:address => "50.57.116.80", :port => "80")

# テストが終わったのでLBを削除します
> balancer.destroy!
=> true
CloudServers同様に、API経由でもなかなか簡単に操作出来るのですね。
RackspaceのGithubのリポジトリを眺めていると、どうやら先日ベータリリースされたCloud DNSのPythonインターフェースは既に存在してるみたい。
Ruby版がリリースされるのが楽しみです。

2011年7月20日水曜日

EBSボリュームのスナップショットを自動作成する(right_aws)

相変わらず、久しぶりの更新となりました。

先日、AWSからRuby用のSDKがリリースされて、喜び半分right_awsを触りだしたばかりの私はアイタタという気持ちが正直なところです。
今回のエントリは"Ruby用のaws-sdkについて"と言いたいところですが、right_awsを使用したスクリプトについてです。

AWSのEBSからスナップショット取得するのですが、個人的にジョブが完了したらメールで通知して欲しい人です。
@dateofrokさんが公開されているこちらのブログを参考に、メール通知機能を追加しています。

正直、Rubyなんて触った事ないし、プログラミングもした事ないので変なところは多々あると思います。
公開する事で誰かがより良いものを作り、回り回って自分に何かの形で返ってくると良いな〜なんて思ってるわけです。

◆EBSボリュームからスナップショットを作成するスクリプト



作っていて感じた今後の改善点は以下のような感じ。
  • 複数ボリュームのスナップショット対応
  • aws-sdkを使って書き直したい
  • 多分もっと良い感じにかけるんだろう

2011年5月27日金曜日

サイバーエージェントxクックパッド合同勉強会に参加しました

5月もそろそろ終わりに近づきましたが、今月は全くブログを更新してないのかorz
昨日はせっかく勉強会に参加したので、ブログに残しておこうと思います。

参加したのはサイバーエージェントさんと、クックパッドさんの合同勉強会。
最近の勉強会は気付いたらすぐに定員が埋まってしまうので、参加するのも大変(汗)
今回の勉強会も登録した時点では補欠でしたが参加枠が拡大されて出席出来ました。
とても参加したかった勉強会だったので、ほんとに良かったです。

場所はクックパッドさんのオフィスがある白金台!
シロガネーゼとやらは、どなたなのか分かりませんでしたが静かで、お洒落なとこでした。
『なんか大衆居酒屋とかねー街なんだな!』というのが第一印象です。
自分が住むには住みずらそうですが、家賃払えないので、不要な心配ですね。

クックパッドさんのオフィスはとても奇麗でした!
写真をあまり撮れてないのが非常に残念><ですが、会場は以下のような感じ。
しかも懇親会でお料理が出るなんて、とてもユニークで美味しいお勉強会ですね★
最初に【プレゼンの時はプレゼンに集中!食べるときは食べる事に集中!】というありがたいお言葉を頂きました。


以下はメモと感想ですが、みなさんSlideShareとかにアップしてくれるらしいです。
私のメモは適当すぎるので参考程度に…資料がUPされたらリンクをつけときたいな。

■一人目はサイバーエージェントの坂本さん
OpensStackを検証してみたというお話です。
AWSに例えるとってところもあり分かりやすくて、ありがたかったです。

AWSとの比較
  • EC2=>Nova
  • S3=>Glance(OSイメージ登録)、Swift(ストレージ)
Nova
  • CloudControllerとComputenodeに分かれる
  • Conputenode内にInstanceが起動される
  • CloudControolerとCnputenodのプロセスのお話
  • インスタンスのネットワーク構成を3種類から選べる
管理方法
  • novaコマンド
  • ecuca2oolsコマンド
注意点
  • 1プロジェクトで作成出来る上限は10インスタンスまで※変更可能
  •  ライブマイグレーションはは共有ディスクのみサポート
  • セキュリティ設定はiptablesで実装している
気付いたこととか
  • ElasticFoxでも管理出来る
  • Ubuntuだとパッケージ化されているからインストールが簡単
  • シンプルで分かりやすい
  • AWS知っている人はとっつきやすそう
苦労話し
  • インスタンスメタデータをどこに取りに行けのか分からない
  • ドキュメントは英語
  • 開発中なのでドキュメントは微妙
まとめ
  • 発展途上だけど使える
  • 開発が盛んだから今後にも期待出来る
  • GUIは本気出してくるかわからない
  • ハイブリッドクラウドが良いよね
【個人感想】
プライベートクラウドはH/Wの面倒をみたりと運用は大変そうだけど、自由度が高いというのは良い点みたいです。
物理H/Wは一台あれば試せるらしいので、かなり興味が湧きました。
お仕事ではパブリッククラウドばかりですが、いわゆるクラウドのバックエンドがどのように動くかという興味を満たしてくれそうな気がします。
あんな事や、こんな事も、楽しそう!!

■二人目はサイバーエージェント森野さん
AmebaPicoの裏側の技術とAWSの利用についてのお話でした。
Picoはピグの海外版でFacebookアプリもあるらしいっす。

サーバー構成
  • サーバーはすべてAWSのクラウドを利用している(個人的にはこの時点で涎モノ)
    • Cloudfront(キャッシュOKなもの)
    • EC2(汎用的なサーバーやその他)
    • S3(静的データのストレージ、ログの保存)
    • Elastic Map Reduce(S3のログ解析→結果はS3に保存)
    • EBS(バックアップや揮発性があっては困るもの)
    • 開発サーバとか本番サーバとかでインスタンスタイプ変更
    • MongoDB(3台構成の6シャドーで分散)
運用してみて
  • 手軽(必要なときに必要な時だけ)
  • データセンターにいく必要がない(海外ならなおさら)
  • インフラエンジニアがいなくてもなんとかやれた
  • たまに落ちる(頻度:現在60インスタンスで2ヶ月に1インスタンスくらいの割り合い)
  • 4週間のうちに4個落ちた事もあった(告知あり)
  •  落ちると応答がなくなる(特定ポートのみの場合や全体的に落ちる場合も)
  • 落ちた場合はリブートする時もあるがリブートしてもダメな場合もある
  • MongoDBのコネクションプールが枯渇した(I/Oボトルネック)
    • ⇒I/Oパフォーマンス高いもの+シャドーを増やした
  • MongoDBのバランシングの挙動に偏りがある
  • MongoDBの設定情報が反映されない事もあった
  • MongoDBの問題の解決とノウハウの蓄積をしたい
【個人感想】
やっぱりAWSはただのレンタルサーバとして使うのは持ったいなさすぎますね。
AWS内の色々なサービスを組み合わせて面白い使い方をして最高の力を発揮しますね。
そのためにはAWSの色々な使い方を妄想したり検証したり、使う準備も必要ですね。
syslogサーバのログデータとかもs3fs使ってs3とかに保存するのって運用したらどうなんだろう。
インフラエンジニアがいらないってなってしまうと悲しいけど…(笑)
どんなエンジニアでも色々な技術を吸収する事が大事になってきていそうですね。
レイヤーとかで分けるのではなく、いろいろ広く勉強しなきゃな〜。

■三人目はクックパッド成田さん
毎日の料理を楽しくする画像配信のしくみのお話
ちなみに私はここら辺から後ろからの、とても美味しそうな匂いで集中力が…が…が…w

今まで
  • 昔は画像をアップしたらいくつかのパターンの画像サイズ(サムネイル)を用意した
  • 現状の写真の大きさで本当に良いのか?まだまだ検討の余地がある
  • よりより写真にしたい
  • iPhoneアプリとかにも、きちんと適切をしたい
  • 画像配信するアプリケーションはサムネイル画像の運用が悩み
  • 画像保存先としてNFSはやめたい⇒AWSにいくならS3つかいたい
変更後(開発したTOFU導入後)
  • 配信は一枚の画像をS3にアップして配信時にオンデマンドの画像サイズで配信
  • TOFUはApacheモジュールとなり画像変換には(本当は速い)ImageMagickを使う
  • Imlib2を使わなかった理由は画像の質が落ちるから
  • CookPadアプリの写真は順次リプレース中
  • 効率が上がり開発者のモチベーションがUP、美味しい料理の写真を届けられるように
  • akamai⇒ELB⇒tofu複数台(c1.xlarge)⇒S3
  • S3は夢のストレージではない。S3の特定のAPIだけが障害発生したりもした。
  • S3はデータが消える事はなさそうだけど、データにアクセスできなくなる事はある
Akamai or Cloudfront
  • S3専用だったけど、EC2をオリジンに指定(Custom origin)が使えるようになった
  • just-ping.com(世界中からpingをうつサービス)を使うとakamai速い
  • Akamaiはあまりキャッシュヒット率が高くないから以前はさらにVarnishを配下に使ってもみた
    • Varnishはメモリを使うからTOFUインスタンスを増やしても良さそう
最後に
  • 写真は料理を美味しくみせる為に大事な事!!!
【個人感想】
とにかく料理を美味しくみせる為にという事を大事にしたお話しで素敵でした。
どうありたいかのゴールを大事にしてその為に何をするかって大事でっすね。
写真は美味しそうだし、後ろから美味しそうな匂いもするし、早くご飯食べたい★

■最後はクックパッド菅原さん
AWS移行に向けたクックパッドの取り組み+αのお話
と、とにかくお腹空きました!お話も勉強になる素敵な会ですよ!

AWSのサーバネットワーク構成
  • iDCだと3層構成から⇒EC2だと1層構成になるからセキュリティをしっかりと確保
  • セキュリティグループは以下を組み合わせるみたい
    • Basic(基本的なものhttpsやpingや監視ポート)
    • 各ロールのセキュリティグループ(DB用やアプリサーバ用や)
    • 基本的にはIPからは許可しない事(ローカルIPだけ許可しても他の会社がいたりするから)
    • 全てのサーバでiptablesは有効⇒人的ミスを防ぐため
    • 内部DNSはPowerDNSで使う(E2のNAMEタグから引ける)
    • resolv.confは定期的に更新するように
  • AMIはCentOS5.5をクリーンインストール(EBSベース)
  • 64bitに統一する予定
    • 現在32bitがあるのはmicroインスタンスがなかった時代の残り(お金の事が原因とかとか)
  • ベースとなるAMIから各ロールのAMIを作成する
  • システム管理ツールのChefの導入も進めてる
  • システムネットワークの生存監視(Nagios)
    • Nagiosを使ったAMIからの復旧(ヘルスチェック失敗のタイミングで)
  • サーバの性能情報(munin)
  • EIP,HeartBeatを使った冗長構成も進めている
    • HearBeatの仮想IPの代わりにEIPを使う
分散DNS
  • resolve.confは内容がキャッシュされるのでApacheの再起動が必要になったりする
  • cronで監視だとダウンタイムが分単位になってしまう
  • 各インスタンスでDNSを起動して分散DNSを実現(デモをしてくれました)
【個人感想】
AWSでの運用はもっと考える余地がありそうだと思いました。
ノウハウもまだまだ集めたいし、現状に満足してはいけませんね。
もうお腹がぐーぐーなって死にたい!

■LT
Varnishのお話しやtmpfsのお話しや、とあるクラウドwのお話しでした。
Varnish勉強会は面白そうですね。懇親会の家が建つお話も素敵でしたw
Vanishで勉強会でお家の建て方を学びたい★

■懇親会
本当に美味しくて温かい料理は素敵ですね!
写真を全然撮ってない昨日の自分バカッ!

■最後に
今回の勉強は内容も充実していて、ご飯も充実して身も心もお腹いっぱいになりました★
関係者の方々ごちそうさまでしたー!

2011年4月17日日曜日

Rackspace Cloud導入記その9(LoadBalancerを使う)

相変わらずRackspaceは放置状態なのですが、久しぶりにログインしてみました。
気付いたらRackspaceでもロードバランサが使えるようになってるんですね。
(どうやら去年から使えたみたいですorz)
せっかくログインもしたので、動作確認程度に使ってみました。

RackspaceにログインするとこのようにLoad Balancersというものが追加されています。
ロードバランサの配下には1〜25台のサーバを登録する事が出来るようです。
そしてロードバランサの配下にはCloudServersで起動したものの他に、外部のサーバも登録可能です。
※外部のサーバーを登録出来るのって結構珍しい気がします
※ロードバランサに割り当てるVIPはグローバルでもローカルでも良いので、内部通信用の負荷分散も出来そうです。

  1. Create Load Balancerをクリックして作成開始

  2. 以下のように名前、プロトコル、VIPタイプ(グローバルもしくはローカル)を決定。
    ※分散のアルゴリズムはランダム、ラウンドロビン(重み付け可)、最小コネクション(重み付け可)と豊富です。
    ※重み付けはCloudServersのスペックを見てくれてくれそうな感じです。

  3. リージョンを決定し、登録したいサーバーを選択したらCreate Load Balancerをクリックして完了です
    ※リージリョンはORDがワシントン、DFWがテキサスです。
    ※外部のサーバーを登録したい場合は "Add External Node"をクリックすると登録出来ます。

  4. 作成後はロードバランサを選択すると詳細が確認出来ます。

  5. VIPにアクセスすると無事に負荷分散出来る事も確認しました。

  6. 最後にロードバランサの価格をまとめておきます
    起動料金
     $0.015/時間
    コネクション料金
     $0.015/100同時コネクション
    転送料金(out)
     $0.18/GB
    転送料金(in)
     $0.08/GB

外部のサーバを登録出来るところは非常に珍しいですね。
本番環境へ影響を与える事なく導入出来そうなので、試してみてはいかがでしょう?

2011年3月31日木曜日

Rails3環境用にSQLite3のRPMを作成する

いやー、最近のこのブログの技術ネタといったら、
  • このRPM作った
  • あのRPM作った
  • こんなRPM作った
と、ただのRPM作成ログの置き場となってますが、今回もRPMを作成したログです(汗)
すんません…orz
作成したきっかけは達人出版会さんから出版されている、”はじめる!Rails3”です。
こちらはRails3を始めるには良さそうな電子書籍で、Rails3の使い方を分かりやすく説明しています。
Linuxへの導入はUbuntu中心で書かれていますが、CentOSでも問題ないだろうと思ってました。

…しかし、SQLite3のインストール手順においてこんな記載がありました。
『Linux(CentOS 5)の場合は以下のコマンドを 実行します。』
残念な事に、この手順では”gem install sqlite3”が実行出来なかった訳です。
理由はCentOS5が使用するsqlite3のバージョンに古い事であり、『じゃあRPM作るか』ってなりますよね〜。

※今回はビルド専用ユーザーを作成していますが、SQLiteはrootでrpmbuildをするとエラーが出てしまいます

  • RPMBuildに必要なパッケージをインストール
  • ビルド用ユーザoko_changを追加
  • SRPMをダウンロードしてインストール
  • RPMビルドの準備
  • ビルド実行

以上で無事に”gem install sqlite3”が実行出来ました。
ちなみに素直にUbuntuを使えば、当然この手順は必要ありません。

2011年3月25日金曜日

hbstudy#21に参加してきました

皆さん同じような状況だとは思いますが、私もここ数日はさすがに普段よりもバタバタしておりました。
個人的な事ですが、茨城県の実家では窓が割れたり壁にヒビが入る程度でした。
大きな被害は無く、連絡がついたときはとても安心しました。
まだまだ油断出来ない状況ですが、あまり暗くなりすぎないようにしたいと思ってます。

さて、今回のhbstudyは最近のドタバタの関係で参加を迷いましたが、AWS関連の内容という事で参加してきました!
今回は参加した時のメモをのせておきます。
※もしかしたら間違った記憶もあるかも
※このブログではあまり書いていませんがユーザーとしてAWSにお世話になってます

【今回のhbstudyの参加費は東北関東大震災の義援金として寄付されるそうです】

  • 勉強会の形式
    • 事前に質問を集めてそれに荒木さんが可能な範囲で回答するという形式
  • そんなわけで事前質問がありました
    • 質問はギリギリで増えるという傾向だったみたいですねw
    • 個人的にはAWS導入を検討されている方って急いでる方が多い印象ですw
  • 質問とメモ
    • Amazon饅頭は販売しないの?
      • 言っておきますw
    • 海外のUGとの交流
      • http://aws.amazon.com/usergroups/とかで宣言したら良さそう
    • AMIたんってどうなりました?
      • サーバー擬人化友の会に言ってみましたよw
    • AWS触った事無い人ってどれくらいいますか?
      • 会場の半分いかない程度に見えました
    • AWSって?
      •  EC2とS3以外にもいろいろなサービスがあるよ
      • インフラエンジニアが楽出来るサービス
    • フィットするサービス
      • 成長度合いの予測が難しいサービス
      • ピーク時も対応出来て、無駄な投資をしたくないもの
      • 2週間でやめるって事が出来るので開発とかテストに向く
      • 特定の日しか使用されないサービス
      • ソーシャルアプリのホスティング
      • 分散処理系
      • ハイパフォーマンスコンピューティング(東京リージョンではまだ開始していない)
    • あたらしいAWSのサービス
      • CloudFormation→AWSのサービスを組み合わせて使う事が出来る
    • AWSを始めるときに使えるチュートリアルは?
      • Amazon Web Servicesガイドブック
      • AWSエバンジェリストのBlog
      • JAWS-UG
    • 各リージョンのキャパ(去年あたりにどこかのリージョンでいっぱいになりませんでした?)
      • 答えられませんw
      • 同一のAZ内でも随時増やしている
      • リザーブドインスタンスは起動の保証をします
    • 東京リージョンのパフォーマンス
      • やっぱり速いです
    • 東京リージョンはいつから、どれくらいの人で構築したんですか?
      • かかわった人はたくさん
      •  構築はいつからだったかは知らない
      • サーバ台数とかは言えません
    • データセンタのスペック
      • くわしい事は言えません
    • Cluster GPUはいつ日本に来る?
      • ユーザーが増えればサービス展開される
    • 絶対競合に負けない自信
      • エコシステムを重視
      • 最大公約数に集中してサービス展開(使いたい人が多いかどうか)
      • 足りないところには外部におまかせ→AWS Solution Provider
    • AWSの利用料金を取得するAPI
      •  ありません
      • Management Consoleで一日前の情報は分かる
      • Cloudworksで概算の計算はしていますよ(AWSの保証はなし)
    • AutoScalingで一時間以内で頻繁にstartとshutdownが繰り返すと料金は?
      • startされたら最低料金の一時間分はとられる
    • Route53のキャッシュポイズニングは?
      • キャッシュサーバの機能はないから大丈夫
    • Windowsサーバを立ち上げた場合のオーディオデバイス
      • うまくいきそうなやり方はあるみたいだけど未確認
      • 出来たら共有して下さい
    • Xenのカスタマイズはどれくらい?
      • 詳しいことはいえないみたい
      • Over-Provisioningはしていない
    •  豪快な使い方の事例のネタ
      • お客さんが公開しないと、こちらからは公開できない
      • インターネットの全トラフィックの19%がEC2に関係とかとか
      • 日本のお客さんが紹介されてました
    • ELBでSSL使いたいときに証明書はどれだけ必要?
      • 技術的には一つ
      • SSL証明書の規約次第
    •  EBSのスナップショットのしくみ
      • いえません
      • 中の人になってw
    •  IOPSってもっと出ないか
      • EBSを使ってRAID0を組んでみるとか
    •  手持ちのVMをコピーして使えないか
      • やっているベンダーさんがあるみたい
      • VM import/exportがありますよー(Windowsの一部バージョンのみ)
    • どうやってAWSに入れる?
      • 求人しているよ!
      • 中の人を知っていれば連絡を!
      •  http://aws.amazon.com/jp/careers/
      • 中の人も日本人同士は日本語で話しているよ
    • 素人向けのコンソールない?
      • Cloudworksを使ってみたら?
    • iPhoneから操作したい
      • directEC2があります
    • 定額化プラン
      • CloudPackさんがやってます
    • GmailでSpam判定される
      • 逆引き申請をしましょう
      • AmazonSESを使いましょう
    • SES統計データをブラウザでみたい
      • APIとかは提供されてるのでビジネスチャンス!
    • リージョン間移行を簡単にしたい
      • Cloudworksで出来ますよ(Linuxのみとかの制限があります)
    • 新サービスの要望
      • たくさんあります。伝えときます。
    • DC見学
      • 出来ませんw
    • AWSの出社時間と退社時間
      • 9時台くらいに出金して8時くらいに買えるようにしている
    • AmazonLinuxはCentOSベース?
      • CentOSベースじゃないRHEL互換なだけ
    • SESのキャリアブロック対策
      • してないようです
      • 運用ノウハウは必要みたい
    • SESの送信限界数を増やす条件
      • 条件は公開されていなさそう
      • Limit解除の申請フォームがあるよ

途中で力つきましたが残ってるメモはこんな感じでした。

2011年2月12日土曜日

qpstudy05に参加してきました!

今日はqpstudyに参加してきました。
明日になると、書かない気がするので本日中に感想を書きたいと思います。
勉強会の参加はもちろんですがブログまで書く事が今年の目標です。
参加する前に以下の2点を疑問に思っていましたので、確かめたいなと思ってました。

  1. 本編より懇親会の方が参加希望人数が多い気がするけど、途中から人が増えるの?
  2. 勉強会の懇親会はやっぱり出たほうが良いのか?
さっそく第1点目、これは正直分かりませんでしたw
懇親会から来た人はいないように感じましたけど、正確なところはどうだったんだろう。
qpstudyの雰囲気なら懇親会だけ来るって人もいそうだけどなーw

続いて第2点目、これは完全に出た方が良いと思います。
qpstudyの場合はビアバッシュ形式でLT大会が行われています。
ネタ率も高いですが、LTを聞いていてとても刺激を受けました。
何よりも皆さん、我先にと飛び込みLTしていたので、ああいう積極性は見習いたい!
何か資料作らないとな…orz

<その他の感想>
  • 他のディストリビューション使いたいと思うきっかけ
    仕事ではCentOSを使う事が多いですが、他のディストリビューションも触りたい。
    Ubuntuとかはデスクトップ用で使ったりするけど、もう少しキチンと勉強してみたいかも。
    Gentooは…触ってみたい気持ちはありますけどね…(汗)
  • Ustream!
    とてもお世話になっているけど、自分で配信したりすると面白いのかも。
    やっぱりこういうのは一度自分でやってみないとね。
    H/W障害の時とかにUstreamで配信してすぐ状況を共有する事も出来そうですね。
    ステータスランプは写真で良いけど異音とかは伝える事が難しいので…。
  • ザビたん
    あんなに盛り上がるだなんてwさすがqpstudy!
    ちょうどZabbixの検証をしているけど、監視対象一括登録ってかなり気になる。
    まさか懇親会でも登場するとは思わなかったw
  • 自宅鯖
    自宅にサーバはあるけど、自宅にラックとか想像も出来ませんw
    でも引っ越ししたらルーターとか変えたいなー。
    やっぱり仕事で使い慣れてるYAMAHAのルーターかな?
    他のお話でもありましたけど、奥さんの承認って大事なんですねw
しかし、初心者枠もしっかりと埋まっていましたね。
1年目、2年目、はたまた学生さんが勉強会に参加するって情熱が凄いなー。
勉強会が参加しやすいイメージになっているなら、とても素晴らしい事です。

qpstudyのスタッフの方々お疲れ様でした!ありがとうございます!
ニフティさん、まじニフティ!