知らなかったでは済まされない、「マネージドDB」に潜む“データ不整合”のリスクとは：「過去に起きた大規模障害を踏まえ、対策すべきだ」

マネージドサービスを活用すれば、運用負荷を削減し、DX実現に向けた取り組みに注力できるだろう。注意点としては「万が一の備え」ができているかどうかだ。

[PR／＠IT]

PR

マネージドDBサービスの利用拡大で見えてきた課題

　DX推進においてクラウド活用は不可欠な要素となった。さまざまなクラウドサービスが活用されているが、最近では「マネージドサービス」に注目が集まっているという。運用に関する部分をクラウドベンダーに任せることで、アプリケーション開発など新しいビジネス価値創出につながる業務に集中できるというのがその理由だ。

Scalarの深津 航氏

　代表的なのはインフラのマネージドサービスだが、データベースなどのミドルウェアを対象としたものも増えており、さまざまな領域でシステムの構築と運用にかかる負担を減らすことができるようになった。「特にデータベースの構築と運用負荷を軽減できた点は大きい」と語るのはScalarの深津 航氏（CEO、COO＜最高執行責任者＞）だ。

　「従来データベースは、将来のデータ量を予測し、必要なリソースをサイジングして設計しなければならなかった。マネージドデータベースサービス（以下、マネージドDBサービス）が登場したことで、今、必要なデータベースリソースを必要なだけ利用し、それに見合うコストを支払えばよくなった。これによって、これまで当たり前だった『コスト削減のために企業内のデータベースをできるだけ統合しよう』という考え方から『各サービスで必要なデータベースリソースを柔軟に調達しよう」という考え方に変わってきている。さらに、これまで構築や運用にかかる手間が大きく、余力がない企業は手が出しにくかった『分散データベース』や『NoSQL』といったデータベースも利用しやすくなった。サービスの開発者は目的に応じて、目的に合ったデータベースを選択できる時代になった」（深津氏）

　しかし、マネージドDBサービスを採用することで、新たな課題に直面する企業もあるという。深津氏は「マネージドDBサービスは、ユーザーの自由度や管理の柔軟性とのトレードオフという側面もある」と指摘している。

「ベンダーロックイン」と「データの不整合」という課題

　深津氏はScalarに寄せられた顧客からの意見について次のように分析している。

　「お客さまと話していて感じるのは『Amazon Web Services』（AWS）、『Microsoft Azure』（Azure）、『Google Cloud Platform』（GCP）などのクラウドサービスを積極的に利用している企業ほど、オンプレミスではデファクトスタンダードともいえる『Oracle Database』以外のデータベースやマネージドDBサービスを検討する企業が増えているということだ。しかも、複数のマネージドDBサービスを組み合わせているお客さまも多い。AWSなら『Amazon RDS』『Amazon Aurora』と一緒に『Amazon DynamoDB』（以下、DynamoDB）、『OpenSearch』などのデータベースやツールを利用するなど。最近ではNoSQLに関する問い合わせも増えている。こうした背景もあり、データベースに求められる機能も変わってきていると感じる」（深津氏）

　もちろん、こうした求められる要件の変化にクラウドベンダーも対応している。可用性の確保については「SLA」（Service Level Agreement）の形で公開しているし、バックアップやリストアなどの機能も提供している。また、ほとんどのクラウドサービスはAPIを積極的に活用しており、ビジネスロジックをAPIで実装しているケースも多いという。このため、「ジョイン（テーブル結合）やストアドプロシージャなどを使う、リレーショナルデータベース内の複雑な処理は減っている」と深津氏は言う。

　しかし、クラウドベンダーが進めるこうした取り組みは、企業にとって「もろ刃の剣」になり得る。それは「クラウドベンダーへのロックイン」だ。

　「データベースはクラウド間の移行が難しいことが多く、特定のクラウドベンダーに依存しがちだ。しかし、依存したクラウドベンダーで大規模障害が発生した場合、多くのサービスがそれに巻き込まれてしまうリスクがある。また、ベンダーロックインが発生すると、そのクラウドベンダーの意向に自社のシステムが左右されるといったリスクも考えられる」（深津氏）

　深津氏はさらに追加で、マネージドDBサービスで起こりがちな「データの整合性の確保」という課題を挙げる。

　「マイクロサービス化などを進めると複数のサービスがそれぞれ独立したデータベースを保持することになるので、サービス間でデータの整合性をどのように保つかが課題になる。シンプルな解決方法としては、各サービスのアプリケーションがデータベース間の整合性を確保することだ。ただ、その方法では“更新処理中の中間状態“を管理する必要があるため、サービスの数が増えるほど管理が複雑になり、処理を実装する難易度も増す。また、更新の途中で障害が発生してしまうと各サービスで使っているデータベースの“静止点”が異なるため、復旧してもデータベース間で不整合が発生する可能性が高い」（深津氏）

大規模障害時にデータの一貫性をどう確保する？

　「ベンダーロックイン」と「データの整合性」というマネージドDBサービスの2つの課題について詳しく見ていこう。

　ベンダーロックインの要因となる「複数クラウド間でのデータベース移行の難しさ」については対処法がある。あらかじめ他のクラウドにもサーバやデータベースといったインフラを構築しておき、大規模障害発生時に切り替えるという方法だ。コンテナ化でアプリケーションのポータビリティ性は上がっているし、SQLなどの標準的な仕様を使っているのであれば、データベースの移行も比較的スムーズだ。

　だが問題は、NoSQLをはじめとする、クラウドベンダーによって異なる仕様やインタフェースで運用されているデータベースを使っている場合だ。深津氏は「もしもに備えてNoSQLのデータを移行しようとしても、仕様やインタフェースが異なるため他のクラウドベンダーが提供するNoSQLへの移行は困難になる。実質、データベースによってクラウドベンダーにロックインされた状態になっている」と指摘している。

　大規模障害そのものを防ぐことは難しいが、迅速にバックアップやリカバリーをすれば影響を最小限にできる。しかし、複数のマネージドDBサービスを利用している、マイクロサービス環境でデータベースを運用しているといった場合は、バックアップやリカバリーの際にデータの整合性をどう確保するかが課題になってくる。

　「複数のサービスにまたがったデータベースを管理している場合、障害復旧時にはデータの整合性も修復する必要がある。AWS、Azure、GCPは『Sagaパターン』『TCC（Try、Confirm、Cancel）パターン』と呼ばれる“マイクロサービス環境でデータの整合性を保つためのアーキテクチャ”を公表している。ただSagaパターンやTCCパターンは処理が複雑で開発時の負担になりやすい。また実装したとしても、大規模障害時に確実にデータの整合性を保てるかどうかは分からない。過去に起きた大規模障害を踏まえ、データの整合性を保つ仕組みをあらかじめ採用しておく必要がある」（深津氏）

汎用トランザクションマネジャー「ScalarDB」がもたらす価値

　こうした課題を解決するのが「ScalarDB」だ。ScalarDBはScalarが開発、提供する汎用（はんよう）トランザクションマネジャーで、複数データベース間（異なるデータベース間、異なるマイクロサービス間など）のトランザクションを管理する。ScalarDBの配下にある複数のデータベースに対し、1つのエンドポイントからアクセスできる。さらに、クラウドベンダーごとに異なるデータベースを利用している場合であっても同じインタフェースが利用できるという特徴がある。

　ScalarDBは国内外で多くの実績がある。国内でいえばマイナビでの採用事例がある。

マイナビの採用事例

　マイナビが提供するレファレンスチェックサービス「TRUST POCKET」では、アンケートなど多くの非構造データを取り扱うため、データベースにDynamoDBを利用している。ただ、DynamoDBにはトランザクションに関する幾つかの制約がある。「Read Only、Write Onlyのトランザクションのみ」「トランザクションは上限100件まで」「トランザクション処理は1MBのデータまで」などだ。

　そこでマイナビはテーブル間のトランザクション管理用にScalarDBを導入。DynamoDBの柔軟性を維持したまま柔軟な要件変更に対応できるシステムを構築した。

　「マイクロサービスは基本的に、サービスごとに最適なデータベースを利用する『ポリグロットパーシステンス』（polyglot persistence）という考え方を採用している。データベースが分散しているため、マイクロサービスのアプリケーション同士が、サービスをまたがって各データベースのトランザクションを管理する必要があるが、ScalarDBならそうした管理は不要だ」（深津氏）

　ScalarDBは、マネージドDBサービスを利用する際の2つの課題に対応している。ベンダーロックインの課題については、ScalarDBが各データベースの差異を吸収することで解決する。

ScalarDBがデータベースの差異を吸収する

　異なるクラウドベンダーのデータベースに移行しても、これまでと同じようにアプリケーションを動かせるため、ベンダーロックインを回避できる。「これまでベンダーロックインを気にして実施しにくかったオンプレミスからクラウド、クラウドからクラウドへの移行も容易になる」と深津氏は言う。

　データ整合性の課題は、リカバリー時にデータベースの整合性を確保する機能で解決する。

　「例えば『Transaction Pause』はトランザクション処理を任意のポイントで一時停止できる。クラウドベンダーが提供するデータベースには『Point-in-Time Restore』『Point-in-Time Recovery』（以下、PITR）という静止点を作る機能があるので、Transaction Pauseを実行し、データベースへのアクセスを一時停止してからPITRを実行すれば、ScalarDB配下にある全てのデータベースに同じ静止点を作ることができる」（深津氏）

静止点を作成することで不整合を防ぐ

　ScalarDBは、マイクロサービス環境やマルチクラウドなどでマネージドDBサービスを利用する際に直面する課題を解決できる製品だ。クライアントライブラリ形式の「オープンソース版」とコンテナ形式の「商用版」を提供している。オープンソース版はCNCF（Cloud Native Computing Foundation）が発表する「CNCF Landscape」のDatabaseカテゴリーに登録されるなど、海外からも評価されている。「ScalarDBクラスタ」など、新しい機能の提供も予定し、開発も活発だ。

　マネージドDBサービスの利用拡大に伴って、想定外のリスクに直面するケースが増える可能性は高い。マネージドDBサービスを利用する企業は、ScalarDBでいつか来るリスクに備えておくのがいいだろう。