コマンドとクエリーでDBを分ける
マイクロサービスで実装するデータ検索処理では「コマンドクエリー責務分離（CQRS）」パターンを使うケースが多い。データの更新系処理「コマンド」と参照系処理「クエリー」を分離してシステムを実装する考え方だ。
CQRSでは、コマンド側DBで発生した変更をクエリー側DBに反映する必要がある。手法としては先のイベントソーシングを用いるのが一般的だ。
例えばAWS上でNoSQLデータベースのDynamo DBをコマンド側に、リレーショナルデータベース（RDB）のAmazon Auroraをクエリー側に設定した構成で、「Dynamo DBのデータ更新をトリガーにAWS LambdaによってAuroraのデータを更新する手法がよく使われる」（塚田技術統括部長）。
コマンドとクエリーの分離により、サービスを個別にスケールアウトできるようになる。コマンドとクエリーでNoSQLとRDBを使い分けるなど、サービスごとに技術を選べるマイクロサービスのメリットも得やすい。
ただしここでも、コマンド側とクエリー側で結果整合性を許容する必要がある。
マイクロサービス特化型DBに期待
モノリシックと表現される従来型システムからマイクロサービスへの移行ではDBをどうするかが考えどころだ。マイクロサービスの作法に従えば、サービスごとにDBを分割したうえで、必要に応じてイベントソーシングなどで同期しなければならない。
しかし、その実装には高いスキルが必要だ。そのため現実解として「アプリケーションはマイクロサービス化するが、DBは従来通りモノリシックで構わない」（アクセンチュアの福垣内クラウドソリューションアーキテクト）との意見は少なくない。日本マイクロソフトの樽沢シニアクラウドソリューションアーキテクトは「アプリケーション、DBと段階的に既存システムを更新していけばよい」と話す。
ここまで同期に着目して手法を見てきたが、その選択はデータ量によっても変わってくる。グロース・アーキテクチャ＆チームスの鈴木社長は「一口にリアルタイム同期が必要と言っても、データ量が多いならDB共有、量はそれなりに多いが参照だけならレプリケーション、量が少ないならAPIによる更新が向く」と話す。
データ同期は、サービスを疎結合にするうえでの課題だ。多くのユーザーが試行錯誤しているのが現状である。
将来的に、分散環境にありながら瞬時にデータを同期する「マイクロサービス専用DB」が登場すれば、サービスの都合だけで自由にDBを分割できるようになり、マイクロサービスの普及を後押しするだろう。さらなるITの進化に期待したい。
