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

本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点／ビジネス視点の両面から理解し、具体的に実践していくためのナレッジアーカイブです。今回は、ビッグデータ基盤の本番環境を設計するのに必要な項目を解説します。

[嶋内翔，Cloudera株式会社]

【1】クラスタ管理

　クラスタの数が決まったら、次は個別のクラスタの管理について検討していきます。ここではプライマリークラスタを対象に考慮します。

可用性

　HadoopはSPOFがないため、Hadoop自体が止まることはめったにありません。しかし、適切な設計を行わないと、十分な可用性を得ることができません。

　例えば、1つのラックにマスターサーバを3台集中させると、ラック全体のスイッチ（ToRスイッチ）がダウンしただけでクラスタ全体がアクセス不能となります。しかし、複数のラックにマスターサーバを分散していれば、ラック障害に対する耐性を得ることができます。クラスタ構築時はドキュメントを熟読してください。

性能と拡張性

　Hadoopは柔軟に拡張できるような設計になっていいます。リソースが不足しても、サーバを追加するだけで無停止で拡張できます。これを踏まえて、ここで考慮すべきはサーバ調達のリードタイムがどれくらいかを確認した上で、拡張計画の決定のしきい値を策定することです。

　例えば、月に5％のペースで容量が増えており、サーバ調達のリードタイムが2カ月であれば、余裕を持って見積もると、大体容量の80％ほどを使用した段階で発注するようにすればいいでしょう。

運用監視

　Hadoopのような分散システムを「Nagios」や「Zabbix」、あるいは「JP1」の一般的な監視ツールのみで監視するのは極めて困難です。必ずHadoopに特化した監視システムを使うようにしましょう。

バックアップ

　Hadoopは、大きく分けて以下の2つのデータを持っています。

• データ
• メタデータ

　ビッグデータという名の通り、Hadoopに保存されているデータは大量です。よって、従来のNASなどにバックアップすることはできず、バックアップ先もまたHadoopクラスタとなります。全く同じクラスタにすると大きなコストが掛かるため、以下の2通りの方法により全体のサーバ台数を減らすことができます。

• セカンダリークラスタのサーバはディスクを多めに積む代わりに、サーバ台数を減らす。これにより、セカンダリークラスタの計算処理能力は落ちるものの、コストを削減できる
• プライマリークラスタでのデータ保持期間を、例えば「直近1年間」などと決め、セカンダリークラスタを完全永続化クラスタとする。これにより、古いデータのクラスタ間冗長性はなくなるものの、全体のコストを抑えることができる

　また、メタデータのバックアップも重要です。メタデータはマスターサーバが保持していたり、RDBMS内に格納されていたりと、いくつかの場所に分散配置されています。これらを正しくバックアップするには、先述した管理ツールが持っている機能を使う方がいいでしょう。

【2】リソース管理

　ビッグデータ基盤は、複数のサーバを束ね、それらのリソースを共有して複数のアプリケーションを稼働させるシステムです。このために、束ねたリソースをどのように共有、管理していくかが重要になります。

　ただし、リソース管理が重要になってくるのは2つ目のプロジェクトが相乗りするようになってからなので、今回は説明を省略します。今後、リソース管理について設計する必要があることだけ覚えておいてください。

（後編へ続く）

　次回は、本番環境において考慮すべき4項目のうち「セキュリティ管理」と「データ管理」の項目を解説します。

筆者紹介

嶋内翔（しまうち しょう）

Cloudera株式会社所属。京都大学工学部卒業後、NECでエンタープライズOSSのSI支援業務に従事。2011年にClouderaの最初の日本人社員として入社。サポートエンジニアとして3年務めた後、セールスエンジニアとしてHadoopを中心としたビッグデータ基盤に関する豊富な経験を積む。監訳書に「Apache Sqoop クックブック」。