Amazon Web Services ブログ

以前の AWS データベースに関するブログ記事で、 複数の属性の範囲の境界を使用して Amazon DynamoDB のテーブルを効率的に照会できるように、データを並べ替えることができる Z オーダーインデックスを紹介しました。この記事では、インデックス用のスキーマを作成するプロセスについて説明します。スキーマに含める属性を決定する方法、インデックスのスキーマがクエリの効率に与える影響、さまざまなデータ型の操作方法について説明します。 この記事はパート 1 で説明した概念に基づいていますので、先へ進む前に少し時間をとってその内容を確認されることをお勧めします。 Z オーダーインデックスのスキーマの作成 前の記事で説明したように、インデックスに保存されている各レコードには Z アドレスが割り当てられます。Z アドレスとは固定長のバイナリ値であり、レコードの属性の既知のセットのビットをインターリーブすることで見つけることができます。次の図は、2つの属性 x と y による Z アドレスの計算を示しています。 Z アドレスは、DynamoDB テーブルのソートキー (またはローカルのセカンダリインデックスキー) として使用されます。ソートキーは、高速でバインドされたクエリを可能にするために保存されているテーブルのデータを並べ替えること、パーティション内のレコードを一意に識別することという 2 つの目的を果たします。パーティションおよびソートキーの詳細については、DynamoDB のドキュメントのプライマリキーを参照してください。 スキーマは、テーブルまたはインデックスに保存される情報の構造を記述します。Z オーダーインデックスの文脈では、スキーマには次のものが含まれます。 インデックス付けされる属性の名前 (上記の図の x と y)。 属性がエンコードされる順序 (y に続いて x)。 属性のそれぞれのデータ型 (x と y は符号なし整数、0 以上の整数) とそれらをバイナリで表現する方法。 新しいレコードをテーブルに挿入するか既存のレコードを更新するたびに、そのレコードの Z アドレスを計算する必要があります。同様に、クエリを作成するときは、範囲の境界を表す最小レコードと最大レコードの Z アドレスを計算する必要があります。Z […]

Amazon Aurora は、プライマリ DB インスタンス (クラスタエンドポイント) と、リードレプリカ (リーダーエンドポイント) のエンドポイントを提供します。Aurora は、クラスタエンドポイントを自動的に更新するので、常にプライマリインスタンスを指し示すようできています。リーダーエンドポイントの読み取り機能は、使用可能なすべてのリードレプリカの読み取り操作の負荷を分散します。 Amazon Aurora Replica では、通常 100 ms 未満のレプリケーションラグが発生します。したがって、アプリケーションで遅延が許容される場合は、クラスタエンドポイントとリーダーエンドポイントの両方を使用して、水平方向に拡張されたデータベースを利用できます (図 1)。 図 1: 使用するエンドポイントを決定するアプリケーションのアーキテクチャ ただし、読み取り用と書き込み用両方のデータベースエンドポイント管理は、複雑なアプリケーションになります。この記事では、pgpool を使った、書き込みデータ量を自動的にクラスタエンドポイントへ、また読み込みデータ量を読み込みエンドポイントに転送する PostgreSQL-Amazon Aurora 互換の単一エンドポイントの構築方法をご紹介します (図 2)。 図 2: pgpool ミドルウェアに基づいたソリューション提案 アーキテクチャ Pgpool は PostgreSQL データベースとデータベースクライアントの間に位置する BSD ライセンスのミドルウェアですこの例では、図 3 のアーキテクチャを使用します。 図 3: PostgreSQL-Amazon Aurora 互換クラスタ用の単一エンドポイントを構築するミドルウェアとしての pgpool の使用 Amazon Aurora クラスタは、1 つのプライマリインスタンス、2 つのアベイラビリティゾーンと 2 […]

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

本日は Amazon SageMaker の内蔵型アルゴリズムのためのパイプ入力モードについて紹介します。パイプ入力モードを使い、データセットが最初にダウンロードされるのではなく、トレーニングインスタンスに直接ストリーミングされます。これは、トレーニングジョブが直ぐに始まり、早く完了し、必要なディスク容量も少なくて済むという意味です。Amazon SageMakerのアルゴリズムは、高速で拡張性が高くなるように設計されています。このブログ記事では、パイプ入力モード、それがもたらす利点、トレーニングジョブにおいてそれをどのように活用できるかについて説明しています。 パイプ入力モードでは、データはディスク I/O なしで実行中にアルゴリズムコンテナに送られます。このアプローチは、長くかかるダウンロードの処理を短縮し、起動時間を大きく短縮します。それによって通常ならファイル入力モードより読込スループットも良くなります。これは、高度に最適化されたマルチスレッドバックグラウンドプロセスによって、データが Amazon S3 から取得されるからです。また、16 TB の Amazon Elastic Block Store (EBS) のボリュームサイズ制限よりもずっと大きいデータセットをトレーニングできます。 パイプモードによって以下のことが可能になります。 データがトレーニングインスタンスにダウンロードされるのではなく、ストリーミングされるため、起動時間がより短くなります。 より高性能なストリーミングエージェントによる I/O スループットの向上 実質的に無制限のデータ処理能力。 内蔵型 Amazon SageMaker アルゴリズムでファイル入力モードまたはパイプ入力モードを活用できます。大きなデータセットにはパイプモードが推奨されているとはいえ、メモリ内に収まる小さなファイルやアルゴリズムのエポック数が多い場合であっても、ファイルモードは有効です。現在、どちらのモードでもトレーニングジョブの小さい実験から、ペタバイト規模の分散型のトレーニングジョブに至るまでさまざまな使用範囲をカバーしています。 Amazon SageMakerのアルゴリズム 大半のファーストパーティのAmazon SageMakerアルゴリズムは、最適化された Protocol Buffers (プロトコルバッファー) のrecordIO フォーマットを使えば最適に動作します。このため、本リリースでは、protobuf の recordIO フォーマット用のパイプモードのみがサポートされています。以下に一覧するアルゴリズムは、Protocol Buffers (プロトコルバッファー) の recordIO にエンコードされたデータセットで使用した場合に、パイプ入力モードをサポートします。 主成分分析法 (PCA) K 平均法クラスタリング 因数分解法 潜在的ディリクレ配分法 (LDA) 線形の学習者 (分類と回帰) […]

AWS ではセキュリティが最優先です。また、お客様にとってもこれは同じことです。私たちは個人データを保護するために膨大な量のリソースを使用し、当社のお客様にとってデータの保護が容易になるよう継続的に機能強化を図っています。Amazon Aurora の MySQL 互換版を含め、AWS のサービスはすべて、EU の一般データ保護規則 (GDPR) に準拠しています。  詳細については、Amazon のウェブサイトで一般データ保護規則 (GDPR) センターを参照してください。 Amazon の主要データストレージと処理サービスの 1 つである、Amazon Aurora の MySQL 互換版では、幅広い暗号化とデータアクセスコントロールオプションを提供しています。これらはこうしたサービス上で保存した個人データを保護しやすいように設計されています。データ保護の責任は現在進行中の運用に限られたものではなく、データの移動や移行といったアクティビティにも伴います。 今日のお客様は個人データの保護方法に大きな関心を寄せており、彼らが保存および処理するデータにも目を配っています。この結果、暗号化されたデータベースへデータを移行したり、データの転送時に暗号化形式を使用したりといった決定を下すことが増えています。このブログ記事では、Amazon Aurora の MySQL 互換版と安全な移行を実行する様々なパターンと、それを可能にするサービス機能についてご紹介します。 Amazon Aurora の MySQL 互換版の暗号化データストレージと処理機能 Amazon Aurora の MySQL 互換版では、次に示すように、お客様が暗号化技術を使用して個人データを保存および処理できるようにするいくつかの機能を提供しています。 Amazon Aurora では AWS Key Management Service (AWS KMS) を通じて管理するキーを使用してデータベースを暗号化することが可能です。Amazon Aurora データベースで暗号化が有効になると、保存されているデータ、自動化されたバックアップ、スナップショットが暗号化されます。 Amazon Aurora の MySQL 互換版を使用することで、データベースインスタンスに暗号化された接続を確立でき、またクライアントに暗号化された接続を使用するよう強制することもできます。 復元時には自分の望む […]

Apache Spark の採用は過去数年で大幅に増加しており、Spark ベースのアプリケーションパイプラインを実行することは今や新しい標準とも言えます。ETL (抽出、変換、ロード) パイプラインにある Spark ジョブの要件はそれぞれ異なります。ジョブ間の依存関係を処理し、実行中の順序を維持し、複数のジョブを並行して実行する必要があります。ほとんどの場合、Apache Oozie、Apache Airflow、さらには Cron などのワークフロースケジューラツールを使用して、これらの要件を満たすことができます。 Apache Oozie は、Hadoop ベースのジョブに広く使われているワークフロースケジューラシステムです。しかし、UI 機能が制限されている、他サービスとの統合がしにくい、XML に大きく依存しているなど、一部のユーザーには適していない恐れがあります。一方、Apache Airflow　には、強力な　UI　とモニタリング機能、いくつかの AWS やサードパーティのサービスとの統合など、たくさんの優れた機能が搭載されています。ただし、Airflow は Airflow サーバーのプロビジョニングと管理を必要とします。Cron ユーティリティは強力なジョブスケジューラです。けれども、仕事の細部に関する可視性があまりなく、Cron ジョブを使用してワークフローを作成することは難しいかもしれません。 特定の順序でいくつかの Spark ジョブを実行したいが、それらのジョブをオーケストレーションしたり、別のアプリケーションを管理するのに時間を取りたくないといった、単純なユースケースがあるとしましょう。 今日は、AWS Step Functions を使ったサーバーレスの方法で、このユースケースを取扱います。Amazon EMR 上で、AWS Step Functions でワークフロー全体を作成し、Apache Livy を通じて、Spark とのやり取りを実行します。 この記事では、AWS Step Functions と Apache Livy を使用して、サーバーレスの Spark ベース ETL パイプラインをオーケストレーションする手順の一覧を順に見ていきます。 データを入力する この投稿のソースデータについては、ニューヨーク市タクシーリムジン委員会 (TLC) […]

Keras および Apache MXNet (Incubating) のオープンソースプロジェクトへの参画者のおかげで、Keras-MXNet 深層学習のバックエンドが現在利用可能です。Keras は Python で書かれた高水準なニューラルネットワーク API です。CNN および RNN のプロトタイピングを素早く簡単に作成することで知られています。 Keras の開発者は、現在、畳み込みニューラルネットワーク (CNN) のトレーニングおよび再帰型ニューラルネットワーク (RNN) の分散トレーニング向けのハイパフォーマンスな MXNet 深層学習エンジンを使用することができます。コードを数行更新すると、Keras の開発者は、MXNet のマルチ GPU の分散トレーニング機能を使用して、トレーニングスピードを速めることができます。MXNet モデルを保存できることは、このリリースのもう一つの注目すべき機能です。Keras での設計、Keras-MXNet によるトレーニング、本番環境のインターフェイスの実行が大規模な MXNet で可能です。 Keras 2 および MXNet の分散トレーニング この記事では、Keras-MXNet のインストール方法と CNN および RNN のトレーニング方法の説明をします。以前、他の深層学習エンジンで分散トレーニングを実施したことがある場合は、退屈で難しいかもしれません。それでは、Keras-MXNet について内容を見ていきましょう。 インストールは数ステップだけです。 AWS 深層学習 AMI のデプロイ Keras-MXNet のインストール Keras-MXNet の設定 1. AWS […]

先日(5月10日)、「Amazon Analytics (Redshift) 事例祭り」というイベントが開催されました。オンプレミスDWHを利用していた、もしくは現在使用しているお客様がDWHをAWSクラウド上のAmazon Redshiftに移行した経験談を共有していただくという内容のセミナーで、定員の120名を越えるお申込をいただき、会場が満室になる熱気の中で実践的な情報が共有されました。 この記事ではそのイベントの内容をご紹介します。また、各社発表資料へのリンクも掲載しています。

セキュリティは 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 […]