Amazon Web Services ブログ

Category: Amazon Simple Storage Services (S3)

SAP on AWS: 2020年振返り

はじめに 2020年を振り返ると、どれだけ信じがたい出来事が起きたかということを認めなくてはなりません。全世界的にCOVID-19やその他の世界の出来事によって私たちの生活様式が変化し、多くの人々にとって困難なものとなりました。このパンデミックにより、企業は顧客や従業員のニーズを満たすために、ほぼ即座に運用上の変更を余儀なくされました。また、多くの企業がクラウドサービスの利用を始めました。 この数週間にわたり、毎年恒例のre:Inventカンファレンスの一環として、私たちは多くのお客様からの声を聞く機会がありました。その数社はSAPトランスフォーメーションのストーリーを世界へ共有するためのバーチャルステージを行いました。:

Read More

新機能 – Amazon S3 Replication が複数の宛先バケットのサポートを開始しました

Amazon Simple Storage Service (S3) は、2019 年にローンチされた S3 Same-Region Replication (SRR)、および 2015 年から利用され続けている S3 Cross-Region Replication (CRR) などの数多くのレプリケーションタイプをサポートします。本日、AWS は複数の宛先バケットに対する S3 Replication のサポートを発表します。これにより、S3 Replication は、1 つのソースバケットから複数の宛先バケットにデータをレプリケートできるようになりました。S3 Replication (複数宛先) を使用すると、同じ AWS リージョン内のデータの場合は S3 SRR、異なる AWS リージョンにまたがるデータの場合は S3 CRR を使用してデータをレプリケートでき、これらの組み合わせを使用することもできます。 このローンチまでは、異なる S3 バケットにあるデータの複数のコピーを作成する必要がある場合、S3 イベントを監視し、作成されたオブジェクトを識別して、各宛先バケットにオブジェクトをコピーするための AWS Lambda 関数を使用することによって、独自の S3 Replication サービスを構築しなければなりませんでした。 このローンチによって、複数の宛先全体へのデータのレプリケーションに独自のソリューションを開発する必要がなくなります。S3 Replication (複数宛先) の柔軟性は、用途に応じて異なるストレージクラス、異なる暗号化タイプ、または異なるアカウント全体でデータの複数のコピーを保存するために利用できます。さらに、複数の宛先にレプリケートするときは、CloudWatch メトリクスを使用して各リージョンペアのレプリケーションの進行状況を追跡できます。 S3 Replication (複数宛先) […]

Read More

Amazon S3 アップデート – 強力な書き込み後の読み取り整合性

2006 年に S3 をローンチした当時、私はその事実上無制限の容量 (「あらゆる数のブロックを簡単に保存…」)、99.99% の可用性を実現するように設計されており、データが複数の場所に透過的に保存される耐久性に優れたストレージを提供するという事実について説明しました。このローンチ以来、AWS のお客様は、バックアップと復元、データアーカイブ、エンタープライズアプリケーション、ウェブサイト、ビッグデータ、そして最終集計で 10,000 個を超えたデータレイクといった、驚くほど多様な方法で S3 を使用しておられます。 S3、およびその他の大規模な分散システムの興味深い (時には分かりにくいこともある) 側面のひとつに、一般に結果整合性として知られているものがあります。要するに、PUT などのデータを格納または変更する S3 API 関数を呼び出した後には、データが受け入れられ、永続的に保存されたものの、まだどの GET または LIST リクエストも参照できない短い期間があるということです。これは、以下の図のようになります。 S3 のこの側面は、書き込み直後に最新のデータにアクセスする必要があるビッグデータワークロード (そのほとんどが Amazon EMR を使用) とデータレイクにとって極めて困難なものになり得ます。お客様がクラウドでビッグデータワークロードを実行できるようにするため、Amazon EMR は EMRFS Consistent View、およびオープンソースの Hadoop デベロッパーは S3Guard を構築して、これらのアプリケーションに強力な整合性レイヤーを提供しました。 S3 の整合性が強力になりました 前置きが長くなってしまいましたが、良いニュースをいくつかお知らせしたいと思います! 本日から、S3 の GET、PUT、LIST 操作のすべて、およびオブジェクトタグ、ACL、またはメタデータを変更する操作に強力な整合性が適用されます。書き込む内容をすぐさま読み取ることができるようになり、LIST の結果はバケットの内容を正確に反映するようになります。これは、既存および新規の S3 オブジェクトすべてに適用され、全リージョンで機能し、追加料金なしでご利用いただけます! パフォーマンスへの影響はなく、必要に応じてオブジェクトを毎秒何百回でも更新でき、グローバルな依存関係はありません。 この改善はデータレイクにとってすばらしいメリットですが、他のアプリケーションタイプにもメリットがあります。強力な整合性を備えた S3 により、オンプレミスワークロードの移行と AWS へのストレージもこれまで以上に容易になります。 私たちは、お客様がそれぞれのビッグデータワークロードでこの更新を活用できることを確実にするため、Amazon […]

Read More

Mistplay: Amazon S3 と Amazon Athena を使ったビジネス分析の改善

本記事は Mistplay のAI エンジニアであるSteven Wang氏によるゲスト投稿です。 Mistplay はモバイルゲーマー向けの世界トップクラスのロイヤルティプログラムです。数百万人のプレイヤーが Mistplay を使用して新しいゲームを発見し、ロイヤルティ報酬を獲得し、他のプレイヤーとつながっています。このプラットフォームにより、Playtika、Scopely、Peak などのモバイルゲームスタジオは、世界中のユーザーを獲得し、それらのユーザーと深く関わることができています。   Mistplay が AWS に移行した理由 Mistplay では十分な情報に基づいた意思決定を行い、計算されたリスクを取るにあたり、データに大きく依存しています。  Mistplay の Android アプリケーションは、ユーザーのインタラクションをキャプチャする大量のイベント情報を生成するため、チームにとって不可欠なデータソースとなっています。このデータは不可欠であり、ビジネス上の主要な疑問に答え、当社が可能な限り最高のユーザーエクスペリエンスを作る上で重要な役割を果たしています。 従来、Android アプリケーションは Firebase にイベントデータを送信するように設計されていました。そこから、デフォルトで利用可能な統合機能を使ってFirebase と BigQuery を統合し、 BigQuery でイベントデータを公開し、詳細に分析していました。 しかし当社のビジネスが成長するにつれ、既存のソリューションでは対処できないいくつかの課題に直面しました。たとえば、品質上・精度上の問題が増加し、処理データに影響を与えていることに気付きました。さらに、インフラストラクチャに対するコストが当社のビジネスと同じくらい急速に増加していました。料金モデルは理解しにくく、当社の使用パターンだと予想外に高額な請求が発生することがよくありました。 当社のデータが新しいホームを必要としていることは明らかでした。当社のイベント分析を AWS に移行することは自然な選択でした。当社では既に Amazon S3 と Amazon Athena を主要なデータレイクとして使用していたためです。  さらに、ツール類を1つのサービスセットで統合し、分析タスクを合理化し、AWS の下で既に実施されている既存のセキュリティ対策を活用したいと考えていました。最後に、AWS の明瞭な料金モデルのおかげで、予算作成が簡単に行えました。 本投稿では、Firebase と BigQuery から Amazon S3 および Amazon Athena に移行した方法と、分析機能、コスト構造、およびオペレーションがどのように改善されたかを説明します。   移行戦略 […]

Read More

サーバーレス LAMP スタック – Part 4: サーバーレス Laravel アプリの構築

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え パート5:CDK コンストラクトライブラリ パート6:MVC からサーバーレスマイクロサービスへ この投稿では、サーバーレスアプローチで Laravel アプリケーションをデプロイする方法を学びます。 これは「サーバーレス LAMP スタック」シリーズの4番目の投稿になります。過去の投稿はこちらです。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え Laravel は PHP 用のオープンソースの Web アプリケーションフレームワークです。フレームワークを使用すると、開発者は一般的なコンポーネントとモジュールを再利用することで、より速く構築できます。また、開発標準に準拠することにより、長期的なメンテナンスにも役立ちます。ただし、従来の LAMP スタックを使用して PHP フレームワークをスケーリングする場合は、まだ課題があります。サーバーレスアプローチを使用してフレームワークをデプロイすると、これらの課題の解決に役立ちます。 Laravel アプリケーションのサーバーレスインフラストラクチャへの展開を簡素化する方法は数多くあります。ここで紹介する方法では、AWSサーバーレスアプリケーションモデル(AWS SAM)テンプレートを使用しています。これによって、Laravel アプリケーションが単一の Lambda 関数にデプロイされます。この関数は、Bref FPM カスタムランタイムレイヤーを使用して PHP を実行します。AWS SAMテンプレートは、「サーバーレス LAMP スタック – パート3: […]

Read More

ご利用のポストプロダクションアプリケーションをAWS仮想デスクトップ インフラストラクチャにデプロイするために

今や仮想化は、クリエイティブな専門家が在宅勤務で仕事をする上で必要な環境となりました。本ブログでは、AWSクラウド上でポストプロダクションアプリケーションを実行する場合に重要な考慮事項を説明します。 お客様から「編集ソフトウェアをAWSで実行できるか」というお問い合わせが頻繁にあります。これらの問い合わせから使用パターンを、典型的なユースケースまたはユーザー想定モデルと呼ばれる形式で説明できます。最も一般的な想定モデルには、ニュース/スポーツ、クリエイティブ、プロモ―ションがあります。想定モデルを識別する目的は、一般的なユースケースの周囲に十分な柔軟性を提供して、ロングフォームおよびショートフォームのプロダクション、コンフォーム編集、マニュアルの品質管理など、さまざまな追加のユースケースに簡単に適用できるようにすることです。想定モデルには、ストレージ、ネットワーク帯域幅、ディスクI / O、CPU、メモリの点で異なる要求があります。もちろん、クラウドでは、カラーグレーディング、カラーフィデリティ(色再現)、マルチチャンネル オーディオ サポートなど、いくつかのワークフローで課題がまだあります。しかし、仮想デスクトップインフラストラクチャ(VDI)プロトコルが進化して、10ビットカラーやより多くのオーディオチャネルなどの機能をサポートするようになると、これらのワークフローを実現することができます。AWSは、将来の機能改善に対応できるように柔軟性を考慮してテンプレートを設計しました。 クリエイティブプロフェッショナル向けクラウドベースワークフローにおける重要な考慮事項 ネットワーク遅延を最小化するとワークステーションのインタラクティブ性が上がり、物理的にAWSリージョンに近いほどユーザーエクスペリエンスが向上することはこの領域では特に重要です。さらに、ロサンゼルスなどの場所には専用の AWS Local Zonesがあり、AWSのコンピューティング、ストレージ、データベース、その他の選択されたサービスを大規模な人口、産業、ITセンターの近くに配置することでレイテンシーを削減します。最後に、制作施設、スタジオ、クリエイティブオフィスで運用する場合、AWS Direct Connect 専用帯域を強化するだけでなく、パブリックインターネットパスを抽象化するセキュリティの層を追加します。デプロイメントの場所またはリージョンを選択する場合、目標レイテンシーが約30ミリ秒以下であれば、最適なエクスペリエンスが提供されます。レイテンシーが長くなると、ジョグ/シャトル操作などの周辺機器のインタラクティブ性、または一般的な再生やGUIアクティビティに遅れが生じる可能性があります。 AWSの利点 クリエイティブワークフローをAWSに移行するには多くの利点があります。その1つは、容量に厳密な計画を立てることなく、需要に基づいてシステムを拡張できることです。コンピューティング、ストレージ、ネットワーキング、その他のAWSサービスはすべて従量課金制ですので、ストレージを拡張したり、多数のワークステーションを調達するために多額の設備投資を計画する必要がなくなります。ワークステーションのアップグレード、パッチ適用、およびイメージングも簡単で、AWS System Mangerを介して自動化できます。インフラストラクチャを一元的に配置して保護できるため、全ユーザーにコンテンツを転送するという、時間とコストのかかるモデルではなく、リソースとアセットのシングルプールを使用して、クリエイティブユーザーがコラボレーションできます。さらに、AWSは現在、グローバルな分散型なワークフローの運用を実現するため、23の地理的リージョン内の73のアベイラビリティーゾーンにまたがっており、これによってインフラストラクチャをローカルで確保している人材の近くに配置できます。例として、動的インフラストラクチャとAWSテクノロジーを採用すると、ワールドカップサッカーなどのライブイベントで、リモート編集やハイライト制作が可能になります。これらの利点を活用してクリエイティブワークフローを最適化すると、コストが削減され、セキュリティとストレージの要件が一元化、時間のかかるデータと人員の移動が排除され、クリエイティブワークフローの市場投入までの時間が短縮されます。 セキュリティ AWSは、ワークステーションとコンテンツへのアクセスを安全に制御、監視、監査するためのきめ細かなアクセスを提供します。AWSのセキュリティは最優先事項であり、AWS Artifactを通じてインフラストラクチャとコンテンツを保護するための多くのリソースを見つけることができます、コンプライアンス関連情報の中心的なリソースであり、AWSマネジメントコンソールから利用できます。Artifactは、アセット管理やクラウドレンダリングなどのユースケースを中心に、AWSで安全でエンドツーエンドの本番環境対応システムを構築する方法を示す詳細な導入ガイドを提供します。より詳細な観点から見ると、監査可能性と追跡可能性はクラウドベースの編集ワークフローを構築する際に考慮すべき重要な要素です。AWSでは、仮想編集ステーションの管理のセキュリティ負担を軽減するサービスを提供しています。AWS CloudTrail、Amazon GuardDuty、Amazon Simple Storage Service(Amazon S3)サーバーアクセスログなどのサービスを使用して、インフラストラクチャを完全に監査できます。さらに、AWS Security Hubサービス全体のセキュリティ状況の包括的かつ集約されたビューを提供します。高価値なアセットとコンテンツに関しては、Amazon Elastic Block Store(Amazon EBS)やAmazon S3などのサービス全体で、保管時および転送時に暗号化を提供できます。AWS Key Management Service (KMS)を使用すれば、顧客管理とサービス管理の両方のコンテンツ暗号化とキー管理できます。 最後に、そして最も重要なこととして、編集ステーションの表示プロトコルは適切なレベルのセキュリティを採用する必要があります。 TeradiciのPCoIPディスプレイプロトコルは、FIPS 140-2レベルで常時オンのAES256暗号化を提供し、クライアントにストリーミングするデータを安全に保ちます。さらに高いレベルのセキュリティが必要な場合は、低遅延用に最適化されたソリューションといった、AWSまたはパートナーのさまざまなVPNソリューションでディスプレイプロトコルを保護できます。 AWS G4 GPUとTeradiciのPCoIPプロトコルおよびAmazon Elastic Compute Cloud(Amazon EC2)上のクラウドアクセスソフトウェアを使用することで、デスクトップを自宅またはオフィスにストリーミングできます。TeradiciのPCoIPプロトコルには、Mac、Windows、およびLinuxシステムのゼロまたはシンクライアント(ハードウェア専用アプライアンス、HP、10ZiGおよびその他のパートナーから入手可能)またはソフトウェアクライアントで実行するオプションがあり、クリエイティブユーザーは、選択したローカルオペレーティングシステムに関係なく同じ編集エクスペリエンスを楽しむことができます。VDIワークステーションとプロトコルの将来を見据えた進化と同様に、AWSには、最適化されたビットレートと4K/UHDをサポートする「PCoIP Ultra」という、Teradiciの新しい拡張プロトコルに適応できるソリューションテンプレートがあります。 マルチモニター編集ワークフローでは、より強力なマルチGPU G4ファミリーインスタンスで最大4台のモニターを使用でき、個別のプレビュー、タイムライン、およびアセット管理モニターを使用して、オンプレミスとほぼ同じエクスペリエンスを提供します。Teradiciは、USBパススルー経由でWacomタブレットなどの一般的なUSB HIDベースの周辺機器もサポートしています。互換性のあるデバイスをローカルに接続するだけで、リモートワークステーションですぐに使用できます。これとその他の一般的なTeradiciのデプロイおよび操作関連の質問の詳細については、コンテンツ作成用AWSワークステーションガイドを参照してください。 アーキテクチャ アーキテクチャについて考えるときは、ワークフローを考慮することが重要です。メディア アセット マネージメント ソリューションの中には、クラウドでこのワークフローをサポートし、Adobe […]

Read More

Amazon S3 への Amazon RDS Snapshot Export によるデータレイクの構築とデータ保持ポリシーの実装

 Amazon Relational Database Service (RDS) は、クラウドでリレーショナルデータベースを簡単に作成、運用、およびスケールするために役立ちます。2020 年 1 月、AWS は Amazon RDS for MySQL、Amazon RDS for PostgreSQL、Amazon RDS for MariaDB、Amazon Aurora PostgreSQL、および Amazon Aurora MySQL からのスナップショットを Apache Parquet 形式で Amazon S3 にエクスポートする機能を発表しました。これで、主要なトランザクションアプリケーションに影響を及ぼすことなく、ダウンストリームのレポート作成および分析アプリケーションが本番データベースからのデータを利用できるようになります。 データベース管理者とデータ所有者は、ビジネスインテリジェンスレポートの作成者、機械学習開発者、またはエンタープライズダッシュボード作成者から、データベーステーブルへのアクセス提供のリクエストを絶えず受け取っています。ここでの課題は、データ上で動作するビジネスクリティカルなアプリケーションに影響を及ぼさない方法でデータにアクセスできるようにすることです。リードレプリカを作成することもソリューションのひとつですが、ダウンストリームアプリケーションリクエストに対応するためにプロビジョニングされたコンピューティング性能を維持しなければなりません。 さらに厄介なことに、レポート作成システムには以前のタイムスタンプ時点でのデータのコピーを必要とするものもあります。これまでは、スナップショットから復元することで新しい RDS インスタンスを作成し、レポート作成システムがこの新しいインスタンスにアクセスできるようにすることが、これを実行する唯一の方法でしたが、 Amazon S3 への Amazon RDS Snapshot Export のローンチにより、リクエストされたテーブルを適切なスナップショットから S3 バケットにエクスポートするプロセスを作成し、ダウンストリームアプリケーションに Parquet ファイルへのアクセスを提供するだけで実行できるようになりました。 この記事では、Amazon RDS のスナップショットから Amazon S3 にエクスポートファイル […]

Read More

クラウドにおける安全なデータの廃棄

クラウドにおける統制をお客様が考慮する場合、基本的な考え方は大きく異なるものではありません。ただし、クラウドならではの統制を考慮すべきケースがあることも事実です。その際には、従来のオンプレミスのやり方を無理にクラウドに当てはめようとしてもうまくは行きません。大事なことはその統制が何を目的としていたのかに立ち返り、その上で、New normal(新しい常識)にあった考え方や実装をすすめる必要性を理解し、実践することです。この投稿では、メディアやデータの廃棄を例として、セキュリティのNew normalを考えていきます。 メディア廃棄における環境の変化 データのライフサイクルに応じた情報資産の管理は多くのお客様の関心事項です。 オンプレミスの統制との変更という観点では、メディア廃棄時の統制は従来のオンプレミス環境とクラウド環境では異なります。オンプレミス環境の利用者はハードウェアの消磁や破砕などを実行することでデータの保全を実行してきました。また、メディア廃棄をサードーパーティに委託し、その廃棄証明の提出をもって“確実な廃棄の証跡”として管理しているケースもありました。 AWSの環境ではセキュリティ責任共有モデルに基づき、クラウドのインフラストラクチャの管理はAWSの統制となるため、お客様はその統制が実施されるていることを評価していく必要があります。お客様はAWSが管理するハードウェアデバイスに物理的にアクセスすることはできないため、従来であれば自組織、場合によってはサードパーティに委託していたメディアの廃棄を自組織の統制範囲として行うことはありません。また、仮想環境のストレージは物理的なハードウェアと異なり、特定の利用者が占有しているとは限らないため、廃棄時に利用者に紐付けた管理や通知を行うことは現実的ではありません。 AWSにおけるメディアの廃棄 AWS データセンターは、セキュリティを念頭に置いて設計されており、統制により具体的なセキュリティが実現されています。ユーザーデータの保存に使用されるメディアストレージデバイスは AWS によって「クリティカル」と分類され、そのライフサイクルを通じて非常に重要な要素として適切に取り扱われます。AWS では、デバイスの設置、修理、および破棄 (最終的に不要になった場合) の方法について厳格な基準が設けられています。ストレージデバイスが製品寿命に達した場合、NIST 800-88 に詳細が説明されている方法を使用してメディアを廃棄します。ユーザーデータを保存したメディアは、安全に停止するまで AWS の統制から除外されることはありません。AWSで扱われるメディアはワイプ処理もしくは消磁処理され、AWSのセキュアゾーンを離れる前に物理的に破壊されます。AWS の第三者レポートに文書化されているように、AWS データセンターに対する第三者の検証によって、AWS がセキュリティ認証取得に必要となるルールを確立するためのセキュリティ対策を適切に実装していることが保証されます。お客様はこうした第三者のレポートをAWS Artifactから入手することが可能です。 AWSにおけるサードパーティの管理 AWSにおいては、本投稿執筆時点(2019年12月19日)においてお客様のコンテンツにアクセス可能なサードパーティーのプロバイダはありません。こうした事実は第三者の検証において評価を得るとともに、AWSのサードパーティアクセスページにおいて公表しており、また、変更がある場合にお客様は通知を受けることも可能です。 目的に立ち返る:なんのために”メディア廃棄”を行うか そもそもメディア廃棄の統制を行う目的は何でしょうか。脅威を踏まえて考えれば、組織の所有する(およびしていた)データが許可なく第三者に漏洩することを防ぐことにあります。メディア廃棄の証明をとることは、メディアの廃棄後も、データが第三者により許可なくアクセスされないことを評価するための手段にほかなりません。お客様にとって重要なことはデータがライフサイクルを通じて確実に保護されることです。メディアの廃棄の証明はその手段のうちの一つ(適切に処理されたことの保証手段)にすぎません。お客様の統制を離れたデータが保護されることを確実にすることに焦点をあてることで、環境がクラウドに変わったとしてもお客様の求める管理目的を達成することが出来るのです。 暗号化を活用したデータの保護と廃棄記録 AWSはお客様に重要なデータやトラフィックの暗号化による保護を推奨しており、そのための機能を提供しています。利用終了後もデータを保護する有効な手段として、暗号化による予防的な統制、そして処理の実行を確実に記録することは強く推奨されます。 暗号化がなぜ有効なのでしょうか。暗号化されたデータはそれを復号するための鍵がなければデータとして復元することが出来ません。暗号化に利用する鍵と暗号化されたデータへのアクセスを分離することで権限のない第三者によるデータへのアクセスを予防することが出来ます。このように暗号化を行い、その鍵を消去することはCryptographic Erase(CE:暗号化消去)としてNIST SP800-88においても紹介されています。 AWSのストレージサービスでは利用開始時にデフォルトで暗号化を行う機能を提供(Amazon EBS, Amazon S3)しています。また、Amazon Key Management Services (KMS)によりお客様の鍵によりデータを暗号化することが可能です。これによりお客様が定義したポリシーで鍵へのアクセスを統制しながら利用状況の証跡を取得することが可能となります。また、AWS Configにより意図しない設定の変更や設定ミスの検知および修正を自動化するといった発見的および是正的な統制を組み込むことも容易です。こうした統制を実施することでAWS上のお客様のデータに対して、ライフサイクルに応じた保護を行うことがより容易になりました。 お客様によるデータ廃棄の統制例 統制の一例として、ストレージ領域をデフォルトで暗号化を行う設定とすることで第三者によるアクセスへの保護を実現します。そしてEBSやS3 Bucketを削除する際には、あわせて当該領域の暗号化に用いた鍵をAWS Lambdaを使用してKMSより削除します。これにより従来行っていた当該データの復号が困難になるとともに廃棄証明の代わりとして、暗号化による保護を実施した記録をお客様自身で自動的に取得、管理することができるようになります。鍵へのアクセスが無くなることで、当然AWSによっても、またお客様も廃棄されたデータへのアクセスはできなくなります。   情報セキュリティを管理するためには目的にあわせた管理策を実施する必要があります。しかし一方で、手段自体が目的化してしまい、それを無理に新しい環境であるクラウドにあてはめてしまうアンチパータンが発生することがあります。本投稿ではメディアの廃棄を一つの例示としてとりあげましたが、セキュリティの管理策を実施するうえでの目的に立ち返り、クラウド上で行う上での妥当性、効果や効率性、そして何よりもクラウドの特性を生かしたさらなるセキュリティの向上を実現することでNew Normalに前向きに取り組むことができます。   このブログの著者 松本 照吾(Matsumoto, Shogo) セキュリティ アシュアランス本部 本部長 […]

Read More

研究データ管理基盤での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