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

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

» 2017年01月27日 05時00分公開

[嶋内翔，Cloudera株式会社]

連載バックナンバー

今回の主な内容

　「ビッグデータプロジェクトを始めることになった」ら、何をすればいいのか──。本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点／ビジネス視点の両面から具体的に理解し、実践していくための導入指南です。

　前回は、ビッグデータプロジェクトにおけるPoCの進め方について説明しました。今回より、複数回に分けて本番環境の構築を考察していきます。まずは、「ビッグデータ基盤を本番稼働させる上での要求」を解説します。

非機能要求から見たHadoop

　「非機能要求」から見たHadoopをおさらいしましょう。独立行政法人情報処理推進機構（以下、IPA）では、機能要求・非機能要求を以下のように定義しています（機能要件・非機能要件という名称もありますが、ここではIPAに合わせて機能要求・非機能要求という言葉で統一します）。

非機能要求とは：情報システムに対する要求には大きく分けて2つ存在する。1つは、業務実現に関する要求で、業務の機能そのものを示すことから「機能要求」と呼ばれる。例えば、「営業情報をシステム上で共有し把握したい。」「受発注情報に連動した在庫管理を行いたい。」等の要求である。もう1つは、「機能要求」以外の要求を意味する「非機能要求」と呼ばれる要求で、例えば、「システムダウン時は3時間以内に復旧して欲しい」などの要求である。システム基盤に関する要求は、主にこの「非機能要求」である。

（「非機能要求グレード利用ガイド［解説編］、情報処理推進機構、2010年」より、一部改変）

　エンタープライズにおけるシステム開発では厳しい非機能要求を満たすことが不可欠です。しかし、Hadoop以前の大規模データ基盤システムの場合、PoC（Proof of Concept：導入前実機検証）やプロトタイプでの基盤と本番用の基盤では全く異なるシステムを用いることが多く、アプリケーション側も、基盤との接続部分まで含めて再開発、テストする必要がありました。

　また、一度本番環境が稼働してしまうと、全くの同一基盤を構築するか、あるいは疑似的な別のアーキテクチャによる小規模環境を作成することでしか検証環境を用意できず、保守費だけでも莫大なコストが掛かってしまいます。

　Apache Spark（以下、Spark）やMapReduce、あるいはApache Hive（以下、Hive）やApache Impala（incubating）（以下、Impala）などのHadoopエコシステムSQLエンジンでは、仮想マシン（VM）、ローカルマシン、小規模クラスタで動作するコードはそのまま大規模クラスタで動作します。これにより、アプリケーション開発者はアーキテクチャの異なる環境で検証する必要がなく、検証環境のためだけに大規模な環境を用意する必要もなくなります。ただし、本番以外の環境が不要というわけではありません。これについては後述します。

　Hadoopは、アプリケーション側と基盤側の双方の負担を軽くしながら、エンタープライズレベルの非機能要求を満たすことが可能な基盤ともいえます。

PoCの環境と本番環境の違い

　PoCでは最低限の機能を実現すれば十分でした。しかし本番環境においては、以下のような要求を考慮する必要が出てきます。ここでは、クラスタ管理、リソース管理、セキュリティ管理、データ管理の4項目について説明します。なお、以下の説明はオンプレミス環境を想定しています。クラウド環境の差分については後述します。

Hadoop自体の持つ非機能要求特性

　Hadoopは、クラスタレベルでSPOF（Single Point of Failure：単一障害点）をなくすことで高い可用性を備えています。ここでいうクラスタレベルとは、ディスク障害、サーバ障害、そしてラック障害です。単一のサーバで稼働するソフトウェアはサーバ障害までしか考慮しないため、ラック障害の耐性を備えることは分散システムならではの特長といえるでしょう。しかし、単一クラスタではデータセンター障害への耐性がありませんので、DR（Disaster Recovery：災害復旧）などのさらなる高い可用性を必要とする場合にはシステム設計が必要です。

　性能や拡張性についてはもはや説明する必要はないでしょう。本連載の第1回目ではHadoopを、「一般的なIAサーバを並べるだけでスケールアウトできる分散処理基盤」と説明しました。CPUとメモリともに拡張性を備え、従来システム比で10倍以上の業務量、データ量の拡大、そして10年以上のデータ保管に耐えることが可能です。

　運用や保守性要求を満たすための基本機能も提供しています。例えば、クラスタ間データコピーの機能を使えばバックアップを実現することができますし、監視のためのメトリクスも詳細に提供しています。Hadoop単体では要求そのものを満たせませんが、これらの基本機能を活用した外部ツールを使うことによって実現することが一般的です。

　前述した通り、Hadoop上で動くアプリケーションの多くは高い移行性を備えています。移行性の高さという意味ではSQLが一番優れていますが、MapReduceやSparkについても、アプリケーションそのものの再設計をする必要はほとんどありません。クラスタからクラスタへの移行も可能です。Hadoopそのものが機能を提供するわけではありませんので、ここもシステム設計が必要なポイントとなります。

　基盤自体の移行性も高く、移行先を小規模クラスタから順次拡張していくことによる段階的移行もできますし、大規模データを一気に移行してしまうことも可能です。また、最近のHadoopはオンプレミス、クラウド両方の環境に対応していますので、オンプレミスからクラウドへの移行や、クラウド間移行なども行うことができます。

　また、Hadoop単体でもセキュリティの基本的な機能を備えていますが、エンタープライズレベルの要求に応えるには十分ではありません。以下にその特徴をまとめます（表1）。

表1　非機能要求とHadoop

システムアーキテクチャ

　ビッグデータ基盤の本番環境では、複数のクラスタを稼働させることが一般的です。しかし、数百台のサーバで構成されるクラスタを複数構築し、運用することは非常にコストが掛かります。ですから、プロジェクトの予算に合ったレベルで、どの程度のシステムを持てばいいのかを検討しなければいけません。本番環境の設計で考慮すべき4項目は以下の通りです。どのようなクラスタ構成を検討すべきかについては後述します。

【1】クラスタ管理

　一般的なシステムと同様に、システムの起動、停止はどのように行うのか、監視はどのように行うのかなどについて設計を行う必要があります。

　Hadoopクラスタの場合は、数十台から数百台規模のサーバを連携して稼働させますので、これらのサーバでハードウェア障害が発生した場合の入れ替え方法などについても検討が必要です。サーバやストレージの調達のためのリードタイムを確認しておき、予備の機材をどの程度確保しておくかなども検討した方がいいでしょう。耐障害性と高可用性はどのように確保するのか、バックアップとリストアはどうするのかなどについても考える必要があります。

【2】リソース管理

　Hadoopでは、複数のサーバを連携させた上で、それらのリソース（CPUやメモリ、ストレージ容量など）をユーザーやアプリケーションに配分して運用していきます。最初のリリースで細かく設計するのではなく、2つ目のプロジェクトが稼働する際にリソース配分の設計をする方がいいでしょう。

　また、クラスタ管理とも関連しますが、もしリソースが不足した場合にサーバの台数をどの程度増設するかの拡張プランも検討が必要です。この際にデータセンターの空きに余裕があるかなどを確認する必要があります。増設が厳しいのであれば、データセンターの移転も検討する必要が出てくるでしょう。あらかじめどのくらいの余裕があるかは確認しておきましょう。

【3】セキュリティ管理

　企業の事業データを扱うのですから、当然、厳しいセキュリティ要求を設けるべきです。「外部のネットワークから切り離しているから大丈夫」と言う方を見かけますが、これは非常に危険な考え方です。情報漏えいの多くは、内部犯行や権限を持つユーザーのマルウェア感染などによるものであることは最低限知っておくべきです。

【4】データ管理

　ビッグデータ基盤を構築するに当たり、最も見落とされがちなのがこのデータ設計です。

　ビッグデータ基盤では、RDBMS（リレーショナルデータベース管理システム）のようなテーブル設計と、NAS（Network Attached Storage）のようなディレクトリ設計の両方が必要となります。さらに、さまざまなデータが同居するために、このデータの意味を表すデータ、すなわちメタデータをどう管理していくかも重要となります。

　管理されていないデータは活用できず、ビッグデータ基盤の貴重なストレージリソースを食いつぶすだけになってしまいます。この第3回、第4回において最も重要な項目ですが、上記の4項目の中で、唯一IPAの非機能要求グレードの項目に当てはまらない項目でもあります。

クラウド環境では？

　オンプレミス環境と比べたクラウド環境の大きな違いは、サーバの調達が不要なこと、必要なときにすぐ新しいリソースを確保できること、不要ならば簡単にシャットダウンできることにあります。

　何より、初期投資が非常に小さく済むだけでなく、1日当たり24時間未満の短時間の運用しか想定していない場合には、大きなコスト削減も期待できるため、2016年にはクラウド環境でビッグデータ基盤を構築する企業は急増しました。

　しかし、既存のデータセンターや運用部隊を持っている大企業が大規模クラスタを構築する場合は、オンプレミスの方がまだコストが安いこと、そして、クラウド環境での運用はオンプレミスのインフラの運用とは全く異なるスキルが要求される上、エンジニアの運用スキルによって運用コストが大きく変わることは知っておくべきでしょう。

　また、多くのクラウドプラットフォームベンダーは、自社のクラウドからデータを外に出す場合は非常に高額の費用が掛かるため、一度クラウド環境でビッグデータ基盤を構築すると別プラットフォームへの移行がコスト的に難しくなる可能性があることも覚えておいてください。

　2017年1月現在、Clouderaのお客さまの約20％はクラウド環境でビッグデータ基盤を稼働させていますが、その一方で、コスト上の問題からクラウドからオンプレミスに移行するお客さまも存在します。自社のビッグデータ基盤としてクラウドを選ぶか、オンプレミスを選ぶかは慎重に検討してください。

目次に戻る

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

Hadoop＋Hive検証環境を構築してみる
Hadoop HiveはHadoop上でSQLライクなクエリ操作が可能なDWH向けのプロダクトです。SQLに近い操作が可能なため、HBaseよりもデータベースに慣れ親しんだみなさんには使い勝手がいいかもしれません。本稿ではこのHiveの使い方とレビューを行っていきます。
いまさら聞けないHadoopとテキストマイニング入門
Hadoopとは何かを解説し、実際にHadoopを使って大規模データを対象にしたテキストマイニングを行います。テキストマイニングを行うサンプルプログラムの作成を通じて、Hadoopの使い方や、どのように活用できるのかを解説します
欧米の金融業界は今、どうHadoopを活用しているか
Hadoopは、欧米の金融関連サービス業界でどう活用されているか。米Hortonworksの金融サービス業界担当ゼネラルマネージャーへのインタビューで得た情報を、2回に分けてお届けする。今回は金融業界におけるHadoopのユースケースを概観する。
Hadoop＋Embulk＋Kibanaのデータ集計基盤によるデータ可視化と集計データを活用したキーワードサジェストの仕組み
リクルートの事例を基に、大規模BtoCサービスに求められる検索基盤はどう構築されるものなのか、どんな技術が採用されているのか、運用はどうなっているのかなどについて解説する連載。今回は、ログデータの分析および可視化の基盤を構成する5つの主なOSSや集計データを活用したキーワードサジェストの事例を紹介します。
ビジネスアナリティクス、機械学習の進化とSASの新アーキテクチャ
統計解析、予測分析でリーダー的存在の米SASが、同社製品群の大部分を新アーキテクチャに移行すると、2016年4月に発表した。これを、ビジネスアナリティクスの世界全般における動向との関連で探る。
Sparkのエンタープライズ対応が「成熟」――Clouderaが宣言
HadoopディストリビューターもあらためてSparkへの注力をアピール。既に800ノード超のSparkクラスターを運用するユーザーも存在するという。
Hadoop用リアルタイムクエリエンジン Impalaのポテンシャルをレビューした
2012年10月24日に発表されたばかりのHadoop用リアルタイムクエリエンジンをいち早くレビュー。次期CDHに組み込まれる予定の新機能をどう使いこなす？
Hadoop用クエリエンジン「Impala」がついに一般公開に
「Hiveの10倍速い」クエリエンジンが一般公開に。最新の列指向データフォーマットなどにも対応している。