ドコモビッグデータ分析基盤の · 2017. 7. 12. · --- 自分のスキーマのテーブル参照(オーナー問わず) SELECT usename, '' AS group, nspname AS schema,relname

ドコモビッグデータ分析基盤の AWS上構築経緯と開発裏話

2017/7/5 株式会社 NTTドコモ

サービスイノベーション部ビッグデータ担当佐々木純

2017/7/5 ⓒ2017 NTT DOCOMO, INC. All Rights Reserved. 0

AWS Solution Days2017 ～AWS DB Day～

今、本気で考えるデータベース移行とビッグデータ活用

自己紹介 ○ 佐々木純（Jun Sasaki）

R&Dイノベーション本部サービスイノベーション部

ビッグデータ担当所属

○ 業務内容

『ドコモビッグデータ分析基盤』の設計・構築・運用

オンプレ含むインフラ設計・セキュリティ設計・コスト管理・調整事

○ 経歴

ネットワーク研究所：『トラヒック研究』＋分析環境構築・運用（オンプレ）

総合研究所：『データマイニング』＋分析環境構築・運用（オンプレ）

現職：『ビッグデータ分析基盤』の構築・運用（オンプレ＋AWS）

インフラ構築とDB運用 10年超、データ分析約7年、AWS 約3年


ドコモビッグデータ分析基盤〇社内外データの横断分析が可能な分析基盤（2014～）


Data Sources ET Temporary Storage Fowarder

Loader State

Management

Long Term Storage

Redshift

Data operation Terminal

User Terminal

Data Encryption Key

Data encryption For Redshift

Encrypted data

SSL

Collector

External S3

External Serv

Ex-Hub

特徴

超大容量DB


多種データ

・ds2.8xlarge ×10： 160TB ・ds2.8xlarge ×125： 2PB ×2

・データソース： 20+ ・テーブル種類： 100+ ・データ容量： 10TB+/day (compressed)

多数のユーザ

・利用者数： 1000+ ・利用方法： SQL(psql, ODBC, R) ・同時実行数： 10程度

少人数開発/運用

・ドコモ社員5名+SE6名・初期構築時は4名のみ・（ほぼ）内製

構築背景①

〇ビッグデータ分析基盤以前のシステム


部内の分析者が使用する研究開発システム社員3名で設計・構築、SE含む5名で運用 10数名の分析者がビジネス部門に施策提案

構築背景②

〇当時の課題データの散在

多数のシステム・サービス

システム毎に隔離されたデータ

分析者リソース

担当内利用前提のシステム（＠YRP）、他拠点からの利用不可

利用者が限定されるためスケールしない

〇データ活用を推進するための解決策多種データの一元収集と部門横断利用の仕組みを備えた分析基盤


AWSを選んだ理由

〇オンプレとクラウド（AWS）を総合的に評価

〇評価結果

3年間のトータルコストは同程度

社内セキュリティ要件準拠可能

Redshiftの性能は圧倒的

構築・機能追加に要する時間、運用性もクラウドが圧倒


Total Cost Security Performance Maintainability

AWSへ舵を切ることを決断

以前のシステム（DB）構築時との比較〇以前のシステム（↓これ）


〇 AWS

設置場所の交渉・確保

電源工事空調工事

ラック工事

床工事

水道工事

フェンス工事

データセンター工事

建築工事

システム構築

ハードウェア選定ハードウェア調達

ネットワーク設計

ケーブリングソフトウェアインストール

DBチューニング

ソフトウェア選定ソフトウェア調達

RI購入

クラスター起動

click

click 人海戦術の構成変更

・・・

・・・半年～1年の工程が数Clickに短縮！本来やるべきことに注力可能

消防工事

ラック内配置設計

構築時の苦労ポイント①

〇社内調整


意思決定に至るまでの数十回の議論

社内中のデータを集めます

全てのデータをクラウド上へ

セキュリティリスククラウドに対する漠然とした不安費用対効果

別システムでのAWS利用実績既存の成果による価値の確信クラウドなら拡大/縮小可能

構築時の苦労ポイント②


〇初めてのAWS

構築時メンバー（4人）はAWS経験ゼロ

構築コンサル、社内AWS有識者、AWSJのサポート

クラウドならではの試行錯誤、即時実装

未経験でも意思決定から4か月で構築完了

セキュリティ対策

〇社内基準は全て準拠

AWSの豊富なセキュリティ機能をフル活用

論理的プライベート空間で構築

VPC, SG/NACL, DX, IAM, MFA, KMS

Cloud Trail, 各種セキュリティ認証 etc.

〇外部攻撃だけでなく内部犯行も防止

2014年7月某社にて運用者による情報漏えい発覚

将来は運用メンバは変化

→仮に悪意を持っても単独で悪さができない仕組みが重要

〇ユーザに対する制限

閲覧可能な情報のコントロール

システム外へのデータ取出し制限


〇基本設計

運用者であっても一人でデータを外部に出せない

root MFAは責任者（IAM無し）が施錠管理

（申請承認後、複数名で借用して作業）

〇初期の権限分離

× システム構成変更〇データ復号鍵〇 DB管理アカウント

IAMによる運用者権限の分離


〇システム構成変更 × データ復号鍵 × DB管理アカウント

運用グループA 運用グループB グループA：構成変更しても暗号化データしか持ち出せないグループB：平文データを持ち出す経路を作れない

X システム構成変更は次第に頻度減少 X データ処理は次第に稼働増加

× システム構成変更〇データ復号鍵〇 DB管理アカウント〇イメージの作成 × イメージの使用

× システム構成変更〇データ復号鍵〇 DB管理アカウント × イメージの作成〇イメージの使用

運用グループA 運用グループB

システム構成変更もroot MFA必須化両グループともデータ処理業務実施可能イメージ（AMI等）はリスクがあるため権限を分離

〇効率化が図れるようにシステム状況に応じて適宜見直し

〇現在の権限分離

Redshift上の制限～データアクセス権限～

〇承認済みでないデータへのアクセス、ユーザ間データ共有を制限

〇ユーザへ付与する権限 1. 承認されたデータ（スキーマ）へのRead権限

2. 個人スキーマへのRead/Write権限

3. プロジェクト（同一権限ユーザグループ）用共有スキーマのRead/Write/Grant権限


table1_20160101

table1_20160102

schema1

・・・

schema1_allow

schema2

table2_20160101

table2_20160102

schema2_allow

A

B

データ公開スキーマユーザグループ

A (schema1, 2を申請)

B (schema1のみ申請) A

ユーザ

Redshift上の制限～システムカタログ権限～〇未承認のテーブル名、他ユーザのテーブル名・実行クエリ閲覧も制限

多数のシステムカタログテーブルの参照権限を一括でREVOKE


SELECT DISTINCT ‘REVOKE ALL ON ‘ ||tablename || ‘ FROM public ‘ FROM pg_table_def WHERE tablename NOT LIKE ‘%index’ AND schemaname=‘pg_catalog’;

〇 ¥dすらできなくなる → 代替手段をViewで提供 -- 自分の参照できるテーブル一覧を確認できるSQL SELECT * FROM tablelist; -- 自分の参照できるテーブルの定義を確認できるSQL SELECT * FROM tabledeflist; -- 自分の実行クエリ・PIDを確認できるSQL SELECT * FROM querylist; -- 自分が実行できる関数一覧を確認できるSQL SELECT * FROM functionlist;

（参考） tablelistのview例


CREATE OR REPLACE VIEW tablelist AS --- group単位でのテーブル参照 SELECT usename, groname AS group, nspname AS schema,relname AS tablename, relkind FROM pg_user pu LEFT JOIN pg_group pg ON ( pg_catalog.array_to_string(pg.grolist,',') LIKE '%' || pu.usesysid || '%' ) LEFT JOIN pg_namespace pn on ( pg_catalog.array_to_string(pn.nspacl,',') LIKE '%group ' || groname || '=%U%' ) LEFT JOIN pg_class pc ON ( pn.oid = pc.relnamespace and pg_catalog.array_to_string(pc.relacl,',') LIKE '%group ' || groname || '=%r%') WHERE current_user = usename UNION --- 自分のスキーマのテーブル参照(オーナー問わず) SELECT usename, '' AS group, nspname AS schema,relname AS tablename, relkind FROM pg_user pu LEFT JOIN pg_namespace pn ON ( nspname = usename ) LEFT JOIN pg_class pc ON ( pn.oid = pc.relnamespace) WHERE current_user = usename UNION --- 自分がオーナーのテーブル参照 SELECT usename, '' AS group, nspname AS schema,relname AS tablename, relkind FROM pg_user pu INNER JOIN pg_class pc ON ( pu.usesysid = pc.relowner ) INNER JOIN pg_namespace pn ON ( relnamespace = pn.oid ) WHERE current_user = usename ORDER BY 1,2,3,4,5;

Redshift上の制限～LOAD/UNLOAD権限～〇（以前のRedshiftでは）任意のバケットへのLOAD/UNLOADが可能


AWS管理GW (非ユーザ領域）

アカウント内バケット

任意の別アカウントS3

自動付与のPublic IPでS3と通信 VPC ENDPOINTの制御外

UNLOAD (‘SELECT * FROM secret-data’) CREDENCIALS ‘別アカウントのcredencial’

〇ユーザからLOAD/UNLOAD権限をREVOKE

〇持込データのLOAD用にはシステム内にProxyを用意

利用拡大に応じて発生した問題①


〇スキーマ数/テーブル数枯渇問題最大スキーマ数： 256 （現在は9900）

1人1スキーマにより枯渇

最大テーブル数： 9900 元データだけで約半数を消費

活躍する人ほど多数のテーブル

〇不適切クエリの増加

SELECT * FROM 超大容量テーブル

無謀なJOIN

日単位テーブルを全UNION

非アクティブユーザのスキーマをサイレント削除

一時テーブル活用、実テーブル5個/人のお願い

勉強会でのレクチャ、個別指導、自動プロセスKILL

利用拡大に応じて発生した問題②

〇 CTAS問題（以前は）CTAS作成テーブルは非圧縮

圧縮設定DDL作成＋INSERTは面倒

非圧縮テーブル増加に伴い容量が逼迫

〇 UDF問題不適切な最適化オプションによる負荷増大

当初は気づかずVOLATILEを使用


オプション内容

VOLATILE 実行するたび毎回計算 STABLE 1クエリ内で同じ引数の場合は同じ結果を返す

IMMUTABLE 同一の引数であれば常に同じ結果を返す

インパクトの大きかったアップデート①

1. LOAD/UNLOADのREVOKE制御

Redshift採用の必須条件

2. インスタンス性能向上 ds1 → ds2

金額据え置きでDBパフォーマンス大幅向上

ヘッドノード高負荷時の安定性の問題も改善

3. VPCエンドポイント For S3

セキュリティ設計の簡略化実現（IGWの削減、IGW有りVPCを考慮したROLE設計）

脆弱性確認対象の縮小


〇 AWSサービスは随時進化

〇継続的にセキュリティ/性能/ユーザビリティ向上を実現可能

〇内容に応じて設計を柔軟に変えていく事が重要

インパクトの大きかったアップデート②

4. Redshift～S3のVPCエンドポイント対応 DB運用者に対してもUNLOAD出力先を制限可能

S3バケットポリシーの大幅な簡略化（126個のIPアドレスDeny除外記述の削除）

5. CTASの自動圧縮非圧縮テーブルによる容量逼迫改善

CTAS使用許可による分析効率向上

6. Schema数の拡大 1人1スキーマの破綻直前に9900に拡大

7. Redshift Spectrum 性能評価のみ実施、大規模クラスタ追加の代替候補になり得る十分な性能


Redshiftに関する残課題

〇AWSへの要望

PostGIS

最大テーブル数の拡大

〇ドコモ内検討事項

破産しないSpectrum活用法


http://postgis.net/

まとめ

〇 PBを超えるビッグデータ分析環境をAWS上に構築

未経験4人での短期間構築を実現

オンプレ構築の煩雑な工程から本来やるべき事にリソースをシフト

「クラウドは不可逆な流れ」

〇セキュリティ

各種AWS機能によりセキュリティ基準に準拠可能

オンプレでは難しい対策も容易に実現可能

システムの状態に応じて随時見直す事が重要

〇拡張性

クラウドでは機能は随時進化

セキュリティ/性能/ユーザビリティを継続的に向上可能



JAWS-UGビッグデータ支部

BigData-JAWS 勉強会

https://jawsug-bigdata.connpass.com/

AWS上でビッグデータ処理を行っている/行おうとしているユーザ中心グループ。

技術やユースケースの情報共有や、日々の悩みを相談。

少人数で 2~3 ヶ月に1回程度。

以下のテーマを想定。

•分散集計(RedShift、EMR、Athena等)

•機械学習(EMR、Amazon Michine Learning等)

•ストリーム・マイクロバッチ(Kinesis)

•分散KVS(DynamoDB)

•データフロー制御・スケジューリング(SWF,DataPipeline,Glue等)

•データマイグレーション(ネットワーク周り、スノーボール等） • BI (QuickSight)

次回は

7月下旬～8月上旬予定






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

連絡先

佐々木純（Jun Sasaki）

[email protected]

Documents

ドコモビッグデータ分析基盤の · 2017. 7. 12. · --- 自分のスキーマのテーブル参照(オーナー問わず) SELECT usename, '' AS group, nspname AS schema,relname