「自社サービスにマッチしたデータベースを選ぶ」ことの重要性
株式会社ブロードリーフは、自動車業界向けパッケージシステムの開発を行う企業だ。同社のシステムは、自動車アフターマーケットと呼ばれる市場で働く事業者をターゲットとしている。
当然ながら、扱っているのは自動車に関するデータだ。車やその部品、流通情報、整備履歴などがそれにあたる。車種データだけでも約48万レコード、それにひも付く車の部品データは約4億6000万レコード、個別の車情報データは約1682万レコードを扱うという。膨大な数である。これらの大量データを高速に扱うことが、同社のシステムに求められる要件だ。
同社はなぜRDBMSをやめ、Cassandraに移行したのか。松本氏はその理由を語る。
「RDBMSでデータを扱うのには課題がありました。全てのデータをクラウド上にアップすることが難しかったのです」
前身となったシステムでは、大きく分けて構成Aと構成Bの2種類の商品構成を採用していたという。構成Aでは、ブロードリーフがサーバー機能を提供し、顧客の環境に専用アプリケーションを導入する。マルチテナント型のシステムのため、多数の顧客がAP/DBサーバーを共有する形だ。このシステムに関しては、クラウドへの移行は特に問題なかった。
しかし、もう一方の構成Bが問題となった。この構成の場合、1社あたり1インスタンスにしなければ、求められる性能要件を達成することは難しい。だが、1社1インスタンスの構成を採用することには大きなデメリットがある。管理・運用コストが膨らんでしまうことだ。より良いデータの保管方法を求め、同社のエンジニアは最適解を模索したという。
Cloud DatastoreやCloud Spannerなど複数の選択肢があったが、自社サービスに最もマッチしたものを選定していった結果、最終的にはCassandraにたどりついた。なぜ、他のデータベースでは駄目だったのだろうか。
Cloud Datastoreは、パフォーマンス面と開発のしづらさから候補外となった。このデータベースが同社の求める応答速度を満たしていなかったこと、マネージドサービスのため各種制約を解消できないことなどがその理由だという。
Cloud SpannerはACID特性もトランザクションもあり、SQLも使用可能であるため理想に近かった。だが難点があった。金銭的コストが比較的高くつくことだ。そのため、候補外となった。
処理速度が速く、データ量が増えてもスケールアウトできること。そしてコストを一定レベルに抑えられること。これらの条件を全て満たしていたのがCassandraだったという。
この経験をもとに、松本氏は自社のサービスに適したデータベースを選定することの重要さを提唱した。扱うデータの特性やビジネス要件、求められる可用性のレベル、メンバーのスキルセットなど、検討すべき指標は複数ある。これらの条件にマッチしたものでなければ、どれほど優れたツールもうまく機能しないのだ。
