Amazon S3再入門【後編】

Amazon S3利用者がハマりがちな落とし穴の回避法

S3は優れたサービスではあるが、活用する上では幾つかの注意点がある。ちょっとした使い方の違いで請求額が大きく異なる場合もある。

公開 2019年06月17日 08時00分

更新 2022年01月19日 09時29分

著者

Chris Evans

[Computer Weekly]

印刷する連載新着通知を受け取る

　前編（ Computer Weekly日本語版　5月22日号掲載）では、クラウドストレージのデファクトスタンダードになりつつあるAmazon S3（以下、S3）の特徴について、改めて復習した。

　後編では、S3のバックグラウンドと使用上の注意点について解説する。

S3の背後にあるもの

　AWSはS3の実装の詳細を一切公表していない。だがS3が動作する仕組みの理解に役立つ技術については分かっていることがある。

　AWSのサービスは世界各地のリージョンで運用されており、毎年新たなリージョンが追加されている。これらのリージョンは1つ以上のデータセンターから成るアベイラビリティーゾーンに分かれている。S3は冗長データを複数のアベイラビリティーゾーンに分散し、データの回復性を提供する。

　可用性と回復性について、AWSは2つの数値を提示している。

　データの可用性は、標準層で99.99％、標準（低頻度アクセス）層で99.9％が保証される。だがGlacier（前編参照）はデータの取得が非同期かつ最大4時間かかるため、可用性は適用されない。

　S3のデータ損失リスクを指す耐久性についても数値が公表されている。3つのストレージ層はいずれも99.999999999％の耐久性を提供する。

アプリケーションでのS3の使用

　S3は事実上無制限のストレージ容量を提供する。だがS3を使う場合の考慮事項や課題が幾つか存在する。

結果整合性

　S3は既存のオブジェクトの更新または削除に「結果整合性」というデータ整合性モデルを採用している。例えば、既存オブジェクトが上書きされたが、そのオブジェクトのレプリケーションが同じリージョンのアベイラビリティーゾーン間で完了していないとする。この場合、オブジェクトを再読み込みすると以前のバージョンに戻る可能性がある。このシナリオを確認するには追加のプログラミングが必要になる。

コンプライアンス

S3のデータが保存されるのは一部の国なので、業界によってはこれがコンプライアンスと規制の制限に関する問題を引き起こす恐れがある。例えば、本稿執筆時点では英国にリージョンがない（構築は計画されている）。

セキュリティ

どのパブリッククラウドでも、セキュリティは常に懸念事項だ。S3は複数のセキュリティレベルを提供しており、例えばS3キー、S3マネージドキー、顧客が用意した暗号化キーを使うことができる。顧客が用意したキーを使う場合は、言うまでもなく顧客が自身でキー管理体制を整えなければならない。これらのキーを紛失すれば、保存されている全てのデータが事実上役に立たなくなる。

ロック

S3はデータへのアクセスをシリアライズする機能を提供していない。同じオブジェクトへの複数のPUT要求が衝突しないようにするのはユーザーアプリケーションの役割だ。このためには、（例えば読み取り、変更、書き込みプロセスなど）オブジェクトを頻繁に更新する環境で追加のプログラミングを行わなくてはならない。

コスト

データアクセス要件を考慮すると、S3は非常に高コストになる可能性がある。S3から読み取るデータは全て課金されるが、「Amazon Elastic Compute Cloud」（Amazon EC2）などAWSの別のサービスからS3にアクセスする場合は例外になる。アプリケーションがS3にアクセスする方法によっては、顧客が自社データセンターとAWSデータセンターの間で障害が発生するリスクを減らすため、ネットワーク容量を追加購入しなければならない場合もある。

　AWSはS3によって確固たる地位を築いている。ほとんどのオブジェクトストレージソフトウェアベンダーは、非公式ではあるもののデファクトスタンダードとしてS3 APIを採用している。そのためオンプレミスストレージやクラウドストレージを使うようにアプリケーションを簡単に修正できる。だがこうした修正の必要性はほとんどないか、全くない。ベンダーの多くが、S3に付加価値を付けて市場で競争力を確保しようとしている。

　オブジェクトストレージはIT業界で急速に成長している分野の一つだ。わずかに異なるプログラミングにユーザーが取り組んでいけば、ストレージエコシステムに含まれるこの部分が大きく成長することになるだろう。

印刷する