Category: Amazon S3


S3 Select と Glacier Select – オブジェクトのサブセットを取得

Amazon Simple Storage Service (S3) は、各業界のマーケットリーダーが使用する数百万のアプリケーションのデータを保存しています。セキュアで耐久性のある非常に低コストのアーカイブストレージとして、これらの多くのお客様は Amazon Glacier も使用しています。S3 では、望むだけの数のオブジェクトを格納することができますし、個々のオブジェクトは最大5テラバイトとすることができます。オブジェクトストレージのデータは、通常1エンティティ全体としてアクセスされます。そのことは、例えば 5GB のオブジェクトに対してなんらかの要求をすれば、5GB 全てのデータ取得を行うことを意味します。これはオブジェクトストレージとしては自然なことです。

2017年11月29日、このパラダイムに挑戦すべく、S3とGlacierに2つの新機能を発表します。シンプルなSQL文を利用して、それらのオブジェクトから必要なバイトだけを引き出すことを可能としました。この機能により、S3やGlacierのオブジェクトにアクセスするすべてのアプリケーションが強化されます。

S3 Select

プレビューとして発表された S3 Select により、アプリケーションはシンプルなSQL文を用いて、オブジェクトからデータの一部分のみを取り出すことができます。アプリケーションが必要とするデータのみを取得するので、大幅なパフォーマンス向上が達成でき、400%ほどの改善が見込めることもあります。
(more…)

Amazon S3バケットのアクセス設定に関する注意喚起メールにつきまして

2017年7月19日前後より、Amazon Web Services(AWS)の一部のお客様に対し、“Securing Amazon S3 Buckets” という件名のメールをご送付させていただきました。Amazon S3 のバケットポリシーアクセスコントロールリスト(ACL)の設定の不備によって、Amazon S3 上の重要なデータが漏洩するセキュリティリスクに対する注意喚起となります。Amazon S3 のバケットポリシーや ACLの設定について、この注意喚起メールを必要な設定の見直しのきっかけにしていただければと思います。なお、メールを受け取られたお客様に、必ずしも問題があることを示すものではありません。

 

メールが送られた契機について

 

重要なデータが漏洩した事例のいくつかを調査した結果、バケット ACL を “All Users” や “All Authenticated AWS Users” に設定されているお客様はセキュリティリスクが高いと判断しています。該当するお客様は、設定の見直しを推奨すべくメールをお送り致しましたので、アクセスが広く許可されていることが本当に正しい状態か、今一度ご確認ください。

(more…)

HBase on Amazon S3を使用してリードレプリカクラスタをセットアップする

多くのお客様は、低コスト、データ耐久性、スケーラビリティなど、Amazon S3をデータストレージとしてApache HBaseを実行することの利点を活用しています。 FINRAのような顧客は、HBase on S3アーキテクチャーに移行し、ストレージをコンピュートから切り離し、S3をストレージレイヤーとして使用するという多くの運用上の利点とともに、コストを60%削減しました。 HBase on S3を使用すると、クラスタを起動して、長いスナップショット復元プロセスを経る必要がなく、S3内のデータに対してすぐにクエリを開始することができます。

Amazon EMR 5.7.0の発表により、HBase on S3の高可用性と耐久性をクラスタレベルにさらに一歩進化させることができます。S3上の同じHBaseルートディレクトリに接続できる複数のHBase読み取り専用クラスタを開始できます。これにより、リードレプリカクラスタを介して常にデータにアクセスできることを保証し、複数のアベイラビリティゾーンにわたってクラスタを実行できます。

この記事では、HBase on S3を使用したリードレプリカクラスタの設定をご案内します。

(more…)

Hightail — クラウド上での創造的なコラボレーションを支援

Hightail (旧社名: YouSendIt) は、世界各地の 5,000 万人以上の専門家が優れたコンテンツをユーザーに提供できるよう支援することで、創造的な作業の確認、改善、承認方法を合理化しています。Hightail は、ファイル共有会社として 2004 年に設立されて以来、付加価値のある創造的なコラボレーションサービスの提供へと戦略的方向を転換し、著名な顧客を数多く獲得しています。

本日のゲスト投稿では、Hightail の技術担当上級副社長である Shiva Paranandi 氏が、同社が実施したオンプレミスからクラウドへのペタバイト単位のデータ移行について語ります。クラウドベンダーの評価プロセスと、すべてを AWS に移行した理由が述べられています。


Hightail はユーザーが大きなファイルを簡単に共有して保存できる方法を提供するために設立されましたが、それ以降、創造的なコラボレーションツールへと進化してきました。当社は、ユーザーがデジタル資産を管理、共有するだけの場所ではなく、創造的なチームを作り、顧客とつながり、創造的なワークフローを開発して、最初から最後までプロジェクトを管理できる場所になりました。現在では、LionsgateJimmy Kimmel Live! といった有名ブランドのコラボレーションサービスの原動力となっています。当社は、国内外の顧客が増える中で、製品開発とユーザーへのサービスに対して社内的により傾注する必要がありました。独自のデータセンターの運営には、予定していたよりも多くの時間、費用、人材が必要になることがわかりました。

より迅速に反復して顧客のニーズを満たし、市場までの時間を大幅に改善する手法が必要でした。データセンターのコストを削減し、世界各地の特定のリージョンで迅速にスケールアップする柔軟性が必要だったのです。新しい場所でのデータセンターの設営には長い時間がかかり、当社が達成できる成長ペースの妨げとなっていました。さらに、使用することもないストレージキャパシティーを所有することになる、ニーズに先回りした購入にはうんざりしていました。頻繁に使用しないデータを非アクティブなストレージに保持する一方で、顧客のリクエストに応じてそのデータを迅速に取り出せることでコストを削減する、階層型で非常にスケーラブルなストレージソリューションが必要でした。当社の主な推進力は俊敏性と革新であり、クラウドはそれらを強力に可能にしてくれます。それを踏まえて、ストレージとコンピューティングインフラストラクチャの管理にリソースを投入するのではなく、ビジネスを差別化する構想に時間とコストを費やすことができる、クラウドファーストのポリシーを採用することに決定しました。

AWS とクラウド競合他社の比較

移行の開始にあたって、まず AWS、Google、IBM、Microsoft を含むさまざまなクラウドベンダーの評価を行いました。当社にとっては明らかに AWS が抜きん出た選択肢でした。ある時点では、ニーズを満たすために複数のクラウドプロバイダーからのサービスを組み合わせることを検討しましたが、最適なルートは AWS を単独で使用することであると判断しました。トレーニング、同期、サポート、システムの可用性、それに他の移行や管理の要素を考慮すると、複数のクラウドを使用する手法は実用的ではありませんでした。最善のコスト削減と、ほかに例を見ないパートナーソリューションのエコシステムにより、他のベンダーは必要なく、すべてを AWS に移行することを選択しました。

AWS に移行することで、ギガバイトあたりの最低料金、リッチなエコシステムへのアクセス、社内の迅速な人材開発、SOC II コンプライアンスの維持が可能になりました。エコシステムは特に当社にとって重要で、非常に多くのパートナーを持つ AWS は競合他社とは一線を画していました。実際に、イメージのプレビュー、ビデオのエンコード、プレゼンテーションの提供などのサービスについて当社が依存しているすべてのベンダーは既にこのネットワークに参加しているため、既存の投資や専門知識を簡単に利用することができました。別のプロバイダーを選択していれば、既に正しく稼働しているプラットフォームからの移行が必要になりますが、これは当社にとって望ましい結果ではありませんでした。また、AWS のテクノロジーについて社内で開発できる人材の数も驚くべきものでした。AWS の使用に関する内部チームのトレーニングは、AWS カンファランス、トレーニング教材、サポートなどの利用可能なツールを使用した簡単なプロセスです。

ペタバイト単位のデータの移行

AWS を選択したことで、作業が簡単になりました。多くの場合、社内で使用していたよりも優れた機能が提供されました。オンプレミスストレージから AWS に数ペタバイトのデータを簡単に移行できました。AWS の Direct Connect により高速に処理を進めることができたため、3 か月ほどですべてのデータをプッシュできました。それによるユーザーへの影響はありませんでした。AWS Key Management Service を採用してデータを安全に保ち、それにより移行の際の安心感が得られました。顧客への影響が低いことを確認するため、当社データセンターと AWS にプッシュされたデータ間のチェックサムなどの方法を使用して、事前に広範な QA テストを実行しました。

AWS 上の新しいプラットフォームにより、ユーザーエクスペリエンスが大きく改善しました。信頼性、パフォーマンス、稼働時間において大きな改善が見られました。これらは当社の業務においてすべて非常に重要です。現在では、以前のデータセンターよりも最大 17 倍高速なアップロードおよびダウンロード速度を達成することができ、稼働時間も桁違いに向上しています。また、新しいリージョンへのサービスのデプロイにかかる時間も、90% 以上削減できました。以前は、新しいリージョンをオンラインにするには少なくとも 6 か月かかっていましたが、現在では、3 週間以内でリージョンを立ち上げることができます。AWS では、災害対策の目的で、リージョン間でデータをバケットレベルでレプリケートすることもできます。

コストを削減するため、ストレージインフラストラクチャを、アクセス頻度が高いデータと低いデータに分類することができました。Amazon S3 の階層化ストレージは大きな利点であり、これによりストレージコストを最適化することができ、製品開発へのより多くの投資が可能になっています。現在では、顧客のニーズを満たすために非アクティブ階層からアクティブ階層にデータを瞬時に移動でき、ストレージインフラストラクチャを過剰プロビジョニングする必要がなくなりました。ピーク負荷の時間中にサービスが自動的に拡張または縮小するのを見て、必要な分だけの支払いで済んでいることを知るのは爽快です。

全体として、当社はインフラストラクチャではなく開発により多く集中するという主要な戦略目標を達成しました。当社の移行はシームレスに感じられ、ここでお伝えできる進歩こそが、ワークロードを AWS で実行するのがいかに簡単であるかの真の証です。移行の成功要因の一部として、AWS チームから提供された専用サポートが挙げられます。サポートは本当に素晴らしいものでした。何人かの技術者は 24 時間 365 日チャットに対応してくれましたが、これは大規模な移行では不可欠なものでした。

-Shiva Paranandi 氏、Hightail 技術担当上級副社長

詳細

Amazon S3 によるコスト効率の高い階層型データストレージの詳細について参照するか、AWS パートナーエコシステムで、お客様のニーズに最適なソリューションをお探しください。

Amazon EMRでS3DistCpを使用してHDFSとAmazon S3間で効率的にデータを移動するための7つのヒント

Amazon S3とHadoop Distributed File System(HDFS)の間で大量のデータを移動する必要があったものの、データセットが単純なコピー操作には大きすぎるということはありませんでしたか? EMRはこれを救うことができます。ペタバイト級のデータの処理と分析に加えて、EMRは大量のデータの移動もできます。

Hadoopエコシステムでは、DistCpがデータを移動するためによく使用されます。 DistCpは、MapReduceフレームワークの上に構築された分散コピー機能を提供します。 S3DistCpは、S3で動作するように最適化されたDistCpの拡張機能であり、いくつかの便利な機能が追加されています。 S3DistCpは、HDFSとS3の間でデータを移動するだけでなく、ファイル操作のスイスアーミーナイフです。この記事では、S3DistCpを使用するための基本的なユースケースから始めて、さらに高度なシナリオまでのヒントについて説明します。

  1. 変換なしにファイルをコピーまたは移動する
  2. ファイル圧縮を変更しつつコピーする
  3. ファイルを段階的にコピーする
  4. 1つのジョブで複数のフォルダをコピーする
  5. パターンに基づいてファイルを集約する
  6. サイズが1TBを超えるファイルをアップロードする
  7. S3DistCpステップをEMRクラスターにサブミットする

(more…)

HDFSからAmazon S3へApache HBaseを移行するためのヒント

Amazon EMR 5.2.0以降、Amazon S3上でApache HBaseを実行することができます。 S3上でHBaseを実行すると、コストの削減、データ耐久性の向上、スケーラビリティの向上など、いくつかの利点が追加されます。

HBaseには、HBaseテーブルの移行およびバックアップに使用できるいくつかのオプションがあります。 S3のHBaseに移行する手順は、Apache Hadoop分散ファイルシステム(HDFS)のHBaseの手順と似ていますが、細かな違いといくつかの「落とし穴」を認識していれば、移行がより簡単になります。

この記事では、一般的なHBase移行オプションのいくつかを使用してS3のHBaseを開始する方法を説明します。

HBaseの移行オプション

正しい移行方法とツールを選択することは、HBaseテーブルの移行を成功させる上で重要なステップです。しかし、正しいものを選ぶことは、必ずしも簡単な作業ではありません。

次のHBaseの機能が、S3のHBaseに移行するのに役立ちます:

  • スナップショット
  • エクスポートとインポート
  • CopyTable

次の図は、各オプションの手順をまとめたものです。

さまざまな要因によって、使用するHBaseの移行方法が決まります。たとえば、EMRでは、S3で実行できる最初のバージョンとしてHBaseバージョン1.2.3が提供されています。したがって、移行元のHBaseバージョンが、移行方法を決決めるのに役立つ重要な要素になります。 HBaseのバージョンと互換性の詳細については、Apache HBaseリファレンスガイドのHBaseのバージョン番号と互換性のマニュアルを参照してください。

旧バージョンのHBase(HBase 0.94など)から移行する場合は、アプリケーションをテストして、新しいHBase APIバージョンと互換性があることを確認する必要があります。アプリケーションとAPIにHBaseバージョンの違いによる問題があることを確認するためだけに、大きなテーブルを移行して数時間を費やすことは望ましくありません。

良い知らせとしては、HBaseはテーブルの一部だけを移行するために使用できるユーティリティを提供していることです。これにより、HBaseテーブル全体を完全に移行することなく、既存のHBaseアプリケーションをテストすることができます。たとえば、Export、Import、またはCopyTableユーティリティを使用して、テーブルの一部分をS3のHBaseに移行できます。アプリケーションが新しいHBaseバージョンで動作することを確認したら、HBaseスナップショットを使用してテーブル全体を移行することができます。

(more…)

EMRFSを利用して、別AWSアカウントからデータを安全に分析する

分析されるデータは、異なるアカウントが所有するバケットに分散されることがあります。データのセキュリティを確保するためには、適切な認証情報管理が必要です。これは、さまざまな部門の異なるAmazon S3バケットにデータを格納している大企業にとって特に当てはまります。例えば、顧客サービス部門は、研究部門が所有するデータにアクセスする必要があるかもしれませんが、研究部門はそのアクセスを安全な方法で提供する必要があります。

データを保護するこの側面は非常に複雑になる可能性があります。 Amazon EMRは、統合メカニズムを使用して、S3に格納されたデータにアクセスするためのユーザー認証情報を提供します。 EMR上でアプリケーション(Hive、Sparkなど)を使用してS3バケットとの間でファイルを読み書きする場合、S3 API呼び出しには認証するための適切な認証情報で署名する必要があります。

通常、これらの認証情報は、クラスターの起動時に指定するEC2インスタンスプロファイルによって提供されます。そのオブジェクトが異なる認証情報セットを必要とするため、EC2インスタンスプロファイルの認証情報がS3オブジェクトにアクセスするのに十分でない場合はどうなるでしょうか?

このポストは、カスタム認証プロバイダを使用して、EMRFSのデフォルトの認証プロバイダがアクセスできないS3オブジェクトにアクセスする方法を示しています。

(more…)

S3 ストレージ管理アップデート – 分析、オブジェクトのタグ付け、インベントリ、メトリクス

本日、皆様がお持ちのストレージとそのアクセスパターンを詳しく知るための 4 つの S3 機能についてご説明したいと思います。何をどのくらい保管しているのか、どのように使用しているのかを知ることができ、その結果として、S3 ストレージクラスの使用に関する情報に基づいた意思決定を行うことができます。これらの機能は、バケットに何十万、何千、何百万、何十億というオブジェクトを持っていても、S3 を使用するすべての人にとって価値があります。

以下が概要です:

S3 分析 – オブジェクトの格納状況と取得パターンを分析し、その結果を使って、最適なストレージクラスを選択することができます。あなたは S3 コンソールで表示される分析の結果を検査したり、お好みの BI ツールにロードし深掘りしても良いでしょう。そうすることで、ストレージの利用傾向を見て、それらが使い方や成長度合いにどのように関連しているのかがつかめます。

S3 オブジェクトのタグ付け – 複数のキーと値のペア(タグ)をそれぞれの S3 オブジェクトに関連付けることができ、いつでも変更することができます。タグは、アクセスの管理と制御、S3 ライフサイクルポリシーの設定、S3 分析のカスタマイズ、CloudWatch メトリクスのフィルタリングに使用できます。バケットをデータレイクと考えることができ、タグを使用してそのデータレイクの中のオブジェクトの分類を作成できます。これは、バケットとプレフィックスを使用するよりも柔軟性があり、オブジェクトの名前を変更、移動、またはコピーせずに意味付けの変更を行うことができます。

S3 インベントリ – S3 インベントリを使用して、ビジネスワークフローやビッグデータのジョブを加速できます。この機能は、毎日または毎週の単位で、バケットの全部または一部の内容(プレフィックスによって識別される)の CSV 形式のフラットファイル表現を提供します。

S3 CloudWatch メトリクス – 13 種類の Amazon CloudWatch メトリクスを監視やアラームを設定することで、S3 を活用するアプリケーションのパフォーマンスを向上させる可能性があります。

詳細を見てみましょう。

S3 分析
S3 のユーザは、標準、標準 IA (標準低頻度アクセス)、Glacier と 3 つのストレージクラスを選択することができます。S3 のオブジェクトライフサイクル管理を使用して、オブジェクトが期限切れになるか、標準 IA もしくは Glacier に移行するかを指定することができます。

S3 分析機能は、オブジェクトについて、標準と標準 IA のどちらを選択したら良いのかの必要な情報を提供します。多くの顧客は、処理を容易にするために、複数の異なるタイプまたはカテゴリの情報を 1 つのバケットに格納するため、バケット内のオブジェクトのサブセット(共通のプレフィックスまたはタグ値によって定義)で分析を実行できます。各サブセットはフィルタによって定義されます。各バケットは最大 1,000 のフィルタを持つことができます。私の jbarr-public バケットのフィルタは次のとおりです:

プレフィックスが www で始まるオブジェクトを分析する簡単なフィルタを定義する方法は次のとおりです:

代わりにタグ名と値でフィルタリングすることができます。type という名前のタグに page という値を持つオブジェクトを分析する方法は次のとおりです:

各フィルタは、任意の好みの数のタグが付いた、多くとも1つのプレフィックスを指定することができます。分析内容を毎日ファイルにエクスポートすることもできます:

1 つ以上のフィルタが配置されると、分析は毎日実行され、フィルタをクリックするだけで分析を表示できます。たとえば、私の Archive と設定したフィルタをクリックすると、次のように表示されます:

この分析から、多くの良い情報が読み取れます!以下のようなことがわかります。

  • 127 日を振り返ってみると、30 日以上経過したオブジェクトのほとんどはアクセス頻度が低いことがわかります。私は、これらのオブジェクトを標準 IA のストレージに移行するライフサイクルルールを作成することで、コストを削減できます。
  • この時点で、私のストレージの大半(6.39 PB)は標準ストレージにあり、ほんの少しだけが標準 IA にあります(実のところ、私のバケットにはあまりデータがありませんでした。S3 チームは、私のアカウントにいくつかのテスト用メトリクスをロードしてくれました。非常に寛大です!)。
  • 127 日間の観測期間にわたって、標準ストレージの 16 %から 30 %くらいのデータが 1 日単位で、リトリーブされました。
  • 30 〜 45 日後、45 〜 60 日後、60 〜 90 日後、90 〜 180 日後、180 日以上後のオブジェクトは、まれにしかアクセスされず、標準 IA に配置するのに適しています。

ストレージクラス分析は、コンソール、CLI、または S3 API を使用して設定できます。

詳細は、Amazon S3 分析 – ストレージクラス分析 をご覧ください。

S3 オブジェクトのタグ付け
既存のロケーションベースの S3 オブジェクト管理モデル(バケットとプレフィックス)加えて、タグ付けは、そのオブジェクトは何か?という観点に基づいてストレージを管理する機能を提供してくれます。たとえば、部門の名前でオブジェクトをタグ付けし、そのタグに基づいてアクセスを許可する IAM ポリシーを構築することができます。これにより、単にタグを変更するだけで変更を反映させることができるなど、多くの柔軟性が得られます。

オブジェクトのライフサイクルのどの部分でも、それらを作成、更新、または削除することができます。タグは、IAM ポリシー、S3 ライフサイクルポリシー、および先ほど紹介した分析フィルタで参照できます。各オブジェクトは最大 10 個のタグを持つことができ、オブジェクトの各バージョンは異なるタグセットを持ちます。タグを利用して、ライフサイクルポリシーにてオブジェクトの有効期限を管理したり、特定のタグに関するアクティビティを反映する CloudWatch メトリクスを設定しても良いでしょう。

各オブジェクトのプロパティページには、現在のタグセットが表示され、それらのタグを編集できます:

また、CLI または S3 API からタグを設定してアクセスすることもできます。これら 2 つの方法のいずれかを使用する場合は、常に完全なタグセットの単位で設定する必要があります。たとえば、オブジェクトに 4 つのタグがあり、5 つ目のタグを追加する場合は、現在のセットを読み込み、新しいセットを追加してから、セット全体を更新する必要があります。

タグは、クロスリージョンレプリケーションを介してリージョン間で複製できますが、ソース側の IAM ポリシーでは s3:GetObjectVersionTagging 及び s3:ReplicateTags アクションを有効にする必要があります。

タグの費用は、10,000 個のタグにつき月額 0.01 ドルです。タグを追加または更新するリクエスト(それぞれ PUT および GET)は、通常の料金で課金されます。

詳細は、S3 オブジェクトのタグ付け を参照してください。

S3 インベントリ
S3 の LIST 操作は同期的で、一度に 1,000 個までのオブジェクトと、2 回目の LIST を開始するために使用するキーを返します。これは小規模から中規模のバケットやシングルスレッドのプログラムでは効果的ですが、大規模なバケットや複数のスレッドと組み合わせて使用するのは難しくなるかもしれません。

S3 インベントリを使用すると、バケットのインベントリレポートを毎日または毎週という形で受け取ることができます。プレフィックスを使用してレポートをフィルタリングしたり、サイズ、ストレージクラス、およびレプリケーションステータスなどをオプションのフィールドとして含めることができます。レポートは、ご自身のアカウントの S3 バケットに送信することも、適切な権限設定を使用して別のアカウントに送信することもできます。

以下は、www で始まるすべてのオブジェクトに対して、WebStuff という名前の、毎日のインベントリレポートをリクエストする方法の例です:

また、宛先のバケット(jbarr-s3-inventory)に書き込むための S3 権限を与える必要があります。使用したポリシーは次のとおりです(詳細は、Amazon S3 インベントリおよび Amazon S3 分析に対するアクセス権限の付与 を参照):

このインベントリのメカニズムは、マニフェスト、マニフェストのチェックサム、およびデータファイルの 3 つのファイルを作成します。マニフェストには、データファイルの場所とチェックサムが格納されています:

{
   "sourceBucket":"jbarr-public",
   "destinationBucket":"arn:aws:s3:::jbarr-s3-inventory",
   "version":"2016-11-30",
   "fileFormat":"CSV",
   "fileSchema":"Bucket, Key, Size, LastModifiedDate, ETag, StorageClass",
   "files":[
      {
         "key":"jbarr-public/DailyInventory/data/cf1da322-f52b-4c61-802a-b5c14f4f32e2.csv.gz",
         "size":2270,
         "MD5checksum":"be6d0eb3f9c4f497fe40658baa5a2e7c"
      }
   ]
}

解凍された後のデータファイルの外観は次のとおりです:

インベントリレポートを使用して毎日または毎週の処理ワークフローを強化する場合は、S3 通知機能の設定を忘れないでください!チェックサムファイルは他の 2 つのファイルの後に書かれていますので、安心して活用することができます。また、ライフサイクルポリシーを使用して、累積されていくインベントリファイルのコレクションを管理することを忘れないでください。

補足として、毎日または毎週のレポートを使用すると、複数の LIST 操作を何度も行うことと比較して最大 50 %節約できます。この機能の詳細については、Amazon S3 ストレージインベントリを参照してください。

S3 CloudWatch メトリクス
S3 は、ストレージ、リクエスト、およびデータ転送のメトリクスを CloudWatch に公開できるようになりました。ストレージメトリクスについては毎日レポートされ、追加料金なしで利用できます。リクエストとデータ転送のメトリクスは 1 分間隔で(処理待ち時間の後に)利用可能で、いつもの CloudWatch 課金レートで請求されます。 S3 分析の場合と同様に、CloudWatch メトリクスは、バケット全体でレポート化できますし、プレフィックスまたはタグを介して選択されたサブセットについて収集してレポート化することもできます。

メトリクスのフルセットは次のとおりです:

Storage Requests Data Transfer
  • Bucket Size Bytes
  • Number Of Objects
  • GET
  • LIST
  • PUT
  • POST
  • DELETE
  • ALL
  • HEAD
  • 4xx Errors
  • 5xx Errors
  • Total Request Latency
  • First Byte Latency
  • Bytes Uploaded
  • Bytes Downloaded

このメトリクス、S3 および CloudWatch コンソールで利用できます。私のバケットの S3 コンソールでの Total Request Latency の外観は次の通りです:

View in CloudWatch (CloudWatch で表示)をクリックし、任意のメトリックの CloudWatch アラームを設定することもできます。こちらは、私のバケットが 100 MB より大きくなった場合、通知を受けようと設定しているところです:

詳細は、S3 バケットにリクエストメトリクスを設定する方法 をご覧ください。

今すぐ利用可能
昨年末に、これらの機能にアクセスできるようになりました。アップデートされた S3 Console からアクセスできます。他にも多くの新機能が含まれています(詳しくは Introduction to the New Amazon S3 Console をご覧ください)。

– Jeff ; (原文:S3 Storage Management Update – Analytics, Object Tagging, Inventory, and Metrics / 翻訳: SA 焼尾)

 

AWSでの疎結合データセットの適合、検索、分析

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する(あるいは反論する)ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています(例えば、日時が間違っている、地理座標が間違っているなど)。
最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。
データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。
関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。
このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。

  • 異なる3つのデータセットを適合させて索引付けし、検索可能にします。
  • 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。
  • Amazon AthenaAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

(more…)