Amazonクラウドが「Amazon EC2 Auto Recovery」開始。システム障害を検知するとインスタンスを自動的に別システムへ移動、復旧
Amazon EC2 Auto Recoveryは、インスタンスが稼働しているサーバのシステム障害が検知されると、そのインスタンスを自動的に別のサーバへ移動、再起動し、システム障害から復旧させる機能。 移動したインスタンスは、IDやIPアドレス、コンフィグレーションなども含めて移動前のインスタンスと同じものになります。 これにより利用者は、クラウド上でいままで以上に可用性を高めることが容易になります。 AWS Cloud Watchで検知し、自動復旧 Auto Recoveryを機能させるには、AWS CloudWatchのアラームを作成し、メトリクスの「EC2 Status Check Failed (System)」のアクション「Recover this instance」を選択します。検知されるシステム障害の例は、ネットワークの切断、システム電源断、物理ホストのソフトウェア障害あるい
Amazon Web Servicesの障害はなぜ起こったのか アマゾンが詳細な経緯と対策を発表 − ＠IT
2011/04/30 米Amazon Web Services（AWS）は米国時間4月29日午後、同社のブロックストレージサービス「Amazon Elastic Block Store（EBS）」および、リレーショナルデータベースサービスの「Amazon Relational Database Service（RDS）」における約4日間にわたる障害につき、詳細な経過報告と対策を発表した。これによると、障害のきっかけはネットワークの構成変更作業におけるミスだった。同社は今回の障害が複数のAvailability Zone（AZ）に影響を与えた理由も説明した。 AWSが発表した今回の障害に関する説明（英語） EBSはAWSの仮想サーバサービスであるAmazon EC2のインスタンスから、仮想ディスクとして使える永続ストレージサービス。実態としてはディスクを備えたノード（コンピュータ）の集合体を
Amazonクラウド、ストレージ障害は潜在バグからメモリリーク発生が原因。きっかけはDNSの変更
先週の10月22日月曜日、Amazonクラウドの米国東リージョンでストレージ障害が発生しました。その原因は、Amazon EBSストレージサーバのバグがメモリリークを引き起こしことだと、Amazonクラウドが報告書「Summary of the October 22, 2012 AWS Service Event in the US-East Region」で明らかにしました。 Summary of the October 22, 2012 AWS Service Event in the US-East Region Amazon EBSストレージサーバのメモリリークを引き起こしたのは、内部DNSの設定ミスによって発生したサーバ間の接続エラーでした。このエラーが潜在的なバグを呼び起こし、知らぬ間に多くのサーバが影響を受け、それがある時点で一斉にストレージ障害という現象を引き起こしたのです
2012年のクリスマスイブ、Amazonクラウドから降ってきたシステム障害。原因はオペレーションミス
2012年12月24日、クリスマスイブの夜にオンライン映画をNetflixで楽しもうとしていた北米の人たちをがっかりさせる出来事が起きました。Amazonクラウドに障害が発生し、その影響でNetflixのWebサイトや動画の再生がトラブルに見舞われたのです。 Summary of the December 24, 2012 Amazon ELB Service Event in the US-East Region 障害が発生したのは、Amazonクラウドの米東部リージョン。発生の経緯と原因をAmazonクラウドが詳細に報告しています。 メンテナンス時のミスでデータを消去 クリスマスイブの障害は、ロードバランサーという比較的上位のサービスで起きたオペレーションミスが原因でした。ポイントを追っていきましょう。 The service disruption began at 12:24 PM
Amazonクラウド、ネットワーク機器の障害で一時動作不良。Heroku、Parse、Kinveyなどがダウン
Amazonクラウド、ネットワーク機器の障害で一時動作不良。Heroku、Parse、Kinveyなどがダウン 8月25日13時頃（米国太平洋時間。日本時間の26日午前5時頃）、Amazonクラウドの米国東部（バージニア北部）リージョンで提供されているストレージサービスのAmazon EBSが、特定のアベイラビリティゾーンで動作不良を発生。パフォーマンスが低下し、その影響でHerokuやParse、Kinveyなどのサービスが一時的にダウンしたことが報告されています（Herokuのインシデントレポート）。 原因はネットワーク機器の不具合によるパケットロスにあったようで、現在は正常動作に復帰しています。しかしAmazonクラウドのネットワークが冗長構成になっていないはずがなく、単純な機器の故障で障害を引き起こすとは思えないので、おそらく原因はここで報告されている以上に複雑なものなのではないか
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 米国でビデオオンデマンドサービスを提供しているNetflixは、Amazonクラウド上でわざとシステム障害を起こすためのツール、Chaos Monkeyをオープンソースで公開しました。 Chaos MonkeyはAmazonクラウド上で使うツール。Amazonクラウド上のインスタンスをランダムに落としまくることで、サービスに対して仮想的な障害を引き起こしてくれます。 NetflixはこのChaos Monkeyを実環境で使うことで、本物の障害が起きたとしてもサービスが継続できることをテストし続けてきました。Netflixのブログ「Chaos Monkey released into the wild」から引用します。 There are many fail
Amazonクラウドを襲った嵐が、EC2、EBS、ELB、RDSの障害に発展した理由（前編）
米国で6月29日の夜に発生したAmazonクラウドのトラブルは、InstagramやFlipboard、Netflixなど有名なサービスにも影響を与えました。国内のサービスでもいくつか影響を受けたところがあったようです。 今回のトラブルの発端は電源障害でした。嵐によって一時的に電源に障害が発生し、UPSに切り替わったもののUPSが電力を使い果たした結果、一部のデータセンターが稼働を停止しました。 この電源障害による直接の影響は全体の数％だったものの、これが引き金となって仮想マシンの「EC2」、ストレージの「EBS」、ロードバランシングの「ELB」、データベースサービスの「RDS」などにおいてソフトウェアや運用まわりでの問題が相次いで発生。一部で複数のアベイラビリティゾーンに影響する障害へと発展しました。 今回は複数のアベイラビリティゾーンに影響があり、その上6月中旬にも電源まわりのトラブル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News