自社プロダクトであるBI製品の集計エンジンの高速化の研究・開発プロジェクトに従事し、特許を取得しました。
このプロダクトは、特許を取得した独自のデータ構造でデータをディスク上に持つことで、非常に高速に検索・集計演算ができることが最大の強みでしたが、当時は原則として単一ノード(サーバ)上でしか動作しないアーキテクチャでした。
これを複数ノード上で動作する分散・並列型のアーキテクチャに対応させるための基礎技術開発、プロトタイプ実装、性能評価をしました。
基本設計やプロトタイプ実装は私とベテランの先輩(当時40歳台)で分担し、設計や性能評価のレビューは社長がしました。
2010年当時、主に英語文献しかない環境下でHadoop等の分散並列処理フレームワークについて調査しました。そこで使われている「分割・統治」型のアプローチ、「コンシステンス・ハッシュ法」を、特許取得済みのデータ構造とうまく組み合わせることで、単一ノードのみ対応だったデータ構造を、N台のノードにスケールする分散並列処理機構としました。
特に、並列化した際にスケーラビリティが出ない問題にぶつかった時に、コンシステンス・ハッシュ法を用いることでスケーラビリティを確保することと、ビットマップを用いた絞り込み(SQLのWHEREに相当する処理)処理、および分散並列JOIN処理方式は私が設計、実装した方式によりスケーラビリティが確保できました。アイデアを数十枚の紙に書き出していき、コンシステンス・ハッシュを一つ一つのデータに対してではなく、データのチャンクに対して適用することをひらめきました。これによりスケーラビリティが確保できました。
プロトタイプ実装により、リレーショナル演算の絞り込み(SQLのWHERE)、結合(JOIN)、集約集計(GROUP BY)に対してN台のノードに対して線形に近いスケーラビリティがあることを実証しました。実装において、各処理を担うクラスのインタフェースは主にベテランの先輩が用意しました。そのインタフェースに合わせて絞り込み、結合の並列処理を実際に記述する部分は私が担当しました。並列化を損なうような処理を紛れ込ませないのが重要でした。
性能評価はAWS上のEC2ノード、後には社内ローカルのブレードサーバ10台で行いました。EC2ではノード数を数十までとして性能測定をしました。多数のノードを効率よく起動したり終了、削除したりするためにPython APIを利用したスクリプトを書きました。EC2ではネットワークの不安定性により、思うような性能が出ませんでしたが、ローカルのブレードサーバ10台では線形的なスケーラビリティがあることが実証されました。
この分散処理方式を日本、および国際特許化しました。特許文書は弁理士の方に執筆・翻訳していただき、主にこのプロジェクトの従事者(社長、先輩、私の3名)でレビューをしました。