QUICKGUARD ホームページ >

マリコ、もがく。―整合性に歴史あり―

2022.04.12

こんにちは、マリコです。
今年も「春眠、暁を覚えず」の季節がやってきましたね。この春、新生活を始めた皆さん、一度でも「あ、この時間に起きても間に合う」を経験してしまうとどんどん二度寝の達人になってしまいますので気をつけてくださいね。人生の先輩からの格言です。

第18回目のテーマは『Amazon S3整合性モデル』です。

結果整合性:
分散型コンピュータにおいて高可用性を実現するために用いられる一貫性モデルのうち、
最終的なデータの整合性を保証する考え方。

問題提起

さて今回もAmazonS3についてもがいていこうと思います。前々回では「S3の超基本用語とS3の超基本特徴」について、前回は「ストレージクラス」についてのIT初心者的理解をまとめてみましたが、今回のテーマは「結果整合性」「強力な整合性」です。
このテーマをまとめる上で忘れちゃいけないS3の特徴をさらっとおさらいしておきたいと思います。今回ポイントになるのは主にこの二つです。

・各オブジェクトサイズ5TBを上限に容量無制限でデータ保存が可能
・自動的にオブジェクトのコピーを(ストレージクラスにより異なるが)複数のアベイラビリティーゾーンに保存することでイレブンナインの耐久性を実現

はい、利用者にはとてもありがたい特徴ですよね。でもここで、一つ気になる問題が出てきませんか?そう「データが大きい時にはS3への保存やコピーに時間かかりそうだけどその間に同様のデータにアクセスした人は何が見えてるの問題」!!

この問題へのS3の回答が「結果整合性」と「強力な整合性」のようなのです。

これまでの結果整合性

2020年11月までのS3のデータ整合性モデルは「結果整合性」でした。
これは「時間はかかるかもしれないけど最終的にはデータの整合性は取れるよ」ということです。
つまり、最終的なデータの整合性しか保証していないため、データにアクセスするタイミングによってはデータが最新のものでなかったり、そもそも存在しないことになっていたりする場合がある訳ですね。

▲結果整合性モデルだとこんなことあり得るよ①
 

▲結果整合性モデルだとこんなことあり得るよ②

これからの強力な整合性

しかし2020年12月より、S3はこの「結果整合性」から「強力な整合性」モデルへと変化し、先述した問題を解決したそうです。この「強い整合性」とは何かというと、「データを追加したり更新したりした直後でも、最新の情報にアクセスできるよ」というものです。他には「強整合性」「強い一貫性」という風なワードで登場することもあります。

▲強力な整合性モデルだとこんな感じになるよ

AWS公式の説明によるとこんな感じです。
https://aws.amazon.com/jp/blogs/news/amazon-s3-update-strong-read-after-write-consistency/

S3 の整合性が強力になりました
前置きが長くなってしまいましたが、良いニュースをいくつかお知らせしたいと思います!

本日から、S3 の GET、PUT、LIST 操作のすべて、およびオブジェクトタグ、ACL、またはメタデータを変更する操作に強力な整合性が適用されます。書き込む内容をすぐさま読み取ることができるようになり、LIST の結果はバケットの内容を正確に反映するようになります。これは、既存および新規の S3 オブジェクトすべてに適用され、全リージョンで機能し、追加料金なしでご利用いただけます! パフォーマンスへの影響はなく、必要に応じてオブジェクトを毎秒何百回でも更新でき、グローバルな依存関係はありません。

どのようにこの「強い整合性」の実現が可能になったのか公式での説明が見つけられませんでしたが、マリコの横に座るイケメンエンジニアに聞いてみると「GCS(Google Cloud Storage)と同じような仕組みなんじゃないかな?」とのこと。
詳しく聞いてみると、GCSはS3より前に「強力な整合性」モデルを採用していたそうで、その方法としてはメタデータ(データのためのデータ)のみやり取りするオペレーションを実行することで即時最新情報を取得できるようにしているそうな。説明されるとなるほどそんな手法があるんだなーって感じですよね。

ちなみにGCP公式の説明によるとこんな感じです。
https://cloud.google.com/storage/docs/consistency?hl=ja

Cloud Storage にオブジェクトをアップロードし、成功のレスポンスを受け取ると、オブジェクトは直ちに、Google がサービスを提供する任意のロケーションからのダウンロード オペレーションとメタデータ オペレーションの対象になります。これは、新しいオブジェクトを作成する場合でも、既存のオブジェクトを置き換える場合でも同じです。アップロードは強整合性なので、read-after-write または read-after-metadata-update オペレーションで 404 Not Found レスポンスや古いデータを受け取ることはありません。

グローバルな強整合性は、オブジェクトの削除オペレーションにも当てはまります。削除リクエストが成功した直後に、オブジェクトまたはそのメタデータをダウンロードしようとすると、404 Not Found ステータス コードが返されます。404 エラーが返されるのは、削除オペレーションが成功した後はオブジェクトがもう存在しないためです。

楽しいサプライズ

なんでもAmazon S3とGoogle Cloud Storageは元来、使用目的が微妙に違ったのだそうですよ。Amazon S3は長期間安全にデータ保管することを第一目的としていて、Google Cloud Storageはメディアストリーミング等の使用が第一目的だったとか。それが各々サービス向上や内容の多様化を目指した結果、両者とも今のような形態になったと…。「強力な整合性」モデルの採用のタイミングに差があるのはこんな背景があるんですね。S3の「結果整合性」や「強力な整合性」についてもがいていたら、業界の大先輩から思わぬ情報をゲットできて、楽しいサプライズです。面白い!!

これからもこんな「面白い」と思える瞬間に出会えるよう、マリコ、もがきます!