Category: Storage

アクティブなアプリケーションで、Amazon EC2 インスタンスの Amazon EBS ボリューム使用率がプロビジョニング済み容量に達してしまうことがあります。どのアプリケーションを使用しているかによって異なりますが、プロビジョニング済み容量が使い果たされると、アプリケーション停止のリスクが生じ、お客様に影響を与えることがあります。これに対するソリューションの 1 つに、アプリケーションへのフェールオーバーメカニズムの設計がありますが、オーケストレーションの負担になる可能性があります。より簡単なソリューションは、EBS ボリュームのサイズを自動的に変更することです。 Infor では、本番環境での数千に及ぶ EC2 インスタンス (Windows と Linux) を管理しています。当社はこうした停止を防ぐ予防的アプローチが必要であったため、特定のしきい値に達したときボリュームが自動的に増加するように、本投稿で説明するソリューションを開発しました。このアプローチには 2 つの利点があります。 異常が発生し、ボリュームのスペースが非常に少なくなると、プロビジョニング済み容量が枯渇する前に自動的にボリュームを拡張します。このアクションにより、根本原因を調査し解決するまで、問題に対処できます。 そのため、ボリュームを過剰にプロビジョニングする必要がなくなりました。このソリューションは、より多くのスペースが必要になると、徐々に自動的にボリューム容量を増やし、EBS コストを削減します。 この投稿では、Infor で開発した自動 EBS ボリュームサイズ変更プロセスを順を追って説明します。さらに、そのアーキテクチャを確認し、ベストプラクティスをいくつか学びます。 概要 AWS は Amazon EBS Elastic Volumes を 2017 年に発表しました。この機能では、ダウンタイムなしでシンプルな API 呼び出しで、ボリュームのサイズを増やしたり、パフォーマンスを調整したり、ボリュームタイプをその場で変更したりできます。 ボリュームの変更は比較的簡単ですが、ファイルシステムを拡張して、追加のストレージを活用しようとすると一筋縄ではいきません。これは通常、OS 上で手動で行いますが、AWS Systems Manager がインスタンスを管理している場合には、AWS Lambda を使用して OS レベルのスクリプトを実行する Systems Manager コマンドを送信できます。 次のリストは、このワークフローの手順を示しています。 ボリュームが 80％ に達することをモニタリングし、自動化をトリガーします。 特定のシステムが除外されたため、続行する前に一連のチェックを実行します。フリートの […]

 Amazon Elastic File System (Amazon EFS) が AWS GovCloud (米国) で FedRAMP High 暫定承認を達成したことをお知らせできるのは大変な喜びです。この成果により、米国政府機関は、個人識別情報 (PII)、機密患者記録、財務データ、法執行データ、およびその他の管理すべき重要情報 (CUI) を含む機密ファイルを Amazon EFS に簡単かつコスト効率よく保存できるようになりました。 ストレージブログで前に述べたように、数万のお客様が Amazon EFS が提供するシンプルさ、拡張性、費用対効果の恩恵をすでに受けています。昨年後半に AWS GovCloud (米国) で EFS が開始され、FedRAMP High 認定を受けた政府機関のお客様向けに、機密性の高いミッションクリティカルなワークロードのブロックを正式に解除できることを誇りに思います。AWS GovCloud (米国) の FedRAMP High ベースラインの詳細については、こちらをご覧ください。 お客様はさまざまなユースケースで EFS を使用していますが、この機会に、政府機関のお客様とその規制対象アプリケーションに見られるメリットを考えて、2 つの特定の機能を強調したいと考えています。何よりもまず、EFS ライフサイクル管理を使用して、使用頻度の低いデータを EFS 低頻度アクセスストレージクラス (EFS IA) に透過的に移動することにより、アクセスパターンの変化に応じて自動的に費用を節約できます。EFS を使用すると、政府機関のお客様は、アプリケーションを変更することなく、ワークロードをリフトアンドシフトするだけで、クラウドで簡単に開始できます。ライフサイクル管理を有効にすると、時間の経過とともにファイルへのアクセスが自然に少なくなるので、自動的にお金を節約できますが、引き続き同じファイルシステムのネームスペースでアクティブに使用されるデータとともに完全にアクセス可能のままになります。また、クラウドへの移行およびデータの Amazon EFS への読み込みを迅速かつ簡単に強化するために、AWS DataSync もお勧めします。 […]

AWS のお客様は 10 年以上にわたり、SQL Server などのミッションクリティカルな Windows を実行しています。この投稿では、Amazon EBS ストレージを使用して SQL Server のパフォーマンスを最大化する方法について説明します。 永続ブロックストレージはリレーショナルデータベース管理システム (RDBMS) の重要なコンポーネントであり、重要なデータの速度、セキュリティ、耐久性の最終的な責任を担います。AWS は SQL Server のニーズに合わせて、EBS を通じて、高性能で使いやすいブロックストレージを提供しています。 この投稿は、SQL Server データベースアーキテクト、管理者、および開発者に関連した内容です。AWS プラットフォームでの最適なストレージ構成の概要を説明しています。現在 AWS を使用している、またはオンプレミスのワークロードをクラウドに移行しようとしているのであれば、EBS についてのより詳しい情報と基本的な理解を得ることができます。 Amazon EBS の概要 EBS はすべての AWS リージョンで利用可能な、高性能のブロックストレージサービスです。EBS を使用すると、わずか数回のクリックで SQL Server インスタンスにボリュームを作成し接続が可能です。ホストバスアダプター (HBA)、スイッチ、ネットワーク帯域幅、ディスクキャッシュ、コントローラー、ストレージエリアネットワークなどを構成する必要がなくなります。 EBS ボリュームは専用ストレージネットワークを使用してインスタンスに接続し、高速で信頼性の高いボリュームを柔軟にプロビジョニングするため、SQL Server の重要なワークロードにも対応できます。 EBS ボリュームは伸縮自在です。ワークロードを中断することなく、次のような変更を実行できます。 ボリュームサイズを最大 16 TiB まで増やす。 最大 64,000 IOPS までボリュームパフォーマンスを改善する。 SSD […]

数万社におよぶ企業がペタバイト規模のデータを Amazon Elastic File System (Amazon EFS) に保存しており、その多くが EFS を使ってコンテナ化したアプリケーションのデータです。Amazon EFS ファイルシステムは、Amazon Elastic Container Service (ECS) と Elastic Kubernetes Service (EKS) の両方で起動したコンテナに接続できます。Amazon EFS はコンテナインフラストラクチャと同様に、データの追加や削除の際に設定が簡単でかつ柔軟なスケーリングが可能な完全マネージド型のサービスであるため、コンテナストレージにうってつけの選択肢です。さらに、ペタバイト級のデータだけでなく、1 秒あたりのギガバイトの総スループットや数千の IOPS にも拡張が可能です。このブログでは、コンテナ化したアプリケーションで EFS を使用するためのベストプラクティスに関する、よくある質問をいくつかご紹介します。 コンテナには共有ストレージが必要ですか? 一般に、共有ファイルストレージは、障害に対する回復力が必要な長期にわたって実行するコンテナや、データを相互に共有する必要があるコンテナに適しています。よく目にする例をいくつか挙げましょう。 WordPress や Drupal などのコンテンツ管理アプリケーションは、パフォーマンスと冗長性を確保するために複数のインスタンスにスケールアウトしたり、複数のインスタンス間でアップロード、プラグイン、テンプレートを共有することで利点を享受します。 JIRA、Artifactory、Git などの開発者ツールでは高可用性を実現するためインスタンス間でデータを共有します。これは、永続性のために複数の AWS アベイラビリティゾーンに保持されているコードとアーティファクトを使って行われます。 MXNet や Tensorflow のような機械学習フレームワークは、ファイルシステムインターフェイスを介してデータにアクセスする必要があります。永続的な共有ストレージを使用すると、複数のユーザーとジョブを同じデータセットで並行して実行できます。 Jupyter や Jupyterhub などの共有ノートブックシステムには、ノートブックやユーザーワークスペース用の耐久性のあるストレージが必要です。共有ストレージを使用すれば、データサイエンティストの間で簡単に共同作業が行うことができます。 コンテナデータを永続化する別のオプションとしては、Amazon Elastic Block Storage (EBS) があります。これは MySQL、あるいは Kafka […]

 本日、Amazon Elastic File System の低頻度アクセス (IA) のライフサイクル管理を使用した AWS クラウド史上最大の値下げが発表されました。今回の値下げにより、コストをこれまで以上に最適化し、ユーザーのアクセスパターンの変化に応じてファイルストレージコストを最大で 92% まで自動的に削減できるようになります。この値下げにより、月額 GB あたり 0.08 USD の料金で、ファイルをファイルシステムにネイティブに保存し、アクセスできるようになります。詳細は本記事の後半で紹介します。 Amazon Elastic File System (EFS) は、Linux ベースのワークロード用向けの低コストで使いやすいクラウドネイティブなフルマネージド型 NFS ファイルシステムで、AWS のサービスやオンプレミスのリソースでも使用できます。EFS は、ファイルを作成または削除するたびにペタバイト規模まで自動的に拡大または縮小する伸縮自在なストレージを提供します。中断は発生しません。アプリケーションは、必要とするストレージをいつでもすぐに使用できます。さらに EFS には、追加設定の不要なマルチ AZ アベイラビリティーと耐久性が (無償で) 含まれ、ファイルシステムの堅牢な整合性とともに利用できます。 ライフサイクル管理を使ってコストを簡単に最適化 特定のアプリケーションでは、ストレージが増加すると、すべてのファイルに常時アクセスする必要がなくなり、アクセスパターンも時間を経て変わっていきます。 IDC のような業界の専門家の分析や、使用パターンに関する当社独自の分析から、データの約 80% はアクセス頻度が低いことが確認されています。アクティブに使用されているのは残りの 20% です。アプリケーションをクラウドへ移行する際の一般的な 2 つの要因として、運用効率の最大化と総所有コストの削減が挙げられます。このことはストレージのコストにも同じことが言えます。すべてのデータを手元で実行速度が最速のストレージに保存するよりも、アクセス頻度の低いデータは異なるクラス/ティアのストレージに移行させて、関連コストを低減して利用するほうが合理的です。 こうしたデータを手動で探すのは面倒な作業です。したがって、アクセスを経時的にモニタリングし、ストレージティア間のデータ移動を自動的に実行するシステムがあればなお理想的です。繰り返しになりますが、実行中のアプリケーションで中断が発生することはありません。 EFS 低頻度アクセス (IA) のライフサイクル管理は、定期アクセスの不要なファイル向けに、使いやすい、コスト最適化された料金/パフォーマンスティアを提供します。本日発表された新たな値下げにより、ビルダーはファイルストレージのコストを EFS 標準ストレージクラスと比べて最大 92% まで削減できるようになります。 EFS ライフサイクル管理は、簡単に有効化でき、バックグラウンドで自動的に実行します。ファイルシステムで有効化すると、選択したライフサイクルポリシーに従わないファイルは、コスト最適化された EFS IA ストレージクラスに自動的に移動します。この移動は、アプリケーションに対して透過的に行われます。 […]

先月投稿した記事において、当社の Amazon Elastic File System (Amazon EFS) の低頻度アクセスストレージクラス (EFS IA) が、数万社におよぶお客様によりいかに活用されているかをお伝えしました。完全マネージド型で、高い可用性と耐久性を持ち伸縮自在なクラウドシステムは、簡単でコスト効率が高く、ネイティブのようにファイル保存が行えます。 当社の AWS News ブログでは、Amazon EFS がさらに訴求力を高めたことも発表しています。EFS IA でのストレージ料金が 44%* 値下げされており、これは、AWS が現在までに行った値下げの中で、最も大きな値下げ率を適用した 1 つとなっています。 先月の記事で取り上げている業界でも浸透した 80/20 ルールを採用し、この Amazon EFS の新料金体系では、クラウドファイルシステムへのペタバイト級データの保存が、たったの 0.08 USD/GB – 月* という費用対効果の高い料金で行えます。この低価格設定により、EFS のお客様は大規模ファイルの保存とアクセスを行いながら、EFS がご提供するすべてのメリットを享受することが可能です。データのうちどれが頻繁に使用され、アクセス頻度の低いデータはどれかなどを気にすることなく、パフォーマンスと低コスト化の両面で役立てていただけるのです。 *料金は米国東部 (バージニア北部) リージョンでのものです。その他のリージョンでの料金については、 「Amazon EFS の料金」 をご参照ください。 Amazon EFS 導入の成功例 すでに多くのお客様が、EFS 低頻度アクセスストレージクラスを利用することで、クラウドのファイル保存に要する年間のコストを数十万ドルも削減しています。EFS IA を利用開始するのは非常に簡単で、ただ、EFS コンソールでの数回クリックにより、自分のファイルシステムのための EFS ライフサイクルの管理を有効化するだけです。EFS ライフサイクルの管理が有効化されると、EFS がファイルへのアクセスパターンを認識し、お客様が選択されたポリシーにしたがい、アクセス頻度の低いファイルを自動的に低コストストレージクラスへと移動します。EFS […]

分析アプリケーションと機械学習モデルをデプロイするには、容量とパフォーマンスをスケールインできるストレージが必要であり、高スループットと低レイテンシーのファイル操作でワークロードの需要に対応できます。 一般的なユースケースでは、データサイエンスチームが何らかの分析 (機械学習、ゲノミクスなど) を行うことを軸としています。AWS は、ビッグデータおよび分析ワークロード向けに、スケーラブルで耐久性のある可用性の高い2つのファイルソリューションを提供しています。Amazon EFS は、ML フレームワークや共有ノートブックシステム、そして Linux ベースのアプリケーションのためのクラウドネイティブの共有 NFS ストレージソリューションです。Faculty などの顧客は、分析ワークロードをスケーリングするために EFS を活用し、配信インサイトに対する俊敏性を向上させています。 Amazon FSx for Lustre は、データへのサブミリ秒アクセスを提供する Amazon S3 またはオンプレミスのデータを処理するための高性能ファイルシステムであり、最大で 1 秒あたり数百ギガバイトのスループットと数百万 IOPS の速度でデータを読み書きできます。Amazon FSx for Lustre は Amazon S3 とネイティブに連携し、コンピューティング集約型のファイルシステムでクラウドデータセットを簡単に処理することができます。Conductor Technologies は、クラウドレンダリングプラットフォームに FSx Lustre を用いることにより、TCO を削減しつつ、VFX およびアニメーションスタジオの顧客に簡素化とスケールをもたらします。 今週、AWS SageMaker チームは、EFS と FSx for Lustre の両方からデータにアクセスして意思決定を通知し、カスタマーエクスペリエンスを向上させることにより、顧客が機械学習のトレーニングジョブをスピードアップできるようになったことを発表しました。 機械学習ワークロードのための AWS ファイルストレージソリューションの詳細は、ブログ記事をご覧ください。

学術研究機関においては研究不正対策なども含め、研究データや関連資料の長期保存が必要となってきています。日本学術会議から公開された文章においても論文の実験データ等の資料は原則論文発表後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 […]

 企業のお客様は、毎日データセンターで生成されるペタバイト規模のデータへのアクセスを維持、保護、提供する必要があります。従来、これには、未加工データをネットワークアタッチトストレージ (NAS)、ストレージエリアネットワーク (SAN)、またはダイレクトアタッチトストレージ (DAS) に保存し、それを変換してリレーショナルデータベースにロードして照会および分析活動をサポートする、一連の複雑な相互関連システムが含まれます。これは、一般に抽出、変換、ロードまたは ETL として知られています。 これらのシステムはそれぞれ、別々のチームによって別々に維持する必要があります。データベースは DBA によって、基盤となる物理インフラストラクチャはシステムエンジニアによって、などです。AWS では、常にお客様のために「Invent and Simplify」の方法を模索しています。この記事では、オンプレミスで生成された重要なデータを照会するプロセスを簡素化するための、お客様のデータセンターにデプロイできる AWS テクノロジ (AWS Storage Gateway) とサーバーレスのクラウドネイティブテクノロジ (Amazon Athena) の組み合わせた使用について説明します。 Tableau などの一般的なエンタープライズ分析ツールを使用してデータを分析するお客様は、ODBC または JDBC を使用してデータに接続し、データに対してクエリを実行しています。逆に、ファイルシステムはファイルの読み書きに SMB や NFS などのプロトコルを使用します。これまで、データを分析できるようにするためには、データを未加工の形式 (多くの場合はテキストファイル) からリレーショナルデータベースに変換する必要がありました。AWS Storage Gateway および Amazon Athena に入ります。

Alkami や Acadian Asset Management などのお客様は、AWS Storage Gateway を使用して Microsoft SQL Server データベースを直接 Amazon S3 にバックアップし、オンプレミスのストレージ占有領域を削減し、耐久性、拡張性、および費用対効果の高いストレージとして S3 を活用しています。 Storage Gateway は、オンプレミスアプリケーションに対して、実質的に無制限のクラウドストレージへのアクセスを提供する、ハイブリッドなクラウドストレージサービスです。このサービスは、ストレージ管理を簡素化し、3 つの主な使用例でコストを削減します。 クラウドへのバックアップ移動 クラウドベースのファイル共有によるオンプレミスストレージの削減 オンプレミスアプリケーション用に AWS 内のデータへのアクセスを低レイテンシーで提供 この記事では、Storage Gateway のファイルゲートウェイ設定を使用してバックアップをクラウドに移動する 1 つの方法を説明します。 概要 次の手順を使用してファイルゲートウェイをデプロイし、SQL Server のバックアップターゲットとしてファイル共有を作成して、S3 にバックアップを保存します。 オンプレミス環境にファイルゲートウェイをデプロイします。 ファイル共有認証でドメインユーザーとグループを使用できるように、ファイルゲートウェイを Microsoft Active Directory ドメインに接続します。 ファイルゲートウェイに SMB ファイル共有を作成し、その共有を S3 バケットに関連付けます。Active Directory ドメインを使用して共有へのオンプレミスアクセスを設定します。 共有をマウントしてクイックバックアップを作成し、SQL Server がその共有にアクセスできることを確認します。 ファイルゲートウェイをデプロイする 始めるには、オンプレミス環境でファイルゲートウェイを作成します。ファイルゲートウェイは、オンプレミスの […]