BigData-JAWS 勉強会#1 参加レポート #bdjaws

甲木洋介

2016.09.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、yokatsukiです。

日本におけるAWSのユーザグループ、JAWSですが、今までビッグデータを専門にしている支部は無かったようです。という訳で、ビッグデータをテーマに扱う支部がBigData-JAWSとして立ち上がり、第1回目の勉強会が7/22に実施されました。

BigData-JAWS 勉強会#1

23名の募集枠に対して42名の応募があり抽選となったのですが、運良く当選しましたので、参加レポートをお伝えします。

会場

会場は目黒のアマゾンウェブサービスジャパンのセミナールームでした。

会場の雰囲気(主催者渡部さんのツイート)

私が到着した時には、参加者はあらかた名刺交換＆着席まで済んでしまっている状態で、セッションが始まる前から熱意が滾っていました。

支部の説明

最初は主催の渡部　徹太郎さん(株式会社リクルートテクノロジーズ　ビッグデータ部)から挨拶とこの支部の概要、趣旨についての説明から始まりました。

支部の概要についての説明は、新たに開設されたGitHub上の支部ページにも記載されています。

ビッグデータ支部の紹介｜GitHub

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

技術やユースケースの共有や、日々の悩みを相談をすることを目的としています。

以下のテーマを想定しています。

　・分散集計(RedShiftやEMR等)
　・機械学習(EMRやAmazon Michine Learning等)
　・分散キュー(kinesis)＋ショートバッチ
　・分散KVS(DynamoDB)
　・データフロー制御・スケジューリング(SWF,DataPipeline等)
　・データマイグレーション(ネットワーク周り、スノーボール等）
　・BI(QuickSight等)

今日の目的

まずは第1回勉強会を開催してみること(手探り感あるのでご了承ください！)
一緒に運営してくれる仲間を見つけること(懇親会で見つけます！)
次回のテーマを募集すること

今後の活動方針イメージ

今回はEMRとRedshiftだが、(同じ位の参加者ボリュームで)違うテーマで2, 3回実施したい
ネタが集まったところで100〜150人くらい入る会場で発表大会
- 興味があるけど発表しない人に広く聞いてもらうイベントにする
発表資料は(公開に差し支えないものは)GitHubに公開

「結構敷居高めの募集をしたのですが、顔ぶれとMacの裏のステッカー見るとなかなかいい人達に集まってきてもらったと思っていて凄く嬉しいので、是非これから仲良くしてください」との言葉で最初の挨拶となりました。

EMRの紹介と他のHadoop製品との使い分け

まず最初の発表は、主催者渡部さんのEMRの話でした。

event-report-bigdata-jaws-1-01

資料ダウンロードはこちら

発表者：渡部　徹太郎（株式会社リクルートテクノロジーズ　ビッグデータ部)
概要： AWSのマネージドHadoopサービスであるEMRを紹介します。
また、リクルートではオンプミスのHadoopやTresureDataといったフルマネージドサービスを使いつつも、適材適所でEMRを使ってます。その時の使い分けを説明します。

自己紹介

スライドp.1
- 東工大でデータベースの研究→NRIでオンライントレードシステムの基盤コテコテのSIer→社内でオープンソースを扱う社内ベンチャーでMongoDBやNoSQL全般を扱う→リクルートへ転職
- 現在はリクルートの様々なサービスからIDポイントに紐付いて集まってくるデータを扱う基盤を担当(Exadata, Hortonworksを使用)
- 技術を横串で技術を扱うビッグデータ部として、事業会社にEMR提供(今日の説明範囲外)
スライド p.2
- 自宅1Fのトイレを使っていないので、潰してサーバを配置
- ラックに2台のサーバマシンと無停電装置
- KVM仮想マシン
- 自宅の30A設定では度々ブレーカーが落ちるので、無停電電源装置で稼働率アップ
スライド p.3
- 対外活動を積極的に実施
- MongoDB→NoSQLの書籍や対外発表
- 2016/07/15 db tech showcase Tokyo 2016でも講演(発表スライド)

Hadoopについて

現在Hadoop使っている人参加者21人中5人
スライド p.6
- データベースには2種類ある
- オペレーション用途：Webシステムの裏側にあり、ランダムにクエリが掛かる
- 分析用途：オペレーション用途DBやCSVデータを夜間バッチで取り込み、BIツールで検索する
- 「ビッグデータ」はどちらの文脈でも当てはまるが、今回は分析用途のデータベースの文脈でビッグデータを説明する
スライド p.7
- データベースの性能拡張方式にはスケールアップとスケールアウトがある
スライド p.8, 9
- スケールアップ、スケールアウトと用途を二軸の平面に取ったイメージ
- Hadoopは分析用途かつスケールアウト型なので右上に位置する
- 画面左側半分は、業務用途のもの、代表的なものは左下の業務用RDB
- Amazon DynamoはKVSではあるが、ゲームのインフラのように、細かいデータをどんどん随時処理するので、左上OLTP系寄り
- 画面右側はデータ分析用途、大量のデータをバッチ等で処理する
- スケールアウトしないものはアプライアンス系、例えばExadata等
- HadoopやBigQueryはスケールアウト型、代わりにトランザクションを無視
- KinesisやSparkはマイクロバッチとして短時間に処理を行うものの、OLTPでは無いので、左右どちらにも大きく振れない中央に位置
スライド p.10
- Hadoopとは、分散したファイルに分散処理ができる
- Hadoopはプロジェクト名
- データはファイルで持つ、RedshiftはRDB
- ファイルを格納するフェーズと、計算を行う処理は非同期
- クエリは非同期でジョブIDを返す、後でジョブIDで結果を確認する
- 処理途中でノードがダウンしても他のノードが引き継いでくれる
- 長いバッチに向けて作られている
- 下はHDFS、上はMapReduceやSpark
スライド p.11
- Hadoopはクラウドの場合、構成が異なる
- AWSの場合、HDSFではなくS3を使用する
- Googleの場合はGCSにデータを配置してCloudDataprocを使用する
- TRASUREの場合はファイルシステム不明だが、恐らくS3、prestoが使用できる

EMRの説明

スライド p.13
- AWSのサービスをそれぞれの処理に当てはめる
- OLTPはRDSやDynamoDBが担当する
- いわゆるDWHはRedshiftで担当する
- レスポンスは数秒から数分、データサイズは直近13ヶ月など
- Redshiftに対してEMRはレスポンス数十分から数時間が当たり前、全量を扱う
- 長期的なトレンド調査やSQLより難しい機械学習やグラフ演算などを行う場合はEMRを使用する
スライド p.14
- EMRの特徴について
- データはS3に格納し、EC2インスタンスとしてHadoopクラスタを立て処理を行う
- Hadoopクラスタは基本的に使い捨て
- S3にデータを保存し、DynamoにS3のメタデータを保管する
- HiveのメタストアはRDSに保管する
- Hadoopクラスタを作るのは大変だが、EMRでは1クリックで作成できる
- データはS3に保存するので、コストメリットがある
- S3に保存されたデータは他のサービスへ使いまわすことができる
- 新し目なHadoopエコシステムも早く使える
スライド p.15
- 素のHadoopは計算とデータ管理(ディスク)がセット(左図)だが、EMRの場合データはS3一括管理され、ノードは計算だけを行う
スライド p.16
- 素のHadoopは計算能力を増やすためにノードを増やした場合でも、ノードがデータを持っていなければ(処理対象のデータが無いので)全力が出ない
- EMRの場合はデータ移動が不要なため、使う時間だけノードを立てて不要なら削除できる
スライド p.17
- HadoopにはHadoopクライアントを使用するが、EMRはStepと呼ばれる場所にクエリを置いておく
スライド p.18
- EMRは抽象化サービスなのでVPCの外に位置する、S3も同様
- EMRを構成するHadoopクラスタはVPCのサブネット内に構成され、MultiAZにはならない
- 補足：2016年1月よりEMRをプライベートサブネットで起動できるようになっています
- 参考：プライベートサブネットでAmazon EMRクラスタを起動する
- S3へのアクセスはVPC Endpointが使用できる
スライド p.19
- EMRはプログラムの投入が面倒
- マスターノードのIPが固定化できないので毎回探す必要がある
- このあたりの操作方法はAmazon流のエコシステムに乗れれば便利なのかもしれないが、オンプレと同じ考え方だと不便
スライド p.20
- S3にデータを格納するため、そのI/Oの時間分処理速度が落ちる(計算処理は同じ)
- 解決策として、永続化の必要の無いデータはHDFSを使うというチューニングがあるが、これが必要になった場面はまだない
- ローカルHDFSをS3にした場合、1ノードの時には3倍から5倍の時間が掛かった
- 頻繁に読み書きが発生する場合は速度差はより顕著になるだろう
- 書き込みデータが多い場合は明らかに遅い
- re:Inventで発表したNetflixの報告では、5%〜10%ダウンとのこと
- 参考：Hadoop on SQLの性能比較
スライド p.21
- S3ではある静止点のスナップショットが取れない
- ヒューマンエラー対策が困難
- 従来のHDFSを前提と考えている人には違いを説明する必要がある

リクルートテクノロジーズでの使い方

スライド p.23, 24
- EMRをラップするサービス「Hadoop on Cloud」を作成
- 独自クライアント、ELB自動紐付け機能、クラスタ増減スケジューラを追加
- EC2からHiveが叩けたりする
スライド p.25
- リクルートのビジネスモデルはユーザと企業のマッチングを行う
- 参考：リボンモデル
- 手作業でマッチングを行うのはとても大変
- SQLでも実施できないので機械学習的な操作を行っている
スライド p.26
- Hadoop環境も条件に応じて使い分けている
- とりあえずSQLが使えれば十分な場合はTresureData
- キャパシティが読めない場合はEMR
- 最新技術を使いたい場合はHortonworksなど
スライド p.27
- マッチングやユーザの属性推定などを夜間バッチで行っている
- 日中は少しのリソースでいいが、マッチングの施策のレベルによって必要な台数が異なり読めないのでEMRを使用している

最後に、EMR使っている人の確認がありましたが、参加者25名中6名でした。

docomoのRedshiftの使わせ方（×使い方）

次の発表は、NTTドコモで運用されている超巨大データベースのお話でした。

event-report-bigdata-jaws-1-02

資料ダウンロードはこちら

発表者：伊吹　勇郎(NTTドコモサービスイノベーション部　ビッグデータ担当)
概要：多くの場合、セキュリティと利便性は相反するものと言われる。
ドコモのルールを守りながら、利便性をなるべく下げないようにするために行った涙ぐましい努力を紹介する。

自己紹介

スライド p.2
- ビッグデータ部門には、分析する側と基盤側の2チームある(伊吹さんは基盤側)
- ビッグデータ統合分析環境"IDAP"の開発、運用を担当
- IDAPは「いっぱい　でーた　あつめる　プラットフォーム」
- 他、ビッグデータ処理基盤の調査・活用推進を担当

システムの紹介

スライド p.3
- IDAPはAWS Summit 2014で江藤さんが発表された業務分析系システム
- 社内で開発〜運用を実施している
- スライド右下はIDAPのロゴ、これを発表スライドに使うことでIDAPの知名度向上を狙う
スライド p.4
- ds2.8xlargeを125ノード使用している
- 分析者はJDBC、ODBCを使って任意のクエリを直接実行している
スライド p.5
- スライド左上がドコモのデータセンター
- 各種ドコモのサービスやシステムからデータを洗ってくる
- すべてクライアントサイドで暗号化している
- 暗号化されたデータはRedshiftに入る時点で復号化されているが、クライアントを利用するためには生体認証装置などを使用して安全性を保っている
- スライド中央上のEC2インスタンス(Fowarder)でデータをS3にアップロード
- 別のEC2インスタンス(Loader)でRedshiftにデータをロードしている
- ロード状況はステータス管理用のデータベース(スライド中央のRDS)に記録している
- スライド左下のクライアントから任意のSQLを発行する
- スライド右下は、外部サービス向けのS3バケットにデータを入れる
- 最近EMRも使い始めた(スライド右上)
- 使用していないユーザは定期的に確認して削除している
- データを集めることで価値を見出す為、クラスタは分けていない
スライド p.6
- ユーザからはめちゃくちゃ速いDBとして見える
- Redshiftで集計したデータは別途オンプレシステムでPythonやRで分析している
- EMRも使用している
スライド p.7
- 導入のメリットはとにかく「速い！」こと
- 2007年導入Netezza Mustang(数百TB規模)
  → Greenplum(1.4TBx2) + Redshift
- 対Greenplumで2〜3倍の比でない速さがある
- Netezzaは当時大きいクラスタを作りにくい
- Netezzaは現在H/W処理をやめており、ソフトウェア処理に変わっている
- 古くから大量のデータをS3に置いていたので、システム全体の整合性などを考慮するとRedshiftが最適
- データの統合は終日外部システムのタイミングで行われている(一括ではない)
- 基本的にはINSERTだけ実施
- 自分のスキーマにテーブルを作ることはできるが、元テーブルのデータは変更できない

課題と対策

スライド p.8
- セキュリティとユーザ数増大の課題が発生した

セキュリティ

スライド p.9
- 外部犯を気にした上で、内部の人間の犯行を気にする
- 基本的に性悪説に基づいて対策を行う
- 業務上必要ないデータを参照できないようにする
- データを勝手に持ち込んだり持ち出せないようにする
スライド p.10
- 以下3つの設定を行った
- データベースのアクセス権限設定
- システムテーブル権限制御
- UNLOAD制御
スライド p.11
- サービスごとにスキーマを作成する
- スキーマの参照権限をグループに与える
- これによって、特定ユーザは特定スキーマのテーブルのみ参照できるようになる
- また、自身のスキーマには操作権限が与えられるので、自身のスキーマ内ならテーブルの作成も可能
- それぞれのユーザの参照権限の範囲は各部門で決定してもらい、実装はRedshiftの管理者へ依頼している
- アクセスログはRedshiftがデフォルトで持つ機能を利用している
スライド p.12
- システムテーブルの権限をすべて削除している
スライド p.13
- 対策として、システムテーブルを使ったViewを作成し、ユーザが自分でテーブル情報等を確認できるようにした
スライド p.14
- テーブル参照を行えるようにするビューの例
スライド p.15
- UNLOADコマンドの中に別途作成したAWSアカウントのクレデンシャルを記述すると、任意のS3バケットにデータをUNLOADできてしまう
- これを防止するため、ユーザにはUNLOADの権限を与えていない
スライド p.16
- 代わりに、S3出力用のproxyを用意した
- 他に、EMR用のスクリプトをS3に置くProxyや、Redshiftへのデータコピー用Proxyも作成した

ユーザ数増大

スライド p.17
- 他に、以下の様々な問題が発生した
- テーブル数/スキーマ数枯渇問題
- へたくそクエリ問題
- CTAS問題
- UDF問題
スライド p.18
- クラスタごとに作成できるテーブル数が9900
- クラスタごとに作成できるスキーマが256
- Greenplumでは、1人で5万テーブルを使っている例があった
スライド p.19
- ユーザにはViewやTemp tableでの対応でも処理はできることを通知、徹底化した
- ユーザ毎のテーブル数を随時SQLで監視し、テーブルを沢山保有するユーザに注意を喚起している
- スキーマ数に関しては現時点で不要なものを積極的に消す以外に対策が無い
スライド p.20
- 利用ユーザが増えると、初めてSQL使う人があまり良くないクエリを発行してしまう
- 例えば、集約しない状態のデータを出力させたり、等
- すると、Disk Fullなどの状況や、他ユーザのクエリが妨害される等の悪影響が発生する
- 状況改善のためにクラスタを再起動させると、Temp tableが消えてしまう
スライド p.21
- 長時間実行されているクエリの抽出をしている
- 悪いSQLを記述しているユーザには、直接指摘している
スライド p.22
- その他の問題
- CREATE TABLE AS SELECT(CTAS)でテーブルを作成する際に圧縮オプションをつけないと、テーブル容量が肥大化してしまい、Disk Fullの原因となっている
スライド p.23
- 対策として、先に圧縮オプション付きのCREATE TABLEを実行し、INSERT SELECTを実施することを推奨しているが、実際には守られていない
スライド p.24
- UDF(ユーザ定義関数)はデフォルトの最適化オプション設定がVOLATILEの為、負荷が高くなることで勝手にクラスタが再起動してしまう状況が発生した
- 対策として、IMMUTABLEを設定した
- そもそも、現在のユースケースとして問い合わせ毎にUDFの実行結果が異なることは起きにくい
スライド p.25
- その他気にするべきこと
- カラムナーデータベースなので、必要な列だけ選択する
- 基本的に週に1回再起動するので、それを前提にSQL発行を考える
- ショートクエリもコンパイルして配布する形式を取っているので、ロングクエリと同じくらいの時間が掛かることがある
- DistkeyとSortkeyの設定をきちんとしないと、ノードにデータが偏ることがある
- AWSのSAさんに相談する

まとめ

スライド p.26
- 125ノードだと爆速
- ノードが落ちることはあり、クラスタ全体の再起動が発生していた
- 同時クエリ実行数を16にしていて、キュー待ちは起きていない
- 希望があれば、それに沿った内容で発表可能
- docomo cloud packageとしてノウハウを展開しているので連絡ください