[アップデート] Network Load Balancer で TLS ALPN がサポートされたので HTTP/2 が可能になりました。 本日のアップデートで Network Load Balancer（NLB）が TLS ALPN（Application-Layer Protocol Negotiation） をサポートするようになりました。 Network Load Balancer now supports TLS ALPN Policies 何が嬉しいのか TLS リスナーで HTTP/2 が利用可能に これまで NLB の TLS リスナーでは ALPN に対応していなかったため、HTTP/2 で受けることが出来ませんでした。そのため、NLB を介した HTTP/2 通信をするには TLS リスナーではなく TCP リスナーとして NLB を構成する必要がありました。 この場
![[アップデート] Network Load Balancer で TLS ALPN がサポートされたので HTTP/2 が可能になりました。 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/876809e40a16193d45c580a01a3f67fc9a50a044/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
コンニチハ、千葉です。 Global Acceleratorは、固定IPアドレスを持つグローバルなロードバランサーで、特徴は以下です。 参考：https://aws.amazon.com/jp/global-accelerator/ エニーキャストな固定IP持かつ、地理的に一番近いロケーションにルーティングされる。これは、IPを複数持つのではなく2つの固定IPが、各エッジローケションにアナウンスされ、ユーザーは意識せずに一番近いロケーションにルーティングされる(すごい) 固定IPのため、ALBやDNSのラウンドロビンで受けるDNSキャッシュの影響を受けなくなる、つまりフェイルオーバーに強くなる(サイコー) 2つの固定IPが割り当てられ、1つのIPネットワークが中断した場合は、別のネットワークゾーンから固定IPが復活する(ゾンビ的な？) ダイヤル機能により、0 - 100を指定し、例えば徐々
ども、大瀧です。 本日、AWSのロードバランササービスであるELBのIPv6対応がリリースされました。試してみた様子をレポートします。 5年ぶり2回目のElastic Load BalancingのIPv6対応 ご存じの方がごく一部いるかもしれませんが、ELBのIPv6対応は5年前の2011年5月に一度リリースされています。 Elastic Load Balancing Announces Support for IPv6, Zone Apex Support and Security Group Integration 再度リリースが出るとはどういうことでしょうか？それは、対応するロードバランサとネットワーク環境の組み合わせに差異があります。以下の表にまとめました。 ロードバランサのタイプ ＼ ネットワークのタイプ EC2 Classic VPC 注意しなければならないのは「×」マークの
![[AWS] Elastic Load BalancingがIPv6に対応しました！(5年ぶり2回目) | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/b87e732c82c8791fc86eac4689996b0481f8d3db/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F02%2Felb.png)
普段 EC2 を使っていると、ロードバランサーは導入の手間的にほぼ ELB 一択になっちゃいます。 ヘルスチェックはもちろん、高負荷時には自動でスケールしてくれるし、最近やっとコンソールから使えるようになった Auto Scaling とも連携してくれるので、たいへん重宝しています。 ただ、スケールすることを前提としているため、初期状態ではそこまで性能が良くありません。 自分が試した限りでは、HTTPリクエストは 2000 req/s くらいしか捌けませんでした。 また、転送量も 800 Mbps (100 MB/sec) くらいしか稼げませんでした。 (HTTPS の使用や Keep-Alive の設定によっても変わるので一概には言えませんが、ざっくりこのくらいということで。) また、公式のドキュメントによると、スケールするのに 1 ~ 7 分はかかるらしいです。 したがって、徐々にアク
こんばんは、三井田です。 今回は、Elastic Load Balancing (ELB)とRoute 53のヘルスチェックの仕様の違いについて簡単にまとめてみたいと思います。 ELBのヘルスチェックはご存知のとおり、ロードバランサがどのバックエンドインスタンスにトラフィックをルーティングするかを判断するために用いられます。 一方、Route 53のヘルスチェックは、重み付けラウンドロビンやDNSフェールオーバーで、どのIPアドレスを回答に含めるかを判断するために用いられます。 ヘルスチェック仕様早見表 まずは、以下の表にご覧下さい。 サービス ELB Route 53 ヘルスチェック元 （Health Checker）
ども、大瀧です。連投します。 今朝がたリリースされた、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
Best Practices in Evaluating Elastic Load Balancing : Articles & Tutorials : Amazon Web Services http://aws.amazon.com/articles/1636185810492479 ＝＝＝＝ 概要 ELBを最もよく評価するには、ELBのアーキテクチャを理解する必要がある。本稿は、AWS ELBの機能と独特なアーキテクチャについて述べる。ベストプラクティスを提供することで、ELBをテスト・評価する際に一般的な落とし穴(pitfall)から避けられるようになる。このホワイトペーパーが対象としている読者は、ELBの経験が少ないが、過去にH/W,S/Wのロードバランサを使ったことがあるような開発者である。 ELBの概要 ELBは、複数のEC2インスタンスへ、自動的にトラフィックを分散する。単
それは予告なく突然起こった TomcatからELBを経由したEC2インスタンスが見つからない。Management Consoleで確認するとちゃんと起動している。なぜ？分からない。ELBの障害でも無さそうだ。ELBへHTTPリクエストしているTomcat側の問題か？謎が深まるばかり。 ELBのIPアドレスは変わることがあるらしい いろいろ調べていると分かったことがある。ELBのIPアドレスは変わることがあるらしいと。たしかに、各種ドキュメントにはELBはドメイン名を使うように至る所で注意書きがあった。確かに、ELBは単一のサーバーではなく、ELBというサービスだからIPが変わるのは理解できる。でも今回は、ELBはちゃんとドメイン名で書いているはずだぞ。全て正しく設定されているはずなのにTomcatがConnection Refusedとエラーを吐いている。 TomcatがDNSキャッシュ
はじめに こんにちは植木和樹です。今回はAWSで提供されているロードバランシングサービス ELBについて調べてみました。 ELBとは ELB(Elastic Load Balancing)サービスはその名の通りロードバランサを提供するサービスです。ロードバランサとは、Webサーバやアプリケーションサーバが複数あった場合に通信負荷が均一になるように分散してくれる装置です。商用製品としてはF5社のBIG-IPなどが有名です。 ELBについては弊社ブログ「Elastic Load Balancingで複数のゾーンにわたって振り分けるときに気をつけること」にまとまっていますので、ぜひそちらをご覧ください。 同一AZ内でどのように負荷は分散されるのか? さて今回は同一AZ(アベイラビリティ・ゾーン)内に2つのEC2インスタンスがあった場合、それらへの負荷がどのように分散されるか、について調べてみまし
ELB配下のEC2インスタンスは接続元がELBのアドレスになる ELB配下のEC2インスタンスが、接続元のIPアドレスなど情報を得ようとする場合、初期設定ではおそらくELBのIPアドレスが返されてしまいます。これは、ELBを経由しているので当たり前といえば当たり前ですが、これではどこからアクセスされているのか把握できません。そこで、ELBの機能を利用して接続元のIPアドレス等を取得したいと思います。 X-Forwarded-ForとX-Forwarded-Proto ELBには市販されているロードバランサー製品と同じように、接続元のIPアドレスをヘッダー情報に付けてくれます。そこで、EC2インスタンス側でその情報を取得してログとして書き出してみます。また、ELBはSSLターミネーション機能がありますので、接続元がどのプロトコル（HTTPかHTTPSか）でEC2インスタンスにアクセスしたのか
少し前に「ELBの帯域がボトルネックになるのでは？」という主旨の記事を書いたが、同じ考えを持っている人もいるようだ。 Daily AWS Wtf - Elastic Load Balancer and EC2 instance bandwidth この記事の結論としては「古くて醜いDNSラウンドロビン（the old and ugly DNS Round Robin）を使うしかない」ということだった。 帯域増やすにはAWSの中の人に相談するしかないのかな。。。と頭を抱えながらGoogle先生に教えを請うていたところ、また別の記事が見つかった。 Benchmarking Load Balancers in the Cloud « RightScale Blog リンク先のホワイトペーパーによると、 まず、500rps×n台の負荷をかけた このとき、DNSはELBへの問い合わせに対して3つのI
AmazonRoute53のβがとれ、正式版になったららしいです。これに伴い、AWSエヴァンジェリストである玉川氏のブログでさらっと紹介されている「新しいエイリアス機能、Zone Apex対応」の文章を読みました。 これ、ELBを利用している人にとっては相当衝撃だったのではないでしょうか。 少なくとも、私にとっては衝撃でした。ビビりました。AmazonEC2最大の弱点（だと個人的に思っていた）ELBのある問題を見事に解決しているからです。あまりに衝撃的だったので、さっそく本ブログで検証してみました。 これまで何が問題だったのか。 実は、AmazonEC2でELBを利用している場合、http://ttcloud.netのような、ドメインルートなURLを利用することができませんでした。http://www.ttcloud.netのような、ホスト名指定のURLにする必要があったのです。サイト
ELBについて深く知りたくなってしまったので、改めて調べたり聞いたりした。 今回そもそも知りたかったポイントは下記の2点 ELBがどういう仕組みで膨大なトラフィックに耐えているのか ELBで稀に障害が発生するみたいなので、その影響をなんとか回避できないか ELBの概要 内部仕様に踏み込む前に、改めて概要と基本機能を確認。 ELBの役割 ELB（ElasticLoadBalancer）は、Webトラフィックを配下のEC2Instanceに適切に分散してバランスを取る仕組み、いわゆるロードバランサー。なぜ分散させる必要があるかというと、1台のサーバで処理可能なトラフィックには限りがあるから。また、AutoScalingや、Zone間分散（Multi-AZ）といった構成をとる為にも必要となる。 ELBの基本機能 ELBの基本機能は、高負荷システムにおいて、肝となる重要なものばかり 負荷分散
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
