概 要このホワイトペーパーでは、ローカル接続ストレージ搭載の Lenovo* ThinkSystem* サーバー上で Cloudera* Enterprise を使用するリアルタイム・ストリーミング分析のリファレンス・アーキテクチャーについて説明します。 このリファレンス・アーキテクチャーは、Cloudera が提供するエンタープライズ対応機能を搭載した Apache* Hadoop* と Apache Spark* のディストリビューションである Cloudera* Enterprise 向けに最適化された事前定義済みのハードウェア・インフラストラクチャーを提供します。 また、 Lenovo 製品を使用して Cloudera* Enterprise 基盤のリアルタイム・ストリーミング分析ソリューションを導入するための、プランニング、設計上の考慮事項、 ベスト・プラクティスも提供します。 リファレンス・アーキテクチャーの詳細については、「Lenovo Big Data Validated Design for Cloudera Enterprise with Local and Decoupled SAS Storage」を参照してください。

このホワイトペーパーで説明するリファレンス・アーキテクチャーについては Lenovo とインテルが検証し、インテル、Lenovo、Cloudera が共同でこのホワイトペーパーを作成しました。

Hadoop* は、大量の構造化 / 非構造化データを高い信頼性で管理するために使用されるオープンソースのソフトウェア・フレームワークです。 Cloudera は、このテクノロジーの拡張と改善を行って、管理、セキュリティー、ガバナンス、分析など、企業の需要にも対応できるリアルタイム・ストリーミング分析の機能を提供しています。 インテル® Optane™ Solid-State Drive（インテル® Optane™ SSD）はストレージのボトルネックを解消し、より大きなデータセットをより低コストで実現できます。 アプリケーションの高速化、遅れが許されないワークロードでのトランザクション・コストの削減、 データセンターの全体的な TCO 改善を実現します。 高速、 低コスト、 不揮発性であるインテル® Optane™テクノロジーは、 プロセッサーの使用率を最大限に向上できます。 Lenovoのネットワーク ・ コンポーネントを搭載した Lenovo* ThinkSystem* サーバーに Cloudera* Enterprise を導入することで、優れたパフォーマンス、信頼性、拡張性を得られます。 リファレンス・アーキテクチャーは、エントリー構成からハイエンド構成まで対応し、ビッグデータやリアルタイム分析の使用が拡大するにつれて容易に拡張できる機能をサポートしています。

このリファレンス・アーキテクチャーは、 IT プロフェッショナル、 テクニカル・アーキテクト、 セールスエンジニア、コンサルタントを対象とし、Lenovo* ハードウェアを使用するビッグデータ・ソリューションのプランニング、設計、および実装を支援するものです。 Hadoop* のコンポーネントや機能については熟知していることを前提としています。 Hadoop* の詳細については、このホワイトペーパーの最後にある「関連資料」を参照してください。

インテル、Lenovo、Cloudera のテクノロジーに基づくリアルタイム・ストリーミング・ アーキテクチャーによって、迅速なインサイト獲得、柔軟性、俊敏性、コンプライアンス遵守の向上を 期待できます。

Lenovo のビッグデータによる、 ThinkSystem* サーバー上のリアルタイム・ ストリーミング分析向け設計の検証

ホワイトペーパー金融サービス ストリーミング分析

著 者

Ajay DholakiaLenovo ビッグデータ & AI ソリューション担当 チーフ・アーキテクト シニア・エンジニアリング・スタッフ・メンバー

Prasad VenkatacharLenovo シニア・ソリューション・プロダクト・ マネージャー

Sean GilbertCloudera パートナー ・セールス担当ディレクター

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

2

ビジネス課題2020 年には、世界中で 4,000 万 TB 以上のデータが生成されることが予測されています。 こうしたデータは、あらゆる場所から、絶え間ない奔流として押し寄せてきます。 例えば、気象情報の収集に使用されるセンサー、ソーシャル・メディアやサイトへの投稿、デジタル画像 / ビデオ、購入取引記録、携帯電話の全地球測位システム（GPS）信号などからデータが大量に流れ込みます。 これこそビッグデータであり、 その流れが止まることはありません。 これまでの組織の意思決定は、毎月のデータから取得したレポートに基づいて行われてきました。 これは、 スピードが重要ではないアーカイブされた過去のデータに対しては、 引き続き有効なアプローチです。 しかし、対応までの時間が重要なカギを握るデータの場合、大きな価値をもたらすには、数秒以内に答えが得られなくては意味がありません。

企業が競争力を維持するには、データセンターにリアルタイム・ストリーミングのマシンラーニング・アプリケーションを導入する必要があります。適切なコンテキストに基づいた分析により、金融市場、モバイルデバイス、IoT、 クリックストリーム、 商取引、 その他のソースから生成されるデータストリームの中から、隠れた価値やインサイトを取り出すことが可能になります。

しかし、どんなに導入の容易なデータストレージやデータ処理インフラストラクチャーであっても、極めて短期間でセットアップを行い、期待される価値を実現することは簡単ではありません。 スキルのあるエンジニアを何十人も雇い、何カ月もかけて、あちこちに分散するデータ管理環境をつなぎ合わせることは、非常にコストがかかります。 また、最終的に目標を達成できず落胆することも少なくありません。 さらに、データ処理インフラストラクチャーは、必要なパフォーマンスと信頼性の目標を実現するだけでなく、拡張の容易さも求められます。

ソリューションの価値91% の CIO が、 ストリーミング・データの分析は会社の収益に良い影響を与えると回答しています。 リアルタイム・ストリーミング分析のリファレンス・アーキテクチャー（概要は図 1 を参照）を使用すると、 企業は次の利点を期待できます。

• インサイト獲得と意思決定の迅速化

• 絶えず変化するビジネス状況への、素早く効果的な対応

• コンプライアンス遵守の強化

目 次

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

ビジネス課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

ソリューションの価値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

機能要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

機能以外の要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

アーキテクチャーの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

コンポーネント・モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Cloudera* Enterprise の概要 . . . . . . . . . . . . . . . . . . . . . . . . 5

ソフトウェアに関する考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . 5

CDH 5 .10 における Apache Spark* . . . . . . . . . . . . . . . . . . . 6

その他のオープンソース・コンポーネント . . . . . . . . . . . . . . . 7

運用モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

ハードウェアに関する考慮事項 . . . . . . . . . . . . . . . . . . . . . . . 8

クラスターノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

導入に関する考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

ハードウェアの最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

ソフトウェアの最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

クラスターのスケーリング構成 . . . . . . . . . . . . . . . . . . . . . . . 12

セキュリティー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

セットアップに関するその他の注意 . . . . . . . . . . . . . . . . . . . 13

部品表（BOM） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

関連資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

図1 . インテル、Lenovo、Cloudera が協働で開発した、マシンラーニングを使用して未加工データを詳細なビジネスインサイトに変えるリアルタイム・ストリーミング・アーキテクチャー

リアルタイム・ストリーミング分析とマシンラーニングで素早くインサイトを獲得

リアルタイム・ストリーミング分析• リアルタイム・ストリーム処理

• 不正取引の予測

• オンライン・クラスタリング

ETLとモデル生成• 分類モデルのトレーニング

• 交差検証とモデルの選択

• モデルの保存、導入、アーカイブ

データの取り込みと保存• ソースストリームからのデータの取り込み

• 特徴の抽出と作成

• トレーニング・データの保存

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

3

このリファレンス・アーキテクチャーは、さまざまな企業ユースケースに使用できます。

• リアルタイム・データと分析を組織のあらゆる意思決定ポイントに取り込むことで、大規模にリアルタイム・データを活用：

– 高い並行処理性能と低いレイテンシーによって、すべてのユーザーが安定してデータにアクセス可能

– Cloudera* の検索によって、組織全体にわたるデータアクセスを実現

– データに基づくアプリケーションによって、分かりやすいカスタマイズされた情報を配信

• 予測モデリングを実行してリアルタイム・データと幅広い履歴データを組み合わせ、今後起こることをより正確に予測：

– クロスセルとアップセルのチャンスについてコンバージョン率を向上

– 信用度と顧客生涯価値の予測を向上

– IoT：予測メンテナンスによりダウンタイム・コストを削減

• 大規模なネットワーク・データ・セットの中のパターンを識別することで、監視と検出を実行して企業のネットワークとデータを保護：

– 積極的なネットワーク・データの収集と監視により実現される予測メンテナンスによって、ネットワークのダウンタイムを低減

– データ収集と異常分析により Advanced Persistent Threat（APT）を識別

– Apache Spot* などの高度なサイバー ・セキュリティー ・テクノロジーと連携

その他のリファレンス、分析機能、ユースケース・コンテンツについては、Cloudera のウェブサイトを参照してください。

リアルタイム・ストリーミング分析は、幅広い業界で役に立ちます。

• 医療業界では、ビッグデータ、マシンラーニング、リアルタイム分析への取り組みが急速に進んでおり、患者の安全の監視、患者の治療成果のパーソナライズ、臨床的リスクの評価、患者の再入院リスクの低減に役立っています。 これらすべてが、 組織の効率と患者の療養環境の向上に貢献します。

• 輸送業界は急激な変化に直面しています。 自動運転車、 先進運転支援システム、IoT によって、輸送に関するデータセットの量が急増しています。 さらに、 都市部への人口集中が進み、 交通密度も増加しています。 エッジデバイスからのデータをリアルタイム・ストリーミング分析することにより、車の速度や移動時間、最適なルートを予測し、交通密度を管理できます。

• 世界各地の実店舗に加え、 オンラインストアも展開している最近の小売企業は、 リアルタイムでの在庫追跡の困難さに直面しています。一元化されたスケーラブルなリポジトリーに基づくリアルタイム・ストリーミング分析により、 業務効率が向上するだけでなく、 売上高を拡大し、 トレンドに関するインサイトを発見し、 顧客満足度の向上を促進できます。

• コールセンターのログは、顧客離れを予測するための重要な情報として利用できます。 これらのログには、センサー、オンライン操作、対話型音声応答システム、IT サポートシステムからのデータを含めることができます。 このデータをデータレイクにストリーミングすることにより、企業は顧客離れを予測するモデルを作成し、顧客に関する指標やインシデントに関するインサイトを引き出すことができます。

• サイバー ・セキュリティーは、 企業が直面している最も重大な脅威の1 つです。 ますます高度化するハッカーたちは、データを盗み出すために使用できる脆弱性を絶えず探しています。Apache Spot* などのツールは、 ネットワーク・フロー、 DNS データ、 プロキシーなどのストリーミング分析を実行するマシンラーニング・モデルにより、脅威検出の促進に貢献します。

• 金融取引は、複数のソースからの連続したデータストリームで構成されています。 リアルタイム・ストリーミング分析は、このデータを集約してビジネスの健全性を向上し、 隠れたインサイトを明らかにすることができます。 さらに、以前の取引データを使用して、マシンラーニング・モデルのトレーニングを行い、不正取引を予測することが可能になります。

機能要件ビッグデータ・ソリューションは、次の主要な機能における要件に対応しています。

• バッチ分析、リアルタイム分析を含め、さまざまなワークロードを処理できること

• アプリケーションを Apache* Hadoop* エコシステムのオープンソース・プロジェクトと連携できる業界標準のインターフェイスを備えていること

• さまざまなデータタイプの大量のデータを処理できること

• さまざまなクライアント・インターフェイスを備えていること

機能以外の要件ユーザーにとってビッグデータ・ソリューションは扱いが容易で、信頼でき、 高速である必要があります。 機能以外の要件として、 次の項目が重要となります。

• 容易さ：

– 導入

– 管理規模の拡大

– 高度なジョブ管理

– マルチテナント機能

– さまざまなユーザータイプによるデータへのアクセス

• 信頼性：

– スナップショットやミラーリングによるデータ保護

– 自動障害回復

– ソフトウェア / ハードウェアの健全性と問題に関するインサイト

– 高可用性（HA）とビジネスの継続性

• 高速性：

– 優れたパフォーマンス

– 拡張性

• 安全とガバナンス：

– 強力な認証と承認

– Kerberos* のサポート

– データの機密性と完全性

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

4

• ストリーミング分析：新しい取引は、さまざまな頻度で Kafka* ブローカーから直接取得されます。 サイジングとミニバッチの間隔は、スループットとレイテンシーに関するサービス・レベル・アグリーメント（SLA）によって異なります。 例えば、20秒が適しているワークロードもあれば、1 秒ごとまたは 1 秒に数回パイプラインを処理する必要があるワークロードもあります。 リファレンス・アーキテクチャーでは、ストリーム処理に Spark* Streaming を使用します。 Spark* Streaming は、 その成熟度は別として、 Kafka* および YARN や、 CSV 解析、 Spark* ML、および Elasticsearch-Hadoop（ES-Hadoop）コネクターをサポートするライブラリーとシームレスに統合できます。 また、Spark* Streamingには広範なコミュニティーが関与しています。 ストリーミング・ワークフローでは、オンライン・クラスタリング（K 平均法）および不正検出（ロジスティック回帰とランダムフォレスト分類）アルゴリズムのパイプラインを通じてデータ処理が行われます。 取引は、最初にフィーチャー ・エンジニアリング・パイプラインを使用して処理され、その後、予測を取得するモデルに組み込まれます。 不正行為のレコードは、迅速なインデックス作成と検索のために Elasticsearch* に投入され、 長期保管のために HBase* に保存されます（代わりに Apache Cassandra* を利用することもできます）。

• データの可視化：このリファレンス・アーキテクチャーでは、分析 / 可視化プラットフォームとして Kibana を使用します。 Kibana はオープンソースであり、 Elastic Stack の一部として Elasticsearch* と連携するよう設計されています。 さらに、Elastic では、セキュリティー、アラート、 監視、 レポート、 グラフの機能がバンドルされた、 エンタープライズ向けの X-Pack 拡張機能も提供しています。

アーキテクチャーの概要インテル、 Lenovo、 Cloudera は、 シリコンおよびソフトウェアのイノベーションを利用して、リアルタイム・ストリーミング分析向けのリファレンス・アーキテクチャーを作成しています（図 2 を参照）。 この図では、データの取り込み、 分析、 データの可視化など、 一般的な活動のカテゴリーを示すとともに、ノードのタイプも示しています。 各ノードタイプは、複数のタイプの活動にまたがっている場合があります。 これらのノードタイプを構成する方法については、表 2 を参照してください。

このリファレンス・アーキテクチャーでは、複数のコンポーネントを使用してワークフローを実現します。

• データの取り込み ： 過去の取引はバッチ分析のために Hadoop* Distributed File System （HDFS*） に保存され、 ウェブ、 スマートフォン、カードリーダーからのリアルタイム・データは Apache Kafka*にストリーミングされます。 レコードは CSV 文字列で、 シリアル化とSnappy 圧縮には Apache Avro* を使用できます。 安全な実装を実現するためには、 Kerberos* による認証に加え、 パイプラインの各ステージで暗号化を追加できます。 ロギングと監視は、Elasticsearch*、Kibana、Logstash など、Elastic のツールを使用して行われます。

• バッチ分析：リファレンス・アーキテクチャーでは、Oozie* および HDFS*とともに Apache Spark* と YARN を使用して、 フィーチャー ・エンジニアリングを実行します。 このタスクには、 重複の削除または非定型レコードのフィルタリング、 特徴データの欠損値補完とビン分割、さらには集計を使用した属性の生成が含まれます。 seaborn またはmatplotlib を使用して、特徴の相関関係を視覚化できます。 すべての特徴が作成された後には、 マシンラーニング・アルゴリズムをトレーニングするための特徴ベクトルが作成されます。 監査およびストリーミング・パイプラインでの再利用のために、マシンラーニング・パイプライン全体がパッケージ化され、保存されます。

データソース

ゲートウェイ

Hadoop* の Cloudera* ディストリビューション

Red Hat* Enterprise Linux*

インテル® Xeon® プロセッサー搭載 Lenovo* ThinkSystem*

データの可視化

監視とアラートKibana

インサイトとトレンドの集約

Tableau*

ストリーミング取り込みKafka*

バッチ取り込みHDFS*

ロギングと監視

データの取り込み

Elasticsearch*

HDFS*

HBase*（オプション）

保存

ストリーミングSpark*、YARN

バッチSpark*、YARN

バッチOozie*

分析

データ処理/マシンラーニング・ノード

ストリーム取り込み/検索ノード

データ供給/長期保管ノード

ユーザー・インターフェイス/管理ノード

図 2 . リアルタイム・ストリーミング分析のスタック

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

5

インテル、Red Hat、Cloudera のコラボレーションで生まれるプラットフォームは、以下を実現するよう構築されています。

• 暗号化 / 復号のハードウェア・オフロード、OS レベルのセキュリティー、RHEL および Security Enhanced Linux*（SELinux）での ID 管理による階層化セキュリティー

• クラスター環境およびインテル® コンポーネント向けのドライバー、ライブラリー、拡張機能の組み合わせによるパフォーマンスの最適化

• RHEL OpenStack* プラットフォームによる簡素化された使いやすさとシームレスな運用管理

ライブラリー• Snappy 圧縮：中間圧縮を可能にすることで、 アプリケーションを変

更することなく、ジョブの実行を高速化できます。 パブリッシャーからKafka* ブローカーに送信されるデータ、 および Hadoop* によってシャッフルフェーズ向けに作成される一時的な中間ファイルには圧縮のメリットがあります。 最終出力は圧縮することも非圧縮とすることもできます。 Snappy は、Gzip などのほかの圧縮アルゴリズムに比べて圧縮 / 解凍が非常に速いので、このようなケースに最適です。

• マシンラーニングの高速化：インテル® マス・カーネル・ライブラリー（インテル® MKL）は、インテル® プロセッサー専用に最適化された、数値演算ルーチンのライブラリーです。 例えば、線形代数、高速フーリエ変換（FFT）、ベクトル演算、統計関数用の高度に最適化されたルーチンが含まれています。 これらの数学演算はマシンラーニングや関連する分析アルゴリズムのためのビルディング・ブロックであり、 インテル® MKL との統合によって、 マシンラーニング・ワークロードのパフォーマンスを大幅に向上することができます。 Spark* はすでに netlib-java を使用してこれらのルーチンの最適化実装を利用するよう構成されていますが、 これらの最適化を有効化するには、 インテル® MKLのような実装の追加が引き続き必要となります。 このパフォーマンス向上の利点は明白です。 パフォーマンスが向上すれば、より大規模なデータセットでのトレーニング、より広い範囲のモデル・ハイパーパラメーター空間の探索、 より多くのモデルのトレーニングを行うことができます。 これによって、多くの場合、専門のハードウェアをマシンラーニング・ワークロード用に購入する必要が軽減されます。 パフォーマンスの向上は、個々のアルゴリズムでさまざまに変化し、ビジネスやデータサイエンスのユースケースによって異なります。

コンポーネント・モデル

Cloudera* Enterprise の概要Cloudera* Enterprise（図 3 を参照）は、金融サービス、小売、メディア、医療、 製造、 通信、 政府機関、 および Fortune 100/Web 2 .0 の主要企業など、さまざまな業界でミッション・クリティカルなリアルタイムのビッグデータ分析をサポートしています。

Cloudera* Enterprise には、次のコンポーネントが含まれています。

• 分析 SQL：Apache Impala*

• 検索エンジン：Cloudera* Search

• NoSQL*：HBase*

• ストリーム処理：Spark*

• マシンラーニング：Spark* MLlib

• Cloudera* Manager と関連サービス

• Cloudera* Navigator

• Cloudera* Kafka*

詳細については、 Lenovo Big Data Validated Design for Cloudera Enterprise with Local and Decoupled SAS Storage を参照してください。

Cloudera* ソリューションは OS に依存しません。 Cloudera は、 Red Hat* Enterprise Linux*、SUSE Linux* など、さまざまな Linux* オペレーティング・システムに対応しています。 対応オペレーティング・システムのバージョンについては、 http://www .cloudera .com/documentation/enterprise/release-notes .html（英語）を参照してください。

ソフトウェアに関する考慮事項OSリファレンス ・ アーキテクチャーは、 Red Hat* Enterprise Linux*（RHEL）7 .3 の導入に基づいています。 ユーザーは、最新の公式パッチをすべての導入ノードに確実にインストールし、 必要なアップグレードがあれば、インストールの開始前に実施しておく必要があります。

処理、分析、供給

統合サービス

バッチSqoop*

リアルタイムKafka*、Flume*

ファイルシステムHDFS*

リレーショナルKudu*

その他Object Store*

NoSQLHBase*

バッチSpark*、Hive*、Pig*、MapReduce

SQL Impala*

ストリームSpark*

検索 Solr*

SDKKite

リソース管理YARN

セキュリティーSentry*、RecordService

保 存

統 合

運 用Cloudera* ManagerCloudera* Director

データ管理Cloudera* NavigatorEncrypt、Key Trustee

Optimizer

図 3 . Cloudera* Enterprise の主な機能

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

6

CDH 5 .10 における Apache Spark*Spark* は近年、 幅広く普及しており、 さまざまなビッグデータ・ユースケースの推奨フレームワークとして採用されています。 そのユースケースは、 クリックストリームなどのデータソースで MapReduce またはSpark* を使用するバッチ・アプリケーションから、センサーデータを使用するリアルタイム・アプリケーションまで多岐にわたっています。図5に、Spark* スタックを示します。 図に示したように、基盤コンポーネントはSpark* Core です。 Spark* は、Scala プログラミング言語で記述されており、Python*、Java*、Scala、SQL でシンプルな API を提供しています。

Spark* スタックは、Spark* Core に加えて、ライブラリーの形式で拡張が可能です。 最も一般的な拡張は、 マシンラーニング用の Spark* MLlib、構造化データに対するクエリー用の Spark* SQL、リアルタイム・ストリーム処理用の Spark* Streaming、 グラフ・データベース処理用の Spark* GraphX です。 その他の拡張機能も利用可能です。 ただし、Cloudera では現在 GraphX または SparkR がサポートされていません。Spark* SQL のサポートにも注意事項があります。 詳細については、Cloudera* Spark* のガイド（英語）を参照してください。

ビッグデータ・インフラストラクチャーの大半はインテル® プロセッサーを使用して構築されていますが、 MLlib 内の実装は必ずしもインテル® アーキテクチャーに最適化されていません。 そのため、 インテル® プロセッサー搭載クラスター上での Spark* MLlib の動作を高速化することが、 多くの開発者の最優先事項となっています。 インテルが提供する一般的なマシンラーニング・アクセラレーション・ライブラリーに、インテル® MKL とインテル® データ・アナリティクス・アクセラレーション・ライブラリー（インテル® DAAL）があります。

図 5 に示す Spark* スタックは、複数のプロジェクト・タイプに対応しています。 これまでの典型的なビッグデータの使用シナリオでは、ストリーム処理用のフレームワークとは別にバッチ処理用の Hadoop* スタックを導入し、さらにマシンラーニングなどの高度な分析用に別のフレームワークを導入していました。

Cloudera* EnterpriseHadoop* の Cloudera* ディストリビューション（CDH）は、 広く普及している 100% オープンソースの Hadoop* ディストリビューションです。これには、無制限のデータについて保存、処理、ディスカバリー、モデリング、供給を行う主要な Hadoop* エコシステムのコンポーネントがすべて含まれており、 安定性と信頼性に関する企業の最高レベルの基準を満たすよう設計されています。

ユーザーは企業ネットワークから Cloudera* ソリューションにアクセスするため、 ポート 22 で Secure Shell（SSH）を使用することによってファイアウォールの外側から Cloudera* クライアントにログインできます。 CDH では、さまざまな Hadoop* コンポーネントのインストール、管理、維持を行うシームレスなセットアップが提供されます。 また、管理者やユーザーが役割やアクセスレベルに従って管理機能やデータ機能を実行できる複数のインターフェイスも提供されます。 データにアクセスするには、Hadoop* API を使用できます。 クラスターの管理と監視には、Cloudera* API を使用できます。 Cloudera のデータ、 管理、 その他のサービスは、 クラスター内のノード上で動作します。 このリファレンス・アーキテクチャーでは、 CDH のさまざまなサービスを使用しています。Spark* v2 および Kafka* v0 .10 ゲートウェイをクラスターのすべてのノードにインストールする一方で、実際のサービスホストは、ごく一部のノードにのみインストールしています。 Spark* と Kafka* の統合には、spark-streaming-kafka_0 .8モジュールを使用しています。

ストレージは、クラスター内の各データノードのコンポーネントです。 データは、顧客のニーズにより Hadoop* API またはネットワーク・ファイル・システム（NFS）経由で Cloudera* Enterprise ストレージに取り込むことができます。 Cloudera* Manager、Hive* メタストア、その他のサービス用のデータを保存するには、データベースが必要です。 Cloudera では、 テスト環境または概念実証（PoC）環境向けの組込みデータベースを提供しており、サポート可能な実稼動環境向けには外部データベースが必要です。

Elastic 製品X-Pack などの Elastic（ELK）製品は、Apache Lucene 上の拡張性に優れた分散検索フレームワークを提供します。 このフレームワークによって、大量のデータの保存とインデックス作成が行われ、データへのほぼリアルタイムのアクセスが可能になります（図 4 を参照）。 Elasticsearch* には、 CDH のコンポーネントなど、 ユーザー ・ワークフローを統合するさまざまなコネクターが付属しています。 Elasticsearch* と Hadoop* の統合によって、 ユーザーは Elasticsearch* で検索 / 分析エンジンを使用してワークフローを強化できます。 Elasticsearch* には豊富な言語が用意されているので、適切な質問で素早く明確な回答を得ることができます。

Elasticsearch* のほかにも、Kibana は視覚化を実現する統合ダッシュボード・インターフェイスを提供し、X-Pack プラグインは監視やセキュリティーをはじめ、 より詳細にデータを分析するための拡張アドオンを実現します。

Elastic Stack

Elasticsearch*保存、インデックス、分析

Logstash、Beats取り込み

Kibanaユーザー・インターフェイス

監視

アラート

セキュリティー

X-Pack

グラフ

Spark* Core

Spark* Streamingリアルタイム

MLlibマシン

ラーニングGraphXグラフ処理

Spark*スタック

Spark* SQL構造化データ

図 5 . Spark* スタック

図 4 . Elastic ソフトウェア・スタック

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

7

Spark* は、 これらのフレームワークを組み合わせて 1 つの共通アーキテクチャーにし、それによって、ビッグデータ・コード・スタックの管理を容易にするとともに、共通のデータ・リポジトリーの再利用を実現します。

Spark* には、Hadoop* MapReduce よりも優れた特長がいくつかあります。 例えば、次のような利点です。

• フォールトトレラントの分散データ構造 （RDD：Resilient Distributed Dataset）

• データ処理に利用できる多数の演算

• 使いやすさ（開発者の生産性の向上）

• さまざまなタイプのクラスターに対応

• さまざまなタイプのデータソースに容易に接続

図 5 に示した Spark* スタックは、 さまざまな環境で実行できます。Hadoop* スタックと並行して動作させることができ、クラスター管理にHadoop* YARN を活用できます。 Spark* アプリケーションは、 マスター / スレーブ・アーキテクチャーを使用して、クラスター上で分散モードとして実行できます。 このアーキテクチャーでは、 「ドライバー」と呼ばれる一元化されたコーディネーター 1 つと、Spark* ジョブ内の個々のタスクを実行する「ワーカー」プロセスを場合によっては多数使用します。Spark* エグゼキューター ・プロセスは、クラスター内のさまざまなノードに分散したデータの、 信頼性に優れたインメモリー ・ストレージも提供します。 分散 Spark* アプリケーションのコンポーネントを図 6 に示します。

Spark* の機能の中でも特に重要な機能は、RDD に基づくデータモデルです。 このモデルによって、 メインメモリーに常駐し、 複数のタスクからのアクセスが可能な、コンパクトで再利用可能なデータセットの編成を実現できます。 反復処理アルゴリズムには、この機能のおかげで演算の反復の間でディスクからのデータセットの取得と保存を行わないで済むというメリットがあり、 MapReduce に比べて大幅なパフォーマンス向上を実現できます。

RDD では、変換とアクションという 2 種類の操作がサポートされています。 変換は新しい RDD を返す操作であり、アクションは結果をドライバープログラムに返します。 Spark* は複数の操作をまとめることで、データにかけるパスの数を低減します。 この評価テクニックには、最小限の作業しかかからず、データ処理を高速化することができます。 また、Spark*では、データをメモリーにキャッシュして維持し、同一データを複数回使用することもできます。 これはデータ処理の高速化に役立つもう 1 つのテクニックです。

その他のオープンソース・コンポーネントこの章では、 Elasticsearch*、 Kibana、 その他のパッケージの詳細について説明します。

Apache Kafka*Kafka* は、リアルタイム・データ・パイプラインの構築やアプリのストリーミングに使用されます。 水平方向の拡張性に優れ、フォールトトレラントで極めて高速という特長があり、数千社もの企業で実稼動中です。 主な用途は次の 3 種類です。

• パブリッシュ / サブスクライブ：データのストリームをメッセージング・システムのように読み書きできます。

• 処理：イベントに対してリアルタイムで反応する拡張性に優れたストリーム処理アプリケーションを記述できます。

• 保存：データのストリームを、分散 / 複製されたフォールトトレラント・クラスターに安全に保存できます。

Elasticsearch* と KibanaHadoop* はバッチ処理システムとしては優れていますが、 リアルタイムでの結果の提示では、問題が生じることもあります。 真にインタラクティブなデータ・ディスカバリーのため、 ES-Hadoop では、 Hadoop* データを Elastic Stack にインデックス化して、 高速の Elasticsearch* エンジンと Kibana による可視化を最大限に利用することができます（図 7を参照）。 ES-Hadoop を使用することで、動的な組込み検索アプリケーションを構築して Hadoop* データを処理することも、 フルテキストの地理空間的クエリーや集約を使用して低レイテンシーな深い分析を実行することも容易になります。 製品のお勧めからゲノム配列決定まで、ES-Hadoop ならば、幅広いアプリケーションで新たな世界が広がります。

Spark* Streaming および Kafka* 向けの統合は、 ES-Hadoop ライブラリー ・コネクター経由で利用でき、 容易にストリーム処理アプリケーションで Elasticsearch* への読み書きを行うことができます。

エグゼキューター

タスク タスク

キャッシュ

ワーカーノード

分散Spark*アプリケーションのコンポーネント

クラスター・マネージャー

エグゼキューター

タスク タスク

キャッシュ

ワーカーノード

ドライバープログラム

SparkContext

図 6 . 分散 Spark* アプリケーションのコンポーネント・モデル

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

8

• 事前に定義された構成：事前に定義された構成は、そのまま実装することも、コスト低減、パフォーマンス向上、信頼性向上などの特定の顧客要件に基づいてカスタマイズすることも可能です。 データの増加速度、データセットのサイズ、データの取り込みパターンなど、主要なワークロード要件によって、個々の導入に適切な構成を決定することができます。 Cloudera* クラスター ・インフラストラクチャーを設計する場合のベスト・プラクティスは、代表的なデータとワークロードを使用することで概念実証テストを実施して、提案された設計が機能することを確認することです。

ハードウェアに関する考慮事項ここからは、サーバー、CPU、メモリー、ストレージ、ネットワークに関連する考慮事項について説明します。

サーバー高スループットのストリーム処理のジョブは、水平方向の拡張に適しています。 コア数を増加してパフォーマンスを向上することもできます。 さらに、これらのジョブは通常、ハイパースレッディングのメリットを利用することができ、 NUMA 設計の影響をほとんど受けません。 このリファレンス ・ アーキテクチャーでは、 Lenovo* ThinkSystem* サーバーSR630 （1U） および SR650 （2U） サーバーと Lenovo* RackSwitch G8052および G8272トップ・オブ・ラック（TOR）スイッチを使用します。

CPUインテル® Xeon® プロセッサー ・スケーラブル・ファミリーは、 前世代のインテル® Xeon® プロセッサー E5-2600 v4 製品ファミリーに比べて、さらに多くの機能が追加された新しいマイクロアーキテクチャーです。追加機能には、 プロセッサー ・コアの増加、 メモリー帯域幅の増加、 非包括的キャッシュ、インテル® アドバンスト・ベクトル・エクステンション512（インテル® AVX-512）、インテル® メモリー ・プロテクション・エクステンション（インテル® MPX）、 インテル® ウルトラ・パス・インターコネクト（インテル® UPI）、Sub-NUMA クラスターがあります。

メモリーメモリー要件は、 個々のビジネス用途のキャパシティー ・プランニングによって異なります。 一般に、リアルタイム・ストリーミング・アプリケーションは、演算負荷もメモリー負荷も高いものです。 また、ノードにメモリーを追加すると、データのキャッシュに役立ち、データ量が増加したときでも、 プロセスでフラッシュやディスクからの読み出しを行う必要がなくなります。 Apache Kafka* などのキューイング ・ システムと、Cloudera* Solr、 Elasticsearch* などのインデックス作成 / 検索コンポーネントは、OS ファイルシステムのキャッシュに大きく依存しており、大容量メモリーのメリットを活用できます。 一般に、推奨メモリーは、データ / ワーカーノードで 256 GB 〜 768 GB、マスター / クライアント・ノードで 192 GB 〜 256 GB です。

運用モデルこの章では、 Cloudera* リファレンス・アーキテクチャーの運用モデルについて説明します。 さまざまな規模の顧客環境について運用モデルを示すため、3 つの異なるモデルを提示して、さまざまなデータ量に対応できます。 このホワイトペーパー全体を通して、これらのモデルを、ハーフラック、 フルラック、 マルチラックの構成サイズと呼んでいます。 マルチラックは、フルラックの 3 倍の大きさです。

以下の章では、リアルタイム ・ ストリーミング実装に関連する詳細について説明します。 サーバー ・ ハードウェア、クラスターノード、システム管理、 ネットワークの一般的な説明については、 Lenovo Big Data Validated Design for Cloudera Enterprise with Local and Decoupled SAS Storage を参照してください。

概 要Cloudera* の導入は、クラスターノード、ネットワーク機器、配電ユニット、ラックで構成されます。

• 管 理 ： こ の リ フ ァ レ ン ス ・ ア ー キ テ ク チ ャ ー で は、 シ ス テ ム 管 理（Cloudera* Manager を 使 用） と ハ ー ド ウ ェ ア 管 理 （Lenovo* XClarity* Administrator を使用）の両方を扱います。 さらに、 xCATによって、 拡張性に優れた分散コンピューティング管理とプロビジョニングのツールが提供されます。 これはハードウェア制御、検出、オペレーティング・システム導入のための統一インターフェイスです。 これを使用して、クラスターノードの管理を容易にしたり、自動化することができます。 xCAT の詳細については、このホワイトペーパーの最後にある「関連資料」を参照してください。 Cloudera* Enterprise のインストールと管理については、最新のマニュアルを参照してください。

• ネットワーク：このリファレンス・アーキテクチャーでは、データ・ネットワークと管理ネットワークの 2 つのネットワークを指定します。

– データ・ネットワークは、複数のノードでプライベート・クラスターを構成し、 ノード間の高速データ転送や、 Cloudera* クラスターへのデータのインポートに使用されます。 一般に Cloudera* クラスターは顧客の企業データ・ネットワークに接続します。 ラック間のネットワークには、クラスターごとに追加のスイッチが必要です。

– ハードウェア管理ネットワークは 1 GbE のネットワークで、 アウトオブバンドのハードウェア管理を実現します。 ThinkSystem* SR650 サーバー内の XClarity* Controller 管理モジュールにより、このアウトオブバンド・ネットワークは、ノード導入、BIOS 構成、ハードウェア障害ステータス、サーバー電力状態など、クラスターノードのハードウェア・レベルの管理を実現します。

Hive*

MapReduce

Pig*

Spark*

Storm*

Cascading

Hadoop*

Elasticsearch*とHadoop*の間でデータを効率的に移動

HDFS*でElasticsearch*をバックアップ

Elasticsearch* Kibana

ES-Hadoop

HDFS*

図 7 . Elasticsearch-Hadoop

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

9

高メモリーシステムは、 Docker* Swarm、 Kubernetes* ベースのアーキテクチャーなど、単一ノード上のコンテナー化インフラストラクチャーのサポートも実現できます。 JVM ガベージ・コレクションは、大規模データ分析に関連する最も重要な調整パラメーターの1つです。 パフォーマンスのボトルネックは通常、大容量のメモリーバッファーをワーカーとエグゼキューターに割り当てることで軽減されます。 メモリーの追加は一時的な回避策のように思われるかもしれませんが、 複数の実稼動シナリオでパフォーマンスの問題を素早く解決するためには不可欠です。

ストレージ分析ソリューションのパフォーマンスは、関連付けられているストレージの効率と信頼性に大きく依存します。 リアルタイム・ストリーム処理のフレームワークは読み取り / 書き込みのレイテンシーの影響を受けやすいため、 さまざまな種類のワークロードを着実に実行できるハイパフォーマンスのストレージ・インフラストラクチャーを使用する必要があります。 さらに、コンポーネントには、提供しようとしているスループットやレイテンシーの SLA によって、異なるストレージ要件があります。

インテルの拡張性に優れたストレージシステムなら、データの増加をビジネスチャンスに変えることができるため、導入した企業ではビジネス競争においてアドバンテージを獲得できます。 長い間 SSD がワークロードの高速化に使用されてきましたが、 NVMe* やインテル® Optane™テクノロジーなどの新しいテクノロジーによってさらに上のレベルを実現できます。 インテル® SSD DC P4500 シリーズは、 YARN シャッフルやKafka* ゲートウェイの受信データに対応する大量の順次書き込みの処理に適しています。 Elasticsearch* クエリーの低レイテンシーのニーズを考えると、トラフィックがリアルタイム・ストリーミングへと変化し、進化するにつれて、インテル® Optane™ テクノロジーによりランダム読み取り / 書き込みのワークロードを拡張することができます。

SATA ハードディスク・ドライブ（HDD）は、 アーカイブデータの保存にお勧めです。 これらのドライブは、 一般に JBOD （Just a Bunch Of Disks）アレイ構成で導入されます。 Apache* Hadoop* コンポーネントにレプリケーション、 フォールトトレランス、 高可用性の実装が内蔵されていることを考えると、RAID による価値は不要となり、オーバーヘッドのみが残るため、 JBOD は RAID よりも望ましいと判断されます。RAID 構成は RAID アレイ内で最も遅いディスクの速度によって制限されるのに対し、JBOD アレイのディスク操作は独立しており、平均として高い読み取り / 書き込みスループットを提供できます。

大規模ワークロードではドライブの推奨ファイルシステムは ext4 および xfs ですが、このリファレンス・アーキテクチャーでは、すべてのドライブを ext4 でフォーマットしてテストしています。

ネットワークビッグデータやストリーミングのソリューションには、 高帯域のネットワーク・インターフェイスが必要です。 設定が不十分なネットワークや飽和したネットワークでは、送信や受信機接続での競合に悩まされ、パケットの再送信やネットワーク・レイテンシーの問題が発生する可能性があります。 アーキテクチャー全体で少なくとも 10 GbE インターフェイスを推奨します。 25 GbE インターフェイスとイーサネット・ネットワーク・アダプターを使用すれば、最大限のパフォーマンスを実現できます。 オーバーヘッドを低減することで帯域幅の効率を向上させるには、ジャンボフレームの有効化など、追加の調整を実施する必要があります。 ただし、パフォーマンスへの影響を回避するために、ネットワーク内のすべてのデバイスをジャンボフレーム向けに設定する必要があります。

クラスターノードCloudera* リファレンス・アーキテクチャーは、1 つのクラスターを構成するノードのセットに実装されます。 Cloudera* クラスターは、ワーカーノードとマスターノードという 2 種類のノードで構成されます。 ワーカーノードはローカル接続ストレージ搭載の ThinkSystem* SR650 サーバーを使用し、マスターノードは ThinkSystem* SR630 サーバーを使用します。

ワーカーノードでは、データの保存と処理を行うデータ（ワーカー）サービスを実行します。

マスターノードでは、次のタイプのサービスを実行します。

• クラスターの調整と管理を行う管理制御サービス

• ファイルとウェブサービス用のその他およびオプションのサービス

表 1 に、どのソフトウェアがどのノードにインストールされているかを示します。 記載された役割はフルラック導入に基づきます。 より小規模な構成ではサービスが共存している場合があります。

ワーカーノード サーバーノードは、ThinkSystem* SR650 サーバー上で動作します。 このサーバーには、 OS 用の 128 GB SSD、 256 GB のベースメモリー、HDD コントローラー、および OS と HDFS* 用のハードウェア・ストレージ保護が搭載されています（Cloudera* では、クラスター内に保存されたデータについて合計 3 つのコピーを保持します。 これらのコピーは、障害復旧のため、データサーバーやラック全体に分散されます）。

表2に、各ノードタイプの推奨構成を示します。 例えば、データ処理ノードの構成は、データ供給ノードとは異なります。 図 2 は、これらのノードタイプが、分析スタックのさまざまな部分に分散している様子を示しています。

推奨のインテル® Xeon® スケーラブル・プロセッサーは、パフォーマンスとコストのバランスのとれた Cloudera* ワーカーノードを実現します。演算負荷の高いワークロードには、コア数と周波数の高いプロセッサーを利用できます。

表 1 . サービスレイアウト表

ハードウェア・コンポーネント 説明

管理ノード1Cloudera* Distribution of Hadoop* Management Services管理ノード2

管理ノード3

ユーザー ・インターフェイス・ノード Kibana/Gateway*

ストリーム取り込み + 検索1

Kafka* および Elasticsearch*ストリーム取り込み + 検索2

ストリーム取り込み + 検索3

ストリーム取り込み + 検索4

保存とデータ供給1

長期保管、HDFS*、 HBase*/Cassandra*

保存とデータ供給2

保存とデータ供給3

保存とデータ供給4

保存とデータ供給5

保存とデータ供給6

ストリーミング分析1 - ZooKeeper*Spark*（バッチ）Spark* StreamingYARNOozie*ZooKeeper* （取り込みノードに移動可能）

ストリーミング分析2 - ZooKeeper*

ストリーミング分析3 - ZooKeeper*

ストリーミング分析4

ストリーミング分析5

ストリーミング分析6

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

10

マスターノード マスターノードは HDFS* の中核であり、特に YARN、ZooKeeper* などの多数のサービスを実行することで、Cloudera* クラスター上で必要なその他の主要な機能をサポートします。 表 3 は、 マスターノードの推奨コンポーネントの一覧です。 これらは、クライアントのニーズに従ってカスタマイズできます。 Cloudera* マスターノードとして十分なパフォーマンスを提供するには、インテル® Xeon® スケーラブル・プロセッサーと最小でも図 3 で指定したメモリー容量を推奨します。

表2 . さまざまなワーカーノードの構成

説明 ハードウェア・コンポーネント ノード数 ノード当たりの数量 注

データ処理 & マシンラーニング・トレーニング / 推論（Spark*、YARN、 Spark* Streaming）

インテル® Xeon® Platinum 8168プロセッサー （24コア、2ソケット、96スレッド、ハイパースレッディング有効）

6

1

384 GB DRAM 1

2 TB SATA HDD 3.5インチ /2.5インチ 8

25 GbE/10 GbE NIC 2ポート

インテル® SSD DC P4500シリーズ4 TB 1 シャッフルの高速化

データ供給と 長期保管（HBase*/Cassandra*/HDFS*）

インテル® Xeon® Gold 6138プロセッサー（80コア）

6

1

384 GB DRAM 1

4 TB ドライブ：14x 4 TB NL SAS 3.5インチ（合計56 TB）利用可能な代替の HDD 容量： 6 TB ドライブ：14x 6 TB NL SAS 3.5インチ（合計84 TB）8 TB ドライブ：14x 8 TB NL SAS 3.5インチ（合計112 TB）10 TB ドライブ：14x 10 TB NL SAS 3.5インチ（合計140 TB）

12 ノード当たり12 TB、 SATA SSD

25 GbE/10 GbE NIC 2ポート

インテル® SSD DC P4500シリーズ4 TB 3 SATA ドライブの代替

ストリーム取り込み & 検索

インテル® Xeon® Gold 6138プロセッサー（80コア）

4

1

384 GB DRAM 1

インテル® Optane™ SSD DC P4800X シリーズ375 GB 1 Elasticsearch*

インテル® SSD DC P4500シリーズ4 TB 1 Kafka*

25 GbE/10 GbE NIC 2ポート

インテル® SSD DC P4500シリーズ4 TB 1 代替の Elasticsearch* 用SSD

ユーザー ・インターフェイス & 管理

インテル® Xeon® Gold 5118プロセッサー（12コア）

3

1Cloudera* Distribution of Hadoop* Management Services と Kibana

192 GB DRAM 1

インテル® SSD DC D3600シリーズ1 TB 2 SATA SSD

25 GbE/10 GbE NIC 2ポート

表3 . マスターノードの構成

コンポーネント マスターノードの構成

サーバー Lenovo* ThinkSystem* SR630

プロセッサー インテル® Xeon® Silver 4114プロセッサー ｘ2 （12コア、2.10 GHz）

メモリー（ベース） 128 GB：16 GB 2666 MHz RDIMM x8

ディスク （OS/ ローカルストレージ）

OS：デュアル M.2 128 GB SSD（RAID 1）データ：2 TB 2.5インチ SAS HDD x8

HDD コントローラー ThinkSystem* RAID 930-16i 4 GB Flash 12 Gb コントローラー

ハードウェア・ストレージ 保護

OS：RAID1NameNode/ メタストア：RAID 1データベース：RAID 10ZooKeeper*/QJN：ハードウェア保護なし、JBOD HDD、複数のマスターノードにわたる複数のサービス・インスタンスにより冗長性を提供

ハードウェア管理 ネットワーク

統合1 GbE BaseT Lenovo* XClarity* Controller（XCC）インターフェイス

データ・ネットワーク・ アダプター

Broadcom NetXtreme* デュアルポート10 GbE SFP+ アダプター

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

11

導入に関する考慮事項この章では、Cloudera* ソリューションを導入する場合のリアルタイム・ストリーミングに関する考慮事項について説明します。 事前に定義されたクラスター構成のサイジングに関する一般的な情報については、Lenovo Big Data Validated Design for Cloudera Enterprise with Local and Decoupled SAS Storage を参照してください。 このホワイトペーパーでは、以下のトピックについても説明しています。

• 低コスト向けの設計

• 高速取り込み向けの設計

• Spark* によるインメモリー処理用の設計

• 仮想化環境の Hadoop* 向けの設計

• ディスク容量の評価

• スケーリングへの考慮

• 高可用性への考慮

• 移行への考慮

• HDD コントローラー、データ・ネットワーク・アダプターなどのコンポーネントの選択

ハードウェアの最適化ここでは、 ハードウェア・パフォーマンスの最適化に関する推奨事項について説明します。

CPU Governor モードの設定利用できる CPU Governor を確認するには、cpupower を実行します。

[root@master ~]# cpupower frequency-infoanalyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated

by software: 0 maximum transition latency: Cannot determine or is

not supported. hardware limits: 1.20 GHz - 3.70 GHz available cpufreq governors: performance powersave current policy: frequency should be within 1.20 GHz

and 3.70 GHz.The governor “performance” may decide which speed to use within this range.

current CPU frequency: 1.21 GHz (asserted by call to hardware)

boost state support: Supported: yes Active: yes

CPU Governor の現在のステータスを確認するには、 次のコマンドを実行します。

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Governor を performance モードに設定するとともに、 クラスター内のすべてのノードのすべてのコアについて同様の設定を確実に行うことをお勧めします。

インテル® ターボ・ブースト・テクノロジー 2 .0 の有効化突発的なワークロードで必要になった場合に、より高い周波数でコアが動作できるように、 インテル® ターボ・ブースト・テクノロジーを有効化することを強くお勧めします。 一般的にも、ターボモードを有効化することでパフォーマンスが向上します。 すべてのコアでスケーリング・ドライバーが intel_pstateに設定されていることを次のコマンドで確認してください。

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver

プロセッサーの現在の状態について概要を把握し、アイドル状態のコアをデバッグするには、次のコマンドを実行します。

[root@master ~]# turbostat --debug -PPackage Core CPU Avg_MHz %Busy Bzy_MHz TSC_MHz SMI CPU%c1 CPU%c3 CPU%c6 CPU%c7 CoreTmp PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 PkgWatt RAMWatt PKG_% RAM_%

インテル® ハイパースレッディング・テクノロジーの有効化ビッグデータのリアルタイム・ストリーミングには、高スループットのデータ取り込みと処理が必要であり、 コアの可用性は一般的に線形の拡張性にプラスの影響を与えます。 データ・パイプラインがキャッシュに大きく依存していない限り、 NUMA アクセスによる影響はなく、 ハイパースレッディングは処理全体に大きなメリットをもたらします。 ハイパースレッディングが有効化されていることを確認するには、 lscpu または「dmidecode –t processor」を実行し、スレッドを検索します。

注意：極めてレイテンシー要件の厳しいリアルタイム・ストリーミング・ユースケースでは、NUMA アクセスを避け、ハイパースレッディングをオフにすることが推奨されますが、これは全体的なスループットと拡張性に影響します。

Transparent HugePage の無効化「Transparent HugePage」（THP） は、 プロセッサーのメモリー ・マッピング ・ ハードウェアをより効率的に利用することでパフォーマンスを向上することを目的とした Linux* カーネルの機能です。 ほとんど の Linux* ディストリビューションでは、 デフォルトで THP が有効（「enabled=always」）になっています。

THP によって一部のアプリケーションはパフォーマンスが少し向上しますが（最大で約 10%、一般的な向上は 0% 〜 3% の範囲）、THP によって重大なパフォーマンスの問題や、明らかなメモリーリークが発生する場合もあります。 これらの問題を避けるには、 サーバー上で THP を「enabled=madvise」に設定します。

echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

また、 カーネル ・ コマンドラインで （/etc/default/grub などで）transparent_hugepage=madviseを設定します。

この変更によって、THP に最適化されたアプリケーションではパフォーマンスのメリットを利用し、 その他のアプリケーションでは起こりうる問題を避けることができます。

ソフトウェアの最適化オペレーティング・システムの上限値（ulimit）• open files（オープン可能なファイル数）： Spark* エグゼキューター

は、 オープン・ファイル・ハンドルに大きく依存するため、 この上限値が小さいと障害が発生する可能性があります。 /etc/security/limits.conf内のこの値を 1048576 以上に設定します。

• max user processes（最大ユーザープロセス数）: 同様に、 Hadoop*ユーザー（または Spark* ジョブを実行するユーザー）の場合、/etc/security/limits.conf内のこの値を 1048576 に増加します。

ネットワークの Maximum Transmission Unit（MTU）ジャンボフレームを示すには、MTU 値を 9,000 に設定します。 デフォルトの MTU サイズを増加すると、 パフォーマンスを大幅に向上できます。こ れ は、 /etc/sysconfig/network-scripts/ifcfg-<interface>を使用し、 ネットワーク・サービスを再起動することで更新できます。

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

12

クラスターのスケーリング構成以下の章では、ラック容量やスループットによるサイジングに関する推奨事項について説明します。 特定の導入にどの構成が最適かは、特有のワークロードやパフォーマンス要件によって異なります。

ラック容量によるサイジング実施したテストでは、 受信レコードと送信レコードがそれぞれ 512 〜1,024バイトと1 KB であった金融サービス業界（FSI）の不正検出のユースケースに焦点を当てています。 ほかの業種やユースケースでは、データの複雑さやマシンラーニング・パイプラインによってメッセージのサイズは異なります。 そのため、キャパシティー ・プランニングを実施して、適切なラック構成を確認する必要があります。

表 4 に、推奨の構成と容量を示します。 使用可能なストレージは、3 倍のレプリケーションを前提としています。 Kafka* データの保持は、CDH セットアップ全体の一部として構成できます。 保持日数には、満了までデータを保持できる最大期間が反映されます。 この期間より長くデータを保持すると、 新しいレコードの保存で問題が発生し、 コミット中に利用できないオフセットによりオフセット例外が発生する場合があります。 一般的なデータ保持期間は、 大容量 / 高スループット・システムで 1 時間〜12 時間の範囲です。

ストレージ・ソリューションを選択するときには、エンドツーエンドの処理、およびインサイトや検索用のデータクエリーを考慮する必要があります。 インテル® Optane™ SSD かインテル® SSD DC P4500 シリーズかの選択では、 予算と SLA のレイテンシー要件のバランスをとる必要があります。 ソリューション概要「リアルタイム・ストリーミング分析ソリューションでデータ価値を最大化」 に記載したように、 インテル® Optane™ SSD は、一部のタスクをインテル® SSD DC P4500 シリーズよりも短時間で完了できますが、3D NAND SSD よりもコストが高くなります。 詳細については、インテル® SSD データセンター ・ファミリーの説明を参照してください。

YARN Node ManagerVMEM（仮想メモリー）チェックの無効化：一般に、長く動作するジョブは、 コンテナー上で実行されている仮想メモリーの制限を超える場合があります。 そのため、YARN でこのチェックを無効化することをお勧めします。

Spark*• シリアライザー ： Spark* では、 KryoSerializer ライブラリー（バー

ジョン 2）を使用して、 より迅速にオブジェクトをシリアル化することができます。 Kryo は、 Java* のシリアル化よりも、 多くの場合で約 10倍高速で、コンパクトです。

• メモリー：推奨されるメモリー最適化は複数あります。

– YARN のメモリー ・ オーバーヘッド ： YARN をコンテナー ・ オーケストレーションのリソース ・ マネージャーとして使用するためには、メモリーを各コンテナーに提供する必要があります。 一般に、YARN のメモリー ・ オーバーヘッド （spark.yarn.executor.memoryOverhead）は 786 MB 〜 1 GB の間に設定されるので、コンテナー管理中にガベージ・コレクションや VMEM/PMEM バウンドによる問題は発生しません。

– 動的割り当て：ワークロードのスループットは時間とともに変化するので、動的割り当ての使用をお勧めします。 動的割り当てによって、スケールアップやスケールダウンを容易に行うことができます。 これを使用するには、 spark.shuffle.service.enabledフラグを使用してシャッフルサービスを有効化する必要があります。

– エグゼキューター数の初期値：タスクの開始早々にスループットが高くなることが分かっている場合、spark.dynamicAllocation.initialExecutorsフラグを設定して、エグゼキューターの初期値を特定します。 この値は、 spark.dynamicAllocation.minExecutors と spark.dynamicAllocation.maxExecutorsの間の値にする必要があります。 これらの値は必要に応じて調整できます。

ZooKeeper*ZooKeeper* と Kafka* ブローカーは、 リソースの競合を避けるため、別々のノードで実行する必要があります。

表 4 . さまざまなラック容量に対する構成ハーフラック フルラック マルチラック（3倍）

ストレージ容量：4 TB ドライブ（不正の確率が1% で、1秒当たりのトランザクション数が10万のストリーム処理用）

ストリーミング用のローストレージ 192 TB 336 TB 960 TB

使用可能な容量（予備を25% とした場合） 48 TB 84 TB 240 TB

Kafka* データの最大保持期間 4.8日 8.4日 24日

ストレージ容量：10 TB ドライブ（不正の確率が1% で、1秒当たりのトランザクション数が50万のストリーム処理用）

ストリーミング用のローストレージ 480 TB 840 TB 2400 TB

使用可能な容量（予備を25% とした場合） 120 TB 210 TB 600 TB

Kafka* データの最大保持期間 2.4日 4.2日 12日

ノードとストレージの構成

ストリーミング / 検索のノード数（Kafka*/Elasticsearch*） 4 7 20

ストリーミング・ノード当たりの HDD 12 12 12

インテル® Optane™ SSD またはインテル® SSD DC P4500シリーズ 2 2 2

コンピューティング・ノード数（Spark* Streaming） 5 10 35

マスターノード数 3 3 3

ラック内の処理ノードの総数 12 20 58

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

13

スループットによるサイジングリアルタイムのビッグデータ・アーキテクチャーでは、通常、ストリーミング・トラフィックはスループット容量で表されます。 スループットの SLAは通常、 平均負荷とバースト / スパイク負荷を使用して設定されます。そのため、これらの要件に適切に対処できるシステムを構成する必要があります。

スループットを向上するとエンドツーエンドのレイテンシーが大きくなることが多いため、スループットの最適化とレイテンシーの最適化では、ほとんどの場合、 パフォーマンスの上限と下限になります。 ユーザーは、スループットとレイテンシーの SLA のニーズを評価し、それに従ってキャパシティー ・プランニングを進める必要があります。 表 5 に記載したように、Spark* Streaming のバッチサイズは、一般的な Spark* Streamingアプリケーションで設定可能なパラメーターです。 Spark* はそのバッチサイズの時間だけ待機してからミニバッチ内のすべてのレコードの処理を開始するので、この時間がエンドツーエンドのレイテンシーに影響します。 また、クエリーのレイテンシーは、一般に、クエリーの複雑さ、および基盤となるストレージ・フレームワークによって変わります。

不正検出以外にも、キャンペーンの有効性の評価、対象を絞った広告や自動クーポンの提供、クロスセルのチャンスの特定など、さまざまなユースケースに影響するので、エンドツーエンドの処理ニーズを検討することが重要です。 全体として、このホワイトペーパーで説明したリファレンス・アーキテクチャーは、バッチサイズを設定するだけで、さまざまなユーザーのシナリオに対応できます。

セキュリティー保管中のデータと移動中のデータのどちらも扱うため、 セキュリティーはどのような企業への導入でも極めて重要な役割を果たします。 すべてのオープンソース・コンポーネントは、 認証と承認を提供するために、Apache Kerberos* および Sentry* と適切に統合されます。 さらにグループアクセスやアクセス制御リスト（ACL）を作成したり、暗号化を使用してデータ利用ポリシーを施行することもできます。 各企業専用に設計されたカスタム・フレームワークとの統合はそれぞれ異なりますが、一般に OAuth ベースのフレームワーク、 LDAP サーバーなどとの統合が導入の際に実施されます。

CDH 上のセキュリティー実装に関する詳細については、https://cloudera .com/documentation/enterprise/latest/PDF/cloudera-security .pdf（英語）を参照してください。

セットアップに関するその他の注意Spark* 2 .0 と Kafka* 0 .10 は、CDH のインストール完了後、別々にインストールする必要があります。 すべてのホスト上で Spark* およびKafka* ゲートウェイの役割を作成する必要があります。 一般に、JBODを使用してディスクボリュームをセットアップし、そのマウントポイントを HDFS* で使用して、 データを 3 倍のレプリケーションで保存します。ほかのサービスのバージョンは、Cloudera の CDH 5 .10 パーセルのデフォルトパッケージに基づきます。 バージョンの詳細については、こちらのサイト（英語）を参照してください。

Kafka* ManagerKafka* Manager は、 Kafka* のトピックやブローカーの健全性と指標を監視するのに有用なツールです。 Kafka* Manager は、次のいずれかの方法で入手できます。

– リポジトリー ： http://github .com/yahoo/kafka-manager/ をコピーし、タグ 1 .3 .3 .6 をチェックアウトする

– バ イ ナ リ ー ： http://github .com/yahoo/kafka-manager/releases/tag/1 .3 .3 .6/ をダウンロードする

Kafka* Manager をビルドするには、次のコマンドを実行します。

./sbt -Dhttp.proxyHost=[proxy_uri] -Dhttp.proxyPort=[proxy_port] -Dhttps.proxyHost=[proxy_uri] -Dhttps.proxyPort=[proxy_port] clean dist

注意：sbt はダウンロードにバンドルされています。 Scala バイナリーのダウンロードには時間がかかります。 ネットワーク帯域幅により 1 〜 2分待つと、 ダウンロードが表示されます。 バージョンの競合によるライブラリー解決の問題がある場合は、 古い Ivy キャッシュ（~/.ivy2/cache）の削除が必要になることがあります。

表 5 . さまざまな平均スループットとスパイク / バースト・スループットに対する構成

平均スループット （1秒当たりのメッセージ数） 10万 50万 100万 500万

スパイク・スループット （1秒当たりのメッセージ数） 30万 80万 200万 800万

1日当たりの ローデータ取り込み 10 TB 50 TB 100 TB 500 TB

推奨のデータ有効期間 12時間 12時間 12時間 12時間

ストリーミング / 検索ノードの ストレージ容量 4 4 4 7

ストリーミング・ノードの ストレージ容量

ノード当たり 4 TB ドライブ x2

ノード当たり 4 TB ドライブ x6

ノード当たり 4 TB ドライブ x12

ノード当たり 10 TB ドライブ x12

検索 / インデックス作成用の 追加のストレージ

375 GB のインテル® Optane™ SSD または1 TB のインテル® SSD DC P4500 シリーズ（1ノード当たり）

375 GB のインテル® Optane™ SSD x2または1 TB のインテル® SSD DC P4500 シリーズ（1ノード当たり）

375 GB のインテル® Optane™ SSD x2または 1 TB のインテル® SSD DC P4500シリーズ x2 （1ノード当たり）

375 GB のインテル® Optane™ SSD x2または 1 TB のインテル® SSD DC P4500シリーズ x2 （1ノード当たり）

処理ノード数 5 5 5 10

推奨ラック ハーフラック ハーフラック ハーフラック フルラック

エンドツーエンドの 処理レイテンシーの測定値（Spark* Streaming の バッチサイズとして設定可能）

5〜20秒 20〜30秒 20〜30秒 20〜30秒

検索レイテンシーの測定値 インテル® Optane™ SSD 上で Elasticsearch* の正確なクエリー ・レイテンシーは約8 ms

ホワイトペーパー | Lenovo のビッグデータによる、ThinkSystem* サーバー上のリアルタイム・ストリーミング分析向け設計の検証

14

ビルドが成功したら、次の手順に従います。

1 . unzip target/universal/kafka-manager*.zip を実行し、展開されたディレクトリーにcdコマンドで移動します。

2 . export ZK_HOSTS=[ZK_QUORUM]を実行します。

3 . bin/kafka-manager -Dhttp.port=9090を実行します。

4 . ウェブ UI：http://localhost:9090を開きます。

次に Kafka* クラスターを追加します。

1 . クラスター ZooKeeper* のホストを入力します。

2 . Kafka* バージョン 0 .10 .1 .0 を選択します。

3 . JMX ポーリングを有効化します（その他の設定はデフォルトのままにします）。

Kafka* Manager のユーザー ・インターフェイスを使用した、Kafka* への新しいインスタンスの追加やトピックのパーティション再分割は非常に有用です。 新しいインスタンスを追加するときには、 すべてのブローカーにわたってトピックのバランスが取れていることを確認したうえで、パーティションの再割り当てが必要になる場合があります。

Cloudera* パーセルのバージョン• CDH5：5 .10 .1-1 .cdh5 .10 .1 .p0 .10

• Kafka*：2 .1 .0-1 .2 .1 .0 .p0 .115

• Spark2：2 .1 .0 .cloudera1-1 .cdh5 .7 .0 .p0 .120904

Solr/ELK とその他のインデックス作成エンジンは、相当な CPU リソースとメモリーリソースを使用するため、別のノードで実行します。

部品表（BOM）このリファレンス・アーキテクチャー向けのさまざまな構成のハードウェアについては、 完全な部品表（BOM）が Lenovo Big Data Validated Design for Cloudera Enterprise with Local and Decoupled SAS Storage に記載されています。 BOM には、部品番号、コンポーネントの説明、数量が含まれています。 概ね、BOM は次のカテゴリーのインフラストラクチャーに対して提供されています。

• マスターノード

• ワーカーノード

• システム管理ノード

• 管理ネットワーク・スイッチ

• データ・ネットワーク・スイッチ

• ラック

• ケーブル

BOM リストはすべてを網羅することを意図したものではなく、必ず構成ツールを使用して検証する必要があります。 価格設定、 サポート、 メンテナンス・オプションの説明については、 このホワイトペーパーに記載されていません。

BOM 情報は米国向けです。 その他の国では部品番号や説明が異なる場合があります。 その他のサンプル構成は、Lenovo のセールスチームから入手できます。 コンポーネントは予告なく変更されることがあります。

自分たちの組織に合った適切なソリューションを見つけましょう。 詳細については、インテルの担当者にお問い合わせいただくか、http://www .intel .co .jp/bigdata/ を参照してください。

関連資料

Cloudera リファレンス、分析機能、およびユースケースに関する コンテンツ（英語）

LenovoLenovo Big Data Validated Design for Cloudera Enterprise with Local and Decoupled SAS Storage

インテル • 高度な分析

• インテル® Xeon® スケーラブル・プロセッサー

• インテルのデータセンターに関する情報（英語）

• インテル® SSD データセンター ・ファミリー

• インテルの金融サービス向けソリューション

オープンソース・ソフトウェア• Apache Spot*（英語）

• Elasticsearch*（英語）

• Kafka*（英語）

• Solr（英語）

336885-001JAJPN/1810/PDF/SE/MKTG/SU

記載されているコスト削減シナリオは、指定の状況と構成で、特定のインテル® プロセッサー搭載製品が今後のコストに及ぼす影響と、その製品によって実現される可能性のあるコスト削減の例を示すことを目的としています。 状況はさまざまであると考えられます。 インテルは、いかなるコストもコスト削減も保証いたしません。

インテル・プロセッサー ・ナンバーはパフォーマンスの指標ではありません。 プロセッサー ・ナンバーは同一プロセッサー ・ファミリー内の製品の機能を区別します。 異なるプロセッサー ・ファミリー間の機能の区別には用いません。 詳細については、 「インテルのプロセッサー ・ナンバーとは」を参照してください。

性能に関するテストに使用されるソフトウェアとワークロードは、性能がインテル® マイクロプロセッサー用に最適化されていることがあります。 SYSmark* や MobileMark* などの性能テストは、特定のコンピューター ・システム、コンポーネント、ソフトウェア、操作、機能に基づいて行ったものです。 結果はこれらの要因によって異なります。 製品の購入を検討される場合は、他の製品と組み合わせた場合の本製品の性能など、ほかの情報や性能テストも参考にして、パフォーマンスを総合的に評価することをお勧めします。 詳細については、http://www .intel .com/benchmarks/（英語）を参照してください。ベンチマーク結果は、 「Spectre」および「Meltdown」と呼ばれる脆弱性への対処を目的とした最新のソフトウェア・パッチおよびファームウェア・アップデートの適用前に取得されたものです。 パッチやアップデートを適用したデバイスやシステムでは同様の結果が得られないことがあります。

インテル® テクノロジーの機能と利点はシステム構成によって異なり、対応するハードウェアやソフトウェア、またはサービスの有効化が必要となる場合があります。 実際の性能はシステム構成によって異なります。 絶対的なセキュリティーを提供できるコンピューター ・システムはありません。 詳細については、各システムメーカーまたは販売店にお問い合わせいただくか、http://www .intel .co .jp/ を参照してください。

Intel、インテル、Intel ロゴ、Intel Optane、Xeon は、アメリカ合衆国および / またはその他の国における Intel Corporation またはその子会社の商標です。

* その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

インテル株式会社 〒 100-0005 東京都千代田区丸の内 3-1-1 http://www .intel .co .jp/

©2018 Intel Corporation . 　無断での引用、転載を禁じます。2018 年 10 月