Author: AWS Japan

MySQLは素晴らしいオープンソースデータベースエンジンで、そのコスト効率から多くの企業で使われています。しかし、その他のオープンソースデータベースと同様に、ビジネスで使えるレベルの性能を出すには多くの労力が必要です。 データベースサイズが増えるとMySQLのスケーラビリティとクラッシュリカバリの複雑さも増します。レプリケーションスレーブを追加することでMySQLデータベースをスケールさせると、特にMySQLマスターで多くの書き込みが発生した場合に、レプリケーションラグを非常にに小さな値で維持することは困難を伴います。ほとんどの場合、安定したパフォーマンスを維持することは難しいです。 一方、Amazon Aurora では最大15個のリードレプリカを追加できます。また、書き込みノードで発生した変更を再実行するために必要な従来のバイナリログ (binlog) レプリケーションのパフォーマンスをAuroraでは気にする必要がなくなります。これはAuroraクラスターボリューム内のデータは、クラスター内のライターとリーダーに対して単一の論理ボリュームとして見えるためです。 多数のテーブルを含む大規模なデータベースでの高速リカバリも Amazon Aurora の重要な利点の一つです。従来のMySQLの実装では、データベースが大きくなるにつれてリカバリ時間が長くなります。MySQLはREDOログファイルを使用するため、クラッシュするとMySQLはテーブルの検出や検証オペレーションを大量に実行します。データベースの表領域が大きいほど、リカバリに必要な時間は長くなります。この影響は MySQL 5.7 でも当てはまります。 このような要因から、MySQLから Amazon Aurora への移行に関心が集まっています。この移行を実行するにはいくつかの方法がありますが、今回は Amazon RDS for MySQL またはオンプレミスや Amazon EC2 上のMySQLから Amazon Aurora with MySQL compatibility への同種間移行について考えます。 同種間移行の方法 AWSホワイトペーパーのサイトにある Amazon Aurora Migration Handbook で同種間移行のための推奨方法がリストされています。Amazon RDS for MySQL から移行するのであれば、RDSスナップショットでの移行方法を使用できます。この方法では、RDS MySQL のDBインスタンスのスナップショットから Aurora MySQL DB クラスターを作成します。これは非常に簡単です。Amazon Aurora へニアゼロダウンタイムで移行した場合は、ソースとなる RDS MySQL DBインスタンスからAuroraリードレプリカを作ることができます。RDSが Amazon Aurora […]

ネットワークストレステスト 【日本語訳】日本時間 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 インスタンス以外から直接実行される場合、フォームからの申請が必要かどうかメールでお問い合わせください。 […]

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 […]

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” }, […]

この記事は、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 […]

本日 日本で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 資産に対する追加の対策として、国内に地域的な多様性を重要視するお客さまは […]

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実行時間の改善 […]

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 […]

2017年5月30日、昨今の IT 技術の飛躍的に進歩に伴い、様々な個人情報の利活用の現状を踏まえ、改正個人情報保護法が全面施行されました。個人情報の取り扱いに関する義務が明確になりましたが、一方でクラウドをご利用する上で配慮すべき点が増え、考慮されているお客様もいらっしゃるかと思います。そのようなお客様の声にお答えするために、お客様が自身のクラウド利用を検討していく際の参考資料として「日本におけるプライバシーに関する考慮事項に照らした AWS の利用」（ホワイトペーパー）を準備し、コンプライアンスのリソースページにて公開しました。本ホワイトペーパーは、今回の改正個人情報保護法に沿った内容となっており、お客様がご自身の IT インフラストラクチャを AWS へ移行する際の主な検討事項となる以下の点について解説しています。   • コンテンツのセキュリティをどのように担保していくのか? • コンテンツはどこに保存されるのか? • コンテンツにアクセスできるのは誰か? • どのような法令がコンテンツに適用され、これらを遵守するには何が必要か?   上記のようなお客様がクラウドのセキュリティやプライバシーについて検討いただく際に、最も重要となるのが「責任共有モデル」についての理解です。AWS はクラウドサービスにおけるインフラストラクチャ自体のセキュリティについて責任を持ちます。一方で、お客様はサービス利用に際して法令を遵守し、併せて当該クラウド環境の上に構築するサービス、オプションの構成やデータ保護のための追加の構成等によりご自身のコンテンツについてのセキュリティを確保するという責任を持つことになります。AWS ではこのようにお客様と AWS の２者でシステム全体の統制やセキュリティを担保していくモデルを「責任共有モデル」と呼んでいます。詳しくは本ホワイトペーパーの「クラウドセキュリティの管理に対する AWS 責任共有の考え方」をご参照ください。   また、AWS のサービスをご利用いただく際に、お客様のコンテンツの所有権と管理権はお客様に保有することになり、AWS にコンテンツの所有権と管理権が移るようなことはありません。したがって、コンテンツの性質やセキュリティ要件に応じたセキュリティの強度レベルを決定できるのはお客様自身となります。お客様が AWS サービスをどのように構成し、アクセス権をどのように付与し、どのリージョンを使用するか等の個別な設定については、お客様の判断と責任の下でコントロールしていただくことになります。（どのような場合に AWS がお客様のコンテンツにアクセスをする可能性があるかにつきましては、「カスタマーコンテンツにアクセスできるのは誰か？」をご参照ください。）   一方、AWS のクラウドサービスのインフラストラクチャーに関するセキュリティを確保するのは AWS の責任です。例えば、AWS はファシリティ、物理セキュリティ、物理インフラ、ネットワークインフラ、仮想インフラの管理につき責任を負います。セキュリティは、AWS における最優先事項です。セキュリティに対する継続的な投資を行い、セキュリティ専門部隊を設置しています。併せて、お客様が安心して AWS のサービスをご利用いただけるよう幅広いセキュリティ機能、ツールを備え、お客様に提供しています。AWS のサービスとインフラストラクチャーは、セキュリティコントロールの設計及び運用についての有効性を証明する、数多くの認定・認証・監査に関連して第三者からの評価を受けており、機密保持契約に基づき AWS Artifact を通じてオンラインにて直接確認いただくことが可能です。（AWS Service Organization Control(SOC) 1、SOC2、PCI DSS7 コンプライアンスレポート等。ISO27001, ISO27017, ISO27018, […]

AWS IoT Coreサービスで、ポート443でTLSクライアント認証を使用してMQTTを使用してデバイスを接続できるようになりました。この機能を利用してどのようにデバイスを接続するのかを知るには次をお読みください、デバイス接続方法についてを知るには最後のセクションをお読みください。 443, 8883 -違い TCP接続は通常、IPアドレスとポート番号の組み合わせの関連付けがなされています。そのために、アプリケーションが他のサードパーティのアプリケーションと通信できるようにするためには、使用するポート番号の問い合わせが発生します。これを解決するために Internet Assigned Numbers Authority(IANA)は 、組織に登録されているTCPとUDPの様々なメッセージプロトコルに対するマッピングを維持管理しています。これは標準的なリストではありませんが、広く採用されています。データベースのクイック検索では、ポート443はHTTP over TLSとして登録済みのポートであり、8883はMQTT over TLSとして登録済みのポートです。 AWS IoT Coreはこれらの規格を可能な限り遵守していますが、これを逸脱するシナリオがあることをお客様から学びました。