Category: Amazon Simple Storage Service (S3)

このブログでは、Amazon S3へのカスタマーアクセスポリシーを作成する方法について説明します。 これらのバケットはデフォルトでは公開されていません。このブログではさらに踏み込んで、Amazon Connectのレポートと通話録音が保存されているバケットをAmazon Connectにロックします。 Amazon Connectアカウントに割り当てられた適切な権限を使用することで、スケジュールされたレポートと保存されたレポートを表示したり、Amazon Connectインターフェイスから通話録音を再生したりできます。 セキュリティとデータのプライバシーは多くの顧客にとって最優先事項であるため、組織やプライバシーの要件を遵守することが重要です。 そのためには、IAMポリシーを使用して、Amazon S3に格納されているAmazon Connectアーティファクトのセキュリティをさらに強化することができます。 これは、顧客情報を危険にさらす可能性があるデータ漏洩または侵害を回避するのに役立ちます。 これにより、顧客のプライバシーを維持するためのセキュリティが強化され、ローカルの規制を遵守するのに役立ちます。 警告 セキュリティ設定を変更するときは注意してください。 これらの変更は恒久的なものであり、あなた自身のアクセスを制限してしまうかもしれません。まずはテストバケットで試すことをお勧めします。 もし間違えると、管理しようとしているリソースへのすべてのアクセスが失われるかもしれません。 これは、Amazon Connectインスタンスの動作に悪影響を及ぼす可能性があります。本番環境で行う前に、テストS3バケットでアクセス制限を試してみることを検討してください。 この記事で説明する次の手順は、S3バケットへのアクセスを制限するために必要です。 インスタンスに使用されているS3バケットを特定する Connectに使用されているIAMロールを特定する コマンドラインを使ってロールIDを特定する S3バケットポリシーを作成する S3バケットへのアクセスを確認する それでは始めましょう。 S3バケットを特定する Amazon Connectインスタンスに関連付けられているバケットを特定します。 インスタンスの作成時に既存のS3バケットを使用しなかった場合は、新しいバケットが作成されています。 次の例に示すように、Amazon Connectダッシュボードで、Amazon Connectに使用されているバケットを見つけることができます。 私のインスタンスの例で使用されているバケット名は、connect-25fd0a3be3ef です。 IAMロールを特定する Amazon Connectサービスに使用されているIAMロールを特定します。Amazon Connectインスタンスでの権限は、IAMロールにより許可されています。 注：Amazon ConnectはService-linkedロールを導入しました 。 この記事の手順は、2018年10月17日にService-linkedロールが導入される前に作成されたAmazon Connectインスタンスに適用されます。 近日中に、この記事をService-linkedロールに関する情報で更新する予定です。 Amazon ConnectサービスのIAMロールを見つけるには IAMコンソールを開きます。 Amazon Connectインスタンスを作成したときに作成されたロールを見つけます。 複数のインスタンスを作成した場合は、作成時間を確認することで、どのロールが各インスタンスに関連付けられているかを判断できます。 作成時間の列が表示されていない場合は、ページの右上隅にある歯車のアイコンから追加できます。 どのロールがどのインスタンスに対応しているか判断できない場合は、ロールがアクセス権を持つS3バケットが、そのインスタンスで使用されるバケットと一致するかを確認します。 正しいロールを使用していることを確認する […]

 EMRFS S3 最適化コミッターは、Amazon EMR 5.19.0 以降の Apache Spark ジョブで使用可能な新しい出力コミッターです。このコミッターは、EMR ファイルシステム (EMRFS) を使用して Apache Parquet ファイルを Amazon S3 に書き込む際のパフォーマンスを向上させます。この記事では、この新しい最適化されたコミッターを既存のコミッターアルゴリズム、つまり FileOutputCommitter アルゴリズムのバージョン 1 および 2 と比較するためにパフォーマンスベンチマークを実行します。最後に、新しいコミッターに対する現在の制限について検討し、可能な限り回避策を提供します。 FileOutputCommitter との比較 Amazon EMR バージョン 5.19.0 以前では、Parquet を Amazon S3 に書き込む Spark ジョブは、デフォルトで FileOutputCommitter という Hadoop コミットアルゴリズムを使用していました。このアルゴリズムには、バージョン 1 と 2 の 2 つのバージョンがあります。どちらのバージョンも、中間タスクの出力を一時的な場所に書き込むことに依存しています。その後、名前変更操作を実行して、タスクまたはジョブの完了時にデータが表示されるようにします。 アルゴリズムバージョン 1 には、2 つのフェーズの名前変更があります。1 つは個々のタスク出力をコミットするため、もう 1 つは完了/成功したタスクからのジョブ全体の出力をコミットするためです。タスクは名前変更ファイルを直接最終出力場所にコミットするので、アルゴリズムバージョン 2 […]

従来のオンプレミスデータベースのライセンスコストとインフラストラクチャコストは増えつづけ、データベースのスケーリングが大きな課題になっています。このような場合には何ができるでしょうか? このブログ記事では、AWS クラウドに移行するときにデータベースコストを削減し、可用性を向上させる戦略について説明します。

SFTP（Secure File Transfer Protocol） は、長年に渡って使用されてきたデータ処理やパートナー連携の一部として、現在でも多くの組織で利用されています。このようなシステムを「レガシー」という言葉で片付けてしまうのは簡単ですが、現実には、今後も長期間に渡ってSFTPは利用され続けるでしょう。そこで私達は、このようなワークフローを持つお客様が、スムーズかつ、大きな変更を伴わずにクラウド環境に移行できるようなお手伝いをしたいと思います。 AWS Transfer for SFTP 本日（2018年11月26日）、私達は完全マネージドかつ高い可用性をもつSFTPサービスである、「AWS Transfer for SFTP」をローンチいたしました。このサービスを利用するのに必要なことは、サーバーを作成し、ユーザーアカウントをセットアップし、ひとつまたは複数のAmazon Simple Storage Service（S3）バケットと関連付けるだけです。また、ユーザーIDや権限管理、鍵管理について細かく設定することが可能です。ユーザー管理については、このサービス用にユーザーを作成することもできますし、既存のIDプロバイダを利用することも可能です。アクセス権限については、IAMポリシーを用いて管理することができます。さらに、既存のDNS名やSSHキーを利用して現在のシステムを簡単にこのサービスに移行することもできます。そのため、あなたのお客様やあなたのパートナーはこれまでと何も変わらず、普段通りに既存のワークフローに従ってファイル転送を行うことができるのです。 このサービスでは、ライフサイクルポリシーや複数のストレージクラス、サーバーサイド暗号化、バージョニングといったS3の様々な機能を活用することが可能です。これにより、AWS Lambdaを用いて、アップロードされたファイルをすぐに処理するような「かしこい」FTPサイトを構築することもできますし、Amazon Athenaを用いてデータにクエリをかけたり、既存のデータ入力方法と組み合わせることも簡単にできます。一方、出力側としては、他のAWSサービスと組み合わせることで様々なファイルやカスタムソフトウェアをS3上に生成し、SFTPを用いてお客様やパートナーに提供することも可能です。

Amazon Simple Storage Service（S3）は12年と半月以上にわたり使用されており、数兆ものオブジェクトを格納し、毎秒数百万件のリクエストを処理します。お客様は、バックアップ＆リカバリ、データアーカイブ、データレイク、ビッグデータ分析、ハイブリッドクラウドストレージ、クラウドネイティブストレージ、災害対策のニーズにおいて、S3を活用しています。初期の頃の、汎用的なStandard (標準)ストレージクラスに始まり、その後ストレージクラスを追加して、よりよくお客様にサービスしてきました。現在では、4つのストレージクラスを選択することができ、それぞれのクラスはある特定のユースケース向けに設計されています。現在のオプションは以下の通りです。 Standard (標準) – よくアクセスされるデータ向けに設計されています Standard-IA (標準-低頻度アクセス) – 長期保管で、あまりアクセスされないデータ向けに設計されています One Zone-IA – 長期保管で、あまりアクセスされず、クリティカルではないデータ向けに設計されています Glacier – 長期保管で、あまりアクセスされず、アーカイブするクリティカルなデータ向けに設計されています S3にデータをアップロードする際、適切なストレージクラスを選ぶことができます。そして、S3のライフサイクルポリシーを使って、オブジェクトの作成日に基づき、そのオブジェクトをStandard(標準) からStandard-IA(標準-低頻度アクセス), One Zone-IAまたはGlacierへ移動をさせることができます。なお、低冗長化ストレージクラス(Reduced Redundancy Storage)は引き続きサポートされますが、新しいアプリケーションにおいては、One Zone-IAの利用が推奨されますのでご注意ください。 現時点(2018年11月26日以前)では、異なるS3ストレージクラスを階層化したい場合は、ライフサイクルポリシーが、ストレージ内のオブジェクトの作成日に基づいて、オブジェクトの移動を自動化します。また、現在Standard(標準)ストレージクラスに格納されているデータがあるとして、そのうちStandard-IA(標準-低頻度アクセス)ストレージクラスに格納するのが望ましいデータがあるかどうかを知りたい場合は、S3コンソールにあるストレージクラス分析を利用できます。これにより、どんなグループのデータがライフサイクルで階層化されると良いのかを把握することができます。しかしながら、データへのアクセスパターンが規則的でなかったり、組織にまたがって数多くのアプリケーションからアクセスされるが故に、状況を把握できないことが多々あります。もしくは、アプリケーション側に多くの時間をさきたいため、ストレージクラス分析のようなツールを利用する時間がないかもしれません。 新機能 Intelligent Tiering （インテリジェントティアリング） そこで、新しいストレージクラス、S3 Intelligent-Tiering (インテリジェントティアリング）を発表しました。これにより、アクセスパターンを把握するために何らか特別な開発をする必要はなく、もっと簡単にS3を有効活用できます。このストレージクラスには、高頻度と低頻度という2つのアクセス階層が組み込まれています。両方の階層とも、Standard(標準)ストレージクラスと同等の低レイテンシーを提供します。モニタリングと自動化の料金を抑えつつ、S3 Intelligent-Tiering はアクセスパターンをモニタし、連続30日間アクセスされていないデータを低頻度のアクセス階層に移動します。もしそのデータがのちにアクセスされた場合は、高頻度アクセス階層に自動的に戻されます。すなわち、アクセスパターンが変化するような状況でも、性能の影響なく、運用のオーバーヘッドもなく、データ取り出しのための料金もなく、利用料金を節約することができるのです。 Intelligent-Tiering ストレージクラスは、S3に新しくオブジェクトをアップロードする際に指定できます。また、ライフサイクルポリシーを用いて、ある一定時間の経過後にこのデータ遷移が有効になるようにすることもできます。データ取り出しの料金はなく、この新しいストレージクラスは、クロスリージョンレプリケーション、暗号化、オブジェクトのタグ付け、そして、インベントリを含む他のすべてのS3機能と併用できます。 データがあまりアクセスされないとほぼ確信している場合には、コスト節約の観点では、Standard-IA(標準-低頻度アクセス)の利用が引き続き有益な選択となります。しかしながら、アクセスパターンが予測できない場合や、変わりうる場合、Intelligent-Teringが有効です！ Intelligent Tiering の実践 S3へオブジェクトをアップロードする際に、この新しいストレージクラスをシンプルに指定してみます。 S3 Consoleにはストレージクラスがいつもの通り表示されています。 そして、Intelligent-Tiering を利用できるようライフサイクルルールを作成できます。 このように利用します。いくつかの注意点があります。 オブジェクトのサイズ – Intelligent-Tiering はどのようなサイズのオブジェクトにもご利用いただけますが、128KBよりも小さいサイズのオブジェクトは、低頻度アクセス階層には遷移しません。そして高頻度アクセス階層での料金レートが適用されます。 オブジェクトの保存期間 – […]

このブログ記事では HDFS 上の Apache HBase から、Amazon EMR の Amazon S3 上の Apache HBase に移行する方法のガイダンスとベストプラクティスについて解説します。 Amazon EMR の Amazon S3 上の Apache HBase Amazon EMR のバージョン 5.2.0 以降では、Amazon S3 上で Apache HBase を実行できます。Apache HBase のデータストアとして Amazon S3 を使用することにより、クラスターのストレージとコンピューティングノードを分割できます。コンピューティング要件のためにクラスターのサイジングをすることになるので、コスト削減につながります。クラスター上の HDFS に 3 倍のレプリケーションでデータセット全体をストアするために料金を払うわけではありません。

こんにちは。AWS ソリューションアーキテクトの上原誠(@pioh07)です。 9月21日に、「AWS Data Lake ハンズオンセミナー」を開催いたしました。前回行ったワークショップの３回目となります。前回も盛況でしたが、今回も80名近くのお客様にご参加頂きました。 はじめに、AWSにおけるデータ活用のベストプラクティスであるAmazon S3を中心とした Data Lakeについて解説し、ビッグデータ分析基盤の考え方として有名なラムダアーキテクチャの解説を行いました。 当イベントでは、AthenaやRedshiftのAWSサービスを駆使して実際にラムダアーキテクチャを構築してみる、というのがゴールです。とはいえすべてを構築し切るのはボリュームが大きいため、コース別に取り組めるようにハンズオンコンテンツを用意しました。最初にコースの説明を行い、出席いただいたお客様ご自身の課題に合わせてコースを選択頂き、ハンズオンを行っていただきました。今回、参加者も多くいらっしゃいましたので、サポートするソリューションアーキテクトも4名で対応させていただきました。 今回参加できなかった方も、ソリューションアーキテクトのサポートを受けながらハンズオンを行いログ分析を初めてみてはいかがでしょうか？   次回は冬ごろに開催予定です。ご参加お待ちしております。

先日 (2018/7/31) 開催しました AWS Black Belt Online Seminar 「S3ユースケース紹介及びサービスアップデート解説」 の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20180731 AWS Black Belt Online Seminar Amazon S3 ユースケースおよびサービスアップデート QA Q. S3アクセス速度を改善する方法があれば、教えてください A. 転送の速度について、インターネット経由で利用可能な帯域幅を十分に活用できていない、といった 課題感がおありになる場合には、Amazon S3 Transfer Accelerationを検討いただくと効果がある場合があります。 Webinar内でもご紹介しましたが、S3としては、スケールするリソースを用意していますので、 お手元からAWSへのネットワーク環境（インターネットやプライベートなネットワーク）をしっかり整備 いただくことが改善に繋がることが多いです。 Q. S3バケットを暗号化なしで使っていたが、途中からデフォルト暗号化しても問題はないでしょうか？ A. デフォルト暗号化は、すでにオブジェクトが格納されているバケットに対しても適用可能です。 その際、デフォルト暗号化を適用する前に格納されていたオブジェクトについては、 適用されませんので、ご注意ください。既存のオブジェクトの暗号化は、これまで通り、 オブジェクトごとに適用いただけます。 Q. 東京リージョンの S3 バケットにあるファイルを 中国リージョンの S3 へコピーするには、どのような方法がありますか？ A. 東京をはじめとする通常のリージョンから中国リージョンへは、S3のクロスリージョンレプリケーションが ご利用いただけないのは、お察しの通りです。 東京リージョンのバケットからオブジェクトをGETし、それを中国リージョンのバケットにPUTするという アプリケーションを何らかの形で準備する方法が検討いただけます。 その際に考えられる課題として、S3に限らず、中国へアクセスするネットワーク （またはその逆、中国側ホストからすると、東京へのアクセス）をどのように確保するかがあります。 中国へのアクセスを得意とされているネットワークプロバイダさんにもご相談いただくとよろしいかと思われます。 […]

こんにちは。AWS ソリューションアーキテクトの八木達也 ( @ygtxxxx ) です。 7月23日に、「Digital Advertising Japan Seminar 2018 – Machine Learning 事例祭り –」を開催いたしました。 AWSジャパン主催でデジタル広告業界の方向けのイベントを開催するのは2年ぶりでしたが、定員60人のところ55名の方にお集まりいただき、盛況となりました。             このイベントは「Digital Advertising、AdTech 領域における Machine Learningの実践知」を「互いに学び合う」ことができる場を作ることを目標としていたため、AWSメンバーによるプレゼンテーションだけではなく、お客様プレゼンテーションを中心としたAGENDAを構成しました。機会学習という領域における、テクノロジー視点でのお取組み、組織育成視点でのお取組み、それぞれの視点で最先端な活動をなさる方々よりご登壇を頂きました。 まずは主催者の唐木/八木よりオープニングセッションを行いました。 唐木より全体の説明を行い、八木より「Machine Learning for Digital Advertising」というタイトルでプレゼンテーションを行いました。 Machine Learning forDigital Advertising 次に、アナリティクス スペシャリスト ソリューションアーキテクトの志村より「AWS ML Services Update」というタイトルでプレゼンテーションを行いました。 AWS ML Update ここから、お客様セッションに移りました。 まずは、SIGNATE inc. 代表取締役社長 CEO/CDO 齊藤 秀 様より「国内外AIコンペティションからみるAI技術者のキャリアパスの潮流およびAIコンペサイトSIGNATEにおけるAWS活用事例」というタイトルでプレゼンテーションを行って頂きました。 […]

多くのお客様が、Amazon EMR と Apache Spark を使用してスケーラブルなビッグデータパイプラインを構築しています。大規模な生産パイプラインの場合、一般的ユースケースは、さまざまなソースから発生する複雑なデータを読み取ることです。このデータは、機械学習パイプライン、分析ダッシュボード、ビジネスレポートなどの下流アプリケーションに役立つように変換する必要があります。このようなパイプラインでは、Amazon EMR で Spark ジョブを並行して実行することがたびたび必要になります。この記事では、EMR バージョン 5.9.0 以降で利用可能な Apache Livy を使用して、複数の Spark ジョブを EMR クラスター上で平行して送信する方法を中心に取り扱います。 Apache Livy は、REST インターフェイスを通じて、Spark クラスターとのやりとりを容易にするサービスです。Apache Livy を使用すると、大きな jar ファイルを管理、デプロイする代わりに、REST API コールでシンプルな Scala コードまたは Python コードを送信できます。これは、EMR ステップ API を使用してシリアルで実行するのではなく、複数の Spark ジョブをパラレルで実行することでデータパイプラインを容易に拡張できるためです。お客様は、ワークフローの一環として一時的なクラスターを継続して利用し、結果としてコストを削減できます。 このブログ記事の目的に合わせ、今回は Apache Airflow を使用してデータパイプラインをオーケストレーションします。Airflow は ETL タスクの管理に役立つオープンソースのタスクスケジューラです。ワークフローを 1 か所からスケジューリングして管理できるため、Apache Airflow はお客様に人気があります。Airflow の Configuration as Code […]