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

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:[email protected] Tel: 03-6220-1420 Fax: 03-6220-1402 #jjug_ccc #ccc_a7

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

Proprietary & Confidential Powered by 2 #jjug_ccc #ccc_a7 自己紹介磯田　浩靖 • 所属：ウルシステムズ株式会社 • 連絡先：[email protected] • twitter：hiroisojp • 最近の活動：スクラムマスター的な活動吉井　弘明 • 所属：ウルシステムズ株式会社 • 連絡先：[email protected] • 興味：スクラム、機械学習とか

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

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

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

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

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

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

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

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

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

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

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

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

Proprietary & Confidential Powered by 16 #jjug_ccc #ccc_a7 ・ユーザ情報・広告予算消化情報リアルタイムに扱う情報を格納広告商品情報サーバ入札サーバ Java8 To-Be SSP nginx 入札サーバ入札サーバ入札サーバ入札サーバ入札サーバ入札サーバ X X X X ・広告キャンペーン情報事前定義、定期的にロードする必要がある情報を格納・アドフラウド情報 3rd Partyから提供された情報を格納 Aerospike (KVS) RDS Redis 現状のレイテンシ& スループットの維持が必須外部化が必須広告商品情報広告商品情報

Proprietary & Confidential Powered by 17 #jjug_ccc #ccc_a7 レイテンシの低減 1. 広告商品情報サーバ接続処理による遅延がないこと To-Be を実現する上での要件広告商品情報サーバ入札サーバスループット向上 1. コネクション増加による処理数低下が起きないこと 2. ロードバランシングできることココの遅延広告商品情報サーバ入札サーバココの処理数

Proprietary & Confidential Powered by 18 #jjug_ccc #ccc_a7 ・ユーザ情報・広告予算消化情報リアルタイムに扱う情報を格納広告商品情報サーバ Java8 gRPC-Java 入札サーバ Java8 gRPC-Java gRPC採用後のLogicadのアーキテクチャ簡略図 SSP nginx 入札サーバ入札サーバ入札サーバ入札サーバ入札サーバ入札サーバ X X X X ・広告キャンペーン情報事前定義、定期的にロードする必要がある情報を格納・アドフラウド情報 3rd Partyから提供された情報を格納 Aerospike (KVS) RDS Redis 今回はココを gRPCで構築広告商品情報

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

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

Proprietary & Confidential Powered by 22 #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回通信が必要

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

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

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

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

Proprietary & Confidential Powered by 28 #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 ヘッダーとボディはそれぞれフレームとして扱われる

Proprietary & Confidential Powered by 29 #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 user-agent Mozilla/...

Proprietary & Confidential Powered by 30 #jjug_ccc #ccc_a7 インデックス化後イメージ • ヘッダーをインデックス化（辞書化）することで、データサイズが小さくなるレイテンシの低減：HTTP/2 ヘッダー圧縮 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 user-agent: Mozilla/... インデックス化前イメージ Req #1 :method GET :scheme https :host example.com :path /resource accept image/jpeg user-agent Mozilla/...

Proprietary & Confidential Powered by 31 #jjug_ccc #ccc_a7 動的テーブル • ヘッダーをインデックス化（辞書化）することで、データサイズが小さくなるレイテンシの低減：HTTP/2 ヘッダー圧縮 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 user-agent: Mozilla/... 2 7 62 :path: /new_resource 63 64 インデックス化前イメージ :method GET :scheme https :host example.com :path /new_resource accept image/jpeg user-agent Mozilla/... Req #2 Req#1での既出分がインデックス化され、次のReqではインデックス値を送信

Proprietary & Confidential Powered by 32 #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) 証明書のやりとり暗号化・復号化に関わる処理がないので高速

Proprietary & Confidential Powered by 33 #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);

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

Proprietary & Confidential Powered by 35 #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

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

Proprietary & Confidential Powered by 38 #jjug_ccc #ccc_a7 • Protocol Buffers – 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; int32 product2_quantity_at_most = 4; repeated int64 product2_ids = 5; } IDL

Proprietary & Confidential Powered by 39 #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; int32 product1_quantity_at_most = 2; repeated int64 product1_ids = 3; int32 product2_quantity_at_most = 4; repeated int64 product2_ids = 5; } IDL

Proprietary & Confidential Powered by 41 #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サーバの追加に対応

Proprietary & Confidential Powered by 42 #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();

Proprietary & Confidential Powered by 43 #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 定期実行でサーバリストを更新

Proprietary & Confidential Powered by 45 #jjug_ccc #ccc_a7 レイテンシの低減 1. 広告商品情報サーバ接続処理による遅延がないこと To-Be を実現する上での要件広告商品情報サーバ入札サーバスループット向上 1. コネクション増加による処理数低下が起きないこと 2. ロードバランシングできることココの遅延広告商品情報サーバ入札サーバココの処理数再掲

Proprietary & Confidential Powered by 46 #jjug_ccc #ccc_a7 スループット向上 1. コネクション増加による処理数低下が起きないこと 2. ロードバランシングできること • HTTP/2 による並列化 • クライアントサイドロードバランシングレイテンシの低減 1. 広告商品情報サーバ接続処理による遅延がないこと To-Be を実現する上での要件は達成できそうか？ • HTTP/2 による高速な通信 • Protocol Buffers によるデータ圧縮

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

Proprietary & Confidential Powered by 48 #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 クライアントを呼び出して処理するだけ

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

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

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

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

Proprietary & Confidential Powered by 53 #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

Proprietary & Confidential Powered by 55 #jjug_ccc #ccc_a7 ・ユーザ情報・広告予算消化情報リアルタイムに扱う情報を格納広告商品情報サーバ Java8 gRPC-Java 入札サーバ Java8 gRPC-Java まとめ SSP nginx 入札サーバ入札サーバ入札サーバ入札サーバ入札サーバ入札サーバ X X X X ・広告キャンペーン情報事前定義、定期的にロードする必要がある情報を格納・アドフラウド情報 3rd Partyから提供された情報を格納 Aerospike (KVS) RDS Redis 今回はここをgRPCで構築ローカル処理を外部化しても 0.1ミリ秒の遅延に収まった広告商品情報

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

Proprietary & Confidential Powered by 57 #jjug_ccc #ccc_a7 お問い合わせ先 mailto: [email protected] https://www.ulsystems.co.jp/

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

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

More Decks by hiroisojp

Other Decks in Programming

Featured

Transcript