Elastic Load Balancingで複数のゾーンにわたって振り分けるときに気をつけること | DevelopersIO
大量のトラフィックが予想されるサービスを構築する際にAWSを使うと Elastic Load Balancing と Auto Scaling を組み合わせて負荷状況に応じて EC2 を自動でスケールさせることができます。普段はまあまあだけど急に跳ね上がる可能性もある場合にはとても便利な仕組みですよね。 今回はさらに複数の Availability Zone（Multi-AZ）にわたってEC2を配置する際に気をつけたほうがいいところを紹介させていただきたいと思います。 Elastic Load Balancingって？ Elastic Load Balancing（以下ELB）は配下にある複数のEC2の負荷状況に応じてトラフィックを分散してくれます。さらに Health Check という仕組みを使うことでアプリケーションの不具合を検知することもできます。 各設定や状況はAWS Conso
【新機能】新しいロードバランサー Application Load Balancer（ALB）が発表されました | DevelopersIO
target2の場合も同様に作成します。 ターゲットグループにインスタンスを登録する 作成したターゲットグループにEC2インスタンスを登録します。 ターゲットグループを選択してコンテキストメニューでインスタンスの登録と登録解除をクリックするか、ターゲットタブの編集をクリックします。 インスタンスtarget1-aとtarget1-cを登録します。 ALBにインスタンスが登録されます。ロードバランサに登録していないため状態はunusedとなります。 同様にtarget2にもインスタンスtarget2-aとtarget2-cを登録します。 ALBを作成する ALBを作成します。アプリケーションロードバランサーを選択します。 ロードバランサの基本的な設定を行います。 プロトコルはHTTPとHTTPSのみとなっています。今回はHTTPSを選択します。 HTTPSを選択したのでSSL証明書を選択しま
[激アツアップデート]ALBだけでカナリアリリース(重み付け)ができるようになりました！ | DevelopersIO
とうとうきてしまいました！ とうとう、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%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
Amazon VPCでELBとNATを使ってよりセキュアな環境を作る【5日目】 | DevelopersIO
公開するサーバはセキュリティを特に強化する ELBを介してEC2インスタンスのWebアプリにアクセスするとき、ELB以外からのアクセスを拒否したくなります。また、公開IPアドレス自体も持ちたくありません。公開IPを持たせたくないということでVPCを前提に考えます。そして、ELBをパブリックサブネットに置いて、EC2をプライベートサブネットにすることで実現できます。今回は、VPCを使ってELBとNATインスタンスを使ったセキュアな環境を構築したいと思います。 VPCとELB ELBとAutoScalingが連携できることは知られていますが、VPC内でも使うことができます。 VPC内のELBのテクニックとして、ELB自体をパブリックサブネットに置いてEC2をプライベートサブネットにおくことがあります。ELBがリバースプロキシとして働いて、EC2はELBからのHTTPインバウンドのみ受け付けるの
Amazon AthenaでELBのログを調査するときに使ったSQL | DevelopersIO
はじめに 今まではログの調査の際にはS3にあるELBのログをローカルに落としてgrepしたりしてましが、 Athenaを使ってログを解析してみましたので今回は調査のときに使ったSQLをご紹介します。 ご紹介するSQLを使えばあとは少し変えるだけでいろいろな調査が可能かと思います。 Athenaデータベース、テーブルの準備 Athenaを使用する際の手順は以下ブログを参考にしてください。 Amazon AthenaでELBログをSQLで解析する #reinvent 調査に使用したSQL ELB毎のリクエスト数を調べる SELECT elb_name, count(*) AS request_count FROM elb_logs GROUP BY elb_name ORDER BY request_count DESC; 特定の時間内でのリクエスト数を調べる SELECT elb_name,
ACMの証明書インポートとELBのSSLリスナー追加 | DevelopersIO
ご機嫌いかがでしょうか、豊崎です。 今回はサードパーティで取得したSSL証明書をAmazon Certificate Manager（ACM）にインポートして、既存のELBにSSLのリスナーを追加する方法を書いていきます。 準備 手元に以下のファイルを用意します。 サーバ証明書 中間証明書 CSR作成時に利用した秘密鍵 ACMへインポート AWSマネジメントコンソール＞Certificate Managerダッシュボードを開いて、 証明書のインポートから進んで行きます。 すると、証明書の選択の画面が出てきますので、こちらに準備しておいたファイルの中身をコピペしていきます。 貼り付け終わったら、レビューとインポートを押して次にすすみましょう。 レビューとインポート画面になりますので、 内容を確認して問題なければインポートを押しましょう。 インポートが完了すると、Certificate Man
AWS ALB(新しいELB)のホストベースルーティングとSSL/TLS証明書の関係を理解する ｜ DevelopersIO
ども、大瀧です。 本日、AWSの新しいロードバランサALB(Application Load Balancer)でホストベースルーティングがサポートされました。早速以下の記事で検証しています。 【新機能】ALBのHost-based routingを試してみた ｜ Developers.IO 今回の機能追加によって、ロードバランサ自身にホストベースのバーチャルホスト機能が追加されたわけですね。使い勝手大幅アップ！という感じなのですが、ホストベースバーチャルホストとHTTPSを提供するためのSSL/TLS証明書は切っても切れない重要な関係かなと思い、その組み合わせについて調べてみました。 結論から言うと、現時点でALBの同一のポートでホスト名ごとに証明書を分けることはできません。ワイルドカードやマルチドメインなど複数のホスト名を1つの証明書で扱う対応を検討しましょう。 2017年10月にAL
Ingest Node を使って、より簡単に ELB のアクセスログを AWS Lambda で Elasticsearch に取り込む | DevelopersIO
Ingest Node を使って、より簡単に ELB のアクセスログを AWS Lambda で Elasticsearch に取り込む こんにちは、藤本です。 先日、Amazon Elasticsearch Service で Elasticsearch 5.1 が利用可能となり、Elasticsearch 5 系の新機能である Ingest Node を利用できるようになりました。 そこで以前エントリした ELB のアクセスログを Amazon Elasticsearch Service へ Lambda で取り込む実装を Ingest Node を利用して、Lambda の実装を減らしたいと思います。 ELBのアクセスログをAWS LambdaでElasticsearchに取り込む Elasticsearch Ingest Node Elasticsearch はスキーマレスで JS
ELBのアクセスログを可視化し、超絶手軽に分析する[QuickSight,Athena] | DevelopersIO
コンニチは、千葉です。 QuickSightとAthenaを使って、色々な視点からELBのログを分析してみました。 SQLをガンガンかける人は、Athenaのみで完結する場合もあるかもしれませんが、グラフで直感的に見るメリットもあると思います。 準備 手順サマリです。以下でやっていきます。 AthenaにてELBログテーブルを作成する QuickSightにて、データセットを作成する QuickSightにて分析する AthenaにてELBログ用のテーブルを作成する Amazon AthenaでELBログをSQLで解析する #reinvent こちらのエントリを参考に、Athenaにテーブルを作成します。 QuickSightにて、データセットを作成する マネージメントコンソールからQuickSightへ移動し、[New Analyze]から[New DataSet]で新しいデータセットを
![ELBのアクセスログを可視化し、超絶手軽に分析する[QuickSight,Athena] | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/2fa55da21da59730bd35238aa38fac0331bb63ac/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F06%2Fquicksight.png)
CloudFrontとELB間をSSLで通信させる | DevelopersIO
ご機嫌いかがでしょうか、豊崎です。 そろそろ花粉の季節ですね。 昨年鼻水と目のかゆみがひどかったので、アレルギーの検査に行ったのですが、 何のアレルギーもありませんでした。 私の抗体は何に対して鼻水と目のかゆみを出していたのでしょうか。 はじめに CloudFrontでELBをオリジンとして使うときに、CloudFrontと、ELBにそれぞれACM証明書を割り当てて、 インターネットからCloudFront間、CloudFrontからELB間をSSLで通信させるというケースがよくあります。 証明書の取得や設定に少しだけお作法がありますので、まとめてみたいと思います。 図の様な構成を作成します。 お作法 先にお作法を書きます。 CloudFrontで利用できるACM証明書はバージニアリージョンで発行されたものだけ！ ELBにも証明書がいるので、ELBのリージョンでもACMから証明書を発行する
CodeDeployでELBヘルスチェックによるローリングアップデート | DevelopersIO
渡辺です。 AWS CodeDeployでは複数サーバにアプリケーションをデプロイできます。 この時、どの程度並列にデプロイするかを決めるのがデプロイ設定です。 デプロイ設定は、AllAtOnce、HalfAtATime、OneAtATimeから選択します。 AllAtOnceは全サーバを並列にデプロイします。 一方、OneAtATimeは並列にデプロイを行わず、ひとつのサーバのデプロイ完了を待って次のサーバのデプロイを行います。 HalfAtATimeは半分ずつのグループにわけ、各グループが成功した後に残りのグループをデプロイします。 OneAtATimeを使えばローリングアップデートとなるわけですが、実際にはデプロイ後にELBのヘルスチェックが通るまでタイムラグがある点に注意しなければなりません。 リリース時のサービス断を発生させない デプロイ（リリース）時のサービス断を発生させない有
ELB+AutoScaling環境でALBに移行してみる | DevelopersIO
こんにちは、菊池です。 昨年発表された Application Load Balancer （ALB）ですが、すでに既存のClassic Load Balancer（元々のELB：標準ロードバランサー）から移行しているユーザも多いと思います。 今回、AutoScalingで使用しているケースにおける、CLBからALBに移行する手順を調べてみました。単純な移行と比較して、いくつか注意点もありました。 手順サマリ ALB/Target Groupを作成（ここではインスタンスの追加不要） Auto Scaling Groupを編集 一部プロセスを停止 Target Groupを追加 Health Checkが正常となることを確認 Auto Scaling Groupを編集 CLBを削除 停止していたプロセスを再開 DNSレコードを切り替え、アクセス先をCLBからALBに変更 1、6についてはこれ
[AWS] Elastic Load BalancingがIPv6に対応しました！(5年ぶり2回目) | DevelopersIO
ども、大瀧です。 本日、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 注意しなければならないのは「×」マークの
[TIPS] ELB のアクセスログのタイムスタンプを QuickSight で Date タイプとして利用する | DevelopersIO
こんにちは、藤本です。 先日、Amazon Athena のクエリ結果を SPICE にインポートして、 QuickSight で可視化するというブログをエントリしました。その時に得られた知見をもう一つご紹介します。 タイトルが何を言っているのか分かりづらいですが、、、ELB のアクセスログのタイムスタンプはフォーマット上、Athena の Timestamp にも、QuickSight の Date タイプにも適合しません。でも、グラフ表示上、Date として扱いたいです。タイムスタンプの文字列でも、Athena の場合は、timestamp like '2017-01-01T10:%'というようなクエリで、QuickSight の場合は、Start with フィルターである程度の絞り込みはできますが、柔軟なクエリをしたい場合に複雑なクエリや、細かいフィルターの指定が必要となります。何
ELB のアクセスログを Parquet 形式に変換して、Amazon Athena からクエリする #reinvent | DevelopersIO
そこで今回は下記ブログで紹介されている ELB のアクセスログを Parquet 形式に変換する手順を試してみました。 S3のデータをAmazon Athenaを使って分析する 試してみた 今回の流れは以下のようになります。 EMR クラスタ立ち上げ スクリプトダウンロード データ変換 変換したデータを S3 へ転送 Amazon Athena からクエリ EMR クラスタ立ち上げ データ変換するスクリプトを実行する EMR クラスタを立ち上げます。 マネジメントコンソールから EMR の画面を遷移します。 Create cluster から立ち上げる EMR クラスタを設定します。 Go to advanced options から詳細設定します。 今回は Spark を利用するので Spark をチェックします。 インスタンスは Core node に r3.8xlarge を 4台利
Amazon AthenaでELBログをSQLで解析する #reinvent | DevelopersIO
西澤です。目新しさの無いエントリーですが、溜め込んだELBログを解析する必要があったので試してみることにしました。Amazon Athenaは東京リージョンでは使えないので、OregonリージョンのAthenaから、東京リージョンのS3バケットをデータソースとして検証しました。 と言ってもほぼ下記ページにやり方は詳しく載っていますので、公式ページを見ていただく形でも構いません。 Analyzing Data in S3 using Amazon Athena | AWS Big Data Blog Athenaでデータベースを作成する データベースエンジニアで無い担当者からすると、専用のSQLクライアントを用意すること無く、AWS Management Console上で全ての操作が完結するというのは大変嬉しいです。GUIで操作することもできますが、テーブルを作成するデータベースを先に別に
[CloudWatch] パーセンタイル統計値がELBなどで利用可能になりました | DevelopersIO
はじめに Cloudwatchのアップデートにより、メトリックの集計値として従来の平均値、最小値、最大値に加え、 パーセンタイル統計値を取得する事が可能となりました。 今回、Application Load Balancer(ALB)のレスポンスタイム(TargetResponseTime)の パーセンタイル出力を確認する機会がありましたので、紹介をさせて頂きます。 Amazon CloudWatch 更新 – パーセンタイル統計およびダッシュボードの新ウィジェット 操作方法 AWSのマネジメントコンソール「CloudWatch」の画面より「メトリックス」を指定します 今回、測定対象のALB名称、メトリックとして「TargetResponseTime」を指定しています 「グラフ化したメトリックス」のタブより、期間を「1分」に変更します 統計としてパーセンタイル統計値「p99」〜「p10」の
![[CloudWatch] パーセンタイル統計値がELBなどで利用可能になりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/733218a332110bfecfa7af8c0ec6179c3fa14b03/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FCloudWatch.png)
【Play Framework】 ELB 経由のアクセス元IPアドレスを取得する | DevelopersIO
Play Framework に対するアクセスから ELB や nginx（リバースプロキシ）を経由した アクセス元IPアドレス を取得するには、少し工夫が必要です。 本記事におけるバージョン情報は下記の通りです。 Play Framework 2.4 Scala 2.11.4 nginx 1.6.2 下準備: IP確認するアプリケーションを用意する アクセス元IPアドレスをどのように取得すればいいかを知るために、まず、アクセス元IPを確認するアプリケーションを作成しましょう。 ipcheck.scala.html @(remoteAddr: String, xForwardedFor: String, xRealIp: String) @main("IP Check") { <dl> <dt>Your remoteAddress</dt> <dd>@remoteAddr</dd> <dt
gRPCサーバーでAWS ELBのPROXY ProtocolのリモートIPを取得する | DevelopersIO
ども、大瀧です。 前回の記事(gRPCアプリをAWS ELBで負荷分散してみた)では、ELBのL4転送による負荷分散をご紹介しました。 この構成では手軽に負荷分散ができる一方で、ELBを介すためにサーバ側でクライアントのリモートIPを取得することができません。そこで今回は、ELBが サポートするPROXY ProtocolによってリクエストにリモートIPを付与し、それをgRPCサーバーで取得するサンプルコードをご紹介します。 PROXY Protocolの有効化 ELBのClassic Load BalancerはHAProxyのPROXY Protocol version 1をサポートしますが、既定では無効になっているため有効化します。aws elb create-load-balancer-policyコマンドでPROXY Protocolサポートが有効なポリシーを作成、aws elb
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AKIBA.aws 第1回 基礎編で「負荷分散だけじゃないELBのメリット」を話しました | DevelopersIO
