アマゾン ウェブ サービス（aws）は、信頼性と拡張性に優れたクラウドコンピューティングサービスを低料金で提供しており、190か国の100万以上、日本国内では10万以上のお客様にご利用いただいています。aws アカウントの作成は無料で、40以上のサービスを無料でお試しいただけます。 will it revert back to free play? Asia Pacificタブは数が多く、1回に5分ほど時間がかかります。, ここまで頑張って作ったあとに、全リージョンの障害情報が取得できるJSONファイルがあることを知りました。さすがClassmethodさん。憧れる。, 【小ネタ】AWSで過去に発生した障害の履歴を確認する方法 | Developers.IO © Copyright 2020 クラウドサービス徹底比較・徹底解説 (2020年版). 26日18時ごろから、「TVer」「Hulu」「Paravi」「DAZN」などのサービスや、 「パズドラ」「FGO」「駅メモ」「Nintendo Switch Online」 など日本国内の複数のサービスが利用できなくなっているとの情報 … (2020/6/13更新)後半に記載しているJSONですが、どうも更新にタイムラグがあるようで、状況が[RESOLVED]になってから登録されるようです。, 4/20の夜にAWSの東京リージョンでSQSやLambdaに障害があったようです。 AWS障害起きてんの？？ わいは絶対出社しないぞ — ゆう (@yuu_frontal) September 26, 2020. 「パズドラ」「FGO」「駅メモ」「Nintendo Switch Online」 twitter.com/Trainfo_NEWS/s…, あーこれのせいで日本のほとんどのサービス重いんだな twitter.com/Trainfo_NEWS/s…, パズドラは現在問題ありません twitter.com/Trainfo_NEWS/s…, 見れてる報告多いがなにが起こってるん？ twitter.com/Trainfo_NEWS/s…, この間もあったよねぇ( ˘ω˘) twitter.com/Trainfo_NEWS/s…, なんか前もあったような気がするでち twitter.com/Trainfo_NEWS/s…, さっき Paraviが 愛媛県今治市で特定の男性を名指しし、新型コロナウイルスの感染者だと中傷するビラを... 【バレ】鬼滅の刃・上弦の参・猗窩座 (あかざ)の声優は石田彰！結核の青年は江口拓也など豪華声優勢揃い. 今回のコラムでは、クラウドの障害対策の4つの方法と、最も信頼性のある構成について考えていきます。, 2019年の8月23日にAWSの東京リージョンで大規模な障害が発生しました。この障害のため、東京リージョンに配置される一部のEC2インスタンス（IaaS）、RDS（データベースのサービス）が使用不可となりました。, 最近は多くの重要なシステムがクラウドのIaaSに移行されています。今回の障害を受けて、不安を感じた事業者は少なくなかったでしょう。, しかし、この障害において、当社の高可用性ソリューションである「AZをまたいだHAクラスター構成」は被害を受けずサービス提供を継続できました。今一度、システムの障害対策が十分なのかどうか考えてみましょう。, AWSでもし障害が発生した場合、簡単に確認する方法をいくつか紹介します。動作がおかしい場合など、まずは確認してみましょう。, AWSで障害が発生したことは、ダッシュボードから確認ができます。まずはAWSにログインし、管理画面を開きます。もし、画面右上にあるベル型のアイコンにチェックが入っていたら、何か情報があるということです。そこをクリックすると、ダッシュボードが開き、「Open Issue」が確認できます。表示されている数字が発生した件数であり、イベント内容と事象が発生したリージョン名、発生日時が開示されています。, 発生しているイベントをクリックすれば右側のペインに開くため、そこで詳細情報を確認しましょう。ダッシュボード以外にも、公式に各リージョンの状況を発表しているサイト「Service Health Dashboard」でも障害情報を確認できます。これは各リージョンのサービス状態を一覧で参照できるものです。, 各サービスの右にある「RSS」をクリックすると、過去の障害情報が記載されています。これをRSSリーダーで読み取れば、過去をさかのぼって、障害履歴が確認することができます。一番下にあるリンク「AWS Post-Event Summaries」にアクセスすると、これまで起きた大規模障害に対する原因と対策レポートも確認できます。, 公式サイトでの障害発生情報は、小さな障害や単なるバグは記載されないこと、反映が遅いことから、現在の状況をリアルタイムに確認できません。そのため、参考程度に見るとよいでしょう。, AWSの調子が悪く、何が起きているのかすぐに確認したい場合は、Twitterを見ることをおすすめします。これは非公式情報ですが、誰かがつぶやいていたら、何かしら障害が起きた可能性が高いということです。, 東京リージョン関連の障害発生用の非公式Twitterアカウント（@awsstatusjp）もあるため、参考にしてみるとよいでしょう。これは、公式サイトの各サービス状況の横にあるRSSフィードを自動収集したものです。, これまで実際に起きた、AWSの過去の障害事例を紹介します。どのようなことが起きたのか、自社システムの可用性を高めるための参考にしてみてください。, 2011年にEU-WESTリージョンで障害が発生し、EC2・RDS・EBSのサービスにそれぞれ問題が発生しました。, これらのサービスは一旦停止され、利用者からはアクセスできないようになりました。原因は、電力事業者の110kv 10メガワット変圧器が故障したためです。, この故障により、完全に電力供給を失いました。通常であれば、バックアップの発電機から電力が供給されるのですが、大規模な地絡事故の影響もあり、正常に作動できなかったようです。停電時は短時間の電力供給をする無停電電源装置（UPS）が作動しましたが、電力をすぐに使い果たしてしまい、影響のあるサーバーは全てダウンしてしまいました。, 再発防止として、バックアップ発電機からの供給方法を改善し、大規模な事故に影響を受けないような仕組みを検討するとのことです。, 影響を受けた利用者に対しては、EBS ボリューム、EC2 インスタンス、RDS データベースインスタンスの利用料金10日分が提供されました。さらに、誤ってスナップショットのブロックを削除するEBS ソフトウェアバグの影響を受けた利用者には、EBS利用料金30日分が提供されることになりました。, 2011年にUS-EASTリージョンにおいて、EC2の障害が発生しました。サービスは停止状態になり、復旧するまでにかかった期間は約3日間です。, 原因は、ネットワーク増強時のヒューマンエラーでした。ネットワーク増強のために、スケーリング作業をします。最初の作業として、プライマリーネットワークのトラフィックを別のルーターに移動しなければならなかったのですが、誤って低レベルトラフィック側のルーターに分岐させてしまったようです。, ルーターは大量のトラフィックを扱いきれず、各ノードに問題を起こしていきました。一つの事象から、さまざまな問題を発生させ、結果的にはAZデータベースインスタンスの0.4%を損失してしまったのです。Amazonは、この事象で、大規模なリカバリ処理に多くのディスク容量が必要だと判明したため、大きくストレージの容量を増やすことを発表しています。, 問題発生により被害が出た利用者には、影響を受けたEBS ボリューム，EC2 インスタンス，RDS データベースインスタンス利用量の100%について、10日分のクレジットを提供することになりました。, 2012年6月にUS-EAST1リージョンで発生した事故により、InstagramやNetflixなどのサービスに影響を及ぼしました。, これは、自然災害による電源障害が原因です。嵐が起きた夜、電源がダウンしたため電力供給がUPSに切り替わったのですが、電力が枯渇して一部のデータセンターが停止したのです。, これが引き金となり、EC2・EBS・ELB・RDSなどのサービスに障害が発生し、複数のアベイラビリティゾーンに波及しました。電気供給は発電機に切り替わりましたが、通常運転に戻ったあと2度目の電力障害が起きてしまうなど、電力供給トラブルがたびたび発生。, 前例で電力障害によるサービス停止が相次いだにもかかわらず、再度このような問題が発生してしまいました。堅ろうにハードウエアを守っているデータセンターといえども、自然災害は想定できないような事象を発生させるようです。, 2012年12月24日のクリスマスイブにアメリカでAWSの障害が発生し、Netflixなどのサービスがトラブルに巻き込まれました。場所は、US-EASTリージョンです。, メンテナンス時のオペレーションミスが、システム障害を発生させました。発生箇所はロードバランサ―であり、このミスにより一部のステートデータが削除されてしまったのです。, 被害の拡大を止めるべく、ステートデータを復旧し、正常運用に戻しました。障害発生から復旧までにかかった時間は約1日です。この事象により、Amazonは運用中のELBステートデータに対するアクセスコントロールについて、変更管理システムの承認なしには変更できないようにしました。また、データリカバリープロセスも改善し、迅速にリカバリできるようにするとのことです。, 2016年にオーストラリア東海岸を襲った豪雨により、AP-SOUTHHEAST-2リビジョンで障害が発生しました。主に影響が出たサービスはEC2です。, 豪雨被害が深刻化する中、やがてEC2への接続障害が散見されるようになりました。発生していた事象は、電源障害です。回復措置として、電源の修理、影響を受けていたインスタンスの接続復旧作業を実施。事象が発生して、約18時間後に全回復しています。, 豪雨被害は、日本各地で多く発生しています。このように、システムがいつトラブルに巻き込まれるかわかりません。高い可用性を実現するためには、クラウドシステムといえども、状態の監視から遠隔地に設置した待機系への切り替えなどの仕組みを独自で導入しておくとよいでしょう。, 2017年に、US-EAST-1リージョンがダウンし、クラウドストレージであるS3のサービスが一部停止、もしくは全く使えなくなる事象が発生しました。, この障害は、サービスを利用している顧客のウェブサイトやアプリケーション、デバイスに影響を与えています。大きな混乱を招いた故障ですが、原因は作業中の誤ったコマンド入力によるものでした。ちなみにUS-EAST-1リージョンの利用者が少ない日本などでは、おもだった影響はなかったようです。, コマンドは確率された手順に則ったものでしたが、このように注意を払いながらも、原因不明な故障が起きる場合があります。作業は既知の問題に対処するためのものでした。メンテナンスを行う以上、稼働しているシステムに影響を与える可能性は大いにあるのです。クラウドサービスはデータセンターで電源を冗長化していたり、耐震設計のラックを利用していたりするなど、ハードウエアを守る対策は得意としています。, 最後は2019年のAP-NORTHEAST-1の東京リージョンで起きた障害事例を紹介します。この事象は主にEC2・EBSに影響を与えました。, 条件によっては、RDSやRedshift、ElastiCache またはWorkspacesにも不具合が発生しています。原因は、東京リージョンの単一アベイラビリティーゾーンでのオーバーヒートです。これにより、EC2インスタンスまたはEBSボリュームのパフォーマンスが低下しました。, データセンターは熱暴走を防ぐために、一定の低い温度で保つよう空調が整備されています。しかし、今回はその空調設備の管理システムに障害が発生したため、温度管理ができなくなってしまったのです。約3時間後に空調は回復し、室温も正常に戻りましたが、その後も回復措置が遅れます。通常は高可用性を実現するための制御システムが、異常事態では逆に悪影響を及ぼしていたからです。, Amazonは、空調ユニットを制御する方法の変更や、バグが発生した場合の制御システムのフェールオーバー機能を無効化にし、今後同じ事象が発生しないよう、対策を講じるとのことです。安心・安全設計のデータセンターでも、予期しないトラブルに巻き込まれる可能性は大いにあります。システムの設置場所を一つにするのではなく、遠隔地へ待機系を用意しておくなどの対策も有効でしょう。, 1．Auto Recoveryによる対策（AWSの標準機能）2．監視ツールと手動操作による対策3．バックアップによる対策4．HAクラスターによる対策, クラウドの標準機能で障害対策を取られているケースは多いと思います。例えばAWSの場合は EC2の「Auto Recovery」機能が有名です。, Auto Recoveryは、物理ホスト側の問題を検知してEC2インスタンスを自動復旧してくれるサービスです。EC2インスタンス上で動いているアプリケーションの障害までは検知してくれませんが、基板側の障害については一定の信頼を得られます。, しかし2019年の8月23日にAWSの東京リージョンで発生した大規模障害では、Auto Recoveryでも自動復旧に失敗するケースがあったようです。原因としては、Auto Recoveryは作動したが、肝心の物理ホスト側が障害から回復しておらずに自動復旧が失敗したのではないかと考えられます。, 多少止まっても影響が小さいシステムであればこの方式でも問題ないと言えますが、ECサイトや銀行ATMなど止められないシステムの対策としては、確実に別のAZ（Availability Zone）での復旧が対策になると考えられます。AZをまたいで復旧することで、別のAZで起こった障害から隔離できる確率が上がるといえます。, EC2上でZabbixなどの監視ツールを使って障害対策をされるケースもあります。監視ツールが障害を検知したら手動で再起動させるという運用もよく聞きます。この方式の長所は、Auto Recoveryでは検知できないアプリケーションの障害も監視ツールが検知してくれる点にあります。, 反面、手動操作を前提としているので、人的な負担や復旧時間の長さ、操作ミスのリスクがあります。また、今回のような大規模障害の場合は、そもそも仮想マシンの再起動の操作ができない可能性もあります。, 多少止まっても影響が小さいシステムであればこの方式でも問題ないと言えますが、止められないシステムの対策としては、自動的に障害を検知して別のAZで復旧できる仕組みが必要になります。, バックアップはどのシステムでも使われていますが、障害対策の観点では次の点に注意が必要です。, まずバックアップは、バックアップを取った時点の状態に確実に戻せます。この点はメリットでもありますが、障害が起きた時点のできるだけ近くの状態に戻すことはあまり得意ではありません。（RPO（目標復旧時点）の観点）, またバックアップからのリストアにはそれなりに時間がかかるので、大事なシステムをすぐに復旧させたい場合は注意が必要です。（RTO（目標復旧時間）の観点）, さらに今回のような障害時にバックアップを取ったデータを別のAZで復旧させたい場合には、ネットワークなどの環境の相違点の対応が必要になる場合もあります。多少止まっても影響が小さいシステムであればこの方式でも問題ないと言えますが、基幹系など止められないシステムの対策としては、RTOとRPOが短くかつ他のAZでも修正不要で復旧できる仕組みとの併用が必要です。, HAクラスターとは稼働系と待機系でサーバーを2台用意し、稼働系システムに障害が発生した際に自動的に待機系システムに切り替える仕組みです。, HAクラスターソリューションは、これまで説明した「障害の自動検知と自動復旧」「別のAZでの復旧」「RPOとPTOの短縮」すべてを実現するソリューションです。, 代表的なHAクラスターソリューションとしては、サイオステクノロジーのHAクラスターソフトLifeKeeperとデータレプリケーションソフトDataKeeperがあります。, LifeKeeperは当社のHAクラスター製品で、グローバルで25年・6万ライセンス以上使われている実績のある製品です。AWSやAzureなどのパブリッククラウドにもいち早く対応しており、既に多くの導入実績があります。, DataKeeperは当社のデータレプリケーション製品で、ブロックレベルのリアルタイム・レプリケーションにより、LifeKeeperに論理的な共有ストレージとして認識されます。これにより、物理的な共有ストレージが使えないクラウド環境でも、オンプレと同じ感覚でHAクラスターの構築が可能です。, 下記ページでは導入事例や詳細な構築手順ガイドを公開しております。ぜひこれらをご覧いただいて、今後のクラウド環境の障害対策にお役立てください。, AWSなどの大手クラウドプラットフォームサービスでも、多くの障害事例があります。システムを運用している限り、いつどのような事象が発生するのかわかりません。, 運用を守るためには、独自の高可用性を実現できる仕組みづくりが必要です。SIOS LifeKeeperは、ハードウエアからアプリケーションまで、幅広い障害を検知した際に自動で待機系へ切り替えます。素早い判断で、業務停止時間を大きく減らすことができます。, クラウドの障害から止められないシステムを守るためには、システム停止の許容時間やコスト負担に応じて様々な選択肢があります。自社の要件に応じて適切な方法を選び、対策を検討してみてはいかがでしょうか。, 企業の重要な業務アプリケーション環境を保護する、HAクラスターソフトウェアを開発・提供しています, しかし、この障害において、当社の高可用性ソリューションである「AZをまたいだHAクラスター構成」は被害を受けずサービス提供を継続できました。, AWSで障害が発生したことは、ダッシュボードから確認ができます。まずはAWSにログインし、管理画面を開きます。もし、画面右上にあるベル型のアイコンにチェックが入っていたら、何か情報があるということです。, そこをクリックすると、ダッシュボードが開き、「Open Issue」が確認できます。表示されている数字が発生した件数であり、イベント内容と事象が発生したリージョン名、発生日時が開示されています。, 発生しているイベントをクリックすれば右側のペインに開くため、そこで詳細情報を確認しましょう。, 」でも障害情報を確認できます。これは各リージョンのサービス状態を一覧で参照できるものです。, 各サービスの右にある「RSS」をクリックすると、過去の障害情報が記載されています。これをRSSリーダーで読み取れば、過去をさかのぼって、障害履歴が確認することができます。, 一番下にあるリンク「AWS Post-Event Summaries」にアクセスすると、これまで起きた大規模障害に対する原因と対策レポートも確認できます。, この故障により、完全に電力供給を失いました。通常であれば、バックアップの発電機から電力が供給されるのですが、大規模な地絡事故の影響もあり、正常に作動できなかったようです。, 停電時は短時間の電力供給をする無停電電源装置（UPS）が作動しましたが、電力をすぐに使い果たしてしまい、影響のあるサーバーは全てダウンしてしまいました。, 影響を受けた利用者に対しては、EBS ボリューム、EC2 インスタンス、RDS データベースインスタンスの利用料金10日分が提供されました。, さらに、誤ってスナップショットのブロックを削除するEBS ソフトウェアバグの影響を受けた利用者には、EBS利用料金30日分が提供されることになりました。, 原因は、ネットワーク増強時のヒューマンエラーでした。ネットワーク増強のために、スケーリング作業をします。, 最初の作業として、プライマリーネットワークのトラフィックを別のルーターに移動しなければならなかったのですが、誤って低レベルトラフィック側のルーターに分岐させてしまったようです。, ルーターは大量のトラフィックを扱いきれず、各ノードに問題を起こしていきました。一つの事象から、さまざまな問題を発生させ、結果的にはAZデータベースインスタンスの0.4%を損失してしまったのです。, Amazonは、この事象で、大規模なリカバリ処理に多くのディスク容量が必要だと判明したため、大きくストレージの容量を増やすことを発表しています。, これが引き金となり、EC2・EBS・ELB・RDSなどのサービスに障害が発生し、複数のアベイラビリティゾーンに波及しました。, 電気供給は発電機に切り替わりましたが、通常運転に戻ったあと2度目の電力障害が起きてしまうなど、電力供給トラブルがたびたび発生。, 前例で電力障害によるサービス停止が相次いだにもかかわらず、再度このような問題が発生してしまいました。, 堅ろうにハードウエアを守っているデータセンターといえども、自然災害は想定できないような事象を発生させるようです。, 被害の拡大を止めるべく、ステートデータを復旧し、正常運用に戻しました。障害発生から復旧までにかかった時間は約1日です。, この事象により、Amazonは運用中のELBステートデータに対するアクセスコントロールについて、変更管理システムの承認なしには変更できないようにしました。, また、データリカバリープロセスも改善し、迅速にリカバリできるようにするとのことです。, 豪雨被害が深刻化する中、やがてEC2への接続障害が散見されるようになりました。発生していた事象は、電源障害です。, 回復措置として、電源の修理、影響を受けていたインスタンスの接続復旧作業を実施。事象が発生して、約18時間後に全回復しています。, 豪雨被害は、日本各地で多く発生しています。このように、システムがいつトラブルに巻き込まれるかわかりません。, 高い可用性を実現するためには、クラウドシステムといえども、状態の監視から遠隔地に設置した待機系への切り替えなどの仕組みを独自で導入しておくとよいでしょう。, この障害は、サービスを利用している顧客のウェブサイトやアプリケーション、デバイスに影響を与えています。, 大きな混乱を招いた故障ですが、原因は作業中の誤ったコマンド入力によるものでした。ちなみにUS-EAST-1リージョンの利用者が少ない日本などでは、おもだった影響はなかったようです。, コマンドは確率された手順に則ったものでしたが、このように注意を払いながらも、原因不明な故障が起きる場合があります。, 作業は既知の問題に対処するためのものでした。メンテナンスを行う以上、稼働しているシステムに影響を与える可能性は大いにあるのです。, クラウドサービスはデータセンターで電源を冗長化していたり、耐震設計のラックを利用していたりするなど、ハードウエアを守る対策は得意としています。, 条件によっては、RDSやRedshift、ElastiCache またはWorkspacesにも不具合が発生しています。, 原因は、東京リージョンの単一アベイラビリティーゾーンでのオーバーヒートです。これにより、EC2インスタンスまたはEBSボリュームのパフォーマンスが低下しました。, データセンターは熱暴走を防ぐために、一定の低い温度で保つよう空調が整備されています。しかし、今回はその空調設備の管理システムに障害が発生したため、温度管理ができなくなってしまったのです。, 約3時間後に空調は回復し、室温も正常に戻りましたが、その後も回復措置が遅れます。通常は高可用性を実現するための制御システムが、異常事態では逆に悪影響を及ぼしていたからです。, Amazonは、空調ユニットを制御する方法の変更や、バグが発生した場合の制御システムのフェールオーバー機能を無効化にし、今後同じ事象が発生しないよう、対策を講じるとのことです。, 安心・安全設計のデータセンターでも、予期しないトラブルに巻き込まれる可能性は大いにあります。システムの設置場所を一つにするのではなく、遠隔地へ待機系を用意しておくなどの対策も有効でしょう。, さらに今回のような障害時にバックアップを取ったデータを別のAZで復旧させたい場合には、ネットワークなどの環境の相違点の対応が必要になる場合もあります。, 多少止まっても影響が小さいシステムであればこの方式でも問題ないと言えますが、基幹系など止められないシステムの対策としては、RTOとRPOが短くかつ他のAZでも修正不要で復旧できる仕組みとの併用が必要です。, AWSで「インターネットに出てはいけない」要件を解決する方法～PrivateLink対応～, Amazon CloudWatchの監視項目を解説！標準・カスタムでできることと注意点, SQL Server を「Microsoft Azure」上に移行する際の課題と方法。そしてAzure上でのデータベースの可用性をさらに高めるLifeKeeper/DataKeeper. @B86zH7ldAVDmgNP, 注目度の推移をご覧いただくには、JavaScriptの設定を有効にしていただく必要があります。, 2020年 9月17日2020年 9月18日2020年 9月19日2020年 9月20日2020年 9月21日2020年 9月22日2020年 9月23日2020年 9月24日2020年 9月25日2020年 9月26日2020年 9月27日2020年 9月28日2020年 9月29日2020年 9月30日2020年 10月1日2020年 10月2日2020年 10月3日2020年 10月4日2020年 10月5日2020年 10月6日2020年 10月7日2020年 10月8日2020年 10月9日2020年 10月10日2020年 10月11日2020年 10月12日2020年 10月13日2020年 10月14日2020年 10月15日2020年 10月16日2020年 10月17日 この例ではService Health Dashboardのタブを一つ指定して処理をするようにしました。 aws アカウントを無料で作成 Amazon は男女雇用機会均等法を順守しています。 人種、 出身国、性別、性的指向、障がい、年齢、その他の属性によって差別することなく、平等に採用選考の機会を提供して … まで, ※番組に関するキーワード、およびグラフはTwitterへの投稿データをもとに表示しています。放送局が提供する情報とは一切関係ありません。. 1 aws障害情報の集め方2 awsの障害を予防するためにできる対策3 今までに起きた障害一覧4 まとめawsがいくら素晴らしいといっても、やはり人間が作ったもの。つまり、awsも一般的なコンピュータシステムと同じように障害は発生しているの Service Health Dashboard にあります。 下記のように、現在の情報 (Recent Events) と、過去の情報 (Remaining Services) に分かれています。 右側の「RSS」をクリックすると、過去の障害履歴が載っています。ただ … AWSも無敵ではありません。, AWSに障害が発生した場合には、こちらのサイトでアナウンスされます。 ちょっと確認してみるか... AWS障害だと知らずにデータ消えたかもってなったから心配になって引き継ぎ再設定する始末, AWS障害のソースがわからん AWS上のシステムを運用している人たちにとって、AWSの障害情報の収集は大切なお仕事の一つです。少しでも自分に合った形で効率的に情報収集できるやり方を見つけたいものですね。 この記事をシェアする. ちなみに、私はあまりこだわりがないのでFeedlyを使用しています。IFTTTの連携は面白いのですが、なかなか最適な形にするのは難しいです。上記の方法も正直まだ不完全なので、あくまで参考程度でお願いします。, AWS上のシステムを運用している人たちにとって、AWSの障害情報の収集は大切なお仕事の一つです。少しでも自分に合った形で効率的に情報収集できるやり方を見つけたいものですね。. Wi-Fiに繋げる Statusはオールグリーンでインシデント記録も見当たらない。, にのみだいじょうぶかな笑笑 twitter.com/Trainfo_NEWS/s…, む、AWSトラブってる？？ twitter.com/Trainfo_NEWS/s…, ともくんが過労死してしまう！ twitter.com/Trainfo_NEWS/s…, @HSakai7 DAZN繋がりません。大規模な障害が起きているみたいです。twitter.com/Trainfo_NEWS/s…, ON行政書士事務所/ONネット戦略コンサルティング【行政手続/法律関係＆ホームページ/チラシ制作】, 日本のIT力が低下し、外資サービスにばかり依存しているから、GoogleやAmazonがトラブルと影響がデカイ twitter.com/Trainfo_NEWS/s…, なんかすごいトラブルが発生しているらしい。サッカー民が爆発している・・・ twitter.com/Trainfo_NEWS/s…, 繋がらないと思ったらコレか。 Wi-Fi切る 26日18時ごろから、「TVer」「Hulu」「Paravi」「DAZN」などのサービスや、 現在AWS障害！ 大手にログインできない状態！？ ApacheWebServer障害？ これだったら物凄い広範囲になると思うけど、 今はAHSなのか？ You seem to be reading articles frequently this month. 軽くググって先人たちがいろいろやっていた形跡は見つけられたのですが、どれも情報が古くてこれだってものがありませんでした。, で、試行錯誤して以下のようにOPML形式でファイルを作成すれば、RSSリーダーにインポートできるようになりました。・・・って、こんなことはみなさんもやってますかね。。 １４日午後１１時５０分ごろ、千葉市若葉区桜木の歩道上で、「血だらけで人が倒れてい... 【これはひどい】「GoToトラベル事務局」に大手旅行代理店の社員が出向、ほとんど仕事せず日当４万円. https://dev.classmethod.jp/articles/service-health-status-history/, https://status.aws.amazon.com/data.json https://status.aws.amazon.com/, こちらのサイトにはRSSも配信されているので、RSSリーダーでチェックしておくと良いですね。 全リージョンの障害情報が取得できるJSONの存在. ※以下、全部だと多すぎますのでAsia Pacificに絞っています。, 上記のファイルをFeedlyなんかに入れてあげて、Chromeの拡張機能でFeedly Notifierを使えばもうバッチリですね。, 最後に、いまの時代、情報を収集して閲覧するのにはいろいろなツールやWebサービスがありますよね。RSSリーダーは使っていないという人向けに、おまけのもう一工夫いってみます。今回は、Twitterに連携してみたいと思います。「今回は」というのは、これから紹介する方法であれば、いろいろなツールと連携が可能ですので、ぜひ参考にいろいろ試してもらえるとよいかと思います。, IFTTTとは、いろいろなWebサービスたちを相互に連携させることができるWebサービスです。これを使えば、簡単にFeedlyからTwitterに連携できてしまいます。・・・とやりたかったのですが、残念ながらFeedlyからIFTTTへの連携には、Feedlyをアップグレード（有償）しないといけないようです。うーん、悔しい！, ということで、代わりにInoreaderというRSSリーダーを使用します。ログイン後の画面はこんな感じです。, そして、試しに一つ登録してみるとこうなります（無料版なので広告が表示されてしまいます）。, 次に、IFTTTへ連携させるために少し設定をします。上記画面の右上の歯車アイコンから設定画面を表示させ、「購読とアイテム」という項目を選択します。, 上記画面で、対象アイテムの左側にあるチェックボックスにチェックを入れ、「バンドルの作成」というプルダウンメニューから「新規フォルダーに追加」を選択し、「Go」ボタンをクリックします。今回は、”AWS Service Status”というフォルダ名にしました。あと、ついでに対象アイテムの右側にあるロケットアイコンをクリックしておきます（詳細な説明は省略します）。, 最後に、設定画面で「フォルダーとタグ」を選択します。先ほど作成したフォルダ名が表示されていますので、右側の「エクスポート OFF」をクリックして「エクスポート ON」にしてください。すると、「RSSフィード」が表示されるので、このURLを控えておきます。, 上部メニューから「My Recipes」を選択し、「Create a Recipe」をクリックします。, レシピの作成画面が表示されたら、そこからはフィーリングでポチポチしていく（RSSとTwitterを選択）と以下の画面にたどり着き、「Create Recipe」をクリックすれば完了です。, さて、いかがでしたでしょうか？ 米Twitterのサービスで、日本時間の10月16日午前から障害が発生しており、... 【未開封費】グッズ代行に未開封費要求で騒然 「普通未開封でしょ？」 ツイステ、あんスタ界隈にも出没？. daznを落とす Qiita can be used more conveniently after logging in. Qiita can be used more conveniently after logging in. こんにちは、城内です。 https://aws.amazon.com/jp/premiumsupport/technology/pes/, https://status.aws.amazon.com/rss/all.rss, https://status.cloud.google.com/incident/storage/19002, Google App Engine で 74円で 独自ドメイン + SSL証明書を設定してみよう, Google App Engine (GAE) チュートリアル – GAEアプリ・サービス・バージョン・インスタンス理解編. [CDATA[AWS Service Status]]>', ' http://status.aws.amazon.com/', '