モバイル広告という、難度の高いサービスを展開する会社が、データ活用プラットフォームをRDBMSからHadoopに置き替えるまでの実録とハウツーを紹介します。
本連載の第1回目ではCyberZの広告効果計測ツールF.O.Xの概要とClouderaManager(以後、CM)の導入経緯についてお話しました。第2回目となる今回はいよいよCM自身の導入手順とCMを使ったHadoopクラスター構築について解説します。
まず、今回使うHadoopエコシステムやクラスター・ハードウェア構成の説明をなるべくオープン紹介しておきましょう。
前回解説したようにHadoopディストリビューションはClouderaのCDH(Cloudera Distributed Hadoop)を利用します。CDHのバージョンは4.4.0、CMのバージョンは4.7.3、サーバーOSはCentOS 6.4で構成しています。
利用するHadoopシステムは、HDFS、MapReduce(v1)、Hadoop Hive、Hueと、一般的なものです。
ハードウェアについては、実行するバッチ処理がCPUバウンドかI/Oや容量バウンドのものかによって、CPUのコア数とハードディスクの容量や本数の比率を変えて選定します。
当社では今後のワークロードとして、インデキシングやグルーピングなどのI/Oバウンド処理と、広範囲の集計処理や複雑なマイニング処理などの、CPUバウンド処理のどちらも想定されていたので、バランスを重視した構成を採っています。
具体的にはIBMのx/Seriesをマスター/スレーブで配置しています。
マスターサーバーはx3530M4で、1CPU(12コア)、メモリ64GB、ディスクは1TBを4本でRAID10で組んでいます。スレーブ側はx3630M4で、2CPU(24コア)、メモリ96GB、ディスクはHadoopで使うストレージ領域として2TBを12本のHDDでJBOD構成とし、OS領域として300GBを2本でRAID1で組みました。
Hadoop環境では、スレーブサーバーがリソース不足になった場合、高いスケーラビリティが求められます。この時、インフラ面では電力やラックの利用効率も考慮する必要があります。
今回のスレーブサーバーで利用したx3630M4は、1ノード当たりCPU24コア、ディスク24TB、96GBメモリのリソースを担保して、最大消費電力が367Wとなり、他のベンダーの同規模のサーバーと比較して非常に電力効率が良い値でした。この点がIBMのx/Seriesを選定した1つの理由です。
電力効率が悪く、ラックに空きがあるのにサーバーを増やせないといったことが起こると、限りあるデータセンターの資源を無駄にしてしまいます。ラック自体の費用は非常に大きなものですから、無駄にはできません。
スケーラブルな構成を前提としたHadoopシステムを作る場合、こういった事前の設計がとても大事になります。
CMには、ライセンス形態が2種類あります。以前は「Free Edition」と「Enterprise Edition」の2種類がありました。「Free Edition」が無償版でしたが、最大ノード数が50ノードまでであったり、サービス監視機能が無かったりと制約や機能差も多くありました。
現在は、「Standard Edition」と「Enterprise Edition」の2つがあり、無償版は「Standard Edition」です。以前とは異なり、主要な機能については、有償/無償との間でほぼ差がなくなり「Standard Edition」でも十分サービス運用が可能になります。
もちろん「Enterprise Edition」の方がハイエンドな機能が使えます。BDR(Backup and Disaster Recovery)などは、災害対策用の機能でHDFSやHiveの遠隔地へのレプリケーションも可能です。何よりもサポートが付く点が無償版とは大きく異なります。CMが有償というよりも、サポートのサブスクリプションを購入することでCMの「Enterprise Edition」が使えるといった方が分かりやすいかもしれません。率直に言うとサブスクリプションは高価ですが、開発スピードの早いHadoopの構築や運用をプロにサポートをしてもらえることは非常に価値があります。
CMのバイナリはユーザ登録をすることでダウンロード可能です。図1の「ClouderaStandard4」の欄の「Download&Install」をクリックします。
図2で必要事項を入力し「Submit」をクリックするとダウンロードが開始されます。ダウンロード手順はこれだけと、至ってシンプルです。
Copyright © ITmedia, Inc. All Rights Reserved.