AWS・Azure・GCPのSLAを徹底分析、共通して役立つ大規模障害への3つの備えとは（ビジネス＋IT） - Yahoo!ニュース
DX（デジタルトランスフォーメーション）の推進などで、クラウドサービスの導入が加速している。コスト効率や柔軟性、可用性の観点で好まれている一方で、クラウド障害によるリスクも拡大。クラウドサービスの提供会社はSLA（サービス品質保証）で高い可用性を保証しているが、実際は大小さまざまな障害でサービスの停止が起きている。しかしサービスが停止してもSLA違反として一部料金が返金されるのみで、さらには提供者側の障害に利用者が気付かなければSLA違反による補償を受けられない危険性がある。本稿では、そんなクラウド障害による影響と対応策について解説する。 【詳細な図や写真】クラウド障害の際にSLAの保証を受けるために必要なこととは（Photo/Getty Images） ●クラウド障害を見逃せば「SLA」の補償は受けられない？ 大規模なクラウドサービスの障害が国内外で相次いで発生している。AWS（Amaz
API gateway + lambda + S3でDDoS攻撃を受けて1日あたりで$3000溶かした話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? qiita夏祭りに乗り遅れてしまったので一人後夜祭 ~2019年某日~ パイセン「それじゃあ、ワイ君は明日からフロントのログデータを飛ばすのにAPI gatewayとlambdaでS3に保存するようにしてな。木曜までな。その間に自分はサービンのドメイン取ったりRoute53周りの構築するから」 ワイ「これもcloud formationに書くんです？」 パイセン「serverless frameworkっていう基本的な設定はデフォルトで構築してくれる便利なものがあるんやで。これ使い」 ワイ「めっちゃ素敵やん。わかったやで」 パイセン「週
AWS、12月7日の大規模障害について説明 ステータスページの改善を約束
米Amazon傘下のAmazon Web Services（AWS）は12月10日（現地時間）、7日に発生した大規模なサービス障害の原因について説明した。この障害は主に米東海岸地域に影響したが、日本でも任天堂のネットワークサービスが影響を受けた。 この障害では、顧客への状況報告が伝わりにくく、「一部の顧客がこの問題に関する情報を見つけることが困難になったことが分かった」ので、「来年初頭に、Service Health Dashboard（ステータスページ）を改善し、新しいサポートシステムをリリースする」としている。 この障害はバージニア州北部地域で午前10時30分ごろに発生。原因は「メインのAWSネットワークでホストされているサービスの1つの容量を拡張する自動化機能で、内部ネットワーク内の多数のクライアントから予期しない動作が発生した」ことという。これにより、接続アクティビティが急増してネ
Summary of AWS Direct Connect Event in the Tokyo (AP-NORTHEAST-1) Region
日本時間 2021 年 9 月 2 日に東京リージョン（AP-NORTHEAST-1）で発生した AWS Direct Connect サービスの中断に関する追加情報を提供いたします。午前 7 時 30 分(以下すべて日本時間)から、Direct Connect をご利用中のお客様は東京リージョンに向かうトラフィックについて断続的な接続の問題とパケットロスの増加を観測し始めました。この事象は、Direct Connect ロケーションから、顧客の Virtual Private Cloud（VPC）が存在する東京リージョンのデータセンターネットワークへのネットワークパスに沿ったネットワークレイヤーの 1 つでネットワークデバイスの一部に障害が発生したことが原因です。お客様は午後 12 時 30 分に復旧を観測しはじめ、午後 1 時 42 分に接続の問題は完全に解決されました。 アベイラビリ
今までに起こった AWS 障害情報履歴
今までに起こった AWS 障害情報履歴 AWSに過去どのくらい障害が発生したかを調べる必要がでたので、AWSが公表している公式の情報がないかを探してみるも、公式情報が全然見当たらない・・・。 仕方ないので、AWSサポートに問い合わせてAWSエンジニアの方へ電話で確認するも、AWSとしては過去の障害についてまとめて公表をしていないとの事でした。 SLAのからみなどから、きっと正式に公表がむずかしいのかもですね。 ということで、AWS公式情報がないので非公式情報ではありますが、ネットで確認調べる限りの情報をまとめてみました。 AWSは全世界にリージョンがありますが、日本のリージョン（東京と大阪）に絞って記載します。 2021年02月19日(金) az1障害発生 障害発生時間 ：約6時間 （2/19 23時 ～ 2/20 5時） 影響範囲 ：az1 のEC2、EBS 原因 ：セクショ
AWSのフランクフルトAZ障害、消火システム誤作動により入室遮断、復旧対応が出来ず | Data Center Café
AWSのフランクフルトAZ障害、消火システム誤作動により入室遮断、復旧対応が出来ず Data Center Cafe 2021.06.128,166 views 空気循環システムの故障により、AWSのフランクフルトのアベイラビリティゾーンが3時間にわたり停止しました。通常では日常的に行われている作業が、消火システムが作動したことで不可となり、状況が悪化したようです。 問題は消火システムが空気中の酸素を除去してしまったため、約1時間の間、スタッフは復旧作業でデータホールに立ち入ることができず、停止時間が長引いたことです。Amazon Web Servicesのステータスページによると、現在はすべてのシステムが正常に動作しているとしています。なお、今回は1つの アベイラビリティゾーン での障害であったため、お客様への影響は限定的であったとのことです。 入室抑制システム障害は13：18PDT（日
地雷を避けながら進むEKS - 俺の屍を超えていけ -
2021年3月11日〜12日で開催の「CloudNative Days Spring 2021 Online」における発表資料です。 3月12日 15:20-16:00 Track B 「地雷を避けながら進むEKS - 俺の屍を超えていけ -」 https://event.cloudnativedays.jp/cndo2021/talks/491 ｰｰｰ サクッとK8sクラスターを作れるAmazon Elastic Kubernetes Service（以下EKS）ですが、ちょっと真面目に使おうとすると色々と「あるぇ？」ってなることにもポツポツ出くわします。 今回は、EKSが持つ機能もちょこちょこ紹介しつつ、地雷っぽいところ（私が踏み抜いたもの）とかTipsなんかをお話しします。主に初級〜中級あたりの視聴者をターゲットにしています。 これからちょっと本気出してEKS使っていくかぁ！っていう
【保存版】東京リージョンの AWS 障害発生時にクラスメソッドのテクニカルサポートチームがやっていること | DevelopersIO
どのような事前準備をしているか 有事の際は想定外のことが発生しやすく、事前準備をしていないと冷静な対応が難しくなります。 いきなりしっかりした事前準備をすることは難しいので、徐々に成熟度を上げていきます。 本章では以下の観点で、事前準備についてご紹介します。 手順書 自動化 訓練 手順書 フローやチェックリストを含む手順書を準備しています。 手順書の内容は後述します。 分かりやすい手順書を準備することも重要ですが、その手順書への導線づくりも大切にしています。 運用周りのドキュメントは数が多く、目的のドキュメントが埋もれてしまい他のメンバーが見つけられない場合があるからです。 周知に加えて、ドキュメントの階層を見直したり、特定チャンネルに手順書の URL をピン留めしておくなど、手順書に辿り着きやすくする工夫をしています。 分かりやすい手順書の書き方については、以下のブログが参考になります。
AWSでAZ障害が起きたので困ったことを書いておく - なんかかきたい
前にも似たようなこと書いたなと思ったけどもう一年半も前のことになるのか t-cyrill.hatenablog.jp ご存知の通り昨日 2021/02/19 23:20頃 AWSにて東京リージョンの一つ apne-az1 にて大規模な障害が発生。多くのAWSを利用していたサービスで影響があった。 そんな私はいつものように アラストリリィ アサルトリリィ ラストバレット というゲームを呑気にプレイしていたのだけど、23:25 から緊急メンテに入ってしまった。 どうしたんだろうと思っていたら、社内SlackにてAWSを利用しているサービスがたまに応答しなくなる、Elasticacheが切り替わったなどなどの報告が入り、もしかすると面倒ごとかなと思いながら対応することになった。 起きていたこと 既にAWSからも公開されていることであるが、今回は2019年8月に起きた障害と類似するタイプの障害だっ
「Athenaで170万円請求」「EC2が復旧できない」 AWSしくじり先生 part.1
Cloud Operator Days Tokyo は、クラウドの運用者に焦点を当てた技術者向けの新しいテックイベントです。AWS環境の運用を手がけるアイレット株式会社のインフラエンジニア古屋氏が、実際にやってしまったしくじりを紹介。原因と対策を語ります。まずは「Athenaで170万円請求」「EC2が復旧できない」 というしくじりから。（全2回） しくじり先生 on AWS 古屋啓介氏（以下、古屋）：では「しくじり先生 on AWS」ということで、始めたいと思います。よろしくお願いします。今日は、AWS環境を使って日々運用していく中で発生した、しくじり、失敗事例。そしてそのしくじりの原因と、そこから得られた教訓についてお伝えしようと思います。 今日このお話を聞いたみなさんの中で「あ、うちの環境どうっだったかな？」と、思われる方もいらっしゃるかもしれません。今日お伝えすることの中で、ちょっ
AWSが11月の大規模障害について説明
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Amazon Web Services（AWS）は、米国時間11月25日に発生した大規模障害についての説明を公開した。この障害では、何千ものサードパーティーのオンラインサービスが数時間にわたって影響を受けた。 数十におよぶAWSのサービスも影響を受けたが、同社によれば、障害が発生したのはバージニア北部のUS-EAST-1リージョンだけだった。同社によれば、ことが起こったのはKinesisサーバーのフロントエンドフリートに「小規模な容量の追加」を行った後だったという。 Kinesisはデータや動画のストリームをキャプチャーし、AWSの機械学習プラットフォームで処理するサービスであり、顧客にも使用されているが、「CloudWatch」や認証
S3の署名付き URLを利用する際に注意する3つのポイント #aws #s3 #lambda #python #serverless - uchimanajet7のメモ
今回は みんな大好きAWS S3ですが、署名付き URL（Pre-Signed URL）という便利で素敵な機能が利用できます。 非常によく利用される機能なので、ここで稚拙な 説明を書くようなことは割愛しますが、公式ドキュメントだと以下 Amazon CloudFront のドキュメントに詳細が書かれています。 docs.aws.amazon.com 今回はこのS3の機能をPython AWS Lambda で利用する際にハマったポイントを共有します。 Boto3 ドキュメントの確認 今回利用したAWS SDK Python（Boto3）のドキュメントを確認してみると boto3.amazonaws.com generate_presigned_url(ClientMethod, Params=None, ExpiresIn=3600, HttpMethod=None) となっており Cli
身に覚えのない170万円の請求が……AWSの運用管理で起きた“4つのしくじり”
「AWSを使って構築したお客さまの環境を日々運用していく中で、これまでさまざまな失敗を経験してきた」――アイレットの古屋啓介さん（クラウドインテグレーション事業部インフラエンジニア）は、クラウドインフラの運用管理者向けイベント「Cloud Operator Days Tokyo 2020」のセッションでこう明かした。 アイレットはクラウド専業のSIer。AWS（Amazon Web Services）のマネージドサービス「cloudpack」なども提供しているが、細かい仕様の見落としなどが原因で、cloudpackの運用でいくつかの“しくじり”があったという。 身に覚えのない170万円の高額請求がAWSから来た 古屋さんによると、特に印象に残っている失敗は4つ。その1つ目は「Amazon Athena」で170万円の請求が来たことだ。 AthenaはAWSが提供するPaaSで、オンラインス
【小ネタ】AWSで過去に発生した障害の履歴を確認する方法 | DevelopersIO
中山（順）です AWSの利用を検討する方は、AWSの信頼性がどの程度のものなのか、気になるのではないでしょうか？ Amazon.comのCTOであるWerner Vogelsが"Everything fails, all the time"と述べているとおり、 システムに要求する信頼性に応じてシステムを構成するコンポーネントを冗長化して信頼性を高めることが基本です。 (Design for Failure) とはいうものの、システムの信頼性はシステムを構成するコンポーネント自体の信頼性や連携する外部サービス / サービスが稼働するインフラストラクチャの信頼性にも依存します。 AWSが各サービスやインフラストラクチャの信頼性向上についてどのような取り組みを行ってるかについては、イベントのプレゼンテーションやホワイトペーパーなどで公開されています。 例えば、AWSのグローバルネットワークやリー
10日間 で AWS Lambda 関数を 28億回 実行した話｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
はじめに こんにちは、エンジニアの内山です。 最近は AWS を使ったサーバレス開発に従事しています。 今回は、サーバレス開発時にやらかしてしまったお話です。 どんなことが起こった？ プログラムのバグが原因で、AWS Lambda 上で再起呼び出しの無限ループが起こりました。さらに発生時にはそのことに気づけませんでした。 発生時から 10 日後の月末に、請求額が想定よりも異常に高いという報告を受け、その時点で初めて無限ループが起こっていることが発覚しました。 10 日間 で、AWS Lambda 関数が 28億回__ほど実行されており、付随するサービス(X-Ray/CloudWatch Logsなど)の料金も加わって、__27万円 ほどの料金が発生してしまいました。 経緯 ある Lambda 関数から別の Lambda 関数を非同期で実行する処理を実装していました。実際とは少し違いますが、
「AWS」「Azure」「GCP」で相次ぐ障害 クラウドを信じ切ってよいのか
関連キーワード Amazon Web Services | Microsoft Azure | Google | クラウド運用管理 「Amazon Web Services」（AWS）や「Microsoft Azure」「Google Cloud Platform」（GCP）の3大クラウドサービス群で、2019年11月にサービスの低下や停止が相次いだ。何が起こったのか。 AWSの各サービスの稼働状況を示すステータスページ「AWS Service Health Dashboard」によると、AWSのフランクフルトのリージョン（データセンターの設置地域）において2019年11月11日（現地時間、以下同じ）に障害が発生した。障害が発生したサービスは仮想マシン（VM）サービス「Amazon Elastic Compute Cloud」（Amazon EC2）とリレーショナルデータベースサービス「A
大規模障害から見るAWSのバックエンド #awswakaran_tokyo
# 大規模障害から見るAWSのバックエンド #### 2019/09/25 #awswakaran_tokyo ### 株式会社ドリコム インフラストラクチャー部 中村 昴 (@varu3) --- # 自己紹介 - ばるさん - twitter: varu_3 - github: varusan - Blog: https://varu3.hatenablog.com/ - インフラストラクチャー部 - 弊社で運用しているソーシャルゲーム、WEBサービスの主にインフラ部分を管理している部署です - 社内サービス（GitLabやRPMパッケージ） - AWS, GCP, 国内パブリッククラウド, Kubernetesなど --- # 2019年8月23日.... --- # 止まるインスタンス... # 鳴り止まないアラート... # 流速が増すTwitterのTL... # 加熱する報道
AzureやAWSの大規模障害でもサービスが停止しない設計とは
こんにちは！FIXER R&D Division担当、フェローの千賀です。 今日は、先日8月23日に発生したAWSでの大規模障害を受けて、クラウドを使ってシステムやサービスを構築、提供する際の考え方や留意事項等をお伝えし、止まらないサービスを作るにはどうしたらいいかをアーキテクチャの観点から解説したいと思います。 AWSでの障害の内容と原因 まず簡単に、AWSで2019年8月23日に発生した障害の原因や内容を簡単に解説します。既に当ブログでも取り上げ、報道などもされておりますのでご存知の方も多いかもしれませんが、同日正午過ぎごろから22時過ぎまでの間、AWS東京リージョンにて、EC2やRDSへの接続障害など発生しました。原因は冷房をコントロールする制御システムを中心とする多重障害であり、サーバの温度が上がりすぎたことによる過熱である、と報告されています。 これにより約10時間に渡って、AW
万が一の障害にも耐えられるようにするためのAWS利用ガイド – 株式会社サーバーワークス
サーバーワークス、無料ebookダウンロードシリーズ 2 万が一の障害にも耐えられるようにするためのAWS利用ガイド 東京リージョンの1つのアベイラビリティゾーンで発生した、制御システムの複合的な不具合によって、いくつかのAWSサービスが影響を受けました。 ECサイトやゲームを含む国内多数のサービスにも影響が生じ、クラウド利用に対する不安が広がりました。今回のような障害に備えるためには、提供しているサービスの稼働レベルを考慮した上で最適な構成を選ぶことが求められます。 当社はAWSのプレミアコンサルティングパートナーの視点で障害発生時からホームページ等で障害に対するお知らせや提言を公開してまいりました。今回それらをまとめ対策として解説することで、お客様のクラウド環境最適化に寄与できると考え、この度レポートの公開に至りました。 本ホワイトペーパーの目次 発生した障害の概要 障害発生時のユーザ
AWS障害、どうすれば回避できた？ 冗長性はどこまで？ AWSのパートナー企業に聞く
AWS障害、どうすれば回避できた？ 冗長性はどこまで？ AWSのパートナー企業に聞く（1/2 ページ） 8月23日、Amazon Web Services（AWS）東京リージョンで大規模な障害が発生した。東京リージョンの1つのアベイラビリティゾーン（Single-AZ）で発生した障害で、Amazon EC2とAmazon EBSに影響があった。またAmazon EC2をベースにしてるであろうAmazon RDS、Amazon ALB、Amazon ElastiCache、Amazon Redshift、Amazon Workspacesなども影響を受けた。今回の障害では復旧までに時間がかかったこともあり、決済サービスやオンラインゲームなど多くのサービスが動かない状況に陥った。 障害発生当初は「データセンターのラックの数本が死んだ程度で、直にリカバリーされて上がってくるのではとみていた」とい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
