マイクロサービスにて、別サービスが提供するデータのIDを保持するということの是非

Question

マイクロサービスで設計する際、別のサービスの特定のデータを紐づけたい場合、別サービスのデータのIDなどを自分のDBに保存してもよいものなのでしょうか？

良いたとえではないですが具体例を挙げます。
ブログアプリを作るとして、２つのマイクロサービスで構成するとします。

• ユーザー管理マイクロサービス
• 投稿マイクロサービス

１つのアカウントでいろんなサービスを使えるようにユーザー管理だけを別サービスにするというのはそこまでおかしくはない気もします。

ブログアプリ(フロント)では、各マイクロサービスを操作して以下の
1.ユーザー管理マイクロサービスでログイン処理をし、ユーザーID、ユーザー名などを取得
2.投稿マイクロサービスから投稿内容を取得して表示したり、サービスにブログ投稿を依頼したりする

この時、投稿マイクロサービスでは以下のようなモデル(Postテーブル)があるはずです。

Post {
  id int primary key
  title text
  message text
  user_id int <---- ユーザー管理マイクロサービスの発行するユーザーIDを持って良いものか
}

````

フロントアプリでは、投稿表示などの際、Postテーブルに持っているユーザーidを元に今度はユーザー管理マイクロサービスからユーザー名などを拾ったりして表示するなどします。
一般的なWAF等で作るならPostテーブルにユーザーIDを持つこと自体は普通だと思います。
ただ、このケースではユーザーIDは別のサービスのidなので、投稿マイクロサービスとしては何の意味も持たない情報になります。これが設計上よいのか気になっています。
特定のサービス（この例ではユーザー管理マイクロサービス）に依存するシステムにもなってしまいます。

投稿マイクロサービス内で独自にユーザーテーブルをを持ったとしてもサービスにまたがって同じユーザーIDがあるだけでもっと悪い気がしますし。。
上記の例に限らず、自サービスの特定のデータを別サービスの特定のデータに紐づけたい、ということはありそうな気がするのですが、その際別のサービスのデータのキー項目を自サービスに保持してしまってよいものなのでしょうか？

Answer 1

PostからUserIdに依存するのは要件から考えると必要かどうかわかるはずです。つまり投稿は誰が投稿したかわかる必要があればUserIdを保持する必要があります。

問題はPostとUserは別々のシステムでDBも違い、PostとUserを別々のトランザクション境界で永続化されています。結果整合になります。なので、Post.userId は user.idに外部キー制約も適用できません。つまり、PostのuserIdはもう退会しているか、サスペンドされて使えない可能性もあります。

そういったことを考える必要がありますが、サービス間でAPI経由でポーリングし合うようなアーキテクチャになるとポーリングだけで負荷があがりスケールしなくなることがあります。ポーリングの頻度は気をつける必要があります。

できるだけ、必要な情報を非同期にプッシュするようにしないといけません。Pub/Subってやつです。サービス間でメッセージキューを使って非同期にメッセージを送りあったりします。

ご参考までに

Answer 2

・ユーザー管理マイクロサービス
・投稿マイクロサービス
これらとは別にユーザ情報をもったデータベースやメッセージがあると思ってください。
ユーザ情報の仕様はインターフェイスなどで共有します。
ユーザー管理マイクロサービスも投稿マイクロサービスもユーザ情報の仕様には依存しますが
お互いは干渉しないように出来るとおもいます。

Comments

[MutsuyukiTanaka]

すみません、いくつか追加で質問させてほしいです。

まず、別途３つ目のユーザー情報データベースやメッセージ（APIですよね？）を持つマイクロサービスを登場させるという意味で合っているでしょうか？

そのうえで、
ユーザー情報（エンティティ）はユーザー管理のサービスが持つのが妥当な気がするのですが、ここで管理しない理由は何でしょうか？
また、ユーザー管理サービス、投稿サービス共におっしゃるユーザー情報を持った第３のサービスの中のキー（ユーザID）は保持する（つまり、このユーザーサービスのIDの仕様に依存する）については問題ないということで合っているでしょうか？

[hihijiji]

ユーザー管理のサービスがユーザー情報のストア機能を兼ねてもいいですし、ユーザー情報のストアを別サービスにしてもいいです。
重要なのは、サービス間でやり取りする「ユーザ情報の仕様」は特定のサービスの配下にしないことです。
むしろ、ユーザー情報を扱うサービスは「ユーザ情報の仕様」に従うように設計します。
ユーザ情報に一意のキーが必要ならば「ユーザ情報の仕様」に一意のキーを盛り込みます。
データストアを行うサービスがその一意のキーをデータストアに利用するのは問題ありません。
要はサービスありきでななく、仕様ありきです。

[hihijiji]

Qiitaにいい記事がありました
https://qiita.com/Seiga/items/a59c800e57e022125e3b

[hihijiji]

もひとつ追加します
https://employment.en-japan.com/engineerhub/entry/2019/08/22/103000