gRPC Load Balancing
This post describes various load balancing scenarios seen when deploying gRPC. If you use gRPC with multiple backends, this document is for you. A large scale gRPC deployment typically has a number of identical back-end instances, and a number of clients. Each server has a certain capacity. Load balancing is used for distributing the load from clients optimally across available servers. Why gRPC?g
Using iptables to balance Node.js processes
One of the challenges in building a web application on any platform is making sure it can handle enough visitors. That’s a fairly well known and understood challenge for apps hosted on Apache, which is where most of our experience has been. It’s a new ballgame when we’re talking about Node.js based apps. The NodePing web application is all Node.js on the server, with lots of jQuery driven Ajax on
Envoy: C++ L7 proxy and communication bus
Envoy Tweet Docs C++ L7 proxy and communication bus Envoy is an open source edge and service proxy, from the developers at Lyft Out of process architecture Envoy is a self contained server. It runs alongside any application language or framework. At Lyft we currently use it to proxy for PHP, Python, Go, Java, and C++. HTTP/2 Envoy has first class support for HTTP/2 for both incoming and outgoing c
Nginx balancer_by_luaの話とupstream名前解決の話 - Qiita
balancer_by_lua_xxxxx いつの間にやら1 lua-nginx-module に balancer_by_lua_xxx という新しいディレクティブが増えていました。 以下ドキュメントより抜粋。 http { upstream backend { server 0.0.0.1; # just an invalid address as a place holder balancer_by_lua_block { local balancer = require "ngx.balancer" local host = "127.0.0.2" local port = 8080 local ok, err = balancer.set_current_peer(host, port) if not ok then ngx.log(ngx.ERR, "failed to set
イマドキのWeb屋さんが考えるネットワーク
クラウド事業者から見たインフラの変化 イマドキのWeb屋さんが考えるネット ワーク Amazon Web Services 技術本部 シニアマネージャ ソリューションアーキテクト 荒木靖宏 自己紹介 • 名前 – 荒木 靖宏 • 所属 – アマゾンデータサービスジャパン株式会社 – 技術本部レディネスソリューション部 シニアマネージャ • 好きなAWSサービス – Amazon Virtual Private Cloud – AWS Direct Connect 2 共通認識と業界トレンド 2017年には従業員の半数以上が自分のデバイスを業務に使うようにな る（Source：ガートナー） 40％のビジネスと技術の方向付けをする専門家が既に複数のクラウドを 使うか、使う予定（Source：Forrester） 2020年までに500億のデバイスがインターネットに繋がる（Source： AT&
Traefik Labs: Say Goodbye to Connectivity Chaos
A centralized routing solution for your Kubernetes deployment
GoogleのHTTPロードバランサーの破壊力があり過ぎる #gcpja - Qiita
そもそもGoogle Compute Engineのロードバランサー、GCE LBは、1インスタンス・1グローバルIP・ウォームアップなしでいきなり100万リクエスト／秒を捌けてしまう謎性能を備えていて、既存の他社クラウドのLBだけこれで置き換えたい！ という声もちらほら聞かれるほどの強力LBサービスであった。 From Compute Engine Load Balancing hits 1 million requests per second! そして今回、正式公開ではないLimited Preview版ではあるものの、GCE LBの新機能としてHTTP Load Balancingが発表された。その性能と機能の破壊力があり過ぎるので、GCPブログ記事のリンクをシェアするだけではあまりにもったいない！ と思い、要点を訳してみた。 DNSに頼らない、1グローバルIPによるUS、EU、A
AWS ELBの社内向け構成ガイドを公開してみる 負荷分散編 – Cross-Zone Routingを踏まえて ｜ DevelopersIO
ども、大瀧です。 最近、お客さまからの問い合わせからElastic Load Balancing(ELB)の負荷分散について調べ社内資料としてまとめる機会がありました。せっかくなので、ブログ記事として公開してみます。内容は随時アップデートしますので、ツッコミ・ご指摘があればぜひお願いします！ 負荷分散の仕組み ELBは、クライアントのリクエストを受け付けEC2インスタンスにトラフィックを転送するために、2種類の負荷分散を組み合わせて動作します。 スケーラビリティと冗長性のために、ELBはロードバランサの機能を提供するノードを複数動作させるはたらきがあり、クライアントから複数のノードへアクセスを分散させるためにDNSラウンドロビン、ノードからEC2インスタンスへのトラフィック転送を分散させるためにLeast Connsという手法を用いています。 DNSラウンドロビン DNSラウンドロビンはそ
ロードバランスを考える
概要 次の制約下におけるロードバランシングに関する悩みを議論します。（これはコンテンツ屋によくある制約だと思っています） /24のサイズを超えるサーバ群にバランシングしたい 複数セットのロードバランサを並列で運用したい クライアントのIPをサーバで知りたい SSLの通信が含まれる もちろんコストは抑えたい 発表内容は次の流れを想定しています。 今回前提としている制約のどこが難しいか NATするとLBにパケットを返さないといけない SNATもするとクライアントIPがわからない（暗号化されてなければ、x-forwarded-forの挿入もできる） SNATしないとLBに返す工夫をしないといけない NATしない場合 macアドレス書き換えの場合は同じセグメントに置かないといけない linuxの場合、arp周り、もしくはiptablesの設定が必要 IPIP等でトンネルするとmssを設定する必要が
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
ELBの扱えるTCP portは25,80, 443 or 1024 to 65535
これもまた知られてないシリーズか。 ELBの扱えるTCP portは25,80, 443 or 1024 to 65535。 そして、違うportにアクセスしてもICMPでrefuseを通知したりはしない。 今は1024 upのものだけですね。HTTPやHTTPS等が特別扱い。。RT @matsukaz: そのうち何とかなるんですかねぇ (´；ω；｀)#jawsug RT @matsukaz: ELBで843ポートが使えないというワナ。まぢかー。 — ARAKI Yasuhiroさん (@ar1) 5月 24, 2012
What are the best load balancing methods, techniques and algorithms?
This kind of question was asked a lot more frequently ten years ago, usually followed by the second most common question: "Why do I need two load balancers?" In fact, we were asked the second question so often that we used it as the title on our homepage for ages. It amazed me that people would go to all the effort of configuring a cluster of multiple application servers but only use ONE load bala
訳：ELB：評価方法のベストプラクティス - aws memo
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インスタンスへ、自動的にトラフィックを分散する。単
How elastic are Amazon Elastic Load Balancers (ELB)? Not very it seems
This is where I record my rants, comment, quotes and thoughts on things. I welcome your input, please fire away. Find out more about me at: http://mattheworiordan.com How elastic are Amazon Elastic Load Balancers (ELB)? Not very it seems Update: Since I made this post, Amazon have in fact been in touch and have been extremely helpful looking into this issue and running numerous tests to ensure ELB
Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。
Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。 鯖管のメモ帳: AWSのELBでHealthyHostCountが0になるという記事の中で ■AWSのELBとApacheを使う際の注意点 ・Timeoutは120以上が推奨 ・ApacheのKeepAliveは有効にすべし。ELBとの接続効率があがる。 という形ですでにやるべきことは書いてあるのが、なぜそうなるか。。(いそがしい人は後は読まなくてok！) 根本的な理由としては、ELBはTCPを単にリレーしているのではなくて、アプリケーションレイヤのプロキシであることによるものが大きい。ELBはバックエンドのEC2との間で無通信の場合でも60秒はセッションを維持する。 ELBはTCP Persistent Connectionを提供し、webサーバとの間のTCP
ロードバランサ｜ネットワーク機器｜【セイコープレシジョン】
戸田建設株式会社様 ロードバランサをSX-3640 LBHに乗り換えました。従来製品に比べ、初期導入費用は約半額、保守費用は約10分の1に削減できました。 詳しく見る
HAProxy で graceful restart する方法 - 酒日記 はてな支店
haproxy には起動後に設定ファイルを読み込み直したりする機能がないので、バランス先を追加するなどの変更が無停止ではできない、と思い込んでいたのだけど実は違った、というお話。 実際、同一プロセスで読み込み直すことはできないのだけども、以下のような手法で graceful に再起動することができる。man はちゃんと読みましょう。 # haproxy -f /path/to/haproxy.conf -sf [既に動いているhaproxyのpid]として -sf オプションに pid を渡して起動すると…… haproxy[2] : 起動 haproxy[2] : 既に動いている haproxy[1] に SIGTTOU を送信 haproxy[1] : SIGTTOU を受けると Listen をやめる 新規接続は受け付けない 既に確立している接続はそのまま維持 haproxy[2]
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/grpc/proposal/blob/master/A5-grpclb-in-dns.md
Application Performance | Google Cloud
Introducing HTTP Load Balancing and SSD Persistent Disk on Google Cloud Platform
