マイクロサービス化による「DB分割」で開発、運用が難しくなるこれだけの理由：時代は「統合」から「分離」へ

ビジネス環境や技術の激しい変化に追従するため「マイクロサービス」に注目が集まっている。だが有識者によると「システムの機能を小さなサービスで切り出すだけではデータベースの面で複雑さが増し、管理が難しくなる」という。

[PR／＠IT]

PR

大きく変化した「人とシステム」の関係

　企業におけるDX（デジタルトランスフォーメーション）の取り組みが加速する中で、「マイクロサービスアーキテクチャ」（以下、マイクロサービス）の注目度が増している。マイクロサービスは、複数の小さなサービスを組み合わせて一つのシステムを構成するという考え方だ。

　マイクロサービスのような「疎結合アーキテクチャ」自体は以前からあるが、「クラウド」「モバイル」といった技術や考え方が普及したことで最近特に注目されている。こう語るのは、Scalarの深津 航氏（CEO、COO＜最高執行責任者＞）だ。

Scalarの深津 航氏

　「技術の進歩によって人とシステムの関係が大きく変化した2000年ごろは、社内の情報は社内のシステムに格納され、他社と情報をやりとりするのは主に“人”だった。しかし、2010年ごろになると企業と企業のやりとりも、メールや電話だけでなく、スマートフォンのアプリケーションやWebシステムなどを使うことが増えた。こうして“人と人”のやりとりが、“システムとシステム”に変わっていった。2015年にはJSON APIの仕様が統一（2015年5月に安定バージョン1.0をリリース）され、APIを相互利用するハードルが下がったことも影響している」（深津氏）

　こうした変化に対応するためには、機能やサービスを素早く開発できる仕組みが必要になる。また、技術の進歩とともにシステムの更新頻度も増えている。深津氏は「スマートフォンのOSが3カ月ごとに更新されるとするとアプリケーションもそのたびに改修しなければならない。顧客や取引先のシステム接続先も頻繁に変化するかもしれない。そうした変化に自社のシステムは追随する必要がある」と言う。マイクロサービスが注目されているのは、こうした素早い開発や頻繁な更新作業に適しているからだ。

　一方、深津氏はシステムだけでなく「組織にも柔軟性が求められる」とも指摘している。開発や運用の担当者が固定されていると負荷が集中し、“人”がボトルネックになり得る。だが、マイクロサービス化で分割された機能ごと、サービスごとで柔軟に担当者を入れ替えられれば、そうした懸念は減らせる。「開発体制や組織づくりの観点で見てもマイクロサービスの重要性は増している」と深津氏は述べている。

「データ構造」と「データの不整合」をどう解消するか

　日本では開発や運用をSIer（システムインテグレーター）に任せている企業は多いが、「任せっきりでは変化に適応したサービスを提供するのは難しい」と深津氏は指摘している。

　「全てを内製化することは難しいが、外部リソースを活用しても柔軟に開発できる体制に変えることは可能だ。例えばシステムをマイクロサービス化すれば、特定の機能やサービスに絞って外注できる。逆に、マイクロサービスに取り組まなければ、変化に対応できないシステムを抱え続けることになり、それがビジネスリスクになりかねない」（深津氏）

　だが、既存システムをマイクロサービス化する、新規でマイクロサービスのシステムを構築するといっても課題がある。深津氏は解決の優先度が高い課題としてデータベースを挙げる。

データ構造の課題

　この課題が発生するのは、マイクロサービス化するシステムのデータベースがRDB（リレーショナルデータベース）の場合だ。

　「モノリシックなシステムでRDBを使っている場合、データの整合性はテーブル間の結合関係によって確保される（参照整合性）。そのため、『どのアプリケーションがどのテーブルをどのようなルール（制約）で利用しているか』を把握しなければシステム改修が難しくなる。また、アプリケーションで使う項目を新たに追加する場合は、結合させるテーブルを追加したりカラムを増やしたりしなければならない」

モノリシックとマイクロサービスでのデータベースの違い

データ不整合の課題

　データの不整合が発生しがちなのは、データベースをサービスごとに分離したりRDBから「NoSQL」に切り替えたりするときだと深津氏は言う。

　「NoSQLは、“Key”（キー）ごとにデータを分散して格納している。キーが異なれば処理は競合しないため、スケールアウト（またはスケールイン）しやすいというメリットがある。一方、『キーをまたがったデータ項目同士の整合性が保たれているかどうか』をチェックすることが難しい。そのためアプリケーションでデータの整合性を確保するビジネスロジックを実装する必要がある」（深津氏）

　これは、1つのRDBに全てのデータを格納している時には問題にならないが、「複数のデータベースを連携させて利用したり、データの整合性をアプリケーション側で管理したりする場合には課題になる」と深津氏は指摘している。

マイクロサービスは「トランザクション管理」に要注意

　これらの課題で特に考慮が必要なのは以下のようなケースだ。

• マイクロサービス化でどの機能をどの単位で切り出すかを決める
• 既存のRDBの性能問題を解決するためにNoSQLに移行する
• データの整合性を保つため、アプリケーションにビジネスロジックを実装する

　「例えばコンシューマー向けサービスやIoT（Internet of Things）を使ったサービスを提供する場合、データベースには1秒間で数万件以上のアクセスが発生することがある。また、ピーク時とそれ以外で落差が激しいという特徴もある。RDBではパフォーマンスやスケーラビリティの面ですぐに限界を迎えてしまうし、NoSQLではデータの不整合が発生する可能性もある」

　マイクロサービスにおいては「Sagaパターン」や「TCC（Try、Confirm、Cancel）パターン」などのアーキテクチャを利用することで分散トランザクションが管理できるが、「どちらも『結果整合性』モデルになるため、“更新処理中の中間状態“がアプリケーションから見えてしまう。このため、『ルールを無視して直接データベースにアクセスする』といった“行儀の悪いアプリケーション”が1つあるだけで、中間トランザクションが更新されず、全てが破綻してしまう」と深津氏は指摘している。

1つの“ルール違反”が全体に影響する

　マイクロサービス化で他のサービスに影響しない「疎結合なシステム」を実現したはずなのに、ルールに基づいていないサービスが1つあるだけでシステム全体に影響が出てしまう。

　こうした課題を解消するのがScalarの「ScalarDB」だ。

　ScalarDBは、さまざまなデータベースで稼働させられる汎用（はんよう）的なトランザクションマネジャーだ。NoSQLなどACIDトランザクション機能を持たないデータベースにその機能を持たせ、複数のデータベースやサービスにまたがる分散トランザクションを実現する。

　「ScalarDBを使うことで、SagaパターンやTCCパターンでは対応しにくい結果整合性の問題にも対応できる」と深津氏は説明している。

Sagaパターン、TCCパターンとScalarDBの違い

　深津氏はSagaパターンとTCCパターンの特徴について次のように説明している。

　「Sagaパターンは、起点となるサービスから関連するサービスへイベントを送り出し、各サービスでローカルトランザクションを実行するといった仕組みだ。ローカルトランザクションが途中で失敗した場合は、用意しておいた『補償トランザクション』を実行してデータをリカバリーする。TCCパターンは『調停者』を使うところがSagaパターンと異なる。各サービスで『Try』（仮登録）を実行し、問題なければ『Confirm』（本登録）を実行する。Tryが失敗した場合は調停者が各サービスに『Cancel』（取り消し）の指示を出すといった流れになる」

　深津氏はこれらの処理の課題を2つ挙げる。

　「1つは、どちらの方式も更新処理中の中間状態が見える“結果整合性”でデータ整合性を確保するということ。もう1つは、処理が失敗したときの補償トランザクションやCancel処理を組み込む必要があり、実装やテストにかかるコストが大きくなることだ」

　ScalarDBは、「2フェーズコミット」（Two-Phase Commit）でサービスをまたがったトランザクションを実行することで、これらのアーキテクチャのデメリットを解消している。

マイクロサービス化におけるデータの課題と対策

　「2フェーズコミットでは標準プロトコル『XA』が使われることが多いが、XA準拠のDBMSにしか利用できないというデメリットがある。そのため、ScalarDBは独自のプロトコルを実装し、RDBMSだけでなく、NoSQLを含むさまざまなDBMSで使えるようにした。『Java』『GraphQL』『SQL』などの言語やインタフェースにも対応しており、コンテナとしてデプロイできるため、クラウドに依存せず利用できることが大きな特徴といえる」（深津氏）

　ScalarDBはCNCF（Cloud Native Computing Foundation）が発表する「CNCF Landscape」のDatabaseカテゴリーに登録されるなど、海外からも評価されている。なお、「データの真正性」（改ざんされていないかどうか）の確保についてはScalarDB上で動作する「ScalarDL」という製品で対応可能だ。トヨタ自動車の知財DXプラットフォーム「Proof Chain of Evidence」で採用されるなど、大手企業での実績もある。

やむを得ないかも、と考えていたトランザクションの課題を解消

　ScalarDBは進化を続けている。2023年2月時点の最新バージョン「ScalarDB 3.8」では、複数のマイクロサービスをまたがるトランザクションを容易に管理できる「ScalarDB Cluster」機能を提供している。今後は「ScalarDBとつながっているデータベースに横断的にアクセスできる機能やインメモリ処理ができるアナリティクスエンジンの追加、『MongoDB』『Redis』『Kafka』などのサポートを検討している」という。

　「『統合ではなく分離、分割する』という“データベースのパラダイムシフト”が起きている。その中で、われわれはScalarDBを通じてデータベースにまつわる企業の課題解決を支援する」と深津氏は力強く語る。