Amazon Route53の新機能 ELBをHealth Checkのターゲットにしてみた | DevelopersIO
ども、大瀧です。連投します。 今朝がたリリースされた、Route53の新機能(Amazon Route 53 on 2013-05-30)を早速試してみました! 従来のRoute53フェイルオーバー機能、設定方法については、福田さんの記事を参照ください。 Route53の新機能とは 従来、Route53ではEC2インスタンスにHealth Checkを行い、EC2が不調の場合にDNSレコードを書き換えるDNSフェイルオーバー機能がありました。以下のようなイメージです。 ただ、Health Checkのターゲットには、ELB(Elastic Load Balancing)が指定できないという、痛い制限がありました。今回のアップデートは、ELBをHealth Checkのターゲットにできるというものです。 あれ、ちょっと待ってください。Health Checkって、元々ELBがバックエンドのE
ELB用のSorryサーバをCloudFormationで構築 – Gezarで一発「ごめんなさい」 | DevelopersIO
よく訓練されたアップル信者、都元です。以前、Amazon ELBでSorryサーバへのフェイルオーバーを実現するというエントリにて、ELB配下に正常なインスタンスが1つも無くなった時にSorryページを表示する方法をご紹介しました。 その後、Route53のヘルスチェックにELBを指定できるようになったり *1、フェイルオーバーの機能は順次強化されてきています。 このRoute53のフェイルオーバー先にはS3を指定できます。S3の可用性は非常に高いため、もうWebシステムのフェイルオーバーは完璧。…かと思いきや、実はそうでもありません。 まずRoute53を使わない場合はどうしようもありません。まぁ、使えよって話ですが。 S3は「あらゆるパスへのリクエストに対して同じコンテンツを返す」ということができません。強引にやろうとするとリダイレクトをする、という解決策になってしまいます。理想として
Amazon ELBでSorryサーバへのフェイルオーバーを実現する | DevelopersIO
AWSにおいて、ELBによるSorryサーバへのフェイルオーバーは、長らく待ち望まれている機能です。先日、Route53にDNSレベルでのフェイルオーバー機能が実装（下記）されました。 Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to S3編） Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to EC2編） ただ、Route53を利用していない場合は、未だにヘルスチェック及びフェイルオーバーの機能は手組みする必要があります。無いなら作るしかないのです。わかりました、作りますよ。 前提 まず確認しておきたいのは、今回ご紹介するテクニックは、前述のRoute53によるフェイルオーバーと比べると、オモチャみたいなもんです。知ってますか？ 何と、Ro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
conma.me
