Amazon Web Services ブログ

Category: Amazon Simple Storage Services (S3)

研究データ管理基盤でのAmazon S3の活用

学術研究機関においては研究不正対策なども含め、研究データや関連資料の長期保存が必要となってきています。日本学術会議から公開された文章においても論文の実験データ等の資料は原則論文発表後10年保存することが必要であるとされています。 研究データや関連資料の保存のための基盤は多くの機関で必要となりますが、その際に考えるべきことは何でしょうか? 様々なことを考える必要はありますが、例えば、 メンバー管理・アクセスコントロール ファイル等のバージョン管理 研究証跡の記録 ファイル保管 高い耐久性でかつ大容量のストレージ 長期保管 のようなことを考える必要があるでしょう。 この1〜4の部分に関しては 米国NPOである Center for Open Science  (COS)のOpen Science Framework  (OSF) など研究データ管理用のオープンソースソフトウェア等の開発が進み、国内でも国立情報学研究所などがこれらをGakuNinRDMとしてカスタマイズして提供するなど、研究データ管理基盤の利用が開始されはじめています。 研究データ管理基盤としてこのようなソフトウェア等を利用していくためには、ストレージについて考えておく必要があります。研究データは年々増える一方ですので、各機関にてストレージを確保しておく必要があります。その際に前述の5〜6についても考える必要があります。 まず高い耐久性を持つためにには、オブジェクトのコピーを複数分散して配置するなどして耐久性を高める必要があります。ストレージの容量ですが、実際に研究を進めてみなければ必要な容量が分かってきません。急激に研究が進み、保存すべきデータが急増することもあるでしょう。あまりに大きく容量を見積もりすぎてしまうと、実際にはそこまで使用しなかった場合にその分のコストが無駄になってしまいます。また長期保存の場合、サービスの永続性が重要になってきます。論文を公開してから10年ということは、論文を発表し続ける研究者にとって、常にそこから10年ということになり、永続的にストレージを確保し続けて行く必要があることを意味します(図1)。 図1 研究が継続している場合のデータ保管期間 ストレージをオンプレミスで確保しようと考えた場合、データの耐久性を確保するために、複数拠点に冗長化されたストレージを用意する必要が出てきます。運用中はディスク等の故障時の交換やハードウェアの保守期限に合わせて後継となる機器の調達、またそれに伴うデータをコピーの手間も発生します。またオンプレミスで用意する多くの場合、最初にストレージ容量を決めておかなくてはならないため、過剰な容量を確保する傾向にもなってしまいコストが増大します。 現在、SINET5とAWSはInternet Exchange(IX)でピアリングもしているため※1、各機関からAWS上に構築されているシステムへアクセスするとSINET5の出口であるIXから直接AWS入る形となり、いわゆる一般に言うインターネットには出て行くことなく通信が可能となります。 また機関で用意されるストレージ はAmazon S3※2を利用頂くことで、標準で耐久性の高いストレージを利用でき、使用した分だけの支払いとなるため、スモールスタートが可能で、研究データや関連資料の量など将来を見積もり事が難しいものを長期間保管するのに適しており、前述の5〜6に対処することができると考えられます。 さまなざな機関や組織においてクラウドを利用する機会が増えています。利用形態もいくつか選択肢があり、AWSに直接サインアップしてご利用いただくケースやAPNパートナーの請求代行サービスを利用しアカウント管理と日本円での支払いを選択いただくことも可能です。各機関に合わせた幅広い選択肢があります。一方で入札による一括でしか調達できないような場合には、単価契約での調達や、図2のように例えば「Amazon S3で月あたりの積み上げで総計T[GB]のストレージをNヶ月以上利用出来、月あたり最大M[GB]以上利用できる環境を提供すること」などとして調達することが考えられます。このようにすることで、オンプレミスのように最初から最大の容量を調達することなく、徐々に増えていくストレージを調達することが可能であると考えられます。この際機関側と契約する企業間で総計容量の上限に達した場合にどのような扱いとするのかをあらかじめ決めておくことも重要です。 図2 時間軸とストレージの容量 他方、法令やデータの置き場所を気にされるお客様もいらっしゃいますが、お客様自身でAWS カスタマーアグリーメントの準拠法を日本法に変更し、更に、同契約に関するあらゆる紛争に関する第一審裁判所を東京地方裁判所に変更※3することができます。AWS ではコンテンツの所有権と管理権をお客様にお渡ししていますので、例えば東京リージョンを選択し、そこにデータを置いている場合はデータは日本国内に留まります。詳しくはAWSのデータプライバシー※4をお読みください。 まとめ 研究データ保管のための基盤としてが研究データ管理用のオープンソースソフトウェア等の開発がすすんでいます 研究データを置くための機関側ストレージとしてAmazon S3を利用頂くことができます Amazon S3は標準で耐久性が高く、使用した分だけの課金となるため、スモールスタートが可能で、研究データや関連資料の長期保存にも向いています   ※1  Amazon Web Services ブログ「学術研究機関でのSINET5を経由したAWSの利用」: https://aws.amazon.com/jp/blogs/news/sinet5-aws-explain/ ※2  Amazon Simple Storage Service (Amazon […]

Read More

Amazon S3 アップデート — SigV2 の廃止時期、延期と変更

Amazon S3 API に対して行うすべてのリクエストは、それが本物であることを確認するために署名する必要があります。初期の AWS では、署名バージョン2 または SigV2 と呼ばれる署名モデルを使用していました。2012年には、より柔軟な署名方法である SigV4 を発表し、2013年以降に開始されたすべてのリージョンでは、こちらを唯一の署名方法としました。また、その時点で、すべての新しい S3 アプリケーションにこちらのSigV4を使用することをお勧めしました。 2018年に、我々はSigV2のサポート終了を2019年6月後半とするという発表をしました。多くのお客様がアプリケーションを更新してくださいました(多くのケースで単純にSDKのアップデートを行うだけです)が、SigV4を使用するために、サポートを延期してもらえないかという多くのご要望をいただきました。 新しい日付、新しいプラン オリジナルのプランに関するフィードバックに応じて、重要な変更を行っていきます。概要は次のとおりです。 オリジナルのプラン — SigV2のサポートは2019年6月24日に終了します。 改訂されたプラン — 2020年6月24日以降に作成された新しいバケットは SigV2 署名付きリクエストはサポートされません。ただし、既存のバケットについて引き続き SigV2 がサポートされますが、我々はお客様が古いリクエスト署名方法から移行するよう働きかけます。 既存のバケット、それは SigV2 をサポートする一部のAWSリージョンにおいて、SigV2 を引き続き使用することはできますが、SigV4 に移行することを強くお勧めします。そのことで重要なセキュリティ上のメリットと効率性のメリットが得られます。この新しい署名方法では、長期のAWSアクセスキーから派生した、別途これに特化した署名キーを使用します。このキーは、サービス、地域、および日付に固有です。これにより、サービスとリージョン間の分離が強化され、キーの再利用に対する保護が強化されます。内部的に、SigV4 実装では認証チェックの結果を安全にキャッシュすることができます。これにより、レイテンシーが改善され、アプリケーションの全体的な堅牢性向上が期待できます。詳細については、「署名バージョン4の変更点」を参照してください。 SigV2 を使っているかどうかの判断方法 S3 は 2006年以来からのAWSサービスです。あなたやあなたの前任者が書いたコードの一部はまだまだ現役で利用されている可能性があり、SigV2で署名された要求を忠実に行っているかもしれません。CloudTrailのデータイベントまたは S3 サーバーアクセスログを使用して、この古風なリクエストを見つけることができますので、そのアプリケーションを更新対象にしてください。 CloudTrailのデータイベント — 各 CloudTrail イベントエントリの additionalDataElement 内で SignatureVersion 要素を探します(詳細については、「AWS CloudTrail を使用して Amazon S3 署名バージョン2リクエストを識別する」を参照してください)。 S3 サーバーアクセスログ […]

Read More

Amazon Connect 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バケットが、そのインスタンスで使用されるバケットと一致するかを確認します。 正しいロールを使用していることを確認する […]

Read More

EMRFS S3 最適化コミッターを使用して、Apache Parquet 形式での Apache Spark 書き込みパフォーマンスを向上させる

 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 […]

Read More

AWS クラウドへの移行時にデータベースコストを削減して可用性を向上させる

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

Read More

新発表 – AWS Transfer for SFTP – Amazon S3と連携したマネージドなSFTPサービス

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を用いてお客様やパートナーに提供することも可能です。

Read More

新機能- Intelligent TieringによるAmazon S3の自動的なコスト最適化

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よりも小さいサイズのオブジェクトは、低頻度アクセス階層には遷移しません。そして高頻度アクセス階層での料金レートが適用されます。 オブジェクトの保存期間 – […]

Read More

Amazon EMR の Amazon S3 上の Apache HBase への移行: ガイドラインとベストプラクティス

このブログ記事では 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 倍のレプリケーションでデータセット全体をストアするために料金を払うわけではありません。

Read More

【開催報告】AWS Data Lake ハンズオンセミナー 秋

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

Read More