Category: Amazon Elastic File System


新機能 − Amazon Elastic Filesystem(EFS)で保管データの暗号化をサポート

我々は、1年と少し前にAmazon Elastic File Systemを本番ローンチしました。(詳細は Amazon Elastic File System – Production Ready in Three Regionsを確認ください)。そしてその年の後半には、Direct Connec経由でのオンプレミスアクセスを追加し、今年になって米国東部(オハイオ)、欧州(フランクフルト)、アジア・パシフィック(シドニー)リージョンでも利用可能となりました。

保管データの暗号化

本日、保管データの暗号化サポートを加えることにより、EFSがより利用しやすくなりました。ファイルシステムの作成時に、ファイルシステム上に保管するコンテンツを暗号化するための鍵を選択することが可能です。AWSが管理するビルトインの鍵、あるいは、AWS Key Management Service(KMS)を利用して自身で作成した鍵がご利用可能です。ファイルのメタデータ(ファイル名、ディレクトリ名、ディレクトリの内容)はAWSが管理する鍵で暗号化されます。どちらの暗号化の形式も、業界標準のAES−256アルゴリズムを利用して実装されています。

新しいファイルシステムを作成するときにすぐにセットアップ可能です。シンプルにビルトイン鍵(aws/elasticfilesystem)、あるいは自分の鍵を選択するだけです:

EFSが残りをすべて行います! コンソールでファイルシステムを選択することで、望みどおり暗号化されているかどうかを確認できます:

データをメタデータの暗号化には、FIPS 140-2の承認に適合した暗号化アルゴリズムが利用されます。暗号化は透過的に行われ、全体のパフォーマンスへの影響は最小限です。

AWS Identitiy and Access Management(IAM)を利用して、Customer Master Key(CMK)へのアクセスを制御することができます。CMKは、ファイルシステムへアクセスするために有効化されていなければいけません。鍵を無効化すると、新しいファイルシステムの作成に使用できなくなり、保護対象の既存のファイルシステムへのアクセスが(一定期間後)ブロックされます。詳細については、Managing Access to Encrypted File Systemsをご参照ください。

すぐにご利用可能

保管データの暗号化はEFSがサポートされている全てのリージョンでご利用可能です。追加料金は発生しません。

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

NICE EnginFrame – AWS のユーザーフレンドリーな HPC

去年、AWS が NICE 買収の契約に署名したこと、そして両社が協力し合い高パフォーマンスと科学計算において今まで以上に優れたツールとサービスを開発していく予定であることをブログでお知らせしました。そして本日、NICE EnginFrame 2017 をリリースするに至りました。この製品は AWS Cloud のパワー、スケール、柔軟性を活用する技術的および科学的なアプリケーションのセットアップと実行のプロセスをシンプルにするように設計されています。1 時間以内に、完全に機能する HPC クラスターをセットアップし、シンプルなウェブベースのユーザーインターフェイスを介してアクセスすることができます。すでに EnginFrame を使用している場合は、引き続きオンプレミスで実行したりクラウドに移動することができます。

AWS Inside
クラスター (1 つ以上のクラスターを起動することも可能) は Virtual Private Cloud (VPC) 内にあり、複数の AWS サービスや機能を使用して構築されています。そうした機能とは Amazon Linux AMI、共有 Amazon Elastic File System、NFS スタイルのファイルストレージ、ユーザー認証の AWS Directory Service、トラフィック管理の Application Load Balancers などを実行している Amazon Elastic Compute Cloud (EC2) インスタンスなどです。このようなマネージド型サービスはワークロードや作業に集中しやすくすることができます。システムソフトウェアのアップグレード、パッチ、処理やストレージのスケーリング、そして自分でクラスターを構築した場合に伴うその他の責任などを心配する必要がありません。EnginFrame は AWS CloudFormation テンプレートから起動します。パラメーター化し自己完結型のテンプレートは、起動する各クラスターが同じ様に設定されることを確実にします。テンプレートを実行すると 2 つの異なる CloudFormation スタック (AWS リソースの集合) が作成されます。

Main Stack – このスタックは自分のクラスターが共有している EFS ベースのストレージと、デフォルトのクラスタースタックへの受信リクエストをルートするアプリケーションロードバランサーをホストします。このスタックは IAM ロールや SSL 証明書のセットアップや管理を担う一連の AWS Lambda 関数のホストでもあります。

Default Cluster Stack – このスタックはメインスタックが管理し、手間の掛かるタスクを処理する場所になっています。このクラスターは CfnCluster によりサポートされています。不要になったコンピューティングノードを終了することで必要に応じてスケールアップやスケールダウンを行うことができます。EnginFrame も実行します。

EnginFrame ポータル
クラスターを起動すると、ウェブベースの EnginFrame ポータルを使用して連係動作します。このポータルはアプリケーション (バッチとインタラクティブの両方) とデータ、ジョブへのアクセスを許可します。ご自分 (もしくはクラスターの管理者) は、バッチアプリケーションや特定のファイルタイプに関連付けられているアクションのテンプレートを作成することができます。EnginFrame にはジョブの出力を追跡できるようにするインタラクティブなファイルマネ―ジャとスプーラービューが含まれています。このリリースで、NICE は同時に複数のファイルをアップロードできるようにする新しいファイルアップローダーを追加しました。ファイルアップローダーは一般的によく使用されているファイルをキャッシュすることでアップロード時間を削減することもできます。

EnginFrame の実行
EnginFrame を詳しく理解するために AWS で使用する EnginFrame のクイックスタートのページを開始してみました。リージョンには US East (Northern Virginia) リージョンを選択し [Agree and Continue] をクリックしました。

自分の AWS アカウントにログインし CloudFormation コンソールにアクセスしました。CloudFormation テンプレートの URL はすでに入力済みだったので [Next] をクリックしました。

スタックを設定します。名前を指定しネットワーク設定をセットアップしてパスワードを入力しました。

EC2 キーペアを選び自分のクラスター用に設定をセットアップしました (EC2 の新しいユーザーであれば、まず作成してからダウンロードする必要があります)。[Next] をクリックします。

足跡のためにタグ (キーと値) を入力します。ただしこの場合は IAM ロールアドバンスドオプションはそのままにし、もう一度 [Next] をクリックします。

次のページで設定を確認し (ここでは表示していません)、CloudFormation が私の代わりにいくつかの IAM リソースを作成することを了承します。次に [Create] をクリックします。

CloudFormation が必要な AWS リソースをすべて作成、設定、連係させます (このプロセスは約 30 分ほど掛かるので犬の散歩をするのに丁度いいでしょう‘)。

EnginFrame クラスターのステータスが CREATE_COMPLETE になったらそれをクリックし Output のセクションを開いて EnginFrameURL を探します。

URL は自己署名の SSL 証明書を使用する Application Load Balancer を参照するようになっているので、意図的にそのサイトにアクセスすることを確認する必要があります。

今起動した CloudFormation で EnginFrame が実行しています。ユーザー名 efadmin とスタック作成時に設定したパスワードでログインしました。

この時点でサービスを作成することができます。最初はまずシンプルに、アップロードしたファイルを圧縮するだけのサービスにしました。青色のタイトルバーで [Admin’s Portal] をクリックし、次にアクセスします。

[Manage] > [Services] > [New] をクリックしてサービスを定義します。

[Submit] をクリックし [Job Script] タブを選択したらデフォルトスクリプトにラインを追加し [Close] をクリックしてアクションウィンドウを閉じます。

新しいサービスを保存し [Test Run] をクリックして希望通りに動作するか確認します。デスクトップからファイルをアップロードし [Submit] をクリックしてジョブを起動します。

ジョブが私のクラスターで実行するようにキューが登録されます。

今回紹介したのは EnginFrame の機能のごく一部に限ります。

可用性と料金
EnginFrame 2017 は今すぐご利用いただけます。お支払いいただくのは使用した分の AWS リソース (EC2 インスタンス、EFS ストレージなど) となります。評価期間の最初の 90 日は無料で EnginFrame をご利用いただけます。その後は同時ユーザー数をベースにライセンスの元で EnginFrame をご利用いただけます。

Jeff;

Amazon EFS の更新 – Direct Connect を介したオンプレミスアクセス

昨年、Amazon Elastic File System をご紹介 (Amazon Elastic File System – Amazon EC2 の共有ファイルストレージ) し、本年初頭には本番環境での利用可能を発表 (Amazon Elastic File System – 3 つのリージョンで本番環境での利用が可能) しました。本年初頭の始動後、何千人もの AWS のお客様が、クラウド上の共有ファイルストレージを設定、スケーリング、および運用するためにこれを利用してきました。 そしてこの度、シンプルかつ信頼性が高い AWS Direct Connect を介したオンプレミスアクセスの紹介により、EFS はより便利なものとなります。これは、強く求められていた機能で、移行、クラウドバースト、バックアップにおいて有用です。 この機能を移行に使用するには、オンプレミスサーバーに EFS ファイルシステムをアタッチし、データをそこにコピーしてからクラウドで必要に応じて処理するだけです。データはそのまま AWS に長期間保存しておくことができます。クラウドバーストでは、オンプレミスデータを EFS ファイルシステムにコピーし、Amazon Elastic Compute Cloud (EC2) インスタンスを使用して高速で分析して、結果をオンプレミスにコピーしたり Amazon QuickSight で視覚化したりできます。オンプレミスサーバーから EFS ファイルシステムにアクセスした場合でも、または EC2 インスタンスからアクセスした場合でも、強力な一貫性とファイルロックを含む同様のファイルシステムのアクセスセマンティックスが得られます (もちろん、両方を同時にもできます)。また、EFS の一部であるマルチ AZ の可用性と耐久性を利用できます。 この新機能を利用するためには、オンプレミスのデータセンターと Amazon Virtual Private Cloud 間の専用ネットワーク接続を、AWS Direct Connect(専用線接続サービス) を使用して設定する必要があります。 その後、お客様のファイルシステムで、AWS Direct Connect(専用線接続サービス) 接続を介して到達可能なサブネットにマウントターゲットがあることを確認する必要があります。

また、マウントターゲットのセキュリティグループにルールを追加して、オンプレミスサーバーからポート 2049 (NFS) へのインバウンドの TCP および UDP トラフィックを許可する必要があります。

ファイルシステムを作成したら、IP アドレスでマウントターゲットを参照し、オンプレミスで NFS マウントしてファイルのコピーを開始できます。IP アドレスは、AWS Management Console 内から利用可能です。

Management Console でも、詳しい手順を知ることができます。オンプレミスのマウント手順をクリックしてください。

以下もご覧ください。

この機能は今すぐご利用いただけます。US East (Northern Virginia)US West (Oregon)Europe (Ireland)US East (Ohio) リージョンでは追加費用はありません。

Jeff;

Amazon Elastic File System が 3 つのリージョンで利用可能に

AWS のストレージ製品ラインは時間とともに豊かに多様な成長を遂げてきました。単一のストレージクラスで開始した Amazon S3 は現在、定期的かつ低頻度にアクセスされる、アーカイブ済みのオブジェクト向けの複数のストレージクラスを提供しています。同様に、単一のボリュームタイプで始まった Amazon Elastic Block Store (EBS) も、現在は 4 種類の SAN スタイルブロックストレージを提供しており、各ストレージが特定のアクセスパターンやデータタイプ向けに設計されています。オブジェクトストレージおよびブロックストレージへの対応は S3 および EBS によってカバーされていることから、AWS は次にファイルシステムに注目を向けました。AWS は、複数の EC2 インスタンス向けに、完全マネージド型ファイルシステムへの低レイテンシーの共有アクセスを提供するため、昨年 Amazon Elastic File System (EFS) を発表しました。そしてこのたび、EFS が US East (Northern Virginia)、US West (Oregon)、Europe (Ireland) の各リージョンでも本稼動使用できるようになりました。本日の発表に至るまで、AWS は長期のプレビュー期間にわたり、実に幅広いお客様のユースケースを検討してきました。EFS プレビューは、大規模かつ高スループット処理ワークロード、および多様なコンテンツとウェブ配信に最適でした。プレビュー期間、こうしたワークロードに対する EFS パフォーマンスについてポジティブなフィードバックが多数寄せられました。一方、レイテンシーの変化に影響を受け、ファイルシステムメタデータを多用するワークロードについても同様に優れたサポートを提供してほしいというご要望もいただきました。こうしたフィードバックへの取り組みの結果、本日のラウンチは非常に幅広いユースケースに対応できる設計となっています。これまで、お客様には EFS に大変ご満足いただき、すぐにでも使用を開始したいというご意見をいただいております。

EFS を構築した理由
AWS をご利用の多くのお客様から、拡張可能なファイルストレージをより簡単に管理する方法を提供してほしいというご要望をいただいてきました。こうしたお客様には、共通の名前空間と、企業または部署別のファイル階層への簡単なアクセスによってメリットを受ける、ウェブサーバ群やコンテンツ管理システムを稼動している方もいらっしゃいます。一方、多数の大規模ファイルを作成、処理、削除する HPC およびビッグデータアプリケーションを運用して、著しく変化するストレージ利用とスループットの需要に対応しているお客様もいらっしゃいます。また、AWS のお客様は、高可用性、高耐久性とともに、アクセスと変更に対しても強力な整合性を提供するモデルを求めてきました。

Amazon Elastic File System
EFS では、POSIX 準拠のファイルシステムを作成して、NFS 経由で 1 つ以上の EC2 インスタンスにアタッチできます。このファイルシステムは必要に応じて拡大/縮小するため (一定の上限はなく、ペタバイト規模まで拡張可能)、ストレージスペースや帯域幅を事前にプロビジョニングする必要はありません。料金が発生するのは、使用したストレージ分のみです。EFS は、ファイル、ディレクトリ、リンク、メタデータのコピーを複数のアベイラビリティーゾーンに保存することで、データを保護します。複数のクライアントが同時にアクセスする大規模なファイルシステムのサポートに必要なパフォーマンスを提供できるよう、Elastic File System パフォーマンスもストレージにあわせて拡張します (この点については後ほど詳しくご説明します)。それぞれの Elastic File System は 1 つの VPC からアクセス可能で、VPC 内で作成するマウントターゲットを介してアクセスされます。VPC のどのサブネットでもマウントターゲットを作成することができます。各マウントターゲットへのアクセスは、通常通りセキュリティグループを使ってコントロールされます。EFS には 2 つの異なるパフォーマンスモードがあります。1 つめのモードは、デフォルトの汎用モードです。数十、数百、数千の EC2 インスタンスがファイルシステムに同時アクセスする場合を除き、このモードを使用します。もう 1 つのモード I/O 最大は、より高レベルの集計スループットと 1 秒あたりのオペレーション数にあわせて最適化されますが、ファイルオペレーションのレイテンシーがわずかに高くなります。ほとんどの場合は汎用モードから開始し、関連する CloudWatch メトリックス (PercentIOLimit) を監視してください。汎用モードの I/O 制限のプッシュを開始する場合は、I/O 最大モードで新しいファイルシステムを作成し、ファイルを移行すれば、さらに高いスループットと 1 秒あたりのオペレーション数を活用することができます。

Elastic File System の動作
Elastic File System の作成、マウント、アクセスは非常に簡単です。私は AWS Management Console を使用しました。EFS API、AWS Command Line Interface (CLI)、またはAWS Tools for Windows PowerShell を使うオプションもあります。コンソールを開き、[Create file system] ボタンをクリックしました。

次に、VPC の 1 つを選択し、パブリックサブネットにマウントターゲットを作成しました。

私のセキュリティグループ (corp-vpc-mount-target) では、EC2 インスタンスがポート 2049 のマウントポイントにアクセスできます。以下はインバウンドルールです。アウトバウンドルールも同じです。

Name タグと Owner タグを追加し、汎用パフォーマンスモードを選択しました。

次に、情報を確認して、[Create File System] をクリックしました。

すぐにファイルシステムを使用できるようになりました (マウントターゲットもその後 1 分ほどで準備が完了しました)。

[EC2 mount instructions] をクリックし、EC2 インスタンスにファイルシステムをマウントする方法を確認しました。

ファイルシステムを /efs としてマウントすると、以下のようになりました。

多くのファイルをコピーし、しばらく NFS ステータスを確認していました。

コンソールに、ファイルシステムによる消費容量のレポートが表示されます (この情報は 1 時間ごとに収集され、収集後 2~3 時間で表示されます)。

 

CloudWatch メトリックス
各ファイルシステムは、CloudWatch に以下のメトリックスを提供します。

  • BurstCreditBalance – バーストレベルのスループットで転送可能なデータ量。
  • ClientConnections – ファイルシステムに接続されているクライアント数。
  • DataReadIOBytes – ファイルシステムから読み込まれるバイト数。
  • DataWriteIOBytes – ファイルシステムに書き込まれるバイト数。
  • MetadataIOBytes – 読み込み/書き込みされるメタデータのバイト数。
  • TotalIOBytes – 前述の 3 つのメトリックスの合計。
  • PermittedThroughput – ファイルシステムのサイズに基づいた最大許容スループット。
  • PercentIOLimit – 汎用モードで利用可能な I/O の割合。

これらのメトリックスは CloudWatch コンソールで確認できます。

 

EFS バースト、ワークロード、パフォーマンス

各 EFS ファイルシステムで可能なスループットは、ファイルシステムの拡張とともに増加します。ファイルベースのワークロードは通常スパイクが発生しやすく、短期間は高レベルのスループットが要求され、それ以外の期間は要求されるスループットのレベルが下がります。EFS は、必要に応じて高スループットレベルに対応してバーストするよう設計されています。すべてのファイルシステムは、100 MB/秒スループットまでバーストできます。1 TB を超えるファイルシステムではストレージ TB あたり 100 MB/秒までバースト可能です。例えば、2 TB のファイルシステムでは 200 MB/秒まで、10 TB のファイルシステムでは 1,000 MB/秒スループットまでバースト可能です。1 TB を超えるファイルシステムでは、使用時間の半分ファイルシステムが使われていない場合、残りの半分の時間はバーストし続けることができます。EFS ではクレジットシステムを使ってファイルシステムがバースト可能なタイミングを判断します。各ファイルシステムは、ファイルシステムのサイズに応じたベースラインレート (ストレージ 1 TB あたり 50 MB) でクレジットを蓄積し、データの読み込み/書き込み際にこれを使用します。クレジットが蓄積すると、ファイルシステムでベースラインレートを超えるスループットを利用できるようになります。実際の運用例で考えてみましょう。

  • 100 GB のファイルシステムでは 1 日 72 分まで最大 100 MB/秒のバーストが可能です。または、連続して 5 MB/秒までバーストできます。
  • 10 TB のファイルシステムでは、1 日 12 時間最大 1 GB/秒まで、または連続して 500 MB/秒バーストが可能です。

クレジットシステムの仕組みについては、ファイルシステムパフォーマンスについての EFS ドキュメントを参照してください。この機能をよく理解するために、数日間ファイルをコピーして連結してみたところ、結局 2 TB を超えるファイルシステムの容量が使用されました。ファイルコレクションが 1 TB を超えると、使用量にあわせて PermittedThroughput メトリックスも上昇することがわかりました。以下は、表示された内容です。

どのファイルシステムでも同じように、スループットはワークロードの特徴に左右されます。平均 I/O サイズ、EFS への同時接続数、ファイルアクセスのパターン (ランダム/シーケンシャル)、リクエストモデル (同期/非同期)、NFS クライアント構成、NFS クライアントを実行する EC2 インスタンスのパフォーマンス特性のそれぞれがポジティブまたはネガティブな影響を及ぼします。要約すると以下のようになります。

  • 平均 I/O サイズ – 小さいファイルに関連付けられたメタデータを NFS プロトコル経由で管理する作業、および耐久性と可用性の高いデータにするための EFS 側の作業が組み合わさって、オペレーションあたりのオーバーヘッドが作られます。一般的に、オペレーションあたりのオーバーヘッドは、より大量のデータで償却されるため、全体的なスループットは平均 I/O サイズに合わせて高まります。また、通常、読み込みにかかる時間は書き込みよりも高速です。
  • 同時接続数 – 各 EFS ファイルシステムは、数千のクライアントからの接続に対応できます。(複数の EC2 インスタンスからの) 高度に並列化された動作を実行できる環境では、多数の同時オペレーションに対応する EFS の機能が効果を発揮します。
  • リクエストモデル – マウント時間に async オプションを含めることで、ファイルシステムへの非同期書き込みを有効にすると、保留中の書き込みがインスタンス上でバッファされた後、非同期に EFS に書き込まれます。sync オプションでマウントされたファイルシステムにアクセスしたり、キャッシュをバイパスするオプション (例: O_DIRECT) を使ってファイルを開くと、代わりに EFS に対する同期リクエストが発行されます。
  • NFS クライアント構成 – 一部の NFS クライアントでは、読み込み/書き込みバッファに対して今日の標準よりもはるかに小さい値がデフォルトで使用されています。1 MiB への引き上げを検討してください (これは mount コマンドに対するオプションです)。EFS では NFS 4.0 または 4.1 クライアントを使用でき、4.1 の方が高いパフォーマンスを提供します。
  • EC2 インスタンス数 – 大量の I/O を処理するアプリケーションでは、大量のメモリや処理能力が必要となることがあります。十分なメモリと処理能力を用意し、適切なインスタンスサイズとタイプを選択してください。非同期読み込み/書き込みを実行する場合、カーネルでのキャッシュに追加のメモリが使用されます。また、EFS ファイルシステムのパフォーマンス特性は、EBS 最適化インスタンスの使用に左右されない点に注意してください。

ファイルシステムのベンチマークは技術と科学の融合です。成熟した信頼できるツールを使用し、複数回これらのツールを実行して、上記の検討事項に照らしながら結果を確認するようにしてください。期待されるパフォーマンスに関する詳しいデータは、Amazon Elastic File System ページでご確認いただけます。

ご利用について
EFS は、US East (Northern Virginia)、US West (Oregon)、Europe (Ireland) リージョンで、今日から使用を開始できます。料金は、保存データの量に応じて、1 日数回にわたるサンプルに基づき 1 か月あたりギガバイト単位で請求されます。通常通り日割り計算となり、US East (Northern Virginia) リージョンでの 1 か月の料金は、1 GB あたり 0.30 USD となります。最低料金やセットアップ料金はありません (詳しくは、EFS 料金表ページをご覧ください)。利用無料枠対象のお客様については、1 か月あたり最大 5 GB までの EFS ストレージを無料でご利用いただけます。

Jeff;

※6月末現在Amazon Elastic File Systemは東京リージョンで未提供です。対応リージョンは順次拡大の予定です。