ClouderaDirectorを使ったクラウドマルチHadoopクラスタの設計
はじめに
F.O.X事業で、ビッグデータ、インフラ全般、SRE的な事をやってる茂木(@tkmoteki)です。 CyberAgent Developers Advent Calendar 2016 21日目の記事です。昨日は @matsuokah さんのImeFragmentというライブラリを公開しました！キーボード開発でもFragmentを使う！でした。
CyberZ公式エンジニアブログでは、ちょうど1年ほど前にオンプレミス環境のHadoopクラスタ全台のメジャーアップグレードについて書きました。
今回は、オンプレミス環境のHadoopクラスタを、クラウド上にCloudera Directorを使って再設計をする話です。
- 背景
- オンプレミス環境以外でのHadoop
- Cloudera DirectorとCloudera Manager,クラウド上でのHadoop利用について
- インフラ構成
- Cloudera Director環境にすることでの課題解決と残課題
背景
F.O.Xのオンプレミス環境では、物理サーバ上で動くHadoopが3クラスタあります。 この3クラスタ 構築した時期がバラバラで、F.O.Xプロダクト中の開発チームが、1つのクラスタを相乗りして使い、Hadoop管理者を中心に運用を行っています。 ざっくりですが、以下のような構成になっています。
フロントサーバからの各種ログをHadoopクラスタへ送り、集計を行ったり、分析を行ったりしています。 台数として、68台、全データで900TBくらいで、HadoopクラスタにはCDHディストリビューションを使い、Cloudera ManagerでHadoopの運用/管理を行っています。
これらのHadoopクラスタで、以下のような、運用面や体制面の課題から、オンプレミス環境からクラウド環境へ移行することになりました。
- (1) 障害対応や増設等で、全体としてリードタイム大きい。専任インフラエンジニアの作業負荷が高い
- (2) Hadoopに運用知見があまりないそれぞれのチームの開発者は、Hadoopクラスタを運用しにくい
- (3) 本番環境と同等の検証環境を容易につくれない
オンプレミス環境以外でのHadoop
オンプレミス環境以外でのHadoopは、たくさんの選択技あります。 例えば、以下あたりです。
- パブリッククラウド
- マネージドサービス
- Treasure Data
パブリッククラウドのAWSや、CDHディストリビューション、ClouderaManager等の既存ナレッジが活かせ、Hadoopクラスタの構築をしなくて済む(自動構築してくれる)
Cloudera Directorを使った環境が良いかもね〜っということになり、設計と検証することにしました。
※ Treasure DataのようなHadoopマネージドサービスも検討したのですが、使いたいHadoopエコシステムが使えない等あったため、見送りました。
Cloudera DirectorとCloudera Manager,クラウド上でのHadoop利用について
Cloudera DirectorとCloudera Manager
Cloudera Directorは、クラウドIaaSレイヤーとCloudera Manager、Hadoop(CDH)クラスタのプロビジョニングを自動で行うCloudera社の製品です。
クロスクラウド、クロスアカウント、クロスリージョンを想定した使い方ができます。 大きくの3つの動作モード(Cloudera Director Serverスタンダローン、Cloudera Director Clientスタンダローン、Cloudera Director Server + Client)があり、挙動が若干異なります。なお、Hadoopエコシステムの運用/管理は、Cloudera Managerで行います。 詳しくは、以下あたりを参照してください。
Cloudera DirectorとEMRの比較検証結果
僕の方でもCloudera Directorを検証したので、簡単に比較結果を記載しておきます。せっかくなんで、AWS上のサービスEMRも載せておきます。 それぞれ現時点での最新版です。Cloudera Director2.2, Cloudera Manager5.9, CDH5.9, Amazon EMR 5.2.0。
CD・・・ClouderaDirector略、 ○ :出来る、△ :出来るけど別の仕組みを連携させるなどちょい負荷、☓ :出来ない、- :比較外 (ざっくりなんでご了承を)
| 項目/比較対象 | CD Serverスタンダローン | CD Clientスタンダローン | CD Server + CD Client | EMR |
|---|---|---|---|---|
| クロスクラウド | △ | ☓ | ○ | ☓ |
| クロスアカウント | ○ | ☓ | ○ | - |
| クロスリージョン | ○ | ☓ | ○ | - |
| マルチAZ | ○ | ○ | ○ | ☓ |
| 管理ユーザインターフェース | GUI | CLI | GUI+CLI | WebUI/aws-cli/API |
| IaaSプロビジョニングの方法 | WebUI/API | confファイル | WebUI/API/confファイル | GUI+CLI |
| インスタンス(タイプ、数選択) | ○ | ○ | ○ | ○ |
| spotインスタンス | ○ | ○ | ○ | ○ |
| ディスクオプション(EBStype、数選択) | ○ | ○ | ○ | ○ |
| 構成管理(IaaS) | △ | ○ | ○ | △ |
| カスタムAMI | ○ | ○ | ○ | ☓ |
| master-node(NN,RM)のHA | ○ | ○ | ○ | ☓ |
| AutoScaling | ☓ | ☓ | ☓ | ○ |
| AutoHealing(slave-node) | ☓ | ☓ | ☓ | ○ |
| クラスタのBlueGreenDeployment | ○ | ○ | ○ | ○ |
| Hadoopクラスタ基本料金 | プロビジョニング対象 | プロビジョニング対象 | プロビジョニング対象 | プロビジョニング対象+EMR利用料金 |
Cloudera Directorは柔軟な使い方ができ、組織やチームの、様々な運用モデルに簡単にハマりそうです。
今回の実現したい事としては、以下のようなものでした。
- 複数のAWSアカウントを持つ
- 中央の親アカウントは、インフラチームのみがクラウドIaaSレイヤーの構築/運用の権限持つ
- 他のAWS子アカウントは、それぞれの開発チームで分けて、その開発エンジニアサイドにもIaaSの構築/運用の権限を付与
- Hadoopエコシステムの運用/管理は開発チームのエンジニアが担当する
- 全体として横断してみるHadoopファシリテータがいる
なので、F.O.Xでも使えそうです。
クラウド上でのHadoop利用について
大きく2つの方法があります。 EC2のストレージEBSにデータを保存する方法と、EC2を計算リソースとして扱いストレージレイヤーをEC2から切り離しS3を使用する方法です。
一時的なHadoopクラスタを動的生成/破棄させたり、マルチHadoopクラスタで一部データを共有したい場合、必然的に後者となります。
他にも、一時的にhdfsテーブルを使って、EC2のストレージに一部ロードしてくる方法もありますが、上記のような場合、運用/管理が複雑化してくることもあり、シンプルな設計となる完全なS3テーブルでの利用を想定することにしました。
インフラ構成
インフラ全体構成
クロスアカウント、クロスリージョン、マルチAZを考慮したCloudera DirectorとCloudera Manager,Hadoop(CDH)クラスタとそのデータストアの構成です。 Cloudera Director2.2とCloudera Manager5.9, CDH5.9を使用しています。
それぞれのAWSアカウントや、ネットワークに対して、1つのCloudera Director Clientを配置し、Cloudera Director Server + Clientのremoteモードで実行し、状態をCloudera Director Serverへ叩きこんで、Server上で一元管理できるようにします。 Cloudera Directorをこのような構成にしたのは、クロスアカウントやクロスクラウドだとプロビジョニングに使うDNSやアクセス情報、ネットワークの疎通等の都合上、Cloudera Director Serverスタンダローンでは、やりずらかったからです。
基本的に、1クラスタ : 1 S3バケット : 1 RDSとし、開発チームと機能(例えばETL専用クラスタなど)でマイクロクラスタへ分解します。
ここでのマイクロクラスタは、動的生成する一時的なクラスタ、long runningクラスタを含みます。
クラスタが作る中間データ等は、自身の保持するS3へR/Wの権限を付与しアクセスします。
他のクラスタが生成するデータやrawデータ等が必要なときは、それぞれのS3でRの権限を付与しアクセスします。
これらの権限は、AWS IAMで実現します。
このようにして、 Hadoopクラスタをマイクロクラスタとして分解し、 開発チーム/機能とHadoopクラスタの関係を1:1もしくは、1:多にして、オンプレミス環境のような多:1や多:多の関係をやめました。
1Hadoopクラスタの構成
前述した図の赤丸中、1Hadoopクラスタの構成です。
1クラスタ : 1VPC構成で行い、ネットワーク帯域/セキュリティグループ等のスロットリングがあるため、他クラスタ/サーバと共有させないようにします。
クラスタとS3との通信には、10G対応のEC2インスタンスを使い、VPCエンドポイント経由でS3へアクセスします。
クラスタとMetaStoreDBとの通信は、DB全般の専用VPCを定義して切り出して、クラスタのVPCとpeeringを行い、相互接続なメッシュなpeering環境を撤廃しつつ、クロスアカウントに備えます。
クラスタ内では、Multi-AZで設計し、EC2 placement groupや、SR-IOV、RPS/RFS/XPS対応しておき、サーバネットワークのレイテンシを最小にしました。
これにより、オンプレミス環境のHadoopのデータ読み込みとクラウド環境のHadoopのデータ読み込みがほぼ同一レベルとなりました。
さらに、オンプレミス環境の巨大なHadoopのeast-westなネットワーク通信に対応するコストが最小化できました。
なお、Hadoopのロールに関しては、オンプレミス環境を踏襲しています。
Cloudera Director環境にすることでの課題解決と残課題
課題解決
背景であげた課題にたいする解決はこのようになりました。
(1) 障害対応や増設等で、全体としてリードタイム大きい。専任インフラエンジニアの作業負荷が高い
クラウドなため、必要な時に必要なだけ使えるのでリードタイムが低い。また開発者自身でインフラの増設が可能となり、インフラエンジニアの作業負荷を少なくでき、事業開発のスピードをあげられた。
YARNのDynamic Resource Pool等を使わずにマイクロHadoopクラスタで行い、他開発チームとの競合が発生せず、Hadoopのリソース戦略がより簡素化された。複数チームの相乗りクラスタとしてないため、Hadoop運用管理者の作業負荷を少なくできた。
(3) 本番環境と同等の検証環境を容易につくれない
クラウドとCloudera Directorで、検証したい時に、本番環境のHadoopクラスタと同等構成の一時Hadoopクラスタを動的生成して検証できるようになった。バージョンアップ等の検証や、バージョン違いのHadoopエコシステムの検証が簡単にできるようになった。また、SPOTインスタンスを効率活用する事により、金額的な費用も抑える事ができた。
残課題
Cloudera Directorの課題ではないものが多いですが、S3を使ったHadoopクラスタの課題も見つかったので、列挙しておきます。 経緯や詳細については、長くなるので、また次回にでも記載しようと思います。
- CDH5.8以前でのwrite heavyなHiveクエリの性能劣化(EMRと比較)
- ※ CDH5.9にてパッチがあたり改良されたようです
- S3テーブルを使用時のMetaStoreのリペアテーブルの動作が遅い
- パーティションの削減を行いました
- 共有マルチHadoopクラスタでのHiveバージョン違いによるMetaStoreDB不整合
- 基本1クラスタ1RDSとし、時間がかかるリペアテーブルには、RDSレプリカ等で対応する
- CDHクラスタと別のディスとリービューションのクラスタを混在させる場合のS3プロトコルの対応関係
- 基本1クラスタ1RDSとする
- S3のコンシステンシー問題
- externalエンドポイント,S3Guard等ありますが、試してません
- S3のスロットリング問題
最後に
Cloudera Directorや、クラウドでのHadoop利用(特にS3を使った利用)は、なかなかWebでも情報が少なく、けっこう手探りで、試行錯誤を重ねて、重ねて、検証を行いました。 長くなるので、詳細な手順や記載をすることができず、別の機会とかでトピックごとに詳細でも書こうかなぁとか思ってます、、 検証を行うにあたり、いろいろな場で、Cloudera社の方々に多大なアドバイスと協力をいただきました。ありがとうございました。
明日のCyberAgent Developers Advent Calendar 2016は @arumani さんです。
