Amazon Web Services ブログ

AWS Glue : ネストされた JSON を Relationalizeトランスフォーム

AWS Glue には、ネストされた JSON をリレーショナルデータベースに簡単にインポートできるカラムに変換することによって抽出、変換、ロード (ETL) プロセスをシンプル化する、Relationalize と呼ばれるトランスフォームがあります。Relationalize は、ネストされた JSON を JSON ドキュメントの最外部レベルでキーと値のペアに変換します。変換されたデータでは、ネストされた JSON からの元のキーのリストが、ピリオドで区切られた形で維持されます。 サンプルユースケースを使って Relationalize がどのように役立つかを見てみましょう。 Relationalize の実行例 ビデオゲームの開発者が、JSON 形式で保存されたデータに基づいてプレイヤーの行動についてのレポートを実行するために Amazon Redshift などのデータウェアハウスを使用したいとしましょう。サンプル 1 は、ゲームからのユーザーデータ例を示しています。「User1」という名前のプレイヤーには、ネストされた JSON データ内に種族、クラス、ロケーションなどの特徴があります。さらに下に行くと、プレイヤーの武器情報に追加のネストされた JSON データが含まれています。開発者がデータウェアハウスに対してこのデータの ETL を行いたい場合、コードではネストされたループや再帰的関数を用いなければならないかもしれません。 サンプル 1: ネストされた JSON { “player”: { “username”: “user1”, “characteristics”: { “race”: “Human”, “class”: “Warlock”, “subclass”: “Dawnblade”, “power”: 300, “playercountry”: “USA” }, […]

Read More

AWS Glue and SneaQLを使ったAmazon Redshift へのUpsert

この記事は、Full 360 のソリューションアーキテクトである Jeremy Winters と Ritu Mishra によるゲスト投稿です。2 人によると、「Full 360 はクラウドファースト、クラウドネイティブのインテグレーターで、2007 年の創立以来の忠実なクラウド信者です。私たちの焦点は、クラウドへの旅におけるお客様の援助であり続けています。ビッグデータとウェアハウジング、アプリケーション近代化、そして Cloud Ops/戦略といった私たちの業務分野は、深いだけではなく、明確な専門知識を表しています。」 AWS Glue は、簡単でコスト効果の高い方法でデータの分類、消去、強化、およびさまざまなデータストア間を確実に移動することができる、完全マネージド型 ETL (抽出、変換、ロード) サービスです。 10年もの間クラウド内にデータウェアハウスソリューションを構築してきた企業として、Full 360 はカスタマーソリューションで AWS Glue をどのように活用できるかについて興味を持っていました。この記事では、当社が Amazon Redshift データ統合ユースケースのための AWS Glue の使用からの得た経験と教訓について詳しく説明していきます。 UI ベースの ETL ツール 当社では、re:Invent 2016 で AWS Glue が発表された当時からそのリリースを心待ちにしていました。私たちの顧客の多くは、データ変換パイプラインを管理するための使いやすい UI ベースのツールを探しています。しかし当社の経験では、どの生産パイプラインの複雑性も、それらを作成するために使われたテクノロジーに関わらず、解消しづらい傾向にあります。Full 360 では, データ統合を処理するためにコンテナにデプロイされたクラウドネイティブなスクリプトベースのアプリケーションを構築しており、スクリプトベースの変換は、発生するデータ問題に対応するために必要なロバスト性と柔軟性のバランスを提供すると考えています。 AWS Glue は、スクリプトを記述することを好む開発者と、UI ベースのインタラクションを望むユーザー両方の要望に応えます。データのソースとターゲットを選択することにより、UI を使ってジョブを初期に作成することが可能です。AWS Glue は内部で Python […]

Read More

Amazon Relational Database Service – 2017 年を振り返って

2017 年には Amazon RDS チームによって、およそ 80 個もの機能がリリースされました。一部はこのブログでもご紹介しましたが、AWS データベースブログや AWS の最新情報またはフォーラムの投稿でもご紹介しています。今週のしめくくりに、これらの情報を振り返って整理したいと思います。ではご紹介します! 認証とセキュリティ 1 月 – FedRAMP Certification for Amazon RDS for MySQL, Oracle, and PostgreSQL 2 月 – Forced SSL Support for SQL Server 4 月 – AWS IAM で RDS for MySQL と Amazon Aurora データベースへのアクセスを管理 6 月 – TDE Encrypted Cross-Region Snapshots for RDS […]

Read More

【 AWS 新リージョン】 AWS 大阪ローカルリージョンが本日より利用可能になりました

本日 日本で2番目、ローカルリージョンとしては AWS 初となる、 Asia Pacific (Osaka) Local Region(以下、AWS 大阪ローカルリージョン)がご利用いただけるようになりました。 2017 年 5 月 31 日 AWS Summit Tokyo 2017 の基調講演にて、 2018 年より利用できるお知らせをしました。AWS 東京リージョンをお使いのお客さまにおいては、規制対応のため補完的なインフラストラクチャを準備し、アベイラビリティゾーン間を地理的に離す必要のある特定のアプリケーションの運用が可能になる点、多くの反響をいただきました。 AWS 東京リージョンが開設した 2011 年から、お客様は、同リージョンの 4 つのアベイラビリティゾーンを利用することで、いずれか 1 つのデータセンターで障害が発生した場合でも支障をきたさない、優れた耐障害性と高可用性を持つアプリケーション構築が可能になりました。すべての AWS リージョンは、複数かつ地理的に分離されたアベイラビリティゾーンから構成されます。アベイラビリティゾーンとは、 1 つの障害が可用性に影響を与えるリスクを大幅に減らすために、十分地理的に離れた地点に位置する一方で、迅速なフェイルオーバーが求められる事業の継続性に関わるアプリケーションのニーズを満たすために、十分近い距離に位置する独立したテクノロジーインフラストラクチャです。また、各アベイラビリティゾーンは、独立した電源および冷却システム、物理的セキュリティを擁し、大容量な光ファイバーネットワークを通じて Amazon のグローバルバックボーンネットワークに接続しています。AWS 大阪ローカルリージョンは、当初、単一のアベイラビリティゾーンのみを提供し、データセンター間をこれまで以上に地理的に離すことで、特定のアプリケーションのニーズに対応します。 AWS 大阪ローカルリージョンは、通常の AWS リージョンと同じように、他の AWS リージョンから独立し、 AWS リージョン内に独立した API エンドポイントを有します。大阪ローカルリージョンは、東京から 400 キロメートル離れた地点に位置しているため、 AWS 東京リージョンからさらに離れた場所に、拡張可能なデータセンターが必要なお客様に適しています。 IT 資産に対する追加の対策として、国内に地域的な多様性を重要視するお客さまは […]

Read More

AWS 深層学習 AMI は TensorFlow と Microsoft Cognitive ツールキット用の Volta GPU に対するより高速のトレーニングを提供します

Ubuntu と Amazon Linux の AWS 深層学習 AMI に最新バージョンの TensorFlow (1.5) と Microsoft Cognitive ツールキット (2.4) が含まれます。 これらのフレームワークは、NVIDIA CUDA 9 と cuDNN 7 ドライバーのサポートを提供します。これにより、ユーザーは Amazon EC2 P3 インスタンスに対応する V100 Volta GPU によりサポートされる複合精度のトレーニングを利用できるようになります。当社の Volta における TensorFlow 1.5 のテストでは、ResNet-50 ベンチマークを合成 ImageNet データを使って FP16 モードの p3.8xlarge インスタンスでトレーニングすると、TensorFlow 1.4.1 でのトレーニングよりも 1.8 倍高速になりました。 深層学習フレームワークの最新の更新 深層学習 AMI は、個別のConda ベースの仮想環境で、深層学習フレームワークの最新の正式バージョンに対して、事前構築された pip バイナリを提供します。 […]

Read More

ご利用の WordPress ブログに新しい Amazon Polly の声を

私は最初、皆さまに 2016 年後半に Polly について、 「Amazon Polly – 24 か国語 47 種類の声で音声変換」の投稿でお話ししました。 AWS re:Invent が起動した後、韓国語、5 種類の新しい声のサポートを追加し、Polly を aws パーティションのすべてのリージョンで利用可能にしました。また、ウィスパリング、スピーチマーク、ティンバーエフェクト、および ダイナミックレンジ圧縮などの機能を備えています。 新しい WordPress プラグイン 当社は今日、お客様のブログ投稿の高品位音声バージョンを作成するために、WordPress プラグインを使い始めています。Amazon Pollycast と呼ぶ機能を使用して、投稿中やポッドキャスト内の音声にアクセスできます! 両方のオプションにより、お客様のコンテンツにより容易にアクセスできるようになり、より広い対象者に達することを支援できます。このプラグインは、AWS アドバンストテクノロジーパートナーである WP Engine の AWS チームの共同作業でした。 ご覧の通り、このプラグインのインストールと構成は容易です。お使いのインフラストラクチャまたは AWS 上で実行する WordPress のインストレーションと共に使用できます。いずれの方法でも、Polly のすべての音声に幅広い構成オプションと共にアクセスできます。 生成される音声 (各投稿の MP3 ファイル) は、WordPress コンテンツと共に保存するか、Amazon Simple Storage Service (S3) に保存し、その際に、Amazon CloudFront 経由のコンテンツ配布のための任意のサポートが利用できます。 プラグインのインストール 既存の […]

Read More

New – DynamoDB の保存時の暗号化

AWS re:Invent 2017 では、Werner は対象者に対して、次のように勧めました。「誰も見ていないようにダンスをして、誰もがしているように暗号化してください。」 AWS チームは常に、機密データを保護し、またコンプライアンスの目標を達成するために支援することを容易にする機能を追加したいと考えています。たとえば、2017 年に当社は SQS と EFS に対して保存時の暗号化を開始し、S3 に対して追加の暗号化オプション、さらに Kinesis データストリームのサーバー側の暗号化を開始しました。 今日、Amazon DynamoDB に対して保存時の暗号化の導入に、別のデータ保護オプションを提供しています。新規テーブルを作成するときに暗号化を有効にするだけで、後は DynamoDB が行います。お使いのデータ (テーブル、ローカルセカンダリインデックス、グローバルセカンダリインデックス) は、AES-256 およびサービスデフォルトのAWS Key Management Service (KMS) キーを使用して暗号化されます。暗号化はストレージオーバーヘッドを追加せず、完全に透過的です。以前のように、アイテムを挿入、クエリ、スキャン、および削除できます。チームは暗号化を有効にして、暗号化した DynamoDB テーブルで異なるいくつかのワークロードで実行した後、レイテンシーで変更を観察しませんでした。 暗号化テーブルの作成 AWS マネジメントコンソール、API (CreateTable)、または CLI (create-table) から暗号化テーブルを作成できます。私はコンソールを使用します。私は通常通り、次のように名前を入力して、プライマリーキーを設定します。 先に進む前に、[デフォルト設定の使用] をオフにして、[暗号化] セクションまで下方にスクロールして、[暗号を有効化] をオンにします。次に、[作成] をクリックすると、私のテーブルが暗号化形式で作成されます。 一目でテーブルの暗号化設定を確認することができます。 コンプライアンスチームが、DynamoDB でキーを使ってデータを暗号化する方法を尋ねられたら、AWS CloudTrail トレールを作成して、アイテムを挿入し、テーブルをスキャンして AWS KMS API へのコールを確認することができます。以下がトレールからの抽出です。 { “eventTime”: “2018-01-24T00:06:34Z”, “eventSource”: […]

Read More

Amazon Lex 対話ボックスの対応を強化

AWS マネジメントコンソールから Amazon Lex 対話ボットに応答を直接追加できるようになりました。ユーザーと活発に説得力のある対話を行うための応答メッセージを使用しましょう。 応答を使用する 応答はボットによるやり取りの最終要素であり、ボットのやり取りがすべて行われたあとに、ユーザーに表示されます。 応答にはお別れの挨拶といったシンプルなものから、メッセージを表示して別のやり取りにつながる様々なボタンの付いた画像のカルーセル表示などがあります。  応答は一部の事例ではやり取りの主要な要素となることもあります。たとえば、ユーザーを別のボット機能へ導くのに役立つやりとりなどがその例です。 応答は事前に定義され、デベロッパーによって作成されたメッセージのグループから動的に選択されるメッセージで構成されています。  たとえば、予約ボットでは最初のメッセージグループとして、ボットがユーザーに使用できる様々な挨拶(「こんにちは」、「いらっしゃいませ」、「お待たせいたしました」)などを含めることができます。2 つ目のメッセージグループには様々な自己紹介メッセージを指定できます。たとえば、「私は予約用ボットです」、「こちらは予約用ボットです」など。 3つ目のメッセージグループにはやり取りするための言葉を指定します。「レンタカーのご予約、ホテルのご予約はお任せください」など。  Amazon Lex は各メッセージグループの各メッセージを動的に使用して会話の受け答えを構築します。たとえば、会話の一例として次のメッセージをご覧ください。 会話例をもう 1 つご覧ください。 応答は簡単なもので、ユーザーが別の表現を使って答え、それにより別のやり取りがトリガーされるものを使用します。  たとえば、ユーザーが「レンタカー」と答えるとします。「レンタカー」がレンタカーを支援するやり取りの対話に一致すれば、そのやり取りが同時にトリガーされます。 応答には次に示すコンポーネントを 3 件まで指定できます。 メッセージ (いずれの応答にも 1 件以上のメッセージが必要) 応答の質問に対するユーザーの回答が「いいえ」であれば、終了メッセージ 応答カード 応答は Amazon Lex コンソール上で、Amazon Lex SDK を介して実行できます。  コンポーネントを見ながら応答の作成方法をご紹介します。 メッセージ Amazon Lex コンソールでは、応答セクションの最初のコンポーネントはメッセージまたはメッセージグループです。エディターではメッセージグループはこのように表示されます。 より自然な会話の流れを作るのに役立つのであれば、1 件の応答に 1 つまたは複数のメッセージグループを作成できます。  メッセージはメッセージグループごとにマークが付いた状態 (メッセージグループ 1、メッセージグループ 2 など) でクライアントに送信されるため、それぞれのグループはサポート対象の Amazon Lex チャンネルに 1 行ずつ自動的に表示されます。  […]

Read More

Amazon Redshiftを使用した高性能ETL処理のベストプラクティス Top 8

ETL(Extract、Transform、Load)プロセスを使用すると、ソース・システムからデータ・ウェアハウスにデータをロードできます。 これは、通常、バッチまたはほぼリアルタイムのインジェスト(挿入)プロセスとして実行され、データウェアハウスを最新の状態に保ち、エンドユーザーに最新の分析データを提供します。 Amazon Redshiftは、高速でペタバイト規模のデータウェアハウスであり、データ駆動型の意思決定を簡単に行うことができます。 Amazon Redshiftを使用すると、標準的なSQLを使用して、費用対効果の高い方法で大きなデータを洞察することができます。 StarおよびSnowflakeスキーマから、分析クエリを実行するための単純化された正規化されていないテーブルまで、あらゆるタイプのデータモデルを使用した分析が可能です。 堅牢なETLプラットフォームを操作し、Amazon Redshiftにデータをタイムリーに配信するには、Amazon Redshiftのアーキテクチャを考慮してETLプロセスを設計します。 従来のデータウェアハウスからAmazon Redshiftに移行する場合、リフト・アンド・シフト方式を採用することが魅力的ですが、結果としてパフォーマンスとスケールの問題が長期的に発生する可能性があります。 この記事では、ETLプロセスにおける最適かつ一貫した実行時間を確保するためのベスト・プラクティスを下記にご紹介します。 複数の均等なサイズのファイルからデータの COPY Workload Management (WLM) を用いたETL実行時間の改善 定期的なテーブルのメンテナンスの実施 単一のトランザクションで複数ステップの実行 データの一括読み込み UNLOADを利用した大きな結果セットの抽出 アドホックETL処理に Amazon Redshift Spectrumを使用 診断クエリを使用して日常的なETLヘルスの監視 1. 複数の均等なサイズのファイルからデータの COPY Amazon RedshiftはMPP(大規模並列処理)データベースで、すべての計算ノードがデータの取り込み作業を分割して並列化します。 各ノードはさらにスライスに細分され、各スライスは1つ以上の専用コアを有し、処理能力を等しく分割します。 ノードあたりのスライス数は、クラスタのノードタイプによって異なります。 たとえば、各DS2.XLARGE計算ノードには2つのスライスがありますが、各DS2.8XLARGE計算ノードには16のスライスがあります。 Amazon Redshiftにデータを読み込むときは、各スライスに同じ量の作業をさせることを目指すべきです。 1つの大きなファイルまたは不均一なサイズに分割されたファイルからデータをロードすると、一部のスライスは他のスライスよりも多くの仕事をする必要があります。 その結果、プロセスは最も遅い、または最も負荷の高いスライスと同じ速度で実行されます。 以下の例では、1つの大きなファイルが2ノードのクラスタにロードされ、ノード「Compute-0」のうちの1つだけがすべてのデータ処理を実行します。 データファイルを分割する際には、圧縮後のサイズがほぼ同じ(1 MB〜1 GB)であることを確認してください。 ファイル数は、クラスタ内のスライス数の倍数にする必要があります。 また、gzip、lzop、またはbzip2を使用してロードファイルを個別に圧縮し、大規模なデータセットを効率的にロードすることを強くお勧めします。 1つのテーブルに複数のファイルをロードする場合は、複数のCOPYコマンドではなく、テーブルに対して1つのCOPYコマンドを使用します。 Amazon Redshiftはデータの取り込みを自動的に並列化します。 1つのCOPYコマンドを使用してデータをテーブルにバルクロードすると、クラスタリソースの最適な使用と可能な限り高いスループットが可能となります。 2. Workload Management (WLM) を用いたETL実行時間の改善 […]

Read More

東京リージョンで Amazon Aurora with PostgreSQL Compatibility をご利用可能に

Amazon Aurora PostgreSQL-compatible edition が、アジアパシフィック (東京) でも利用可能となりました。これにより、データベースの構築、可用性、スケーラビリティを確保するための選択肢が広がります。 Amazon Aurora は、ハイエンドな商用データベースのパフォーマンスと可用性、オープンソースデータベースのシンプルさとコスト効率性を兼ね備えています。Amazon Aurora は、一般的な PostgreSQL データベースと比べてパフォーマンスが最大 3 倍であり、さらにより高いスケーラビリティ、耐用性、およびセキュリティを備えています。詳しくは、Amazon Aurora の製品ページをご覧ください。リージョンごとのサポート状況については、製品およびサービス一覧をご覧ください。 Recent Updates 2018年に入り、RDS for PostgreSQL からの移行に関して機能が追加されています。 Amazon RDS for PostgreSQL のリードレプリカとして Aurora PostgreSQL レプリカの作成:これにより、スナップショットからの移行に比べてよりダウンタイムの短い移行が実現できます。 暗号化されたスナップショットからの移行:これにより暗号化された状態を維持したまま、 RDS for PostgreSQL インスタンスからの移行が可能です。 移行について 既存のデータベースからの移行については、その運用環境に基づいて、いくつかの選択肢が考えられます。RDS for PostgreSQL をご利用の場合、AWS が提供する機能を利用して移行できます。上記のアップデートでも紹介しましたが、具体的には以下の通りです。 Aurora レプリカを利用した RDS for PostgreSQL からのレプリケーション RDS for PostgreSQL スナップショットからの移行 注意点として、上記の2つの機能を利用するためには、現在のところ RDS for […]

Read More