マイクロサービスにおける ScalarDB Cluster のデプロイパターン
このページは英語版のページが機械翻訳されたものです。英語版との間に矛盾または不一致がある場合は、英語版を正としてください。
ScalarDB Cluster を使用するマイクロサービスアプリケーションを構築する場合、ScalarDB Cluster のデプロイ方法として、共有クラスターパターンと分離クラスターパターンの2つのパターンを選択できます。 このドキュメントでは、まずこれらのパターンについて説明し、それらの違いと、どの場合にどちらを選択するかの基本的なガイドラインを示します。
また、このドキュメントでは、マイクロサービスアプリケーションが database-per-service パターンに基づいて作成されているものと想定しています。このパターンでは、各マイクロサービスがデータベースを管理し、マイクロサービスはマイクロサービス間の API を介して別のマイクロサービスのデータベースにアクセスする必要があります。
ScalarDB Cluster のデプロイパターン
共有クラスターパターンでは、マイクロサービスはシステム内で1つの ScalarDB Cluster インスタンス (ScalarDB Cluster ノードのクラスタ) を共有するため、同じ ScalarDB Cluster インスタンスにアクセスしてデータベースとやり取りします。一方、分離クラスターパターンでは、マイクロサービスは複数の ScalarDB Cluster インスタンスを使用します。通常、1つのマイクロサービスが1つの ScalarDB Cluster インスタンスにアクセスして、データベースとやり取りします。
次の図は2つのパターンを示しています。(MS はマイクロサービスの略です。)
どちらのパターンでも、マイクロサービスに必要なデータベースに加えて、Coordinator テーブルも管理する必要があります。
長所と短所
明らかな違いの1つは、ScalarDB Cluster インスタンスのリソースの量です。分離クラスターパターンでは、アプリケーションを管理するためのリソースが増えます。これにより、メンテナンスの負担とコストも増加します。
さらに、使用する ScalarDB Cluster API も異なります。具体的には、共有クラスターパターンの場合、1フェーズコミットインターフェースを使用する必要があります。このインターフェースでは、マイクロサービスがレコードを読み書きした後、1つのマイクロサービスのみが commit を呼び出してトランザクションをコミットします。分離クラスターパターンの場合、2フェーズコミットインターフェースを使用する必要があります。このインターフェースでは、すべてのマイクロサービスが最初に prepare を呼び出し、すべてのprepare 呼び出しが成功した場合に commit を呼び出します。したがって、分離クラスターパターンのマイクロサービスは、トランザクションとそのエラーをよりきめ細かい方法で処理する必要があるため、共有クラスターパターンのマイクロサービスよりも複雑になる可能性があります。
さらに、リソースの分離レベルも異なります。マイクロサービスは、保守性と開発効率を高めるために十分に分離されている必要がありますが、共有クラスターパターンではリソースの分離が弱くなります。リソースの分離が弱いと、セキュリティも弱くなる可能性があります。ただし、認証や承認などの ScalarDB Cluster のセキュリティ機能を使用することで、セキュリティリスクを軽減できます。
同様に、システムの管理方法にも違いがあります。具体的には、共有クラスターパターンでは、他のチームに代わって ScalarDB Cluster インスタンスを管理するタスクをチームに割り当てる必要があります。通 常は中央データチームが管理しますが、そのようなチームが存在しない場合は問題が発生する可能性があります。分離クラスターパターンでは、管理のバランスがより取れていますが、Coordinator テーブルに関して同様の問題が発生します。この問題は、調整用のマイクロサービスを用意し、1つのチームにそのマイクロサービスを管理させることで対処できます。
次に、パターンの長所と短所をまとめます。
共有クラスターパターン
- 長所:
- 1フェーズコミットインターフェースのため、トランザクションとエラーの処理が簡単です。(データベースのバックアップ操作も簡単です。)
- 1つの ScalarDB Cluster インスタンスを使用するため、リソース使用量が少なくなります。
- 短所:
- マイクロサービス間のリソース分離が弱い。
- 管理のバランスが取れていない。(1つのチームが他のチームに代わって ScalarDB Cluster インスタンスを管理する必要があります。)
分離クラスターパターン
- 利点:
- リソースの分離が向上します。
- 管理のバランスがより取れます。(1つのチームが1つのマイクロサービスと1つの ScalarDB Cluster インスタンスを管理します。また、1つのチームに Coordinator ターテーブルの管理を任せる必要があります。)
- 欠点:
- 2フェーズコミットインターフェースによるトランザクションとエラー処理が複雑です。(データベースのバックアップ操作も複雑になることがあります。)
- 複数の ScalarDB Cluster インスタンスがあるため、リソース使用量が増加します。
どのパターンを選択するか
可能な限り、共有クラスターパターンを使用することをお勧めします。共有クラスターパターンには前述のようにいくつかの欠点がありますが、そのシンプルさと管理のしやすさはそれらの欠点を上回ります。さらに、ScalarDB Cluster はすべての重要な状態を基盤となるデータベースに保存し、メモリには重要な状態を保持しないため、データベースへの単なるパスとして見ることができます。したがって、共有クラスターパターンのシステムは依然としてサービスごとのデータベースパターンに準拠しており、マイクロサービスの理念にあまり違反していないと考えています。
共有クラスターパターンの欠点が受け入れられない場合は、分離クラスターパターンを使用できます。ただし、2フェーズコミットインターフェースのメカニズムと使用方法を適切に理解している場合にのみ、このパターンを使用してください。そうでない場合、データベースの異常などの問題が発生する可能性があります。
制限事項
ScalarDB は、CRUD、SQL、Spring Data JDBC などのいくつかの API を提供します。 CRUD および SQL インターフェースは共有クラスターパターンと分離クラスターパターンの両方をサポートしていますが、Spring Data JDBC インターフェースは共有クラスターパターンをサポートしていません。これは、Spring Data JDBC の1フェーズコミットインターフェースが現在、アプリケーションがモノリシックであり、相互にやり取りするマイクロサービスに分割されていないことを前提としているためです。Spring Data JDBC インターフェースは、他の API と同様に、2フェーズコミットインターフェースと分離クラスターパターンをサポートしています。