少し前に，Facebookのロードバランサが話題になっていた． blog.stanaka.org このエントリを読んで，各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた． ざっくり検索した限りだと，Microsoft, CloudFlareの事例が見つかったので，Facebookの例も併せてまとめてみた． アーキテクチャ部分に注目してまとめたので，マネジメント方法や実装方法，ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする． 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた？)ロードバランサのアーキテクチャは，下記の論文が詳しい． Parveen Patel et al., Ananta: cloud scale load balancing
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
『Linuxロードバランサ構築・運用ノウハウ』を公開します！ これはWEB+DB PRESS Vol.37の特集記事としてDSASチームが執筆したもので、技術評論社様の許可を得て今回公開するはこびとなりました。 一口でいうと、「Linux＋IPVS＋keepalivedを使って、冗長構成(Active/Backup)のロードバランサを作るまで」の解説記事で、 サーバ負荷分散一般についてのはなし Linuxでロードバランサを作ってみる ロードバランサを冗長化 といった構成になっています。 みなさんがLinuxロードバランサを導入・構築・運用する際の一助になれば、DSASチームとしてもうれしい限りですので、是非、ご覧になってください！ 第1章 サーバ負荷分散概論 特集のはじめに なぜサーバ負荷分散をするのか？ サーバ負荷分散の実現方法 ロードバランサのいる構成 ロードバランサはなにを元に分散す
そもそも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
【新機能】新しいロードバランサー 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証明書を選択しま
最近、SREが話題ですね。 tech.mercari.com www.wantedly.com ということでSREについて調べてたら、SREconなんてものが開催されていたので中を見てたら、「Building a Billion User Load Balancer」というタイトルでFacebookのDNS〜LBまでの話があったので、そのメモです。 Building a Billion User Load Balancer | USENIX tl;dr tinydns + IPVS で Facebook規模はいける httpsの接続確立はかなり重い(RTTの4倍 = RTT 150msとするとGETまで600ms)ので、太平洋越えとかは厳しい httpsを終端させるCDNとかは活用の可能性ありそう (国内だけを考慮するなら影響は軽微かも) メモ L4 LB shiv (IPVS + pyt
昨日書いたの通り，記事を寄稿したWEB+DB PRESS Vol.37が，今日発売になりました．それを記念して(?)，記事の内容が簡単に実験できるパッケージを公開します． これは，VMWareを使って，だれでも直ぐにロードバランサの実験を始められるパッケージになっています．何台もマシンを集めたり，Linux をインストールする必要は一切ありません．無償配布されているVMWare Playerがあれば，いつでもどこでも実験ができます． もちろん，このブログで去年の夏に公開した4つのエントリ こんなに簡単！ Linuxでロードバランサ (1) こんなに簡単！ Linuxでロードバランサ (2) こんなに簡単！ Linuxでロードバランサ (3) 高トラフィックに対応できるLinuxロードバランサを目指して〜LVSをNATからDSRへ の実験もできます． ダウンロードはこちらからどうぞ(75MB
ロードバランサーってなんやねん
はじめに どもども、インフラ案件で奮闘中の井上弥風（いのうえみふう）です。 現在プロジェクトでELB（Elastic Load Balancing）を使用しており、その内部機能を完全に理解したいと思い、この記事を書きました。 この記事について この記事の最終的な目標は、「ELBとは何か？」を深く理解し、それを自信を持って説明できるレベルになることです。 しかし、ELBを完全に理解するためには、まず基本的なロードバランサーの概念を押さえる必要がありました。 そこで、この記事ではELBの根底にあるロードバランサーとは何かという点に焦点を当てていきます。 ELBの詳細については、この記事の後に公開予定の「ELBってなんやねん」という記事で詳しく取り上げます。 ELBに興味のある方は、ぜひそちらもご覧ください。 記事のゴール この記事を通じて、ロードバランサーがどのようにしてトラフィックの負荷分散
SREチームの@cubicdaiyaです。今回はnginxによるTCPレイヤーでのロードバランスについて解説します。 ロードバランサーとしてのnginx nginxはHTTPやTCP、UDP等の複数のレイヤーでロードバランサーとして稼働させることができます。（TCPロードバランサーは1.9.0以降、UDPロードバランサーは1.9.13以降で利用可能です） また、ngx_http_ssl_module や ngx_stream_ssl_module を利用することでそれぞれのレイヤーでTLSを有効化することも可能です。 TCPロードバランサー用のモジュールを有効にする HTTPレイヤーでロードバランスするためのモジュールはデフォルトで組み込まれますが、TCP(とUDP)レイヤーでロードバランスするにはnginxのconfigureスクリプトに--with-stream(あるいは --with
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
Docker ロードバランサ内部実装
先日のDockerCon16でDocker 1.12RCが発表されまして，主な機能追加として SwarmのDocker engineへの統合とそれに伴うクラスタ構築の簡略化 Service機能の追加 Load Balancer機能の追加 が発表されました． 今回はSwarmクラスタの構築~Serviceの定義まで行って，ロードバランサの内部実装を詳しく追ってみます． Docker 1.12RCのインストール これは既にget dockerで問題なく可能です． 今回はAWS上にクラスタを構築します． node1(master) : ip-172-31-1-218 node2 : ip-172-31-1-219 node3 : ip-172-31-1-217 これら３台のホスト上でそれぞれ以下のコマンドでDocker 1.12をインストールします． $ wget -qO- https://ex
LVS構築における最強の手順書を残してみました。 はじめに ロードバランサ（LVS）の需要は間違いなくあると思うのですが、いかんせんネットに情報が少ない。 かの有名な「サーバ/インフラを支える技術」が出版された2008年あたりがピークの感がある。(Klabさんの記事には大変お世話になりました) Googleで調べてもまとまった情報がなかったりするので、最初は大変でした。 普段インフラ周りで仕事しているので、そこで培ったノウハウを出したいと思います。マイブログ史上最大の情報量。 今回は「CentOS6.4 x86_64マシン」に「最新版keepalived-1.2.7を導入」で「割りと本番運用に耐えられる手順」を解説。もちろん定番のIPVS + Keepalived のDirect Server Return(DSR)構成。 ※是非コメント欄でもさらに有益な情報がありましたら歓迎です。 内容
AWS側の目線から理解する、Google Cloud ロードバランサの世界 - How elegant the tech world is...!
はじめに お久しぶりです、iselegantです。 今回はAWSアーキテクトの目線から、多様なGoogle Cloud Load Balancingの世界を紹介してみたいと思います。 昨今、担当業務やプロジェクトによってはAWSのみならずGoogle Cloudを活用したり、マルチクラウドとして両方扱うエンジニアの方も多くなってきたのではないでしょうか？ 特に、SI企業に所属する人においては、担当プロジェクトや業務、お客様が変われば利用するクラウドサービスも変わる、なんてこともよくあると思います。 私もその道を辿ってきた一人です。 現在ではクラウドサービス間においてもある程度のコモディティ化が進んでおり、ある一つのクラウドサービスに精通すると、他のクラウドサービス利用時におけるメンタルモデルが出来上がり、システムを構築する際に前提の知識や経験が大いに役立つはずです。特にAWSはサービスの幅
ロードバランサは高いので、Linuxで比較的簡単にL4の負荷分散を行えるLVSは使いドコロが色々あり結構便利。 久々に作った時のメモがわりとして、今回は、LVSの構築手順と簡単なテスト結果を順に書いてみた。 構成 ちょっと特殊な要件があり、負荷分散行うLVSも実際にレスポンス返すアプリも同じ筐体で動かしたいという前提で作った。 ※最初の投稿だと、同一筐体で動かした時にBACKUP STATEのLVSがARP応答する設定になっていたので、加筆！ LVS単体サーバとしても下記の手順で同じように作れる サーバはaa,bbの2台(vagrant上の仮想マシンとした) 同じ役割を持つサーバaa,bbをLVSを使って負荷分散したい LVS自身も冗長構成にして、aa,bbにやらせたい リクエスト元は、同一セグメントなのでDSR(Direct Server Return)を使う ※NATは、戻す時に直接L
はじめに Nginx でロードバランサを構成する Webサーバ1号機の作成 Webサーバ2号機の作成 ロードバランサの作成 ロードバランサとWebサーバの起動 Web アプリケーションの準備 Docker でアプリケーションをビルドする DBサーバの準備 ロードバランサとアプリケーションサーバの起動 まとめ はじめに 前回は Docker のインストールからイメージビルド・コンテナ起動・Compose までの流れをみてきました。 blog1.mammb.com 今回は以下のような、一般的な Web アプリケーションの開発環境を構築していきます。 前回の記事とあわせて、Docker の活用方法を理解いただければと思います。 Nginx でロードバランサを構成する 最初に、単純な Web サーバを Nginx でロードバランシングする環境を作成して動作を見てみます。 このような構成となります。
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか つっこみどころが満載スギなのは脇においておいて、金をかけないなら、DNSラウンドロビンじゃなくて、せめて、件の記事でも紹介されている Apache 2.2のmod_proxy_balancer か、Apache 2.2じゃなくても使えるreverse proxy系の実装たち、 POUND mod_backhand Perlbal を使うべきでしょう。 んで、「L7ロードバランサ（要はreverse proxy）なんていらねっす。セッション？ んなのmemcachedでシェアすりゃいいんじゃん。その方がスケールアウトしやすいしー」という向きには、LinuxでL4のロードバランサするのをオススメでします。まともなL4ロードバランサが手に入るのに、金銭的コストはゼロですってよ、オクサン！ Linux Virtual Serve
Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。（編集部） Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの
高トラフィックに対応できるLinuxロードバランサを目指して 〜 LVSをNATからDSRへ : DSAS開発者の部屋
「こんなに簡単！ Linuxでロードバランサ」のシリーズでは、 こんなに簡単！ Linuxでロードバランサ (1) 〜 LVS + NATで負荷分散をしてみよう こんなに簡単！ Linuxでロードバランサ (2) 〜 keepalivedでWebサーバのヘルスチェック こんなに簡単！ Linuxでロードバランサ (3) 〜 VRRPでロードバランサを無停止にする こんな流れでNATによる負荷分散システムを構築してきました。 今回はこれを DSR(Direct Server Return) 方式に変更してみます。 「DSRとはなんぞや？」という方は、 ロードバランサの運用.DSRって知ってますか? L4スイッチはDSR構成にすべし こちらでわかりやすく説明されていますので参考にしてみてください。 一般的(?)に大規模システムを構築する場合は、「ネットワーク機器の整備はこの部門」、「サーバの調
前回までで、 複数のWebサーバにロードバランスする というところまではできました。 これでリアルサーバへ負荷分散することができたのですが、冗長性がありませんでした。つまり、リアルサーバがダウンしても、ロードバランサはそれを認識できず、ダウンしているリアルサーバなのにパケットを送ってしまっていました。 このとき、クライアントから見ると、たまにサーバから応答がないように見えてしまいます。 というわけで今回は冗長化のお話、 リアルサーバのヘルスチェック を紹介したいと思います。 今回はkeepalivedを使います。 おおざっぱにいうと、keepalivedは2つの機能を提供します。 1. ヘルスチェック機構と連携したIPVSでのリアルサーバの管理 (--check) 前回ipvsadmコマンドを使って行ったような、バーチャルIPアドレス (VIP) やリアルサーバの管理を設定ファイルに記述す
富士通の“政府認定クラウド”への不正アクセス、ユーザーのメール本文なども盗まれた可能性 復号されたパケットがロードバランサーを通過
富士通の“政府認定クラウド”への不正アクセス、ユーザーのメール本文なども盗まれた可能性 復号されたパケットがロードバランサーを通過 富士通クラウドテクノロジーズのパブリッククラウド「ニフクラ」「FJcloud-V」が不正アクセスを受け、一部ユーザーの認証情報などが盗まれた可能性がある件について、同社は5月31日、ユーザーのメールアドレスやメール本文なども窃取された恐れがあると発表した。脆弱（ぜいじゃく）性のあったロードバランサー（負荷分散用の装置）を、復号後の通信パケットが通過していたことを確認したという。 復号された状態でロードバランサーを通過していたデータは、（1）両サービスで提供しているメール配信機能「ESS」で配信したメールのアドレスや本文、配信ログ、（2）富士通クラウドテクノロジーズのWebサイトから問い合わせや申し込みをした顧客情報のうち、会社名や担当者名など、（3）同社が業務
図1: QUICコネクションを振り分けるロードバランサはじめに本記事では、バックエンドのWebサーバへリクエストを振り分ける装置の意味でのロードバランサ(図1)について、QUIC対応の議論状況を紹介します。方式編と実装編にわけて二編を予定しており、本稿は方式についての解説です。 IETFでは、F5 Networksとマイクロソフトから提案されたロードバランシング方式が議論されています。本稿では下記のインターネットドラフトをQUIC-LBと表記します。 QUIC-LB: Generating Routable QUIC Connection IDs https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers 執筆時点の -07 をベースとしますが、ドラフトですので今後の議論次第で改版が続きます。あらかじめご承知おき
NGINX、F5による買収を正式発表。F5のロードバランサとNGINXのプロキシなどにより総合的なアプリケーションサービスを提供
NGINX、F5による買収を正式発表。F5のロードバランサとNGINXのプロキシなどにより総合的なアプリケーションサービスを提供 オープンソースの軽量なWebサーバなどを提供しているNGINXが、F5 Networksによって買収されたことを発表しました（プレスリリース、NGINX CEO Gus Robertson氏のブログ）。 Today @F5Networks Acquires #NGINX to Bridge NetOps & DevOps https://t.co/ZUXcfXKCBe pic.twitter.com/3m4YsKW2C2 — NGINX, Inc. (@nginx) 2019年3月11日 F5は負荷分散を実現するロードバランサのBIG-IPやアプリケーションファイアウォールなどで知られる企業。大規模システムにおけるネットワーク構築やインフラ構築の分野で有名です。
みなさんどうもこんにちは。CTOの馬場です。 最近DELLのサーバ(R410)で、CentOS6.3を使ってLVS+keepalivedなロードバランサを構築したら 見事にハマったりしたので記念ポスト。 ちょっと長いので、一番のドハマリだけ見たい方は最後の「通信速度が著しく遅い件」だけでも見ていただけるとよろしいかと思います。かしこ。 eth0、eth1がない件 いやー。びびった。まじでびびった。 インターフェース名がem1、em2になってます。きもい。 このあたりを参考に対応します。 Getting back to using eth0 in Fedora 15 /boot/grub/grub.conf に biosdevname=0 追記 /etc/udev/rules.d/70-persistent-net.rules の NAME を変更 /etc/sysconfig/networ
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか:Web屋のネタ帳 on CNET - CNET Japan
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか 公開日時： 2006/08/10 20:23 著者： watanabe 結論。DNSラウンドロビンという古くからある技術を取り巻く状況の変化を見過ごしている結果、負荷分散と可用性確保のために高価なロードバランサー機器を導入しているWebサイトは、実は大幅に金を無駄にしているのかもしれない。 一部の人には「今頃気がついたか」と笑われる可能性が高い話だ。 筆者が気づいたきっかけはとあるブログに書かれたこんな一節である。 あまり知られていないことかもしれませんが、DNS があるホスト名に対して複数の IP アドレスを返した場合、多くのウェブブラウザは、その全てのアドレスに対して接続を試みます (接続に成功するまで)。 Kazuho@Cybozu Labs: DNS ラウンドロビンと高可用性 (High Avail
LVSで実現するロードバランサ - KLablabWiki
環境構築 それでは実際に、Linuxベースのロードバランサを構築していきます。最近では標準でIPVSをサポートしているディストリビューションが多いので、必要なパッケージをインストールして少し設定するだけで動作させることができる便利な世の中になってきています。 今回使用するソフトウエアについて Debian GNU/Linux3.1(sarge) ディストリビューションはDebianを使用します。 IPVS対応カーネル ロードバランサの基本機能であるIPVSはカーネルの内部に実装されています。そのためIPVSに対応したカーネルが必要になります。Debian付属のカーネルイメージ（2.6.8-3）でも利用できますし、自前で再構築してもかまいません。カーネルを再構築する際の注意点については後述します。 ipvsadm IPVSを制御するためのツールです。仮想サーバグループの追加やリアル
前回はkeepalivedを使ってWebサーバを冗長化してみました。 今回はkeepalivedのもう一つの機能であるVRRPを使って、ロードバランサ自身を冗長構成にしてみたいと思います。 ┌─────┐ │ client │ └──┬──┘ │[10.10.31.200] │ ━━━━━━━┯━━━━┷━━━━━┯━━━━━━━━━ 10.10.31.0/24 │ │ │ │ │ ←(10.10.31.10) → │ │ ←{10.10.31.100}→ │ [10.10.31.11]│ │[10.10.31.12] ┌─┴─┐ ┌─┴─┐ │ lv1 │ │ lv2 │ └─┬─┘ └─┬─┘ [192.168.31.11]│ │[192.168.31.12] │ ←(192.168.31.10)→│ │ │ ━━━━━━┯┷━━━━━━━━━━┷┯━━━━━━━━ 192.168.3
10月13日深夜から10月14日にかけて起きたポータルサイト「Yahoo！Japan」のアクセス障害について、ヤフーはCNET Japanの電話取材に応じ、原因を説明した。 Yahoo！Japanでは、10月13日午後11時33分から10月14日午前0時56分の約1時間半の間にアクセスした際、サイトが表示されない、もしくはサイトの一部が表示されても画像が表示されないという障害が発生していた。 ヤフーによると、原因は負荷分散用サーバの一部に物理障害が起きたためだという。「同時期に他社でもアクセス障害があったようだが、調査したところ外部からの攻撃は認められなかった」（ヤフー）。その後、同社では14日1時から約2時間、トップページにてアクセス障害についての謝罪文を掲載していた。今後は広告主などにむけて、個別に状況を説明するとしている。
「Linux Virtual Server」と「Keepalived」で作る冗長化ロードバランサ | さくらのナレッジ
多数のクライアントがアクセスするような負荷の高いサービスや停止させられないサービスを運用する場合、複数のサーバーを使ってサービスの負荷分散や冗長化を行うのが一般的だ。本記事では、「Linux Virtual Server（LVS）」を使ってこのような構成を実現する方法について紹介する。 Linuxサーバーをロードバランサにする「Linux Virtual Server」（LVS） 最近では多数のCPUコアを持つサーバーが安価で利用できるようになり、サーバー1台の処理能力は飛躍的に向上している。しかし、リクエストの処理に多くのリソースを使用するようなサービスや、短時間に多数のリクエストを処理する必要があるサービスでは、1台のサーバーだけでは処理能力が不足する場合がある。このような場合、複数台のサーバーで同じサービスを運用し、ロードバランサを使ってリクエストを振り分けることで負荷の分散を図るこ
富士通クラウドテクノロジーズは5月16日、政府のクラウドサービス認定制度「政府情報システムのためのセキュリティ評価制度」（ISMAP）に登録しているパブリッククラウド「ニフクラ」「FJcloud-V」が不正アクセスを受けたと発表した。ロードバランサー（負荷分散用の装置）の脆弱性を突かれ、一部ユーザーのデータや認証情報を盗まれた可能性があるという。 不正アクセスがあったのは7日午後3時ごろから9日午後10時30分ごろの間で、サービスのコントロールパネルやAPIへのアクセス情報、ロードバランサーを経由した情報、ロードバランサー上にあるユーザー証明データなどが盗まれた可能性がある。 攻撃者は4日に装置メーカーが公表した脆弱（ぜいじゃく）性を悪用して侵入したとみられる。富士通クラウドテクノロジーズによる防御システムの設定不備も原因になった可能性がある。同社は12日までに脆弱性の修正とアクセス防御を
[新機能]静的なIPを持つロードバランサーNetwork Load Balancer（NLB）が発表されました！ | DevelopersIO
[新機能]静的なIPを持つロードバランサーNetwork Load Balancer（NLB）が発表されました！ ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程新しいロードバランサーNetwork Load Balancer（NLB）が発表されました！ New Network Load Balancer – Effortless Scaling to Millions of Requests per Second Announcing Network Load Balancer for Elastic Load Balancing Network Load Balancer Network Load Balancer（NLB）はApplication Load Balancer(ALB)と異なりL4のロードバランサーです。 特徴 Network Load Balancerには以
何気に流行っているらしいロードバランサー nginx を使ってみる - 傀儡師の館.Python - 楽天ブログ（Blog）
2007.07.21 何気に流行っているらしいロードバランサー nginx を使ってみる カテゴリ：その他 Scaling Python for High-Load Web Sites を読んでいたら、この中で Load Balancer として nginx があげられている。Perlbal を試してみようかなと思っていたところなのだが、とりあえず nginx について先に調べてみる。pound とも最終的に比べる必要ありか。 Online Security Blog によるとGoogle Web server software distribution across the Internet の 4% が nginxらしい。 Netcraft では 2007年6月時点で 0.19% と少な目。でも Zope の 0.03% より多いし、thttpd や Resin よりも多いといえば十分
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ロードバランサのアーキテクチャいろいろ - yunazuno.log
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1)
DSAS開発者の部屋:特集記事『Linuxロードバランサ構築・運用ノウハウ』を公開します
GoogleのHTTPロードバランサーの破壊力があり過ぎる #gcpja - Qiita
世界中の「Firefox」が一時的に使用不能になった問題について、Mozillaが詳細を明かす／ロードバランサ―の設定とHTTP/3接続に関する問題が引き金に
facebookの13億ユーザーを支えるロードバランサーの話 - stanaka's blog
DSAS開発者の部屋:パソコン1台ではじめるロードバランサ体験
nginxによるTCPロードバランサー | メルカリエンジニアリング
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
KeepalivedによるロードバランサLVS構築 - RLB
LinuxでL4のロードバランサを簡単に作る手順 - Qiita
Docker でロードバランサ・アプリケーションサーバ・DBサーバの環境構築 - A Memorandum
(ひ)メモ - そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか
Poundで作るロードバランサとSSLラッパ（1/4） ― ＠IT
こんなに簡単！ Linuxでロードバランサ (2) : DSAS開発者の部屋
インフラエンジニアなら気になるQUICのロードバランサ (方式編)
DELLのサーバでCentOS6でLVS+keepalivedなロードバランサを構築したらハマったりした話
こんなに簡単！ Linuxでロードバランサ (3) : DSAS開発者の部屋
Yahoo! Japanのアクセス障害、原因はロードバランサーの物理障害
富士通の“政府認定クラウド”に不正アクセス 認証情報など盗まれた可能性 ロードバランサーの脆弱性悪用