AWS ELBの504ステータスのGateway Timeoutと格闘した話(最終的にALBで直った） - YOMON8.NET
ELBのメトリクスのステータスには、バックエンドのEC2が返したステータス(HTTPCode_Backend_XXX)と、ELB自身のステータス(HTTPCode_ELB_5XX)があります。 ELB自身のステータスコードの中には504というエラーコードがあります。この504エラーと格闘した話を書きます。 この504エラーは、CloudWatchのメトリクスで言うとHTTPCode_ELB_5XXに上がってきます。 このメトリクスは5XXという名前の通り、504以外のコードも含んでいます。 例えば、 HTTP 502: Bad Gateway (バックエンドサーバからのレスポンスがHTTPレスポンスとして解釈不能)や、 HTTP 503: Service Unavailable (突発的なアクセス増によりスケールが間に合わない時など） などがあります。 実際に504かどうかはS3に保存され
【AWS】ALBからCLIでEC2切り離しderegister-targetsはGracefulじゃない? - YOMON8.NET
ALBからEC2を切り離す時に使う aws elbv2 deregister-targets のコマンド、大量のアクセスがあってもエラーを返すことなく切り離すことができると思っていました。 ① EC2をALBより切り離し aws elbv2 deregister-targets --target-group-arn target_group_arn --targets Id=i-xxxxxx,Port=80 ②ステータス確認 healthy -> draining -> unused と状態が遷移するのを待つ。 ③ EC2をALBに登録 aws elbv2 describe-target-health --target-group-arn target_group_arn --targets Id=i-xxxxxx,Port=80 何度もテストしましたが①の部分で 502 ステータスが返っ
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,
動的コンテンツをオリジンとしたCloudFrontを構築してみた
Editor's Notesそれでは、ELBをオリジンとしたCloudFrontを構築してみた、という内容をお話してまいりたいと思います。まず自己紹介から かわむらたいき30歳オス まぁ見たまんまですかね。 前職では新卒入社し、LAMP環境構築してAPI作成や管理画面作成をしていました。 現職では前職おざなり？になっていたインフラを鍛えようと思いインフラを中心に仕事させてもらってます。 通常の趣味はいっぱいあるので割愛して開発的な趣味を話すと、シェルスクリプトによる自動化とシェルスクリプトによるログ調査を嗜んでいます。awkとかsedとかgrepとかですね。 ここまで聞くとただの変態ですが、普通の趣味もいっぱいあります。 では、本題に戻りまして、今日お話する内容をサクッと 簡単です。やったことと、なぜやったかと、どうやったかです。加えて、気をつけること、という内容です。ではまず、もしかした
１台のEC2でもELBを使うメリットについてまとめてみました | DevelopersIO
ご機嫌いかがでしょうか、豊崎です。 ELB（Elastic Load Balancing）はその名の通りロードバランサーなので、負荷分散のイメージが強いと思いますが、 ここではWEBサーバが１台でも前段にELBを置いた方がいい理由についてまとめたいと思います。 WEBサーバが１台でもELBを置いた方が良い理由 インスタンスの差し替えが容易 運用が開始した後、EC2に対して修正を行う必要がでた場合、インスタンスの差し替えが容易になります。 DNSの変更を行うことなく、バックエンドの切り替えが可能です。 ELBのヘルスチェックで監視 ELBのヘルスチェックを利用してWEBサーバの死活監視を行うことができます。 CloudWatchアラームを組み合わせて通知が可能です。 HTTPSのSSL終端をELBへ SSLを利用する場合、EC2でSSLを終端させるとOpenSSLなどの管理が発生します。 一
ELB のログを Lambda の Node.js で取り込み、Elasticsearch Service の Kibana で可視化する - Qiita
手順 Identity & Access Management でロール作成 ELB のログ出力設定 Amazon Elasticsearch Service 作成 AWS Lambda 設定 Amazon Elasticsearch で確認 Kibana 表示 参考 URL http://qiita.com/toshihirock/items/e530f3cb6dcf545601c9 http://dev.classmethod.jp/cloud/aws/elb-accesslog-to-elasticsearch/ http://kenzo0107.hatenablog.com/entry/2015/10/08/113110 Identity & Access Management でロール作成 ロール名の設定 適宜ロール名を入力。 ロールタイプの選択 AWS Lambda を選択。
CloudWatch で ELB の「パーセンタイル統計」を可視化しよう - kakakakakku blog
今日は CloudWatch の話を書こうと思う．既に活用してる人も多いと思うけど，2016年11月の新機能リリースで各種メトリクスの「パーセンタイル統計」を可視化できるようになった． 「パーセンタイル統計」は凄く重要で，平均値だけをモニタリングしていると気付きにくい異常値に気付くことができる．例えば，ELB の Latency をモニタリングしている場合に，リクエストの 1% が非常にパフォーマンスが悪いとしても，平均値で見ると値が丸まってしまって，通常より少し遅い程度にしか見えないという場合がある．そんなときに「パーセンタイル統計」を活用できる． まだ全ての ELB に反映されていない 以下の記事を読むと，newly created ELB and ALB と書かれていて，新機能リリース以降に作成した ELB と ALB にしか対応していないように読み取れた． Amazon Cloud
[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 注意しなければならないのは「×」マークの
Elastic Load Balancing: Support for CloudWatch percentile metrics
We are pleased to announce that Elastic Load Balancing now supports percentile metrics, providing customers with improved visibility into the performance of their applications. Load balancer metrics already support statistics such as average, minimum or maximum, which are useful for many metrics. Percentiles are particularly useful when applied to metrics that exhibit large variances, such as load
remote_addrとかx-forwarded-forとかx-real-ipとか - Carpe Diem
背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_
Nginx with dynamic upstreams - Tenzer.dk
Posted on July 26, 2015. Reading time: 5 minutes I recently made a setup at work where I had a Nginx server facing the user, which would forward requests to a service running behind an AWS Elastic Load Balancer (aka. ELB). That in itself doesn't sound like a difficult task, you just find the hostname for the ELB and point Nginx at it with a proxy_pass statement like this, right? location / { proxy
リアルタイム通信環境の(一部)構成紹介 : DSAS開発者の部屋
こんにちは。 今回は、当社で稼働させているリアルタイム通信環境について、ご紹介させて頂きます。 ご紹介する環境に対する要件は、以下となります。 ・ゲーム内の期間限定イベントで使用し、イベント開催中のみサーバを稼働 ・リアルタイム通信。プロトコルは、websocket を使用 ・同じチームに所属するユーザを同じサーバへ接続 ・とりあえずいっぱいスケールできるように(笑 最後の要件は冗談で、実際にはちゃんとした数値を頂いているのですが、このような環境構築を依頼されましたので、AWS 上で以下にあるような構成を考えてみました。 構成図 ※ 主要なサーバのみを抜粋 ELB 外部のクライアントから、websocket な接続を受け付けます。 http(s) モードでは、websocket の通信確立に必要なヘッダが消去されてしまうため、tcp モードを使用しています。 tcp モードを有効にすると、
ELBによるSSL Terminationをご利用中の方へ、TLSの脆弱性「Logjam」対策のご案内 - サーバーワークスエンジニアブログ
こんにちは、サーバーワークスの三井です。 少しばかり遅くなってしまいましたが、HTTPSやSSH、IPSecなどセキュアな接続に幅広く使われているTLSプロトコルに、「Logjam」と呼ばれる脆弱性が見つかり、日本でもぼちぼち話題となっています。まずは慌てずに状況を確認し、対策を実施しましょう。 （※本記事は、AWS環境でELBを用いたSSL Terminationを行っている方を主たる対象としています。予めご了承ください。） この脆弱性の成立するロジック自体は、3月に大きな話題となった「FREAK」と似ていますが、前者はOpenSSLの実装の脆弱性であったのに対し、今回のLogjamは鍵交換のプロトコル自体に潜在的にある脆弱性です。中間攻撃者にこの脆弱性を悪用されると、TLS通信を暗号強度の低い輸出グレードの暗号方式にダウングレードされ、通信内容が傍受される可能性があります。 クリティカ
AWSのELB(Elastic Load Balancing)は、セキュリティ的に問題ないのか | ozumaの日記 | スラド
AWS(Amazon Web Service)を個人的にボチボチいじっているのだけど、ELB(Elastic Load Balancing)が結構気持ち悪い。ので今日はその辺のお話。 ELBとはAWSが提供するロードバランサで、オートスケールと組み合わせることにより、トラヒック増大時にも自動的にスケールアップしてくれるというのが売りとなっている。内部的な話をすると、ひとつのELBにはひとつのFQDNが割り当てられ、スケールする際にはこのFQDNのIPアドレス(Aレコード)が変わるという若干トリッキーな動きをする。そのため、ユーザはIPアドレスではなく、常にFQDNでアクセスするようにしないといけない。（この他、配下のサーバのヘルスチェックもきめ細かくできるとか、Route 53の合わせ技が強力……とか色々あるけど本稿では関係ないので省略）。 さてここで問題は、スケールしてELBのIPアドレ
SSL 問題「FREAK 攻撃」
----------------------------------------------------------------------------- 2015/03/03 9:00 PM PST - 更新 以下にリストされている AWS のサービスは、この問題を調査および対処している最中です。他のすべての AWS のサービスは影響を受けません。 Amazon Elastic Load Balancing (ELB) エクスポート暗号スイート (「EXP-」で始まるもの) を使用していることが判明したお客様には、注意喚起のために E メールで直接連絡します。推奨される利用可能な暗号セットを確実に使用するために、ロードバランサーで事前定義されたセキュリティポリシーを使用することをお勧めします。次の手順に従って、AWS コンソール経由で事前定義されたセキュリティポリシーを有効にできます。
もっとELB（Elastic Load Balancing）を活用する | DevelopersIO
みんな大好きElastic Load Balancing(以下ELB)は利用にあたっては細かい仕様に注意する必要があります。 2014年ELBにお世話になった人もそうでない人も2015年はもっとELBを活用するために、改めてELBの仕様や活用方法を振り返ってみましょう。 ※本稿の内容の多くは一度でもELBを使ったことがある方を想定しています。 ELBが得意なところ ELBはコスト効果良く高い可用性と拡張性をもつロードバランサーをサービスとして提供してくれるので、最初に利用するロードバランサーとしても、長く使うロードバランサーとしても優秀です。 ELBを活用するためのドキュメントがAWSから公開されています。未読の方は必ず目を通しておきましょう。 Best Practices in Evaluating Elastic Load Balancing ELBが苦手なところ ELBを利用する上で
Comparing Message Queue Architectures on AWS | FORTER
Notes: https://www.cloudamqp.com provides a hosted RabbitMQ service cluster and is not covered here. However, the Highly Available RabbitMQ cluster is included. CloudAMQP do not document what network partitioning mitigations they have configured for RabbitMQ cluster. https://redislabs.com provides a hosted Redis service and is not covered here. It uses custom replication and sharding proxies, but
A Gift from AWS: Improved API Latency at Lower Costs | BigDoor
Here at BigDoor we strive to ensure our API is always running at peak performance, and yesterday we got a great performance boost with one small infrastructure change. AWS is constantly improving their service and the performance of their platform, and yesterday afternoon the BigDoor team upgraded our API’s HTTP layer to the latest generation of Compute Optimized instances. This fleet update alone
CloudFront+S3の画像配信にリサイズ機能を追加する - 俺たちのブログ
CloudFront+S3の画像配信システムに、サムネイルとかに使う画像のリサイズ機能を追加してみる。 要するにオリジナル画像がこのURLだとすると、 http://xxx.cloudfront.net/sample.jpg こういうURLで100×100にリサイズできるようにする。 http://xxx.cloudfront.net/resize/100x100/sample.jpg システム構成 元の構成はこういうのを想定。 画像はS3に保存され、アクセスは全てCloudFront経由。 これをパスが/resize/で始まる場合は、画像変換サーバを通してリサイズするようにする。 画像変換サーバはEC2で、ちゃんとELBを使って冗長化もする。 既にELB+EC2でAPPサーバを運用しているなら、流用して追加コスト0で実現できるかも。 画像変換サーバの設定 今回はnginxのimage_f
ElastiCacheとELBとtwemproxy その2 - まめ畑
以前、 http://d.conma.me/entry/2013/01/22/195331 のエントリで、Internal ELB + twemproxy + ElastiCacheの構成で、スループットが劇的に低下してしまう問題について書きましたが、その後色々と調査をしてみました。 Internal ELBのウォームアップを行い、都度コネクションを切っていたものを接続したままにし、コマンドを送信するように変更してみました。 しかし、結果は前回の結果と同様のものとなりました。 他にも色々とtwemproxyやカーネルパラメータなどの調整を行なってみたのですが、劇的な効果はありませんでした。 Internal ELB の代わりにhaproxyを使用してパフォーマンスを測定してみました。 条件は、haproxy * 1 / twemprxoy * 4 / ElastiCasche(large)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
