Amazon Web Services ブログ

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

Amazon SageMaker で増分学習を簡単に実行する

 データ科学者および開発者は、Amazon SageMaker で増分学習を簡単に実行できるようになりました。増分学習は、既存のモデルの知識を新しいデータでさらにトレーニングすることによって拡張する機械学習 (ML) 技術です。今日から、Amazon SageMaker 組み込みビジュアル認識アルゴリズム、画像分類とオブジェクト検出のどちらもが、増分学習をすぐにサポートできるようになります。したがって、新しいデータのモデルトレーニングを開始する前に、AWS マネジメントコンソールまたは Amazon SageMaker Python SDK API を使用して、既存の Amazon SageMaker ビジュアル認識モデルを簡単にロードすることができます。 概要 増分学習は、既存の機械学習モデルの知識を新しいデータでさらにトレーニングすることによって継続的に拡張する技術です。したがって、訓練の開始時には、最初に無作為に初期化するのではなく、以前トレーニングを実行して得られたモデルの重みをロードしてから、新しいデータでモデルをさらにトレーニングし続けます。このようにして、以前トレーニングを実行してモデルが得た知識を保持し、それをさらに拡張します。これは、すべてのトレーニングデータに同時にアクセスすることができず、データはバッチ単位で経時的に取得し続ける場合に役立ちます。この学習テクニックを使用して、新しいトレーニングデータでモデルを再トレーニングするときに時間を節約し、リソースを計算することもできます。 このブログ記事では、Amazon SageMaker の増分学習機能を使用して転移学習を実行する方法についても説明します。説明する際は、既存のモデルをシェルフから取り出して使用します。モデルズーから画像分類モデルを選択し、新しい分類タスクを実行するためのモデルをトレーニングする出発点として使用します。転移学習は、特定の機械学習タスクに対して最先端のリファレンスを実装した上で新しいモデルを構築することを可能にします。これは、深く複雑なネットワークを最初からトレーニングするのに十分なデータがない場合にも役立ちます。 では、例を見てみましょう。 Amazon SageMaker の組み込みアルゴリズムを使用してビジュアル認識モデルを段階的にトレーニングする Amazon SageMaker のビジュアル認識アルゴリズム、画像分類とオブジェクト検出の両方で、増分学習をサポートするサンプルノートブックを用意しました。次に、Image Classification ノートブックのコードスニペットを示します。初めて Amazon SageMaker Image Classification モデルをトレーニングする場合、ノートブックにはステップバイステップの手順が記載されています。この例では、Amazon SageMaker で以前にトレーニングした既存の Image Classification モデルが既にあるとします。 ステップ 1: 既存の Amazon SageMaker Image Classification モデルを使用するための入力チャネルを定義する。 Amazon SageMaker チャネルは、トレーニングアルゴリズムが使用できる名前付き入力データソースです。この入力チャネルは “model” という名前でなければならず、既存モデルの […]

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

AWS Lambda、Amazon Route 53、および Amazon SNS を使用して、Redis クラスター用 Amazon ElastiCache (クラスターモードが無効) のリードレプリカエンドポイントを監視します

 Redis 用 Amazon ElastiCache では、アプリケーションが指定されたエンドポイントを使用して ElastiCache ノードまたはクラスタに接続します。Redis 用 ElastiCache ユーザーガイドのRedis 用 ElastiCache コンポーネントと機能によると、複数のノードを持つ Redis (クラスターモード無効) クラスターには次の 2 種類のエンドポイントがあります。 「プライマリエンドポイントは、プライマリロール内の特定のノードが変更された場合でも、常にクラスタ内のプライマリノードに接続します。クラスターへのすべての書き込みにプライマリエンドポイントを使用します。Redis (クラスターモードが無効) クラスターの読み取りエンドポイントは、常に特定のノードを示します。リードレプリカを追加または削除するときは、アプリケーションで関連するノードエンドポイントを更新する必要があります。」 Redis 用 ElastiCache のプライマリエンドポイント機能は、プライマリノードエンドポイントを解決する際に常に一貫性を提供します。AWS の顧客はこの機能を高く評価しています。 「ElastiCache Redis の便利な機能は、クラスターの現在のプライマリノードを常に示す、プライマリエンドポイントを利用できる点です。このエンドポイントは、クラスターにフェイルオーバーが発生しても変更されません。したがって、プライマリノードが変更されてもアプリケーションを変更する必要はありません。この機能は、自動フェイルオーバーが発生した場合に特に役立ちます。」—AWS の顧客 ベストプラクティスとして、およびワークロードバランシングのため、リードレプリカに読み取りリクエストを送信する必要があります。ただし、フェイルオーバーが発生した場合は、以前に使用したリードレプリカをプライマリロールに昇格させることができます。読み取りリクエストを同じエンドポイントに送信し続けると、新しいプライマリ (古いリードレプリカ) の負荷が増える可能性があります。この場合、フェイルオーバー発生後であっても、常にレプリカを示すリードレプリカエンドポイントがあると便利です。 これを行うには、リードレプリカエンドポイントの監視および更新が可能な AWS Lambda 関数を設定します。この目的は、Amazon Route 53 のプライベートゾーンにある各リードレプリカに対してカスタムの CNAME を作成して使用し、これらの CNAME を Redis のクライアントで使用することです。 フェイルオーバーが発生すると、Amazon Simple Notification Service (Amazon SNS) トピックにプッシュ通知が配信されます。この SNS […]

Read More