マイクロサービス勉強してみた (共有DBはNG編)
＜目次＞
※今記事から目次を試験的に置いてみます。
・何故この記事を書こうと思ったのか？
・今回勉強するにあたって参考にしたサイト
・結論
・何故そんなことが起きてしまうのか？(※結論に対して)
・DBはどう扱うべきなのか？
・学んだ感想
以上の構成で記事は進みます。
＜何故この記事を書こうと思ったのか？＞
マイクロサービスについて調べていくうちに共有DBはアンチパターンだそうで、機能単位で分割したらDBも分割することを知らなかったです。
それ故に、マイクロサービスのDBについてさらに調べることにしましたので、その勉強した結果を記事にしてみようと思いました。
＜今回勉強するにあたって参考にしたサイト＞
マイクロサービスアーキテクチャにおけるDB設計のパターン – Regardie's Salesforce Blog
※この記事のパターン1より共有DBがアンチパターンとの記述があります。
マイクロサービスをどう切り出すか ～マイクロサービスの凝集性・疎結合性を保つベストプラクティスと最適手法 - アイマガジン｜i Magazine｜IS magazine
※マイクロサービスが目指すべき状態の表より「データベースを介したマイクロサービス間の結合は避けること」との記述がありました。
これは他のマイクロサービスのDBに直接アクセスするのは良く無いという意だと思います。
＜結論＞
先に結論を書きます、DBは分けましょう。
何故ならば「機能単位では独立しているがDBを共有していると、どの機能群でDBのテーブルやカラムを使われているのかわからなくなってしまう」ということが起きてしまうからです。
後述で何故そんなことが起きてしまうのか？と私が想定したシナリオを交えて、記事を書いていきます。
＜何故そんなことが起きてしまうのか？＞
【今回使用するバックエンドの例】
例：掲示板アプリのバックエンド
__認証関連APIサーバー
上記、バックエンドの例より「認証関連APIサーバー」の開発チームがusersテーブルというのを製作していたとして、例えば「認証関連APIサーバー」チームが想定しない形でデータを更新される可能性あります。
具体的なシナリオとして以下を想定してみてください。
1、「認証関連APIサーバー」の開発チームがusersテーブルに向けてCRUD出来るという役割を持っていたとします。
2、「掲示板CRUD関連APIサーバー」の開発チームは掲示板テーブルに関連するCRUD出来る役割はあるが、usersテーブルに向けてデータの作成・更新・削除することは無いという役割だとします。(※参照は出来るとする)
「掲示板CRUD関連APIサーバー」の開発チームが掲示板に書込するユーザー情報を編集出来るようにしたら便利になるかな？と思いユーザー情報を更新するエンドポイントを制作した場合、共有DBだとDBにアクセスできてしまうのでusersテーブルの情報が更新できてしまいます。
上記のようなシナリオが仮に出てきてしまうと、認証関連APIサーバーチームは「どこかの機能郡から勝手にユーザーの情報を更新されている...」といった困った状態になるケースがあると思いました。
※機能単位でAPIサーバーを分割してるが、共有DBにした時にパッと浮かんだ想定されるシナリオを書いてみました。
以上、本記事の結論に対し「何故そんなことが起きてしまうのか？」という説明になります。
＜DBはどう扱うべきなのか？＞
DBを分割し他DBの情報が欲しくなった場合は、APIサーバー間で通信し取得した情報を利用する。
例えばユーザー情報をリクエストに含んで掲示板に書き込みをする時、本当にそのユーザーがDBに存在するのか掲示板のDB保存前に「掲示板CRUD関連APIサーバー」から「認証関連APIサーバー」に通信を行なって、ユーザー情報をチェックするという感じの運用をする感じですかね。
＜学んだ感想＞
マイクロサービスのDockerファイルを構築するときに、mysqlのコンテナ1つに対して、バックエンドのAPIコンテナを2つ立てる予定だったのですが、共有DBにするという手法はアンチパターンだと知りました。(※手を動かす前に知れて良かったです。)
しかし、DB分割により本来はDB1つだった場合は、左結合で済んでいた処理がマイクロサービス化すると他のデータベース上にテーブルが存在する、それ故にその情報を取得するためにAPIサーバー同士で通信し情報を取得してから自サーバーで任意の処理をするというような流れになったりすると思うので、最初の機能分けの段階で設計ミスするとかなり大変な思いをするなと感じました。
後から、〇〇APIと△△APIは分けない設計に変えます！って簡単に言えないと思いますし....
分割DBの設計について私の中ではこれがベストプラクティスです！って話せるように、もっと設計に関する勉強をして知見を深めていけるように頑張ります。
今回の記事は以上となります、次回記事でお会いしましょう。
