Amazon Web Services ブログ

MongoDB クラスターから Amazon DynamoDB へのライブマイグレーションの実行

あるデータベースから別のデータベースへのデータ移行は、データの整合性、アプリケーションのダウンタイム、ターゲットとソースデータベース間の重要な設計の違いに関して、相当難易度が高くなる場合があります。AWS Data Migration Service (AWS DMS) は、MongoDB、Oracle、MySQL、Microsoft SQL Server などのデータベースの素早く、安全で、シームレスな AWS への移行を支援します。ソースデータベースは移行中もほとんど動作し続けるため、データベースに依存するアプリケーションのダウンタイムを最小限に抑えることができます。 この記事では、シャーディングされた MongoDB クラスターのライブデータを Amazon DynamoDB のテーブルにシームレスに移行するためのアプローチを説明します。Amazon DynamoDB は、あらゆる規模で一貫性のある 1 桁ミリ秒台のレイテンシーが必要なアプリケーション向けの、完全マネージド型、高速、スケーラブル、柔軟なクラウドデータベースサービスです。この記事で説明されているアプローチは、ほぼダウンタイム無しで移行を実施し、AWS DMS を使用してソースデータを変換し、少数のアクセスパターンを提供します。 DynamoDB と MongoDB のコンポーネント間のマッピング 移行を実施する前に、Amazon DynamoDB と MongoDB のコンポーネントを簡単に比較してみましょう。DynamoDB と MongoDB の多くのコンセプトは類似しており、どちらも JSON のようなデータを柔軟でダイナミックなスキーマでアプリケーションに保存することができますが、いくつかの点で大きく異なります。 このセクションでは、DynamoDB のコアコンセプトをいくつか説明し、DynamoDB と MongoDB のコンポーネントを比較します。MongoDB のコンセプトの詳細については、MongoDB のマニュアルを参照してください。 主要なコンポーネント Amazon DynamoDB で用いる主要なコンポーネントは、テーブル、項目、および属性です。テーブルは項目の集合であり、各項目は属性の集合です。DynamoDB では、テーブルのアイテムを一意に識別するためプライマリキーを使用し、クエリの柔軟性を高めるためにセカンダリインデックスを使用しています。各テーブルはそれぞれに対応するインデックス、キャパシティー、スケーラビリティの設定がある分離されたユニットです。DynamoDB と MongoDB は、どちらもデータセットを項目の集合に分割することが可能です。 以下の表は DynamoDB […]

Read More

Amazon EC2 テストポリシー

ネットワークストレステスト 【日本語訳】日本時間 2018年02月08日09:00 このポリシーは、お客様の Amazon EC2 インスタンスから、他の Amazon EC2 インスタンス、AWS プロパティ/サービス、外部エンドポイントのような他の場所へ、大規模なネットワークテストを直接実施することを計画しているお客様に関係するものです。 これらのテストは、ストレステストや負荷テスト、ゲームデーテストと呼ばれることがあります。このポリシーでは、テストにおいて正当な大規模トラフィックあるいはテストトラフィックを特定の対象アプリケーションに対し送信する行為を「ネットワークストレステスト」とします。エンドポイントとインフラストラクチャは、このトラフィックを処理できる必要があります。 このポリシーは、通常のプロダクションのトラフィックとは関係ありません。ネットワークストレステストは、多くの場合、特定のエンドポイントを対象とし、送信元や対象が集中することを含め、通常とは異なるトラフィックパターンを持ち、持続的に大規模なトラフィックが発生し、予期している上限値を超える可能性があるため、通常のプロダクションとは異なります。ネットワークストレステストにおけるこれらの違いは、外部エンドポイント、他のお客様、AWS サービスに対し意図しない影響を与えうる潜在的なリスクとなります。 パケットや接続のフラッディング、それ以外の大規模なトラフィックで、ターゲットやインフラストラクチャへ意図的に過大な負荷をかけるテストは、ネットワークストレステストではなく、分散型 DoS (DDoS) テストとして扱われます。ボリュームのあるネットワークベースの DDoS シミュレーションは、Amazon EC2 プラットフォームでは明示的に禁止されています。このポリシーは、https://aws.amazon.com/security/penetration-testing の範囲のセキュリティやペネトレーションテストは対象としません。 ほとんどのお客様はこのポリシーには該当しません。通常、ユニットテストのように大規模なワークロードをシミュレートするストレステストでは、ネットワークストレステストに該当するだけのトラフィックは生成されません。このポリシーは、お客様のネットワークストレステストによって、Amazon EC2 インスタンスで以下の基準を満たすトラフィックが生成されたときに適用されます。”持続的に 1分以上の間 1 Gbps(秒間 1億ビット)あるいは 1Gpps(秒間 1億パケット)を超えるトラフィック、悪用目的や悪意があるように見えるトラフィック、テスト対象以外(ルーティングや共有サービスのインフラストラクチャなど)へ潜在的に影響を及ぼしうるトラフィック” などが該当します。 お客様は、対象のエンドポイントへのテストが承認され、その起こりうる規模について理解している必要があります。いくつかの外部エンドポイントや AWS サービスは、ある種のテストシナリオに対して期待する閾値よりも低い性能しか発揮できない可能性があります。 AWS を利用する多くのお客様は通常のプロダクションモードで定期的に 1Gbps もしくは 1Gpps 以上のトラフィックを生成していることを確認しております。これは完全に正常であり、特にネットワークストレステストの目的のために実施されたものではない限り、このポリシーの範囲下ではありません。 このポリシーの基準を満たすネットワークストレステストにはリスクがあります。お客様が悪質であると検知され報告されるリスク、お客様が意図せず悪質となり他の対象に影響を及ぼすリスク、お客様が所有するインスタンスで機能制限を受ける可能性などがあり、この際にはテストだけではなく、プロダクションのワークロードへ影響する可能性があります。 実施するテストがこれらの基準を満たすか、お客様で不明な場合は、このポリシーに従い、AWS 側にテストの評価を依頼する必要があります。お客様の体験や、その他の影響を受ける可能性があるサービスを改善していくため、これらのストレステストを実行する前には、Amazon EC2 ネットワークストレステストを申し込みフォームから申請してください。このフォームは aws-security-simulated-event@amazon.com へメールを送ることで入手できます。 お客様のネットワークストレステストが 外部や他の AWS サービスのような EC2 インスタンス以外から直接実行される場合、フォームからの申請が必要かどうかメールでお問い合わせください。 […]

Read More

AWS Cloudtrail Logs を AWS Glue と Amazon Quicksight 使って可視化する

AWS CloudTrail ログを簡単に視覚化できることは、AWS インフラストラクチャがどのように使用されているかについてより良い理解を提供してくれます。また、AWS API コールの監査とレビューを行って、AWS アカウント内のセキュリティ異常を検知するためにも役立ちます。これを行うには、CloudTrail ログに基づいた分析を実行できる必要があります。 この記事では、Amazon S3 内の AWS CloudTrail ログを JSON 形式からクエリ用に最適化された形式のデータセットに変換するための AWS Glue と AWS Lambda の使用について詳しく説明します。その後、Amazon Athena と Amazon QuickSight を使用してデータをクエリし、視覚化します。 ソリューションの概要 CloudTrail ログを処理するには、以下のアーキテクチャを実装する必要があります。 CloudTrail は Amazon S3 バケットフォルダにログファイルを配信します。これらのログを正しくクロールするには、S3 バケットの単一フォルダ内に変換済みファイルを格納する Amazon S3 によってトリガーされる Lambda 関数を使ってファイルコンテンツとフォルダ構造を変更します。ファイルが単一のフォルダ内にある場合、AWS Glue はデータをスキャンし、それを Apache Parquet フォーマットに変換して、Amazon Athena と Amazon QuickSight を使用したクエリと視覚化を可能にするためにカタログ登録します。   チュートリアル ソリューションを構築するために必要なステップを見て行きましょう。 CloudTrail ログのセットアップ 最初に、S3 バケットにログファイルを配信する証跡をセットアップする必要があります。CloudTrail […]

Read More

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 Schema Conversion Tool によるTrimble社のデータベース移行を成功させた秘訣とは’s データベース移行の成功

Trimble 社の フィールドサービス管理部門 (FSM) でインフラストラクチャ運用部のディレクターである Todd Hofert 氏による寄稿。 状況 最近、 Trimble 社のフィールドサービス管理部門のインフラストラクチャ運用グループは、非公開でホストされている SaaS サービスをアマゾン ウェブ サービス (AWS) に移行する積極的な取り組みに着手しました。同部門は、ハードウェアのリフレッシュ、継続的なコスト削減の必要性、 AWS 上の同社の次世代プラットフォームと従来の商品を調和させたいという必要性に直面しました。これに対応して、 Trimble 社のインフラストラクチャチームは、データウェアハウスソリューションから始まる包括的な移行計画を策定しました。 コスト削減、可用性、スケーラビリティは、 AWS イニシアチブへの主な推進力でした。Trimble 社は、Oracle からオープンソースデータベースプラットフォームに移行することで、現在のライセンスコストを最適化することに決めました。また Trimble 社は、 Amazon RDS を使用してデータベースを動作させることで、信頼性を保証し、運用サポートの間接費を削減することにも力を入れました。 データベースの選択 Trimble 社の運用とデータベース開発チームは、 AWS チームを招き入れて、 Oracle から離れたデータベースプラットフォームへの移行に関する難易度を調べました。この評価の中心となったのは、 AWS Schema Conversion Tool (AWS SCT) 評価レポートでした。 Trimble 社のチームは AWS SCT を使用して、ソースである Oracle データベースと Amazon Relational […]

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