書いた直後に読めば、必ずその内容が返ります。それでも200人が同じ鍵を直したら、199件が消えました。
読めることと、同時の書き込みが守られることは別の話です。ここを混同すると数が合わなくなります。
書いた直後に読める性質と、同時の書き込みが守られる性質は別です。後者はありません。
Amazon S3は、同時に書く相手同士を待たせません。公式は同時に書く相手のための締め出しには対応していないと述べています。
後から書いたほうが残ります。では、読んで直して書く形が重なると何件消えるのか。実際に並べて数えました。
同じ鍵に 200 人が「読む→1足す→書く」を行う
後から書いたほうが残る。読んでから書くまでの間に他人が書くと、その分が消える
重なる幅 最後の値 消えた件数 消えた割合 割り込まれた人
0 1 199件 99.5% 200人
5 5 195件 97.5% 199人
20 19 181件 90.5% 199人
80 61 139件 69.5% 186人
200 95 105件 52.5% 137人
全員が同時なら、残るのは1件だけです。199件は書いたのに残りません。
重なる幅を200まで広げても、まだ105件が消えます。散らせば減りますが、なくなりはしません。
公式は同じページで置く操作と消す操作について、書いたあとの読みで最新が返るとも述べています。これは正しく、書いた本人が読めば必ず自分の内容が返ります。
ただし、それは他人の書き込みを待たせる話ではありません。読めることと、消えないことは別々です。
この違いは冪等性の記事で扱った「何度実行しても同じ」という性質とも別で、ここでは実行回数ではなく重なり方が効いています。
散らしても、消える件数はゼロにならない。
Amazon S3 does not support object locking for concurrent writers.原文AWS ドキュメント「What is Amazon S3?」 この内容の有効期限2027-02-18
鍵をまたいでまとめて直す方法はありません。間隔の長さがそのまま見える割合になります。
Amazon S3では、複数の鍵をまとめて直せません。公式は鍵をまたいで一度に直す方法はないと述べています。
1つ目を書いてから2つ目を書くまでの間、食い違った状態が読めます。どれくらい見えるのかを数えました。
2つの鍵を続けて書き替える。書き替えは 10000 ミリ秒ごとに1回
その間に 100,000 回読んで、片方だけ新しい状態を何回見たかを数える
毎秒100回読み、1日ぶん（8,640,000回）に引き伸ばした場合もあわせて出す
2つの書き替えの間隔 途中が見えた回数 割合 1日ぶんの換算
1ミリ秒 21回 0.02% 1,814回
10ミリ秒 93回 0.09% 8,035回
50ミリ秒 498回 0.50% 43,027回
200ミリ秒 1988回 1.99% 171,763回
1000ミリ秒 9907回 9.91% 855,965回
1ミリ秒でも0.02%は見えます。ゼロにはなりません。
200ミリ秒あくと1.99%です。毎秒100回読む前提なら、1日で171,763回になります。
公式は1つの鍵への更新は、途中や壊れた状態が見えることなく行われるとも述べています。1番目が効くのはこの性質があるからです。
鍵をまたぐ更新をまとめたい場合は、DynamoDBの記事で扱った条件付きの書き込みのような仕組みが必要になります。
There is no way to make atomic updates across keys.原文AWS ドキュメント「What is Amazon S3?」 この内容の有効期限2027-02-18
中身と設定で扱いが違います。設定を変えた直後に確かめる処理は、古い状態を読みます。
Amazon S3では、入れ物の設定は後から揃います。公式は入れ物の設定は、後から揃う形であると述べています。
中身の読み書きとは扱いが違います。設定を変えた直後の確認は、古い内容を読むことがあります。
6時間ぶん。書き込み 64,779件・読み取り 648,176件 写しに届くまでの遅れを変えて、古い内容を読んだ割合を見る 写しの遅れ 0.01秒後に読む 0.1秒後に読む 1秒後に読む 0.005秒 0.0% 0.0% 0.0% 0.05秒 100.0% 0.0% 0.0% 0.5秒 100.0% 100.0% 0.0% 2秒 100.0% 100.0% 100.0%
間隔が遅れより短ければ必ず古いものを読みます。0%か100%のどちらかで、途中の値になりません。
だから数回試して通ったから大丈夫、という確かめ方は当てになりません。遅れとの大小だけで決まります。
公式は版の管理を初めて有効にする場合について、15分待ってから書き込みを行うことを勧めると述べています。
これは反映が完全に行き渡るまでに少し時間がかかるためだと説明されています。設定変更を含む手順では、この待ちを組み込むことになります。
3つの計測はいずれも手元で書いた模型で、実際のAmazon S3を叩いたものではありません。消えた件数は「読む→1足す→書く」という形に限った話で、単に置くだけの操作では起きません。途中が見えた割合は、書き替えの間隔と読む頻度を置いた上での計算です。遅れの計測も一定の遅れを仮定しており、実際の値はこれと違います。ここで見せているのは、書いた直後に読めることと同時の書き込みが守られることは別だという点と、鍵をまたぐ食い違いは間隔の長さで決まるという点の2つです。
Bucket configurations have an eventual consistency model.原文AWS ドキュメント「What is Amazon S3?」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る