The HTTP method (also called the verb) specifies the action to be performed on the resource receiving an HTTP request. The standard methods for HTTP requests are defined in RFC 2616, Method Definitions. The standard methods include GET, POST, PUT, HEAD, and OPTIONS. Some web applications require (and sometimes introduce) methods that are extensions of HTTP/1.1 methods. Common examples of HTTP exte
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に保存され
よく訓練されたアップル信者、都元です。ELBはAWSにおけるWebシステムを構築する場合、ほぼ確実に利用するコンポーネントとして不動の地位を確立しつつあります。 利用方法としては、ELBを作成して配下にWebサーバを配置するだけというお手軽さがあり、非常に利用しやすいのも大きなメリットです。しかし、ELBの詳細な挙動について、しっかり理解できているでしょうか。本エントリではいつも利用しているELBについて、ちょっと深く突っ込んでみました。 ELBのロードバランシング戦略 ELBの配下には複数のAZにまたがるようにインスタンスを配置するのが一般的です。(cf. AWSにおける可用性の考え方) ELBを作成すると、DNS名が付与されますが、クライアントがELBにアクセスする際、まずこのホスト名をIPアドレスに変換するDNSの正引きリクエスト(下図中の緑色の矢印)を行います。digコマンドを使っ
諸般の理由により、AWSの各サービスの挙動を改めて復習中です。まずは、Amazon Elastic Load Balancing 、通称ELBについてです。ELBの内部の動作については、公開されている公式ドキュメントが割とあります。是非一度しっかりと目を通しておくとよいですよ。少なくともAWSマイスターシリーズのELBについては、読んでおくべきです。簡潔にかつ詳しく説明されているので、理解が格段に進むでしょう。というところで、現段階で私が理解しているELBのアーキテクチャをまとめてみました。 ELBの内部構造 ELBは、ELBエンドポイントとELBインスタンス(仮称)によって構成されます。ELBインスタンス(仮称)の正式名称は知らないので、その名前で呼ぶことにします。ELBインスタンスには、グローバルIPが付与されます。ELBエンドポイントは、myLB-xxx.elb.amazonaws.
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インスタンスへ、自動的にトラフィックを分散する。単
To ensure that a Classic Load Balancer stops sending requests to instances that are de-registering or unhealthy, while keeping the existing connections open, use connection draining. This enables the load balancer to complete in-flight requests made to instances that are de-registering or unhealthy. When you enable connection draining, you can specify a maximum time for the load balancer to keep c
Build RAG applications with MongoDB Atlas, now available in Knowledge Bases for Amazon Bedrock Foundational models (FMs) are trained on large volumes of data and use billions of parameters. However, in order to answer customers’ questions related to domain-specific private data, they need to reference an authoritative knowledge base outside of the model’s training data sources. This is commonly ac
みんな大好きElastic Load Balancing(以下ELB)は利用にあたっては細かい仕様に注意する必要があります。 2014年ELBにお世話になった人もそうでない人も2015年はもっとELBを活用するために、改めてELBの仕様や活用方法を振り返ってみましょう。 ※本稿の内容の多くは一度でもELBを使ったことがある方を想定しています。 ELBが得意なところ ELBはコスト効果良く高い可用性と拡張性をもつロードバランサーをサービスとして提供してくれるので、最初に利用するロードバランサーとしても、長く使うロードバランサーとしても優秀です。 ELBを活用するためのドキュメントがAWSから公開されています。未読の方は必ず目を通しておきましょう。 Best Practices in Evaluating Elastic Load Balancing ELBが苦手なところ ELBを利用する上で
テーブルを作る GUIで入力もできますが、SQLを書いていきます GUIでテーブル定義を入力するのが結構面倒です 以下、DDL定義です ELB CREATE EXTERNAL TABLE IF NOT EXISTS aws_logs.elb_log ( request_protocol string, request_timestamp string, elb_name string, request_ip string, request_port int, backend_ip string, backend_port int, request_processing_time double, backend_processing_time double, client_response_time double, elb_response_code string, backend_resp
はじめに 今まではログの調査の際には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,
batchiです。 ELBには下記2つのスキームがありますね。 ●インターネット向け(internet-facing) ●内部向け(internal) 両者の違いは、ELBのロードバランサーノードが、 グローバルIPを持つか否かです。 今回は、内部向けロードバランサーに対して、 オンプレミス環境からDirectconnect経由でアクセスする際のケースを考えてみます。 IPではなくエンドポイントで指定する ELBという一つのコンポーネントではありますが、 裏側では1つ以上のロードバランサーノードがそれぞれIPを保有しています。 このIPは可変であるため、ELBへのアクセスはIPではなく、 エンドポイントで指定する必要があります。 複数プールされているIPのいずれかが、DNSラウンドロビンで返されます。 エンドポイントとは 僕自身しっくりくる説明ができないのですが、 「グローバルに解決可能な
はじめに こんにちは、技術3課の紅林です。年始早々に風邪を引いてしまい、なかなか辛い正月を過ごすことになってしまいました。 今回、AWSのElastic Load BalancingのClassic Load Balancer (以下、ELB)のスティッキーセッション機能についてまとめてみました。 目次は以下の通りとなります。 はじめに ELBのスティッキーセッション、その前に Cookieについて Cookieの動作例 テストコード 動作概要 動作結果 パケットキャプチャ セッションについて ELBのスティッキーセッションについて 概要 検証構成概要 コード 維持無し 動作確認 ELBによって生成されたCookieの維持 シーケンス図 動作確認 アプリケーションによって生成されたCookieの維持 シーケンス図 動作確認 注意点 おわりに ELBのスティッキーセッション、その前に ELB
Elastic Load Balancing provides access logs that capture detailed information about requests sent to your load balancer. Each log contains information such as the time the request was received, the client's IP address, latencies, request paths, and server responses. You can use these access logs to analyze traffic patterns and to troubleshoot issues. Access logs are an optional feature of Elastic
Summary VPC 内にたてた ELB(internet-facing/internal) のプライベート IP アドレスをコマンドラインツールの AWS-CLI から調べる方法をメモ。 tl;dr : EC2 DescribeNetworkInterfaces を使う EC2 サービスには DescribeNetworkInterfaces という NIC 向けの API が存在する。この API を使うと ELB のグローバル/プライベート IP アドレスを確認できる。 NIC 一覧からお目当ての ELB を突き止めるには? ELB インスタンスの NIC の設定は aws が裏でやっているためか、ELB のNIC は Attachment => InstanceOwnerId が “amazon-elb” となっている。 また NIC の Description も aws が勝
ELBについて深く知りたくなってしまったので、改めて調べたり聞いたりした。 今回そもそも知りたかったポイントは下記の2点 ELBがどういう仕組みで膨大なトラフィックに耐えているのか ELBで稀に障害が発生するみたいなので、その影響をなんとか回避できないか ELBの概要 内部仕様に踏み込む前に、改めて概要と基本機能を確認。 ELBの役割 ELB(ElasticLoadBalancer)は、Webトラフィックを配下のEC2Instanceに適切に分散してバランスを取る仕組み、いわゆるロードバランサー。なぜ分散させる必要があるかというと、1台のサーバで処理可能なトラフィックには限りがあるから。また、AutoScalingや、Zone間分散(Multi-AZ)といった構成をとる為にも必要となる。 ELBの基本機能 ELBの基本機能は、高負荷システムにおいて、肝となる重要なものばかり 負荷分散
■ [AWS] ELBでHTTPリスナーだとWebSocketは使えない ELBを使っていて、WebSocketを使おうとしたときに、最初のハンドシェイクが上手くいかないという問題に遭遇した。 テストするために、node.jpのドキュメントから、http.ClientReqestにあるサンプルを使ってみた。ここのEvent: 'Upgrade'のところにあるサンプルコードを若干改造して下記のようなコードを用意した。 var http = require('http'); var net = require('net'); // Create an HTTP server var srv = http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く