Dr.Sum

界を超えろ!
速さを追求したインメモリデータベースエンジン開発への挑戦

第2部 Deep Dive

リーダーたちが語る! Dr.Sum Ver.5.0開発の核心

Dr.Sum Ver.5.0のインメモリデータベースエンジンは、旧バージョンからどのような進化を遂げてきたのか。様々な課題を乗り越えてきた苦労話も織り交ぜつつ、リーダーたちに今回の開発のポイントを語ってもらった。

開発グループとデータベースエンジンは運命共同体

あらためて伺います。Dr.Sumのデータベースエンジンを、なぜゼロベースで作り直そうと考えたのでしょうか。

笹原Dr.Sumは歴史の長い製品です。もっと高速化したい、機能強化を図りたいという思いは持っていましたが、10年以上前のコードに手を入れると、どこに影響がでるかわかりません。思い切った手は打てなくなっていたのです。その意味でもデータベースエンジンの全面的な刷新が必要なタイミングでした。

今回は特にインメモリへの移行を大きなテーマとしていますね。

開発リーダー 橋田 哲尚

橋田はい。Dr.Sumを通じて提供する価値は何かというと、端的にはデータ集計のスピードです。そしてDr.Sumが今後に向けて訴求していく価値も、やはりスピードでありたいと思っています。これがDr.Sumに対する一貫した開発コンセプトです。そうした中から出てきたのが、「100億件のデータを1秒で実行する」という目標で、これを達成するためにはファイルをベースとした既存のデータベースエンジンでは不可能。インメモリに軸足を移すのは必然の選択でした。もっともお客様のすべてのワークロードをインメモリに展開できるとは限らないので、既存のデータベースエンジンとハイブリッドで運用できる仕組みを提供しています。

ちなみに「100億件のデータを1秒で実行する」という目標は、執行役員CTOの島澤 甲さんが設定したのですか。

笹原そこは島澤の感覚だったと思います。ただ、一足先にMotionBoardでインメモリ方式を採用している実績があり、簡単なことではないが決して達成不可能な数字ではないという確信はあったようです。

それにしても、なぜそこまでデータベースエンジンにこだわったのですか。スピードを追求しているのはよくわかりましたが、それならばむしろ、すでに市場に登場している汎用的なインメモリデータベースエンジンを採用するという手もあったかと思います。そうすれば3年間にも及ぶ開発期間をかけることなくスピードアップを実現することができ、ウイングアークとしてはBIツールのユーザーインターフェイスやエクスペリエンスの部分にもっと注力できたのではないでしょうか。

笹原そもそもなぜ私たちがDr.Sumを開発したかというと、日本企業のお客様が求めているような集計ツールがなかったことに端を発します。その状況は現在でも大きく変わっているわけではなく、他社の汎用的なデータベースエンジンでは、お客様の業務の"かゆいところに手が届かない"のです。だからこそ私たちが提供する情報活用ソリューションについては、主要モジュールをすべて内製化すべきという基本姿勢で臨んできました。これからは逆にDr.Sumのインメモリデータベースエンジンにより汎用的な機能を取り込んでいくことで、超大規模なデータ活用の市場を切り崩していきたいとも考えています。

安達私もウイングアークがデータベースエンジンを開発することに疑問は持ちませんでした。というより私たちはこれまでもずっとDr.Sumのデータベースエンジンに関わってきたエンジニアのグループで、そこに存在意義を感じています。仮にもうデータベースエンジンの開発から撤退するので、君たちはこれからエクスペリエンスの開発をやれと言われたら、会社を辞めると思います。データベースエンジンを高速化することは私にとって最大の仕事のやりがいであり、楽しいことなのです。

なるほど。皆さんとデータベースエンジンは"運命共同体"なのですね。

橋田そういっても過言ではないと思います。

クエリーごとに異なるパターンでいかに高速性を発揮するか

いくら楽しくてもインメモリデータベースエンジンの開発には様々な苦労があったかと思います。具体的にどんな困難を乗り越えてきたのでしょうか。

開発エンジニア 安達 俊貴

安達すでに何度も話がでているようにDr.Sumにとって集計スピードこそが命であるわけですが、あらゆるパターンで性能を発揮できるわけではありません。あるデータセットに対して特定のクエリーを適用した場合に高速化できたとしても、別のデータセットに切り替えた途端に速度がガクンと落ちてしまうのです。そこで別の対処を考える、そういった作業を繰り返しながら全体としてのスピードを上げてきました。

なぜデータセットやクエリーのパターンによって、集計スピードが変わってしまうのですか。

安達最も大きく集計スピードに影響するのはカージナリティ(カラムに格納されているデータの種類がどのくらいあるか)です。例えば「所在地」を例に取ると、都道府県単位であればデータの種類は47種類しかありませんが、市区町村単位になると1,700以上にも広がります。

橋田どんなデータセットやクエリーのパターンに対しても汎用的に適用できるアルゴリズムを用意できれば理想的なのですが、安達が言ったように現実はそうはならず、カージナリティの高低に応じて特殊化された複数のアルゴリズムを使い分けることになります。

そうすると当然、全体のコントロールが難しくなりますね。

橋田そのとおりです。アルゴリズムを特殊化したことでオーバーヘッドが肥大化し、データベース全体のパフォーマンスが低下してしまうケースさえあります。実は外資系の大手ベンダーが提供しているデータベースエンジンも同様に特殊化されたアルゴリズムのかたまりなのですが、大規模な人海戦術でその開発をこなしています。私たちのような少人数の開発体制にとって一番厳しいところです。

どうやってその課題を乗り越えたのですか。

安達アルゴリズムの設計を大人数で分担するのではなく、私ひとりに任せてもらえたことで逆にやりやすい面もありました。集計処理の大まかな流れは一本ですが、集計データを保持するコンテナを動的に切り替えるというアーキテクチャーを考えたのです。詳しいことは話せませんが、処理を始める前にどのコンテナを使用するかなどの分岐の"シナリオ"を決めておき、あとは一気呵成に処理を流していくという仕組みです。

淡々と話していますが、かなり高度なテクニックですよね。

安達頭全体がコンパイラにならないとできません(笑)。

川代開発言語にはC++を使っているのですが、今回はそのテンプレートを使ったメタプログラミングを多用しています。これは旧バージョンのDr.Sumのデータベースエンジンではほとんど使っていなかった技法で、そういった面でも安達のチャレンジに開発グループ一同注目しています。

開発側での手戻りを最小化するテスト自動化の取り組み

データベースエンジンをゼロベースで作り直す、しかもこれまでと違った技法まで駆使したとなると、テストもますます大変ですね。

川代そのとおりで、新しく作ったものが問題なく動き、最初から正しい結果を返すはずがありません。改善したはずの部分がかえってデグレード(以前の状態よりも品質が悪化)をもたらすことも多々あります。社内には品質保証部という専門チームがあり最終的な品質を担保しています。しかし、機能数も膨大なため、いきなり彼らに渡しても"お手上げ"になってしまいます。そこで開発側であらかじめ入念なテストを行い、一定レベル以上の品質を満たしておく必要があります。

開発側でどういったテストを強化したのですか。

開発エンジニア 川代 雄太

川代各担当者がそれぞれ作ったコードに対して、開発グループ内でレビューを行い、そこでOKが出たものを製品モジュールにマージして統合テストを行っています。率直なところ、このプロセスにおいては、これまで十分なテストがなされていませんでした。いざ実行してみたところ動かなかったり、結果に矛盾が生じたりすることがあり、そのたびに個々のコードに立ち返って原因を調べ直すという手戻りが発生していたのです。これは大変な無駄な作業であり、開発スケジュールにも大きな遅延をもたらすため、コードレビューを行う前に自動でテストを行う仕組みを作りました。簡単に言うと、そうした全体的な作業の手戻りをなくすためのインフラ整備に注力してきました。

様々なクエリーのパターンに対する網羅的なテストを自動的に実施し、品質維持のための作業を効率化するのですね。

川代基本的にはそういう考え方をとっているのですが、クエリーのパターンの組み合わせを単純に展開すると1億以上となってしまうため、ある程度の"足切り"も必要です。その見極めが難題でした。

橋田まさにそこがQE(品質工学)の核心であり、開発グループ全体をリードしてくれた川代の貢献は絶大です。川代がいなければスケジュールどおりにDr.Sum Ver.5.0をリリースできなかったと思います。

汎用データベースとしても活用できる機能の拡張へ

少し気が早いかもしれませんが、今後に向けたDr.Sumの拡張、特にインメモリデータベースエンジンの機能強化の構想をお聞かせください。

開発責任者 笹原 徹

橋田これまでのDr.Sumのデータベースエンジンは一般的なRDBMSとは違い、集計処理に特化したアーキテクチャーを採用していました。これに対して今回のDr.Sum Ver.5.0のインメモリデータベースエンジンは、よりジェネリックなワークロードを意識したアーキテクチャーを設計しており、汎用的なデータベースとしてもそれなりに活用できる機能を付加していく計画です。例えばトランザクション処理を担う更新系の機能、ビッグデータを想定した複数の異なるデータソース(テーブル)のJOINといった機能についても、できるだけ早期に実装したいと考えています。

安達個人的な思いとしては、これまでのDr.SumのデータベースエンジンでトライしたことがなかったWindow関数を組み込みたいです。クライアントツール側ではなくSQLレベルで機能強化を図ることでこそ、お客様のかゆいところに手が届くようになります。せっかくジェネリックなインメモリデータベースエンジンに生まれ変わったのですから、そのメリットを最大限に活かし、より多様な分析をより容易に実行できるBIプラットフォームにDr.Sumを発展させていきたいです。

川代私は開発作業やテストを支援するためのインフラ部分の強化を引き続きやっていきたいと考えています。開発やテストのプロセスを効率化することでコスト削減を促せば、よりコストパフォーマンスの優れた製品を提供するという形で、お客様にも還元することができます。

笹原ハイブリッド型のエンジンはまだ始まったばかりです。パフォーマンスはもちろんですが、機能的にも絶え間ない進化を続けていきますので、どうかご期待ください。

member
このページのトップへ