Category: Amazon S3


AWS ストレージの更新 – S3 と Glacier の値下げ + Glacier に追加された取得オプション

2006 年に、S3 のサービスを画期的な従量課金制 (月額 15 セント/GB の初期料金) で開始しました。以降、これまでの間に GB あたりの料金を 80% 値下げし、すべての AWS リージョンで S3 を開始しました。元の汎用モデルにはユーザー主導型の機能として、ウェブサイトのホスティングVPC の統合IPv6 のサポートなどが追加され、さらに S3 の低頻度アクセスなどの新しいストレージオプションも追加されました。AWS の多くのお客様は、法的、コンプライアンス、その他の目的で重要なデータをアーカイブしますが、このようなデータは滅多に参照することがないため、2012 年に Glacier を発表しました。そして、ライフサイクルのルールを使用して S3、S3 の低頻度アクセス、Glacier の間でデータを転送する機能を提供しました。ここでは、2 つのビッグニュースを紹介します。まず、S3 の標準ストレージと Glacier ストレージの料金が値下げになります。さらに、Glacier に新しい取得オプションが追加されます。

S3 と Glacier の値下げ
AWS を長くご利用いただいているお客様はご存じだと思いますが、AWS では絶えずコスト削減に取り組んでおり、その結果を AWS の値下げという形でお客様に還元しています。S3 の標準ストレージの GB あたりの料金は、ほとんどの AWS リージョンで 2016 年 12 月 1 日より値下げになります。12 月の使用量に対する請求には、自動的に値下げ後の新料金が反映されます。標準ストレージの新料金は以下のとおりです。

リージョン 0〜50 TB (USD / GB / 月) 51〜500 TB (USD / GB / 月) 500+ TB (USD / GB / 月)
  • 米国東部(バージニア北部)
  • 米国東部 (オハイオ)
  • 米国西部 (オレゴン)
  • 欧州 (アイルランド)

(値下げ幅は 23.33%〜23.64%)

0.0230 USD 0.0220 USD 0.0210 USD
  • 米国西部(北カリフォルニア)

(値下げ幅は 20.53%〜21.21%)

0.0260 USD 0.0250 USD 0.0240 USD
  • 欧州 (フランクフルト)

(値下げ幅は 24.24%〜24.38%)

0.0245 USD 0.0235 USD 0.0225 USD
  • アジアパシフィック (シンガポール)
  • アジアパシフィック (東京)
  • アジアパシフィック (シドニー)
  • アジアパシフィック (ソウル)
  • アジアパシフィック (ムンバイ)

(値下げ幅は 16.36%〜28.13%)

0.0250 USD 0.0240 USD 0.0230 USD

上の表を見ておわかりのように、料金体系も 6 段階から新しい 3 段階に簡略化されます。Glacier のストレージの料金もほとんどの AWS リージョンで値下げになります。たとえば、US East (Northern Virginia)US West (Oregon)、または Europe (Ireland) リージョンで 1 GB を 1 か月保存した場合の料金はわずか 0.004 USD (1 セントの半分未満) であり、43% の値下げになります。参考までに、同じ量のストレージは 2012 年の Glacier の開始時では 0.010 USD であり、前回の Glacier の値下げ (30%) 時では 0.007 USD でした。料金の値下げは、お客様が AWS を信頼して何兆というオブジェクトを利用された直接の結果です。ただし、利点はそれだけではありません。新しい機能に関して寄せられたフィードバックによると、クラウドストレージプラットフォームの真価は迅速で安定した進化にあります。お客様からは、お客様のニーズを事前に把握し、そのニーズに応じた新しい機能を提供している点を評価できるとよく言われます。

Glacier の新しい取得オプション
AWS の多くのお客様は、Amazon Glacier を階層化ストレージアーキテクチャのアーカイブ用コンポーネントとして利用しています。Glacier を使用すると、コンプライアンス要件 (組織または規制の要件) を満たしながら、必要なだけクラウドベースの処理能力を引き出してデータを処理し価値を取り出すことができます。Glacier には、データを取り出すための新しいオプションが 2 つ追加されました。データの取得を急ぐ場合は、少しのコスト負担で緊急オプションを利用できます。急がない場合は、より低価格の取得オプションを利用できます。Glacier に保存したデータの量とそれを取り出す頻度に基づいて、新しい料金体系を導入しました。この変更は AWS でのサービスの提供コストを正確に反映した結果ですが、説明しようとすると少し複雑です。これからは従量ベースの取得料金が、よりシンプルな GB あたりの料金に変ります。メディアおよびエンターテインメント業界のお客様は、テレビ映像を Glacier にアーカイブします。緊急事態が発生して特定の画像を取り出すために分を争うような場合、画像にすばやくコスト効率よくアクセスする必要があります。医療関係のお客様は、「患者を待たせている間に」アーカイブされた医療画像やゲノム情報にすばやくアクセスする必要があり、衛星データを販売するフォトアーカイブ企業も似たような必要性に迫られます。一方、データの取り出しを事前にスケジュールできて、5〜12 時間以内にデータを取得できれば問題ないというお客様もいます。以上のような状況を応じて、Glacier からデータを取り出す際に、以下のオプションを使い分けることができます (これまでの従量制の取得モデルは今後適用されません)。

標準取得は、Glacier が従来提供していたオプションの新しい名前であり、API 駆動のすべての取得リクエストに対するデフォルトです。データは数時間 (通常 3〜5 時間) で取得されます。料金は 0.01 USD/GB、0.05 USD/1,000 リクエストです。

緊急取得は、迅速対応アクセスのニーズに対処します。データはすばやく取得されます。通常、所要時間は 1〜5 分です。Glacier に 100 TB を超えるデータを保存 (または保存を計画) し、頻度は低いが急いでデータのサブセットをリクエストするような状況には、このオプションが最適です (データ量が少ない場合は、S3 の頻繁にアクセスしないストレージクラスがより適切なオプションです)。取得コストは 0.03 USD/GB、0.01 USD/リクエストです。

通常、取得の所要時間は 1〜5 分です (全体の需要により異なります)。まれに需要が非常に多い場合でも、この所要時間内にデータを取り出す必要がある場合は、取得容量をプロビジョニングすることができます。プロビジョニングを行うと、すべての緊急取得のデータは自動的にプロビジョンド容量を経由して取得されます。プロビジョンド容量の各ユニットは月額 100 USD です。これにより、5 分ごとに最低 3 回の緊急取得を行うことができます。取得スループットは最大 150 MB/秒です。

一括取得は、事前にスケジュールできる場合や緊急でない場合に最適です。通常、取得の所要時間は 5〜12 時間。料金は 0.0025 USD/GB (標準取得の 75% 未満)、0.025 USD/1,000 リクエストです。一括取得は、大量のデータを 1 日以内に取得する場合に最適です。さらに数時間を余分に待機できる場合は、大きな割引も得られます。

アーカイブを取り出す際に、どの取得オプションも指定しないで InitiateJob を呼び出すと、標準取得が開始されます。既存のジョブは引き続き正常に動作し、新料金が課金されます。詳細については、データ取り出し (よくある質問 – Glacier) を参照してください。これまで同様、嬉しいニュースでした。同じように喜んでいただければ幸いです。

Jeff;

IPv6 サポートの更新 – CloudFront、WAF、S3 Transfer Acceleration

先日のブログ「Amazon S3 で IPv6 をサポート」の続報として、今回は Amazon CloudFrontAmazon S3 Transfer AccelerationAWS WAF と 50 か所以上に渡るすべての CloudFront エッジロケーションでも IPv6 サポートが利用可能になったことをお知らせします。AWS では、すべての自律システムネットワーク (ASN) で IPv6 を有効にするための段階的な移行プロセスを本日より開始し、今後数週間に渡りすべてのネットワークで拡張する予定です。

CloudFront IPv6 のサポート
Amazon CloudFront ディストリビューションごとに IPv6 サポートを有効にすることができます。IPv6 を使用して CloudFront エッジロケーションに接続する閲覧者とネットワークは自動的に IPv6 でコンテンツを取得します。IPv4 を使用して接続する場合は以前のように機能します。オリジンサーバーへの接続には IPv4 を使用します。

新たに作成したディストリビューションでは自動的に IPv6 が有効になります。既存のディストリビューションを変更するには [Enable IPv6] を有効にします。これはコンソールまたは CloudFront API から設定できます。

この新機能の重要事項については次をご覧ください。

  • エイリアスレコード – ディストリビューションで IPv6 サポートを有効にすると、ディストリビューションの DNS エントリは AAAA レコードを含むものに更新されます。Amazon Route 53 とエイリアスレコードを使用してディストリビューションのドメインすべてまたは一部をマップしている場合、そのドメインに AAAA エイリアスを追加する必要があります。
  • ログファイルCloudFront アクセスログを有効にしている場合、IPv6 アドレスが c-ip フィールドで表示されるので、ログ処理システムがそれに対処できるようにしておいてください。
  • 信頼された署名者信頼された署名者と IP アドレスのホワイトリストを併せて使用している場合は、IP ホワイトリストと実際のコンテンツの IPv4/IPv6 ディストリビューションを備える、信頼された署名者 URL の IPv4 に限られたディストリビューションの使用を強くお勧めします。このモデルでは、IPv4 アドレスを使用して送信した署名リクエストにサインしたことで、コンテンツのリクエストがホワイトリストに載っていない別の IPv6 アドレスから届くといった問題を回避することができます。
  • CloudFormation – CloudFormation サポートを準備中今回のリリースでは、CloudFormation テンプレートから作成したディストリビューションで IPv6 は有効になりません。既存のスタックを更新する場合、スタックで参照したディストリビューションの設定に変更はありません。
  • AWS WAFAWS WAF と CloudFront を併せて使用している場合は、IPv6 アドレスのホワイトリストまたはブラックリストで適切となるように WebACL と IP ルールセットを必ず更新してください。
  • Forwarded ヘッダー – ディストリビューションで IPv6 を有効にする場合は、オリジンに渡した X-Forwarded-For ヘッダーに IPv6 アドレスが含まれているようにしてください。オリジンがこの形式のヘッダーを処理できるか確認してください。

詳しくは「Amazon CloudFront で IPv6 をサポート」をご覧ください。

AWS WAF IPv6 サポート
AWS WAF はアプリケーションレイヤーで発生する攻撃からアプリケーションを保護します (詳しくは「新機能 – AWS WAF」をご覧ください)。

AWS WAF が IPv4 アドレスまたは IPv6 アドレス経由で届くリクエストを調べられるようになりました。IPv6 と一致するウェブ ACL を作成することができます。詳しくは「IP Match Conditions の使用」をご覧ください。

既存の WAF 機能はすべて IPv6 に対応、そのパフォーマンスで目に見える変化はありません。IPv6 は WAF が収集し表示したサンプルリクエストで表示されます。

S3 Transfer Acceleration IPv6 サポート
この重要で新しい S3 機能が IPv6 をサポートするようになりました (詳しくは「AWS ストレージの更新 – Amazon S3 Transfer Acceleration + より多くのリージョンでさらに大きくなった Snowballs」をご覧ください)。アップロードに使用できるデュアルスタックのエンドポイントに簡単に切り替えることができます。次のように変更するだけです。

https://BUCKET.s3-accelerate.amazonaws.com

https://BUCKET.s3-accelerate.dualstack.amazonaws.com

クライアントオブジェクトの作成とデュアルスタック転送の有効を可能にする AWS SDK for Java 使用コードは次の通りです。

AmazonS3Client s3 = new AmazonS3Client();
s3.setS3ClientOptions(S3ClientOptions.builder().enableDualstack().setAccelerateModeEnabled(true).build());

大半のアプリケーションとネットワークスタックは自動的に IPv6 の使用を好む傾向があるので、これ以上の設定は必要ありません。IPv6 アドレスと併せて使用する上で機能動作に問題がないことを確認するため、パケットの IAM ポリシーを見直すことをお勧めします。詳しくは「IPv6 を使用して Amazon S3 にリクエストを送信」をご覧ください。

テストを忘れずに
AWS リージョンへの IPv6 接続に制限があったり存在しない場合は、代わりに IPv4 が使用されます。以前公開したブログでも触れましたが、IPv6 をサポートするようにクライアントシステムを設定することができます。ただし、その場合は IPv6 パケットをインターネットにルートするように設定していないネットワークに接続する必要があります。こうした理由から、IPv6 に切り替える前に何らかのアプリケーションレベルで行うエンドツーエンド接続のテストを行うことをお勧めします。

Jeff;

サービス開始 – Amazon S3 が IPv6 をサポート

ご存知かもしれませんが、インターネットに接続されたすべてのサーバーとデバイスには独自の IP アドレスが必要です。遡ること 1981 年、RFC 791 (“インターネットプロトコル”) により IP アドレスとは 32 ビットのエンティティで、かつ組織の異なる IP アドレスの必要数に対応するよう設計された 3 つの異なるネットワークとサブネットサイズ (クラス A、B、C – 基本的に大中小のサイズ) を有するものと定義されました。やがてこの形式は無駄が多いとみなされるようになり、より柔軟な CIDR (Classless Inter-Domain Routing) 形式が標準化され使用されました。32 ビットエンティティ (一般に IPv4 アドレスとして知られる) はよく用いられてきましたが、インターネットの継続的な成長により、最終的には利用可能なすべての IPv4 アドレスが割り当てられ使用されてしまうでしょう。

この成長に対応し今後の展開に道を開くよう、ネットワーク、デバイス、サービスプロバイダーは IPv6 へと移行中です。128 ビット/IP アドレスの IPv6 にはたっぷりのアドレス空間 (単純計算すると 128 ビットには 35 億個の IP アドレスを 10 穣個 (1 穣は 10 の 27 乗)、つまり宇宙の星の数ほどの人数に割り当てられるのに十分な数) があります。膨大なアドレス空間が IPv6 の明白なメリットである一方、そのほかにより繊細なメリットもあります。これには拡張性、動的アドレスの割り当てに関するより良いサポート、および追加のセキュリティの組み込みサポートが含まれます。

本日、Amazon S3 バケットのオブジェクトが IPv6 アドレス経由、新しい「デュアルスタック」エンドポイント経由でアクセスできるようになったことを発表します。DNS ルックアップがこの型のエンドポイントで実行される場合、IPv4 アドレスでは “A” レコードが返されますが、IPv6 アドレスでは “AAAA” レコードが返されます。ほとんどの場合、顧客環境のネットワークスタックでは自動的に AAAA レコードを優先し IPv6 アドレスを使用して接続します。

IPv6 経由で S3 コンテンツにアクセスする
IPv6 経由でコンテンツにアクセスを開始するには、次のような新しいデュアルスタックエンドポイントに切り替える必要があります:

http://BUCKET.s3.dualstack.REGION.amazonaws.com

または:

http://s3.dualstack.REGION.amazonaws.com/BUCKET

AWS Command Line Interface (CLI) または AWS Tools for Windows PowerShell をお使いなら、 --enabledualstack フラグを使用してデュアルスタックエンドポイントに切り替えます。現在 AWS SDKs を更新しており、 use_dualstack_endpoint の設定の使用をサポートし、来週半ばまでには本番環境に展開することを見込んでいます。それまで SDK の開発者ガイドを参照してこの機能を有効化する方法をご覧になってください。

知っておいていただきたい事項
IPv6 にスムーズに移行する上で知っておいて頂きたい事項がいくつかあります:

バケットと IAM ポリシー – IP アドレス経由でのアクセスを許可または制限するポリシーをご利用の場合、新しいエンドポイントに切り替える前に希望する IPv6 範囲が含まれるよう更新してください。そうしないとクライアントは AWS リソースへのアクセスを間違って取得、または喪失するかもしれません。対応する IPv6 アドレスを追加し、特定の IPv4 アドレスからのアクセスを除外するすべてのポリシーを更新します。IPv6 接続性 – ネットワークスタックは IPv4 アドレスより IPv6 アドレスを選択する傾向があるため、特定の状況下では異常事態が生じ得ます。クライアントシステムが IPv6 用に設定されても、IPv6 パケットをインターネットにルーティングするよう設定されていないネットワークに接続されるかもしれません。それでデュアルスタックエンドポイントに切り替える前に、必ずエンドツーエンド接続のテストをしてください。ログエントリ – ログエントリには必要に応じて IPv4 または IPv6 アドレスが含められます。内部アプリケーションまたはサードパーティアプリケーションを使用するログファイルを分析する場合、IPv6 アドレスを含むエントリを認識し処理できることを確認します。S3 機能サポート – IPv6 サポートはウェブサイトホスティング、S3 Transfer Acceleration、BitTorrent 経由のアクセスを除き、すべての S3 機能で利用可能です。リージョンサポート – IPv6 サポートはすべてのコマーシャル AWS リージョンと AWS GovCloud (US) で利用できます。China (Beijing) リージョンではご利用になれません。

Jeff

AWSストレージアップデート – Amazon S3 Transfer Accelerationとより大きなSnowballをより多くのリージョンに展開

いくつかのAWSチームは、オンプレミスのデータをクラウドへ移動する処理を簡素化し、高速化することにフォーカスしています。当初はとてもベーシックなPUTのオペレーションとマルチパートアップロード機能のご提供から始めて、ディスクを送付する方法をご提供し、昨年のAWS re:Inventで、AWS Import/Export Snowballをローンチすることでそのプロセスはより簡素化されました。(AWS Import/Export Snowball – Amazon所有のストレージアプライアンスを利用して1週間あたり1ペタバイトのデータ転送を実現を参照下さい。)

本日、S3とSnowballに関する重要な改善についてお伝えします。この改善はどちらもデータ移行プロセスをよりシンプルに、より加速させるようデザインされています。以下が新しい機能になります。:

Amazon S3 Transfer Acceleration – この新機能はAWSのエッジロケーションとネットワークプロトコルの最適化を利用し、S3へのデータ転送を高速化します。大きなオブジェクトを国を跨いで転送する場合、50%から500%の改善、もしくは特定の環境下ではそれ以上の高速化を見込むことができます。

より大きなSnowballをより多くのリージョンで – より大きなキャパシティ(80TB)のSnobwballが利用可能となりました。加えて、新たに2つのUSリージョン、および2つのインターナショナルリージョンでご利用頂くことができるようになりました。

Amazon S3 Transfer Acceleration

現在AWSは50箇所以上ののエッジネットワークを提供しています。今までは、Amazon CloudFrontによるコンテンツの配信やAmzon Route53による高速なDNSクエリの応答に利用されてきました。本日のアナウンスにより、S3へ、もしくはS3からのデータ転送の高速化にエッジネットワークが活用されます。もしあなたが、高速なインターネット回線を持ち、大容量のオブジェクトもしくは、大量のコンテンツを地域間で転送する際に、その恩恵を受けることが可能となります。

エッジネットワークを、あなたのアップロード場所(デスクトップもしくはオンプレミスのデータセンター)とターゲットのS3 Bucket間のブリッジとして利用いただけます。Bucketにてこの機能を有効にする(AWSマネージメントコンソールのチェックボックスをチェックする)ことで、簡単にBucketのエンドポイントをBUCKET_NAME.s3-accelerate.amazonaws.comのように変更することができます。それ以外の設定は不要です。設定後は、TCPのコネクションが自動的に最寄りのAWSのエッジロケーションにルーティングされます。S3 Transfer AccelerationによりAWSが管理するバックボーンネットワークと効率化されたネットワークプロトコル、エッジとオリジン間のパーシステント接続、最大化された転送ウィンドウなどを活用し、S3へのアップロード転送を行います。

下記が、自分のBucketに対してTransfer Accelerationを有効化する方法になります。(jbarr-public):

私のBucketのエンドポイントはhttps://jbarr-public.s3.amazonaws.com/でしたが、ツールやコードのエンドポイントをhttps://jbarr-public.s3-accelerate.amazonaws.com/に変更するだけです。これだけで、アップロードを行うとS3 Transfer Accelerationの恩恵をうけることができます。また同じルールで構成されたURLを利用することで、ダウンロードも高速化することが可能です。

ネットワーク設定や環境は日々もしくは場所により常に変動することから、Transfer Acceleration によりアップロードパフォーマンスが改善する可能性がある転送の場合のみ費用をお支払いいただきます。高速化転送は、GBアップロードあたり$0.04から課金されます。またS3の他の機能同様、初期費用および長期的なコミットメントは不要です。

新たに提供するAmazon S3 Transfer Acceleration Speed Comparisonを利用することで、Transfer Accelerationの効果を確認いただくことができます。私のUS West(Oregon)リージョンにあるAmazon WorkSpacesで実行した結果が下記となります:

距離に応じた、自分のリージョンからターゲットへの高速化の割合が確認いただけるかと思います。

本機能に関してより詳細を確認したい場合は、S3 開発者ガイドGetting Started with Amazon S3 Transfer Accelerationを参照してください。本日より北京(中国)リージョンおよびAWS GovCloud(US)以外の全てのリージョンでご利用いただけます。

より大きなSnowballをより多くのリージョンで
AWS Import/Export SnowballはAWSクラウドへの大量データの持ち込み/搬出用途として、既に多くのAWSのお客様にご利用頂いています。例えば、こちらはGE Oil & Gas様でのオンサイトのSnowballの様子です。
Ben Wilson (CTO of GE Oil & Gas)氏は、この写真を次の注釈付きで LinkedInに投稿されています。:

“ピグとSnowball- 最高のカップル!25TBのパイプラインピグデータはAWS Snowball でAWSへと送られます。こちらは私達がデータを取り出すGEピグです。私たちはAWSの新しい機能を試し、今までのやり方を変えていくことをいつも楽しんでいます。”

本日より、Snowballは4つの新しいリージョン: AWS GovCloud (US), 米国西部(北カリフォルニア), EU(アイルランド),アジアパシフィック(シドニー)でご利用可能となりました。来年には、残りのAWSリージョンでもご利用いただけるようになることを期待しています。

オリジナルのSnowballアプライアンスは50TBの容量でしたが、本日、80TBの容量を持つ新しいアプライアンスを発表します。米国東部 (北バージニア), 米国西部 (オレゴン), 米国西部(北カリフォルニア), AWS GovCloud (US)リージョンにデータを出し入れする場合には、どちらかのキャパシティを選択出来ます。EU(アイルランド),アジアパシフィック(シドニー)リージョンの場合は、80TBのアプライアンスをご利用頂きます。こちらは、インポートジョブを作成するときの容量選択の方法を示しています。

Snowballについてより詳しく知りたい方は、Snowball FAQと、開発者ガイドをご参照下さい。

Jeff;(翻訳はSA北迫、布目が担当しました。原文はこちら)

Amazon Kinesis アップデート – Amazon Elasticsearch Service との統合、シャード単位のメトリクス、時刻ベースのイテレーター

Amazon Kinesis はストリーミングデータをクラウド上で簡単に扱えるようにします。

Amazon Kinesis プラットフォームは3つのサービスから構成されています:Kinesis Streams によって、開発者は独自のストリーム処理アプリケーションを実装することができます;Kinesis Firehose によって、ストリーミングデータを保存・分析するための AWS へのロード処理がシンプルになります;Kinesis Analytics によって、ストリーミングデータを標準的な SQL で分析できます。

多くの AWS のお客様が、ストリーミングデータをリアルタイムに収集・処理するためのシステムの一部として Kinesis Streams と Kinesis Firehose を利用しています。お客様はこれらが完全なマネージドサービスであるがゆえの使い勝手の良さを高く評価しており、ストリーミングデータのためのインフラストラクチャーを独自に管理するかわりにアプリケーションを開発するための時間へと投資をしています。

本日、私たちは Amazon Kinesis Streams と Amazon Kinesis Firehose に関する3つの新機能を発表します。

  • Elasticsearch との統合 – Amazon Kinesis Firehose は Amazon Elasticsearch Service へストリーミングデータを配信できるようになりました。
  • 強化されたメトリクス – Amazon Kinesis はシャード単位のメトリクスを CloudWatch へ毎分送信できるようになりました。
  • 柔軟性 – Amazon Kinesis から時間ベースのイテレーターを利用してレコードを受信できるようになりました。

Amazon Elasticsearch Service との統合

Elasticsearch はポピュラーなオープンソースの検索・分析エンジンです。Amazon Elasticsearch Service は AWS クラウド上で Elasticsearch を簡単にデプロイ・実行・スケールさせるためのマネージドサービスです。皆さんは、Kinesis Firehose のデータストリームを Amazon Elasticsearch Service のクラスターへ配信することができるようになりました。この新機能によって、サーバーのログやクリックストリーム、ソーシャルメディアのトラフィック等にインデックスを作成し、分析することが可能になります。

受信したレコード(Elasticsearch ドキュメント)は指定した設定に従って Kinesis Firehose 内でバッファリングされたのち、複数のドキュメントに同時にインデックスを作成するバルクリクエストを使用して自動的にクラスターへと追加されます。なお、データは Firehose へ送信する前に UTF-8 でエンコーディングされた単一の JSON オブジェクトにしておかなければなりません(どのようにこれを行うかを知りたい方は、私の最近のブログ投稿 Amazon Kinesis Agent Update – New Data Preprocessing Feature を参照して下さい)。

こちらが、AWS マネージメントコンソールを使用したセットアップの方法です。出力先(Amazon Elasticsearch Service)を選択し、配信ストリームの名を入力します。次に、Elasticsearch のドメイン(この例では livedata)を選択、インデックスを指定し、インデックスのローテーション(なし、毎時、日次、週次、月次)を選択します。また、全てのドキュメントもしくは失敗したドキュメントのバックアップを受け取る S3 バケットも指定します:

そして、バッファーのサイズを指定し、S3 バケットに送信されるデータの圧縮と暗号化のオプションを選択します。必要に応じてログ出力を有効にし、IAM ロールを選択します:

一分程度でストリームの準備が整います:

コンソールで配信のメトリクスを見ることもできます:

データが Elasticsearch へ到達した後は、KibanaElasticsearch のクエリー言語による視覚的な検索ができます。

総括すると、この統合によって、皆さんのストリーミングデータを収集し、Elasticsearch に配信するための処理は実にシンプルになります。もはや、コードを書いたり、独自のデータ収集ツールを作成したりする必要はありません。

シャード単位のメトリクス

全ての Kinesis ストリームは、一つ以上のシャードによって構成されており、全てのシャードは一定量の読み取り・書き込みのキャパシティを持っています。ストリームにシャードを追加することで、ストリームのキャパシティは増加します。

皆さんは、それぞれのシャードのパフォーマンスを把握する目的で、シャード単位のメトリクスを有効にすることができるようになりました。シャードあたり6つのメトリクスがあります。それぞれのメトリクスは一分間に一回レポートされ、通常のメトリクス単位の CloudWatch 料金で課金されます。この新機能によって、ある特定のシャードに負荷が偏っていないかを他のシャードと比較して確認したり、ストリーミングデータの配信パイプライン全体で非効率な部分を発見・一掃したりすることが可能になります。例えば、処理量に対して受信頻度が高すぎるシャードを特定したり、アプリケーションから予想よりも低いスループットでデータが読まれているシャードを特定したりできます。

こちらが、新しいメトリクスです:

IncomingBytes – シャードへの PUT が成功したバイト数。

IncomingRecords – シャードへの PUT が成功したレコード数。

IteratorAgeMilliseconds – シャードに対する GetRecords 呼び出しが戻した最後のレコードの滞留時間(ミリ秒)。値が0の場合、読み取られたレコードが完全にストリームに追いついていることを意味します。

OutgoingBytes – シャードから受信したバイト数。

OutgoingRecords – シャードから受信したレコード数。

ReadProvisionedThroughputExceeded – 秒間5回もしくは2MBの上限を超えてスロットリングされた GetRecords 呼び出しの数。

WriteProvisionedThroughputExceeded – 秒間1000レコードもしくは1MBの上限を超えてスロットリングされたレコードの数。

EnableEnhancedMetrics を呼び出すことでこれらのメトリクスを有効にすることができます。いつもどおり、任意の期間で集計を行うために CloudWatch の API を利用することもできます。

時刻ベースのイテレーター

任意のシャードに対して GetShardIterator を呼び出し、開始点を指定してイテレーターを作成することで、アプリケーションは Kinesis ストリームからデータを読み取ることができます。皆さんは、既存の開始点の選択肢(あるシーケンス番号、あるシーケンス番号の後、最も古いレコード、最も新しいレコード)に加え、タイムスタンプを指定できるようになりました。指定した値(UNIX 時間形式)は読み取って処理しようとする最も古いレコードのタイムスタンプを表します。

— Jeff;
翻訳は SA 内海(@eiichirouchiumi)が担当しました。原文はこちらです。