Distributed computing (Apache Spark, Hadoop, Kafka, ...)のカレンダー | Advent Calendar 2019 - Qiita の 2日目(12/2)の記事になります!
インフラエンジニアのN村です。子育て中につき時短で勤務中です。
今日は、育休開け早々にGCP環境にCloudera Altus Directorを導入した時の話をします。
なぜCloudera Altus Directorを?
Cloudera Altus Directorは、AWSやGCP、AzureといったパブリッククラウドでCloudera Enterpriseクラスタ(以下、CDHクラスタ)を簡単に立ち上げられるツールです。VMインスタンスの立ち上げから、Cloudera Managerと各ロールのインストールまで担ってくれますので、ブラウザ一個でサクッとCDHクラスタを構築できます。Cloudera Altus Directorでは、一度作成したCloudera ManagerやCDHクラスタの構成をテンプレート的に流用でき、更にはWebUIを使わずにコマンドラインでも操作可能なので、再作成や量産が容易です。
オンプレ環境ではこうはいきませんよね。構築時はデータセンタにそれなりのスペックのノードを少なくても数台準備しないといけないですし、不要になった際の始末も一手間ですから。
マイクロアドではCDHクラスタを複数運用していますので、クラスタ自体のバージョンアップやコンポーネントの新バージョンなど、検証をしたい場面は多いです。気軽に検証できる環境があると重宝しそうです。
なぜGCPに?
AWS環境にCDHクラスタを構築したブログ記事はよく見かけるのですが、GCP環境はあまり見かけません。
マイクロアドではG Suiteを使っており社員全員Googleアカウントを持っているので、GCPならアカウント管理が簡単です。サクッと検証する環境にはもって来いでした。また、検証用途だけではなくビジネス部隊がすでに活用しているBigQueryとのCDH連携も今後出てくるかもしれない、という事で、今回はGCPに導入する事になりました。
前提
構築時期でのDirectorの最新バージョン6.2.0を使いました。※現在の最新は6.3.0です。
デプロイはWebUIを使って行い、今回は「社内の検証を行うためのCDHクラスタとそれを簡単に再作成するためのCloudera Altus Director」として、
asia-northeast1内でasia-northeast1-a,bゾーンにまたがって下図のように作成しました。
以下、Cloudera Altus Directorを「Director」、Cloudera Managerを「CM」と表記します。
導入ステップ
下記のようなステップで進めました。基本的にはCloudera提供のドキュメントの通りです。 docs.cloudera.com
- 手順1)GCPのプロジェクトを準備
- 手順2)GCPのアカウント周りの準備
- 手順3)Director用GCEインスタンスを作成
- 手順4)Director用GCEインスタンスにDirectorServerとClientをインストール
- 手順5)ローカルPCからSOCKSプロキシ経由でDirector画面を見る
- 手順6)DirectorおよびCM用のデータベースサーバを準備
- 手順7)Director画面からCMをデプロイ
- 手順8)Director画面からCDHクラスタをデプロイ
- 手順9)CDHクラスタの接続確認
- 手順10)DirectorのDBをMySQLに載せ替える
Directorでのデプロイ作業のなかで出てくる用語
Directorを使用する際に出てくる用語をまとめておきます。
「Environment」
CMとCDHクラスタをデプロイするためには、Director上に「Environment」を作成する必要があります。「Environment」には、Directorがデプロイしに行く先のクラウド、リージョンや使用するキーペアを設定します。この「Environment」の中にCMとCDHクラスタをデプロイします。
「Deployment」と「Cluster」
「Deployment」は配置するCMの、使用バージョンやCMが情報を保持するのに使うDBを設定します。 1つの「Deployment」で1つのCMの配置することになります。この「Deployment」の配下に「Add Cluster」をして、複数のクラスタを持つことができます。(1CMでは1クラスタ運用が推奨されていますが、必須ではありません。)
「Instance Template」
「Deployment」作成時(つまりCMインストール時)と、「Add Cluster」の時に使うインスタンスの定義を「Instance Template」として設定します。この中ではVMインスタンスのスペックやOS、ゾーンを定義します。このテンプレートは、同一「Environment」内で使用できます。
先ほどの全体像の絵では、下記のようになります。
悩んだ点
プリエンプティブルVMの使用
検証環境だからコストを抑えようと、DirectorやCMにプリエンプティブルVMを使用してしまい、ハマりました。
プリエンプティブルVMは起動後24時間以降は突然シャットダウンし、私が試した時には復帰すらして来ない事もありました。
Clouderaはクラスタのワーカーへの利用のみを推奨しています。*1
マスタやGateway、Director、CM用インスタンスに使用してしまうと検証も進みませんので注意が必要です。厄介なことに、プリエンプティブルの設定はVMインスタンス作成後の変更はできませんので全部作り直しになってしまうのです。
スペックについて
Clouderaのドキュメントを見ると、検証環境のDirectorのスペックとして、n1-standard-1以上が推奨となっています。私が試した感じでは、クラスタデプロイ時のモッサリ感が気になりました。HDFS,Hiveあたりの動作を軽く検証するための環境としては、下記のスペックが最低でも必要に思います。(当然、検証の内容によって変わって来ますが)
Clouderaのドキュメントについて
GCPに関する記述がAWSやAzureに比べ少ない印象です。情報が少なくて手を動かしながらハマることが多かったですが、AWSに関する記述を一読しておくと、GCPの構築時楽かもしれません。
実際、サービスアカウントに付与する権限については、
Creating AWS Identity and Access Management (IAM) Policies | 6.3.x | Cloudera Documentation を参考にしました。
GCP周りのドキュメントの充実は今後に期待です。
良かったこと
Directorを導入したことで、CDHクラスタを本当にサクッと構築できるようになりました。導入後半年ほどですが、
「商用環境と同じバージョンのCDHクラスタをインターン生に解放したい」「商用CDHクラスタのJVMの監視をPrometheusでやりたいけどまずは検証したい」といった事、各人の勉強用クラスタを作るなどに利用しています。近々、新バージョンのSparkの検証に利用する話も出ています。
このようにだいぶCDH検証の敷居が低くなりました。私自身も、GCPやCDHに触れ「復職後のリハビリ」と言う以上に学ぶことが多かったです。
最後に
実際の手順は、引き続き、明日のアドカレに載せます!
マイクロアドは、復帰直後の私のような人間にも新しい技術に触れる機会が満ち溢れている会社です。と言ってもスパルタ(?)ではなく、子育て中の社員への制度は充実しています。パパママエンジニアにとって働きやすい環境だと思いますので、興味をお持ちの方はぜひ門戸を叩いてみてください。
*1:現在Clouderaのドキュメントには、冒頭にこのあたりの注意が明記されていますが、私が構築した頃は確か明記されていませんでした。