私たちのシステムにはどのような分散ロックが必要ですか?

共有リソースへの相互排他アクセスは、多くのビジネス システムが解決する必要のある問題です。分散システムでは、分散ロックはよく使用される一般的なソリューションです。この記事では、Alibaba Cloud Storage における分散ロックの実装原則、テクノロジの選択、および具体的な実践について説明します。

1. 単一マシンロックから分散ロックへ

単一マシン環境では、共有リソース自体が排他制御機能を提供できない場合、複数のスレッド/プロセスによる共有リソースへの同時読み取りおよび書き込みアクセスによるデータ破損を防ぐために、サードパーティが提供する排他制御機能が必要です。これは多くの場合、相互排他機能を提供するカーネルまたはクラス ライブラリです。次の図に示すように、プロセスはまずカーネル/クラスライブラリから排他ロックを取得し、ロックを取得したプロセスは共有リソースに排他的にアクセスできるようになります。分散環境へ進化する場合、同じ機能を提供する分散サービスが必要になります。さまざまなマシンがこのサービスを通じてロックを取得します。ロックを取得したマシンは、共有リソースに排他的にアクセスできます。このようなサービスは分散ロック サービスと呼ばれ、ロックは分散ロックとも呼ばれます。

​​

単一マシンロックから分散ロックへ

分散ロックの概念を抽象化しましょう。まず、分散ロックは、同時実行制御を提供し、排他状態を出力できるリソースである必要があります。つまり、ロック = リソース + 同時実行制御 + 所有権表示です。

一般的なスタンドアロン ロックを例に挙げます。

• スピンロック = BOOL +CAS (楽観的ロック)
• ミューテックス = BOOL + CAS + 通知（悲観的ロック）

Spinlock と Mutex はどちらも Bool リソースであり、アトミック CAS 命令によって 1 に設定されます。現在 0 の場合、成功した場合はロックが保持され、失敗した場合はロックは保持されません。 AtomicInteger などの所有権表示が提供されていない場合は、リソース (Integer) + CAS を介しても、所有権が明示的に要求されないため、ロックとはみなされません。もちろん、「所有権表示」は、ある形態のサービス提供をパッケージ化したものと考えることもできます。

単一マシン環境では、カーネルは「神の視点」を持ち、プロセスの生存を知ることができます。プロセスがハングアップすると、プロセスによって保持されているロック リソースが解放される可能性があります。しかし、分散環境に発展すると、これが課題になります。さまざまなマシンの故障やダウンタイムに対処するには、ロックに新しい機能である可用性を提供する必要があります。

次の図に示すように、3 つの機能を提供するサービスであれば、分散ロック機能を提供できます。リソースには、ファイル、KV などがあります。ファイルや KV の作成などのアトミック操作を通じて、所有権は作成結果の成功によって示され、ロックの可用性は TTL またはセッションを通じて保証されます。

​​

分散ロックの特徴と実装

2. 分散ロックのシステム分類

ロック リソース自体のセキュリティに基づいて、分散ロックを 2 つのグループに分けます。

• MySQL、Tair、Redis などの非同期レプリケーションに基づく分散システム。
• zookeeper、etcd、consul などの、paxos プロトコルに基づく分散一貫性システム。

非同期レプリケーションに基づく分散システムには、データ損失 (ロック損失) のリスクがあり、十分に安全ではありません。多くの場合、きめ細かいロック サービスを提供するために TTL メカニズムが使用されます。このシステムはアクセスが容易で、時間に非常に敏感で、有効期間を短く設定し、短期間のタスクを実行することが期待され、ロック損失がビジネスに与える影響が比較的制御可能なサービスに適しています。

Paxos プロトコルに基づく分散システムは、一貫性プロトコルを通じてデータの複数のコピーを確保し、高いデータ セキュリティを実現します。多くの場合、リース (セッション) メカニズムを通じて粗粒度のロック サービスを実行します。このシステムには一定のしきい値が必要であり、セキュリティに非常に敏感で、ロックを長時間保持することを希望し、ロックの損失を想定していないサービスに適しています。

3. Alibaba Cloud Storage 分散ロック

Alibaba Cloud Storage は、長年の実践の中で、分散ロックの使用の正確性を向上させ、ロックの可用性を確保し、ロックの切り替え効率を向上させる方法について多くの経験を蓄積してきました。

1 厳格な相互排除

相互排他性は分散ロックの最も基本的な要件です。ユーザーにとっては、「1 つのロックを複数のユーザーが占有することはできない」ことを意味します。では、ストレージ分散ロックはどのようにしてこの状況を回避するのでしょうか?

答えは、サーバー上の各ロックは一意のセッションにバインドされており、クライアントはハートビートを定期的に送信してセッションの有効性を確認し、それによってロックの所有権を確保するということです。ハートビートを維持できない場合、セッションと関連するロック ノードが解放され、ロック ノードを再度プリエンプトできるようになります。ここでの重要なポイントは、クライアントとサーバー間の同期を確実にして、クライアントがサーバー セッションの有効期限が切れたことを感知できるようにすることです。

下図に示すように、セッションの有効期間はクライアントとサーバーの両方で維持されます。クライアントはハートビートが送信された時点 (S0) からカウントを開始し、サーバーはリクエストが受信された時点 (S1) からカウントを開始します。これにより、クライアントがサーバーより先に期限切れになることが保証されます。ユーザーがロックを作成した後、コア ワーカー スレッドは、コア操作を実行する前に十分な有効期間があるかどうかを判断できます。同時に、ウォールタイムに頼らず、システムクロックに基づいて時間を判断するようになりました。システム クロックはより正確になり、前進または後退しなくなります (秒単位の誤差はミリ秒単位、NTP ジャンプのシナリオではクロック レートが最大限に変更されます)。

​​

収納シーンの使い方

分散ロックの相互排除は完璧になったでしょうか?あまり。分散ロックサービスに基づくビジネスのアクセス排他性が破壊される状況が依然として存在します。

次の例を見てみましょう。下の図に示すように、クライアントは時点 (S0) でロックを取得しようとし、時点 (S1) でバックエンドのロックを正常に取得し、分散ロック有効期間ウィンドウを生成します。有効期間中、時点（S2）でストレージにアクセスする操作が実行され、すぐに完了しました。そして、時点（Ｓ３）において、ロックの有効期間がまだ有効であると判定され、ストレージへのアクセス操作が継続された。その結果、この操作には長い時間がかかり、分散ロックの有効期限を超えてしまいました。そして、この時点で、分散ロックが他のクライアントによって正常に取得され、2 つのクライアントが同時に同じデータ バッチを操作する可能性があります。可能性は存在しますが、確率は非常に小さいです。

​​

国境を越えたシーン

このシナリオの場合、具体的な解決策は、データを操作する際に十分なロック有効期間ウィンドウがあることを確認することです。もちろん、企業自体がロールバックメカニズムを提供する場合、ソリューションはより完全なものになります。このソリューションは、ストレージ製品で分散ロックを使用するプロセスにも採用されています。

より良い解決策として、ストレージ システム自体に IOFence 機能を導入する方法があります。ここで、Martin Kleppmann 氏と redis の作者である antirez 氏の間の議論について言及する必要があります。非同期レプリケーションによって発生するロック損失の問題を防ぐために、Redis では redlock が導入されました。このソリューションでは多数決メカニズムが導入され、多数決ロックの取得が必要となり、可用性と正確性が最大限に保証されました。しかし、まだ 2 つの問題が残っています。

• 信頼性の低いウォールタイム (NTP 時間)
• 異機種混在システムでは厳密な正確性は達成できない

ウォールタイムは非ウォールタイムの MonoticTime によって解決できます (Redis は現在もウォールタイムに依存しています) が、異種システム内の 1 つのシステムのみの完全な正確性を保証する方法はありません。下図のように、Client1 がロックを取得し、データ操作時に GC が発生します。 GC が完了すると、ロックの所有権が失われ、データの不整合が発生します。

​​

異機種混在システムでは完全な正確性は達成できない

したがって、完全に正しい相互排他的アクセスを完了するには、2 つのシステムが同時に連携する必要があります。 IOFence 機能がストレージ システムに導入されました。下の図に示すように、グローバル ロック サービスはグローバルな自己増分トークンを提供します。ロックを取得した後にクライアント 1 から返されるトークンは 33 であり、これがストレージ システムに持ち込まれ、GC が発生します。クライアント 2 がロックを正常に取得し、34 を返すと、それがストレージ システムに持ち込まれ、ストレージ システムはそれより小さいトークンの要求を拒否します。その後、クライアント 1 が長時間のフル GC の後に回復し、再度データを書き込むと、ストレージ層に記録されたトークンが更新されているため、トークン値 33 を持つ要求は直接拒否され、データ保護の効果が得られます (Chubby の論文に記載されており、Martin Kleppmann が提案したソリューションでもあります)。

​​

IOFence機能の紹介

これは、Alibaba Cloud の分散ストレージ プラットフォーム Pangu の設計コンセプトと一致しています。 Pangu は、IO Fence と同様の書き込み保護機能をサポートし、インライン ファイルのファイル タイプを導入し、IO Fence と同様の書き込み保護機能を持つ SealFile 操作と連携します。まず、SealFile 操作を使用して、すでに開かれている cs 上のファイルを閉じ、古い所有者が引き続きデータを書き込みできないようにします。 2 番目に、InlineFile は古い所有者が新しいファイルを開くのを防ぐことができます。これら 2 つの関数は、実際にはストレージ システムでトークンのサポートを提供します。

2 可用性

ストレージ分散ロックは、継続的なハートビートを通じてロックの堅牢性を保証するため、ユーザーは可用性にあまり注意を払う必要がありませんが、異常なユーザー プロセスがロックを占有し続ける可能性もあります。このシナリオでは、ロックが最終的にスケジュールされるようにするために、ロックを安全に解除するためのセッション ブラックリスト メカニズムが提供されます。

ユーザーは、疑似停止を経験したプロセスによって保持されているロックを解除する必要がある場合、セッション情報を照会し、セッションをブラックリストに登録することができます。その後、ハートビートが正常に維持されなくなり、最終的にセッションが期限切れになり、ロックノードが安全に解放されます。ここではロックを強制的に削除するのではなく、次の理由によりハートビートを無効にすることを選択します。

• ロック削除操作自体は安全ではありません。ロックが他のユーザーによって取得されている場合、ロック削除要求によって誤って削除される可能性があります。
• ロックが削除された後も、ロックを保持している人のセッションは通常のままです。依然としてロックを保持していると認識されているため、ロックの相互排他原理が破られています。

3 スイッチング効率

プロセスによって保持されているロックを再スケジュールする必要がある場合、保持者はロック ノードを積極的に削除できます。ただし、保持者に例外が発生した場合 (プロセスの再起動、マシンのクラッシュなど)、新しいプロセスは、ロックを正常にプリエンプトする前に、元のセッションの有効期限が切れるまで待機する必要があります。デフォルトでは、分散ロックで使用されるセッションの有効期間は数十秒です。ロックを保持しているプロセスが予期せず終了した場合 (ロックを積極的に解放せずに)、ロック ノードが再びプリエンプトされるまでに長い時間がかかることがあります。

​​

クライアントとサービスはそれぞれ有効期限を維持します

切り替えの精度を向上させるには、セッションのライフサイクルを基本的に圧縮する必要があります。これは、ハートビートの頻度が速くなり、バックエンドのアクセス負荷が大きくなることも意味します。セッションライフサイクルをさらに圧縮するために最適化しました。

同時に、デーモン プロセスがロックを保持しているプロセスがクラッシュしたことを検出するシナリオなどの特定のビジネス シナリオと組み合わせて、ロックの CAS 解放操作が提供され、プロセスが待機なしでロックを取得できるようになります。例えば、プロセスの一意の識別子をロックノードに格納することで、使用されなくなったロックを強制的に解放して再競合させることができます。この方法により、プロセスのアップグレード後や誤って再起動した後にロックを取得するために必要な待機時間を完全に回避できます。

結論

分散ロックは、分散環境内の共有リソースへの相互排他的アクセスを提供します。企業は、効率性を向上させるために分散ロックに依存するか、アクセスの絶対的な相互排除を実現するために分散ロックに依存します。同時に、分散ロック サービスにアクセスする際には、アクセス コスト、サービスの信頼性、分散ロックの切り替えの精度や正確性などの問題を考慮する必要があります。分散ロックを正しく合理的に使用するには、継続的な思考と最適化が必要です。

参考文献

分散ロックのやり方 - Martin KleppmannRedlock は安全ですか? - アンチレズチャビー論文 - グーグル