QuickBooksを複数ユーザーでGoogle Driveに保存できない理由

具体的な内容に入る前に、これが一般的な概念であることを理解することが重要です。つまり、「なぜクライアント/サーバーまたは共有データベースファイルアプリケーションを、アクセスが単一ユーザーに制限されていない場合に、同期ストレージ（例：Google Drive、DropBox、NextCloudなど）に保存できないのか？」という問いに集約できます。QuickBooksは、1980年代スタイルのアプリケーションに共通する共有データベースファイルの仕組みを使用しており、単一のファイルまたはファイルセットがファイル共有メカニズムを介して共有され、個々のアプリケーションコピーがそれぞれこのファイルにアクセスして変更を加えます。Google Driveは同期ストレージの仕組みです。つまり、ある場所のデータを別の場所にコピーするものです。同じファイルで同時に作業している複数のユーザーは、互いの変更を上書きすることがあり、実際によく発生します。これらの変更は後で手動で調整されるか、無視されるか、またはユーザーが同時に作業しないよう制御されることが期待されています。

一部のマルチユーザーアプリケーションでは同期ストレージを活用できますが、それはストレージシステムがファイルをロックして他に編集者がいない場合のみ変更を許可できる状況に限られます。これには、汎用ファイル同期では実現不可能なレベルの統合が必要です。これを実現しているほとんどのシステムは、汎用的な同期ではなく、データベース層またはアプリケーション層に組み込まれた同期メカニズムを使用しています。同期ストレージでデータの整合性を維持するためには、一度に一人だけがファイルを編集し、そのファイルが「保存」された後にすべての潜在的なユーザーが更新を受け取るまで待ち、その後別のユーザーがファイルを編集してプロセスを繰り返すことが必要です。しかし、一度に一人のユーザーしか作業できず、そのユーザーは自分でファイルを開いて編集する前に他のユーザーの更新を受け取る必要があります。そうでなければ、システムはすべてのケースでどの変更を保持し、どれを破棄するかをユーザーに尋ねなければなりません。

この整合性プロセスは、現実的な方法でデータベースファイルには適用できません。ファイルは常に開かれてアクセスされるように設計されており、素早く開いて編集して保存するだけのものではありません。保存も手動ではなく、常に予測可能とは限りません。一般的には、使用中は継続的に保存が行われると想定していますが、キャッシュによってそれらの保存操作を手動で制御することは不可能になる場合があります。しかし、これはパフォーマンス上の理由から必要なことです。

混乱がよく生じるのは、他のユーザーが同時にシステムにアクセスする恐れのない単一ユーザーが、Google DriveやApple iCloudのような同期ストレージをバックアップメカニズムとして使用できるからです（単純に遠隔地にコピーを自動的に作成するだけです）。また、単一ユーザーがファイルを手動で場所から場所へ移動することなく、まずある場所で、次に別の場所でファイルを使用するための手段としても利用できます。その単一ユーザーが場所を移動する際に、キャッシュがフラッシュされ、同期とロックが完了するのに十分な時間を取るか、あるいは最初のアプリケーションインスタンスを開いたままにしていないことを確認する限り、安全なシステムと合理的に仮定できます（ただし完全には保証できません。このメカニズムは、その場合でもわずかなレースコンディションのリスクを持ちます）。アプリケーションを単一ユーザーモードで使用して同期ストレージを安全に使用できる「方法が存在する」ため、多くの非技術系の経理・財務担当者は、全く異なるマルチユーザーの同時アクセスも動作すると誤って想定してしまいます。しかし、それは不可能です。

何が起きるかというと、複数のユーザー間でレースコンディションが発生し、それが起きていないと完全には確認できなくなります。数値が大幅に不正確になることで、データが明らかに壊れておりレースコンディションが発生したことが疑いのない場合もあります。しかしより多くの場合、一部のトランザクションが確認後でさえも単純に失われます。

例を挙げましょう。ユーザー1は自宅にいて、QuickBooksに新しいレシートを入力します。この変更はローカルコンピューターへの保存を開始し、完了後、新しいファイルをクラウド（オンライン）のGoogle Driveに転送し始めます。ユーザー2はオフィスにいて、この間に請求書への顧客支払いを入力し始めます。ユーザー2のQuickBooksデータファイルのコピーは開いており、使用中は上書きできないため、Google Driveに送信中のコピーはユーザー2に届きません。ユーザー2が変更を保存すると、そのコピーもGoogle Driveに送信しようとします。Google Driveは今、同じ内容から始まったのに今は互いに大きく異なる変更が加えられた2つのドキュメントを処理しなければなりませんが、どちらのコピーも両方の変更を持っていません。それらをマージする手段がないため、ユーザー1をマスターとしてユーザー2の変更を破棄するか（例：先着優先）、ユーザー2の変更を受け入れてユーザー1の変更を破棄するか（例：最新優先）、またはもちろん、すべての変更を破棄してどれも受け入れないかのいずれかになります。どの場合でも、すべてのユーザーの財務トランザクションがローカルで保存された後でも保持されることはありません。ユーザー1またはユーザー2（あるいは両方）は、保存されたと信じていたデータが突然消えてしまうことになります。ユーザーが増えると、問題はさらに大きくなります。

問題の一部は、ファイルアクセスレベルで動作し、完全なファイルレベルでデータを同期・共有する場合、単一のレコードや行だけをロックしたり、トランザクションを分離したり、変更をマージしたりする方法がないことです。ファイルは単一のエンティティであり、変更されました。すべてか無かです。個々のQuickBooksアプリケーションは互いに直接通信することも、データベースファイルを通じて通信することもできず、書き込み、保存、読み取りなどを調整してこの問題を回避することができません。それらはブラインドであり、各々がファイルの独自のコピーを持っているため、他のアプリケーションが同時にファイルを操作しようとしていることを知ることができません。コピー間には通信を可能にする「共有」されたものが何もありません。コピーは互いに結びついておらず、ここには量子状態は関与していません。そして、遅いまたはバグのあるインターネット接続を使用している場合、あるいはインスタンスがオフラインの場合の1つ以上のアプリケーションインスタンスを使用することで生じる潜在的な問題を加えることができます。同期が最終的に行われるとき、上書きするか上書きされるかしなければならない数時間または数日分の変更が存在する可能性があります。ミリ秒ではなく、数日分のデータについて話していることがよくあります。

ローカル共有ファイルによるこの問題の処理は、多面的です。まず、そのファイルのコピーではなく、単一のファイルのみが存在します。そのため、すべての変更がアプリケーションのすべてのコピーに同時かつ瞬時に利用可能です。アプリケーションの1つのインスタンスがファイルにデータを書き込もうとするとき、クラスタードファイルシステムがSANの動作を許可する方法と同様のロックおよびアラートメカニズムを使用します。変更が行われていること、および他のアプリケーションインスタンスがそれが完了するまで待つ必要があることを信号で伝えることができ、続行する前にデータのコピーを更新します。書き込めるのは1つのインスタンスのみで、他のすべては待機しなければなりません。ロックは開始前に取得され、完了時に解放されるため、レースコンディションは存在しません。そして、すべてのインスタンスはデータが現在アクセス可能な限りにおいてのみ機能し、接続が失われると続行できません。これは重要なデータ整合性保護メカニズムです。一部のアプリケーションはこのメカニズムをさらに高いレベルに引き上げ、このプロセスをより迅速にしてより良いパフォーマンスを得るために、共有ファイルを介さない直接の通信チャネルを追加します。しかし、そのレベルに達すると、一般的には数十年前の設計に現代のマルチユーザーシステムを無理やり合わせようとするよりも、単純に現代のアプリケーションに移行する方がはるかに簡単なため、ここまで行うものはほとんどありません。

これにより、会計士がなぜ同期されたファイルが機能すると一般的に考えるのか、そして「私には機能した」と主張することがあるのに「運が良かった」または「マルチユーザー環境には適用されない全く異なるシナリオで使用していた」と言うべき理由、そして、なぜGoogle Drive、NextCloud、iCloud、DropBoxなどをQuickBooksや他のレガシースタイルのアプリケーションのバックアップやデータ転送に絶対に使用できるのに、データを無傷に保つことができないため、マルチユーザーアクセスを得る手段として使用しようとすることは考えられない理由が明確になったことを願っています。