認知度が高まっているが、まだまだSparkの活用例は少ない
「本セッションではあくまでもSparkとKafkaを使ってリアルタイム基盤をどう作っていくのか、従来のHadoop基盤と比べてどういうメリットがあるのかについて説明する。したがってプログラマよりは、アーキテクチャに携わる方向けの内容となる」
こう最初に宣言し、田中氏のセッションは始まった。田中氏は現在、IBMでHadoopやSparkを使った解析基盤の構築に携わっている。前職ではWeb系の会社で大規模アーキテクチャ設計や実装、サーバサイドプログラム、フロントエンドプログラムを担当していたこともあり、いわゆるフルスタックエンジニアである。
これまでビッグデータの処理基盤として用いられてきたのがHadoopである。Hadoopの認知度は非常に高く、会場でもそれなりの人数の方が「業務ですでにHadoop基盤を使っている」と手を挙げていた。そして一昨年ほど前から注目を集めているのが、Sparkである。
Sparkは当初、イノベーターやアーリーアダプターを中心に注目を集め、今ではアーリーマジョリティ、レイトマジョリティへの広がりを見せつつある。とはいえSparkを業務で利用している会社はまだまだ少ないが「昨年末より事例も登場してきた」と田中氏は語る。
HadoopやSparkの認知度の向上の背景には、ビッグデータの広がりがある。「ソフトウェアはもちろん、ITコンサル、金融系、ハードウェア系、教育分野、医療分野、通信キャリア、広告、ECなどというように「いまや特定の分野ではなく、さまざまな業界を横断してビッグデータは展開されている」と田中氏。もちろん、ビッグデータといっても業界によってそのデータ量はさまざまだが、たとえば数千万PV、数億PVのコンテンツを有するWeb系システムでは、単純なサーバログだけで1時間に数GB～数十GB、1日に換算すると100GB近くのログが吐き出されることになる。そのほかにもユーザーログやアプリケーションログなども収集できる。
ログデータだけではない。Webサイトデータ、センサーデータ、ログデータ、カスタマーデータ、オフィスデータ、オペレーションデータ、ソーシャルデータなどを収集し、これらのデータを組み合わせて分析したり、高度な機械学習をしたりして新たな価値を生み出そうというのがビッグデータである。数十～数百TB級を分析するための基盤技術として採用されてきたのが、「Hadoopを中心としたHadoopエコシステムだ」と田中氏は語り、基盤アーキテクチャの説明へと入った。
オーソドックスなHadoop解析基盤では何が問題なのか
オーソドックスなHadoop解析基盤は、Hadoop（HDFS＋MapReduce）とHadoop上でSQLを扱うHiveや機械学習を扱うMahoutで構成。これにより、単位時間当たりに集めたデータをHadoop上のHiveやMahoutで1日数回の頻度で解析を実行し、ストレージやBIに反映できるようになる。「以前はこのような基盤を提案してきた」と田中氏は語る。というのも、1つのRDBで保存不可能な大量データがHFDSを利用することで保存が可能になること、保存したデータに対し、分析や機械学習が現実的な時間で実行可能になるからだ。
しかし「このオーソドックスな基盤には問題点もある」と田中氏は指摘する。それは「データを受け取りHadoopへ格納する際のタイミング。この基盤だといずれの場合も数時間に一度データをインプットする形となり、この遅延はリアルタイム分析基盤構築のための枷になる」と田中氏は言う。
それだけではない。データを処理する部分やデータを反映する際にも問題があるという。データ処理する部分については「HDFS上のファイルをMapReduceで処理するものはディスクアクセスが多くなるため、レイテンシも高くインタラクティブな処理やリアルタイム処理には不向き」、データ反映についても「データ反映をRDBにする場合、書き込み不可の時間帯を外さないと別システムの足を引っ張るなどの考慮事項が増え、生産性が悪くなる」と田中氏は言う。
SparkとKafkaを組み合わせで実現するリアルタイム処理基盤
そこでSparkとKafkaを採用しようというのである。SparkはSparkCoreモジュールとそれを利用したSparkSQL（SQLのインタフェースの提供）、GraphX（グラフ演算やグラフを操作機能を提供）、Streaming（ストリーミングデータ処理の提供）、MLib（機械学習アルゴリズムを提供）というコンポーネントから成る。HadoopでのMapReduceではスループットを重視し、バッチ処理に特化しているので、レイテンシに問題があったが、SparkとRDD＆DAGで処理すると、Sparkはレイテンシを重視し、メモリ上で操作を行うので、「たとえ機械学習でも繰り返し処理が高速にできる」と田中氏は語る。
一方のKafkaはメッセージキューを扱うシステムで、「プロデューサー」「ブローカー」「コンシューマー」という3つの役割から構成されている。
プロデューサーはメッセージを格納する役割を担う。実際APIから直接Kafkaにキューイングする場合は、APIがプロデューサーになる。トピックスと呼ばれる単位でキューの制御が可能で、プロデューサーはトピックスに対してメッセージの送信を行う。
キューイングされたメッセージやトピックスの管理を行うのがブローカーで、これがKafkaの本体となる。そしてトピックスからメッセージを消費するのがコンシューマーで、Kafkaからメッセージを使って何らかの処理を行うという役割を担う。Sparkとの組み合わせでは、コンシューマーはSparkのアプリケーションとなる。
そのほか、バッチ処理を行うためのプログラムやデータをストリーミング配信するAPIなどがコンシューマーとなる。「コンシューマーはコンシューマーグループというグループをつくることが可能で、複数のコンシューマーごとに一貫したデータの処理が可能。これがKafkaの特徴」と田中氏は説明する。
実際のリアルタイム基盤はどのような仕組みになるのか。田中氏はデータのインプット先をKafkaに、従来のHadoopのクラスタ部分のHiveとMahoutをSparkに置き換えるという構成を提案。データのインプットとしてSparkから直接RDBを参照するように。SparkSQLではJDBC、ODBCをサポートしているので、Sparkから簡単にMySQLなどのDBを参照できるからだ。またデータの出力部分もKafkaを出力先とする。
こうしてKafkaをハブとすることで、各モジュール間の連携が極力疎結合となる。またビッグデータを活用するために、多様なデータの格納、大量のデータの受付を行えるよう設計すると「基盤活用の幅が広がるのでお勧めだ」と田中氏は言う。
そのためにはKafkaを利用してオンライン系システムから論理的に切り離し、それぞれの影響を最小限にすることだと田中氏は言う。あらゆるデータをKafkaに一旦集約することで、Spark側はKafkaのみに対応すればよいということになるからだ。また「障害からの分離にもなる」と田中氏は言う。ビッグデータ基盤は多くのミドルウェアやエコシステムの組み合わせで構築されているため、障害の頻度や種類も多様。たとえどこかのシステムに障害が発生してもKafkaをバスにそれぞれの世界を分離できれば、全体に影響を出すことなく安定したシステム運用が可能になるからだ。
さらにKafkaはコンシューマー側でデータの取得制御を行うため、同じトピックスから複数の処理を分けることができる。「この特徴をうまく生かすことで、新しい処理やアルゴリズムの検証などをアドホックに行うことができる」と田中氏は語る。
SparkとKafkaによるリアルタム基盤の活用例
実際、SparkとKafkaによるリアルタイム基盤の活用例も紹介。最初に紹介したのはSpark Streamingのみを活用して単純な集計処理を秒単位で実行するという構成例。これはWeb系やゲーム系の企業でよりリアルタイムなユーザーの反応をキャッチアップし、意思決定のためのPDCAの高速化に応用できるという。
次にRDBに既存資産があるケースについても紹介。すでにHadoopの基盤システムがある場合でも、HiveをSparkSQLに接続して利用することで、より高速に解析・判定処理ができるようになるという。「製造業や金融業など、既存データから新たな価値を生み出す施策や事業立ち上げ時に有効に使えるのでは」と田中氏は提案する。
第三はStreamingとMLibを組み合わせルことで、リアルタイムで流れてくるデータを判定処理し、ラベル付けを行うなどの活用も可能だという。このような処理はセキュリティや医療分野での異常値の検知にも応用できるのではという。
最後は大量トラフィックの反映パターンとしても「この基盤は活用可能だ」と田中氏は語る。というのもKafka自身が容易にスケールが可能なシステムだからだ。大量トラフィックをKafkaで受け、同時書き込みに特化したHBaseを組み合わせることで、秒間数10万～100万規模のトラフィックに耐えられる基盤ができるという。「このような基盤は今後、さらなるニーズが広がるとよそされるIoT分野に向けた施策として有効に使えるはず」と田中氏は言い切る。
最後に「ぜひ、リアルタイム処理を行う処理基盤にチャレンジしてほしい。そしてナレッジを共有しよう」と会場に呼びかけ、セッションを締めた。
お問い合わせ
日本アイ・ビー・エム株式会社
- TEL: 0120-550-210
- Apache Spark関連情報
