Microsoft Azure Storageのデータへの同時アクセスの組織

現代のWebアプリケーションでは、複数のユーザーが同じデータを同時に操作する場合に状況がしばしば発生します。



各ユーザーのアクションを確実に成功させるために、アプリケーション開発者は、特にユーザーのグループによるデータの同時処理が本当に必要な場合、そのようなシナリオの処理と実装を慎重に検討する必要があります。



ほとんどの場合、開発者はデータへの同時アクセスを管理するために次の3つの戦略を使用します。

1. 楽観的並行性
   
   
   
   アプリケーションは、最後にアクセスされてからの変更をチェックした後にのみデータを更新します。
   
   
   
   たとえば、2人のユーザーが同じWikiページを表示しているときに、同時にそれを更新することにしました。
   
   
   
   この場合、wikiプラットフォームは、2番目のユーザーの更新が最初のユーザーの更新に置き換わらないプロセスを提供する必要があり、両方のユーザーはそれぞれのアクションが実行されたかどうかを理解します。
   
   
   
   この戦略は、Webアプリケーションで最も頻繁に使用されます。
   
   
   
   
2. 悲観的並行性
   
   
   
   この場合、アプリケーションは更新されたデータをブロックし、ロックが解除されるまで、つまり 最初のユーザーがデータの編集を完了するまで、それらへのアクセスは他のユーザーに制限されます。
   
   
   
   たとえば、マスター/スレーブのデータレプリケーションシナリオでは、原則としてマスターのみが更新を実行し、他の人がデータを編集できないように、長期データロックを設定できるのは彼だけです。
   
   
   
   
3. 最後の勝利（最後の作家が勝利）
   
   
   
   このアプローチにより、アプリケーションが最後にアクセスしてから更新のためにデータをチェックすることなく、データを使用して操作を実行できます。
   
   
   
   この戦略（または正式な戦略の欠如）は、通常、複数のユーザーが同じセクションにアクセスする可能性が除外されるようにデータが分散される場合に適用されます。
   
   
   
   また、上記の方法は、短期のデータストリームの処理に役立ちます。
   
   

この記事では、Azure Storageプラットフォームがデータウェアハウスを使用するアプリケーションの開発を簡素化し、同時アクセスを編成するための3つの戦略すべてをサポートする方法について説明します。

Azure Storage-クラウド開発を簡素化

Azure Storageは、データへの同時アクセスに関する3つの戦略すべてをサポートしていますが、ストレージはもともと厳密な同時実行モデル用に設計されているため、楽観的および悲観的同時実行をサポートする機能がいくつかあります。その後このデータにアクセスすると、最新の更新が検出されます。



整合性モデルを使用するストレージプラットフォームには、1人のユーザーが記録する期間と更新されたデータが他のユーザーに表示される期間との間の遅延が含まれます。



開発者は、適切なデータアクセス戦略を選択することに加えて、ストレージプラットフォームが変更の分離（トランザクション内の同じオブジェクトの部分的な変更）を整理する方法に注意を払う必要があります。



Azure Storageはスナップショット分離を使用して、単一のパーティション内で同時読み取りと書き込みを可能にします。



他の分離レベルとは異なり、スナップショットによる分離により、特に更新トランザクションの実行中に最後に保存された値を返す場合、更新が発生した場合でもすべての読み取り操作でデータの一貫したスナップショットが確認されます。

BLOBへの同時アクセスの構成

BLOBサービス内のBLOBおよびコンテナーへのアクセスを制御するために使用する同時方式を選択できます。



戦略を明示的に指定しない場合、デフォルトで「最後に勝つ」戦略が使用されます。

BLOBとコンテナーの楽観的並行性

ストレージサービスは、保存されている各オブジェクトに識別子を割り当てます。 この識別子は、オブジェクトに対して更新操作が実行されるたびに更新されます。 識別子は、HTTPプロトコルで定義されたETagヘッダー（エンティティタグ）を使用して、HTTP GET要求への応答の一部としてクライアントに返されます。



このようなオブジェクトで更新を実行するユーザーは、特定の条件下でのみ更新が行われるように、元のETagとともに条件付きヘッダーを送信できます。この場合、条件はストレージサービスで必要な「If -Match」ヘッダーです。



このプロセスの概要は次のとおりです。

1. ストレージサービスからblobを取得します。応答には、ストレージサービス内のオブジェクトの現在のバージョンを識別するHTTP ETagヘッダーパラメーターが含まれます。
2. BLOBを更新するときは、サービスに送信するIf - Matchリクエストの条件ヘッダーに、前のステップから受信したETagパラメーターを含めます。
3. サービスは、要求内のETag値をBLOB内の現在のETag値と比較します。
4. blobの現在のETag値がIf - Match要求ヘッダーのETagと異なる場合 、サービスはクライアントにエラー412を返します。これは、クライアントが要求してから別のプロセスがblobを更新したことをクライアントに示します。
5. 現在のETag値が要求ヘッダーのETag値と変わらない場合、サービスは要求された操作を実行し、現在のblob ETag値を更新して、データの更新があったことを示します。

以下のC＃スニペットは、以前に抽出またはブロブに追加されたプロパティから取得したETag値に基づいてAccessConditionクラスを使用してIf-Match条件を作成する簡単な例を示しています 。



次に、この条件はblobの更新中にAccessConditionオブジェクトを使用します。AccessConditionオブジェクトはリクエストにIf-Matchヘッダーを追加します。



別のプロセスがblobを更新した場合、blobサービスはHTTP 412（Precondition Failed）メッセージを返します。



完全な例はこちらからダウンロードできます 。

//  Etag  ,   - UploadText string orignalETag = blockBlob.Properties.ETag; //       string helloText = "Blob updated by a third party."; //    etag,     (   etag) blockBlob.UploadText(helloText); Console.WriteLine("Blob updated. Updated ETag = {0}", blockBlob.Properties.ETag); //    ,   ETag,     try { Console.WriteLine("Trying to update blob using orignal etag to generate if-match access condition"); blockBlob.UploadText(helloText,accessCondition: AccessCondition.GenerateIfMatchCondition(orignalETag)); } catch (StorageException ex) { if (ex.RequestInformation.HttpStatusCode == (int)HttpStatusCode.PreconditionFailed) { Console.WriteLine("Precondition failure as expected. Blob's orignal etag no longer matches"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リポジトリサービスは、 If - Modified - Since 、 If - Unmodified - Since 、 If - None - Matchなどの他の条件付きヘッダーもサポートしています。



MSDNの詳細情報ドキュメント 。



次の表は、要求でIf - Matchなどの条件付きヘッダーを受け入れ、応答でETagを返すコンテナ操作を示しています。

運営	ETagを 返します	条件付きヘッダーを受け入れます
コンテナを作成	はい	いや
コンテナのプロパティを取得	はい	いや
コンテナメタデータの取得	はい	いや
コンテナのメタデータを設定する	はい	はい
コンテナACLを取得	はい	いや
コンテナACLを設定します	はい	はい（*）
コンテナを削除	いや	はい
リースコンテナ	はい	はい
BLOBを一覧表示する	いや	いや

（*）SetContainerACLで定義された権限はキャッシュされ、更新には30秒かかります。その間、更新の一貫性は保証されません。



この表は、If-Matchなどのリクエストで条件付きヘッダーを受け入れ、ETag値を返すblob操作を示しています。

運営	ETagを返します	条件付きヘッダーを受け入れます
ブロブを入れる	はい	はい
ブロブを取得する	はい	はい
Blobプロパティを取得	はい	はい
BLOBプロパティを設定する	はい	はい
BLOBメタデータを取得する	はい	はい
BLOBメタデータを設定する	はい	はい
リースブロブ（*）	はい	はい
スナップショットBLOB	はい	はい
ブロブをコピー	はい	はい（ソースおよび宛先BLOBの場合）
コピーBLOBの中止	いや	いや
ブロブを削除	いや	はい
ブロックを置く	いや	いや
ブロックリストを置く	はい	はい
ブロックリストを取得する	はい	いや
ページを置く	はい	はい
ページ範囲を取得する	はい	はい

（*）BlobリースはEtagを変更しません。

BLOBでの悲観的並行性

blobを排他的にブロックするには、リースメカニズムが使用されます。 リースを使用する場合、期間を15〜60秒、または終了なしで指定します。これは排他的ブロックを意味します。 また、ロックを拡張したり、作業を完了した後にBLOBのロックを解除したりすることもできます。 blobサービスの有効期限が切れると、blobサービスは自動的にリースを無効にします。



リースを使用すると、排他的書き込み/分割読み取り、排他的書き込み/排他的読み取り、分割書き込み/排他的読み取りなど、さまざまな同期戦略を使用できます。



リースが存在する場合、ストレージサービスは排他的エントリ（put、set、delete操作）を整理します。 読み取り操作の排他性を確保するために、開発者はすべてのクライアントアプリケーションがリース識別子を使用し、一度に1人のクライアントのみが適切なリース識別子を持つようにする必要があります。 リース識別子を含まない読み取り操作は、共有読み取りで発生します。



以下のコード（C＃）は、Blobでの排他的な30秒のリース、Blobの更新、リースの終了を示しています。 blobに必要なリースが既にインストールされている場合、新しいものをインストールしようとすると、blobサービスは「HTTP（409）Conflict」という結果を返します。



ストレージサービスのBLOBを更新する要求を作成するとき、コードでは、リースに関する情報のために、AccessConditionオブジェクトが使用されます。



完全な例はこちらからダウンロードできます 。

 //    15  string lease = blockBlob.AcquireLease(TimeSpan.FromSeconds(15), null); Console.WriteLine("Blob lease acquired. Lease = {0}", lease); //  ,  .     const string helloText = "Blob updated"; var accessCondition = AccessCondition.GenerateLeaseCondition(lease); blockBlob.UploadText(helloText, accessCondition: accessCondition); Console.WriteLine("Blob updated using an exclusive lease"); //       Simulate third party update to blob without lease try { //    ,       Console.WriteLine("Trying to update blob without valid lease"); blockBlob.UploadText("Update without lease, will fail"); } catch (StorageException ex) { if (ex.RequestInformation.HttpStatusCode == (int)HttpStatusCode.PreconditionFailed) Console.WriteLine("Precondition failure as expected. Blob's lease does not match"); else throw; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リース識別子を送信せずにリースでblobに書き込み操作を実行すると、リクエストはエラー412で失敗します。UploadTextメソッドが呼び出される前にリースが期限切れになり、リース識別子を渡すと、リクエストはエラー412で再度失敗します。



リース期間とリース識別子の管理については、 ドキュメントを参照してください。



次のリストは、悲観的並行性のためにリースを使用できるblob操作を示しています。

• ブロブを入れる
• ブロブを取得する
• Blobプロパティを取得
• BLOBプロパティを設定する
• BLOBメタデータを取得する
• BLOBメタデータを設定する
• ブロブを削除
• ブロックを置く
• ブロックリストを置く
• ブロックリストを取得する
• ページを置く
• ページ範囲を取得する
• スナップショットBLOB-リースIDは不要
• Blobのコピー-Blobでリースが確立される場合、識別子が必要です
• コピーBLOBの中止-無制限のリースがBLOBにインストールされている場合、識別子が必要です
• リースブロブ

コンテナの悲観的並行性

コンテナのリースは、ブロブと同じ同期戦略（排他的書き込み/分割読み取り、排他的書き込み/排他的読み取り、および分割書き込み/排他的読み取り）のサポートを提供しますが、ブロブとは異なり、ストレージサービスは削除操作に排他的戦略を使用します。



アクティブなリースを持つコンテナを削除するには、クライアントは削除リクエストにアクティブなリース識別子を含める必要があります。



リースコンテナに対する他の操作には、必ずしもリース識別子を含める必要はなく、そのような操作は共有と呼ばれます。



排他的な更新（putまたはset）または読み取り操作が必要な場合、開発者は各クライアントがリース識別子を使用し、1つのクライアントのみが現在適切な識別子を使用する必要があります。



以下は、悲観的な同時実行性のためにリースを使用できるコンテナ操作です。

• コンテナを削除
• コンテナのプロパティを取得
• コンテナメタデータの取得
• コンテナのメタデータを設定する
• コンテナACLを取得
• コンテナACLを設定します
• リースコンテナ

追加情報：

• BLOBサービスでの操作に条件付きヘッダーを使用する
• コンテナリース
• ブロブリース

テーブルサービスでの同時実行性の整理

エンティティを操作する場合、テーブルサービスは、オプティミスティックな同時実行性を明示的に選択する必要があるblobサービスとは異なり、デフォルトでは、データへの同時アクセスにオプティミスティック戦略を使用します。



テーブルサービスとBLOBサービスのもう1つの違いは、テーブルではエンティティに対してのみ並列アクセスの動作を制御でき、BLOBサービスではコンテナーとBLOBにアクセスするときの同時実行を制御できることです。



楽観的同時実行性を使用し、エンティティがテーブルサービスから選択されてから別のプロセスによって変更されたかどうかを確認するには、選択中に取得したETag値を使用できます。



このプロセスの概要を以下に示します。

1. テーブルストレージサービスからのエンティティの取得。 応答には、ETag値（リポジトリ内のエンティティに関連付けられている現在の識別子）が含まれます。
2. エンティティを更新するとき、サービスに送信するIf - Matchリクエストの条件ヘッダーに、前のステップから受信したETagパラメーターを含めます。
3. サービスは、リクエスト内のETag値をエンティティの現在のETag値と比較します。
4. エンティティの現在のETag値がIf - MatchリクエストヘッダーのETagと異なる場合 、サービスはクライアントにエラー412を返します。これは、クライアントが要求してから別のプロセスがエンティティを更新したことをクライアントに示します。
5. 現在のETag値がIf - MatchまたはIf - Match要求ヘッダーの記号（*）のETag値と変わらない場合、サービスは要求された操作を実行し、エンティティの現在のETagを更新してデータが更新されたことを示します。

BLOBサービスとは異なり、テーブルサービスでは、更新リクエストにIf - Matchヘッダーを含める必要があります。 ただし、無条件の更新（「最後に勝つ」戦略）を強制し、クライアントが要求内のIf - Matchヘッダー値をシンボル（*）に設定するときにチェックをバイパスすることは可能です。



以下のコード（C＃）は、更新された電子メールアドレスを持つ既存のデータから作成または選択された顧客エンティティを示しています。 最初の挿入または取得操作では、ETag値を顧客オブジェクトに保存します。この例では、置換操作中にオブジェクトの同じインスタンスを使用するため、ETag値がテーブルサービスに自動的に返され、サービスはアクセス中に違反をチェックできます。



別のプロセスがテーブルストア内のエンティティを更新した場合、サービスはステータスがHTTP 412（前提条件失敗）のメッセージを返します。



完全な例はこちらから入手できます。

 try { customer.Email = "updatedEmail@contoso.org"; TableOperation replaceCustomer = TableOperation.Replace(customer); customerTable.Execute(replaceCustomer); Console.WriteLine("Replace operation succeeded."); } catch (StorageException ex) { if (ex.RequestInformation.HttpStatusCode == 412) Console.WriteLine("Optimistic concurrency violation – entity has changed since it was retrieved."); else throw; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同時アクセスチェックを明示的にブロックするには、更新操作を実行する前に従業員オブジェクトのETagプロパティを「*」に設定する必要があります。



customer.ETag =“ *”;



表は、表操作がETag値を使用する方法を示しています。

運営	ETagを返します	条件付き ヘッダー が必要
クエリエンティティ	はい	いや
エンティティを挿入	はい	いや
エンティティを更新	はい	はい
エンティティを結合	はい	はい
エンティティを削除	いや	はい
エンティティの挿入または置換	はい	いや
エンティティの挿入またはマージ	はい	いや

エンティティの挿入 または 置換およびエンティティの 挿入 または マージ操作は 、テーブルサービスにETag値を送信しないため、同時アクセスチェックを実行しないことに注意してください。



通常、テーブルを使用する開発者は、スケーラブルなアプリケーションを開発する場合、データへの同時アクセスについて楽観的な戦略に依存する必要があります。



悲観的ロックが必要な場合、開発者がテーブルにアクセスするための適切なオプションは、各テーブルに特別なblobを割り当て、テーブルに対する各操作の前にそれをリースしようとすることです。



このアプローチでは、アプリケーションがテーブルへのアクセスがblobをリースするための予備的な試みを介して行われることを保証する必要があります。



また、最小リース時間は15秒であるため、スケーラブルなソリューションを開発する際には特別な注意が必要です。



追加情報：

• エンティティの操作

キューストレージサービスでの同時実行性の整理

キューの場合、並列アクセス戦略を使用する必要があるシナリオが1つあります。これは、複数のクライアントがキューから同時にメッセージを抽出する場合です。 メッセージがキューから取得されると、応答にはメッセージ自体と、後でメッセージを削除するために必要なポップ受信値が含まれます。



メッセージはキューから自動的に削除されませんが、取得された後、一定時間可視性タイムアウトの間クライアントに表示されます。



メッセージを受信するクライアントは、メッセージが処理されてから応答内のTimeNextVisible要素によって決定される瞬間まで、メッセージが削除されることを期待しています。



TimeNextVisibleを定義するために、メッセージが取得された時刻にvisibilitytimeout値が追加されます。



キューストレージサービスは楽観的または悲観的戦略をサポートしていないため、キューから取得したメッセージを処理するクライアントは、メッセージを処理するべき等べき方法を提供する必要があります。



SetQueueServiceProperties、SetQueueMetaData、SetQueueACL、UpdateMessageなどの更新操作では、「win last」戦略が使用されます。



追加情報：

• RESTキューサービスAPI
• 操作取得メッセージ

ファイルボルトサービスでの同時実行性の整理

ファイルサービスには、SMBとRESTの2つの異なるプロトコルを使用してアクセスできます。 RESTサービスは楽観的または悲観的ブロッキングをサポートしておらず、すべての更新は「最後に勝つ」戦略に基づいています。



SMBを使用するクライアントは、ファイルシステムレベルでロックメカニズムを使用して、悲観的なロックの可能性を含む共有ファイルへのアクセスを制御できます。



SMBクライアントがファイルを開くと、ファイルアクセス設定と共有アクセスモードが決定されます。 ファイルアクセスオプションを「書き込み」または「読み取り/書き込み」に設定し、共有アクセスモードを「なし」に設定した結果、ファイルはSMBクライアントによって閉じられるまでブロックされます。



SMBクライアントによってロックされたファイルでREST操作が実行されると、RESTサービスはコード「Sharing Violation」でエラー409を返します。



SMBクライアントが削除のためにファイルを開くと、他のすべてのSMBクライアントがそのファイルを閉じるまで、そのファイルは「削除保留」としてマークされます。 ファイルが削除待ちとしてマークされている限り、このファイルに対するREST操作はSMBDeletePendingコードで409エラーを返します。 SMBクライアントがファイルを閉じる前に削除保留フラグをクリアする可能性があるため、エラーコード404（見つかりません）は返されません。 つまり、エラーコード404は、ファイルが本当に削除された場合にのみ返されます。



ファイルがSMBクライアントによる削除を保留されている間、List Files出力の結果に含まれないことに注意してください。



また、RESTの[ファイルの削除]および[ディレクトリの削除]操作はアトミックに実行され、ステータスが[保留中の削除]に設定されないことに留意する必要があります。



追加情報：

• ファイルロック組織

おわりに

Microsoft Azure Cloud Storageは、複雑なWebアプリケーションのニーズを満たすように設計されました。 同時に、開発者は、データへの同時アクセスやデータの正しい状態の確保など、主要な設計パターンを犠牲にしたり再考したりする必要はありません。 それらのプロビジョニングのメカニズムは、リポジトリ自体に含まれています。



この記事で使用されているアプリケーションの完全な例：

• Microsoft Azure Storageのデータへの同時アクセスの組織

Azureストレージの詳細：

• Microsoft Azureストレージホーム
• Azure Storageの概要
• BLOB 、 テーブル、およびキュー
• 記事： Windows Azureストレージ：強力な一貫性を備えた高可用性クラウドストレージサービス

便利なリンク

• Azureを30日間無料でお試しください ！
  
  
  • Microsoft Azure Development Center（azurehub.ru） -スクリプト、ガイド、例、開発の推奨事項
  • Twitter.com/windowsazure_ru-最新のMicrosoft Azureニュース
  • FacebookのMicrosoft Azureコミュニティ -専門家、質問
  
  
  
• Microsoft Cloudおよびその他の仮想アカデミーコースを学ぶ
  
  
  • ビジネスとクラウド：ベストプラクティスソリューション
  • 大規模組織向けのWindows 8.1アップデート。 はじめに
  • Microsoft Hybrid Cloud：サンプルガイド
  • Windows 8.1のユーザーを準備するためのツールキット
  • Win2Dグラフィックスライブラリの概要
  
  
  
• 無料または試用版のVisual Studioをダウンロードする
• ユニバーサルWindows 開発者になる