Logicadの秒間16万リクエストをさばく広告入札システムにおける、gRPCの活用事例

ULS Powered by
Copyright © 2011-2018 UL Systems, Inc. All rights reserved.
Proprietary & Confidential
Logicadの秒間16万リクエストを処理する
リアルタイム広告配信における、gRPCの活用事例
2018/5/26
ウルシステムズ株式会社
http://www.ulsystems.co.jp
mailto:info@ulsystems.co.jp
Tel: 03-6220-1420 Fax: 03-6220-1402
#jjug_ccc #ccc_a7

ULS
Proprietary & Confidential Powered by 1
#jjug_ccc #ccc_a7
1. 自己紹介
2. Logicadについて
3. 今回のシステムと業界
4. 今回のシステムのアーキテクチャと背景
5. gRPCと他の選定候補
6. gRPCのよいところ
7. gRPCを実際に適用してみた結果
8. まとめ
9. QA
アジェンダ

ULS
#jjug_ccc #ccc_a7自己紹介
磯田　浩靖
● 所属：ウルシステムズ株式会社
● 連絡先：hironobu.isoda@ulsystems.co.jp
● twitter：hiroisojp
● 最近の活動：スクラムマスター的な活動
吉井　弘明
● 所属：ウルシステムズ株式会社
● 連絡先：hiroaki.yoshii@ulsystems.co.jp
● 興味：スクラム、機械学習とか

ULS
#jjug_ccc #ccc_a7Logicadについて
● お客様
– ソネット・メディア・ネットワークス株式会社
● 主な事業内容
– DSP事業
● Logicad を提供
● RTBを活用した広告配信最適化
● 機械学習・人工知能を活用したDMPによる広告配信精度の向上
● プロジェクト支援概要
– DSP/RTBシステム開発支援
– VALIS-Engine（機械学習・人工知能）開発支援

ULS
#jjug_ccc #ccc_a7
1. 自己紹介
8. まとめ
9. QA

ULS
#jjug_ccc #ccc_a7
● 広告配信はオークション形式で実施
RTB（リアルタイムビッディング）の概要
AD
WebサイトA に、XYZさんが来ました。
誰か広告を出したい方いませんか？
Webサイト
SSP
事業者
DSP3
DSP2
DSP１
3円
2円
1円
ID=XYZ
訪問通知
入札リクエスト
&レスポンス
本日お話する
のはココ

ULS
#jjug_ccc #ccc_a7
● 入札に勝つと広告を表示する権利を得ることができる
● 表示された広告に応じて売上が発生するビジネスモデル
RTB（リアルタイムビッディング）の概要
AD
Webサイト
SSP
事業者
DSP3
DSP2
DSP１
3円
2円
1円
ID=XYZ
訪問通知
①広告配信
　リクエスト
本日お話する
のはココ
WIN
②広告配信レスポンス
③Webサイトに
　広告表示用の
　URLを設定

ULS
#jjug_ccc #ccc_a7
● タイムアウトが発生するとオークションに参加できない
性能要求を満たせないと会社の存続に関わる
AD
Webサイト
SSP
事業者
DSP3
DSP2
DSP１
3円
2円
1円
ID=XYZ
訪問通知
入札リクエスト
&レスポンス
本日お話する
のはココ
タイムアウトが発生すると
他のDSPに権利をもっていかれて、
ビジネスとして成り立たない！

ULS
#jjug_ccc #ccc_a7
スループット向上
単位時間あたりの処理能力を高めて、
よりたくさん捌く
レイテンシの低減
要求〜結果が返ってくるまでの時間
をできるだけ短くする
Client Server
1回あたりの処理が
高速であること
同時にたくさん
捌くことができること
悩める性能要求
Client ServerClientClient
タイムアウトを減らして売上を確保するためには・・・

ULS
#jjug_ccc #ccc_a7
ネットワークレイテンシ
● ネットワークレイテンシ
● 入札処理のレイテンシ
– 最適な広告を選択する処理
オークションに関わるレイテンシ
入札処理のレイテンシ
SSP
事業者
DSP
最大 100ミリ秒

ULS
#jjug_ccc #ccc_a7ネットワークレイテンシ
● ネットワークレイテンシは一定ではない
65ミリ 100ミリ
ココから先は
タイムアウトになって
しまう
通信相手往復時間
東京～東京約1～2ミリ秒
東京～台湾約65ミリ秒

ULS
#jjug_ccc #ccc_a7オークションのレイテンシ
● 入札処理が加わるとさらにタイムアウトは増える
65ミリ 100ミリ
入札処理が加わって
タイムアウトになった分

ULS
#jjug_ccc #ccc_a7入札処理のレイテンシは平均3ミリ秒！
● Logicadの入札処理は平均3ミリ秒！
– レイテンシを短くできればタイムアウトが減らせる
– 売上につながる
65ミリ 100ミリ
入札処理を短くすることが
できればもっとタイムアウトが
減らせる

ULS
#jjug_ccc #ccc_a7
1. 自己紹介
8. まとめ
9. QA

ULS
#jjug_ccc #ccc_a7
・ユーザ情報
・広告予算消化情報
リアルタイムに扱う情報を格納
広告商品情報・・・
　画像URL 、サイズ、LPなど
レイテンシのためローカルに情報を保持
入札サーバ
Java8
Logicadのアーキテクチャ簡略図
SSP
nginx
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
X
X
X
X
・広告キャンペーン情報
事前定義、定期的にロードする
必要がある情報を格納
・アドフラウド情報
3rd Partyから提供された
情報を格納
Aerospike
(KVS)
AWS RDS
Redis
今回これらは
話のスコープ外
広告商品
情報

ULS
#jjug_ccc #ccc_a7
入札サーバ
Java8
gRPC採用前のLogicadにおけるアーキテクチャの課題
SSP
nginx
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
X
X
X
X
広告商品情報
レイテンシ・データモデルの都合上、
全サーバに同一広告商品情報を持つ
データ量が増→スケールアップが必要
ディスク拡張で乗り切る
システムの成長に伴って、広告商品情報の
一部が億オーダーの商品数となり、
各サーバで保持できるサイズを超える入札サーバ

ULS
#jjug_ccc #ccc_a7
・ユーザ情報
広告商品情報サーバ
入札サーバ
Java8
To-Be
SSP
nginx
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
X
X
X
X
情報を格納
Aerospike
(KVS)
RDS
Redis
現状のレイテンシ&
スループットの維持が必須
外部化が必須
広告商品
情報
広告商品
情報

ULS
#jjug_ccc #ccc_a7
1. 広告商品情報サーバ接続処理による遅延がないこと
To-Be を実現する上での要件
広告商品情報
サーバ
入札サーバ
1. コネクション増加による処理数低下が起きないこと
2. ロードバランシングできること
ココの遅延
広告商品情報
サーバ
入札サーバ
ココの処理数

ULS
#jjug_ccc #ccc_a7
・ユーザ情報
Java8
gRPC-Java
入札サーバ
Java8
gRPC-Java
gRPC採用後のLogicadのアーキテクチャ簡略図
SSP
nginx
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
X
X
X
X
情報を格納
Aerospike
(KVS)
RDS
Redis
今回はココを
gRPCで構築
広告商品
情報

ULS
#jjug_ccc #ccc_a7
1. 自己紹介
8. まとめ
9. QA

ULS
#jjug_ccc #ccc_a7
# ソリューションレイテンシスループット検討結果
1
シングルスレッドで動作
するため、
スループットに影響あり
2
データがシャーディング
されており、
分散しているとレイテンシに
影響あり
3
後述
● 選定の候補
gRPCの選定
+ ローカルDB

ULS
#jjug_ccc #ccc_a7
● スループットの観点で不採用
– シングルスレッドで動作し複数の処理を並列で処理できない
Redisを採用しなかった理由
入札サーバ
入札サーバ
入札サーバ Command 1Command 2Command 3
1スレッドで順番に処理
= ブロッキングされて、スループットに影響

ULS
#jjug_ccc #ccc_a7
● レイテンシの観点で不採用
– データがシャーディングされているため複数回の通信が発生してしまう
Aerospikeを採用しなかった理由
入札サーバ
id=5,120,200 の
広告商品情報を取得する
Aerospike Cluster
Cluster1
id:1~99 の
データを格納
Cluster2
id:100~199 の
データを格納
Cluster3
id:200~299 の
データを格納
id=5
を取得 id=120
を取得
id=200
を取得
3回通信が必要

ULS
#jjug_ccc #ccc_a7
そこでgRPC
サーバ間通信で広告商品情報を
高速かつ同時に多数処理できる何かが必要！

ULS
#jjug_ccc #ccc_a7
● gRPC = Googleが開発した高速なRPCフレームワーク
– HTTP/2, Protocol Buffersを用いて高速化
● 採用事例
– Google, Netflix, Docker, Cisco etc
gRPCとは？

ULS
#jjug_ccc #ccc_a7
1. 自己紹介
8. まとめ
9. QA

ULS
#jjug_ccc #ccc_a7
● HTTP/2
– バイナリフレーム
– ヘッダー圧縮
– 非 SSL
● Protocol Buffers
– データ圧縮
gRPCのよいところ
● HTTP/2
– 多重化
（マルチプレキシング）
● クライアントサイド
ロードバランシング
レイテンシの低減スループット向上

ULS
#jjug_ccc #ccc_a7
● HTTP/2
– 非 SSL
– データ圧縮
● HTTP/2
– 多重化

ULS
#jjug_ccc #ccc_a7
● バイナリフレームによる効率化で高速な通信ができる
– 受信側のTCPソケットのバッファをすばやく空にでき、
次のデータを高速にリクエストできる
– バイナリなのでヘッダーのデータサイズが小さい
レイテンシの低減：HTTP/2 バイナリフレーム
Network(IP)
Transport(TCP)
Session(TLS)[Optional]
POST: /upload
HTTP/1.1
Host: www.example.com
Content-Type: application/json
Content-Length:27
{“msg”: “Welcom to JJUG!”}
Application(HTTP/2)
Binary Framing
HEADERS Frame
DATA Frame
HTTP/1.1
HTTP/2
ヘッダーとボディはそ
れぞれフレームとして
扱われる

ULS
#jjug_ccc #ccc_a7
● ヘッダーをインデックス化（辞書化）することで、データ
サイズが小さくなる
レイテンシの低減：HTTP/2 ヘッダー圧縮
:method GET
:scheme https
:host example.com
:path /new_resource
accept image/jpeg
user-agent Mozilla/...
Req #1 Req #2
:method GET
:scheme https
:host example.com
:path /resource
accept image/jpeg

ULS
#jjug_ccc #ccc_a7
インデックス化後イメージ
index header value
2 :method GET
3 :method POST
7 :scheme https
・・・・・・・・
静的テーブル
頻出するものは事前
にインデックス化
されている
:method: GET
:scheme: https
:host: example.com
:path: /resource
accept: image/jpeg
user-agent: Mozilla/...
2
7
:host: example.com
:path: /resource
accept: image/jpeg
インデックス化前イメージ
Req #1
:method GET
:scheme https
:host example.com
:path /resource
accept image/jpeg

ULS
#jjug_ccc #ccc_a7
動的テーブル
index header value
62 :host example.com
63 accept image/jpeg
64 user-agent Mozilla/...
index header value
2 :method GET
3 :method POST
7 :scheme https
・・・・・・・・
静的テーブル
インデックス化後イメージ
:method: GET
:scheme: https
:host: example.com
:path: /resource
accept: image/jpeg
2
7
62
:path: /new_resource
63
64
インデックス化前イメージ
:method GET
:scheme https
:host example.com
:path /new_resource
accept image/jpeg
Req #2
Req#1での既出分が
インデックス化され、
次のReqでは
インデックス値を送信

ULS
#jjug_ccc #ccc_a7
● h2c を用いることでより一層の高速化が可能
– h2c = HTTP/2 over TCP = 平文による TLS を使わない通信
– 内部ネットワークのみであれば TLS を使わない通信を採用できる
– TLS のオーバーヘッドを削除できるため高速
レイテンシの低減：HTTP/2 非SSL
gRPC
Client
gRPC
Server
h2c(cleartext) request
response(s)
証明書のやりとり
暗号化・復号化に関わる
処理がないので高速

ULS
#jjug_ccc #ccc_a7
● gRPC-javaの場合、利用時にusePlainTextメソッドを
呼び出すだけでOK
レイテンシの低減：HTTP/2 非SSL
ManagedChannel channel = ManagedChannelBuilder
.forAddress(host, port)
.usePlainText(true)
.build();
GreeterBlockingStub blockingStub = GreeterGrpc.newBlockingStub(channel);
HelloRequest request = HelloRequest.newBuilder().setName(name).build();
HelloReply response = blockingStub.sayHello(request);

ULS
#jjug_ccc #ccc_a7
● HTTP/2
– 多重化
● HTTP/2
– 非 SSL
– データ圧縮

ULS
#jjug_ccc #ccc_a7
● 1つのTCPコネクションで数万接続でも並列化が可能
– TCPコネクション中でストリームを用いて並列化
– ストリームはTCPのようなハンドシェイクが不要であるため、オーバーヘッドを
削減することが可能
スループット向上：HTTP/2 マルチプレキシング
Client Server
stream 3
HEADERS
stream 3
DATA
stream 1
DATA
・・・
stream 5
DATA
stream idでデータを
見分けることができる
途中に別のstreamが
挟まってもOK
stream 1
DATA

ULS
#jjug_ccc #ccc_a7
● HTTP/2では並列処理でブロックされない
– stream idで見分けることができ、順序の意識が不要になる
前の処理が
完了しないと次
の処理を
行えない
スループット向上：HTTP/2 マルチプレキシング
HTTP/2
Client Server
HTTP/1.1 パイプライン
順番に処理する必要
があるため、
ブロッキングされる
ブロックされずに
処理できる
Client Server

ULS
#jjug_ccc #ccc_a7
● HTTP/2
– 非 SSL
– データ圧縮
● HTTP/2
– 多重化

ULS
#jjug_ccc #ccc_a7
– Google 社製のシリアライザ
– IDLにより、言語に応じたメッセージオブジェクトが自動生成でき
– gRPC ではデフォルトで Protocol Buffers が使用できる
Protocol Buffers
message ProductMastersRequest {
int64 product_group_id = 1;
int32 product1_quantity_at_most = 2;
repeated int64 product1_ids = 3;
}
IDL

ULS
#jjug_ccc #ccc_a7
● データ圧縮効率が高い
– フィールド名をデータとして持たずに tag を使う
– 文字列より数値型を扱うように設計した方がより圧縮率が高まる
レイテンシの低減：Protocol Buffers データ圧縮効率
シリアライズ前
シリアライズ後
product_group_id = 1122
product1_quantity_at_most = 3
product1_ids = 103,999,101
product2_quantity_at_most = 4
product2_ids = 106,105,998,104
「72byte + フィールド名」のデータを
17 byte に圧縮
tag ≒ index
message ProductMastersRequest {
int64 product_group_id = 1;
}
IDL

ULS
#jjug_ccc #ccc_a7
● HTTP/2
– 非 SSL
– データ圧縮
● HTTP/2
– 多重化

ULS
#jjug_ccc #ccc_a7
gRPC Client
● ロードバランシングの設定が容易
– 動的なgRPC サーバの追加・削除が容易
– DNSレコードを削除したサーバに自動的にリクエストが送られなくなる
– nginx など外部のロードバランサが不要で管理が楽
スループット向上：クライアントロードバランシング
Name Resolver
(DNS)
gRPC Client grpclb policy
gRPC Server gRPC Server gRPC Server
Load
Balancer
今回はここを拡張して、
動的なgRPCサーバの
追加に対応

ULS
#jjug_ccc #ccc_a7
● 現状のgRPC-java単独の仕組みでは動的なgRPCサーバの増減に対してうまく
機能しない
● 独自の仕組みや、他のロードバランシング機能を提供するライブラリとの組み合わ
せも考慮されているが、 Logicad では使われていないため不採用
1. grpc-eureka-java
2. grpc-consul
3. grpc-zookeeper
（注：これらはサードパーティのOSSです）
● 今回は定期的にサーバリストを更新する
NameResolverを作成して対応した
Tips：クライアントロードバランシング
RefreshableNameResolverProvider
nameResolverProvider = ...
ManagedChannel channel =
ManagedChannelBuilder
.forAddress(host, port)
.usePlainText(true)
.nameResolverFactory(nameResolverProvider)
.loadBalancerFactory(
RoundRobinLoadBalancerFactory
.getInstance()
)
.build();

ULS
#jjug_ccc #ccc_a7
import io.grpc.Attributes;
import io.grpc.NameResolver;
import io.grpc.NameResolverProvider;
import io.grpc.internal.DnsNameResolverProvider;
@Singleton
public class RefreshableNameResolverProvider extends
NameResolverProvider {
private static final int _priority = 5;
private final DnsNameResolverProvider _delegate =
new DnsNameResolverProvider();
private final MutableList<NameResolver> _resolvers = Lists.mutable.of();
@Override
public NameResolver newNameResolver(
final URI targetUri, final Attributes params) {
final NameResolver r = _delegate.newNameResolver(targetUri, params);
if (r != null) {
_resolvers.add(r);
}
return r;
}
● サーバリストを更新するNameResolverのサンプル
Tips：クライアントロードバランシング
@Override
public String getDefaultScheme() {
return _delegate.getDefaultScheme();
}
@Override
protected boolean isAvailable() {
return true;
}
@Override
protected int priority() {
return _priority;
}
public void refresh() {
for (final NameResolver r : _resolvers) {
r.refresh();
}
}
}
①複数のgRPCサーバ
の接続情報を登録
②API or 定期実行で
サーバリストを更新

ULS
#jjug_ccc #ccc_a7
1. 自己紹介
8. まとめ
9. QA

ULS
#jjug_ccc #ccc_a7
To-Be を実現する上での要件
広告商品情報
サーバ
入札サーバ
ココの遅延
広告商品情報
サーバ
入札サーバ
ココの処理数
再掲

ULS
#jjug_ccc #ccc_a7
● HTTP/2 による並列化
● クライアントサイドロードバランシング
To-Be を実現する上での要件は達成できそうか？
● HTTP/2 による高速な通信
● Protocol Buffers によるデータ圧縮

ULS
#jjug_ccc #ccc_a7
● 1. 広告配信サーバのストレステスト
– 最大のスループット、Connection数の変化を測定
● 2. 負荷試験環境でのレイテンシ、スループットの測定
– 入札の一連の処理に関するレイテンシ、スループットを測定
ベンチマーク
ストレステスト
負荷試験環境での
レイテンシ、スループット測定

ULS
#jjug_ccc #ccc_a7
● gRPCでもJMeterを用いて負荷をかけることが可能
● JavaSamplerClientを実装したクラスを用意して任意のプロトコルをリ
クエストすることが可能
@Override
public SampleResult runTest(final JavaSamplerContext context) {
HelloRequest request = HelloRequest.newBuilder()
.setName(context.getParameter("param_name"))
.build();
final SampleResult result = new SampleResult();
result.setDataEncoding(StandardCharsets.UTF_8.toString());
result.setDataType(SampleResult.BINARY);
result.setSamplerData(StringUtils.EMPTY);
result.sampleStart();
client.sayHello(request);
result.sampleEnd();
result.setSuccessful(true);
result.setResponseCodeOK();
result.setResponseData(StringUtils.EMPTY,StandardCharsets.UTF_8.toString());
return result;
}
Tips：ストレステスト時の負荷のかけ方
public class GrpcHelloSampler extends AbstractJavaSamplerClient {
private GreeterBlockingStub client;
@Override
public void setupTest(final JavaSamplerContext context) {
super.setupTest(context);
JMeterVariables variables = JMeterContextService.getContext().getVariables();
String host = variables.get("grpc_host");
int port = Integer.parseInt(variables.get("grpc_port"));
GreeterBlockingStub stub = getClient(host, port);
this.client = stub;
}
①setupTestでgRPC
クライアントのインスタン
スを生成
②runTestでgRPC
クライアントを呼び出
して処理するだけ

ULS
#jjug_ccc #ccc_a7
● 環境
– サーバ
● 広告配信サーバ x 1台
– Java8
– メモリ128GB
– 8core/16thread
– NW
● 10GbE
● 扱う広告商品情報
– 件数：1億件
– サイズ：1.6TB
ベンチマーク（ストレステスト）

ULS
#jjug_ccc #ccc_a7
● スループット
– 比較的軽い処理の場合、秒間7万件程度
– データ量に応じて処理件数は変わるが秒間数万件の問題なく処理できる
30商品
高負荷
レアなデータ量
3商品
低負荷
ややありうる
データ量
秒間の処理件数
(10k=秒間1万件)
15商品
中負荷
通常のデータ量

ULS
#jjug_ccc #ccc_a7
● Connection
– データ量、スループットに関係なくConnection数は一定
– HTTP/2のマルチプレキシングにより少ないTCPコネクションで処理できる
Connection数は
スループットに比例せず一定

ULS
#jjug_ccc #ccc_a7
● 負荷試験環境
– サーバ
● 入札サーバ
– Java8
– メモリ30GB
– 14core/28thread x 2cpu
● 広告配信サーバ
– Java8
– メモリ128GB
– 8core/16thread
– NW
● 10GbE
● 扱う広告商品情報
– 件数：1億件
– サイズ：1.6TB
ベンチマーク（レイテンシ、スループット）

ULS
#jjug_ccc #ccc_a7
● gRPC対応前後で、レイテンシ・スループットは全体の僅か
1割程度の変化に収まった
○ gRPC 化前：広告商品情報を入札サーバに持たせた状態
○ gRPC 化後：入札サーバから広告商品情報サーバに外部化した状態
ベンチマーク（レイテンシ、スループット）
# 計測対象レイテンシ(ミリ秒) スループット(秒間処理件数)
平均 50perc
entile
99perc
entile
1分間
平均
5分間
平均
15分間
平均
1 gRPC 化前 2.04 1.84 9.47 3,732 3,201 2,382
2 gRPC 化後 2.14 1.83 6.79 3,345 3,463 3,501

ULS
#jjug_ccc #ccc_a7
1. 自己紹介
8. まとめ
9. QA

ULS
#jjug_ccc #ccc_a7
・ユーザ情報
Java8
gRPC-Java
入札サーバ
Java8
gRPC-Java
まとめ
SSP
nginx
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
X
X
X
X
情報を格納
Aerospike
(KVS)
RDS
Redis
今回はここをgRPCで構築
ローカル処理を外部化しても
0.1ミリ秒の遅延に収まった
広告商品
情報

ULS
#jjug_ccc #ccc_a7まとめ
● 億オーダーの商品情報を gRPC で扱っても
簡単に導入でき、なおかつ速い
● 性能要求の高いシステムでも gRPC おすすめ
# gRPC の特徴導入結果
1 HTTP/2 : 高速な通信数万のスループットでも同時に並列処理を実現
レイテンシの悪化によるタイムアウトはほぼ無し
レイテンシ・スループットのビジネス要求を達成
2 Protocol Buffers :
効率的なシリアライズ
3 ロードバランシング簡単な拡張で動的なロードバランシングを実現

ULS
#jjug_ccc #ccc_a7
お問い合わせ先
mailto: info@ulsystems.co.jp
https://www.ulsystems.co.jp/

Logicadの秒間16万リクエストをさばく広告入札システムにおける、gRPCの活用事例

Recommended

More Related Content

What's hot (20)

Similar to Logicadの秒間16万リクエストをさばく広告入札システムにおける、gRPCの活用事例 (20)

Logicadの秒間16万リクエストをさばく広告入札システムにおける、gRPCの活用事例