先進技術調査グループのリサーチエンジニアの酒井 (@neko_suki)です。 先進技術調査グループでは、新しいトランスポートプロトコルのQUICの製品への適用を検討しています。今回の記事では、自社が主に扱う高頻度なデータの伝送における課題のひとつをQUICを適用したらどうなるかを評価してみました。 目次は以下の通りです。 QUICとは Head of Line (HoL) Blocking とは 実験内容 実験結果 まとめ 参考文献 QUICとは QUICとは、Googleが提案・実装をし、現在IETFで標準化が行われているプロトコルです。(区別のため、前者はgQUIC、後者はiQUICと呼ばれています)。2020年の中頃にはRFCが発行される予定です。 QUICはUDPベースの信頼性のある接続を提供するトランスポートプロトコルです。QUICではコネクション上に仮想的なストリームを生成し

Robin Marx氏の論文「Resource Multiplexing and Prioritization in HTTP/2 over TCP and HTTP/3 over QUIC 」の1章を読んだメモ。 https://h3.edm.uhasselt.be/ からダウンロードできます。いずれちゃんと読んでqiitaにまとめたい。 Introductionでは、HTTP/1.1の時代の課題から、HTTP/2が出てきた背景、HTTP/2の課題、QUIC/HTTP3が出てきた経緯、などが紹介されていました。歴史的な経緯を知るのにはいいのかも？ HTTPは、ここ数年で2015年のHTTP/2の標準化からほぼ最終段階にあるHTTP/3の標準化まで劇的な変化を5年の間に経験している 標準化が進んだ背景にはパフォーマンスとセキュリティがある。この論文ではパフォーマンスの問題に着眼する。 HT

日本からのイベント参加者に女性が少ない！ OpenStack SummitやKubeConなど、国際的なイベントを取材すると、さまざまな国の多くのエンジニアが性別、年齢を問わず活発に活動をしていることを感じる。それはセッションのスピーカーだけでなく、参加者も同様に多様であることから見てとれる。 しかし今年の春にデンバーで行われたOpen Infrastructure Summitの際に、日本からの参加者が集って夕食を取った時にふと周りを見回すと、日本人男性だけの集団であったことに軽い衝撃を覚えた。つまり日本からデンバーのカンファレンスに参加し、有志として夕食に参加していた方は全員男性だったのだ。これは昨今、多くの参加者を集めて急成長中のKubeConでもほぼ同様で、日本から参加した女性エンジニアの数は両手にも満たなかったのではないか。 他方、国内で開催されるデータサイエンティストやWebの

blog.litespeedtech.com LiteSpeedのLiteSpeed Web Server 5.4.2、Web ADC 2.6.0、OpenLiteSpeed 1.6.1でQUICの接続にBBRを使うようになったらしいです。 BBRは、Googleが開発した、Bottleneck Bandwidth and RTTという新しい輻輳制御のアルゴリズムです。BBRの解説は、こちら で読むことができます。ちなみに、BBRv2 もgoogleによって開発が進んでいるようです。 LiteSpeedの記事は、BBRの特徴、欠点、特徴を確認するためのテストを行った結果などが書かれている記事です。 特徴は、輻輳に起因しないロスに反応しにくいことと、レイテンシーが小さいことの2つです。 欠点は、shallow bufferの時に性能が低い点と、他のフローに対して公平ではない点が挙げられていま

Intro 依存コンテンツを 1 つにまとめて配信する WebBundle の仕様策定と実装が進んでいる。 これは Signed HTTP Exchange と合わせて WebPackaging を実現するための仕様であり、組み合わせれば WebBundle に対して署名することでコンテンツの配信を通信と分けて考えることができる。 Signed HTTP Exchange に比べると格段に簡単な仕様なので、現状のフォーマットと挙動について解説する。 draft-yasskin-wpack-bundled-exchanges-latest WebBundle かつて Bundled HTTP Exchanges と呼ばれていた仕様であり、複数のコンテンツを 1 つにまとめ、配信することができる。 例えば index.html とそれが依存する css/js/favicon etc を 1 つ

Load Balancers plays a key role in Web Architecture. They allow distributing load among a set of backends. This makes services more scalable. Also since there are multiple backends configured the service become highly available as load balancer can pick up a working server in case of a failure. After playing with professional Load Balancers like NGINX I tried creating a simple Load Balancer for fu

リクエストに対してx-cacheレスポンスヘッダでキャッシュにhitしたか示すCDNベンダーもあります。 しかし、このx-cacheヘッダは各ベンダー独自のもので標準化されていませんでした。 そこでCache-Statusというヘッダをちゃんと定義する「The Cache-Status HTTP Response Header」という仕様がFastlyのMark Nottingham氏から出ています。 以前まではcacheヘッダという名前でしたが、draft 01ではCache-Statusヘッダと改称されました。それにあわせてヘッダ値もリファクタされています。 前の仕様は以前書いた通りです。 asnokaze.hatenablog.com Cache-Statusヘッダ Cache-Statusは以下のようになります。「Structured Headers for HTTP」の定義に従っ

Fastlyの「Binary Structured HTTP Headers」という提案仕様がでています。 目次 概要 BINHEADERSフレーム Binary Literal Representation Lists Dictionaries Items String Literals Item Payload Types Aliased Fields 概要 HTTPヘッダはテキストで表現されます。特に値に関して数値、日付やブーリアン値もテキストで表現されます。また、Accept-Encodingのようにリスト構造を持つヘッダ値もあります。 本来バイナリで表現できるデータ形式や構造をテキストで表現するのは、データ量が増えるほかパースコストがかかります。 そこで、Structured Headersの定義に基づいて、HTTPヘッダ値を直接バイナリで表現できるようにするのが「Binary

.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads 71 Ads API 11

facebookのHTTP Library proxygen がQUICとHTTP/3に対応しているらしいので動かしてみました。 github.com Note that currently this project has been tested on Ubuntu 18.04 and Mac OSX although it likely works on many other platforms. ubuntu16.04 でやると、ビルドスクリプト内部でapt-get してくるライブラリのバージョンに問題があるのでやめたほうがいいです。 ビルド方法 cd proxygen ./build.sh --with-quic サーバ側サンプル実行方法 _build/proxygen/httpserver/hq --qlogger_path /tmp/logs/ クライアント側サンプル実行方法

2020/060/01 追記 nginx公式版が提供されました。こちらを御覧ください asnokaze.hatenablog.com NginxをHTTP/3対応させるパッチがCloudflareから提供されました (CloudflareのHTTP/3ライブラリ Quicheを利用しています。現状ではHTTP/3ドラフト23版の対応になります) github.com 基本的に、書いてるとおりにやればビルドできるのですが、無事HTTP/3しゃべるところまで確認できました ビルド rustインストールしておく $ curl https://sh.rustup.rs -sSf | sh $ source $HOME/.cargo/env書いてあるとおり $ curl -O https://nginx.org/download/nginx-1.16.1.tar.gz $ tar xzvf ngin

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

こんにちは。SRE の近藤（@chaspy）です。 先日、より高い信頼性でサービスを提供するために、スタディサプリ小中高大のサービスの最後の砦であるデータベース、MongoDB のインスタンスクラスのスケールアップを行いました。また、スケールアップをするにあたり、負荷試験を行いました。 本記事では、データベースインスタンスのスケールアップの際に行なった負荷試験に対する考え方と、得た学びを紹介します。 なぜスケールアップするのか サービスの急成長に伴い、アクセス数もデータ量も増加しています。数年前に「しばらくは大丈夫」と判断できるインスタンスクラスにスケールアップをしたデータベースも、高負荷時には性能が劣化してしまう問題に遭遇しました。 私たちの MongoDB は AWS 上に EC2 インスタンスとしてセルフホストしており、MongoDB Cloud Manager を使って運用の一部を

「Of the Utmost Importance: Resource Prioritization in HTTP/3 over QUIC」を読みましたHTTP3 Of the Utmost Importance: Resource Prioritization in HTTP/3 over QUIC という論文が公開されていたので読んでみました。 HTTP/3の優先度制御について、11個の異なる方法を比較検討しています。ウェブページのロードの実験を複数のサイトのデータを使って行い、その実験結果から利点欠点と今後の標準化への提案を行っています。 評価結果から、優先度制御の方法はシーケンシャルな方法のほうがラウンドロビンの方法より優れているということがいえます。また、すべての場合に速い方法はないので、複数の実装が許容されているほうが良いようです。そして、サーバ側はウェブページのロードを早く

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.