認証/認可が実現する安全で高速分析可能な分析処理基盤

認証/認可が実現する
安全で高速分析可能な
分析処理基盤
株式会社ドワンゴ
第二サービス開発本部
木浦正博

自己紹介
• 木浦正博, Masahiro Kiura
• 株式会社ドワンゴ/第二サービス開発本部
• ソフトウェアエンジニア
• 2015年01月入社
• I ❤️
• 分散システム(Hadoop/Grid computing etc…)
• パラメータチューニング
• Linux
• Python
2DWANGO Co., Ltd. all rights reserved.

会社紹介
株式会社ドワンゴ
• カドカワグループ
• ニコニコ動画、ニコニコ生放送を
はじめとするニコニコ事業を展開
• 2016年04月 N高等学校/N予備校開校
• 2017年04月ニコニコ超会議2017開催
項目データ
登録者数約6,743万人
プレミアム会員数※ 約243万人
MAU 約913万人
※プレミアム会員とは?
月額540円にて、専用回線での快適な視聴や、
生放送の優先視聴ほか様々な特典を受けられます
※2017年03月末時点のデータです
ユーザ数情報
DWANGO Co., Ltd. all rights reserved. 3

Agenda
• ドワンゴの分析基盤の紹介
• ドワンゴの分析基盤の課題
• プロジェクトゴール
• どのように実現したのか
• Hadoopの標準的な認証/認可機構の実現
• Hue/Oozie/HttpFSによる自社開発WebUI/APIのリプレイス
• Hive on Spark/Impalaの導入
• 何が実現できたのか
• アーキテクチャ
• 効果
• まとめ

ドワンゴの分析基盤の紹介
• 利用用途
• 分析(UU, PV, etc..)
• 情報推薦、レポーティング等
• ワークロード
• Pigが80〜90%
• 残りはHive on Spark/Spark, etc.. ※
• 利用者
• 連携システム 6
• 社内ユーザ 200+
• Pig
• Hive on Spark ※
• Spark ※
※ 本発表内容実現後に社内で提供開始
Date CM version CDH version
2015/05- 5.4.1 5.4.1
2016/07- 5.7.1 5.7.1 w/patch
2016/10- 5.8.2 5.8.2
2017/03- 5.10.1 5.10.1 w/patch
2017/06- 5.11.1 5.11.1
2017/10- 5.11.2 5.11.2 w/patch
CDHアップデート情報
• クラスタ概要
• 台数 100+
• 物理HDFS容量1.6PB
(Replication factor:3)

ドワンゴの分析基盤の課題
• 自社開発 Hadoop WebUI/API
• 独自の認証/認可機構
• Pig/MapReduceのみ実行可能
• 限りられたHDFS操作が可能
• 冗長化なし
• Oozie workflowのような、
ワークフロー制御機構はなし
• 利便性の高い機能拡張をするためには、24人
月以上の開発が必要
• Pig/MapReduceよりも学習コストが
低いSQLベースの分析ができない
• SQLベースの分析を提供するには、
データリスクを伴う
HDFS
YARN
自社開発 WebUI 自社開発WebAPI
WebHDFS
社内ユーザ
UU、PVを始めとする分析、KPI
の算出などを行うユーザ
連携システム
推薦システム、
検索システムなど
ブラウザアクセス
Pig/MapReduce実行ファイルUP/DL
独自認証による
WebAPIアクセス

ドワンゴの分析基盤における戦略
• 基盤の利便性向上攻めの戦略
• 自社開発のWebUI/APIよりも利便性が高く、
運用コストが低いHue/Oozie等の導入
• Hive/Impalaによる分析機能の提供
• 様々なリスクの回避守りの戦略
• 多くの社内ユーザが参照しているデータが誤って削除されるリスク
• 可用性がない箇所で問題が発生した場合に分析ができなくなるリスク
• 認証・認可機構やコンポーネントの冗長化が必要
• 基盤として攻めの戦略を取っていきたい
• しかし、リスクを抱えながら攻めの戦略はできない

プロジェクトゴール
Hadoopの標準的な認証/認可機構による安全性を確保した、
より利便性・安定性の高いHadoop WebUI/APIの提供
高速に分析できる環境の提供

どのように実現したのか
• 認証と認可、Kerberos認証の基礎
• Kerberos認証の導入
• OozieAPI/HttpFSについて
• OozieAPI/HttpFSと自社開発WebAPIの比較
• Oozie/HttpFSの導入
• Hive on Sparkの導入課題・導入
• Impalaの導入
• 分析高速化に関する取り組み

• Impalaの導入

認証と認可、Kerberos認証の基礎
• 認証と認可
• MIT Kerberos vs. AD
• (参考)用語解説
• コンポーネント
• エンティティ
• チケット
• API
• 認証シーケンス
• 認証シーケンス例
• Hadoopクラスタでの処理

Kerberos認証 - 認証と認可
• 認証/認可とは?
• OSで言うと
• OSにusername/passwordを用いてログイン(認証)
• 認証されたユーザができる操作をACLで制御(認可)
種類説明 Hadoopでの実現方法
認証(Authentication) アクセスした人は誰か? Kerberos認証(MIT Kerberos,
Active Directory)
認可(Authorization) その人はどういう操作ができるのか? HDFS ACL/Sentry
監査(Audit) いつ誰がアクセスしたのか? Cloudera Navigator,
Apache Ranger

Kerberos認証 - MIT Kerberos vs. AD
• Kerberos認証 MIT Kerberos vs. Active Directory
• MIT Kerberosの調査
• 実運用レベルの情報が少ない
• バックエンドにLDAPを利用するためには?
• マルチマスタリプリケーションを構築するためには?
• 弊社が取った調査方法
• 公式ドキュメント http://web.mit.edu/kerberos/krb5-latest/doc/
• RFCs
• ソースコード
Kerberos Software Pros. Cons.
MIT Kerberos Linuxの運用知識が流用可能構築・運用に関するドキュメントが少ない
Active Directory スケールさせやすい • Windowsに関する学習コストが必要
• Hadooopクラスタの各ノードを
ドメインに参加させる必要あり

(参考)Kerberos認証 - コンポーネント
• KDC (Key Distribution Center)
• Kerberos認証・チケット配布を行うサーバ
• 後述するAS, TGSとKerberos Databaseから構成される
• AS (Authentication Server)
• Kerberos認証を行い、暗号化されたTGT(Ticket granting ticket)の配布を行う
• TGTは、Principalがサービスの利用要求を行う際に利用される
• TGS (Ticket Granting Server)
• ユーザがもつTGTを復号化し、正当性チェックとサービスチケットの発行を行う
• KDC Database
• Realm, Principalなどの情報を保持するデータベース
• MIT Kerberosにもあるが、LDAPをバックエンドにすることも可能

(参考)Kerberos認証 - エンティティ
• Realm
• Principalが参加している組織を表す文字列。所謂ドメイン
• 例) HADOOP.DWANGO.CO.JP
• Principal
• 認証される対象
• 全てのユーザとサービスは、Realm内のPrincipalとしてKDCに認証される
• UPN (User principal names)
• ユーザを認証するためのPrincipal、{user name}@{realm}と指定する
• 管理者として認証する場合は「/admin」などを指定する(KDCのacl_fileで変更可)
• 例1) masahiro_kiura@HADOOP.DWANGO.CO.JP
• 例2) masahiro_kiura/admin@HADOOP.DWANGO.CO.JP
• SPN (Service principal names)
• サービスを認証するためのPrincipal、{service}/{host}@{realm}と指定する
• サービスとそのサービスが稼働するホストを指定する
• 例) yarn/node1.dwango.co.jp@HADOOP.DWANGO.CO.JP

(参考)Kerberos認証 - チケット
• TGT (Ticket granting ticket)
• ASでの認証が成功したPrincipalに対して発行されるチケット
• 後述するSTを要求するために利用される
• ST (Service ticket)
• サービスを利用する際に利用するチケット
• TGSにTGT渡した結果としてSTが発行される
• Client/TGS/Service Master Key
• Client・KDC間でやり取りするデータを暗号化・復号化を行うための鍵
• Session Key
• AS/TGSで作成され認証情報の暗号化・復号化を行うための鍵

(参考)Kerberos認証 - API
• GSS-API(Generic Security Standard Application Programming Interface)
• 通信を行うClient/Serverのアプリケーションに、汎用的なデータ保護を行う方法を提供
• アプリケーションは、セキュリティに関する実装をアプリケーション内にもつ必要がなく、RFCに準拠
したインターフェイスでセキュリティ外部モジュールを呼び出し、
送信することでセキュアな通信を確立できる
• SPNEGO(Simple and Protected GSSAPI Negotiation Mechanism)
• GSS-APIを利用するClient/Server間で利用する認証メカニズムを決定する方法

Kerberos認証 - 認証シーケンス
YARNサービス on node1
HDFSサービス on node2
ユーザ1
KDC
Authentication Server
Ticket Granting Server
Kerberos Database
Ticket granting ticket
Service ticket
Principals(ユーザ・サービス)
??
Realm(組織)

Kerberos認証 - 認証シーケンス
Client AS TGS サービスサイド
KDC
TGS_REQ (認証情報, TGT, Requested Service Name)
TGS_REP (ST)
AP_REQ (認証情報, ST)
AP_REP (ST)
AS_REQ (Realm, UPN)
AS_REP (Realm, UPN, TGT)
例えば、Clientからhttpfsへのアクセスではどのような処理が行われているのか…?
※暗号化復号化に関わるMaster Key, Session Keyを利用した処理はここでは省略しています。

Kerberos+Hadoopシーケンス例(httpfs)
Client AS TGS httpfs
※暗号化復号化に関わるMaster Key, Session Keyを利用した処理はここでは省略しています。
KDC
AS_REQ (Realm, UPN)
TGS_REP (ST)
HTTP Request
HTTP Response 401 Unauthorized
HTTP Request
HTTP Response ★

KDC
AS_REQ (Realm, UPN)
TGS_REP (ST)
HTTP Request
※詳細な通信や処理内容は省略しています。
HTTP Request
HTTP Response
$ kinit masahiro_kiura@HADOOP.DWANGO.CO.JP
masahiro_kiura@HADOOP.DWANGO.CO.JP's password:
$ klist
Credentials cache: API:XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX
Principal: masahiro_kiura@HADOOP.DWANGO.CO.JP
Issued Expires Principal
Oct 18 15:30:54 2017 Oct 19 01:30:54 2017
krbtgt/HADOOP.DWANGO.CO.JP@HADOOP.DWANGO.CO.JP
★

KDC
AS_REQ (Realm, UPN)
TGS_REP (ST)
HTTP Request
HTTP Request
HTTP Response
$ curl --negotiate -u : http://hadoop.dwango.co.jp/webhdfs/v1/user?op=LISTSTATUS
GSS-API/SPNEGOでHDFS上の/user配下をリストする
ClientとServerがそれぞれKerberos認証に対応していることを確認し、
Client側のcurlがTGTを取得する(SPNEGO)
★

KDC
AS_REQ (Realm, UPN)
TGS_REP (ST)
HTTP Request
HTTP Request
HTTP Response
{"FileStatuses":{"FileStatus":[{"pathSuffix":”dwango","type":"DIRECTORY","length":0,"owner
":"dwango","group":"dwango","permission":"750","accessTime":0,"modificationTime":1475119
912309,"blockSize":0,"replication":0},{"FileStatuses":{"FileStatus":[{"pathSuffix":”dwango","typ
e":"DIRECTORY","length":0,"owner":"dwango","group":"dwango","permission":"750","access
Time":0,"modificationTime":1475119912309,"blockSize":0,"replication":0}…
★

KDC
AS_REQ (Realm, UPN)
TGS_REP (ST)
HTTP Request
HTTP Request
HTTP Response ★Hadoopクラスタでは何が行われているのか

• UPN/SPNの実行ユーザ名への変換
• Principal名はhadoopではそのまま扱えない
• hadoop.security.auth_to_localのルールにより解決
• CDHはデフォルトで以下をサポートする
• masahiro_kiura@HADOOP.DWANGO.CO.JP → masahiro_kiura
• yarn/node1.dwango.co.jp@HADOOP.DWANGO.CO.JP → yarn
• 実行ユーザ名が所属するグループの解決
HadoopGroupMappingによりユーザ・グループの対応を解決
• ShellBasedUnixGroupsMapping
OSユーザ・グループの関係でHDFSユーザ・グループの関係を管理
• LdapGroupsMapping
LDAP上のユーザ・グループの関係でHDFSユーザ・グループの関係を管理
Hadoopクラスタでの処理

• Delegation Token/その他Tokenのやり取り
• HDFSに複数回アクセスするために、毎回Kerberos認証を行うことなく、
HDFSアクセスを行う仕組みがDelegation Token
• BlockTokenは、DN上のHDFSブロックへのアクセスを
許可するために発行されるToken
• Hadoopクラスタ上で利用されるTokenはまだありますが、
ここでは割愛します(AMRMToken, NMToken)
Hadoopクラスタでの処理

• コンポーネントやPrincipalなど独自の用語がある
• コンポーネント・Principal間で独自の通信が発生する
• Hadoopクラスタ側でも様々な処理がある
• Principal→Username変換
• User・Groupのマッピング(HadoopGroupMapping)
• Delegation Token/その他Tokenのやり取り
• どうやって構築するのか(したのか)
Kerberos認証のまとめ

0. 弊社で導入する場合の前提条件
1. LDAPサーバへのKerberosスキーマの追加
2. 各種ユーザ設定
3. KDCのdatabaseとしてLDAPを設定
4. SSSD導入
5. CMの設定・その他
Kerberos認証の導入

HDFS
YARN
WebHDFS
社内ユーザ
連携システム
WebAPIアクセス
弊社でKerberos認証を導入する場合の前提
• 前提1 Hadoop認可導入済み
• 弊社は、このプロジェクトの一貫で、認証
の前に認可(HDFS ACL)を導入
(詳細は昨年の資料をご確認ください)
• 認可を先に実現する意味は?
Kerberos認証を入れた場合の影響範囲
HDFS ACLを入れた場合の影響範囲
• 自社開発WebUI/WebAPIがKerberos認証
に対応していないため、認証を
先に導入すると、影響範囲が大きい
• 先に認可を導入し、認可が正しくできてい
なかった自社開発WebUIをHueに置き換
えて認証導入時のリスクを軽減

• 前提2 LDAPサーバ導入済み
• ユーザとグループの情報はLDAP上に保存済み
• ユーザとグループのマッピングもLDAP上で設定済み
• このユーザ情報をKerberos認証のPrincipalとして利用したい
弊社でKerberos認証を導入する場合の前提
LDAP #1 LDAP #2
Repli
ユーザ・グループ情報
マッピング情報
KDC #1 KDC #2
ユーザ情報
☓Kerberos・LDAPそれぞれで管理するのはコスト大
既存
新規
LDAP #1
KDC #1 KDC #2
LDAP #2
Repli
Read
ユーザ・グループ情報
マッピング情報
◯LDAP上で認証情報を含めて一元管理
新規
既存

• KDCのバックエンドにLDAPを用いる場合、Principalに相当する
実体にはobjectclassにkrbTicketPolicyAuxとkrbTicketPolicyAuxを追加す
る必要がある
LDAPサーバへのKerberosスキーマの追加
object class名 krbPrincipalAux
付与できる属性 • krbAllowedToDelegateTo
• krbCanonicalName
• krbExtraData
• krbLastAdminUnlock
• etc…
object class名 krbTicketPolicyAux
付与できる属性 • krbMaxRenewableAge
• krbMaxTicketLife
• krbTicketFlags
DN名 uid=masahiro_kiura…
objectclass • inetOrgPerson
• krbPrincipalAux
• krbTicketPolicyAux
• posixAccount
属性 • krbExtraData=…
• krbTicketFlags=…
• gidNumber=…
実体Objectclass
イメージ的には、実体はobjectclassの
多重継承により設定できる属性が決まる

• Kerbeos関連のobjectclassをLDAPに追加
• LDAPをバックエンドにするOSパッケージ(krb5-server-ldap)を導入
• パッケージ内にkerberos.schemaというファイルが入っているため、
slapcatコマンドなどでobjectclassを定義したファイルに変換し、
ldapaddコマンドでLDAPに追加
LDAPサーバへのKerberosスキーマの追加

• KDCからLDAPに接続するユーザ
• LDAP上に作成し、LDAPの書き込み権限を設定する
• KDC上にはアクセスパスワードを暗号化したstashファイルを配置
• LDAP上のユーザデータ
• 実体を修正し、objectclassや各種属性を追加
• KDCから参照してPrincipalとして利用できるデータに変更
各種ユーザの設定
Kerberos管理者
KDC
LDAP
Stashファイル
LDAP Object
Read/Write

• kdb5_ldap_utilコマンドでldapにprincipalのサブツリーを作成
• Ansibleなどで遅延なく実行できれば複数ホストに流せる
• ネットワーク遅延があると複数台実行はエラーになりKDC毎に設定が必要
• MIT KerberosのMulti Master Replicationは、
公式ドキュメントがないので、RFCやコマンドを十分に学習する必要がある
KDCのdatabaseとしてLDAPを設定
kdb5_ldap_util
-D {{ kerberos_ldap_admin_tree }}
-w {{ ldap_admin_password }}
create -subtrees {{ kerberos_principal_tree }}
-r {{ realm_name }}
-s -H ldap://{{ ldap_server }}

DWANGO Co., Ltd. all rights reserved.
• Kerberos化する前後で各ジョブの実行ユーザが異なる
• Kerberos化前: yarnユーザ
• Kerberos化後: masahiro_kiuraユーザなど
• ジョブを実行する全ユーザのOSアカウントが各ノード上に必要
• SSSD(System Security Services Daemon)
• OSに対してLDAPのような外部ID管理サーバへの接続管理を提供
SSSD導入
35
個々のノード
yarnユーザが実行するNM
個々のジョブコンテナ
LDAPSSSD
1.作成
2.ジョブ実行
・実行ユーザ名の解決
・該当ジョブの実行
2.ジョブ実行
・実行ユーザ名の解決
・該当ジョブの実行
ユーザ名の解決は弊社の場合は以下の順
・/etc/passwd
・SSSDキャッシュ
・SSSD経由LDAP接続

• CMのウィザードベースでほぼ完結
• https://www.cloudera.com/documentation/enterprise/latest/topics/cm_sg_intro_k
erb.html
• 注意点
• CMがKDCにユーザを作成できる専用Principalを作成しておく必要がある
• DN上のyarn usercache配下のディレクトリ等を全削除しておかないと、
前述のジョブ実行ユーザが変わる問題でジョブが落ちる
CMの設定・その他

• Kerberos認証
• 冗長化されたKDCを構築
• KDCのバックエンドとしてLDAPサーバでPrincipalを管理
• HDFS ACL/Sentry(詳細な説明は省略)
• Group MappingでLDAPからグループ/ユーザの紐付けを一元管理
• 管理アプリケーションを開発し、ユーザ・ACLを一元管理
Hadoopの標準的な認証/認可機構の実現
LDAP #1
KDC #1 KDC #2
LDAP #2
Kerberos client for cluster nodes
/CDH components/users HDFS
Sentry
Repli
User/Principal/ACL
management WebApp
LDAP Object
Read/Write
Read
Read
ACL
Read/Write
LB LB
Hadoop cluster sideAdministrator side Kerberos client side
Group mapping
Read
YARN
SSSD
LDAP Object
Read

• Impalaの導入

OozieAPI/HttpFSについて
• OozieAPI
• REST APIでジョブの実行が可能
• ジョブ依存関係や実行間隔等を定義
• 勿論単体のジョブ実行も可能
• 実行完了後にCallback可能
• ジョブ依存関係の例(Hue)
• HttpFS
• REST APIでHDFSの操作が可能
• クライアントはHttpFSをプロキシとして、
HDFS(NN, DN)と通信を行う
HDFS
WebHDFS
連携システム
HttpFS
LB
NameNodeNameNode DataNodeDataNode

OozieAPI/HttpFS 自社開発WebAPI
MR/Pigの実行 ◯ ◯
Spark/Hiveの実行 ◯ ☓ (追加開発が必要)
APIによるジョブ実行 ◯ ◯
APIによるHDFS操作 ◯ ◯
APIの柔軟性 ◯ △ (追加開発が必要)
ジョブの依存関係の定義 ◯ (Oozie Workflowから可能) ☓ (追加開発が必要)
ジョブの定期実行制御 ◯ (Oozie Coordinatorから可能) ☓ (追加開発が必要)
Kerberos認証 ◯ (対応) ☓ (追加開発が必要)
可用性(冗長性) ◯ (CMから設定可能) ☓ (追加開発が必要)
OozieAPI/HttpFSと自社開発WebAPIの比較
OozieAPI/HttpFSに移行することで、自社開発WebAPIの追加開発コスト、運用保
守コストを下げながら、WebAPIの利便性を上げることができる

• 自社開発APIを利用する連携システムの移行ケア
• 社内OozieAPI/HttpFSマニュアルの作成
• APIを事前に利用できる環境の整備
• QA対応
• リプレイス
• 基本的には以下の手順でできる
https://www.cloudera.com/documentation/enterprise/5-2-
x/topics/admin_httpfs.html
• OozieについてはHue導入時に追加しているため、
Kerberos認証が有効になった段階で連携システム・ユーザにAPIを解放
OozieAPI/HttpFSの導入

Hue/Oozie/HttpFSによる
自社開発WebUI/APIのリプレイス
• 新たな機能の提供
• Spark/Hiveが実行できるWebUI/API環境
• より柔軟性のあるAPI
ワークフロー/実行頻度管理機能(Oozie workflow/coordinator)
• 冗長化
• 自社開発のWebUI/APIは冗長化されておらずSPOFだった
• Hue/Oozie/HttpFSをそれぞれ冗長化してSPOFを解消した
• 自社開発のWebUI/APIの機能追加/運用/保守コストを24人月以上削減
• 付加価値の高い機能を社内ユーザ/システムに対して提供

Hue/Oozie/HttpFSによる
自社開発WebUI/APIのリプレイス
HDFS
YARN
WebHDFS
社内ユーザ
連携システム
WebAPIアクセス
HDFS
Hue
Oozie
社内ユーザ
連携システム
HttpFS
Pig/MapReduce
実行YARN
Kerberos認証による
WebAPIアクセス

• Impalaの導入

Hive on Sparkの導入課題・導入
• Hive on Sparkの導入課題
• 今までは認証・認可ができておらず、
社内ユーザは多くのユーザが利用するデータを誤って削除できる状況
• 自社開発WebUI/APIに大きな変更を加えなければ導入は難しかった
• Kerberos化・Hue/Oozie/HttpFS導入により低コストで導入可能に
• Hive on Sparkの導入
• CMからSentryとともにコンポーネント導入
• Sentry w/Sentry-HDFS Synchronizationを導入し、Hive上の認可を設定
• Hue/OozieAPI/TableauからHiveを用いた分析が可能に

Impalaの導入
• Impala導入の課題
• 現行クラスタの1台あたりのCPU・MemoryではSpark・Hive on Spark
のジョブ実行を行いながら、Impalaを導入するには十分ではない
• Impala導入
• 試験的に別クラスタ(KDCは現行クラスタと共有)を構築
• 現行クラスタからdistcpバッチでデータをコピーしながら、
ホットデータのみに絞ってTableauから分析できるように

(参考)分析高速化に関する取り組み
• チューニング以前の課題
• splitできない巨大なデータが1ファイルとして保存されていた
• 例えば10GBなどのデータ
• ジョブ実行の際にネットワーク転送しながら読み込み並列度が上がらない
• データの最適化
• HDFS上の殆どの分析データをParquetに変換(1年半で進捗率8割程度完了)
• 1ファイルをSparkの変換ジョブでBLOCK SIZE程度に調整
block block
DN DN
Yarn TaskYarn Task
1HDFSファイルをBLOCK SIZE程度に調整しParquet化
Local ReadLocal Read
blockblock block
DN DN DN
Yarn Task
1つのHDFSファイルサイズがBLOCK SIZEを超えると、
読み込みのためネットワーク経由で読み込んでYarn Taskが実行される
NW ReadNW Read Local Read
複数のDNに跨って保存された1ファイル 1ファイル 1ファイル

Hive on Spark/Impalaの導入
• Hive on Sparkを導入
• Hue/Oozie API/Tableauを通じてSQLベースで分析可能になった
• Impalaを導入
• 試験的に導入
• 試行錯誤の段階だが、TableauからODBCを通じてインタラクティブに分析可能
になった
• 従来のMapReduce/Pigと比較して、SQLベースの分析が可能に
なったことで、社内ユーザの学習コストを年間12人月以上削減
• TableauによりSQLを書かなくても分析ができる環境を提供
• 従来のMapReduce/Pigと比較して、数倍から数十倍高速に
分析イテレーションを回せるように

何が実現できたのか
• 得られた効果

アーキテクチャ
HDFS
YARN
Hue
OozieHive/Sentry HttpFS
Kerberos
LDAP
社内ユーザ
Impala
連携システム
Tableau経由
ODBCアクセス
WebAPIアクセス

アーキテクチャ
HDFS
YARN
Hue
OozieHive/Sentry HttpFS
Kerberos
LDAP
社内ユーザ
Impala
連携システム
Tableau経由
ODBCアクセス
WebAPIアクセス
Hue/Oozie/HttpFSの導入Hive on Spark/Impalaの導入
Hadoopの標準的な
認証/認可機構の実現

得られた効果
• 社内ユーザ側
• 利便性が高く安定したHue/Oozieを提供
• Tableau経由での分析を提供
• ユーザ全体で、Hive on Spark/Impalaにより
技術的学習コストを年間12人月以上削減
• Hive on Spark/Impalaにより分析・レポーティング
イテレーションを数倍から数十倍高速化
• Hadoop ecosystemを社内サービス化し、セルフサービス分析を実現
• 連携システム側
• Oozie APIを通じてワークフロー/定期実行管理を提供
連携システムで行っていたワークフロー/定期実行管理が不要に
• Spark/Hive on Sparkを提供(一部のジョブは従来より約10倍高速化)

得られた効果
• 管理者側
• Hadoopの標準的な認証/認可を導入
自社開発の認証/認可によるセキュリティリスクを
意識する必要がなくなった
• Hue/Oozie/Spark/Hive on Spark/Impalaなど、
多くの新たな機能を提供するとともに可用性を担保
• 自社開発のWebUI/APIの機能追加/運用/保守コストを24人月以上削減

まとめ
• ドワンゴの分析基盤の紹介
• ドワンゴの分析基盤の課題
• プロジェクトゴール
• どのように実現したのか
• 何が実現できたのか
• 効果
Hadoop, Hive, Pig, Spark and Oozie are either registered trademarks or trademarks of the Apache Software Foundation in the United States and other countries.
Cloudera and Hue are trademarks of Cloudera, Inc. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. Python is a registered trademark
of the PSF.

We’re hiring !
ドワンゴでは、分析基盤の利便性をより向上
させることができるエンジニアを募集しています!
ドワンゴデータプラットフォーム

認証/認可が実現する安全で高速分析可能な分析処理基盤

More Related Content

認証/認可が実現する安全で高速分析可能な分析処理基盤