Amazon Web Services ブログ

Category: Storage

研究データ管理基盤での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 Athena および AWS Storage Gateway を使用して、オンプレミスで作成されたデータを照会する

 企業のお客様は、毎日データセンターで生成されるペタバイト規模のデータへのアクセスを維持、保護、提供する必要があります。従来、これには、未加工データをネットワークアタッチトストレージ (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 に入ります。

Read More

AWS Storage Gateway を使用して Amazon S3 に SQL Server バックアップを保存する

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 がその共有にアクセスできることを確認します。 ファイルゲートウェイをデプロイする 始めるには、オンプレミス環境でファイルゲートウェイを作成します。ファイルゲートウェイは、オンプレミスの […]

Read More

Amazon RDS または Amazon EC2 を使ってホストされているデータベースで実稼働ワークロードを実行するためのストレージのベストプラクティス

AWS は、OLTP ワークロードを処理するデータベースをホストするために複数のオプションを提供しており、Amazon EC2 インスタンスで独自のマネージドデータベースをホストする、または AWS が管理する Amazon RDS を使用することができます。RDS は、高可用性、自動バックアップ、データベースのアップグレード、OS パッチ、セキュリティ、およびリードレプリカを管理します。RDS は、クラウドネイティブのオプションである Amazon Aurora データベースエンジンも提供し、このエンジンは MySQL および PostgreSQL に対応しています。Aurora は、標準の MySQL と PostgreSQL データベースよりも優れたスループットを実現します。 Amazon RDS または Amazon EC2 を使ってホストされているデータベースで実稼働ワークロードを実行している時は、次のような疑問を思い浮かべたことがあるかもしれません。 最良のデータベースストレージタイプのオプションは何か? ストレージのパフォーマンス問題はどのように解決すればよいのか? EC2 インスタンスでホストされているデータベースに対する RAID 設定オプションには何があるのか? 最適なパフォーマンスのためのアプリケーション変更は何か? Amazon CloudWatch を使用してストレージパフォーマンスのトラブルシューティングを行うにはどうすればよいのか? Amazon RDS とAurora の運用パフォーマンスの違いは? この記事では Amazon RDS または EC2 インスタンスでホストされているデータベースで実稼働ワークロードを実行するためのストレージのベストプラクティスについて説明します。 テスト、QA、またはステージングの環境と比べて、実稼働ワークロードには高速で一貫した I/O パフォーマンスが必要です。リレーショナルデータベースは多目的に使用できますが、それらの最も一般的なユースケースはオンライントランザクション処理 (OLTP) […]

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 S3 path-style 廃止予定 – それから先の話 –

先週(4/30)、私たちは非常に静かな(実際には静かすぎる)発表を行いました。S3 バケット内のオブジェクトのアドレスを指定するために使用される、パスベースのアクセスモデルについて、ゆっくりとそして慎重に廃止するという計画です。私はこのブログ記事を書くために、状況をよりよく理解すべく、S3チームと話し合うことに時間を費やしました。私が学んだことは以下です… S3 は、2006年の始めにサービスが開始されました。S3 における Jeff Bezosの考える元々の仕様は、非常に簡素なものでした。彼はインターネットにおける malloc (C言語プログラムにおけるキーメモリ割り当て関数)に相当するようなものを望んでいました。その出発点から、S3 は何兆ものオブジェクトを格納し、毎秒数百万のリクエストを処理するところまでに成長しました。 13年間にわたり、S3 には多くの新しいストレージオプション、機能、およびセキュリティ制御が追加されました。 Old vs. New S3は現在、2種類のアドレスモデルを提供しています。path-style と virtual-hosted styleです。一つずつ見てみましょう。まず、path-style モデルでは、次のように見えます(グローバルなS3エンドポイントです): https://s3.amazonaws.com/jbarr-public/images/ritchie_and_thompson_pdp11.jpeg https://s3.amazonaws.com/jsb-public/classic_amazon_door_desk.png もしくは、次のような形です(リージョナルなS3エンドポイントです): https://s3-us-east-2.amazonaws.com/jbarr-public/images/ritchie_and_thompson_pdp11.jpeg https://s3-us-east-2.amazonaws.com/jsb-public/classic_amazon_door_desk.png この例では、jbarr-public と jsb-public がバケット名であり、/images/ritchie_and_thompson_pdp11.jpeg と /jsb-public/classic_amazon_door_desk.png がオブジェクトキーとなります。 仮に、オブジェクトが別々の AWS アカウントによって所有されたり、異なる S3 バケット(また場合によっては異なる AWS リージョン)にあったとしても、どちらも同じ DNS サブドメイン s3.amazonaws.com にあります。次に、対応する virtual-hosted style の参照方法を見てみましょう(これらは「新しい」と思われるかもしれませんが、少なくとも2010 年以降に存在しています): https://jbarr-public.s3.amazonaws.com/images/ritchie_and_thompson_pdp11.jpeg https://jsb-public.s3.amazonaws.com/classic_amazon_door_desk.png これらの URL は同じオブジェクトを参照しますが、オブジェクトは別々の DNS サブドメインにあります (それぞれ […]

Read More

[AWS Black Belt Online Seminar] Amazon FSx for Windows File Server/Lustre 資料及び QA 公開

先日 (2019/3/19) 開催しました AWS Black Belt Online Seminar「Amazon FSx for Windows File Server/Lustre」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 Amazon FSx for Lustre 20190319 AWS Black Belt Online Seminar Amazon FSx for Lustre from Amazon Web Services Japan Amazon FSx for Windows File Server 20190319 AWS Black Belt Online Seminar Amazon FSx for Windows Server from Amazon Web Services […]

Read More

[AWS Black Belt Online Seminar] Amazon EBS 資料及び QA 公開

先日 (2019/3/20) 開催しました AWS Black Belt Online Seminar「Amazon EBS」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190320 AWS Black Belt Online Seminar Amazon EBS from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. EBSスナップショットを取得した際のスナップショットのサイズを確認する手段を教えてください。 A. 現在のところ確認する手段はありません。 Q. DLMがEC2一時停止できる環境でおすすめな理由を教えてください。DLMはEC2停止が必須なのでしょうか。 A. DLMで取得されるEBSスナップショットの整合性レベルはクラッシュコンシステンシ−のレベルとなり、アプリケーションレベルでの整合性は保証されません。(メモリ上にまだ未コミットのデータがある場合は、その情報は保管されません)そのため、厳密なデータ整合性が必要な場合は、IOが発生しない状態での取得をお勧め致します。 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。 AWS Innovate オンラインカンファレンス ≫ 申込先 2019 年 4 月 8 日〜5 月 7 日期間中いつでもオンラインで視聴可能 AWS基礎、業種別事例、人材育成、認定対策講座などAWSが厳選した33セッションを一挙に公開 — AWS Black Belt […]

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