こんにちは。ATOM事業部エンジニアの松尾です。 普段は、広告媒体からのデータ取得処理やAPI実装を行っています。
最近、同一システム内で顧客ごとにDBを分ける対応を進めています。今回は、こちらについてご紹介させていただきます。
マルチテナントとシングルテナントについて
まずはマルチテナントとシングルテナントについて説明させてください。
マルチテナント
マルチテナントとは、複数のユーザが同じ１つのシステムやサービスを共有する仕組みです。
こちらのアーキテクチャは、SaaS型のサービスの多くで利用されています。 メリットは、リソースや運用コストを大幅に削減でき、低コストで導入可能です。
シングルテナント
シングルテナントとは、複数のユーザがユーザごとに１つのシステムやサービスを占有する仕組みです。
こちらのアーキテクチャは、PaaS型のサービスの多くで利用されています。 メリットは、ユーザごとのカスタマイズ性が高く、セキュリティの強化につながります。
同一システム内で顧客ごとにDBを分ける
マルチテナントの単一DBの構成から顧客ごとにDBを分ける構成に移行しようとしています。 こちらの対応は、マルチテナントとシングルテナントの中間のようなイメージが近いです。 ただその一方で、顧客ごとに対し１つのDBサーバの占有は実現できていないので、マルチテナントとも言えます。
メリットは、セキュリティの強化です。もちろん、シングルテナントの方がよりセキュリティの強化に繋がります。 しかし、APIサーバからのリクエスト時に、顧客ごとにDBを切り替える必要があるので、意図しない顧客のデータの読み書きが発生しにくくなります。そして、もし何かしらのインシデントが発生した場合も影響範囲の切り分けが行いやすくなります。
また、メンテナンス性の向上にも繋がります。特定の顧客がDBサーバのパフォーマンスに大きな影響を与えるようになった際に、内部でDBを分けているので新たにDBサーバを新設し、そちらに移すことも容易になります。そして、マルチテナントからシングルテナントへの移行も容易になります。
スムーズな運用を行うために必要な仕組み作り
移行後は、セキュリティやメンテナンス性が担保されるようになる一方で運用コストが高くなります。 そのため、少しでも運用コストを抑えるために以下のような仕組みを用意していく予定です。
- DBサーバへのリクエスト時のDB切り替えの仕組み
- 全DBに対して一斉にマイグレーションが行える仕組み
- 顧客跨ぐデータの読み書きが行なえる仕組み
の３つになります。
1は必須になります。 2も早めに必要です。 3はあると便利だよねというイメージです。 この他にも運用コストを下げる工夫がまだまだあるかと思いますが、こちらの３つ仕組みだけでも運用コストが結構抑えられると思っています。
まとめ
今回は、「同一システム内で顧客ごとにDBを分ける」対応について、シングルテナントとマルチテナントと比較しながら説明させていただきました。 基本的にはセキュリティの強化を行うと、何かしらのコストが発生することが常かと思いますが、工夫しだいで極力コストを下げることが可能になります。今回紹介させていただいた仕組み以外で何か他にアイデアがあれば教えていただけると嬉しいです。
最後までお読みいただきありがとうございました。
