Amazon Web Services ブログ

RDS データベースに汎用 IOPS またはプロビジョンド IOPS のどちらを使用するかを決定するための CloudWatch メトリクスの使用方法

 このブログ記事では、最高のパフォーマンスのミッションクリティカルなデータベースワークロードに対して、IO1 としても知られるプロビジョンド IOPS からメリットを得ることができる機会を把握するために Amazon CloudWatch メトリクスを使用する方法について説明します。まず、バーストを生じない一貫性のある高書き込みワークロードをシミュレートするテストケースをセットアップすることから始めます。今回は、価格とパフォーマンスのバランスを保つ、GP2 ボリュームとしても知られる汎用ストレージを使ったデータベースと、IO1 ボリュームを使ったデータベースのパフォーマンスを比較します。次に、対応する CloudWatch メトリクスが明らかにする事柄と、ワークロードのパフォーマンス結果をご覧いただきます。 数ヵ月前、GP2 ボリュームでのバーストバランスとベースラインパフォーマンスを説明する Understanding burst vs. baseline performance with Amazon RDS and GP2 という素晴らしいブログ記事が AWS データベースブログに掲載されました。GP2 ボリュームはプロビジョニングが簡単で使いやすく、低価格です。これは、GP2 ボリュームが必要時にパフォーマンスをバーストさせ、散発的なワークロード、または待機時間が発生する可能性を許容できるアプリケーションを上手く処理できることが理由です。開発、機能テスト、およびサンドボックスなどの環境では、偶発的な負担がかかる場合でさえも GP2 の使用には何ら問題がありません。絶えず負担がかかるデータベースワークロードについては、プロビジョンド IOPS ボリュームがプロビジョニングするレベルでの持続的なパフォーマンスとスループットを提供します。 前提条件 始める前に、先ほど紹介した GP2 バーストパフォーマンスについてのブログ記事、Understanding burst vs. baseline performance with Amazon RDS and GP2 を十分に検討してください。 この記事にあるコードを一通り実行したい場合は、アカウント内に同一の Amazon RDS for MySQL データベースを 2 つ作成してください。ひとつのインスタンスには […]

Read More

Amazon SQS のFIFO機能が東京リージョンでもご利用いただけるようになりました

みなさん、こんにちは。アマゾン ウェブ サービス、プロダクトマーケティング エバンジェリストの亀田です。 非常に多くのユーザーさんからご要望をいただいていた Amazon SQS のFIFO (First In First Out)機能が東京リージョンでご利用いただける用になりましたのでお知らせいたします。 Amazon SQSの特徴 Amazon SQSは完全マネージド型のメッセージキューイングサービスで、マイクロサービス、分散システム、およびサーバーレスアプリケーションの切り離しとスケーリングを可能とします。 AWS上でのアプリケーション設計において、非常に重要な役割を果たすサービスである一方、そのコンセプトなどが従来の一般的なWEBサービス(以下のような構成です)の設計に頻繁に用いられるものではないことから、使い方のイメージが湧きづらく敬遠されるケースもあります。 非常に良いサービスであり、コストの適正化とシステムの耐障害性を実現することができる可能性のあるサービスですので、少しその特徴を説明します。 コストの適正化: 上記のアーキテクチャを取る場合、ユーザーからのリクエスト数が増えれば増えるほど、WEB、DBともに求められるスペックは比例して向上していきます。これは、すべてのリクエストに対して同期処理、リアルタイムでレスポンスを出力しようとするためです。WEBサービスにおいては、すべてのリクエストが必ずしも同期処理、リアルタイムでのレスポンス出力が必要ないケースがあります。 ECサイトにおけるユーザーからの注文等がその一例です。ユーザーからの注文を受け付けた時点で、画面には「注文を受け付けました。ありがとうございました」と表示させ、後ほどメールやアプリへのプッシュ通知で「注文を確定しました」という連絡をユーザーへ行う実装などはよくあります。 この場合、上記のWEBをさらに2階層に分割し、 1階層目:ユーザーからのリクエストを受け付ける。 SQSへリクエストを書き込む ユーザーへリクエスト受付を行った旨をレスポンスで戻す。 2階層目:SQSに記載されているリクエストを処理する SQSからリクエストを読み込む リクエストを処理ユーザに非同期で処理結果を返す。 とすることができます。この場合、ユーザー数、リクエスト数の増加に応じて求められるスペックの向上が必要なのは、1階層目だけであり、2階層目は自身のコンピュートリソースの状況に応じて任意のタイミングで処理を行うことができるため、システムのサイジングを適切に保つことができます。(もちろんSQSへ書き込まれるリクエストが処理待ち状態で滞留すればするほど、ユーザーからは処理確定の遅延にみえてしまいますので、ある程度のリソース増強は必要になっていきます。) 耐障害性の向上: SQSを採用したアーキテクチャは耐障害性の向上も見込むことができます。SQSは完全マネージド型サービスであり、書き込まれたメッセージが失われることはないため、システム障害においても、SQSからデータを取り出すという処理部分から再開させることで、耐障害性が向上します。 SQS FIFOの特徴 従来のAmazon SQSは、書き込まれたメッセージの配信順序はベストエフォート型であり、「少なくとも最低1回の配信」をサポートしておりました。このため、順番の入れ違いや同じメッセージの複数回配信はアプリケーション側で冪等性を確保しておく必要があり、それらが大きい課題となる場合Amazon Kinesis Data Streamsの利用などが検討されるケースもありました。 新しいSQS FIFO キューでは、「メッセージが送信される順序のとおりに 1 回のみ確実に処理」されるようになるため、アプリケーションでの実装におけるこの考慮点が解消されることとなります。 FIFOキュー利用の注意点 SQS FIFOキューは従来のSQS標準キューからの移行をサポートしておらず、新規でキューの作成が必要となります。 デフォルトでは、FIFO キューはバッチ処理により 1 秒あたり最大 3,000 件のメッセージをサポートします。制限の引き上げをリクエストする場合は、サポートリクエストを提出してください。 バッチ処理なしでは、FIFO キューは、1 秒あたり最大 […]

Read More

Amazon SageMaker を使用した K-means クラスタリング

Amazon SageMaker は、さまざまな問題の種類で使用できる組み込み機械学習 (ML) アルゴリズムを複数提供しています。これらのアルゴリズムは、高性能でスケーラブルな機械学習を提供し、速度、スケール、精度が最適化されています。 これらのアルゴリズムを使用して、ペタバイト規模のデータを学習できます。これらは、利用可能な他の実装の最高 10 倍のパフォーマンスを提供するように設計されています。このブログ記事では、教師なし学習の問題である k-means について探っていきます。さらに、Amazon SageMaker の組み込み k-means アルゴリズムの詳細も説明します。 k-means とは? k-means アルゴリズムは、グループのメンバーがお互いにできる限り類似し、他のグループメンバーとできる限り異なるようなデータ内の離散グループを探します (以下の図を参照)。アルゴリズムで類似性を決定するために使用する属性を定義します。  k-means を定義するもう 1 つの方法は、クラスター内のすべての点が、他の中心よりもその中心に近い距離になるように、与えられたレコードセットに対して、k クラスター中心を見つけるクラスター問題です。 与えられたデータセットを示すこの図では、赤、青、緑の 3 つの明確なクラスターが見えます。各クラスターにはクラスター中心があります。各クラスターの点は、他のクラスター中心より、割り当てられているクラスター中心に空間的に近いことに注意してください。  数学的には、以下のように解釈できます。 前提条件: S={x1…xn}、次元 d の n ベクトルのセット S と整数 k 目標: 以下の式を最小化する、k クラスターセンターのセット C={µ1… µk } を探します。 k-means を使う場所  k-means アルゴリズムは、明示的にラベル付されていない、大きなデータセットのパターンまたはグループを見つけることに適しています。さまざまなドメインでのいくつかのユースケースを紹介します。 E コマース 購入履歴またはクリックストリームアクティビティで顧客を分類。 ヘルスケア 病気のパターン検出または成功する治療シナリオ。 画像検出で類似画像をグループ化する。 金融 データセットの異常検知により、不正取引を検出。例えば異常な購入パターンによるクレジットカード詐欺の検出。 […]

Read More

Amazon Aurora PostgreSQL によるフェイルオーバー

レプリケーション、フェイルオーバー、レジリエンス、災害対策、バックアップ—従来の、または非クラウドベースのアーキテクチャでは、これらの一部またはすべてを実現するのはとても困難です。さらに、時にはかなりのリエンジニアリング作業が必要になることがあります。関係する実装やインフラストラクチャのコストが高いため、一部の企業では最も重要なアプリケーションのみが適切に保護されるようにアプリケーションを階層化せざるを得ません。 こうした懸念は、Amazon Aurora for PostgreSQL に移行すること軽減できます。AWS は、Oracle、MySQL、PostgreSQL、Aurora を含む (ただしこれらに限定されない) 幅広い種類のリレーショナルデータベースエンジンを提供しています。PostgreSQL の場合、AWS は Amazon EC2 インスタンスでの PostgreSQL、Amazon RDS for PostgreSQL、Amazon Aurora with PostgreSQL compatibility を含むさまざなバリエーションをサポートしています。適切なバージョンの PostgreSQL を選択するための多くの指標の中で、以下のいくつかが重要です。 高可用性 (HA) パフォーマンス 管理のしやすさ それでは、Amazon Aurora PostgreSQL がこうした基準をどのように満たしているかを掘り下げてみましょう。 高可用性: HA は、Aurora PostgreSQL のアーキテクチャに組み込まれており、3 つのアベイラビリティーゾーンにわたって 6 つのデータコピーが維持されています。つまり、アベイラビリティーゾーンごとに 2 つのコピーがあることになり、いずれかのアベイラビリティーゾーン全体がダウンしてもわずかな中断で済むことから可用性が向上します。さらに、データベースは Amazon S3 に継続的にバックアップされるため、S3 の高耐久性 (99.999999999) をバックアップで利用できます。Aurora PostgreSQL は、ポイントインタイムリカバリもサポートしています。 パフォーマンス: Amazon Aurora […]

Read More

AWS、ヘルスケア顧客向けの HIPAA 適格 machine learning サービスを拡大

 今日 AWS は、Amazon Translate、Amazon Comprehend、そしてAmazon Transcribe が米国版になったことを発表しました。1966 年の健康保険の携帯性と説明責任に関する法律 (HIPAA) 対象サービス。この発表は、HIPAA の対象となる AWS 人工知能サービスである Amazon Polly、Amazon SageMaker、そして Amazon Rekognition の数を増やしています。これらのサービスを使用することで、医療業界の AWS 顧客は、データ見識を活用し machine learning (ML) の力を利用することで、プロバイダーと患者にとってより良い成果をもたらすことができます。 ヘルスケア顧客をサポートするために、AWS HIPAA の対象となるサービスは、対象となる事業体および HIPAA の対象となる事業者が保護された健康情報の処理、保守、保管に安全な AWS 環境を使用することを可能にします。NextGen Healthcare、Omada Health、Verge Health、そして Orion Health などのヘルスケア企業では、既に多数の患者の記録を分析するために、AWS 上の HIPAA ワークロードが実行されています。 HIPAA 対象サービスのリストに Amazon Translate、Amazon Transcribe、そして Amazon Comprehend を追加することで、顧客はこれらの AWS ML サービスを活用して、顧客サポートの合理化と患者エンゲージメントの向上を図ることができます。顧客はこれら 3 つのサービスを利用して、以下の […]

Read More

今すぐ利用可能 – AWS Marketplaceの新しいRHEL for SAP with HA and US

SAP HANAを含むSAPワークロードをAWS上で簡単に実行できるように、AWSとレッドハットは長い間協力しており、お客様には2つの選択肢があります。AWS MarketplaceのRed Hat Enterprise Linux (RHEL) for SAP HANAのAmazon Machine Image (AMI)を使用して、オンデマンドのRHEL上で様々なSAPワークロードを実行できます。あるいは、Red Hat Cloud Accessプログラムで利用可能なBring Your Own Subscription (BYOS)モデルのイメージを使用することもできます。

Read More

グラフ化なら、おまかせください (パート 1 – 航空ルートの事例)

Amazon Neptune に関する記事を複数回に分けてお届けします。本シリーズ記事で、グラフアプリケーションデータセットと、多数の異なるドメインおよび問題空間から取り出されたクエリを探求します。 Amazon Neptune は高速で信頼性が高い完全マネージド型グラフデータベースで、高度に連結されたデータの保存およびクエリ実行のために最適化されています。高度に連結されたデータを使用するオンラインアプリケーションでは、接続をナビゲートし、エンティティ同士のリレーションシップの強度、重要性または品質を活用できるような接続性能がクエリの仕事量で求められますが、まさに理想的な用途と言えます。皆さんは、こんな問いかけに遭遇したことがおありだと思います。 私たちに共通の友人や仲間はいる? あるネットワークエレメント、たとえばルーターやスイッチが故障すると、自分のネットワーク内でその影響がおよぶアプリケーションやサービスはどれ? ネットワークに最重要顧客用の冗長性はある? 2 つの駅を地下道を使って行き来する最短ルートはどれ? このお客様に次に買うもの、次に見るもの、次に聞くものをあなたがすすめるとしたら、何を? ユーザーがアクセスしたり変更したりする権限がある製品、サービス、サブスクリプションはどれ? この荷物を A 地点から B 地点に届けるのに最安または最速の方法は? 銀行または保険会社に共謀して詐欺をはたらきそうな連中グループはどれ? これで、高度に連結されたデータの管理および意味を理解する必要性にすでにお気づきだと思います。 本シリーズ記事はまず、世界のエアラインの運航ネットワークをモデリングしたオープンソースの航空路データセットで始めることにします。このデータセットには Practical Gremlin というブックが付属しています。 本シリーズ記事の事例はすべて、Analyze Amazon Neptune Graphs using Amazon SageMaker Jupyter Notebooks で記述されている Amazon SageMaker および Neptune の統合ソリューションを使用した Jupyter ノートブックとして提供します。各ノートブックには、サンプルデータおよびクエリ、ならびにデータモデル上の解説と本アプリケーションのユースケースに対応するクエリ設計テクニックが含まれています。 航空路データセットの起動 次の表で、[Launch Stack] ボタンの1つを選択して、AWS CloudFormation コンソールから Neptune-SageMaker スタックを起動します。チェックボックスを選択して、AWS CloudFormation が IAM リソースを作成することを確認します。 次に、[Create] を選択します。 […]

Read More

専用の AWS Glue VPC を使用して複数の VPC 間で ETL ジョブに接続し、実行する

多くの組織では、Amazon VPC サービスに基づく複数の VPC を含む設定を使用し、セキュリティ、監査、コンプライアンス目的で個別の VPC で隔離されたデータベースが使用されます。このブログ記事では AWS Glue を使用して、複数の VPC にあるデータベースで、抽出、変換、ロード (ETL)、クローラー操作を実行する方法を示します。 ここで紹介するソリューションは、専用の AWS Glue VPC とサブネットを使用して、異なる VPC に配置されたデータベースに対して次の操作を実行します。 シナリオ 1: Amazon RDS for MySQL データベースからデータを取り込み、これを AWS Glue で変換し、結果を Amazon Redshift データウェアハウスに出力します。 シナリオ 2: Amazon RDS for MySQL データベースからデータを取り込み、これを AWS Glue で変換し、結果を Amazon RDS for PostgreSQL データベースに出力します。 このブログ記事では、1 つの VPC の 1 つのソースから消費し、別の VPC […]

Read More

ソートキーを使用して、Amazon DynamoDB でデータを編成する

 Amazon DynamoDB テーブルにデータを入力することは難しくありません。さらにデータの整理に頭を悩ませることなく、データ検索オプションを後で制限することができます。 データ検索のためのデータの編成とプランニングは、テーブルを設計する際に大切な手順のうちの一つです。適切なデータ編成がない場合、データを取得するための唯一のオプションは、パーティションキーによる検索かテーブルのフルスキャンしかありません。これらの検索方法では、テーブルは高価となり、パフォーマンスは限られたものになります。 この記事では、ソートキーを使用した、データを取得するための最適化テーブルの実際の例について検討します。ソートキーを使用すると、データをグループ化し編成するだけでなく、テーブル内の項目に対してクエリを実行する追加手段にもなります。 パーティションキーの簡単な紹介 データの編成方法についてよりよく理解するためには、データが DynamoDB に格納される方法を知っておくことが大切です。DynamoDB テーブルの各項目には、DynamoDB のドキュメントに記載されているように、テーブルのプライマリーキーを作成する必要があります。プライマリーキーは、パーティションキー、またはパーティションキーとソートキーの組み合わせです。プライマリーキーは、テーブル全体で固有のものでなければなりません。 パーティションキーのみをプライマリキーとして使用する場合、最適とはいえないパーティションキーを選択し、その結果、テーブルの全体的なパフォーマンスに影響する可能性があります。例えば、同じプライマリキーを頻繁に取得すると、スループットが超過した例外が発生し、テーブルへのリクエストを抑制する可能性があります。 パーティションキーとそのベストプラクティスの詳細については、AWS データベースブログの「正しい DynamoDB パーティションキーの選択」の記事を参照してください。 ソートキーを使用して、データ検索オプションを拡張する 場合によっては、テーブルを作成する時に、プライマリキーとしてパーティションキーのみを提供する場合があります。このような場合、パーティションキーによるデータの取得、またはスキャン操作でテーブル内のすべての項目の返送に限定されます。このようにテーブルを作成するのは簡単で、場合によってはとてもシンプルです。 ただし、データセットが増加するにつれて、テーブルスキャンは価格とパフォーマンスの面で大きな負担となります。テーブルスキャンは、読み取り容量をすぐに使い果たしてしまうため、請求額が増加します。読み書きの容量単位、およびこれらの単位が DynamoDB 請求書に与える影響の詳細については、DynamoDB ドキュメントの「Amazon DynamoDB 料金表」と「読み書きの処理能力」を参照してください。さらに、パーティションキーだけで、項目の取得ができるとは限りません。特定の日付の前に顧客の注文を検索し、カテゴリーに一致するすべての商品を取得する例を考えてみましょう。ソートキーをテーブルに追加すると、スキャンやパーティションキーを利用する以上に、より多くのデータ検索機能が利用可能となります。 ソートキーは、クエリによって返される項目のソート順を決定するためだけのものではないことに留意しましょう。この記事が示すように、ソートキーは検索のために項目を直接ソートするのではなく、データ検索オプションを拡張します。 パーティションキーとソートキーを組み合わせると、コンポジットキーが作成され、それらのコンポジットキーはテーブル内の個々の項目のプライマリキーになります。コンポジットキーを使用すると、ソートキーに対して KeyConditionExpression でクエリを使用することが可能となります。クエリでは、KeyConditionExpression を用いて、キーに対して評価して返される項目を制限する比較演算子を利用し、条件文を記述できます。つまり、特殊演算子を使用して、項目をソートキー値でインクルード、除外、および照合することができるわけです。 ソートキーを使ってクエリを実行する例と、時間によってクエリを実行する例を、簡単に見てみましょう。特定のテーブルのソートキーが、数値として格納された Unix タイムスタンプであるとします。この場合、特定の時刻の前に < 比較演算子を使用して、すべての項目を返すというキー条件でクエリを発行できます。時間を限定した検索の例を、後ほど考察しましょう。 範囲を使う ソートキーに関連した範囲を使用して、クエリを作成します。KeyConditionExpressions クエリでは、次の演算子を使用できます。 = < > <= >= between begins_with between 演算子は範囲を決定するために 2 つの値を受け取り、begins_with 演算子は文字列が部分文字列で始まるかどうかを調べます。これらの演算子のほとんどは数値を使用できますが、beginning_with 演算子では面白い方法でデータをクエリできます。 例えば、場所をグループ化する方法を検討するとしましょう。米国では、場所は通常、都市、州、郡でグループ分けします。city-state-country のテンプレートを使用して、項目の場所を文字列に格納するソートキーを作成したとします。 city-state-country の順序は、場所データの最も具体的な部分から開始します。結果として、beginning_with […]

Read More

AWS Schema Conversion Tool ブログシリーズ: ビルド 617 の新機能紹介

 今回は、AWS Schema Conversion Tool (AWS SCT) 新バージョンをご紹介します。このバージョンには、テーブル値関数の変換のサポート、サーバーレベルの評価レポートへの追加情報などが含まれます。 AWS SCT とは、あるデータベースエンジン上の既存のデータベーススキーマを別のデータベースエンジン用に変換するためのツールです。リレーショナル OLTP スキーマやサポート対象のデータウェアハウス OLAP スキーマを Amazon RDS に変換することができます。たとえば、MySQL や PostgreSQL などと互換性があるため、Amazon Aurora に変換できます。また、リレーショナル OLTP スキーマやサポート対象のデータウェアハウス OLAP スキーマを Amazon Redshift に変換することも可能です。サポートされているすべてのソースおよびターゲットは、AWS SCT ドキュメントで確認できます。 以下に、この記事で説明するトピックの概要を示します。 Microsoft SQL Server から PostgreSQL へ – テーブル値関数の変換 SQL Server から PostgreSQL/MySQL へ – テーブル型変数の変換 SQL Server から PostgreSQL へ – MERGE ステートメントの実装 Oracle から […]

Read More