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) の単一のアベイラビリティゾーンで、オーバーヒートにより一
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の契約先は数十万件とみられる。*
さよならGAFAM：5社一気にブロック→地獄です
さよならGAFAM：5社一気にブロック→地獄です2019.02.25 18:00107,093 Kashmir Hill - Gizmodo US ［原文］ （ 福田ミホ ） GAFAM（Google、Amazon、Facebook、Apple、Microsoft）の製品・サービスを使わずに過ごしてみるこの実験、ここまでは1週間に1社だけ使うのをやめればよかったんですが、今回は5社全部いっぺんにブロックです。ほとんど仙人みたいな生活に突入したKashmir Hill記者は、地獄を抜けた後どんな境地にたどりついたんでしょうか？ 6週目：5社全部私は2カ月ほど前、5大テック企業なしで生活できるか？という疑問に答えるべく、行動を開始しました。5週間にわたってAmazon、Facebook、Google、Microsoft、そしてAppleを1週間にひとつずつ順番にブロックして、彼らの製品やサービ
AWSを学ぶ上でやってよかった勉強法５選 - log4ketancho
「AWSの勉強をしたいんだけど、まず何をすればいい？」と会社の同期や同僚から聞かれることがよくあります。ありがたいことに、先日 Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA) を出版してからは、システムエンジニアではない知人からもこのような質問を頂くようになりました。このような質問を頂いた方には、過去に有志で開催していた社内勉強会の資料を渡したり、自分の勉強方法を共有したりするのですが、自分がどのような勉強方法をしてきたか棚卸ししきれていないなと感じたので、これを機に整理しようと思います。 私について 私は、大学時代はアプリケーション系の情報専攻で、社会人になってからも入社後最初の数年はアプリエンジニアとして仕事をしていました。そのため、当時インフラサイドの知見はほとんどありませんでした。そのような状況に危機感があり、当時の上司に
新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング | Amazon Web Services
Amazon Web Services ブログ 新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング Elastic Load Balancing(ELB)は、Auto ScalingとAmazon CloudWatchを含む3つの組みの一部としてローンチした2009年以来、AWSの重要な要素になっています。それから、私たちは多数の機能を追加し、そしてApplication Load Balancerをリリースしました。コンテナで稼働するアプリケーションに対するアプリケーションレベルでのコンテンツベースルーティングをサポートする様に設計されており、Application Load Balancer はマイクロサービス、ストリーミング、リアルタイムワークロードと相性が良いです。 長年にわたって、私達のお客様はあらゆる規模のwebサイトや、アプリケーシ
AWS のデータセンターに侵入する（妄想で） - Qiita
AWS の中身はどうなっているの？ AWS インスタンスを立ち上げたとき、なんとなく Virtual Machine 上で 仮想OSが立ち上がっているんだろうなーというのは分かるけど、実際の物理層はどうなっているんでしょうか。データセンターはどこにあって、何台くらいのサーバが動いていて、どのラックのどの VM 上にインスタンスができるんでしょう。 そんなこと知らなくてもサーバ立てることはできるし、障害にも強いらしいし、知らなくてもいいことなんだけど。でも、わたし気になります！ ナイショです AWS はデータセンターの場所は非公開、どこにあるか教えてくれません。物理層の内部仕様も非公開で re:invent でチョイ出しする程度です。 ここはささやかな抵抗として、物理構成を想像で補完し、妄想によるデータセンターへの侵入を試みます。 こんな構成で構築しました 手始めにサーバ 1台、ボリューム
AWS でいままで起きた大規模障害を振り返る - Qiita
目的 2017/3/1 に us-east-1 の S3 大規模障害がありました。過去にもいくつか発生しているのと、いつ使っているリージョンで同じ事態が起きてもおかしくないと思い、これを機に過去どのような障害があったのか遡って調べました。 所感 毎年どこかのリージョンで大規模な障害が起きている ap-northeast-1 で起きていないのはたまたま、運がいいだけ AWS は復旧時間の改善・可用性向上に全力を尽くしているものの、未知の障害はいつかどこかで起きるもの ステータスダッシュボードは時に嘘をつく クラウドシェアトップである AWS はインターネット全体の SPOF になりつつある Chaos Monkey の思想は必須 報告書読むの面白い AWS の中身がすこし透けて見えてきます 前回データセンターについて調べたことが役に立った AWS のデータセンターに侵入する（妄想で） - Q
Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く
AWSの米国東部リージョン（US-EAST-1、バージニア北部）において2月28日に発生したAmazon S3の障害の原因と対策などについて、AWSが報告を公開しました。 Amazon S3がダウンした直接の原因は、Amazon S3課金システムのデバッグ作業中に入力したコマンドのミスによって多数のサーバが削除されたことでした。また、それによって引き起こされたサブシステムの再起動に時間がかかったことが、障害を長引かせる要因になっています。 この記事ではAWSの報告内容を整理し、発生した出来事を時系列でみたあと、障害の背景にあった技術的な要因と対策を紹介します。 コマンドの入力ミスで多数のサーバを削除、復帰にも長時間かかる そもそもの障害の発端は、Amazon S3課金システムの処理速度が想定よりも遅くなっていたため、Amazon S3チームがデバッグ作業を行っていたことでした。 2月28日
無料のドメインを取得する - Qiita
最近はドメインも安く取得できるようになりましたので、需要はあまり多くはないかも知れませんが、「無料」で気軽に取得できるという点で、コストコンシャスな方々に一定の需要があると信じて投稿します。 症状と効能 オリジナルドメインで手軽にブログを始めたい（タダで） ネームサーバのテスト用のドメインを一時的に取得したい（タダで） フリーランスの名刺にオリジナルドメインのＵＲＬとメアドを刷り込みたい せっかくAWSが無料試用期間なのにドメイン取得費用を払うのはイヤ とにかくドメイン取得に一銭も払いたくない、という方向けに寄稿します。 無料で取得できるドメイン Freenomからは5種類のドメイン(.tk/.ml/.ga/.cf/.gq)が無料で取得できます。どれを使うかはお好みで。今回は.tkで取得を進めます。 .tkドメインの注意事項 90日間で25アクセス以下の場合は、登録が削除されます。3ヶ月の
初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 - Qiita
こんにちは、2015年も終わりですね。昨年よりエンジニアのお仕事をはじめております自称エンジニアの@mochizukikotaroです。 お祭り記事ですので、皆様の箸休めの一助にでもなればと思いながら、全力で書きたいと思います。 まず感謝 当記事は、「素人がAWSに手を出し、のんきに過ごして気づいたら、自分のミスで不正利用され$6,000ほどの請求が来ていて」一週間ほど食べ物も喉を通らず、AWS様に泣きついた結果、「なんとか情け容赦を頂いた」という内容です。 本文中には多少ふざけた言葉選びが散見されるかもしれませんが、私は全力で AWSさんに感謝 をしております。 この先、 僕と同じような過ちを犯す可哀想な素人エンジニアを、この世から一人でも無くしたい。 と切に願っております。 最初にお断りしておきますが、 当記事から得られる、プログラミングインテリジェンスは1gくらいです。 一定レベル以
複数のクラウドサービス間でオブジェクトストレージの中身を同期する - クックパッド開発者ブログ
複数のクラウドサービス間でオブジェクトストレージの中身を同期する こんにちは。インフラストラクチャー部の加藤(@EugeneK)です。 クックパッドのすべてのレシピやつくれぽ等の画像はAmazon Web Services(以下AWS)のSimple Storage Service(以下S3)にオブジェクトとして保存されています。 S3は99.999999999%の堅牢性と99.99%の可用性を謳っていますが、ユーザさんから預かった大切なデータを守るため、万一に備えて別のクラウドストレージにもバックアップを行っています。 今回はそのオブジェクトを準リアルタイムでGoogle Cloud Storage(以下GCS)に同期されるようにした話をします。 S3にオブジェクトが追加されたことを知る S3にはEvent Notificationという機能があります。 この機能を用いると、S3のバケッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
