サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
はじめに どもども、インフラ案件で奮闘中の井上弥風（いのうえみふう）です。 現在プロジェクトでELB（Elastic Load Balancing）を使用しており、その内部機能を完全に理解したいと思い、この記事を書きました。 この記事について この記事の最終的な目標は、「ELBとは何か？」を深く理解し、それを自信を持って説明できるレベルになることです。 しかし、ELBを完全に理解するためには、まず基本的なロードバランサーの概念を押さえる必要がありました。 そこで、この記事ではELBの根底にあるロードバランサーとは何かという点に焦点を当てていきます。 ELBの詳細については、この記事の後に公開予定の「ELBってなんやねん」という記事で詳しく取り上げます。 ELBに興味のある方は、ぜひそちらもご覧ください。 記事のゴール この記事を通じて、ロードバランサーがどのようにしてトラフィックの負荷分散
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2024 の14日目です。 ここで書くできごとは、私が12年前に招いたネットワーク障害の話です。 書くにあたって当時の資料やメモを見たのですが、「あああああああああ! 何を考えているんだこのお馬鹿さんは」という気持ちにしかなりませんでした。 こういうことに気を付けねばならない、こういうことをしてはいけないと自戒の碑として、書いておく次第です（ご迷惑をおかけした関係者の皆様、本当にすみませんでした）。皆様の参考になれば幸いです。 背景 担当していたサー
はじめに お久しぶりです、iselegantです。 今回はAWSアーキテクトの目線から、多様なGoogle Cloud Load Balancingの世界を紹介してみたいと思います。 昨今、担当業務やプロジェクトによってはAWSのみならずGoogle Cloudを活用したり、マルチクラウドとして両方扱うエンジニアの方も多くなってきたのではないでしょうか？ 特に、SI企業に所属する人においては、担当プロジェクトや業務、お客様が変われば利用するクラウドサービスも変わる、なんてこともよくあると思います。 私もその道を辿ってきた一人です。 現在ではクラウドサービス間においてもある程度のコモディティ化が進んでおり、ある一つのクラウドサービスに精通すると、他のクラウドサービス利用時におけるメンタルモデルが出来上がり、システムを構築する際に前提の知識や経験が大いに役立つはずです。特にAWSはサービスの幅
富士通の“政府認定クラウド”への不正アクセス、ユーザーのメール本文なども盗まれた可能性 復号されたパケットがロードバランサーを通過 富士通クラウドテクノロジーズのパブリッククラウド「ニフクラ」「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 をベースとしますが、ドラフトですので今後の議論次第で改版が続きます。あらかじめご承知おき
富士通クラウドテクノロジーズは5月16日、政府のクラウドサービス認定制度「政府情報システムのためのセキュリティ評価制度」（ISMAP）に登録しているパブリッククラウド「ニフクラ」「FJcloud-V」が不正アクセスを受けたと発表した。ロードバランサー（負荷分散用の装置）の脆弱性を突かれ、一部ユーザーのデータや認証情報を盗まれた可能性があるという。 不正アクセスがあったのは7日午後3時ごろから9日午後10時30分ごろの間で、サービスのコントロールパネルやAPIへのアクセス情報、ロードバランサーを経由した情報、ロードバランサー上にあるユーザー証明データなどが盗まれた可能性がある。 攻撃者は4日に装置メーカーが公表した脆弱（ぜいじゃく）性を悪用して侵入したとみられる。富士通クラウドテクノロジーズによる防御システムの設定不備も原因になった可能性がある。同社は12日までに脆弱性の修正とアクセス防御を
はじめに この文章はGoでシンプルなL7ロードバランサーを作成するというKasun Vithanageさんの記事を参考にRustでL7ロードバランサーを書いてみたという記事です。ロードバランサーについて、ちゃんと勉強するならそっちを見た方が良いかもしれません。 またこの記事を書いている途中にactix-webのexampleのレポジトリがガッツリとactix-web 2.0-alpha.3に書き換えられました。actix-webの2系はfuturesの0.3系を使っております(actix-webの1系はfuturesの0.1でした)。多いに参考にさせてもらっております。途中までサンプルなしで2.0-alpha.1を強引に動かしていたので非常に助かりました。 成果物 https://github.com/rchaser53/rlb 実装する内容について NginxのようなL7ロードバランサー
富士通の“政府認定クラウド”への不正アクセス、ロードバランサー内で任意のコマンドが実行できる状態だった 被害状況の調査結果 富士通クラウドテクノロジーズのパブリッククラウド「ニフクラ」「FJcloud-V」が不正アクセスを受け、一部ユーザーの認証情報などが盗まれた可能性がある件について、同社は6月7日、不正アクセスの原因となったロードバランサー（負荷分散用の装置）が、一時的に任意のコマンドが実行できる状態にあったことなどが分かったと発表した。 富士通や専門機関などと合同で行った調査で判明したという。調査では他にも、（1）不正アクセスは、ロードバランサーの脆弱性を悪用したものだったこと、（2）ロードバランサー上に、サーバ証明書をはじめとしたユーザー証明データが圧縮されたファイルがあったこと、（3）2022年5月4日～11日の一部タイミングで、ロードバランサーを経由した通信の情報を集めた痕跡が
こんにちは。クラウド基盤本部の野島です。 今年のインターンシップでは、プラットフォーム(自社基盤)コースとして2名の方を受け入れ、それぞれ異なる課題をやってもらいました。 そのうちの一つは Pingora に関する課題で、覚道さんに取り組んでいただきました。（もう一つの課題は nginx のキャッシュの性能に関するもので、これについては昨日の記事をご参照ください） Pingora は Cloudflare が開発したロードバランサのためのフレームワークであり、Rust を使って好きなロジックを組み込んだロードバランサを書くことができます。 今回のインターンでは Pingora を使って TLS のクライアント証明書を使った認証プロキシを作ってもらいました。 そこで、この開発の中で得られた Pingora や OpenSSL に関する知見を共有しようと思います。 この記事は覚道さんのインター
はじめに この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2023 の6日目です。 この記事で取り上げるやらかしは数年前の出来事です。 当時新卒2年目のエンジニアだった私が、ロードバランサ配下のサーバを全部切り離してサービス停止させてしまった話について、ここに供養させていただきます。 自分の失敗談なんて書きとぉないんじゃ、、というのが本音ですが、毎年やらかし系のアドベントカレンダーに勇気と希望をもらっていたので、今年は私もその一助となれたらという思いです。 やらかして死にたくなっているあなたへ。 背景 新卒で入社した会社で社内システム向けインフラの保守運用に携わっていました。 2年目となって仕事にも慣れてきた頃（フラグ）、事を起こしてしまいました。 環境 やらかしの対象となった環境はこちら。 AWS環境上で、ロードバランサとしてELBがあり、その配下にサーバ（
Stay up to date with the latest from the Knowledge Center. See all new Knowledge Center articles published in the last month, and re:Post’s top contributors. 簡単な説明 内部ロードバランサーまたはインターネット向けロードバランサーに関連付けられた IP アドレスは、ロードバランサーの DNS 名を解決することで決定できます。これらは、クライアントがロードバランサー宛のリクエストを送信する IP アドレスです。ELB ノードは、サーバーに転送されるリクエストのソース IP アドレスとして、エラスティックネットワークインターフェイスに関連付けられているプライベート IP アドレスを使用します。Network Load Balancer の
2022年5月16日にお知らせいたしましたFJcloud-Vおよびニフクラ（以下、当該サービス）の一部のロードバランサー機器（以下、当該ロードバランサ―）の脆弱性を悪用した不正アクセスについて、これまで調査・分析を進めて参りました過程において、既にご報告させていただいた内容の他に、情報の窃取が可能となる復号化された通信パケットが当該ロードバランサーを通過していたことを新たに認知いたしました。 新たに認知した事象の対象となるシステムは、メール配信サービス、お客様からのお問合せやお申込みの各種受付システム、契約管理システム（※）になり、データの内容には、メール本文・メールアドレス・会社名・ご担当者名等の情報が含まれる場合があります（クレジットカード情報は保有していないため、対象情報に含まれません）。なお、現時点では情報を窃取された事実は確認されておりません。また、対象となるお客様には既にご報告
FJcloud-Vおよびニフクラ（以下、当該サービス）の一部のロードバランサー（インターネットからのアクセス負荷を分散させるネットワーク装置。以下、当該ロードバランサー）に対して、脆弱性を悪用した不正アクセスが行われていたことを確認しました。 これにより、一部のお客様の業務通信データや当該サービスにアクセスするための認証情報等を窃取できる技術的な可能性があったことを確認しました。 これらの影響を受けた可能性のあるお客様に対しては、本件に関するお知らせと対処に関するお願いを既に実施させていただいております。 なお、現時点では当該ロードバランサーを踏み台としたクラウド基盤内部への不正侵入の形跡ならびに不正アクセスにより情報を外部に持ち出された形跡は確認されておりません。 現在、富士通および富士通クラウドテクノロジーズは緊急対策チームを設置し、さらなる被害状況の調査と対策を進めております。 当該
東急レクリエーションは2025年6月9日、同午前7時ごろから同社が運営するシネマコンプレックス「109シネマズ」のオンラインサービスが停止していると発表した。具体的にはオンラインチケットの購入や会員ページへのログイン、ポイントカード入会申し込みといったサービスが停止した。 東急レクリエーションによれば「負荷分散装置（ロードバランサー）のハードウエア故障が起きたことがサービス停止の理由」（東急レクリエーションの総務部）だという。ハードウエア故障の原因は調査中だ。同社は2025年6月9日午後0時45分時点で「復旧のめどを知らせるのは困難」（総務部）としていたが、同日午後2時20分時点で復旧した。 利用者に対しては「不便を掛け申し訳ない」（総務部）とした。
こんにちは。GMOアドマーケティングのH.Tと申します。 担当しているプロダクトでセキュリティチェックの一環として現在受け付けているリクエストのTLSバージョンや暗号スイートを洗い出す必要がありました。 GCPのロードバランサのカスタムヘッダという機能から確認できたのでご紹介します。 システム構成は以下のような感じです。 External HTTP(S)load balancer → サーバレスNEG → Cloud Run(Goアプリ) 以下Cloudコンソールでの手順になります。 先に公式ドキュメントを読みたい方はこちら 1. ロードバランサ一覧より対象のロードバランサ名をクリックして詳細を開く。 2. 「ロードバランサの詳細」画面から「編集」を開く。 3. 「バックエンド サービス」で対象バックエンドの鉛筆アイコンから「バックエンド サービス」の編集を開く。 4. 下の方にスクロール
米村歩@日本一残業の少ないIT企業社長 @yonemura2006 ロードバランサーが何やってるのかいまいちわからないという顧客に対して「オフィスのトイレの個室が埋まってると困りますよね？ピンチですよね？そんな時には他の空いてるフロアに行きますよね？それで事なきを得ますよね？ロードバランサーとはそういうものです」と説明したら理解してもらえました。 2025-06-12 09:48:27
Application Load Balancer で "ELB 5XXs" が出ていた時の調査方法を、サポートデスクの実例からご紹介します。 最終更新： 2024年1月4日（概念図を追加しました） こんにちは、テクニカルサポートのShimizuです。 サポートデスクにおいて、Application Load Balancer（ALB）をご利用中のお客様から、よく以下のようなお問い合わせをいただきます。 「ALB の 502 エラー（もしくは 504 エラー）の原因調査で、メトリクスの画面に "ELB 5XXs" が出ていますが、"HTTP 5XXs" は出ていません。これはロードバランサー側（AWS基盤側）に問題があったと判断してよいでしょうか？」 結論から言いますと「いいえ」です。 必ずしもロードバランサー側の問題とは限りません。 筆者のサポートデスクでの経験上、多くの場合バックエンド
ELBは正式名称「Amazon Elastic Load Balancing」の通称で、AWS が提供する「負荷分散」に加え、「ヘルスチェック機能」を備えたロードバランササービスです。ELBには多くの特徴（強み）がありますが、最初にELBの3つのロードバランサを紹介しましょう。 AWSが提供するロードバランサには3種類があり、Network Load Balancer（略称NLB）・Application Load Balancer（略称ALB）・Classic Load Balancer（略称CLB）です。 AWSでは、この3種類の中から、利用するシステムの適性に合わせて選択することができます。以下で、それぞれの特徴について説明します。 1.Network Load Balancer（NLB） NLBは、秒間数百万のリクエストを捌けるように設計されたロードバランサです。TCPプロトコルの
re:Invent 2020のセッション「 Choosing the right load balancer for serverless applications 」を聴講しましたのでレポートします。 サーバーレスとありますが、on Fargateで稼働するECSやEKSについても扱っています。ELBファミリーの各サービスの差異や、Lambda、ECS、EKSをターゲットにする場合の注意点、またELBとAPI Gatewayの比較や、マイクロサービスのアーキテクチャーパターンについても述べられていて、非常に有意義なセッションでした。最下部に視聴リンクを置いていますので、より詳しく学びたい方はre:Inventにサインインした上でそちらをご確認ください。 セッション概要 Elastic Load Balancing automatically distributes incoming ap
![[レポート]サーバーレスアプリ用のロードバランサーの選択方法 #reinvent #NET301 | DevelopersIO](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f1fc8bce7c66555564f1e060e786724d616daf7d8%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fdevio2023-media.developers.io%252Fwp-content%252Fuploads%252F2020%252F11%252Feyecatch_reinvent-2020-session-report.jpg&f=jpg&w=240)
はじめに前回のQUICのロードバランサの方式解説に続き、今回はQUIC-LBが実際にどのように動くのかOSS実装を紹介したいと思います。 本稿では、前半はQUIC-LBの実装状況と問題点、およびNginxを改変した実装についてコンフィグと動作イメージを紹介します。後半については、ロードバランスの基礎となっている5タプルによるフロー識別について考えます。フロー識別は、ポリシルーティングやper flow ECMPによるIP転送など、より低レイヤに対しても適用される技術です。もし、L3スイッチやLinuxカーネルのIP転送に対してQUIC向けの拡張をするとどうなるか？ を考えてみます。 QUIC-LBの実装状況と問題点QUIC-LBの提案者である、Martin Duke氏のIETF111での発表によると2つのOSS実装が言及されていました。現状では下記の2つ以外の実装を知り得ていません。 Ma
こんにちは、Google Cloud でプリセールスエンジニアをしている有賀です。 TL; DR表題に関して、いい感じの方法はありません 😥強いて言えば（VM なりサーバーレスサービスなりで作った）プロキシを使うことで実現できますロードバランサーへのアクセス自体も制限してよければ VPC Service Controls も選択肢に入ります目次問題定義Compute Engine、Cloud Run などをプロキシにした IAM アカウントベースのアクセス制限Cloud Storage 閲覧用サービスアカウントの作成Cloud Storage バケットとオブジェクトの用意ファイアウォール ルールでロードバランサーからの VM へのアクセスを許可gcsfuse を使う方法NGINX をプロキシとして使う方法gcs-proxy-cloud-run を使う方法Envoy Proxy を使う方法
ライター：奈良 昌紀 通信事業者のデータセンターにおいてネットワーク・サーバー運用を経験した後、ネットワンシステムズに入社。帯域制御やWAN高速化製品担当を経て、2008年から仮想化関連製品を担当。現在は主にクラウドやコンテナなどの技術領域を担当。 はじめに 以前、こちらのBlogで「Kubernetesネットワーク入門」を掲載させていただきました。今回はKubernetesクラスターにおいて、外部ロードバランサーがどの様に利用されるのかご紹介します。 Kubernetesクラスター内で起動するPodをクラスター外部に公開する方法として、Service (type: LoadBalancer)リソースを利用する方法と、Ingressリソースを利用する方法があります。いずれの方法も、クラスター外のロードバランサーを利用して、クラスター内のPodにリクエストを届ける必要があります。 クラウド環
2022年5月16日にお知らせいたしましたFJcloud-Vおよびニフクラ（以下、当該サービス）の一部のロードバランサー機器（以下、当該ロードバランサー）の脆弱性を悪用した不正アクセスについて、外部の専門機関および当社にて実施しておりましたフォレンジック調査の結果等を以下のとおりお知らせいたします。 当該サービスをご利用のお客様および関係者の方々には、多大なるご迷惑とご心配をおかけしますことを、改めて深くお詫び申し上げます。この度の不正アクセスを重く受け止め、安心してご利用いただけるようセキュリティ対策をより一層強化してまいります。 1．本件の概要（再掲） （１）対象期間：2022年5月4日～2022年5月11日 （２）事象概要：当該ロードバランサーに不正アクセスがあったことで、当該ロードバランサー上のお客様証明書データ等 および当該ロードバランサーを通過した通信パケットを窃取された可能性
※この投稿は米国時間 2022 年 7 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。 クラウドでワークロードをプロビジョニングしてアプリケーションを提供する場合、ロードバランサ（LB）をそのアプリケーションまたはサービスのフロントエンドに配置することを強くおすすめします。ロードバランサは、リクエストを処理できる容量を備えたさまざまなバックエンド（インスタンス グループ、ネットワーク エンドポイント グループ、Cloud Storage など）に、ユーザー アプリケーションのリクエストをリダイレクトします。 Google Cloud のロード バランシングは、最大限のスケーラビリティを備えた分散型の冗長化されたマネージド サービスです。グローバル外部、リージョン外部、リージョン内部など、さまざまな種類があります。Cloud Load Balancing に
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes 第98回 インターネット上のロードバランサーの構成調査（パート2） (中井悦司) 2021年2月 はじめに 前回に続いて、2020年に公開された論文「Classification of load balancing in the Internet(PDF）」を紹介します。この中では、ネットワーク経路を調べる伝統的なツールである「traceroute」をロードバランサーを含む経路に対応するための拡張手法が提案されており、さらにこれを用いた実際の調査結果が示されています。今回は、調査結果の内容を紹介します。 データセット 冒頭の論文では、19,866種類のIPv4アドレス、および、16,674種類のIPv6アドレスに対して、特定の31地点からのネットワーク経路を調
本記事は、2021年9月16日に開催された Google の公式イベント「オープンクラウドサミット」において、 Google Cloud のカスタマーエンジニアである有賀征爾氏が講演された「 Google Cloud の多彩なロードバランサーを一気にご紹介」のレポート記事となります。 今回は、 Google Cloud （GCP）に搭載されている多彩なロードバランサーの分類や構成、機能などについて、それぞれ具体的に解説します。実際の構成を図でわかりやすく示していますので、ぜひ最後までご覧ください。 なお、本記事内で使用している画像に関しては、オープンクラウドサミット「 Google Cloud の多彩なロードバランサーを一気にご紹介」を出典元として参照しております。 それでは、早速内容を見ていきましょう。 ロードバランサーの分類 まずは Google Cloud （GCP）のロードバランサ
注: nginx のバージョン要件は 1.9 以降です。nginx をコンパイルするときは、--with-stream を追加する必要があります。例: ./configure --prefix=/data/apps/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_realip_module --with-http_image_filter_module --with-streamNote 1. mysql はデフォルトでポート 3306 を使用するため、nginx tcp リバース プロキシ mysql を設定するときは、そのポートが mysql がリッスンするポートと同じでないことに注意してください。たとえば、3307 2 を使用します。root ユーザーが mysql たとえばデータベース
まず始めに 今回はNginxのロードバランサー(負荷分散)・エラー時の設定についてまとめました。 ロードバランサー(負荷分散)とは？ Webサイトへのアクセスを振り分ける機械をロードバランサーといいます。 英語の「load（負荷）」＋「Balancer（釣り合いをとるためのもの）」が由来で 負荷分散装置とも呼ばれています。 公開当初はさほどアクセスがないサイトでも、急に人気が出てアクセスが集中することも多いです。 そうした場合に備え、ユーザーからのアクセスをさばくWebサーバを複数台用意しておき、システムの処理能力が不足してきた場合には、サーバの台数を増やして処理性能を維持できるようにしておくのが一般的です。 負荷を分散することで、TAT・TPSなどのパフォーマンスの低下防止や システムダウン時の可用性の向上が得られます。 ※TAT(Turn Around Time:応答時間) ※TPS(
<span class=\"biz-smb-block\"><b>ビジネスに役立つ情報をメールでお届けします（無料） <br>\r\n </b><span class=\"biz-smb-fs-m2\">企業もしくは官公庁など、組織団体に所属している方を対象としています。</span></span></p>\r\n"}}" id="text-5d0a1ee3ec" class="cmp-text"> ビジネスに役立つ情報をメールでお届けします（無料） 企業もしくは官公庁など、組織団体に所属している方を対象としています。
クラウドネイティブ界隈でよく耳にするCNI(Container Network Interface)・L4ロードバランサーのCilium、そしてランタイムセキュリティツールのFalcoでは、eBPF(Extended Berkeley Packet Filter)およびeBPFを活用したXDP(eXpress Data Path)の技術が非常に重要な役割を果たしています。 みんな大好き、『詳解 システム・パフォーマンス』や "BPF Performance Tools" の著者である現IntelのBrendan Gregg ニキは、eBPFとLinuxカーネルの関係はJavaScriptとウェブサイトの関係と同じだと発言しています。 近年、重要度が高まっているeBPF/XDPをワークショップ形式で学べるSECCONのイベントが地元福岡の九州大学で開催されましたので、レポートします。 ワーク
概要 「負荷のためにRailsやDjangoの手前にNginxをいれよう！」という記事が多く存在します。 ただ、僕は以下の疑問を覚えました。 「モダンな構成でnginx本当に必要なのか？] 「あんまわかってないnginx入れてリソース増やして管理コストあげてまで、本当に負荷が下がってくれるのか？」 本記事は、その調査についてのメモとなります。 結論 要件次第だが、CDNやLoadBalancerが入っていれば大概Nginxはなくていい。 昔はNginxが必要だった 「負荷分散」「キャッシュ」「セキュリティ」「SSL/TLSの接続」という観点からNginxが役割を果たしていました。 それぞれの項目における 「問題点」 および 「nginx(リバースプロキシの仕組み)によって解決すること」 を整理しました。 項目 問題点 解決の方法
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes 第97回 インターネット上のロードバランサーの構成調査（パート1） (中井悦司) 2021年1月 はじめに 今回からは、2020年に公開された論文「Classification of load balancing in the Internet(PDF）」を紹介していきます。この中では、ネットワーク経路を調べる伝統的なツールである「traceroute」をロードバランサーを含む経路に対応するための拡張手法が提案されており、さらにこれを用いた実際の調査結果が示されています。 tracerouteの基本的な仕組み はじめに、一般的なtracerouteの仕組みを簡単に説明しておきます。IPネットワークでは、パケットを中継するルーターには、それぞれに個別のIPアドレ
G-gen の杉村です。 Google Cloud (旧称 GCP) の強力なネットワークインフラサービスである External Application Load Balancer (外部アプリケーションロードバランサ) について解説します。 サービスの概要 Cloud Load Balancing とは ロードバランサーの種類 名称変更 External Application Load Balancer とは 3 種類の External Application Load Balancer ユースケース 料金 Cloud Load Balancing の料金体系 計算例 計算条件 計算式 ロードバランサーの選び方 9 種類からの選択 Global vs Regional Global vs Regional の留意点 新型 vs 従来型 External Application Lo
ネットワークロードバランサー (NLB) は、Transport Layer Security (TLS) プロトコルのバージョン 1.3 をサポートするようになりました。これにより、ワークロードを安全に保つのをサポートしながら、バックエンドアプリケーションサーバーのパフォーマンスの最適化を実現できるようになりました。NLB の TLS 1.3 は、TLS トラフィックの暗号化と復号をアプリケーションサーバーからロードバランサーにオフロードすることで機能し、ターゲットに至るまで暗号化を提供します。TLS 1.3 は、1 ラウンドトリップ (1-RTT) TLS ハンドシェイクを使用し、Perfect Forward Secrecy を提供する暗号のみをサポートすることにより、パフォーマンスとセキュリティが最適化されています。他のバージョンの TLS と同様に、NLB は、ロードバランサーで
概要この記事はMakuake Advent Calendar 2021の24日目の記事です。（大遅刻しました・・） ラウンドロビンで負荷分散するロードバランサーをGolangで自作してみるという話です。 ロードバランサーとは何かロードバランサーはリクエストを複数のサーバーへ振り分けて負荷分散する（ロードバランシング）機能を持ったサーバーです。 サービスの可用性を高めてくれるリバースプロキシの一種です。 ロードバランサーの種類は大きく分けて2種類あります。アプリケーション層で負荷分散するL7ロードバランサーと、トランスポート層で負荷分散するL4ロードバランサーです。 ロードバランサーは、ロードバランシングの他、パーシステンス（セッション維持）とヘルスチェックの機能を兼ね備えています。 ロードバランシングの種類負荷分散には静的な方式と動的な方式のものでそれぞれ種類があります。 静的なものの代表
はじめに 本投稿はこちらの投稿の続編にあたります。 ソースや設定ファイルは差分の表記となりますので、ベースとなる成果物についての説明は本投稿においては割愛します。下記を参照願います。 目的 NGINXのロードバランサ機能の概要を理解、および、構築ができるようになる。 背景 参画したシステムではほぼ必ずと言っていいほどロードバランサの構成が取られていたが、インフラ側の構築経験がなかったため、自分で構築を体験してみたかった。NGINXを利用したWebサーバ構築を前回投稿していたため、そのソースコードを活用し知識を得ることができないかと思い、構築、投稿するに至った。 ロードバランサとは 負荷分散をする機能のことを言います。 負荷分散をすることにより以下を得ることができます。 サーバリソース使用率の最適化 スループットの最大化 レイテンシーの低減 耐障害性の向上 NGINXのロードバランサ機能には
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ネットワークロードバランサーが TLS 1.3 のサポートを開始
