Amazon Web Services ブログ

セキュリティは AWS の最優先事項です。これはサービスの開始時から変わりません。GDPR (EU 一般データ保護規則、2018 年 5 月 25 日に施行開始) の導入により、私たちのセキュリティ中心の文化でもプライバシーとデータ保護がより強く意識されるようになりました。締切りよりかなり前でしたが、数週間前に AWS のすべてのサービスが GDPR の基準を満たしていることを発表しました。つまり、お客様の GDPR の課題を解決する 1 つの方法として AWS をご利用いただけるようになりました (詳細は GDPR Center をご覧ください)。 GDPR への準拠に関しては、多くのお客様で順調に準備が進んでおり、当初の不安はかなりなくなったようです。この話題でお客様とお話をさせていただくと、いくつかのテーマが共通しているように感じます。 GDPR は重要です。EU のデータ主体の個人データを処理する場合は、よいプランが必要です。これはガバナンスの問題だけでなく、GDPR に違反した場合には重い罰則があるからです。 この問題の解決は複雑で、多数の要員とツールが必要になる可能性があります。GDPR のプロセスでは多岐にわたる訓練も必要になるため、人員、プロセス、テクノロジーに影響が及びます。 お客様ごとに状況は異なり、GDPR への準拠を評価する方法も多数あります。そのため、お客様のビジネスの特性を意識することが重要です。 ここでは、私たちが学んだ教訓を共有したいと思います。GDPR の課題を解決するために、重要だったのは次の点です。 経営陣の参加が重要です。GDPR の詳細なステータスを当社 CEO の Andy Jassy と定期的に話し合っています。GDPR が非常に重要であることを AWS の経営陣は理解しています。必要な注意が GDPR にまだ向けられていないなら、今すぐ経営トップに知らせる必要があります。 GDPR 関連の作業を集中管理する必要があります。すべての作業の流れを集中管理することが重要です。当然のことのようですが、管理が分散すると、作業の重複やチーム・メンバーの方向性にズレが生じます。 GDPR の課題の解決で最重要のパートナーは法務部門です。お客様独自の環境に対して GDPR をどのように解釈するかを法務部門以外に任せるのは、リスクが大きく、時間とリソースの無駄になる可能性があります。法務部門から適切な助言を得て、方向性を統一して協力し、適切な緊急感を持って前進すれば、分析麻痺による作業停滞に陥らずにすみます。 […]

Amazon DynamoDB をアプリケーションの NoSQL データベースサービスとして使用する場合に、DynamoDB テーブルが使用するストレージ使用量を追跡したいとしましょう。DynamoDB は、サービスメトリックを Amazon CloudWatch に公開します。CloudWatch　は、これらのメトリックをモニタリングおよび分析し、アラームを設定し、さらに AWS　リソースの変更に対して自動的に反応します。現在のところ、DynamoDB　は、ThrottledRequests、ConsumedWriteCapacityUnits、および　ConsumedReadCapacityUnits　を含む、多くの有用なメトリックを　CloudWatch　に送信します。 DynamoDB　テーブルのストレージ使用状況を分析し、DynamoDB　ワークロードが使用するストレージ使用量の履歴を把握し、ストレージコストを管理することは重要です。例えば、Time to Live　(TTL)　を使用して、不要なデータや陳腐化したデータを期限切れにしたいとします。そのような場合、ストリームを使用してそのデータを Amazon S3 または Amazon Glacier にアーカイブすることができるのです。この記事では、DynamoDB テーブルのストレージ使用状況をモニタリングする方法について解説します。 ソリューションの概要 DynamoDB は、6 時間ごとにテーブルのストレージ使用状況を更新します。この情報は、DynamoDB DescribeTable API を使用することで取得できます。テーブルのサイズを決定したら、カスタム CloudWatch メトリックを作成して、データを CloudWatch にプッシュできます。このソリューションでは、AWS CloudFormation を使用して、DynamoDB テーブルのストレージ使用状況をモニタリングするワンクリックデプロイメントアーキテクチャを作成する方法を解説します。これはインフラストラクチャをコードモデルとして実装するために必要です。 次の Python スクリプトと AWS CloudFormation テンプレートは、この GitHub リポジトリで入手できます。プロセスの仕組みは、上の図のようになります。(このソリューションは、DynamoDB ワークロードのあるすべての AWS リージョンでデプロイし、DynamoDB テーブルのストレージ使用量を継続してモニタリングすることを忘れないでください。) Amazon CloudWatch Events は、AWS Lambda 関数をスケジュールに従って実行します。 Lambda 関数は、DescribeTable […]

2021 年 8 月 1 日現在、日本語での SOC レポートは提供されていません。AWS Atifact 内において英文で提供されている最新版をご参照ください。 —————————————————————– 日本のお客様から問い合わせの多かった日本語での SOC1 レポートの提供ですが、2018 年 5 月 23 日より日本語の AWS SOC1 レポートの翻訳文書（以下、日本語 AWS SOC1 レポート）を AWS Artifact 経由で提供を開始しました。今回提供開始の日本語AWS SOC1レポートの対象期間は2017年4月1日から2017年9月30日のものとなります。AWS は最新の SOC1 レポートに合わせてのタイムリーな日本語文書の提供に向けて継続して取り組んでいく予定です。また、SOC レポートに関連してお客様から問い合わせの多い質問と回答を下記に記載しています。各 SOC レポートの詳細、および最新の情報に関しては、以下のサイトをご参照ください。 https://aws.amazon.com/jp/compliance/soc-faqs/   ・SOC1レポートの主目的 SOC1は財務報告に係る内部統制に関連する可能性がある AWS の統制環境について、顧客に情報を提供すること、および財務報告に係る内部統制（ICOFR）の有効性に関する評価および意見について、顧客とその監査人に情報を提供することを目的としています。   ・SOC1 レポートの内容 AWS の統制環境に関する説明、および AWS が定義した統制と目標の外部監査に関する説明   ・各 SOC レポートの入手方法 AWS SOC 1 […]

全 5 回の Blog 連載のうちの 4 回目の連載である今回は、様々なエンコーダーから AWS Media Services への接続および設定方法を学びます。AWS Media Services はカスタマーに対して、高いスケーラビリティを持つ over-the-top (OTT) ビデオ体験を提供することを可能にします。ライブチャンネルもしくはイベントを配信するには、カメラなどの機器からのビデオ信号をエンコードし、追加的な処理、パッケージング、配信のために、クラウドに送信します。 FFMPEG と RTMP および AWS MEDIA SERVICES を利用したチャンネルの作成 こちらの例では、RTMP (Real-Time Messaging Protocol) 伝送用エンコーダーとして FFmpeg を用いたストリームをセットアップし、クラウド上での動画処理およびパッケージングのための AWS Media Services の設定方法を、ステップ・バイ・ステップの手順でお見せします。 FFmpeg は、オーディオとビデオを記録、変換、およびストリームする完全なクロスプラットフォームのソフトウェアソリューションです。 ワークフロー例のダウンロード こちらの例では、下記の方法を学びます。 ・RTMP を使った伝送用エンコーダーとして FFmpeg をセットアップ ・伝送ストリームを AWS Elemental MediaLive で受けて、adaptive bitrate (ABR) のストリームにエンコードする設定方法 ・AWS Elemental MediaLive の出力を AWS Elemental […]

Amazon RDSの利便性と柔軟性を備えたPostgreSQLデータベースエンジンのベータ版、リリース候補、およびearly productionバージョンを簡単にテストできる、Amazon RDSデータベースプレビュー環境が利用可能になりました。 PostgreSQLコミュニティから新しいバージョンがリリースされてから数日または数週間以内に、PostgreSQLの新しい機能をテストすることができるようになりました。現在のところ、Amazon RDSデータベースプレビュー環境では、PostgreSQLの次のメジャーバージョンの開発、ベータ、およびリリースの候補バージョンが提供されています。Amazon RDSデータベースプレビュー環境のデータベースインスタンスは全ての機能を有し、データベースのプレビューバージョンを自動でインストールし、プロビジョニング、および管理をお客様側で行って頂く必要がなく、新しいデータベースエンジンをテストできます。Amazon RDSデータベースプレビュー環境のデータベースインスタンスの価格は、米国東部(オハイオ)リージョンで作成されたRDSインスタンスと同じ価格です。 本番環境クラスのセキュリティ、パフォーマンス、信頼性、管理性、および可用性を確保するために、Amazon RDSは多くのテストを行った後で初めて新しいデータベースバージョンをリリースしてきました。Amazon RDSデータベースプレビュー環境は、新バージョンのデータベースエンジンがAmazon RDS環境への統合とテストが完了するのを待たずに、新しいPostgreSQLデータベースエンジンの信頼性、機能性、およびパフォーマンスの向上をすぐにお客様がテスト出来る環境を提供することで、お客様のリリースサイクルを数週間短縮することが可能になります。PostgreSQLのプレビュー版は、PostgreSQLコミュニティによってGA版がリリースされ、その後Amazon RDSでサポートされるまでAmazon RDSデータベースプレビュー環境で使用できます。 Amazon RDSデータベースプレビュー環境は、最新世代のインスタンスクラス(現在のところT2、M4、およびR4)でSingle-AZインスタンスとMulti-AZインスタンスの両方をサポートし、KMSキーを使用した透過的暗号化もサポートしています。Amazon RDSデータベースプレビュー環境データベースインスタンスは、最大60日間保持された後、自動的に削除されます。Amazon RDSデータベースのスナップショットは、プレビュー環境で作成し、データベースインスタンスの作成や復元に使用できますが、プレビュー環境内でコピーしたり、プレビュー環境外にコピーしたりすることはできません。代わりに、PostgreSQL標準のダンプとロード機能を使用して、データベースのロードとアンロードを行うことができます。 既存のAmazon RDSプロダクション環境のSLAはAmazon RDSデータベースプレビュー環境のインスタンスには適用されません。また、プレビュー環境で作成されたインスタンスについては、Amazon Customer Supportでサポートチケットを開くことはできません。私たちは、Amazon RDSデータベースプレビュー環境向けのフォーラムを作成しました。Amazon RDSチームは、PostgreSQLデータベースの候補バージョンとAmazon RDSデータベースプレビュー環境の両方に関する情報などをこちらで共有致します。 Amazon RDSデータベースプレビュー環境は今日からご利用可能です。詳細については、http://aws.amazon.com/rds/databasepreviewを参照してください。   翻訳は星野が担当しました。原文はこちら

こんにちは、マーケティングの鬼形です。 本日 (2018/5/22) 開催しました AWS Black Belt Online Seminar「失敗例を成功に変える AWS アンチパターン」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

全 5 回の Blog 連載のうちの 3 回目の連載である今回は、様々なエンコーダーから AWS Media Services への接続および設定方法を学びます。AWS Media Services はカスタマーに対して、高いスケーラビリティを持つ over-the-top (OTT) ビデオ体験を提供することを可能にします。ライブチャンネルもしくはイベントを配信するには、カメラなどの機器からのビデオ信号をエンコードし、追加的な処理、パッケージング、配信のために、クラウドに送信します。 FFMPEG と RTP および AWS MEDIA SERVICES を利用したチャンネルの作成 こちらの例では、RTP (Real-Time Transport Protocol) 伝送用エンコーダーとして FFmpeg を用いたストリームをセットアップし、クラウド上での動画処理およびパッケージングのための AWS Media Services の設定方法を、ステップ・バイ・ステップの手順でお見せします。 FFmpeg は、オーディオとビデオを記録、変換、およびストリームする完全なクロスプラットフォームのソフトウェアソリューションです。 ワークフロー例のダウンロード こちらの例では、下記の方法を学びます。 RTP を使った伝送用エンコーダーとして FFmpeg をセットアップ 伝送ストリームを AWS Elemental MediaLive で受けて、adaptive bitrate (ABR) のストリームにエンコードする設定方法 AWS Elemental MediaLive の出力を AWS […]

こんにちは、マーケティングの鬼形です。 先日 (2018/5/16) 開催しました AWS Black Belt Online Seminar「Amazon Connect」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

このブログ記事では、Amazon SageMaker、Spark ML、Scikit-Learn を使用した、高ディメンジョンセットでの PCA に関するパフォーマンス比較を実施します。SageMaker は一貫してより高速な計算性能を示しました。速度改善内容を確認するために、下図 (1) および (2) を参照してください。 主成分分析法 主成分分析 (PCA) とは、依然として、可能な限りより多くの情報を保持しながら、データセット内部のディメンジョナリティ (例: 機能の個数など) の低減を目的とした監督機能解除済み学習アルゴリズムです。PCA は、各列は、それ以降はお互いが独立性を有する状況となるような、1 組のデータ行列を 1 個の直交空間に線形変換するものであり、個別のカラムが対象データ内で 1 個の既知の割合を占めることができるものです。換言すれば、個別のコンポーネントが互いに無相関性のような、元の特徴の複合体である、コンポーネントと呼ばれる 1 つの新しいセットの機能を発現します。更に、これらは制限が付加されることで、第 1 コンポーネントが対象データ内で可能な限り巨大な可変率を占め、第 2 コンポーネントが第 2 番目に最大であり、そして以下も同様となることとなります。 より包括的な説明については、「https://docs.aws.amazon.com/sagemaker/latest/dg/how-pca-works.html」を参照してください。 PCA は、Exploratory Data Analysis (EDA) 用の 1 個のツールおよび 1 個の機械学習用アルゴリズム (ML) の両面でも強力です。EDA に関して、PCA はディメンジョナリティ低減および 1 件のデータ問題についての多重共線性 (マルチコ) 低減に最適です。ML 方法論の 1 つとして、異常検出 (例: […]

Amazon DynamoDB サービスでは、1 秒あたり数十億件のアイテムと数百万回のリクエストの中から膨大な分析値を取得することができます。ただし、その分析値を取得するには、データをエクスポートする必要があります。DynamoDB テーブルから分析プラットフォームにデータをコピーすることで、情報を豊富に抽出することができます。これを行うには、優れたアーキテクチャのビッグデータパイプラインが、トランザクションプロセスを分析から切り離すのに大変便利です。このブログ記事では、DynamoDB テーブルから Amazon S3 にデータを移行するビッグデータパイプラインを構築する方法を説明します。これは、完全管理型の Presto クエリサービスである Amazon Athena を使用して、高度な分析が実行でき、Amazon QuickSight を用いて、視覚化およびアドホック分析を構築することも可能です。 デカップリングしたビッグデータアプリケーションにはたいてい、ストレージとコンピューティングを分離する共通のパイプラインがあり、そのため、新しい処理技術が生まれた際にはそれを活用することができます。デカップリングにより、データの耐久性に影響を与えることなく、複数の分析エンジン用の計算リソースを柔軟にプロビジョニングできるようになります。また、パイプラインを設計して、ストレージと処理の段階を繰り返し、下流のアプリケーションがすばやく使用できる形式でデータを整形することも可能です。 ビッグデータパイプラインの設計には、3 つの大きな特性が作用しています。 パイプライン全体の遅延 – データから正しい情報を得るまでにどれくらいの時間を要するでしょうか? 数千分の 1 秒、数分、あるいは数日? データのスループット – どれくらいのデータを取り込んで処理する必要がありますか? 数ギガバイト、数テラバイト、あるいは数ペタバイト? コスト – アプリケーションのための目標予算はいくらですか? AWS の最も費用対効果の高いオプションが、普通、適切な選択と言えるでしょう。 ビッグデータパイプラインを設計する際に考慮すべきことは他にも、データ構造、アクセスパターン、データの温度、可用性と耐久性、そしてサービスが完全に管理されているかどうかなどがあります。これらの特性に基づいてジョブに適切なツールを使用することは、優れたアーキテクチャを持つビッグデータパイプラインにとって重要です。 階層化されているビッグデータパイプライン 階層化されたビッグデータパイプラインを解説する前に、このソリューションで利用する主なサービスと機能を見てみましょう。 パイプラインでの DynamoDB の機能 DynamoDB で用いる主要なコンポーネントは、テーブル、項目、および属性です。テーブルは項目の集合であり、各項目は属性の集合です。DynamoDB はプライマリキーを使って、テーブルの各項目を識別します。セカンダリインデックスを使用すると、クエリの柔軟性が向上します。詳細については、「Amazon DynamoDB の仕組み」を参照してください。これは「DynamoDB 開発者ガイド」の中にあります。 DynamoDB TTL (Time To Live) を使用すれば、ストレージコストを削減する手段として、すでに関連性がなくなった項目を自動的に削除することができます。このブログ記事では、テーブルの TTL を有効にし、ttl　属性を使用して削除のタイムスタンプを設定します。TTL の詳細については、「Time […]