c9日記 -カタヤマンがプログラマチックに今日もコードアシスト

2012-04-01

■「AWS EMS」

[4/1 7:00 シアトル時間]

本日はみなさんに、AWSに新しいサービスが加えられた事をお知らせします。

AWS EMS(Electric Muscle Stimulation)は、クラウド型ダイエットを提唱するAWS*1が提供する、まったく新しいダイエットソリューションです。

従来型のダイエットには、次のような問題点がありました。

高価な初期費用（トレーニング機器やサプリメント）
トレーニング機器の設置は困難　減らす場合は粗大ゴミ
体重のピークが読めない
体重を増やすのは容易減らすのは困難
プロテインは多めに買いがち
体重を減らすことではなく、ダイエットが目的になりがち

EMSはこのような問題を解決するために、AWSが初めて提供する人体装着型のソリューションです。

特徴

Electric Muscle Stimulationとは、電気的な刺激で筋肉を動かす事を指します。

EMSから発する電流により、装着した部位の筋肉の運動神経に刺激を与えることで、筋肉運動をさせることができます。

ハードな運動やハードの購入を行わずに、パソコンに座ってクラウド上にシステムを構築しながら、筋肉を鍛えることが可能になります。

使用方法

アカウント作成後にウェイトマネジメントコンソールから申し込むと、お客様の手元にEMS クライアントが配送されます。

あとは気になる部位に装着し、スイッチを入れるだけです。（インターネット接続は必要です）

他のAWSサービスとの連携

食事面のコントロールをしたい場合は、EC2(Elastic Calorie Calculator)を使用することで、どのような食材でもカロリー計算を瞬時に行うことができます。

Calorie Watchと連動させて、グラフィカルに数値を表示することも可能です（記録間隔は1分または5分）。

より効率的に、そして安全にダイエットの記録を保管したい場合は、RDS(Recording Diet Service)の利用を推奨します。

費用

初期費用はありません。すべて重量課金となります。

体重の減少量	料金
最初の1Kgまで	$0 per 100g
5Kgまで	$10 per 100g
10Kgまで	$8 per 100g
20Kgまで	$5 per 100g
300Kgまで	$2 per 100g
300Kg以上	医者にお問い合わせください

セキュリティ

お客様の個人情報をお預かりするため、次のような第三者認証を取得しています。

SAS 70
ISO 27001
USO 800

詳細情報

より詳しい情報については、EMSの製品ページをご覧ください。

Permalink | コメント(0) | トラックバック(0) | 23:52

*1：AWS(Advanced Weight-loss Services)は、クラウド型ダイエットサービスを提唱・提供しています。クラウドコンピューティングを提供するAmazon Web Servicesとはなんら関係ありません。

2011-12-25

■[EC2][VPC]VPCでアベイラビリティゾーン越しにプライベートIPを共有する（Source/Descチェック外し）

久々のblogです。片山です。

先日@suz_labさんと、ENI出たけどAZは越せませんねー、という話をしていたときに思いついたアイデアを試してみました。

ENIについて

先日発表されたAWSの仮想ネットワークカード機能、Elastic Network Intarface(通称ENI)ですが、プライベートIPはもちろんのこと、セキュリティグループやグローバルIP、さらにMACアドレスまで別のサーバにつけたり外したりできる、かなりイケてる機能です。

EC2 インスタンスにENIをひっつけることで、元々持っているeth0と合わせて複数のネットワークカードを持つことが出来るようになるので、マルチホームを実現できます。またあるEC2 インスタンスから別のEC2 インスタンスへ付け替えできるので、たとえばDB サーバにひっつけたENIに対してWebサーバからアクセスさせておけば、DBが死んだときにも別で立てたDBにENIを付け替えることで、Webサーバの変更を行うことなくそのままアクセスできるように出来ます。いわゆるVirtualIP的なことがAWS上で構築できる、ということです。

さてこの機能ですが、1つだけ欠点があります。それは「AWSのアベイラビリティゾーン(AZ)を越えて移動できない事」です。

つまり、ENIを使ってDBのフェイルオーバー機能を実装しても、AZを超えたフェイルオーバーは行えないということです。

（現在の仕様で、VPC内に作るサブネットがAZをまたげないため、これに準じてENIもAZまたぎが出来ないのだと思います）

ということで何かいい方法はないかということで、次のようなことを行ってみました。

Source/Desc Check

AWS Management Console から、VPC内にあるEC2 インスタンスや、Network Interfacesの一覧のネットワークカードを右クリックすると、「Change Source/Dest Check」という項目があるのがわかるかと思います。

この設定はデフォルトでONになっていますが、このメニューからOFFにすることが出来ます。これは何かというと、「自分宛の通信以外を受け入れるかどうかをチェックするかどうか」を決める項目です。

通常、EC2のインスタンスには自分宛の通信しかこないので、このチェックがONでもOFFでも何も変わりません。元々この機能は（多分）VPCの中で使うNAT インスタンスために用意されています。

NAT インスタンスとは、インターネットに面していないサブネットから、インターネットに向かって通信する際に代理で通信をするためのサーバです。つまりNAT インスタンスでは、インターネットに向けた通信を受け入れて、自分が代理で通信をする必要があるため、このSource/DestチェックがOFFである必要があります。

今回の仕組みでは、この機能の特性を使って、VPC内にシステムを構築します。

構成図

今回作る仕組みは次のような絵になります。なお、前段で話しておいてなんですが、ENIは今回登場しません。

WebサーバとDB サーバのサブネットを、各AZに作成します。作成したサブネットに、１つづつインスタンスを配置します。Webサーバの入っているサブネット2つには、1つルーティングテーブルを作成して割り当てます。（今回ELBはおまけです）

仕掛けの説明

VPCでルーティングを作る際に、指定したIPアドレスレンジ宛ての通信を特定のインスタンス（もしくはネットワークインターフェース）に渡すという設定をすることができます。この設定をしても通常、EC2 インスタンスは自分宛以外の通信は受け入れないのですが、Source/Destチェックを外したEC2 インスタンスは、どこ宛の通信でも受け入れてくれます。つまり適当なIPアドレスを決めて、そのIPアドレスの場合は指定のEC2 インスタンスに渡すようルーティングしてやれば、EC2 インスタンスに付与したIPアドレスとは関係なく、EC2 インスタンスにパケットを到達させることができます。

たとえば今回の構成では、「10.0.0.2」を仮想的なIPとみなし、WebサーバからのDBにアクセスする際は、10.0.0.2へアクセスするように設定します。この絵のVPCは192.168.0.0/16のネットワークなので、何もしなければ、デフォルトゲートウェイから出て行ってあて先不明でロストしますが、Webサーバのサブネットに付けたルーティングテーブルにルーティングを書いてあげれば、DB サーバに到達するようになります。

ルーティングはつぎのような感じです。

10.0.0.2の通信が来たときに、指定のDB インスタンスに行くように設定します。もしDB サーバに障害が発生した場合は、このDB インスタンスのあて先を変えることで、DBを切り替えることが出来ます。切り替えはAWS SDKやコマンドラインから行えるため、スタンバイしているDBに監視機能を入れておいて、failを検知したら切り替えコマンドを発行します。ルーティング切り替えは瞬時に終わるので、DNS切り替えよりもフェイルオーバーに要する時間は短縮できます。

iptables

ここまで構築するとうまく行きそうですが、WebサーバからDBにアクセスしても通信が帰ってきません。自分以外のあて先でないので、どこかで通信が破棄されているようです。

ということで、各DB サーバのiptablesに次のような設定をしました。

iptables -t nat -A PREROUTING -i eth0 ! -d DB サーバのプライベートIP -p tcp --dport 3306 -j DNAT --to-destination DB サーバのプライベートIP:3306

設定としては、「自分宛以外のIPアドレスが来たら、自分のIPアドレスの3306に振り変える」というものです。これであれば、DB サーバのプライベートIPで来た場合はそのまま、それ以外はDB サーバ内で自分のプライベートIPに変換することでアクセスを行えます。

（今回はこの方法でうまく動きましたが、もっといい方法はあるかもしれません。。）

※追記

@j3tm0t0さんに、ループバックインターフェースにIPつけたほうがかっこいいよと教えてもらいました。

上記のiptablesの設定の代わりに、

ifconfig lo:0 10.0.0.2/32

という感じでループバックにIPを振っても、同じ事が実現できます。こちらの方がネットワークカードが明確になるのでよいですね。

テスト

192.168.30.10のサーバには「DB30」という名前のDB、192.168.30.10のサーバには「DB31」という名前のDBを作っておき、Webサーバからつないでみます。

mysqlで10.0.0.2に対して接続。

つながりました。DBの一覧を取得。

「DB30」が見えます。次にルーティングテーブルを変更します。

変更後、再度DB一覧を取得。

接続エラーになります。ルーティングが変わっているので、これは想定内の挙動。再度10.0.0.2につないて、DB一覧を取得。

同じ接続情報で接続し、「DB31」が見えました。うまく切り替わっています。

最後に

多少トリッキーですが、Webサーバで使うIPアドレスの変更なしで、DBの切り替えを行うことが出来ました。今回はDBのレプリケーションは試していませんが、DBには各サーバのプライベートIPでアクセスできるため、特に問題なくレプリケーションできると思います。今回ENIは使わなかったのですが、ENIと組み合わせてあげれば、プロキシサーバの冗長化や、ファイルサーバの冗長化などが行えるかもしれません。何かいい活用法や、内容のご指摘があれば、お教えいただければと思いますm(_ _)m

Permalink | コメント(0) | トラックバック(0) | 03:25

2011-07-31

■ アマゾンデータサービスジャパンに入社しました

2011年7月25日付けで、アマゾンデータサービスジャパンに入社しました。

初めてAWSに触れたのが、2009年でした。まだManagementConsoleがなく、コマンドラインやFireFoxのプラグインでEC2のインスタンスを操作していました。

初めてEC2 インスタンスが立ち上がった時は、新しい時代の到来を感じました。

「これがクラウドか」と。

それから自社でAWSを利用をしながら、新しいサービスが出るたびに感心し、ユーザーグループの活動を通じて知識を得るごとに、AWSへの興味が増えて行きました。それと同時に、みんなこれを使ったら楽になるのにな、と考えていました。

今回AWSを提供する側になったのも、こういう経験や想いがあってのことです。

私は元々ソフトウェアの仕事がメインであったため、AWSというインフラを提供する仕事になることについては、不安がなかったとは言えません。ただ、AWSを多くの方に使ってもらって、より多くの時間をサービス開発に費やせるようにしてもらえたり、インフラを抱えられないような会社や個人でもサービスが提供出来るようなお手伝いが出来たらいいなと思い、思いきって飛び込む事にしました。

今後は、いろいろな方にお会いする事になると思います。その際は是非、いろいろなご意見をお聞かせください。

今日で入社１週間、まだまだこれからですが、少しでも多くの方にAWSを使って良かったと言ってもらえるようがんばりたいと思いますので、どうぞよろしくお願い致します。

またAWSには、１週間で実感出来るぐらい、素晴らしい人たちと働ける環境があります。

もしAWSで働く事に興味がある方がいらしたら、是非お声かけ下さい。

今後ともよろしくお願いします。

Permalink | コメント(0) | トラックバック(0) | 00:16