クラウド分散システム処理モデルの遷移およびその展望 #devsumi

Yahoo! JAPAN Tech Conference 分散システム処理モデルの課題と展望 今野 賢 2016.2.18 データ&サイエンスソリューション統括本部 データインフラ本部

自己紹介 今野 賢 (http://www.cybergarage.org) (こんの さとし) KURO-OBI 2005年 ヤフー株式会社中途入社。主に、IoT関連のデジタルテレビなどの組み 込み機器、iOS/Androidスマートフォン向けサービスの開発を担当。 最近は、NoSQLデータベース、CI/CD関連のエコシステム開発・運用業務に従 事。現在、社内の黒帯制度と社会人博士課程支援制度を活用中。 [1] Yahoo! JAPAN 黒帯制度 ~エンジニアの才能と情熱を解き放つ~

Yahoo! JAPAN Tech Blog アプリでモノとウェブを組み合わせて、生活を便利に自動化しよう ウェブ検索 YAHOO! デベロッパーネットワーク ようこそ、chkyj_st_skonno さん JAPAN ■0ポイント ヤフーでもTポイントがたまる、使える Yahoo! JAPAN ヘルプ Tech Blogトップ 全記事一覧 最近のエントリー 2016年2月16日 アーキテクチャ 分散プログラミングモデルおよびデザインパターン の考察 分散プログラミングモデルおよびデザイン パターンの考察 Developers Summit 2016 にて Yahoo! JAPAN Tech Conference を開催します ブックマーク 333 ツイート f Share 107 SCRIPTY#4 〜フロントエンド紳士・淑 女のための勉強会〜 #scripty04 EVPN (Ethernet VPN) 爆速改善を実現するヤフオク!アプリのアジ ャイル開発 カテゴリー アジャイル お知らせ イベント iOS Android サービス ● FastPay ● Yahoo!ボックス ● Yahoo! Open Local Platform ● テキスト解析 ● ヤフオク! ● Yahoo!ショッピング ● Yahoo!ニュース ● Yahoo!知恵袋 ● OpenID/OAuth

データインフラ本部とは？ 現在は、データ&サイエンスソリューション統括本部のデータインフラ 本部、KVSチームに所属。主にCassandra関連の開発と運用を担当[1] ここです！ RDB DWH Object Store KVS Hadoop [1] Yahoo! JapanのHadoopクラスタは6000ノードで120PB。指数関数的に増大するデータ需要を技術で解決していく。 Hadoop Spark Conference Japan 2016

黒帯制度とは ■社員の情熱と才能を解き放つため制度。任命 期間中は活動予算などの支援があります[1] KURO-OBI 黒帯制度による 褒賞金で購入！ [1] Yahoo! JAPAN 黒帯制度 ~エンジニアの才能と情熱を解き放つ~

本日のアジェンダ No 発表内容 ① 分散処理モデル 分類 ② 現状 ③ 歴史に学ぼう ④ 分散アプリケーション構築 課題 ⑤ 提案 ⑥ 実装 ⑦ 評価

Yahoo! JAPAN Tech Conference 分散処理モデルの 現状

分散処理モデルの現状 ■クラウドアプリケーションの構築方法 ・大別すると3種類の分散処理モデル上に構築[1] Cloud Applications 3 2 Application Frameworks 1 Resource Management Services Coordination Services Operating System ① 協調サービス ② リソース管理サービス ③ アプリケーション フレームワーク 現状 課題 歴史 課題 提案 実装 評価 [1] Yahoo! JAPAN Tech Blog: 分散プログラミングモデルおよびデザインパターンの考察

分散処理モデル分類① - 協調サービス ■協調サービス ・分散システム: 複数ノードが協調して目的を達成 ・ノード間で協調する機能を提供 ・デザインパターン: 共有メモリ、生産者消費者パターンなど Producer store retrieve Buffer Producer store retrieve Consumer Consumer Producer-Consumer ZooKeeper etcd Kafka Akka 現状 課題 歴史 課題 提案 実装 評価

分散プログラミングモデル分類② - リソース管理サービス ■リソース管理サービス ・分散システムのリソース管理機能を提供 ・デザインパターン: マスタワーカー Master control control Worker Worker Master-Worker Borg YARN Mesos 現状 課題 歴史 課題 提案 実装 評価

分散プログラミングモデル分類 - アプリケーションフレームワーク ■アプリケーションフレームワーク ・目的アプリケーション記述する機能を提供 ・デザインパターン: データフローなど Hadoop Node Node Node Tez Storm Pig .... 現状 課題 歴史 課題 提案 実装 評価

Yahoo! JAPAN Tech Conference 分散処理モデルの 課題

分散プログラミングモデルの歴史と乱立[1] ■分散処理モデルが乱立 2006: Google MapReduce 2013: MillWheel 2007: Microsoft Dryad 2006: Apache Hadoop 2006: Google Chubby 2008: Facebook Pig 2010: FlumeJava 2008: Google Borg 2009: Apache ZooKeeper 2009: Facebook Hive 2013: CoreOS etcd 2014: HashiCorp Consul 2010: Google Dremel 2013: Facebook Presto 2010: Apache Mesos 2012: Yahoo YARN 2011: Twitter Storm 2014: Google Kubernetes 2012: Google Spanner 2013: Apache Tez 2010: Apache Spark 2015: Twitter Heron 2013: Google F1 2014: Dataflow どれを 選ぶべきか？ 現状 課題 歴史 課題 提案 実装 評価 [1] Yahoo! JAPAN Tech Blog: 分散システム処理モデルに関する動向について (MapReduceからBorgまで)

乱立して困ること - 課題と提案 分類 課題 提案 どれが いいかなぁ 投資 運用 ・クラスタの構築 ・クラスタの利用効率 ・仮想化やコンテナによる転用 [1][2][3] ・リソース管理などによる効率化 [4][5][6] 資産 ・ソフトウェア資産の継承 ・知識、経験の陳腐化 ・DSLやSQLなどの抽象化言語の採用 (利用者視点) [7][8][9][10][11][12] 現状 課題 歴史 課題 提案 実装 評価 [1] 「OpenStack Summit Tokyo 2015」が開催。基調講演にYahoo!、NTTグループなどが登場、「OpenStackはデータセンター抽象化のコア」(前編) [2] OpenStack, http://www.openstack.org [3] Docker, https://www.docker.com [4] Mesos: a platform for fine-grained resource sharing in the data center, 2011 [5] Apache Hadoop YARN: Yet Another Resource Negotiator, 2013 [6] Large-scale cluster management at Google with Borg, 2015 [7] Hive - A Warehousing Solution Over a Map-Reduce Framework, 2009 [8] Yahoo Query Language (YQL), 2009 [9] Dremel: Interactive Analysis of Web-Scale Datasets, 2010 [10] Spanner: Google's Globally-Distributed Database, 2012 [11] F1: A Distributed SQL Database That Scales, 2013 [12] Facebook Presto, 2013

歴史に学ぼう！

乱立して困ること - 課題と提案 リソース管理って 見たことあるなぁ SQLって データベース言語だよね？ 現状 課題 歴史 課題 提案 実装 評価

乱立して困ること - 課題と提案 分類 事例 既存提案 どれが いいかなぁ 投資 超並列の世界だと ジョブ管理だね SQLトランザクションは 並列DBの世界だね 運用 ・専用クラスタの構築 ・専用クラスタの利用効率 ・リソース管理などによる効率化 [4][5][6] 資産 ・ソフトウェア資産の継承 ・知識、経験の陳腐化 ・DSLやSQLなどの抽象化言語の採用 (利用者視点) [7][8][9][10][11][12] 現状 課題 歴史 課題 提案 実装 評価 [1] The high-performance computing community has a long tradition of work in this area; however the [2] requirements of scale, work-loads and fault tolerance are different from those of Google's cells. [3] [4] Mesos: a platform for fine-grained resource sharing in the data center, 2011 [5] Apache Hadoop YARN: Yet Another Resource Negotiator, 2013 [6] Large-scale cluster management at Google with Borg, 2015 [7] Hive - A Warehousing Solution Over a Map-Reduce Framework, 2009 [8] Yahoo Query Language (YQL), 2009 [9] Dremel: Interactive Analysis of Web-Scale Datasets, 2010 [10] Spanner: Google's Globally-Distributed Database, 2012 [11] F1: A Distributed SQL Database That Scales, 2013 [12] Dremel is designed to operate at scale. Although it is conceivable that parallel DBMSs can be made to scale to thousands of nodes, we are not aware of any published work or industry reports that attempted that. クラウド環境とは 要件が違うと言うけれど...

歴史に学ぼう Dataflow (1960年代) Reactive Systems (1980年代) CSP *1) (1970年代) Actor Model (1970年代) AOP *2) (1970年代) High Performance Computing Parallel Database 分散システム Unix (1970年代) Microkernel (1980年代) *1) CSP : Communicating Sequential Processes *2) AOP : Aspect Oriented Programming 現状 課題 歴史 課題 提案 実装 評価

Microkernel

Microkernelの歴史に学ぶ① - 歴史的背景 ■歴史的背景 (1980年代~) ・モノリシック(Monolithic)なカーネルの大規模化、 柔軟性、信頼性、安全性などの問題を背景に発展 Mach QNX PikeOS L4 . . . 現状 課題 歴史 課題 提案 実装 評価

Microkernelの歴史に学ぶ② - 特徴 ■マイクロカーネルの特徴 ・カーネルを小さく分割して構成する ・最小限機能のみをカーネルモードで実行 → 最小限機能モジュール = マイクロカーネル ・その他大部分の機能をユーザープロセスとして実行 File . . . . . . . . . . . . Device User Process Microkernel Kernel Mode 現状 課題 歴史 課題 提案 実装 評価

Microkernelの歴史に学ぶ③ - 利点 ■マイクロカーネルの利点 ・高信頼性: カーネルとプロセスの分離 ・単一責務、疎結合性: 理解度、デバッグ効率 ・可変性: 動的なモジュール変更が可能 ・柔軟性: 動的な機能拡張が可能 File . . . . . . . . . . . . Device User Process Microkernel Kernel Mode 現状 課題 歴史 課題 提案 実装 評価

Microkernelに関連した動向① - MicroService ■マイクロサービスの特徴 モノリシック(Monolithic)なサービスを、複数の小さな サービスの集合体として構成する手法 Service . . . . Service Network 現状 課題 歴史 課題 提案 実装 評価

Dataflow

Dataflowの歴史に学ぶ① - 歴史的背景 ■歴史的背景 (1960年代~) ・当初は電子回路の記述言語として運用[1] → ハードウェアと密接な関係性あり ・1970年代: ソフトウェア的な活用が活発に [2] Node Node Node Node [1] John L. kelly Jr., Carol Lochbaum, V.A. Vyssotsky, A Block Diagram Compiler, 1961 [2] Jack B. Dennis, First Version of a Data Flow Procedure Language, 1974 現状 課題 歴史 課題 提案 実装 評価

Dataflowの歴史に学ぶ② - 特徴 ■データフローの特徴 ・ノード: 入出力ポートがある処理単位 パス: 入出力ポート間を接続。データが転送される ・ノード = 点(Vertex)、パス = 辺(Edge) → グラフ構造 Node Node Node Node 現状 課題 歴史 課題 提案 実装 評価

Dataflowの歴史に学ぶ③ - 利点 ■データフローの利点 ・並行性: 性質的に可能 (≠ 保証) ・高抽象性: (言語としての)抽象度が高い → 複数のプログラミング言語、位置的透過性など Node Node Node Node 現状 課題 歴史 課題 提案 実装 評価

Dataflowに関連するモデル① - UNIXパイプ ■ UNIXパイプ (≒ UNIX原則) ・データフロー的な観点で、最も普及している事例 ・複数の小さなプログラムを連結(パイプ)し、目的の (大きな)処理を実現する手法(思想) ・実装するプログラミング言語は問わない ls grep awk xargs 現状 課題 歴史 課題 提案 実装 評価

Dataflowに関連した動向 - 有向非巡回グラフ① ■有向非巡回グラフとは？ ・グラフ構造的には、有向グラフのデータフローから 巡回(閉路)がないもの Node Node Node Node 現状 課題 歴史 課題 提案 実装 評価

Dataflowに関連した動向 - 有向非巡回グラフ② ■有向非巡回グラフ: DAG (Directed Acyclic Graph) 近年のクラウドのプログラミングモデルとして、DAG ベースのフレームワークが隆盛 Hadoop Hive Storm Akka Dramel Tez Flume Java DataFlow (Google) 現状 課題 歴史 課題 提案 実装 評価

Dataflowに関連した動向 - リアクティブ (Reactive) ■リアクティブの語源 (1980年代~) ・リアクティブ(システム)[1]: 外部環境から入力に 対して連続して反応するもの ・リアクティブ(プログラミング)[2]: 外部環境の速度 で、外部要求に連続して反応として動作するもの Reactive ≒ Dataflow [1] David Harel, On the Development of Reactive Systems, 1985 [2] Gerad Berry, Real Time Programming: Special Purpose or General Purpose Language, 1989 現状 課題 歴史 課題 提案 実装 評価

課題

分散アプリケーションの課題① - モノリシック ■モノリシックな構築 ・分散アプリケーション毎にモノリシックに構築 ・既存資産(コード/知識)が移行できず陳腐化する場合も Distributed Application Distributed Application Distributed Application Distributed Framework Distributed Framework Distributed Framework App : A App : B App : C Operating System Operating System Operating System 現状 課題 歴史 課題 提案 実装 評価

分散アプリケーションの課題② - 再利用性 ■モノリシックな課題 ・再利用性: 流用が難しい Distributed Application Distributed Application Distributed Application Distributed Framework Distributed Framework Distributed Framework Operating System Operating System Operating System 現状 課題 歴史 課題 提案 実装 評価

分散アプリケーションの課題③ - 拡張性 ■モノリシックな課題 ・拡張性: (単一の)プログラミング言語に限定される Distributed Application Distributed Application Distributed Application Distributed Framework Distributed Framework Distributed Framework Java C++ Go Operating System Operating System Operating System 現状 課題 歴史 課題 提案 実装 評価

分散アプリケーションの課題④ - 可変性 ■モノリシックな課題 ・可変性: 動的な機能追加や変更 → 再起動が必要 New Distributed Applications Reboot Patch Operating System 現状 課題 歴史 課題 提案 実装 評価

分散アプリケーションの課題⑤ - 可読性 ■モノリシックな課題 ・可読性: プログラム構造の理解が難しい Distributed Application Distributed Framework Operating System ブラックボックス的な 運用になっているなぁ 現状 課題 歴史 課題 提案 実装 評価

提案

提案したいこと ■分散フレームワークの改善 モノリシック(Monocyclic)から マイクロ(Micro)に 静的(Static)から 動的(Dynamic)に 現状 課題 歴史 課題 提案 実装 評価

デザインゴール

デザインゴール① - マイクロ ■モノリシックからマイクロに ・分散アプリケーションをモジュールにて構築 ・既存資産(コード/知識)を移行可能に Distributed Application Distributed Application Distributed Application Distributed Framework Distributed Framework Distributed Framework App : A App : B App : C Operating System Operating System Operating System 現状 課題 歴史 課題 提案 実装 評価

デザインゴール② - 再利用性 ■再利用性 ・モジュール(積み木)的な構築手法に Distributed Application Distributed Application Distributed Application Distributed Framework Distributed Framework Distributed Framework Operating System Operating System Operating System 現状 課題 歴史 課題 提案 実装 評価

分散アプリケーションの課題③ - 拡張性 ■拡張性 ・拡張性: 最適なプログラミング言語で実装可能 Distributed Application Distributed Functions Distributed Frameworks Java C Ruby Python Java Script Tcl . . . Operating System 現状 課題 歴史 課題 提案 実装 評価

分散アプリケーションの課題④ - 再起動なし ■静的から動的に ・可変性: 動的な機能追加や変更を可能に → 再起動なし New Distributed Applications Reboot Patch Operating System 現状 課題 歴史 課題 提案 実装 評価

分散アプリケーションの課題⑤ - 可読性・透明性 ■ホワイトボックス的な開発・運用 ・可読性: モジュール毎のコード量が小さい ・透明性: 動作しているモジュールを把握 Distributed Application Distributed Frameworks Operating System 運用する部品は 自分で選んで 自分で開発！ 現状 課題 歴史 課題 提案 実装 評価

基本コンセプト

基本コンセプト② - マイクロノード ■マイクロ協調サービス ・各クラスタは、複数の基本処理エンジンから成る ノードから構成 Message Queue Method Engine Route Engine Method Route Zeroconf Engine Trigger Engine Registry Event Trigger Key 現状 課題 歴史 課題 提案 実装 評価

基本コンセプト④ - マイクロノード ■必要最低限の機能 ・各ノードはプログラマブルなRPC(Remote Procedure Call)として動作 ・初期状態では、各エンジンの基本メソッド(method)のみが定義済み Engine Method Script set_method, remove_method, .... Route set_route, remove_route, .... Trigger set_trigger, remove_trigger, .... Registry set_registry, remove_registry, .... Messaging post_method, post_trigger, .... その他の機能はユーザーが動的(または静的) プログラミング言語でメソッドを作成して追加 現状 課題 歴史 課題 提案 実装 評価

基本コンセプト③ - 動的なノード ■動的とは？ ・ノード挙動を動的に変更可能 → 挙動は「method」「route」「trigger」の組み合わせで定義 Program method route method method route method trigger route method trigger 現状 課題 歴史 課題 提案 実装 評価

基本コンセプト④ - 動的なノード ■多くのプログラミング言語に対応 ・メソッドは各種プログラミング言語で実装可能 method route method method route method trigger route method trigger JavaScript Python Tcl . . . C++ 現状 課題 歴史 課題 提案 実装 評価

基本コンセプト⑤ - 自律的なノード ■自律的とは？ ・外部イベントだけではなく内部イベントの定義も可能 → 「trigger」でcron的な動作も定義可能 Program method route method method route method trigger route method trigger 現状 課題 歴史 課題 提案 実装 評価

基本コンセプト⑤ - データフロー ■メソッド(method)とルート(route) ・メソッド: 処理の最小単位 → 動的(静的)プログラミング言語で実装 ・ルート: メソッド間を接続するパス method map() combine() shuffle() reduce() route ルートは、ローカルおよび別ノードのメソッドに設定が可能 現状 課題 歴史 課題 提案 実装 評価

基本コンセプト⑥ - データフロー ■特徴的な機能 ・メソッドやルートの動的追加が可能 ・非同期ルートや既存メソッドのオーバライドが可能 オーバライド map() combine() shuffle() reduce() debugging route original mehod outputlog() shuffle() 非同期なルート 現状 課題 歴史 課題 提案 実装 評価

実装

試作① - プロトコルスタック ■オープンスターダードな技術のみで実装 「JSON-RPC over HTTP」を拡張 ROUND Zeroconf RPC UPnP JSON-RPC Scripts SSDP GENA SOAP HTTPU HTTP HTTPU Script Engines UDP TCP UDP IP Operation Systems 現状 課題 歴史 課題 提案 実装 評価

試作② - コアエンジン実装言語 ■最初はコアエンジンはC++で実装してみたが ..... → 最終的にはC言語で再実装してみることに C++ 比較検証用に 実装してみよう Java Go Go版は C言語バインディング部は C++版と共有したい 設計がシンプルになりそう (全部Cで実装してみよう) C 現状 課題 歴史 課題 提案 実装 評価

試作③ - バインディング言語 ■最初はJava, JavaScriptからバインディングしてみたが ..... → Python, Lua辺りが本命になりそう Java クラスオブジェクト Staticメソッドにする？ Java Script SpiderMonkeyと V8で挙動が違う... Ruby 並列性がちょっと... mRubyは資料少ない Tcl 昔は鉄板でしたが... Python Lua 軽快で並列性も 取り扱いが良さそう 現状 課題 歴史 課題 提案 実装 評価

評価

評価① - 評価環境 ■評価アプリケーション ・NoSQLなKVSを実装 ・ストレージエンジンはLevelDB ■評価クラスタ ・RasberryPi2 Cluster ・RASPBIAN JESSIE 現状 課題 歴史 課題 提案 実装 評価

評価② - 評価の目的 ■心配だったこと ・コア部とスクリプトエンジン間のオーバヘッド ・スクリプト実行速度の性能 許容範囲であれば 動的メリットを優先したい 現状 課題 歴史 課題 提案 実装 評価

評価③ - 評価結果 ■YCSB (Yahcoo Cloud Serving Benchmark)にて計測 → 比較対象: Cassandra、Redis Cassandraは CQLベースのベンチマーク C言語ネイティブな 実装結果 動的言語組み合わせ (JavaScript or Python)の オーバヘッド 通信フレームワーク (HTTP + JSON)の オーバッヘッド Redisはバイナリプロトコル (通信およびメッセージ)のた め、高速に動作 現状 課題 歴史 課題 提案 実装 評価

まとめ

まとめ ■温故知新 ①今回は「Microkernel」「Dataflow」に発想を得た 協調サービスの実装を紹介しました ②動的スクリプト言語による性能劣化は、想定範囲 内でした ③最終的なエンジン実装は、(C++ or Go) + C言語 で、Cコア部の比率を調整するのが良い

ご静聴ありがとう ございました

YAHOO! JAPAN