AmazonのCloudFrontの障害規模はどれくらいだったのか？
By BFLV Amazonの「CloudFront」は、大容量アプリケーション・音楽・動画・オンラインゲームなどのブロードバンドコンテンツの配信を安定かつ低コストで行うためのコンテンツ配信ネットワーク(CDN)と呼ばれるものです。 そんなCloudFrontのDNSにて障害が発生し、CloudFront経由で配信されていたさまざまな画像などのコンテンツが表示されなくなる、という恐ろしい事態が発生。 AWSのCloudFrontのDNSで障害中。いろんなところで影響でまくり。AWSのサイトもめちゃ重いｗｗｗ #AWS #cloudfront #DNS— Shogo Matsudo (@ShowRiseGo) 2014, 11月 27 Instagramなどの大手ウェブサービスにもその影響があり、サイト上に何も表示されないという非常事態に。 instagram when amazon's d
こんにちは、虎塚です。 Amazon Route 53でドメインが管理できるようになって数ヶ月がたちました。Route 53では、Amazon Route 53でドメインを購入する ｜ Developers.IOにあるように、ドメインを新規に取得することができます。さらに、別のドメインレジストラで登録していたドメインを、移管して管理することもできます。 そこで今日は、他のドメインレジストラに登録しているドメインをRoute 53へ移管する手順を紹介します。例として、 お名前.comで管理しているドメインを想定して説明します。 ちなみに、移管手続きからAmazon側での処理完了までの所要時間は、移管元の事業者によって異なります（移管元が何も応答しなかった場合、5〜7日間かかるとのことです）。今回は約6時間でした。 はじめに この記事の内容は、AWSの公式ドキュメントをスクリーンショット入りで
実践！ヌーラボサービスでの CloudFront の障害対策 | 株式会社ヌーラボ(Nulab inc.)
CDNが単一障害点にならないようにするために ヌーラボでは 2010 年 Cacoo の商用サービスの開始に合わせて AWS における運用を開始しました。当時、運用環境として AWS を採択する決め手の一つになったのが CloudFront でした。その後も着々とエッジロケーションは増え、独自ドメインのサポートなど魅力的な機能も提供され、今ではヌーラボの全サービスの静的ファイルの配信で利用している、無くてはならないサービスとなっています。 その魅力の反面、CloudFront の障害は、アプリケーションそのものに問題がなくても、以下のような表示が崩れた画面が表示されて、ユーザが全くサービスを使えなくなるという、その影響が非常に大きいものです。また障害の原因が DNS やネットワークの経路における問題といった、私たちが直接解決しにくい領域にあることもしばしばです。 ただ、どんな事情であれ、障
ウィスキー、シガー、パイプをこよなく愛する大栗です。 DNSサービスであるRoute 53がVPC内のPrivate DNSをサポートしたので試してみました。 Route 53の設定 Route 53でHosted Zoneを作成します。今まで見慣れないTypeとVPC Idが出てきます。TypeでPublic DNSかPrivate DNSを選択します。 ドメイン名を"maroon1st.local"としてドメインを作成して、Typeを"Private Hosted Zone for Amazon VPC"に設定して、対象のVPCを関連付けます。 作成したHosted Zoneでレコードを作成します。ここではRDSのエンドポイントにCNAMEを設定しました。 この後、既存のDNSキャッシュが消えるまで待ちます。(DNSは「浸透」しませんよ) digコマンドで確認すると、以下の様に表示され
こんにちは。セールスグループの中嶋(@mnakajima18)です。 ずいぶん暖かくなってきたので、四国にうどんを食べに行きたいなと思う今日このごろです。 もしくは京都がいいですね。特に清水寺は春の夜のライトアップが非常に綺麗みたいです。 あ、しかも今日からですね。今から行ってもいいですか、部長。 さて、早速ですがみなさんはDNSは何を使っていますか。 BIND？レジストラの提供サービス？ AWSにもRoute 53というDNSのサービスがあるのをご存知でしょうか。 Route 53とは様々な特徴はありますが、大きなところはこのような感じです。 速い 全世界33箇所にロケーションを配備しているので、アクセス元に一番近いロケーションに転送される 信頼性が高い SLA100％ 参考ページ→Amazon Route 53 サービスレベルアグリーメント 安い 1ホストあたり$0.5/月(最初の25
ども、大瀧です。 ここのところ新機能を追いかける記事ばかりだったので、今回は少し毛色の異なるノウハウ系を書いてみます。 負荷テストの前置き(読み飛ばし可) 「Webサイトがテレビ番組で紹介されることになった！大幅なアクセス増がやってくる！」という場合に、ロードバランササービスのElastic Load Balancing(ELB)やCDNのCloudFrontなどスケールするサービスを組み合わせ乗り切るというのは、クラウドらしい柔軟性の高さを活かせる典型な例かと思います。実際、弊社の事例でも多くのお客様に提供し、ご好評をいただいています。 これらのサービスを構成するにあたり、実際のアクセス増に耐えられるか試すため負荷テストを実施することも多いと思いますが、大規模なケースになってくると難しいのが負荷テストを実施するマシンの確保です。これについてもAmazon EC2であれば、Auto Sca
2014年5月14日 13時00分 修正 タイトルが誤解を招くものだったので、「なぜ URL に www を付けるのか。または、サブドメインなしでは CNAME が使えない件」から変更致しました。併せて、画像に Public IP と Private IP の明記を行いました。 皆さん、こんにちは。MUGENUP の osada です。 今回は、スケールアウト時にELB(Amazon Elastic Load Balancer) を使うときの注意点についての記事です。 といっても、インフラ・エンジニアには自明のことと思いますので、読者の対象は インフラ・エンジニアではないけど、インフラもやるというベンチャーならではのエンジニア向けです。 要旨 ELBにはEIPなどのAレコードを関連付けることが出来ず、ドメインとサーバーを結びつけるには提供されるCNAMEを使う必要があります サブドメイン無
設定ファイルと格闘せずにDNSを運用管理 始めてみよう、Amazon Route 53 並河 祐貴 株式会社サイバーエージェント 2011/6/23 Amazon Web Services（AWS）の「Amazon Route 53」は、API経由でDNSの運用管理を可能にするサービスです。Firefoxのアドオン「R53 Fox」を使って、その導入、設定を行う方法を紹介します（編集部） Webサイト運用に欠かせないDNS 今日、一般に公開されているWebサイトでは、IPアドレスを直接公開するケースはほとんどありません。多くのケースでは、ドメイン名（「google.co.jp」や「yahoo.co.jp」など）を公開し、ユーザーはそのドメイン名を基にブラウザでURLを入力したり、検索したりしてアクセスすることとなります。 そのためWebサイトの運用に当たり、ドメイン名とIPアドレスをひも付
DNSフロントエンドサービスのRoute53でフェイルオーバー機能が使えるようになったぞ Route53に参照先へのHTTP/TCPヘルスチェックがついて、ダウンしたとき用のレコードを登録できるぞ S3 で静的ページ作ってバックアップサイトにしとくといいかもね。ヘルスチェックの詳細は Route 53 Developer Guide をチェケラッ cf: http://aws.typepad.com/aws_japan/2013/02/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting-.html コメント ヘルスチェックもついてるので EC2 インスタンスを2台作って冗長性を持たせるというのにも使えるだろうけど、それなら ELB を使えば良いので、解説にもある通り S3 で静的ページが現実的
6. Route53で困ってたこと API操作→即反映 ● 事前に検証できない ● 変更履歴が残らない R53 FoxにImport/Export機能をつけた ● dry runができない ● テストが手動（GUIなので） →ExportしたJSONをgitに保存する運用… 8. 設定ファイル hosted_zone "winebarrel.jp." do rrset "winebarrel.jp.", "A" do ttl 300 resource_records( "127.0.0.1", "127.0.0.2" ) end rrset "winebarrel.jp.", "MX" do ttl 300 resource_records( "10 mx.winebarrel.jp" ) end end hosted_zone "info.winebarrel.jp." do rrset
Instagram のスケール正攻法 -- Kosei Kitahara's Blog
Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
