DB統合と分離したときのはなし
自己紹介
こんにちは。ぱんだ と ももみです。
二人ともナビタイムジャパンでスポットデータの開発や運用を担当しています。
ぱんだ・・・バックエンド開発（DB系）を担当。直近1か月は毎日1時間歩いています。
ももみ・・・スポットデータのプロジェクトに異動して2年経ちました。
ナビタイムジャパンで行っているDB（データベース）の統合と分離の裏側についてお話ししていきたいと思います。
はじめに
所属しているチームでは、スポットデータや住所データ・交通系データなどのデータをDBに登録する処理を作ったり、DB運用や管理を行っています。
運用しているDBはナビタイムジャパンのサービスや販売されているAPIなどのシステムの裏側で参照されていますが、データ管理に使っているDBはサービスや用途によって分けていたり、共通で利用可能な場合は同じDBが参照されています。
運用しているDBは数多くの種類が存在し、現在では共通で利用可能な場合は同じDBを参照する構成となっていますが、過去にはわかれている構成となっているものもありました。今回は、統合や分離をする目的や事例、ポイントなどについて話していきたいと思います。
DB統合について
目的
複数あるDBの費用コストや運用コストを下げることが主な目的となります。サービスが多くなり、DBの物理的な費用コストが増えてきた、DBのバージョンアップやリプレース時の運用コストが増えてきた、といった場合に改善タスクとして検討をはじめていきます。
統合する方法と事例
これまで行ってきたDB統合は大きく2種類あります。1つのクラスタ・サーバーにDBを共存させるものと、複数のDBを1つのDBにデータを整理・精査したうえで集約させて統合する方法です。
DBを統合するメリットは、複数のサーバーに跨っていたDBが1つのサーバーに集約されることとなるので、そのぶんサーバーやDBのリソースを有効活用することができ、インフラコストを節約できたりバージョンアップ等の運用コストも削減できることです。
①1つのクラスタ・サーバーに複数のDBを集約する
1つのクラスタ・サーバーに複数DBを集約するタイミングは定期的に行っているわけではなく、インフラチームや他のチームからの提案・依頼で行うケースや、所属しているチームで定期的に管理しているサーバーの洗い出しを行っている中で統合できそうなところを集約していくこともあり、タイミングや背景はそれぞれ異なります。
統合する背景として多いのは、DB参照が開始されてからある程度時間が経過したのち、サーバーリソースやDBリソースに余裕がありそうな場合に統合対象として列挙されてきます。
実際にどれくらいのリソースに余裕があれば統合可能なのかというところなのですが、このあたりはサーバー監視システムの数値をベースにさまざまな情報を総合して判断しています。
➁複数のDBを1つのDBに集約する
複数のDBを1つのDBに集約するというのは、たとえばAというDBに登録されているデータと、BというDBに登録されているデータを、CというDBにひとまとめにするような対応を指しています。
テーブル定義や登録されているデータ内容を細かく精査・整理して、DBを参照する側のシステムやAPIにも影響が及ぶため、1つのクラスタ・サーバーに複数DBを集約する対応より骨が折れる作業となります。以前所属しているチームで行った対応では1,2年ほどかけて対応を実施しました。
以前はナビタイムジャパンのサービスである『NAVITIME』サイト（PC）や『カーナビタイム』、法人系サービスなど、各種案件や利用用途ごとにデータを登録するDBを用意する必要があり、その都度DB構築→データ準備→登録ということを行っていました。
しかし、現在ではDBのマスタテーブルの設定を追加・変更することで以前同様の仕組みを実現することができており、費用対効果の高い施策を行うことができたと考えています。
現在の構成に変更する形でのDB統合は、多くのテーブル定義の変更やマスターデータの新規追加などが発生しました。比較的規模の大きいAPIリプレースが必要となったため、APIへの影響を最小限にするためにリグレッションテストを入念に行い、大きなシステムトラブルが起こることなく本番リリースすることができました。
リグレッションテストは、社内で使っているリグレッションテストツールがあるので、それを利用することでスムーズに進めていくことができました。
DB統合の使いどころ
DB統合の使いどころとしては、ナビタイムジャパンの例をあげると、管理するデータやDBの運用コストや費用コストが上がって来たタイミングで改善案件として対応を進めました。データが増え続けて困っている、日々のデータ管理や運用コストが上昇傾向にあるという状況であればデータ・テーブル定義を見直してDB統合を行うよい機会になるのではないかと考えます。
DB統合まとめ
DB統合で費用コストや運用コストを下げることが可能。
サービスリリース後、サーバー・DBリソースに余裕がある場合は統合の検討をするとよさそう。
テーブル定義やマスターデータを見直す統合方法は、効果は高いがコストもかかる。（採算が取れそうか見積もることが重要。）
システムリプレースが発生する統合時にはリグレッションテストが大事。
DB分離について
目的
過去にDB分離したときの目的は、アクセスを完全にわけるため、というものでした。所属しているチームではあまり分離を行ったことはないのですが、DBアクセスが一時的に急上昇した時に、暫定的な対応として分離した事例があります。一般的な例でいうと、顧客との契約条件等で物理的にサーバーをわけなければならないという場合も該当すると思います。
分離する方法と事例
DB分離はDB統合とは反対に1つのクラスタ・サーバー上にあるDBを分離させて、複数のサーバー上にDBをわけることを指しています。分離する方法は新しくサーバーを用意するなどして、物理的にDBを分ければ完了です。
所属しているチームでの対応事例は少ないですが、過去にあった事例を紹介していきたいと思います。
以前、短期間にDB参照が継続的に増え続けてDBサーバーが悲鳴を上げ続ける事象が続いたことがありました。通常、DB参照が急激に増える場合は、スケールアウトやスケールアップといった施策を打つのが一般的でその対応も行っています。
当時はそれに加えて一時的に重いクエリを集中させるように分離するのがよさそうといった意見が上がり、各所で対応方法を協議してDB分離を行いました。
DB分離の使いどころ
DB分離をどういうときに行うと有効なのかという部分なのですが、DB参照する処理の改善ということを前提に考えた場合の例で、たとえば「限定的なアクセスで負荷の高い処理だけを切り出したい場合」や、複数サービスから参照されている状態で「契約条件等で特定データを分離させて管理させておきたい」場合などに有効な方法となると思います。
またDB分離する際のデメリットですが、統合時のメリットと逆に単純にクラスタ・サーバーの台数が増えることになり、インフラ費用や管理運用コスト増になるため、現在所属しているチームではあまり積極的にはDB分離を行っていないというのが現実的なところです。
DB分離まとめ
アクセスを限定的に切り出したいときに有効。
顧客との契約条件等で分離することもある。
インフラ費用や運用コスト増につながる。
さいごに
DBの分離と統合についてお話ししてきました。
十数年の間にも、すぐに思い出せないほどの件数のDB分離と統合が行われました。現在も類似サービス間でのDB統合を「複数のDBを1つのDBに集約する対応」で検討中ですが、古いシステムでもあり、やはりコストがかかりそうです。
ただ、過去の複数のDBを1つのDBに集約する対応によって、データを物理的に統合して、論理的に出力を制御できるようになりました。そのおかげで、設定値の追加によって、新規サービス向けにカスタマイズしたデータの出力を実現できるようになっています。
サービスリリースのスピードアップやコストカットにもつながっていると感じますし、サービススケールに応じて、DBの台数も必ずしも増えるわけではないので、DBの運用コストもスケールしづらいです。マイクロサービスともその点では相性がよいかもしれないと感じています。
そのような先々のメリットも考えながら、システムのバックエンドで、今後も改善に取り組んでいきたいと思います。