論文読み会 systems and infrastructure

13
WWW2017 読み会 Systems and Infrastructure 株式会社サイバーエージェント秋葉原ラボ 斎藤貴文

Upload: cyberagent

Post on 22-Jan-2018

783 views

Category:

Technology


4 download

TRANSCRIPT

Page 1: 論文読み会 Systems and Infrastructure

WWW2017 読み会

Systems and Infrastructure株式会社サイバーエージェント秋葉原ラボ斎藤貴文

Page 2: 論文読み会 Systems and Infrastructure

● 名前○ 斎藤貴文

● 経歴○ 東工大大学院 情報理工学研究科 数理・計算科学専攻 修士○ → サイバーエージェント入社

● 業務○ ストリーミングデータ処理基盤の研究・開発○ ログ転送管理システムの開発・運用

自己紹介

Page 3: 論文読み会 Systems and Infrastructure

● どんなセッション?○ ウェブのシステムに関する論文

● 傾向○ 広いテーマ

■ データストアやネットワーク等システムの性能比較系■ インターネットを題材にした社会科学っぽい分析系■ ウェブアプリケーションの開発支援系

○ 産業界より学術界の著者が多い■ 産業界の著者が参加している論文は 2/8■ 実用性よりは新規性

System and Infrastructure セッション概要

Page 4: 論文読み会 Systems and Infrastructure

● Legion: Enriching Internet Services with Peer-to-Peer Interactions● BOAT: Building Auto-Tuners with Structured Bayesian Optimization

紹介論文

Page 5: 論文読み会 Systems and Infrastructure

● 課題○ クライアントサーバモデルにおけるリソース集中管理によって生じる問題点

■ サーバあたりのクライアントのスケーラビリティ■ サーバ障害時はアプリケーションの利用が不可能

● Legionとは?○ サーバのデータをクライアントにコピーし 透過的に扱うためのフレームワーク

■ 開発者はデータの場所を意識せずデータを扱うことが可能

○ P2Pを使うことでサーバを介さずクライアント同士でデータの通信を行うことも可能

Legion: Enriching Internet Services with Peer-to-Peer Interactions概要

レガシーなアプリサーバとLegionを同様に扱えるようにするコンポーネント(※今回はAdaptersの話はしません)

Page 6: 論文読み会 Systems and Infrastructure

● P2Pのネットワークトポロジー○ 各クライアントはK個のクライアントとのリンクを保持

■ K = Kn(近場にいるクライアント数 ) + Kd(遠方にいるクライアント数 )■ クライアントの遠近はWebサーバのRTTベースで決定

● データオブジェクト○ Legionのオブジェクトは内部的に Δ-based CRDTとして表現

■ CRDTによってクライアント間のレプリカの結果整合性を保つことを保証

Legion: Enriching Internet Services with Peer-to-Peer Interactions提案手法

API1 API2 API3

C

RTT1 RTT2 RTT3

CCC

CCC

Kn

Kd

API群のRTTから座標が決定(x1, x2, x3) = (RTT1, RTT2, RTT3)

Page 7: 論文読み会 Systems and Infrastructure

●  クライアント間のPingPong的なやりとりのレイテンシの比較○ GDriveRTはGoogle Drive Realtime API○ 「Legion X」のXはクライアント数

Legion: Enriching Internet Services with Peer-to-Peer Interactions評価

Legionのほうがレイテンシを削減できている事がわかる

Page 8: 論文読み会 Systems and Infrastructure

● 課題○ アプリケーションパラメータの最適化のためにオートチューナー

■ DBのGC起因のレイテンシを削減する時のメモリ設定

○ ベイズ最適化ベースのオートチューナー■ 目的関数fと獲得関数αを用いてパラメータの事後分布を更新し最適なパラメータを探索

○ ベイズ最適化は1イテレーションのコストが高く収束に時間がかかる

● BOATとは?○ Structured Baysian Optimization(SBO)に基づいた

アプリケーションパラメータのオートチューナー

BOAT: Building Auto-Tuners with Structured Bayesian Optimization概要

ガウス分布と獲得関数にもとづいてパラメータxを選択パラメータと目的関数fから新しい観測値yを取得xとyの事後分布としてガウス分布を更新

Page 9: 論文読み会 Systems and Infrastructure

● 収束高速化のためSBOを提案○ ガウス分布ではなくアプリケーションの挙動を考慮した

セミパラメトリックな確率モデルを利用○ システムの開発者が確率モデルをコードベースで定義

BOAT: Building Auto-Tuners with Structured Bayesian Optimization提案手法

確率モデルのDAGをコード化

Page 10: 論文読み会 Systems and Infrastructure

● 2つのアプリケーションにおける既存のオートチューナーとの比較○ YCSB実行時のCassandraのレイテンシ○ 音声データのNNの確率的勾配降下法 (SGD)での反復時間

BOAT: Building Auto-Tuners with Structured Bayesian Optimization結果

両アプリケーションでBOATでは早々に収束完了

BOATが途中で消えている時点で最適解に到達

Page 11: 論文読み会 Systems and Infrastructure

● Legion: Enriching Internet Services with Peer-to-Peer Interactions○ クライアントサーバモデルをストレージレイヤーとみなした場合

データ移動の削減という観点で重要そうだと思った■ ネイティブアプリやリッチなコンテンツを配信するアプリとは親和性が高そう

● BOAT: Building Auto-Tuners with Structured Bayesian Optimization○ ウェブサービスの大規模分散化と属人性排除の方向性の中で

オートチューナーは重要だと感じた○ アプリケーションの挙動を考慮したパラメータの分布というのが面白いと感じた

■ その分布を作るコストが現実的なのかはちょっと疑問。。。

紹介論文の感想

Page 12: 論文読み会 Systems and Infrastructure

● Measuring and Improving the Reliability of Wide-Area Cloud Paths○ クラウドベンダーのDC間のネットワークパス (Cloud Path)の特徴を調査し

品質向上のパス決定手法を提案

● Blotter: Low Latency Transactions for Geo-Replicated Storage○ Non-Monotonic Snapshot Isolationにおいて

効率的にGeo-replicationを行うためのシステムBlotterの提案

● Ten Blue Links on Mars○ 「火星から地球の検索サービスを利用したらどういう影響がでるか?」という題材で

ネットワーク環境が超絶劣悪環境で起こりえる現象についての考察

○ 検索の応答性とデータの転送量のトレードオフ

1-2行解説

Page 13: 論文読み会 Systems and Infrastructure

● Exploring HTTP Header Manipulation In-The-Wild○ HTTPのリクエスト /レスポンスのヘッダがネットワークを介する上で

行われる変更についてグローバルな規模での傾向について分析

● Push or Request: An Investigation of HTTP/2 Server Push for Improving Mobile Performance○ HTTP/2の新機能ServerPushの効果をネットワーク・電力の点から調査

○ ネットワーク環境が劣悪 (高レイテンシ or パケロス頻発 )な場合はPushの効果大

● Performance Monitoring and Root Cause Analysis for Cloud-hosted Web Applications○ PaaSのアプリケーション上の性能異常を検知するシステム Roots○ リクエストごとに IDを付与しメトリクスを取ることで

ブラックボックスなアプリケーションにおいても異常検知が可能

1-2行解説