大規模LBaaSプロジェクトの成長期に体験した2つの問題
こんにちは、LINEのプライベートクラウドサービスであるVerdaのLoad Balancer as a Service (LBaaS) のチームでTech Leadをしている早川です。このエントリでは私が2019年4月にLINEに入社してからの約2年半で体験した大規模LBaaSならではの興味深い問題をピックアップしてご紹介します。 Verda LBaaSについて VerdaのLBaaSは2016年ごろに稼働を開始したVerdaの中でも比較的歴史が長いサービスです。当時のLINEではハードウェアのアプライアンス製品を用いて提供されていたロードバランサのサービスを置き換える目的で開発されました。特徴としては実際にユーザのトラフィックを受けるいわゆるデータプレーンと呼ばれるコンポーネントも含めて全てがソフトウェアで実装されているということが挙げられます。 中でも個人的に気に入っているのは、L4
さくらのクラウド「エンハンスドLB」を作った話(後編) - Qiita
この記事は さくらインターネット Advent Calendar 2019 5日目の記事です。 さくらインターネット研究所の大久保です。 昨日公開した前編では、弊社のIaaSであるさくらのクラウド上で提供している「エンハンスドロードバランサ」機能について、概要と全体構成の紹介をさせていただきました。 後編となる本稿では、システムを構成する各パーツの詳細について引き続き紹介したいと思います。 VIPフェイルオーバ機能について 今回まずはじめに、DDoS攻撃対策として実装した機能について紹介します。 が、あらかじめ申し上げておきますと、これでどんなDDoSにも完璧に対応できます！ というものではありません 😇 一般的なDDoSミティゲーションの仕組みでは、DPI(Deep Packet Inspection)を用いて攻撃トラフィックのみを抽出破棄し、正常なトラフィックのみを通過させることが行
さくらのクラウド「エンハンスドLB」を作った話(前編) - Qiita
この記事は さくらインターネット Advent Calendar 2019 4日目の記事です。 さくらインターネット研究所に所属している大久保です。お久しぶりです。 自分、研究は全くやってなくて、 ひたすら弊社のIaaSである「さくらのクラウド」の運用、開発、コーディング、お客様サポート、構築、ラックマウント、配線、障害対応、その他あらゆる全てをやっています。よろしくおねがいします 😇 せっかくAdvent Calendar空いてたので、最近作ってるサービスの紹介をさせていただこうと思います。 HTTPSの終端って大変だし面倒じゃないですか。 今回のネタは、お客様からご要望いただいて1年前から開発スタートしたサービスなんですね。当時、L4のロードバランサは提供していましたが、要件として、 インターネット向け大規模コンテンツ配信に使える高性能なもので、 DDoS対策ができて、 SSLの終端
New – TLS Termination for Network Load Balancers | Amazon Web Services
AWS News Blog New – TLS Termination for Network Load Balancers When you access a web site using the HTTPS protocol, a whole lot of interesting work (formally known as an SSL/TLS handshake) happens to create and maintain a secure communication channel. Your client (browser) and the web server work together to negotiate a mutually agreeable cipher, exchange keys, and set up a session key. Once estab
Building and Scaling the Fastly Network, Part 2: Balancing Requests
Building and Scaling the Fastly Network, Part 2: Balancing RequestsOur previous post detailed how Fastly started down the slippery slope of network software. By implementing a distributed routing system on commodity switches, we were able to maintain complete control over how we forward packets at a fraction of the cost imposed by conventional networking wisdom. The return on investment of our sma
LVS-NAT one arm - nyantのブログ
LVS-NATで、real serverをいじらないで済む一本腕な構成を考えて見ました。 CONFIG_IP_VS_NFCT = y なカーネルが必要です。 real serverでは、directorサーバからのアクセスに見えます。 構成 client: 192.168.1.1 director: 172.16.1.2 (VIP: 172.16.1.1) realserver: 10.1.1.1 directorで設定 sysctl echo 1 > /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv4/vs/conntrack vipの設定 ip addr add 172.16.1.1 label eth0:1 dev eth0 arping -U -c 1 -I eth0 172.16.1.1 ipvsadm ipvsad
VPCでアベイラビリティゾーン越しにプライベートIPを共有する（Source/Descチェック外し） - カタヤマンがプログラマチックに今日もコードアシスト
久々のblogです。片山です。 先日@suz_labさんと、ENI出たけどAZは越せませんねー、という話をしていたときに思いついたアイデアを試してみました。 ENIについて 先日発表されたAWSの仮想ネットワークカード機能、Elastic Network Intarface(通称ENI)ですが、プライベートIPはもちろんのこと、セキュリティグループやグローバルIP、さらにMACアドレスまで別のサーバにつけたり外したりできる、かなりイケてる機能です。 EC2インスタンスにENIをひっつけることで、元々持っているeth0と合わせて複数のネットワークカードを持つことが出来るようになるので、マルチホームを実現できます。またあるEC2インスタンスから別のEC2インスタンスへ付け替えできるので、たとえばDBサーバにひっつけたENIに対してWebサーバからアクセスさせておけば、DBが死んだときにも別で立
HTTP/2.0のALPN利用に伴うSSL負荷分散装置の不具合にご注意下さい - ぼちぼち日記
1. はじめに、 ただ今IETF-88@バンクーバーの開催が真っただ中です。スノーデン事件の余波もあり、インターネット技術（特にセキュリティ関連）の議論は熱くなっています。 ちょうど今朝未明（バンクバーでは11/5朝）に HTTP/2.0の標準化を進める httpbis ワーキンググループとセキュリティエリアの合同セッションが開催されました。合同セッションでは、ヘッダ圧縮技術(HPACK)のセキュリティや、HTTP接続(HTTPSではない）で通信の暗号化を行ったらどうか、といった興味深い議論が行われました。このうち将来HTTP/2.0の展開に重要な ALPN(Application Layer Protocol Negotiation) は、このミーティングで最終的な仕様を確定させる段階での議論でした。議論の中で、ALPNの導入によってブラウザから既存の実サービスへの接続に(少なからず)影
ocsp.verisign.net あるいは GSLB の間違った設定 - どさにっき
2013年8月11日(日) ■ 赤岩滝 _ ここ数日の暑さはエアコンなしだとふつーに夜寝ているだけでも熱中症で命の危険を感じる。ので、いつものように週末は涼しいところに避難。奥日光の標高1400mのところまで上がって車中泊していたら、明け方に肌寒さで目が覚めた。とーぜん毛布をかぶって二度寝するわけだが、日が昇って朝8時を過ぎるとだいぶ暑くなるな、やっぱり。 _ 世間はお盆でみんな休んでるので、名のあるところはどこも人がたくさんいるだろうなー、ということで、誰も来そうにないところへ。観光化されていない奥地にある赤岩滝へ。いちおう地図に名前は載ってはいるけど、そこに至る道が記載されていないぐらいマイナーな滝。まあ、地図に道はなくても、現地に行ってみると踏み跡は明瞭だし道標もちゃんとあるんだけどな。 _ 80分ほど歩いて到着。おお、デカい。水量はそんなに多くはないけど、滝壷のすぐ下まで行けるので
Load Balancing in The Cloud | PDF | Web Server | Internet & Web
Load Balancing is a method to distribute workload across one or more servers, network interfaces, hard drives, or other computing resources. Typical datacenter implementations rely on large, powerful (and expensive) computing hardware and network infrastructure, which are subject to the usual risks associated with any physical device, including hardware failure, power and/or network interruptions,
『ネットワーク基盤の変遷の歴史』
こんにちは。アメーバのネットワークアーキテクト、責任者のいづるです。 本当は子育てについて書きたいのですが、何でもお見通しのM.S氏から 「育児の話題は禁止だから」 と、前もって眉間に釘を刺されたので、渋々、子供と嫁とロックと哲学と青い空と広い海の次に好きな、ネットワークの話でも書いてみようと思います。 とは言え、ネットワーク機器のような、比較的単純なパターンマッチングの処理をひたすら高速にぶん回す世界では、CPUの処理速度が飛躍的に高まった現在でも、まだまだASICやFPGAなどのハードコーディングされたチップ処理が主流でございまして、、、つまるところ、ちょっと足を深く踏み入れた濃ゆいところはNDAベースのやりとりになったり、セキュリティ的に開示できなかったりと、本当に面白いところは大人として書けなかったりもします。 そんなわけで、何を書こうか悩んだ結果、アメーバというサービスを支える、
『大規模サービスを支える仮想ネットワーク』
エンジニアブログをご覧の皆さんこんにちは、インフラエンジニアのすとーです。 僕はインフラの中でもネットワークチームで長らく働いてきたため、 今回はAmebaのネットワークまわりのお話をさせていただこうかと思います。 そこで、「ネットワーク基盤の変遷の歴史」を一歩踏み込んで、 その時々でポイントになった(と思っている)技術を、簡単な設定例と共に紹介していきます。 前提として、弊社ではルーティングはスタティックに行っており、 機器についてはCiscoとH3Cを7:3の割合ぐらいで利用しています。(ざっくり) 其の一 「VRF」 VRF(Virtual Routing and Forwarding)とは、ひとつのルータ内で仮想的に 複数のルーター(ルーティングテーブル)を作れる機能です。(ざっくり) 主な目的は、初期アメーバの余剰なネットワークリソースを、 マルチレイヤスイッチの導入で解消すると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.kernel.org/doc/Documentation/networking/ipvs-sysctl.txt
mruby を用いた Linux ロードバランサインタフェースの実装
GCP を支えるロードバランサの設計を公開
Path MTU discovery in practice
IPVS: Allow boot time change of hash size
GitHub - blblack/gdnsd: Authoritative DNS Server --
Relayd: a load balancer for OpenBSD
Direct Server Return support in OpenBSD