とうとうきてしまいました！ とうとう、ALB一つだけでターゲットグループの重み付けが出来るようになってしまいました！！！！ ALBでターゲットグループの重み付けができるようになり、Route53で設定しなくても良くなりました。 AWSエンジニアは朝5時に起きるらしいと聞いていましたが、まさか自分がそっち側に回るとは思ってもいなかったもこ@札幌オフィスです。 とうとうきてしまいました！ とうとう、ALB一つだけでターゲットグループの重み付けが出来るようになってしまいました！！！！ Application Load Balancer simplifies deployments with support for weighted target groups New – Application Load Balancer Simplifies Deployment with Weighted T
![[激アツアップデート]ALBだけでカナリアリリース(重み付け)ができるようになりました！ | 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)
おはこんばんちは。ユニファのインフラ担当すずきです。 今年一本目のブログなんですが… 途中で間違えてブログ消してしまって2回目書いてつらいです… 気を取り直して本題いきます！！ 弊社ではサーバ等々の監視にprometheusを利用しようとしています。 prometheusでは多くの情報を取得するためにいろいろなexporterを利用するのですが、それら1個ずつ起動したり、起動確認するのは面倒だなと考えていました。 そこでECS+NLBを利用して各exporterの設定毎にDockerコンテナとして起動してしまえば楽じゃないかな？と思ったので今回はそのチャレンジしたことを記事にしています。 ECSクラスターとタスクを設定 とりあえずはじめにECSクラスターを作成します。 ECSコンソールに入ってもらって、簡単なECSクラスターを作成します。 リポジトリは不要なので一つ目の項目だけチェックしま
TL;DR 2016年8月にAWSのLoad Balancerが WebSocketに対応した スムーズすぎて心配になるくらい簡単に導入できる 「うまい、はやい、やすい」ので、導入しない理由はないと思う ALB Release! 巷では長らく噂になっていた、新しいAWSのLoad Balancer。 先月2016年8月11日についにリリースされた。待望のL7対応だ。 個人的に魅力の一つだったのはWebSocket対応。 従来のELBではWebSocket通信を終端できなかったため、 WebSocket通信の負荷分散/バランシングを行ったりSSL/TLS化する場合、 自前でバランシングする仕組みを実装したり、Nginxを前段に配置するなどちょっとした工夫が必要だった。 AWSのLoad BalancerがWebSocketサポートしてくれるのであれば、この設計構築および運用をアウトソース出来
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インスタンスへ、自動的にトラフィックを分散する。単
前提環境 SSL通信をHTTPSロードバランシングではなくTCP(443)ロードバランシングELBで実現している。 （SSLドメインを複数持つバックエンドEC2を、単一のELBのみでやりくりさせている等の事情で） 課題 ELBはTCPロードバランシングの際には、X-FORWARDED-FORヘッダを付与しない為、ローカルIPアドレスをバックエンドEC2へ伝えられない。 TCPロードバランシングELBでもPROXY protocolを有効にすればローカルIPアドレスをバックエンドに伝えられるが、apacheがデフォルトでPROXY protocolに対応していない。 実現方法 ELBのPROXY protocolを有効にしてバックエンドにクライアントIPアドレスを渡す apacheはデフォルトだとPROXY protocol未対応である為、PROXY protocol対応モジュールを追加実装
AWSにはELBというLoadBalancerがあります。主な用途としては ・AutoScalingを使用する際に使用する ・単純なLoadBalancer機能 では少しずつではありますが、基本的な機能について説明します。 SSLアクセラレータ機能 SSLアクセラレータを使用すると何がうれしいのかと言うと、サーバの負荷が減ります。 当然ながらサーバで「暗号化」→「複合化」をするよりはELBでやってもらったほうが負荷は格段に減ります。 Cookieによる同一サーバへのアクセス CookieをELBが発行でき、クライアントから受け取ったCookieを元に与えられた秒数の間、同じサーバに同一クライアントからアクセスされます。 AutoScaling機能 ELBも状況に応じてAutoScalingします。 C:\Users\XXXX>nslookup elb-982033531.ap-nor
はじめに Elastic Load Balancing の暖気申請についての申請方法や申請に必要な情報をご紹介します。 ELBの暖気運転について ELBは負荷に合わせてスケールする機能がありますがELBのスケールにはある程度の時間がかかり リクエストが瞬間的に増えたときはELBのスケールが間に合わないことがあります。 その際ELBはHTTP 503を返します。 そこで回避策としてあらかじめTVやメディアによる露出など急激なアクセス増が予想される場合に ELBの暖気申請を行い事前にELBをスケールしておきます。 注意事項としてAWSサポートプランはBusiness / Enterpriseに加入している必要があります。 ELB暖気申請フォーマット 以下、申請フォーマットの内容です。 ELB名・リージョン、またはFQDN 予測されるピーク時のリクエスト数 （requests/秒） 予想されるピ
※：CloudFrontは米国東部 (バージニア北部)で設定を行うため、CloudFrontの全エッジロケーションでACMを使用できます。 早速試します ACMを設定する 設定の手順の詳細は、[ACM] SSL証明書発行時のドメイン認証メールをSESで受け取ってみたを参照して下さい。このエントリの「ACM設定」までを実施します。 東京リージョンでAmazon Linux 2016.03のEC2を起動して、以下のコマンドを実行します。（Webサーバのインストール、index.htmlの作成、Webサーバの開始） $ sudo yum install -y httpd $ sudo echo "AWS Certificate Manager" | sudo tee /var/www/html/index.html $ sudo service httpd start 次に、東京リージョンのEL
![[AWS Certificate Manager]東京でも無料でSSL証明書が使用可能になりました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/e10c36a6d4b1f695a66553f82a3d6a1f8b46fc38/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F01%2Feyecatch_certificate_manager.png)
Auto Scaling環境でのBlue-Green Deploymentの切替がAWS ELBでできるようになりました。 超おはようございます。最近パンケーキを昼食にできるようになった城内です。 今回は、Auto Scalingのアップデートにより、AWSでのBlue-Green Deploymentの方式に新たな選択肢が増えたことを喜びたいと思います。 Auto Scalingのアップデート 先日のAuto Scalingのアップデートにより、Auto Scalingグループに対するELBの付け外しができるようになりました。 Attach or Detach Load Balancers in Your Auto Scaling Group (What's New) Attach and Detach Elastic Load Balancers from Auto Scaling G
AWSのロードバランサであるELBではSSLの暗号化通信をクライアント<->ELB間で完結させるためのSSL Termination機能が備えられています。ELBにSSL証明書を配置することで、ELB配下のEC2にサーバ証明書が不要になりました。このメリットは、暗号化処理の負荷をWEBサーバからELBにオフロードすることができる点と、証明書の更新作業時に各サーバにサーバ証明書を配布して回る手間を軽減することが出来る点だと考えています。 とはいえ、証明書の更新時期が来たらELBに設置している証明書を更新する必要があります。通常のFQDN形式のサーバ証明書なら紐づくELBは1台だと思いますが、ワイルドカード証明書を利用している場合には更新対象のELBが数十台にもなることもあります。 この更新作業を繰り返し手動でManagement Consoleから実行するのは筋が悪いので、AWS CLIのみ
こんにちは！新人のKです！ 本日はELBに設定したSSL証明書の削除方法をご紹介します。 ELBへのSSL証明書設定 ELBへのSSL証明書登録作業はAWSマネージメントコンソールから行なう事が出来ますが、削除はコマンドラインからの操作が必要となります。 SSLの期限が切れて不要になったものは、コマンドラインから削除を行ないましょう。 ※SSL証明書のELBへの設定は、デフォルトだと1アカウントにつき10個までしか登録できません。 （10個以上SSL証明書を登録したい場合はAWSへ申請する必要があります） 不要なSSL証明書を放置していると、そのうち10個以上ELBへ登録していた、なんて事になるかもしれません。 ちなみに10個以上登録しようとすると、下記のようなMSGが出力されます。 AWS CLIインストール 1.それでは、ELBに登録されたSSL証明書の削除を行なっていきましょう。 ま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[社内勉強会]ELBとALBと数万スパイク負荷テスト](https://cdn-ak-scissors.b.st-hatena.com/image/square/2d66722d28b188f243f0cd881f7598f699791ab1/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Felbalb-160822022623-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Apache mod_proxy DNS caching issues with Route53 DNS
