「自社サービスにマッチしたデータベースを選ぶ」ことの重要性
株式会社ブロードリーフは、自動車業界向けパッケージシステムの開発を行う企業だ。同社のシステムは、自動車アフターマーケットと呼ばれる市場で働く事業者をターゲットとしている。
当然ながら、扱っているのは自動車に関するデータだ。車やその部品、流通情報、整備履歴などがそれにあたる。車種データだけでも約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だったという。
この経験をもとに、松本氏は自社のサービスに適したデータベースを選定することの重要さを提唱した。扱うデータの特性やビジネス要件、求められる可用性のレベル、メンバーのスキルセットなど、検討すべき指標は複数ある。これらの条件にマッチしたものでなければ、どれほど優れたツールもうまく機能しないのだ。
システムを刷新するならば「開発体制も共に変えるべきだ」
データベースを改善した後、彼らが次に手をつけたのはアプリケーション側のアーキテクチャ変更だった。データベースがどれほどスケールアウトできたとしても、アプリケーションが処理のボトルネックとなっては全体のパフォーマンスが向上しないためだ。では、こちらはどんな基準で新しいツールを選定していったのだろうか。
基準となったのは、まず開発・運用やスケールアウトが容易であること。同社のアプリケーションは複数のサブシステムに分かれており、以前はインスタンスグループの管理や内部接続用のロードバランサの管理などが煩雑となっていた。そのデメリットを解消したかったという。
次に、クラウド環境でなくても動くツールであること。ブロードリーフでは自社内開発だけではなく協力会社への業務委託も行っている。他社に対し、クラウド環境を使用することを強要すべきではないと考えたからだ。これらの条件を満たすものとして、Kubernetesを採用した。
「これで、データベースもアプリケーションもスケールアウトするようになりました。何事も問題なく進んだかといえば、そうではありません。次は人がスケールしないのです」
理想はサービスごとにチームを作っていくこと、つまり各チームがオーナーシップを持ち、スピード感を持ってリリースできる開発スタイルを採用する方式だ。しかし、現実はそうならなかった。自動車アフターマーケットを構成している業者ごとに管理体制が構築されていた。つまり、同一サービスのなかでもチームが細分化されていたということだ。
その結果、コミュニケーションや成果物の管理が非常に煩雑になっていった。しかも、その全ての仲介をしているブロードリーフがボトルネックとなってなかなか開発速度が上がらなかった。
さらに、他にも課題があった。必ずしも最新技術に詳しい協力会社だけではないため、新しく導入したツールについての説明が必要だったのだ。「この体制をより良いものにしていく必要がありました」と松本氏は続ける。
システムアーキテクチャだけを改善しても、開発は円滑に進まない。開発プロセスやチームの体制なども含めて変えていかなければ、生産性の高い組織は実現しないのだ。ブロードリーフのエンジニアたちは、コミュニケーションのあり方を変えていったという。
最初のうちは、JIRAによるチケット管理でコミュニケーションを行っていたが、より気軽にコミュニケーションを取れるようにSlackを導入した。また、社内で使用していたConfluenceページを全ての協力会社と共有した。そうすることで、よりスピーディーなコミュニケーションと情報の蓄積を行っていったそうだ。
「最初はデータの基盤を変えていこうとプロジェクトを推進したのですが、その過程でアプリケーションやインフラのあり方、コミュニケーションのあり方すらも変えていきました。それらを改善しなければ、新しいサービスをうまく開発することはできません。このプロジェクトではデータを中心に物事を考えていきましたが、理想のアーキテクチャを実現するにはデータ以外にも数多くの知識が必要になりました。この経験から、システムや組織が成長し続けていくには、それを支えるエンジニアが変化を受け入れ、新技術を積極的に学んでいくことが重要だと実感しました」
では、その姿勢を持つエンジニアになるためには何が必要なのか。それは、「変化を楽しく受け入れる」ことであると松本氏は結んだ。
「技術の進化スピードは本当に速いです。新しいことを学ぶのは嫌だ、ついていけないから仕事がつらいと思えば、負のスパイラルに陥ってしまいます。だからこそ、新しい技術に対してポジティブな気持ちで向き合えることが何よりも大事なのだと考えています」
お問い合わせ
株式会社ブロードリーフ
