Amazon S3 の一貫性モデル超入門 #ハードル激低LT大会 / Low-hurdle LT Meetup 2nd

ハードル激低LT大会ッ！ #02 で使用したスライドです。

Amazon S3 の強い Read-after-write 一貫性と、その同期プロトコルの検証に使用された形式手法の一種、P 言語のさわりを紹介しています。

イベント概要：https://smarthr.connpass.com/event/278899/

Transcript

1. #ハードル激低LT大会 Amazon S3 の 一貫性モデル超入門 チェシャ猫 (@y_taka_23) ハードル激低 LT 大会ッ！ #2 (20th Apr. 2023)
2. #ハードル激低LT大会 Amazon Simple Storage Service (S3) を AWS CLI で操作してみた
3. #ハードル激低LT大会 cp コマンドでアップロード 結果を ls コマンドで確認 rm コマンドで削除 結果を ls コマンドで確認
4. #ハードル激低LT大会 ご清聴ありがとうございました Presented by チェシャ猫 (@y_taka_23)
5. #ハードル激低LT大会 （作れば作られ、消せば消えるのは自明では…）
6. #ハードル激低LT大会 S3 の一貫性モデル (Consistency Model) • S3 オブジェクトの「見え方」は一筋縄ではいかない ◦ 複数の AZ にレプリケーションが行われる関係で「時差」がある • 2020 年 11 月以前の更新・削除は結果整合性（結果一貫性） ◦ つまり「消せば（すぐ）消える」は自明どころか間違いだった • 2020 年 12 月以降は更新・削除も Read-After-Write 一貫性に ◦ 更新・削除の後、そのデータ（の不在）が即座に読み取り可能 ◦ オブジェクトのタグや ACL も対象だが、Bucket 自体の設定は対象外 ◦ ちなみに新規作成は以前から read-after-write 一貫性だった https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#ConsistencyModel
7. #ハードル激低LT大会 （2020 年の話なら、もう気にしなくていいのでは…）
8. #ハードル激低LT大会 Read-After-Write があったとしてもかなり複雑
9. #ハードル激低LT大会 パターン 1：書き込み完了後に読み込み開始 • クライアント A と B がほぼ同時に README.md を書き換える ◦ A は Hello に、B は GoodBye に中身を更新したい • 書き込みリクエスト完了後に読み込みリクエストが到着 ◦ この場合、読み込み結果は後から書いた GoodBye で確定 Client A Client B S3 PUT(Hello) GET => GoodBye GET => GoodBye PUT(GoodBye)
10. #ハードル激低LT大会 パターン 2：読み込み開始が書き込み完了に先行 • B の書き込み終了より前に A が読み込みを開始 • 読み込み結果はリクエスト到着順やレプリケーション速度に依存 ◦ A から見ると Hello になる場合と GoodBye になる場合の両方がある ◦ B から見ると自分が書き込んだ GoodBye は確定して見える Client A Client B S3 PUT(Hello) GET => GoodBye GET => GoodBye PUT(GoodBye)
11. #ハードル激低LT大会 パターン 2：読み込み開始が書き込み完了に先行 • B の書き込み終了より前に A が読み込みを開始 • 読み込み結果はリクエスト到着順やレプリケーション速度に依存 ◦ A から見ると Hello になる場合と GoodBye になる場合の両方がある ◦ B から見ると自分が書き込んだ GoodBye は確定して見える Client A Client B S3 PUT(Hello) GET => Hello GET => GoodBye PUT(GoodBye)
12. #ハードル激低LT大会 パターン 3：別の書き込み開始が書き込み完了に先行 • A の書き込み完了前に B が書き込みを開始 • 読み込み結果はやはりリクエストの到着順に依存 ◦ 実際には後から来た書き込みが有効になる ◦ 先ほどと違って十分な時間待っても最終結果がどちらかは分からない Client A Client B S3 PUT(Hello) GET => GoodBye GET => GoodBye PUT(GoodBye)
13. #ハードル激低LT大会 パターン 3：別の書き込み開始が書き込み完了に先行 • A の書き込み完了前に B が書き込みを開始 • 読み込み結果はやはりリクエストの到着順に依存 ◦ 実際には後から来た書き込みが有効になる ◦ 先ほどと違って十分な時間待っても最終結果がどちらかは分からない Client A Client B S3 PUT(Hello) GET => Hello GET => Hello PUT(GoodBye)
14. #ハードル激低LT大会 クライアント 2 個が書いて読むだけで タイミングの組み合わせは 70 通りもある
15. #ハードル激低LT大会 （こんなの、パターンが多すぎてテスト不可能では…）
16. #ハードル激低LT大会 P https://p-org.github.io/P/
17. #ハードル激低LT大会 AWS Storage 開発チームによる P 言語の活用 • 形式手法と呼ばれるツール群の一つ ◦ システムの動作と仕様を数学的に厳密に記述し理論的に検査 • 各プロセス（クライアント・サーバ等）を状態機械で表現 ◦ 分散システムで起こり得るタイミング問題を静的・系統的に探索 • AWS の S3 開発チームでも使用されている ◦ 一貫性の性質を変更する際にバグがないかを P 言語で設計・検査 ◦ S3 のスケールは大きいので、十億回に一回のバグでも日に何度か起きる ◦ P 言語を用いることで、レアケースでももれなく検知できる https://www.youtube.com/watch?v=B0yXz6EeCaA
18. #ハードル激低LT大会 AWS Dev Day 2023 プロポーザルに投票お願いします！ https://github.com/aws-events/aws-dev-day-tokyo-2023-cfp/issues/107 興味のある人は GitHub で リアクションよろしく！
19. #ハードル激低LT大会 From “Probably Correct” to “Provably Correct” Presented by チェシャ猫 (@y_taka_23)