Appleのネットサービスで大規模な接続障害が発生【復旧済み】
米AppleのクラウドサービスであるiCloudをはじめとするネットワークサービスの多くで、9月30日（日本時間）朝から一部のユーザーで認証問題、接続障害が発生していた（日本時間午前9時46分時点）。現在（日本時間午後12時11分）は復旧している。 AppleのSystem Statusページによれば、App Store、Apple Arcade、Apple Music、Apple TV+、Radio、Find My、Game Center、iCloud Backup、iCloud Calendar、iCloud Ccntacts、iCloud Web Apps、iWork for iCloud、Photosで接続できないユーザーがいる模様だ。
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ボリューム）とインスタンスが復旧したという。 同社は、障害
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 東京リージョンで発生した大規模障害についてまとめてみた - 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の契約先は数十万件とみられる。*
令和のシステム障害第1号はどこだ？改元後のトラブル10連発まとめ
令和が幕を開けた2019年5月1日、改元対応に関する目立ったシステムトラブルは発生しなかった。だが10連休が明けた2019年5月7日、大阪市や名古屋市、仙台市で改元対応の不備によるシステム障害が発生。ゆうちょ銀行やみずほ銀行、楽天銀行で連休明けのアクセス集中に関するトラブルがあった。 多くのシステムが改元対応やアクセス集中を乗り切った一方で、トラブルはなぜ生じたのか。改元のその日に起こったトラブルから見ていこう。 仕様のずれに気付かず「31年5月」を印字、第1号は上天草市 改元日の2019年5月1日、熊本県上天草市は同月6日まで発行する水道使用量の検針票に「31年5月分」と誤って印字していると発表した。検針票はもともと元号を省略した和暦で年月を印字しており、正しくは「元年5月分」と印字するはずだった。 水道局の職員は月初に契約世帯を巡回し、水道使用量を確認してハンディー端末で検針票を出力し
Microsoft Azure、DNSの設定変更に失敗して全世界的にサービス障害。日本は十連休中だったのが不幸中の幸いか
Microsoft Azure、DNSの設定変更に失敗して全世界的にサービス障害。日本は十連休中だったのが不幸中の幸いか Microsoft Azureは、2019年5月2日午後7時43分から午後10時35分まで（日本時間 2019年5月3日午前4時43分から午前7時35分まで）の約3時間、DNSの名前解決に問題が発生。 ほぼ全世界的に、Microsoft AzureをはじめOffice 365/Microsoft 365やMicrosoft Dynamicsなど同社サービスに対する接続ができなくなるという大規模な障害を起こしました。 この大規模障害の原因は、同社サービス用のDNSのメンテナンス作業のミスが原因だったと発表されました（中間報告の段階では既存のDNSからAzure DNSへのマイグレーション作業に失敗したと報告されていました。現在の報告では計画メンテナンス作業での失敗だとされ
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
