Category: Storage

クラウド上で Windows アプリケーションを利用しようとしている組織では、通常、既存のアプリケーションや Windows 環境と完全に互換性のあるネットワークストレージを探します。例えば、エンタープライズ企業では ID 管理目的で Active Directory を使用し、フォルダやファイルへのきめ細かなアクセス制御のために Windows Access Control List を使用し、これらの企業のアプリケーションは Windows ファイルシステム (NTFS ファイルシステム) と完全互換のストレージに頼った作りになっています。 Amazon FSx for Windows ファイルサーバー Amazon FSx for Windows ファイルサーバーはこれら全てのニーズに対応しています。既存の Windows アプリケーションや Windows 環境で作業することを前提に設計されており、Windows ワークロードのクラウドへの Lift-and-Shift を非常に簡単にしてくれます。完全マネージド型の Windows ファイルサーバーに裏付けられたネイティブ Windows ファイルサーバーに、広く採用されている SMB (Server Message Block) プロトコルを介してアクセスできます。SSD ストレージで構築されている Amazon FSx for Windows ファイルサーバーは、皆さん (と皆さんの Windows アプリケーション) […]

ペタバイト（PiB – 1,125,899,906,842,624 バイト）は驚異的なデータ量であり、ヒトの脳の記憶容量見積もりの半分近くに相当するほどです。データレイクや、HPC（High performance Computing）、EDA（Electronic Design Automation） といったアプリケーションは伝統的にこのようなスケールに対応する必要があり、更に近年では機械学習やメディア処理といったデータインテンシブなアプリケーションも加わっています。 Amazon FSx for Lustre 本日（2018年11月28日）私達は、このような今まで夢見ていたような需要に答えるため、Amazon FSx for Lustreをローンチいたしました。Amazon FSx for Lustreは、著名かつ成熟したオープンソースプロジェクトであるLustreをベースにした高並列なファイルシステムであり、ペタバイトスケールのファイルシステムに対するミリ秒以下でのアクセスをサポートします。数千のクライアント（EC2インスタンスやオンプレミスサーバー）による同時アクセスにより、数百万IOPS（Input/Output Operation per Second）や数百GB/secものデータ転送を行うことが可能です。 このサービスでは、数分でファイルシステムを作成し、すぐにでも多数のクライアントからマウントして利用を開始することが可能です。また、完全マネージド型のサービスのため、管理や保守に手間をかける必要はありません。さらにこのサービスでは一時的な用途のスタンドアローンなファイルシステムを作成するだけでなく、S3のバケットとシームレスに接続してコンテンツがLustreファイルシステム上にあるかのようにアクセスすることも可能です。各ファイルシステムはNVMe SSDストレージにより構成されており、3.6 TiB単位でプロビジョンされ、1 TiBごとに200 MBpsのスループット、10,000 IOPSを発揮できるようにデザインされています。

これまで多くの AWS のお客様から AWS Cloud の内外へ大量のデータを移動させる必要があると言われてきました。そのユースケースには以下のものが挙げられます : Migration – 常に変化し続ける大きなデータセットをお持ちのお客様もいます。一度限りの転送を行うため、中断や停止は許されません。 Upload ＆ Process – クラウド上で処理するために大規模データセットをオンプレミスで定期的に生成するお客様もいます。これには Media & Entertainment 業界や Oil & Gas 業界、Life Science 業界の我々のお客様があげられます。 Backup / DR – 最後に、オンプレミス上の貴重なデータを災害対策やビジネス継続性のためにクラウドにコピーするお客様もいます。 これらのお客様は大規模データで利用しています。数十 TB から数百 TB の一度限りや定期的な転送は日常的に行われています。この規模では、ネットワーク帯域を効果的に使用し、高いスループットを得ることは必要不可欠で、信頼性やセキュリティ、使い勝手の良さも同様に重要です。 Introducing AWS DataSync 今日、我々のデータ転送サービスのポートフォリオに AWS DataSync が加わりました。AWS Snowball, AWS Snowmobile, Kinesis Data Firehose, S3 Transfer Acceleration, AWS Storage Gateway に加わる […]

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

昨年、私たちは調整可能なボリュームと呼ばれる新しいAmazon EBS 機能を開始しました。Amazon EBSの調整可能なボリュームを使用すると、ボリュームの使用中に、EBSボリュームのサイズを増やしたり、IOPSまたはボリュームのタイプを変更したりすることができます。この変更は操作に影響を与えなく、行うことができます。 この3つのブログ記事のシリーズでは、Oracleデータベースでの調整可能なボリュームを使用するメリットを検討します。また、調整可能なボリュームを使用してデータベースストレージを増やし、データベースの可用性または性能に影響を与えなく、準備されたIOPSを変更する方法についても説明します。 1番目の記事では、データベースストレージマネジメント用のロジカルボリュームマネージャー（LVM）のないオペレーティングシステムファイルシステムを使用して、Oracleデータベースで調整可能なボリュームを使用する方法について説明します。2番目の記事では、データベースストレージマネジメントにLVMを使用するOracleデータベースについて説明します。3番目の記事では、Oracle自動ストレージマネージャー（Oracle ASM）を使用するOracleデータベースについて説明します。 Amazon EBSの調整可能なボリュームの概要 調整可能なボリュームを使用すると、EBSボリュームの使用中に、EBSボリュームのサイズを増やしたり、準備されたIOPSを調整したり、EBSボリュームのタイプを変更したりすることができます。データベースはオンラインのままで、変更が有効になっている間に使用可能となっています。 AWS マネジメントコンソールから、簡単なAPI呼び出しを使用して、またはAWSコマンドラインインターフェース（AWS CLI）を使用して、ボリュームの変更を要求することができます。変更されるEBSボリュームは一連の状態を経過します。ボリュームの変更を要求すると、ボリュームは変更 状態になり、次に最適化状態になり、最後に完了状態になります。 EBSのボリュームのサイズの変更は、完了するまでに通常だと数秒がかかり、ボリュームが最適化状態になってから有効となります。パフォーマンス（IOPS）の変更には数分から数時間かかることがあり、構造の変更が行われたかどうかで決まります。EBSボリュームは最適化 状態になっていますが、ボリュームのパフォーマンスはソースとターゲットの構成仕様の間にあります。 Amazon EC2におけるOracleデータベースストレージレイアウト Amazon EC2でOracleデータベースを実行する場合は、EBSボリュームをデータベースストレージに使用します。一般的に、高性能のデータベースワークロード用のio1ボリュームと、それよりもあまり要求のないその他のワークロード用のgp2ボリュームを選択します。IO1ボリュームは、遅延の影響を受けやすい取引ワークロード用に設計されており、ボリュームにあたり最大32,000 IOPSまで提供します。GP2ボリュームは、価格と性能のバランスが優れており、ベースラインIOPSは3 IOPS/GB、ボリュームにあたり最大10,000 IOPSを提供します。 Oracleデータベースの物理ストレージには、ディスクに格納されているファイルのセット（データ、一時的なファイル、再実行ファイル、制御ファイルなど）が含まれています。これらのファイルの作成および管理には、オペレーティング・システムのファイル・システム、LVM、またはOracle ASMを使用することができます。 単純なデータベースストレージ操作 このセクションでは、単一のEBSボリュームとオペレーティングシステムファイルシステム（LVMなし）をデータベースストレージに使用する単純なOracleデータベース用のAmazon EC2におけるストレージレイアウトについて簡単に説明します。次に、準備されたストレージを増やしたり、準備されたIOPSを変更したりすることなどといったOracleデータベースのストレージの変更が調整可能なボリュームの導入前にどのように行われたかについて説明します。私たちは、この変更に関連する問題点を説明します。最後に、調整可能なボリュームを例に、これらの問題点のいくつかを解決する方法をお教えします。 単純なデータベースのストレージレイアウト 単純なデータベースについて、データベースストレージ用に単一のEBSボリュームのみを使用する場合があります。データベースファイルを格納するには、データベースファイルを分割してファイルシステムを作成します。このシナリオでは、LVMを使用しません。次の図は、この単純なデータベースストレージレイアウトを示しています。 調整可能ボリュームではないストレージ操作 データベースストレージ用の単一のEBSボリューム（LVMなし）を使用してストレージを増やしたり、またはシステム用に準備されたIOPSを変更したりすることができます。これを行うには、現在のEBSボリュームのスナップショットから目的のサイズとIOPSで新しいEBSボリュームを作成し、EBSボリュームをスワップします。この操作を行うには、次の手順を実行します。この操作には、データベースを停止する時間が必要です。 データベースを停止し、EBSボリュームのスナップショットを作成します。 スナップショットから求めたサイズとIOPSで新しいEBSボリュームを作成します。 古いEBSボリュームをEC2インスタンスから切り離し、新しいEBSボリュームをEC2インスタンスに接続します ファイルシステムのサイズを変更し（EBSのボリュームサイズが変更されている場合）、データベースを起動します。 調整可能なボリュームによる保管作業 EBSボリュームを変更するには、AWS CLIからの変更 – ボリュームコマンドまたはAWS マネジメントコンソールからの変更 – ボリュームオプションを使用します。その場合は、新しいボリュームサイズとIOPSを指定します。ボリュームサイズを変更せずに準備されたIOPSのみ変更する場合は、オペレーティングシステムレベルで変更する必要はありません。EBSボリュームのサイズを変更する場合は、ボリュームの変更後にファイルシステムのサイズを変更する必要があります。 EBSボリュームのサイズまたはIOPSを変更すると、データは自動的に複数のバックエンドデバイスに分散され、ホットスポットが発生しないようにしたり、準備されたIOPSを取得するようにします。 例：LVMを使用せずに単純なデータベースのストレージを増やす このセクションでは、停止時間が無くても、オペレーティングシステムファイルシステムをストレージマネジメントに使用するOracleデータベース用に準備されたストレージを増やす方法を示します。このデモでは、Amazon Linuxの上で動作するOracle 12cデータベースを使用します。30-GiB EBSボリュームがインスタンスに接続され、Oracleデータベースストレージ用のファイルシステムが作成されます。このデモでは、停止時間がなく、30 GiBから60 GiBに準備されたストレージを増やします。 サイズ変更がデータベースの停止時間なしに実行されたことを示すため、evtestprocというデータベースストアドプロシージャを作成しました。このプロシージャは、レコードを10秒間隔でevtesttabというテーブルに挿入します。このプロシージャは、サイズ変更操作の実行中に行われます。レコードが10秒間隔でevtesttabテーブルに挿入されていることを確認して、データベースの停止時間なしにサイズ変更が完了したことを確認できます。 ステップ1：現在の設定を確認する AWSマネジメントコンソールから、EBSボリュームのサイズを確認します。現在、次のスクリーンショットが示すように30 […]

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

このブログシリーズのパート 1 とパート 2 では、Amazon EBS のエラスティックボリューム機能と、Oracle データベースのストレージレイアウトとの連携について説明します。オペレーティングシステムにあるファイルシステムおよび、データベースストレージ管理のための Logical Volume Managers (LVM) を使用するデータベースとのエラスティックボリュームについてお話しします。この記事では、Oracle Automated Storage Management (Oracle ASM) を使った Oracle データベース用 Amazon EC2 のストレージレイアウトについて解説します。可用性に影響を与えずに、データベースストレージを拡張する方法をご紹介します。また、Oracle データベースでエラスティックボリュームを使用する利点について、いくつかを検討します。 Oracle ASM を使用したデータベースのストレージ操作 このセクションでは、ストレージ管理のための Oracle ASM を使用した Oracle データベース用 Amazon EC2 のストレージレイアウトについてまず簡単に説明します。次に、エラスティックボリューム機能が導入される前に、ストレージの増強やプロビジョニングされた IOPS の変更など、Oracle データベースストレージの変更がどのように行われたかについて解説します。関連する課題についてもお話しします。最後に、ある例を参考に、エラスティックボリュームを使って、これらの問題をいくつか解決する方法を示します。 Oracle ASM を使用するデータベース用ストレージレイアウト Oracle ASM は、Oracle データベース用ストレージを管理するためのボリュームマネージャーです。これには、データベース専用に設計されたファイルシステムが含まれています。Oracle ASM は、ディスク全体にデータを分散し、一貫したパフォーマンスを約束します。また、ディスクの追加や削除などのストレージ構成の変更後に、自動的にデータを再調整することもできます。 Oracle ASM を使用する場合、1 つ以上の ASM ディスクを含む […]

 このブログシリーズのパート 1 では、エラスティックボリュームの機能について検討します。また、データベースストレージとして LVM なしの単一の Amazon EBS ボリュームを使用するシンプルなデータベースである Oracle データベースストレージレイアウトについても検討します。この記事のパート 2 では、ストレージ管理に LVM を使用する Oracle データベースである Amazon EC2 のストレージレイアウトについて検討します。さらに、可用性に影響を与えることなくデータベースストレージを拡張する方法を示します。 LVM を使用したデータベースのストレージ操作 このセクションでは、ストレージ管理に LVM を使用する Oracle データベース向けの Amazon EC2 のストレージレイアウトについて簡潔に検討します。次に、プロビジョニングされたストレージを増やしたり、またプロビジョニングされた IOPS を変更するなど、 Oracle データベースストレージの変更が、エラスティックボリュームの導入前にどのように行われたかについて検討します。また、関連する課題についても取り扱います。最後に、エラスティックボリュームでこれら課題のうちのいくつかを解決する方法について例を挙げて示します。 LVM を使用するデータベースのストレージレイアウト データベースストレージ用に複数の EBS ボリュームが必要な大規模なデータベースの場合、LVM を使用してストレージを管理できます。このシナリオでは、ボリュームグループを作成し、ボリュームグループに EBS ボリュームを追加します。そして、ボリュームグループから論理ボリュームを作成し、論理ボリュームの上にファイルシステムを作成します。次の図は、LVM を使ったデータベースストレージレイアウトを示しています。 エラスティックボリュームのない Oracle データベースのストレージ操作 複数の EBS ボリュームとストレージ管理用の LVM を使用するシステム用にプロビジョニングされたストレージまたは IOPS を増やすために、新しい EBS ボリュームを作成します。そして、次の手順で新しい […]

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