ビッグデータ基盤の本番環境設計──本番環境におけるクラスタ構成を考察する：「ビッグデータプロジェクト」の進め方（3）（2/3 ページ）

[嶋内翔，Cloudera株式会社]

本番環境におけるクラスタ構成

　先述の通り、Hadoopクラスタ単体では非機能要求を満たすことができないために、本番環境においては複数のクラスタで運用することが一般的です。

　初期投資の予算が膨らむために最初から以下の全クラスタを用意することは難しいかもしれませんが、最終的には以下のような構成を目指すようにしていってください（図1）。

図1　本番環境におけるクラスタ構成

プライマリークラスタ（本番クラスタ）

　プライマリークラスタ（本番クラスタ）は、業務の実行の中枢を担う、最も重要なクラスタです。どのような構成にせよ最低1つあることでしょう。

　このクラスタでは、止まってしまうとビジネスに直接支障が出るような、最もSLA（Service Level Agreement）の厳しいアプリケーションを稼働させます。

　例えば、以下の用途に使われます。

• SLAの定められたETL処理。例えば、日次バッチ処理など
• 全社員が活用するBIのダッシュボード
• リアルタイムアプリケーションのバックエンドシステム

セカンダリークラスタ

　大規模なビッグデータ基盤になると、クラスタのデータそのものを丸ごとバックアップするという運用も出てきますが、単にバックアップ用途のために大量のサーバを購入し、クラスタを構築するという手段は費用対効果があまり高くありません。

　そこで多くの企業では、セカンダリークラスタを単なるバックアップ用途だけではなく、さまざまな用途にも活用しています。例えば、データサイエンティスト用の基盤にセカンダリークラスタを活用する方法です。データサイエンティストは社内のあらゆるデータを活用しますが、彼らの書くプログラムは大小さまざまな負荷をシステムにかけるため、SLAの決まっている本番環境で稼働させることはあまり望ましくありません。その一方で、サンプルデータだけを取り出して分析しても、データサイエンティストの効率は上がりません。そこで、セカンダリークラスタをデータサイエンティスト用に活用することで、本番環境に負荷をかけることなく、新たな洞察を得るために活動できるようになります。

　もう1つは、新しいバージョンのアプリケーション用のステージングクラスタとして運用する方法です。アプリケーション開発クラスタの規模は通常、本番環境よりかなり小さいクラスタであり、いくらHadoopエコシステムの移行性が高いといっても、本番環境の大量のデータに対して処理をかけたときに何が起きるか分かりません。そこで、このセカンダリークラスタをステージングクラスタとして使うことで、本番環境と同じ環境で動作確認を行えるようになります。

　この他に、災害対策用を想定するのであれば、セカンダリークラスタはプライマリーとは別のデータセンターに設置する方がいいでしょう。

開発クラスタ

　開発用のクラスタを本番と同等規模で用意することは、予算の関係からまず不可能でしょう。しかし、1000ノードの本番クラスタに対して、10ノードの開発クラスタしか用意しないというのもリスクが高すぎます。

　この目安としては、本番環境のノード数の10分の1、100分の1……の規模のクラスタを用意するといいでしょう。例えば1000ノードの本番クラスタがあるならば、100ノードと10ノードの2つの開発クラスタを別々に用意することになります。

　なお、スペックが違うことから、ここでの性能評価は最初から諦める方がいいでしょう。性能評価はセカンダリークラスタなど、本番に近い環境で行うことにしましょう。

　一方、性能評価をする必要がないので、ほとんどの場合はVMで稼働させても問題はありません。参考までに、多くの企業は、4ノード（マスター1＋ワーカー3）程度のVM上の小規模クラスタからスタートしています。

メッセージバス、あるいはKafkaクラスタについて

　Apache Kafka（以下、Kafka）はスケーラブルな分散メッセージキューで、最近急速に普及が進んでいるHaodopエコシステムコンポーネントの1つです。

　今まではさまざまなデータソースがHadoopに直接データを書き込んでいましたが、Kafkaの登場により、データを書く側がKafkaに書いてしまえば、HadoopだけでなくSparkや他のアプリケーションからも簡単に呼び出せるようになりました。このため、現代においてはHadoopクラスタの前段にKafkaクラスタを設置することが増えてきています。

　Kafkaクラスタからプライマリークラスタ、セカンダリークラスタへ簡単にデータを投入できるので、複数クラスタの構成を見据えるのであれば、Kafkaクラスタは最初から構築しておく方がいいでしょう。可用性を持つKafkaクラスタは最小3ノードから構築可能です。

その他に必要なシステム

　エンタープライズレベルのビッグデータ基盤を構築するには、さらに幾つかのコンポーネントも必要となります。Hadoopクラスタの構築に気を取られてしまって、これらのサーバの調達を忘れてしまいがちになりますので、十分注意してください。

• データベースサーバ

　HiveのメタストアDBやHueのDBなど、Hadoopエコシステムの中にはRDBMSを必要とするコンポーネントが多数存在します。従って、耐障害性や可用性を考慮したRDBMSのサーバを用意する必要があります。小規模なクラスタのうちは1つのDBサーバで問題ないでしょうが、大規模なクラスタを構築するのであれば、クラスタごとに個別に構築する必要も出てくるでしょう。

• クラスタ管理サーバ

　詳しくは後述しますが、最近はHadoopクラスタの管理に特化した専用ソフトウェアを使って構築、運用することが一般的です。こうしたソフトウェアは管理用のサーバを必要とします。Clouderaでは管理ツールとして「Cloudera Manager」を提供しています。また、Hortonworksも「Apache Ambari」という管理ツールをサポートしています。

• Kerberosの鍵配布センター（KDC）あるいはActive Directoryサーバ

　Kerberos認証やActive Directory（以下、AD）で認証を行うのであれば、これらのサーバが外部に設置されている必要があります。

• ゲートウェイサーバ

　クラスタを構成するサーバそのものに直接ログインして操作することは、セキュリティの観点から望ましくはありません。ゲートウェイサーバを設けて、そこからクラスタと通信する方法が安全でしょう。また、負荷を考えてもクラスタ外からクライアント操作を行う方がいいでしょう。

• リポジトリサーバ、CIサーバ

　開発用のCI（Continuous Integration：継続的インテグレーション）サーバや、Mavenリポジトリ、gitリポジトリを管理するサーバも必要です。これらのサーバは多くの場合、他のシステムと共用で問題ないでしょう。

目次に戻る