ネットワークからビッグデータの世界へ

鈴木　新卒で入社して、エンジニアとしてずっとキャリアを積んでいます。大学時代は建築学科で、建築家になるための勉強もしていたのですが、研究室でネットワーク構築やソフトウェア開発に触れる機会がありまして「これは何か大きいことができそうだ。」と思いこの業界にきました。

ビッグデータ系の技術に出会ったのは5年ほど前です。それまでは通信ネットワークや携帯のトラフィック監視系のシステムを開発する業務に関わっていました。ビッグデータ関連のシステム開発をしている人は、データベースやBI関連出身のエンジニアが多いので、この経歴は珍しいのではないかなと思います。

勝本　私は入社して以来、ずっとテレコムのネットワークに関わる開発を行ってきました。特にネットワークの集中監視プロダクトの開発や、大手キャリアのインターネットサービスの構築の部分をしばらく担当していました。

最近では、ネットワーク系の分野でも、ビッグデータというものは避けては通れなくなってきています。例えば携帯のトラフィック監視はRDBを使うことが普通でしたが、近年のスマートフォンによるデータ量の増加や、加入者の増加によってそのままでは対応が難しくなってきています。そのような背景があり、ビッグデータ系のソリューションをどう活かせるのか、ということを考え始めました。

鈴木　ビッグデータ系ソリューションを活用した経験が当時は無かったので、まずは社内勉強会という形でHadoopに取り組み始めました。当時は、いきなりクラウドで構築すると物凄くお金がかかってしまうので、社内サーバーを50台くらい置いて実験をして。そしてHadoopをひと通り学んだ後は、CassandraやStormなどの別のビッグデータ系のテクノロジーに知識を広げていきました。

限られた情報の中での挑戦が新たな価値を生む

勝本　ビッグデータが注目される前から、巨大なデータをどう処理するのかというテーマは考えていまして。既製品の中身を調べて、どういう技術が使われているのかも1つひとつ勉強していましたね。その時の知識も今のビッグデータに生きています。

鈴木　Stormはリリースされて、1ヶ月も経たない内から調査し始めて、これも社内で勉強会を実施しながらノウハウを蓄積していきました。リリースされて間もないプロダクトだったので、日本語の情報源になるものは2つくらいしかなくて、その内の1つは弊社エンジニアのブログという状況でした（笑）。しょうがないので、海外のブログ記事を読んだり、OSSで公開されているソースコードを読みながら解析して、徐々に理解が深まっていきました。

鈴木　そうやって2~3年の間に蓄積したビッグデータ系のノウハウを、いろいろなプロジェクトで利用する機会が増えました。ちょうどIoTという言葉が脚光を浴び始めたこともあり、リアルタイム系のビッグデータソリューションのニーズが急増してきています。弊社ではStormを始めいくつかのテクノロジーのノウハウがあり、社外向けの勉強会で発信もしていたので、様々な企業からお声がけ頂くことができました。

ビッグデータはリアルタイムの世界へ

鈴木　StormはTwitter社が2011年にリリースしたOSSのプロダクトです。最大の特徴としてはリアルタイムのストリーム処理（※連続的に発生するデータを逐次処理する方式）に向いていることですね。

当時、ビッグデータ系のソリューションといえば、Hadoopくらいしか無くて、大量に蓄積されたデータに対し、バッチ処理で解析するようなものが主流だったんですよ。一方、私達が担当する業務は、データをリアルタイムに処理することの方が多かったので、Stormは今後の案件に活かせるはず、と考えていました。

最近ではIoT向けのリアルタイムセンシングや、ユーザー行動の解析などリアルタイムに大量のデータを処理することが求められるようになってきていますが、Stormを利用することで、大量のストリームデータを簡単に処理することができるんですよ。秒間数万～数十万件のデータであっても、リアルタイムに、正確に扱うことができます。

パフォーマンス200倍を実現したStormの底力

鈴木　あるお客様から、ネットワークトラフィックを扱うシステムを、現行の100倍くらい早くしたい、という要望を受けまして。以前は最大でも秒間100イベント程度の負荷だったものが、次第にピーク時の負荷に耐えられなくなってきているので、パフォーマンスの改善をしたいと。

そこでどの技術を使うのが最適なのかという話になるのですが、最も重要視したのがデータの信頼性です。例えば、アクセスログ収集のビッグデータ処理だと、1つくらいデータが抜け落ちたり、処理する順序が変わったとしても、全体の結果にはあまり影響が無かったりするので、問題にならないケースもあるんですよね。

もちろん、実際にはそのような問題への対処も考慮して開発しますが。しかし今回のケースではネットワーク監視という特性上、ビッグデータでありながら、データ欠損や処理順序の逆転は起きてはいけない。エラー情報が漏れてしまって障害に気が付かなかったら大問題ですから。そのような点を考慮して、Stormを利用したアーキテクチャを提案しました。

その結果、秒間2万件以上のイベントを処理でき、従来のシステムに比べて最大200倍ほどの高速化を実現できたんです。

Stormは「1つの選択肢」

鈴木　Stormと似たようなプロダクトにSpark Streamingというものがあるのですが、別のプロジェクトではこちらを選択することもあります。Sparkはマイクロバッチという方式を採用していて、数百ミリ秒から数秒ほどの短い時間に流れて来たデータに対して、短い間隔でバッチ処理を行うようなイメージです。

Sparkが力を発揮したのは、ユーザーの行動解析をリアルタイムに行って、それに応じた処理をしたい、というような課題に対してです。短時間の中で発生したユーザーの一連の行動から、単発のユーザーの行動からでは判断できない、より適した処理を行えるようにする。

勝本　例えば、似たような商品を連続して見ている場合は、商品を見比べている可能性が高い。そのような短期間の行動データをマイクロバッチを利用して解析し、ユーザーにお勧めの情報を提示することが可能になります。

あとSparkはHadoopとの親和性が非常に高いという点や機械学習のライブラリを利用できるのが大きな利点となりました。このように、業務やそこで利用されるデータの特性に合わせて使用するソリューションは選択しています。なので、お客様の業務のヒアリングは欠かせないんです。

ビッグデータに銀の弾丸はない

鈴木　ビッグデータ系のテクノロジーはある領域に特化したものが多いんです。StormとSparkの違いもそうだし、データの蓄積だけを見ても信頼性を重視するならHBaseを使うし、パフォーマンスを優先するならCassandraを使ったり、Redisを利用してインメモリ処理で高速化する。どのようなときでもこれがいい！というものは絶対に決まらないんです。

どのテクノロジーも、何かの課題を解決する目的でどこかに特化して発展してきたものなので、万能ではない。それが難しい所ではあるのですが、実現したい事とテクノロジーの特徴・組み合わせがカチッとハマると強力な武器になります。

特に弊社では、受託開発やサービスプラットフォームを開発するプロジェクトが多いので、お客様の要望や業務の特性を正確に捉えるように気をつけています。特に難しいのは信頼性を取るのか、パフォーマンスを取るのかというところ。大体のお客様は、両方と答えられるんですけどね（笑）。とは言ってもお客様の実現したいことにとって本当に重要なものは何か、というのを徹底的に考えます。既存システムの注意点や業務要件などをお客様からヒアリングし、最適な解を一緒に考えながら開発をしています。

チャレンジを伴う選択を今後も続けていく

鈴木　何かを選択する、ということは必ず新しいチャレンジが必要だと考えています。ずっと同じことをやっていても開発をしているエンジニアはつまらないですし、何より同じことを続けていても会社としての成長はないので、お客様にとっても魅力が無い。それ故、私達としては、常に新しいことにチャレンジし、選択肢を増やして、お客様に新しい価値を提供していきたいと思っています。

勝本　受託開発をメインにしている会社で新しい技術をどんどん取り入れているという会社は少ないと思います。新しい技術を取り入れるということは、リスクもあるし、それを理解するのに時間も要します。

ただ、それにチャレンジしていくということは、既存の技術ではできなかったパフォーマンス向上を実現したり、最終的にはシステム全体のコストを下げることに繋がったりする、というメリットがあるので、最終的にお客様のためになるんですよね。今後も、私達は新しいテクノロジーは積極的に取り入れていきたいと考えています。