2012年6月は、立て続けにUS EASTリージョンでダウンタイムが発生している。 NetflixのようにマルチAZの構成にして、常に擬似的に障害を発生させる仕組み( Chaos Monkey)を導入していても、ダウンする場合があることが明らかになった。さらなる可用性向上のためのツール(Chaos Monkey Family)やアーキテクチャ設計ノウハウがNetflixから出てくることを期待。 The Netflix Tech Blog: Lessons Netflix Learned from the AWS Storm === 概要 2012年6月29日(金)、ここ1年で最も大きな停止障害を経験した。太平洋時間午後8:00に始まり、復旧まで約3時間かかり、アメリカのNetflix会員に影響を及ぼした。弾力性のあるインフラに向けた努力にとAmazonクラウドでの経験をよく書いている。過去
10genからこんな記事が The 10gen Blog on MongoDB and NoSQL, Fluentd + MongoDB: The Easiest Way to Log Your Data Effectively. === ということで、Amazon Linuxでの環境構築メモ まずは、httpd+Fluentdを入れるインスタンス (web)と、MongoDBを入れるインスタンス(mongo)を用意して、インストール。 EC2: AMazon Linux にFluentdをインストール - aws memo EC2: AmazonLinuxにMongoDBをインストール - aws memo 次に、fluent-plugin-mongo をインストール $ sudo /usr/local/bin/fluent-gem install fluent-plugin-mongo
この構成を適当にポチポチしてるだけで作れちゃうAWSはスゴイ... 手順メモ 1. VPCの作成 ウィザードを使って、VPCと1組目のパブリックとプライベートネットワークを作る。 Amazon Web Servicesから VPC 選択 https://console.aws.amazon.com/console/home?region=ap-northeast-1# 「Start VPC Wizard」 「VPC with Public and Private Subnets」 Two Subnets を編集 Public Subnet: 10.0.10.0/24 (251 available IPs) Availability Zone: ap-northeast-1a Private Subnet: 10.0.100.0/24 (251 available IPs) Availabi
DynamoDB, SQSなどは、Linux内部から高頻度に HTTP APIを叩きに行くことになる。( Fluentdやら、memcachedやらも同じかも) 通常のLinuxのカーネルパラメータ設定で、本番環境や、負荷テスト環境に使うと、おそらくネットワーク障害のような状況に陥るはず。 その時、「DynamoDBの IOPS不足?」「 SQSのAPI スロットリング?「AWSの限界?」と思う前に、これチェック! netstat -an この結果に、大量のTIME_WAITが表示された場合は、 エフェメラルポートが枯渇して socket作れない状態に陥っている。つまり、DynamoDBやSQSまでパケット届いていない状態なのでAWS側は原因ではない。 ということで、エフェメラルポートを最大限使うようにカーネルパラメータを設定しておくことを忘れないようにするためのメモ。 $ sudo cp
この手順ではAmazon VPCを用いて、仮想ネットワーク(VPC)を作成し、 その中にサブネットを作成するまでを取り扱います。 【作業概要図】 VPCについて VPC(Amazon Virtual Private Cloud)はAWS内のサービスで、 仮想ネットワークを構築するものです。 使い方としては、VPCで作成した仮想ネットワーク内にいくつかのサブネットを切り出していき、 その中にEC2インスタンスを構築していく形となります。 (サブネットは通常のNWのサブネットとほぼ同義です) VPCを使うメリットとしては、以下の点が挙げられます。 EC2単体では出来なかった、外部から遮断されたインスタンスの作成ができる。 既存NWとVPNで接続することにより、EC2インスタンスを既存NWの一部のように使える。 VPCやサブネット単位で外部からのアクセスコントロールが可能であり、セキュリ
よく訓練されたアップル信者、都元です。今回のお題は久しぶりにVPCです。 この記事は、アップデート版が存在します。最新情報は【AWS】VPC環境構築ノウハウ社内資料 2014年4月版を参照してください。 VPCを利用する理由 弊社で構築するAWSのサーバ環境は、一部の例外を除いて全てVPCを利用しています。 突然ですが、筆者はあまり大規模なシステムに携わった経験がありません。大規模なプロジェクトだと「数百数千台のサーバがラッキングされ、それが論理的なネットワークで区切られていて」「複数のデータセンターが冗長化された専用線で結ばれて」等、正直ちょっと想像つかない世界があるんだと思います。よくわかんないですが。 (c)John McStravick. (CC BY 2.0 Licensed) 逆に、小さなシステムであれば、月々数万円でレンタルサーバを借りて「1台のマシンの中にWebサーバとDB
Introduction Amazon Web Services (AWS) Virtual Private Cloud (VPC) provides a good way to isolate your cloud servers from the shared data-center environment and to reduce public cloud security threats. For a more detailed discussion about security threats arising from IaaS consumption see our previous post on the need for VPC solutions. There are several good reasons why one would want to deploy v
Kiip recently completed a migration from EC2 to VPC. VPC exited beta and became generally available in all regions in August, and allows you to provision compute nodes within a virtual network in AWS. For anything more than simple websites, we believe migrating to VPC is something worth doing, or at the very least worth investigating. Because Amazon VPC is a new service and requires a substantial
解決したい課題 複数拠点間でのVPN(仮想プライベートネットワーク)接続をフルメッシュ型で構築すると、拠点が増えるに従い各拠点のVPNルーターへの設定も煩雑になり、メンテナンスコストが増大する。この問題を解決するためにスター型でVPNを構築すると、各拠点のVPNルーターはVPNハブに接続するだけでよくなる。しかしVPNハブに障害が起こると、すべてのVPN接続に影響を与えてしまうので、VPNハブの可用性が重要な課題となる。 クラウドでの解決/パターンの説明 従来のVPNハブは、可用性を高めるためにVPNに利用する通信機器を冗長構成にするなど、高額な初期投資を必要としてきた。またVPN接続の利用量にかかわらず設備維持の固定費がかかってしまい、コスト効率も悪い。クラウドにはVPN機能を提供するものもあり、VPNハブとして利用することもできる。可用性の高いクラウド基盤を従量課金で利用することになる
解決したい課題 システム全部をある地域から異なる地域へ移行したいというケースがある。例えば、オンプレミスのデータセンターから、クラウドへシステムを移行する場合、もしくはクラウドのある地域から異なる地域へ移行したい場合が考えられる。この際、システムのドメイン名を変えることなく、なおかつ、システムを停止することなく、できるだけスムーズに移行したいという要望は大きい。 クラウドでの解決/パターンの説明 ドメイン名を変えることなくシステム全部を移行させるには、DNSサーバーにおいて重みづけラウンドロビンという機能を用い、名前解決する際に既存システムから新システムに切り替える手法がある。最初は新システムに少しだけ振り分け、問題が無ければ、新システムへの配分を徐々に増やしていくことができる。クラウドで提供されているDNSサービスを用いれば、重みづけラウンドロビン設定も容易に行えるため、最小限のDNSサ
解決したい課題 バッチ処理の負荷分散として、ジョブリクエストをキューで管理し、キューのジョブリクエストを複数のバッチサーバーが並列に処理する方法がある。しかし、用意するバッチサーバー数はピークに合わせた数となるため、ピーク外の時間帯ではバッチサーバーのリソースが余ってしまい、コスト効率が悪くなってしまう。また、予想以上の負荷がバッチシステムにかかった場合、レスポンスが悪くなってしまう。 クラウドでの解決/パターンの説明 従来はサーバーリソースを動的に増減することができなかったので、ピークや許容コストの範囲内でバッチサーバーを用意していた。コスト効率が悪く、想定外の負荷に対応ができないという課題があった。クラウドでは、負荷をモニタリングし仮想サーバーを自動的に増減させる仕組みを備えている。この仕組みを利用することで負荷に応じてバッチサーバーを増減できるようになり、コスト効率がよく想定外の負荷
解決したい課題 世界中のキャッシュロケーションを活用したコンテンツデリバリーのサービスを用いることで、世界中のユーザーに高速にデータを配信することが可能となった。しかし、特定のユーザーにのみコンテンツを配布する場合、利用者を認証する必要があり、そうした仕組みを構築するのは簡単ではない。 クラウドでの解決/パターンの説明 コンテンツデリバリーで提供される「署名付きURL認証機能」を用いる方法がある。ユーザーがコンテンツをダウンロードするためにWebサイトにアクセスする際に、あらかじめ設定しておいた「アクセス元IPアドレス」「ダウンロード可能期間」「アクセス元地域」等に適合した場合のみ、「署名付きURL認証機能」を発行すれば良い。より高い精度での特定ユーザーへの配信が可能となる。 また署名付きURL以外にも、クッキーに対して署名を付与する「署名付きクッキー認証」を利用することもできる。 実装
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く