マルチ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障害対応に見えた利用規約免責の変節点 —サブスク化で重みを増す継続責任 | クラウドサイン
Amazon社のAWS障害の影響を受けて対応する各企業の姿に、ITサービスのサブスクリプション化による「責任の果たし方の変化」を見ました。 AWS東京リージョンで数時間にわたる障害が発生 2019年8月23日の午後、多くのITサービスを縁の下で支えるAWS（Amazon Web Services）の東京リージョンのサーバーの一部で障害が発生 しました。 このAWS上で運用されているサービスは数多く、また障害解決までに時間を要したこともあって、「AWS障害」がTwitterのトレンドワード入りしたほか、翌日には新聞報道もされるほどの騒ぎとなりました。 ▼ クラウド集中にもろさ アマゾン「AWS」大規模障害 今回の障害を受け、ソフトバンクグループ傘下でスマートフォン決済を手掛けるPayPay（ペイペイ、東京・千代田）では支払いや入金ができなくなった。 クラウド会計ソフトのfreee（フリー、東
AWSのAZの割り当ては、アカウントごとに違うという話 - プログラマでありたい
先週の金曜日（2019/8/23）に発生したAWSの東京リージョンで大規模な障害が発生しました。障害の内容は、一つのAZで空調設備の問題からEC2インスタンス並びにEBSに問題が発生したという事象です。詳細についてはAWSから発表があるので、そちらをご参照ください。 aws.amazon.com 障害の最中にTwitterのタイムラインを見ていると、単一AZ障害ではなく複数のAZで障害が発生しているのではないかという観測が多く見られました。障害としては、AWSの発表通り単一AZ障害です。では何故多くの人に勘違いされたのでしょうか？理由は2つあります。 AZの割り当ては、アカウントごとに違うという事が知られていない マルチAZ構成にしていても、単一AZの障害の影響を受ける ここでは前者のAWSアカウントの割り当ての話を説明します。 あなたが見ているap-northeast-1aは、私が見てい
AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず
AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず 報告によると直接の原因は東京リージョンのデータセンターで使用されている冷却制御システムにバグがあったこと。これにより、緊急時の手動操作にも冷却制御システムの一部が反応しないなどでサーバが過熱し、障害に至ったと説明されています。 8月23日午後に約6時間の障害。EC2だけでなくRDSも 報告によると、障害は日本時間2019年8月23日金曜日の昼過ぎに発生。影響範囲は仮想マシンを提供するAmazon EC2とブロックストレージを提供するAmazon EBSのそれぞれ一部。以下、AWSの報告を引用します。 日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一
Summary of the Amazon EC2 Issues in the Asia Pacific (Tokyo) Region (AP-NORTHEAST-1)
2019年8月28日(日本時間)更新: 最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご
障害から学ぶクラウドの正しい歩き方について考える - そーだいなるらくがき帳
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
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
AWS障害、大部分の復旧完了 原因は「サーバの過熱」
8月23日午後1時ごろに発生した、米Amazon Web Servicesのクラウドサービス「AWS」の東京リージョンでの障害について、同社は午後8時18分、クラウドサーバの復旧がほぼ完了したことを明らかにした。制御システムの障害により、サーバの温度が上がりすぎたことが原因だったという。 同社によると問題が起きたのは、「Amazon Elastic Compute Cloud」（EC2）の東京リージョンを構成する4つのデータセンター（アベイラビリティーゾーン、AZ）の内の1カ所。AZ内の制御システムに問題が発生し、複数の冗長化冷却システムに障害が起きたという。結果として、AZ内の少数のEC2サーバが過熱状態となり、障害として表面化したとしている。 冷却システムは午後3時21分に復旧。午後6時30分までに、ほぼ全てのストレージ（EBSボリューム）とインスタンスが復旧したという。 同社は、障害
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の契約先は数十万件とみられる。*
20190819 AWS におけるモニタリング 議論のための観点総ざらえ
- The document discusses monitoring AWS resources using Amazon CloudWatch. It covers collecting metrics and logs from EC2 instances, ELB, RDS, and other services and visualizing the data in CloudWatch. - Key services mentioned include CloudWatch Metrics to collect CPU, memory, disk and network utilization from EC2 instances, CloudWatch Logs to collect logs, and integrating monitoring with services
インフラのコスト最適化の重要性と RI (リザーブドインスタンス) の維持管理におけるクックパッドでの取り組み - クックパッド開発者ブログ
技術部 SRE グループの mozamimy です。 クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいるため、今回はそれについてご紹介します。 前半では、そもそもの話として「なぜコスト最適化が重要なのか」「何が難しいのか」「何をすべきなのか」といったことを述べます。これは、当たり前すぎて逆に陽に語られることが少ない (とわたしは感じています) トピックで、一度しっかり言語化しておいてもいいかなと考えたからです。内容のほとんどはわたしの脳内ダンプで、クックパッドという会社のコンテキストや組織としてのステージが前提になっているため、大多数の組織について当てはまる内容とは限りません。 後半では、コスト最適化の一例として、リザーブドインスタンス (以下 RI と略記) を維持管理するためのフローと、それを支えるモニタリング
AWSのアーキテクチャの基本をアップデート 押さえておくべき7つの原則
まずは基本中の基本 EC2とVPC 2019年6月に開催されたAWS Summit Tokyoでは、数多くのブレイクアウトセッションが用意され、どの会場も多くの聴衆が耳を傾けていた。ここでは「Architecting for the Cloud 2019 クラウドにおけるアーキテクチャの設計原則」のポイントをまとめておこう。解説はAWSに入社して8年目となるアマゾン ウェブ サービス ジャパン ソリューションアーキテクト 荒木靖弘氏。 アマゾン ウェブ サービス ジャパン ソリューションアーキテクト 荒木靖弘氏 まずは基本中の基本としてEC2とVPCから。AWSで「サーバー」と言えばEC2（Amazon Elastic Compute Cloud）。荒木氏は「便利に使える仮想サーバー」と言う。規模や用途に応じて多数のインスタンスタイプが用意されている。EC2はAMI（Amazon Mach
SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた - piyolog
2019年7月29日、米金融大手 Capital Oneは不正アクセスにより1億人を超える個人情報が流出したと発表しました。WAFの設定ミスに起因して、Server Side Request Forgery（SSRF）攻撃を許したことにより情報を盗まれたと見られています。ここでは関連する情報をまとめます。 Capital Oneによる公式発表 Information on the Capital One Cyber Incident（米国向け） Information on the Capital One Cyber Incident（カナダ向け） Frequently Asked Questions （１）影響範囲 影響が及んだ人数の内訳は以下の通り。 米国 約1億人 カナダ 約600万人 発表時点でCapital Oneは流出した情報が外部へ出回ることや、詐欺への使用は確認していない。
AWS Chatbot発表、CloudWatchのアラートなどをSlackへ通知。無料で利用可能
AWSは、AWSのさまざまなサービスからのメッセージをSlackもしくはAWS Chimeへ通知してくれる「AWS Chatbot」をベータ版として発表しました。 具体的には以下のサービスからのメッセージを扱うことができます。 Amazon CloudWatch AWS Health AWS Budgets AWS Security Hub Amazon GuardDuty AWS CloudFormation AWS Chatbotはこれらから送られてきたメッセージをAmzon SNS経由で受け取り、SlackもしくはAmazon Chimeへ通知します。AWS Chatbotを利用するための追加料金などは発生しません。 ITシステムの開発や運用の現場では、Slackのようなチャットサービスを人間同士のコミュニケーションに使うだけでなく、ビルドやデプロイなどシステムに対する操作や、その結
「AWS Toolkit for Visual Studio Code」正式版がリリース。AWS Lambdaのステップ実行、ローカルデバッグなど可能に
AWSはオープンソースとして開発されているコードエディタVisual Studio Codeの拡張機能として、これまでプレビュー公開されていた「AWS Toolkit for Visual Studio Code」が正式版になったことを発表しました。 AWS Toolkit for Visual Studio Codeと、AWS Command Line Interface（AWS CLI）やDockerなどを組み合わせることで、サーバレスコンピューティング環境であるAWS Lambdaのローカル環境でのステップ実行やブレークポイントの設定などのデバッグ操作などが可能になります。 そして開発したアプリケーションをAWSの任意のリージョンへのデプロイもVisual Studio Codeから手軽に行えるようになります。 AWS Lambdaのローカルデバッグが可能 AWS Toolkit f
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか【西田宗千佳のイマトミライ】
クラウド集中にもろさ アマゾン「AWS」大規模障害 - 日本経済新聞
ヤマハが待望の仮想ルータ「vRX」を正式発表、まずはAWS版を9月に発売
DeNA の AWS アカウント管理とセキュリティ監査自動化
そんなことあるんだ AWS
