AWSのシステム構成情報を集めて構成図を自動生成してくれる「CloudMapper」、オープンソースで公開
AWSのシステム構成情報を集めて構成図を自動生成してくれる「CloudMapper」、オープンソースで公開 CloudMapperを用いることで、AWS上のシステムについて以下のような状況をすぐに把握することができると説明されています。 どのリソースがインターネットに公開されているか？ どのリソース同士がつながっているのか？ アベイラビリティゾーンが落ちたときでも十分堅牢なアーキテクチャか？ このアカウントはいくつのリージョンを利用しているか？ どれだけ大きないシステムを運用しているか？ CloudMapperを開発しているDUOは、セキュリティサービスを提供する企業。同社は自身もAWSユーザーで、さまざまなオープンソースのツールを試してみたものの満足できるようなものがなかったため、自社でCloudMapperを開発したとのこと。 CloudMapperの仕組みは、まずAWSコマンドライン
Tuppari - WebSocket on Your Cloud - - hakobera's blog
Tuppari とは 東京Node学園 6時限目で発表した Node.js で作られた Pusher クローンです。 簡単に言うと WebSocket を利用した大規模 Broadcast に特化したサービスです。 インフラとしては Amazon Web Services (以降、AWS）上で動かすことに最適化されていますが、AWS以外でも動かすことは可能です。つまり、クラウド上に自分自身の Pusher を構築することが可能になります。 現時点では Pusher の機能には追いついていませんが、今後も鋭意開発を進めていくので、是非使ってみてください。 あと、WebSocket を使うので、IE9 以下では動きません。 8/15 追記: v0.2.0 から IE もサポートしました。 詳細は以下の記事を参照して下さい。 Tuppari コミュニティ始めました & IE に対応しました -
Elastic Load Balancerをつかってwebsocketを処理する方法
AWSにはElastice Load Balancerというロードバランサがあります。これはとても安いこともあって多くのお客様のwebサービスで使っていただいています。 最近はwebsocketを使いたい!という声もありますが、いくつかの制限により、 ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法がおすすめです。 そもそも問題は、 ELBの場合、HTTPモードだとそもそも同じポートのままではwebsocketに遷移できない。 ELBでTCPモードにした場合でも60秒でタイムアウトする。 の2点が原因です。そのため、2つの方法があります。 解1: ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法 C ---------> ELB(HTTPモード) --> S ふつうにHTTPでアクセス。
Socket.IO or WebSocket を AmazonELB でバランスする検証 - Block Rockin’ Codes
追記 12/2/29 検証コードと環境は後にしてとりあえず結果だけ書く 12/3/5 Socket.IO の RedisStore を使えばスケール可能なことがわかったので追加 12/3/11 検証コード追加 caution この検証は 東京Node学園 4時限目 - connpass でやった結果です。しかしその時の環境やソースが手元に無いので今再現ソースと環境を作っています。 2/28 現在分かってる結論だけ先に出しておきます。ソースは後で追って掲載します。その時点でもし結論が変わったりした場合は追記します。 また、この検証内容については一切責任は取りませんので、プロダクション等で使う場合はきちんと検証して下さい。 特に ELB の仕様が変わったら結果が変わると思います。結果が変わったことに気がついた方は教えて頂けると助かります。 code 検証コードを公開しました。 https://
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クラウドセキュリティ基礎
