AWSは最近、Amazon S3で条件付き書き込みをサポートすることを発表した。これにより、ユーザーはオブジェクトを作成する前にその存在を確認できるようになった。この機能は、データをアップロードする際に既存のオブジェクトの上書きを防ぐのに役立ち、アプリケーションのデータ管理を容易にする。
条件付き書き込みは、複数のクライアントを持つ分散アプリケーションが、共有データセット間で並列にデータを更新する方法を簡素化する。各クライアントは条件付きでオブジェクトを書き込み、他のクライアントがすでに書き込んだオブジェクトを上書きしないようにできる。つまり、更新を調整するためにクライアントサイドのコンセンサスメカニズムを構築したり、データをアップロードする前にオブジェクトの存在をチェックするために追加のAPIリクエストを使用したりする必要がない。
代わりに、開発者はそのような検証をS3にオフロードでき、大規模分析、分散機械学習、高度に並列化されたワークロードのパフォーマンスと効率が向上する。条件付き書き込みを使用するには、開発者はPutObject とCompleteMultipartUploadAPIリクエストと共にHTTP if-none-match条件付きヘッダーを追加できる。
if-none-match パラメータを使用して条件付き書き込みヘッダを持つオブジェクトをアップロードするために AWS CLI を使用した put-object は以下のようになる。
aws s3api put-object --bucket amzn-s3-demo-bucket --key dir-1/my_images.tar.bz2 --body my_images.tar.bz2 --if-none-match "*"Hacker Newsのスレッドで、分散ロックのための信頼性の高いマネージド・サービスを必要とする現在のシステムのほとんどはDynamoDBを使っているのかという質問があった。そのような分散ロックの実装に、DynamoDBよりもS3が望ましいシナリオはあるのだろうか？という質問があった。
s3だけを使う方が、より簡単で、セットアップもコードも少なく、コストもかかりません。
同社のドキュメントによると、条件付き書き込みの動作は以下のようになっている。
- Amazon S3で条件付き書き込みを行う際、同じキー名のオブジェクトがバケット内に存在しない場合、書き込み操作は200レスポンスで成功する。
- 既存のオブジェクトが存在する場合、書き込み操作は412 Precondition Failedレスポンスで失敗する。バージョニングが有効な場合、S3は同じ名前を持つ現在のオブジェクトバージョンの存在をチェックする。
- 現在のオブジェクトバージョンが存在しないか、現在のバージョンが削除マーカーである場合、書き込み操作は成功する。
- 同じオブジェクト名に対して複数の条件付き書き込みを行うと、最初の書き込み操作は成功し、それ以降の書き込みは412 Precondition Failedレスポンスで失敗する。さらに、同時リクエストは409 Conflictレスポンスを返すかもしれない。
- 条件付き書き込み操作が完了する前にオブジェクトへの削除要求が成功した場合、削除要求が優先される。PutObjectとCompleteMultipartUploadで409エラーを受け取った後、再試行が必要になる場合がある。
412 Precondition Failed レスポンス（出典：Conditional Requests Documentation）
AWSのプロダクトマネージャーであるPaul Meighan氏は、LinkedInの投稿で次のように述べている。
これは、多くの同時書き込みを行う可能性のある分散アプリケーションにとって大きな簡素化であり、一般的に、データの整合性にとっては勝利です。
続いて、Gregor Hohpe氏のコメントが続く。
これこそ分散システムの「プリミティブ」と呼ぶべきもの、つまり条件付き書き込みだ。
現在、Amazon S3の条件付き書き込み機能は、AWS GovCloud（US）リージョンとAWS Chinaリージョンを含むすべてのAWSリージョンで追加料金なしで利用できる。さらに、サンプルはGitHubリポジトリで入手できる。