【AWS】障害時の調査事項まとめ ～ELB・ECS・RDS～ - Qiita
はじめに 現在はAWSで構築されたシステムの運用保守業務に携わっており、その一環として障害調査を行うことが多々あります。 少しは経験値が上がったため、障害が発生した際に初動で確認する事項をまとめてみました。 インフラ基盤観点で障害調査を行うさいの参考になれば幸いです。 前提条件 当システムの構成は以下となっているため、それに即した調査項目となっています。 ALB/NLB・ECS・RDSを利用している ECSはEC2上で実行している（Fargateでは利用していない） ECSクラスター（以下クラスター）の自動スケーリング設定をしている ECS サービス（以下サービス）の自動スケーリング設定をしている RDSはAuroraを利用している また、障害は予期せぬコンテナの停止を想定しています。 NLB/ALBの調査事項 メトリクス 初めにロードバランサーのメトリクスからターゲットの状態を確認します
AWSで障害に強いシステムを構築する方法 - Qiita
はじめに 2011年の東日本大震災、これから来ると言われる南海トラフ地震などの大規模な災害や事故に備えるために、災害復旧(DR)が可能なシステムと、その実現手段としてAWSを始めとしたクラウドが長年注目されています。 このDRに関連して、近年「レジリエンス」という言葉が注目を集めるようになりました。 レジリエンスとは、回復力、復元力、弾力などの意味を持つ英単語。IT分野では、情報システムがシステム障害や災害、サイバー攻撃などの問題に直面したとき、迅速に被害からの回復を図り正常な状態に復旧・復元する能力（の大きさ）をこのように呼ぶ。 https://e-words.jp/w/%E3%83%AC%E3%82%B8%E3%83%AA%E3%82%A8%E3%83%B3%E3%82%B9.html AWSでは、2019年8月に大規模障害が発生したことがあり、この時もAZ障害が起きた時に取り得る対策
AWS障害が起きたその日、人類は思い出した。ヤツらに支配されていた恐怖を…。
リンク ITmedia NEWS AWSで障害、「Nature Remo」「SwitchBot」などに影響 「電気消せない」と嘆く声 AWSの米バージニア州北部のデータセンターで障害が発生。複数のサービスが正常に動作しない状況が続いている。日本では「Nature Remo」「SwitchBot」などのスマート家電向けデバイスで不具合が発生。「電気を消せない」などの声がTwitterに投稿されている。 214 users 575 nasuuu @nasuvit_z AWS障害で us-east-1 の Kinesis Data Stream が赤ランプになった。「深刻な障害」と出ているけれど、Service Health Dashboard で赤ランプになったの、そう言えば見たことない気が。(あったのかもしれないけど…) pic.twitter.com/xKQFs7Jvyt 2020-11-
マルチAZ構成で単一AZの障害の影響を受けるのは何故か？ - プログラマでありたい
昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装（の予想） マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが
AWS 東京リージョンで発生した大規模障害についてまとめてみた - piyolog
2019年8月23日 13時頃からAmazon AWS 東京リージョン でシステム障害が発生し、EC2インスタンスに接続できない等の影響が発生しています。ここでは関連する情報をまとめます。 AWSの障害報告 aws.amazon.com AWS障害の状況 障害発生時間（EC２） 約６時間 2019年8月23日 12時36分頃～18時30分頃（大部分の復旧） 障害発生時間（RDS） 約９時間半 2019年8月23日 12時36分頃～22時5分頃 障害原因（EC２） 一部EC2サーバーのオーバーヒートによる停止 制御システム障害により冷却システムが故障したことに起因 影響範囲 東京リージョン（AP-NORTHEAST-1）の単一のAZに存在する一部EC2、EBS、およびRDS。 発生リージョンは東京。東京近郊４データセンター群の内、1つで発生。 日本国内のAWSの契約先は数十万件とみられる。*
8月23日のAWSの大規模障害でMultiAZでもALB（ELB）が特定条件で500エラーを返すことがあったという話 - Make組ブログ
このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです （当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW
9月20日に発生したAmazonクラウドのDynamoDB障害。原因はセカンダリインデックス増大によるメタデータ処理のパンク
9月20日に発生したAmazonクラウドのDynamoDB障害。原因はセカンダリインデックス増大によるメタデータ処理のパンク Amazonクラウドが提供しているDynamoDBは、キーバリュー型のNoSQLデータベースサービスです。運用管理はクラウドに任せられて簡単に利用でき、高速かつ非常に大規模なスケールで展開できることなどを特長とする、クラウドならではのサービスの1つです。 そのDynamoDBで、米東リージョンにおいて9月20日午前2時頃（太平洋夏時間）から午前7時頃まで障害が発生。DynamoDBを利用しているEC2 Auto Scaling、Simple Queue Service、CloudWatch、そしてコンソールなどにも一時的な障害が発生していました。 また、この障害はAmazonクラウドを利用している他社のさまざまなサービスにも影響を与えたと報じられています。 Amaz
負荷低すぎはもはや障害じゃないのか - mikedaの日記
前のブログの続きで、もにかじ7で話した小ネタその2。 実際にサービスでなんかやったというのじゃなく、こういうこと考えてるんだけどみんなどうしてます？って話です。 まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリやCPU引っこ抜いてもそんなに節約にならなかった。 ※CPUやメモリはサーバ価格の一部でしかないし、ラック費用(消費電力)もあるし。 でもクラウド前提だとスペックダウンはとても簡単で、スペック半分にすると価格も半分になる。 そうすると、 『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』 みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか？ みんななんかやってますか？ というようなことを参加者に聞いてみました。 参加者の中では、AutoScalingしてい
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」を選択します。検知されるシステム障害の例は、ネットワークの切断、システム電源断、物理ホストのソフトウェア障害あるい
実践！ヌーラボサービスでの CloudFront の障害対策 | 株式会社ヌーラボ(Nulab inc.)
CDNが単一障害点にならないようにするために ヌーラボでは 2010 年 Cacoo の商用サービスの開始に合わせて AWS における運用を開始しました。当時、運用環境として AWS を採択する決め手の一つになったのが CloudFront でした。その後も着々とエッジロケーションは増え、独自ドメインのサポートなど魅力的な機能も提供され、今ではヌーラボの全サービスの静的ファイルの配信で利用している、無くてはならないサービスとなっています。 その魅力の反面、CloudFront の障害は、アプリケーションそのものに問題がなくても、以下のような表示が崩れた画面が表示されて、ユーザが全くサービスを使えなくなるという、その影響が非常に大きいものです。また障害の原因が DNS やネットワークの経路における問題といった、私たちが直接解決しにくい領域にあることもしばしばです。 ただ、どんな事情であれ、障
米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る
Amazon EC2は9月末、その内部で使用しているXenハイパーバイザのセキュリティリスクに対処するため、全インスタンスの約10％にあたるインスタンスに対して段階的にリブートを行うメンテナンスを実行していました。 リブートをユーザーが回避する手段はなく、AWSから事前に通知を受けたユーザーはリブートによってデータを失ったりシステムがダウンしたりしないように、何らかの処置をする必要がありました。 AWS上で大規模なシステムを運用しつつもこのメンテナンスリブートを難なく乗り切ったのが、米国で動画配信サービスなどを運用するNetflixです。その理由は同社が開発したChaos Monkeyというツールにありました。 同社のブログにポストされた記事「A State of Xen - Chaos Monkey & Cassandra」で、その顛末が紹介されています。 Chaos Monkeyによっ
ステータスチェックに失敗した Linux インスタンスのトラブルシューティング - Amazon Elastic Compute Cloud
Amazon EC2 コンソールを使用して、問題のあるインスタンスを調査するにはAmazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。 ナビゲーションペインで [インスタンス] を選択し、インスタンスを選択します。 詳細ペインの [ステータスとアラーム] タブを選択して、すべての [システムステータスのチェック] と [インスタンスステータスのチェック] に関する個々の結果を表示します。 インスタンスの復旧アラームを作成します。詳細については、「インスタンスを停止、終了、再起動、または復旧するアラームを作成する」を参照してください。 インスタンスタイプを AWS Nitro システム上に構築されたインスタンスに変更した場合、必要な ENA と NVMe ドライバーがないインスタンスから移行するとステータスチェックは失敗しま
猿が暴れてクラウドの障害に強くなるNetflixのシステム - ワザノバ | wazanova.jp
http://techblog.netflix.com/2013/10/introducing-chaos-to-c.html 「歴史上の有名な開発プロジェクトからまなぶべきこと」をまとめていたときに、Videoの中で、ある大型ロケットエンジンの開発において、信頼性テストのために小型爆弾をエンジンの噴射口辺りで爆発させて耐性を調べた云々のエピソードが紹介されていて、更に続いて「ネット業界で同じようなことをやってるのはNetflixぐらいだ。」という説明がありました。その時は何のことだかよくわからなかったのでブログでは取り上げなかったのですが、今回見つけました。 以前紹介したように、北米のインターネットトラフィックの30%以上を占めるNeflixはインフラをAmazonに全面的に移行しています。クラウドに移行した後の学びとして、 自社データセンターの時は、個別のハードウェアインスタンスが障害
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
「AWSを活用して少人数で複数のサービスを運用するコツ」〜JAWS-UG in Nagoya〜 - よかろうもん！
10月6日に名古屋で開催された第4回JAWS-UGにて、「AWSを活用して少人数で複数のサービスを運用するコツ」というテーマで、SonicGardenの運用に関しての考え方や取り組みについてお話させていただきました。 当日の資料を以下から見えるようにしておきます。 「AWSを活用して少人数で複数のサービスを運用するコツ」〜jawsug in nagoya〜 また、資料のインプットとなっている記事については以下にリンクを用意しておきますので、時間があるときに読んでいただけましたら幸いです。 AWS障害による影響を小さくするための設計(2011/4/21の障害を踏まえて) - よかろうもん！ データやログのバックアップを楽に実現するために活用すべきライブラリ〜Backup〜 - よかろうもん！ 実践で使えるEBSスナップショット取得スクリプト - よかろうもん！ トータルフットボールなチームの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NetflixがChaos Monkeyをオープンソースに
クラウドサービス障害発生時にサービスを維持するには
TechCrunch | Startup and Technology News