Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く
AWSの米国東部リージョン（US-EAST-1、バージニア北部）において2月28日に発生したAmazon S3の障害の原因と対策などについて、AWSが報告を公開しました。 Amazon S3がダウンした直接の原因は、Amazon S3課金システムのデバッグ作業中に入力したコマンドのミスによって多数のサーバが削除されたことでした。また、それによって引き起こされたサブシステムの再起動に時間がかかったことが、障害を長引かせる要因になっています。 この記事ではAWSの報告内容を整理し、発生した出来事を時系列でみたあと、障害の背景にあった技術的な要因と対策を紹介します。 コマンドの入力ミスで多数のサーバを削除、復帰にも長時間かかる そもそもの障害の発端は、Amazon S3課金システムの処理速度が想定よりも遅くなっていたため、Amazon S3チームがデバッグ作業を行っていたことでした。 2月28日
LINE Bot API の HTTPS Callback は Amazon API Gateway を使うと簡単便利安価で最高 - おともだちティータイム
追記 (4/15) 現在は Let's Encrypt の証明書が利用できるようになっているようです。なので「https で Callback が受け取れない」と言う理由のためだけに Amazon API Gateway を使う必要も無くなりました。 LINE Bot API は Callback URL が https のみで、しかも Let's Encrypt や StartSSL と言った無料の証明書が使えない。どうにか安価で Bot を動かしたいとなると Heroku のようなドメインを指定しなければ Wildcard 証明書が割り当てられている PaaS を使うのが一般的でしょう。 しかし Heroku は外に抜ける IP アドレスがどんどん変わっていくので、 Bot API の IP Whitelist に登録することが出来ない。仕方無いので Heroku に rack-rev
米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る
Amazon EC2は9月末、その内部で使用しているXenハイパーバイザのセキュリティリスクに対処するため、全インスタンスの約10％にあたるインスタンスに対して段階的にリブートを行うメンテナンスを実行していました。 リブートをユーザーが回避する手段はなく、AWSから事前に通知を受けたユーザーはリブートによってデータを失ったりシステムがダウンしたりしないように、何らかの処置をする必要がありました。 AWS上で大規模なシステムを運用しつつもこのメンテナンスリブートを難なく乗り切ったのが、米国で動画配信サービスなどを運用するNetflixです。その理由は同社が開発したChaos Monkeyというツールにありました。 同社のブログにポストされた記事「A State of Xen - Chaos Monkey & Cassandra」で、その顛末が紹介されています。 Chaos Monkeyによっ
オンプレミスから AWS に移行して変えた 3 つのこと
7 月に開催された「JAWS-UG 三都物語 2014」でも発表したとおり、自分が関わっているプロダクトをオンプレミスから AWS に移行しました。 JAWS-UG 三都物語 2014 に登壇しました 移行して 2 ヶ月ほど経ちましたが、目立った障害もなく安定した運用を続けています。スライドでも少し触れていますが、これまでのやり方を大きく変えるキッカケにもなりました。 今回は「オンプレミスから AWS に移行して変えた 3 つのこと」と題して、社外に公開できる範囲でご紹介します。 稼働中のサーバに変更は加えない いわゆる Immutable Infrastructure の考え方を取り入れました。最初は流行りに乗りたかったという気持ちが大きかったのですが、今では昔のやり方にはもう戻れません。 オンプレミスでは本番稼働中のサーバにログインして何か変更するということが当たり前に行われていました
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
サイトを Amazon S3 に移行しました - WebOS Goodies
WebOS Goodies へようこそ！ WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。 遅ればせながら、新年明けましておめでとうございます。今年もよろしくお願いいたします。 2008 年に移行してからずっと XREA で動いていたこのブログですが、さすがにこのご時世にレンタルサーバーはないだろということで、年末年始の休みを利用して Amazon S3 に移行してみました。 DNS は以前から Route 53 に移行済みなので、サイトのほぼ全体で 9
Amazon EC2 と Route 53 のはじめかた その 3 : Amazon Route 53 を試す - WebOS Goodies
WebOS Goodies へようこそ！ WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。 本日は「Amazon EC2 と Route 53 のはじめかた」 3 回シリーズの最後（3 回目）で、 Amazon Route 53 をご紹介します。ちなみに前 2 回の内容は以下のとおり。 サインアップ Amazon EC2 を試す Amazon Route 53 を試す（この記事です） Amazon Route 53 は比較的マイナーなサービスなのでご存じ
高速にWordPressを動作させる網元を使うべくAWSにブログを移転しました。その手順を備忘録として残します。 ｜https://wp.yat-net.com/name
2012年 12月 06日 高速にWordPressを動作させる網元を使うべくAWSにブログを移転しました。その手順を備忘録として残します。 カテゴリ： AWS タグ：AWSWordPress このブログをAWS(Amazon Web Services)で提供しているEC2に変更しました。前々からロリポップに対しての限界点がある程度見えていて、いずれ変更することになるけども、それならもうやっておこうかなと言う思いで変えちゃいました。今回はその備忘録として記事にしたいと思います。 1.AWSとは？EC2って？ 2.AWSのメリット・デメリット 3.今回の環境について 4.導入手順 5.サーバーと接続する SSHとSFTPについて 6.料金の確認 7.最後に 8.追記 AWSとは？EC2って？ AWS(Amazon Web Services)というのは、あの多くの人が利用しているECサイトであ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Documentation