モダナイゼーション10の罠｜5.データ整合性の罠

「データ整合性の罠」とは？

コンピューター・システムやその上で稼働するアプリケーションが、以前よりも増してより複雑なビジネス上の役割や社会機能を担い、より複雑な業務データやその関連をもって構成・表現され、より大きな規模で利用されるようになっています。

また、その個々のアプリケーションの開発には適材適所なテクノロジーが用いられ、環境は複数のクラウドやオンプレミスに分散され、クラウド化された既製の業務サービス部品を取り入れることも一般的になりつつあります。それら分散化された機能や部品は、マイクロサービスやAPIといった手法を用いて分離独立して定義・管理され、複数のアプリケーションから再利用できるように設計されることが重要なキーとなる場合が多くあります。

これによりアプリケーションの独立性／疎結合性、変更しやすさが確保され、データ管理も分離・独立するだけでなく、業務やデータの性質に応じたテクノロジーを採用すること（Polyglot Persistenceと呼ばれます）も可能となります。こういった分散化のメリットを享受する事により、短いtime-to-marketでのビジネス展開や、ビジネス試行を繰り返しながら顧客サービスを改善し続けることが可能となるのです。

さて、業務機能とその配下のデータが分散して配置されることで、分散化された異なる業務データ間で一時的な不整合状態（図1）が生じることがあります。また、同一業務上のデータであっても、更新しかかり中の当事者データとそのデータを参照する他者から見えるデータが一時的に不整合（図2）となることもあります。

こういった一時的な不整合の発生は「結果整合性」と呼ばれる考え方（値の整合に一定時間を要する）に基づいており、本稿では「データ整合性の罠」と呼びます。分散化がもたらすビジネス上のメリットは、この不整合のトレードオフとのセットで考える必要があるのです。

図１ サービスAとBの両方を順次呼び出し、業務データAとBの更新を行うケース

図2 サービスを通じ基幹業務データXを更新すると、参照用のX’が背後で複製されるケース

実際に起こっている問題

次のようなことが発生する可能性があります

• マイクロサービスやAPIを導入することにより得られる分散化のメリットには目を向けたが、そのトレードオフである整合性問題への対処の必要性を過小評価したために、開発後半でのコスト超過につながった。
• APIを利用したアプリ開発が迅速に行える反面、開発者が整合性の考え方をよく理解しないままに設計・実装し、失敗時の対処を漏らしたり、テスト不足につながったりすることが増えた。その結果、本番化後の高負荷時にAPI呼び出しが失敗する現象が発生すると、そのたびに意図しないデータ更新漏れが発生し、緊急の手対応によるデータ補償を実施する必要が生じた。
• データに一時的な不整合が生じることが、アプリ仕様や運用の中で認識されず、更新したはずなのに正しく反映されない等の利用者からの問い合わせが増加し、対処に追われた。
• 運用上発生する障害ポイントの考慮が漏れ、対処に時間がかかり、二度手間、三度手間の対処や後追いの恒久対応のための保守作業が生じ、開発コスト増につながった。

このような問題の背景としては、分散化を導入するビジネス上の意義への理解が希薄なままで漠然とテクノロジー主導で分散化を推し進めることがその一因として挙げられます。ビジネス上のメリットとトレードオフを併せて検討しないと、こういった不整合への対処を単なるオーバーヘッドで足手まといなものと敬遠したり、軽視したりすることにつながります。

また、この結果整合性の考え方は、従来型の一貫したトランザクション制御や即時の強い整合性を前提とした中央集権型のデータ処理に慣れている人にとっては受け入れ難く戸惑ったり、理解しても前提とすべき制約を見逃してしまうことがあります。さらには、整合性確保のための設計・実装が必要であることを見逃してデータを壊してしまったり、もしくは気がついても整合性が担保されるタイムラグやそれが業務に与えるインパクトが軽視され、その対処への正しい判断ができなかったりすることがあります。

「データ整合性の罠」の乗り越え方

第一に、分散されたシステムやそのAPIを利用するアプリ開発では、「結果整合性」や「べき等性」と言った考え方を理解し、それに基づいた設計・開発を進めることが重要です。整合性が求められる分散処理の後ではその結果状態を検証し、必要に応じたデータ補償を行う設計が必要となります。特に、データ更新を伴うような外部のAPI呼び出しが失敗した場合は、呼び出し側でのリトライ処理やリカバリー処理が必要となることに注意する必要があります。また、障害発生時の通知や運用方法、利用者への案内についても十分な考慮が求められます。

もし、より確実性の高い一貫性が必要な場合は、高度な補償処理（TCCやSagaパターンと呼ばれる処理）の導入を検討する場合もあります。ただし、単純なリトライ処理やユーザー自身のやり直しにより十分に業務が担保できるケースも多く、実際には高度な補償処理が必須となるケースは限られます。業務の性格に大きく左右され、不整合によるビジネス・インパクトとその対応コストとのトレードオフとなるため、補償処理の採用はこれら理解に基づいた適切な判断が必要です。

また、即時の強い整合性が必要な特定のサービスについては、更新トランザクションを分離・分散しない選択も検討に値します。分散化のメリットには逆行しますが、部分的に確実な整合性が必要となる不可分な業務サービスを識別することも重要であり、無理な分割を目的としてはなりません。

このような検討をする場合、議論が進むにつれて整合性への要求度合いが高くなる傾向もあります。一部業務の高い要求を、闇雲に全業務機能に準用したり、高い達成基準や開発標準を設定しそれを盲目的に広く採用したりすることで、開発コストや運用難易度が上がるケースもあります。システム視点で無理な均一化を計ろうとすることが、ビジネス上の分散化のメリットとのバランスを崩す結果にもつながります。過度な均一化や統制は、その効果を弱めることにも注意が必要です。

逆に、完全な分離型（polyglot型）のDBが増えると、インフラ視点でのシステム運用コストの圧迫が指摘されることもあります。これには、疎結合性を確保しながらも、複数のデータを集中管理する緩和的ソリューションを検討する余地があります。また、分散データ間の不整合タイムラグの最小化が求められ、それを緩和する方法が検討されることもあります。マルチコンテナやマルチモデル型DBの採用や、高速なevent stream型処理の併用などが、これにあたります。分散化のメリット最大化のために、それを補完する仕組みに目を向けることもまた大切です。

まとめ

分散型システムにより得られるビジネス上のメリットと、結果整合性の考え方にはトレードオフがあることを十分に理解し設計・実装する必要があります。分散化の妨げとなる、高い一貫性の確保が必要な業務を特定・識別することも重要です。また、整合性担保やその軽減にも様々なソリューションがありますので、業務特性に合わせた経済合理的な判断が求められます。

本ブログでは、モダナイゼーションを進めるうえで陥りがちな10の罠について、IBMの経験に基づき、傾向と乗り越え方をシリーズでお伝えしております。今後の解説もご覧ください。

参考文献
Martin Fowler氏解説：Microservice Trade-Offs–Eventual Consistency（結果整合性）（IBM外のWebサイトへ）

次の記事『モダナイゼーション10の罠｜6.可用性・信頼性の罠