設計パターンのベストプラクティス: Amazon S3 のパフォーマンスの最適化 - Amazon Simple Storage Service
Amazon S3 のストレージに対してアップロードおよび取得を行う際に、アプリケーションはリクエストのパフォーマンスとして 1 秒あたり数千のトランザクションを容易に達成できます。Amazon S3 は、高いリクエストレートに自動的にスケールされます。例えば、アプリケーションは、パーティショニングされた Amazon S3 プレフィックスごとに毎秒 3,500 回以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 回以上の GET/HEAD リクエストを達成できます。バケット内のプレフィックスの数に制限はありません。並列化を使用することによって、読み取りまたは書き込みのパフォーマンスを向上させることができます。例えば、Amazon S3 バケットに 10 個のプレフィックスを作成して読み取りを並列化すると、読み取りパフォーマンスを 1 秒あたり 55,000
【アップデート】S3の一貫性に変更があります | DevelopersIO
ウィスキー、シガー、パイプをこよなく愛する大栗です。 本日のアナウンス(要ログイン)で、S3の一貫性に一部変更があることが発表されました。変更があったのは"US Standard"という聞きなれないリージョンとなります。 リージョン＝US Standard？ S3に詳しい方はご存知かと思いますが、S3のリージョンにバージニア(us-east-1)が存在しません。替わりにUS Standardというリージョンがあります。歴史的経緯もあるのだと思いますが、s3.amazonaws.com（バージニア北部または太平洋岸北西部）とs3-external-1.amazonaws.com（バージニア北部のみ）の2箇所のエンドポイントが使用できます。 何が変わったの？ US Standardは一貫性が他のリージョンと異なっていましたが、他のリージョンと同じ整合性モデルが使用できる様になりました。変更点は
あらためてS3のデータ整合性モデルを整理してみる(2018年11月現在) - きっと、うまくいく~非IT業界をスクラムで変えるための系譜~
いつも"アジャイル"とか"スクラム"、"カイゼン"みたいな文脈で書いているのですが、 普段の業務の中での関わりが大きいAWSについても書いていこうかと思います。 とある出来事 私の勤める会社のSlackには「困りごとch」というものを設けています。 先日、そこにこんな投稿がありました。 ruby aws-sdkで困りごと s3にオブジェクト登録→ラムダ発火でapi叩く→そのs3オブジェクトにアクセス(deniedされる)→1秒sleep→同じs3オブジェクトにアクセス(成功) なぜすでにあるオブジェクトにアクセスしているのにdeniedされてしまうのか、 一秒待つとdeniedされないのか、わからなくて困っています。 「ああ、あれじゃん！」 と思う方、その通りです。 AWS S3 のデータ整合性モデルに絡んだ話です。 公式のデータ整合性モデル AWS自体が日進月歩の世界なので、この記事もす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
