Amazon Web Services ブログ

Java と Amazon SageMaker Random Cut Forest アルゴリズムを使ってサーバーレスの異常検知ツールを構築する

ビジネスオーナーの方達が、共通して直面する問題の一つが、ビジネス上で普段と違う出来事に遭遇する、というものです。例えば、ユーザーが日ごろとは違う行動を取ったり、日々のトラフィックパターンに変化が起きるなどは、それらの問題の一部にすぎません。データやメトリクスが常に増加しつづける中、機械学習の力を借りて異常検知をすることは、積極的な問題特定のための、非常に有益な手法と言えます。 今回のブログでは、Amazon SageMaker と Java を使って、サーバーレスの異常検知ツールを作成する方法を解説していきます。Amazon SageMaker を使えば、機械学習モデルのトレーニングとホスティングを簡単に行え、ビルトインのアルゴリズムが、ビジネスに共通の問題を解決します。こういったビジネス上の特有な問題解決には、Random Cut Forest (RCF) 異常検知アルゴリズムを使います。Amazon Web Services ではお客様に、素早い対応力、低い IT コスト、そしてスケーリングなどを提供する、国際的なクラウドベースの製品を幅広く提案しています。ここでは、それらを使い、サーバーレスの異常検知ツールを構成する方法をご提示しましょう。Python は、機械学習の問題を追跡するための、最も普及したプログラミング言語の一つですが、多くのユーザーは、Java やその他の JVM ベース言語を使って、マイクロサービスやサーバーレスのアプリケーションを構築しているでしょう。このブログを読み終えた段階で、 お客様はAmazon SageMaker を使い、Java アプリケーションの中で機械学習を動作させられるようになると思います。 このブログ全体を通して、Java コードのスニペットを示しながら、本ツールの特徴的な側面に焦点を当てていきます。こちらから、構築およびデプロイされたコードを、ご自身の AWS アカウントのために取得することが可能です。 問題の概要 今回の例では、Java 開発者の Alice さんにご登場願います。彼女は、複数の AWS サービスの上層で走るビデオストリーミングプラットフォームを運営しており、顧客は数千人におよびます。Alice さんは、彼女のプラットフォームが上手く機能しているかを表示するメトリクスを追跡するため、ダッシュボードの設定を行っています。彼女にとって最も重要なメトリクスの 1 つは、次の図に示すような、プラットフォーム上のアクティブユーザーの総数です。 このメトリクスは、ユーザー数の基本的な日次パターンを示していますが、同時に、周期的な変化も見せています。 アクティブユーザー数の低い点、高い点、そして日常パターンから外れた動きなどは、すべて変則値として捉えられます。主に Alice さんが関心を寄せているのは、これらの変則的データポイントの根本原因を突き止めるということです。現在のところ彼女は、データ内の異常を見つけるための自動ツールは使っていません。代わりに、データのスパイクやくぼみ、周期性から外れた部分をみつけるため、マニュアル操作を行い多くの時間を費やしています。そして、この周期性に変化があることから、固定的なしきい値やそのウィンドウを設定しても、さほどの効果は上がりません。彼女には、もっと良い解決策が必要というわけです。 Alice さんの仕事を楽にする方法とは? ソリューションのアーキテクチャ 異常検知についてAlice さんが抱える問題を解決するには、まず、異常検知ツールの全構成ブロックを確認することが必要でしょう。 Amazon SageMaker – メトリクスデータの履歴をもとにしたモデルの構築を容易にするには、Amazon SageMaker を使います。これにより、(前週の値を参考に) 現在の変則的なデータポイントを見つけ出すことができます。Amazon SageMaker […]

Read More

改元はどのように RDS で実行されている MySQL 互換エンジンに影響を与えるか

RDSもしあなたのソフトウェアやシステムが日本のお客様をサポートしており、さらにそのソフトウェアやシステムが元号を表示する必要がある場合、新しい元号を表示するように改修の必要があるかもしれません。新しい元号は、現在の天皇陛下が退位される 2019 年 5 月 1 日から有効になります。 このブログ記事では、かかる元号の変更(改元)にかかわる背景について説明し、その後、どのように改元の影響を調べるかを、私が RDS で実行される MySQL 互換のデータベースエンジンについて調査した際の方法を元に、詳しく解説します。またその調査の結果、RDS で実行される MySQL 互換のデータベースエンジンは改元の影響を受けない、という結果を得たことを報告します。 改元について 元号は、日本で、主に政府のシステムや公的な文書などを中心に、未だ広く使われています。そのようなシステムをサポートするために、いくつかのソフトウェアでは元号をサポートするための機能が実装されています。例えば、Windows では元号をレジストリに格納していたり、Oracle データベースは元号を表示するためのカレンダー・ファイルを持っていたり、glibc ライブラリの strftime()関数は元号を表示するための機能があり、日本語のロケール・ファイルには元号の情報が含まれていたりします。 来る 2019 年 4 月 30 日に、現在の天皇陛下が退位され、それにともない 2019 年 5 月 1 日から元号が変更されます(改元)。そのため、元号をサポートするソフトウェアは、新しい元号を表示できるように更新する必要があります。 新しい元号は2019 年 4 月 1 日に発表される予定となっており、ソフトウェアのアップデートを準備する時間は 1 ヶ月未満の短い期間しかありません。 条件の理解 基本的に、Linux ビルトインのソフトウェアのうち、元号の表示に対応しているものは glibc() ライブラリの strftime() 関数のみです。 strftime()は日付や時刻の表示フォーマットを変更するための関数で、元号を使用して日付を変更する機能を持ちます。日本語 (ja_JP) ロケールを使用しているシステムでフォーマット指定子 (format specification) として […]

Read More

[AWS Black Belt Online Seminar] Amazon EC2 資料及び QA 公開

先日 (2019/3/5) 開催しました AWS Black Belt Online Seminar「Amazon EC2」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190305 AWS Black Belt Online Seminar Amazon EC2 from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. Nitro Hypervisor と KVMベースのハイパーバイザーとの違いは何でしょうか。今後はNitor Hypervisorベースが主になるのでしょうか。 A. Nitro Hypervisor はKVMのコアテクノロジーをベースとして構築されており、一般的なHypervisorの機能である、CPUやメモリの分離といった仮想化機能に加えて、Nitro CardなどEC2の専用ハードウェアコンポーネントを活用して、Hypervisorとしてより軽量に、仮想化インスタンスに対して一貫したパフォーマンスを提供できるように作られています。今後、新しいインスタンスタイプのほとんどがNitro Hypervisorを使用する予定です。Nitro Hypervisorに関しては、下記のFAQも参照ください。 https://aws.amazon.com/jp/ec2/faqs/#Nitro_Hypervisor Q. Public IPのユースケースがよくわかりませんでした。Public IPが変わっても、ALBの設定に連動するのでしょうか? A. EC2インスタンスをインターネットと通信する要件がある場合、1) VPCのサブネットにインターネットゲートウェイ(IGW)をアタッチする(このサブネットを「パブリックサブネット」と呼びます)のに加え、2) EC2インスタンスがインターネットから通信可能なIPアドレスを持つ必要があります。この2)を実現するひとつの方法がPublic IPアドレスです。Public IPアドレスを付与するかどうかはEC2インスタンス起動時のオプションで指定することができます。 後半のご質問は対象のEC2インスタンスがALBのバックエンドにアタッチされている場合、Public IPアドレスが変わったときどうなるか、というご質問としてお答えします。この場合、ALBに登録したインスタンスの設定を変更する必要はありません。これはALBはバックエンドEC2インスタンスをPublic IPアドレスの単位で管理しておらず、EC2インスタンスそのものとして管理しているためとお考えください。補足として、EC2インスタンスの稼働中にPublic IPアドレスは変更されることはなく、停止して起動するタイミングでのみ変更されます。このとき、インスタンスの停止中もALBからの登録状態は継続されます。 Q. Webサーバーなどのアプリケーション利用ではAMDのCPUは、有用性はありますでしょうか? A. 利用するアプリケーションの性能要件をAMDのCPUでも満たすことさえできれば、Intel版の同等のインスタンスタイプに比べてオンデマンド価格で10%程度安価にご利用頂くことが可能であり、コスト面でとても有用と思われます。 […]

Read More

AWS DeepRacer リーグサミットサーキット初の優勝者の発表!

本日、カリフォルニア州サンタクララ市で開催された AWS サミットでは、世界初のグローバル自律型レーシングリーグの2019年シーズンが開始されました。AWS DeepRacer リーグは、すべてのスキルレベルの開発者が、 世界中のAWS グローバル サミット の一連のレーシングイベントを通じて、Machine Learning を使った実践を行うことを許可します。AWS DeepRacer リーグは、年間を通じた仮想イベントとトーナメントを含みます。 開発者として、Machine Learning のスキルをテストするエキサイティングな日でした! 9 時間後に、400 周の自律走行、5 マイルを超えるレースで、サンタクララの優勝者が発表されました。カリフォルニア州サンタクララを拠点にする Cloud Brigade の創立者である Chris Miller は、リーダーボードを突破し、ネバダ州ラスベガスで開催される re:Invent 2019 でAWS DeepRacerチャンピオンシップカップへの経費支給の旅に進める最初の勝者です。10.43 秒の優勝者のタイムで Chris と彼のチームはサンタクララサミットに AI トML について学ぶことを目的に来ました 「私は最新の用途で利用できる Machine Learning と技術に興奮しています」。 Chris はサミットの AWS DeepRacer ワークショップの 1 つで彼の勝利したモデルをトレーニングしました。次は Chris のアジェンダです。彼は現在、Machine Learning と彼のモデルをさらにカスタマイズする方法についてもっと多く学習することにより、re:Invent の準備をしています。 リーダーボードの 3 つのトップの開発者: […]

Read More

Portworx クラウドネイティブストレージを使用して、Amazon EKS で高可用性 Microsoft SQL Server コンテナを実行する

このブログ記事では、Amazon Elastic Container Service for Kubernetes (Amazon EKS) を使用したコンテナへの Microsoft SQL Server のデプロイについて説明します。ここで説明するものと同じアプローチと原則は、再利用可能で再現可能な DevOps プラクティスと組み合わせた高可用性 (HA) と耐久性を必要とする他のステートフルアプリケーションにも適用されます。ユースケースの例としては、MongoDB、Apache Cassandra、MySQL、ビッグデータ処理などがあります。 SQL Server をコンテナ内で実行するためのサポートは、SQL Server 2017 で初めて導入されました。Kubernetes (K8s と呼ばれることもあります) を使用して、Linux コンテナ内で本番用 SQL Server ワークロードを実行できます。 Microsoft SQL Server は、今日使用されている最も人気のあるデータベースエンジンの 1 つです。SQL Server は魅力的な機能と堅牢なコミュニティを数多く提供しますが、クラウドベースまたはオープンソースのデータベースソリューションよりもさらにメンテナンスを必要とするか、より高価です。組織によっては、オープンソースソリューションに移行してライセンスコストを削減することで、これらのコストを削減しようとしているところもあります。他の企業は、ワークロードを Amazon RDS for Microsoft SQL Server や Amazon Aurora などのマネージド型リレーショナルデータベース管理システム (RDBMS) サービスに移行することを選択しています。 ただし、組織が SQL Server エンジンから離れることができない […]

Read More

AWS App Mesh – クラウドアプリケーション向けのアプリケーションレベルネットワーキング

AWS App Mesh は、HTTP および TCP サービスの実行を広範囲で支援します。これにより、トラフィックのルーティングと監視に一貫性のある方法が提供され、問題の内容を把握し、障害やコード変更の後にトラフィックをリルートすることが可能になります。App Mesh は、オープンソースの Envoy プロキシを使用します。AWS のパートナーやオープンソースコミュニティが提供する多くのツールと連携できます。 このサービスは、AWS Fargate、Amazon EC2、Amazon ECS、Amazon Elastic Container Service for Kubernetes、 Kubernetes などの上で実行が可能です。各サービスに出入りするトラフィックは、全て Envoy プロキシを通過するので、ルーティング、帯域制限、測定、記録などが行えます。この追加された間接レベルにより、共通コミュニケーションライブラリの必要もなしで、お望みのあらゆる言語でサービスを構築することもできます。 App Mesh のコンセプト 早速取りかかる前に、まず、重要な App Mesh のコンセプトやコンポーネントのいくつかについて確認しておきましょう。 サービスメッシュ – 隣り合うサービス間にあるトラフィックの論理的な境界線。1 つのメッシュには、仮想サービス、仮想ノード、仮想ルーター、ルートなどが含まれています。 仮想サービス – 仮想ノード にが直接的に、あるいは、仮想ルーターにが間接的に与える、サービスの抽象型 (論理名)。メッシュ内にあるサービスは、他のサービスを論理名によって参照および利用します。 仮想ノード – タスクグループ (ECS サービスもしくは Kubernetes デプロイメント) 、または、1 つか複数の EC2 インスタンスの上で実行されるサービスへのポインタ。各仮想ノードは、リスナーを経由して入って来るトラフィックを受け付け、バックエンドを通じ他の仮想ノードへ接続します。加えて、各ノードには、サービスディスカバリー設定 (現状では DNS ネーム) […]

Read More

新しい AMD EPYC 搭載の Amazon EC2 M5ad インスタンスと R5ad インスタンス

昨年、皆さんに新しい低コストの AMD 搭載 M5a および R5a EC2 インスタンスについてお伝えしました。AWS Nitro System 上に構築されたこれらのインスタンスは、2.5 GHz で動作するカスタム AMD EPYC プロセッサを備えています。これらは、同等の EC2 M5 および R5 インスタンスよりも価格が 10% 低く、コストとパフォーマンスに基づいてインスタンスの組み合わせのバランスを取るための新しい機会を提供します。 本日、AWS は M5ad と R5ad の各インスタンスを追加します。これらはどちらもカスタム AMD EPYC 7000 シリーズプロセッサを搭載しており、AWS Nitro System 上に構築されています。 M5ad および R5ad インスタンス これらのインスタンスは、昨年末にローンチされた既存の M5a および R5a インスタンスに、高速で低レイテンシーのローカル (物理的に接続された) ブロックストレージを追加します。 M5ad インスタンスは、ウェブサーバー、アプリケーションサーバー、開発/テスト環境、ゲーム、ログ記録、およびメディア処理などの汎用ワークロード向けに設計されています。これらは 6 つのサイズでご利用いただけます。 インスタンス名 vCPUs RAM ローカルストレージ […]

Read More

新しい Amazon S3 ストレージクラス – Glacier Deep Archive

AWS のお客様の多くは、大量 (大抵の場合ペタバイト以上) の重要データを収集して保存しますが、そのデータにアクセスすることはほとんどありません。raw データを収集してからすぐに処理し、その後万が一さらに処理または分析する必要が生じたときのために数年または数十年にわたって保存しておく場合もあれば、データをコンプライアンスまたは監査目的のために保持する場合もあります。このパターンに当てはまる業界とユースケースには以下のようなものがあります。 金融 – 取引アーカイブ、活動 & 監査ログ、および通信ログ。 ヘルスケア/ライフサイエンス – 電子医療カルテ、医療画像 (レントゲン、MRI、または CT)、遺伝子配列、製剤開発の記録。 メディア & エンターテイメント – メディアアーカイブと未処理の撮影映像。 物理的なセキュリティ – 未処理のカメラ映像。 オンライン広告 – クリックストリームと配信ログ。 交通 – 車両テレメトリ、ビデオ、RADAR、および LIDAR データ。 科学/研究/教育 – 石油および天然ガス探鉱のための振動実験に関連するデータを含む、研究のインプットと結果。 AWS は本日、Amazon S3 で重要な低頻度アクセスのデータを保存するための、新しく、コスト効率性がより高いストレージを導入します。 Amazon S3 Glacier Deep Archive ストレージクラス 新しい Glacier Deep Archive ストレージクラスは、耐久性があり、セキュアな大量のデータ向けの長期ストレージを、オフプレミスのテープアーカイブサービスに負けない価格で提供するよう設計されています。データは 3 つ以上の AWS アベイラビリティゾーンにまたがって保存され、12 時間以内に取りだすことができます。高価で扱いにくいテープドライブに対処し、オフプレミスストレージを手配して、新世代のメディアへのデータの移行について心配する必要はもうありません。 既存の […]

Read More

新機能 – AWS Application Load Balancer 向けの高度なリクエストルーティング

AWS Application Load Balancer は、2016 年の夏以来活躍しています。 これらは、コンテンツベースのルーティングをサポートし、サーバーレスおよびコンテナベースのアプリケーションとも相性がよく、スケーラビリティがきわめて高いロードバランサーです。AWS のお客様の多くが既存のホストおよびパスベースのルーティングを使用して、HTTP や HTTPS アプリケーションを動作させています。同時に、ポート転送 (コンテナベースのアプリケーションには最適)、ヘルスチェック、サービスディスカバリー、リダイレクト、固定レスポンス、組み込み認証といったさまざまな ALB 機能も活用しています。 高度なリクエストルーティング ホストベースのルーティング機能で、ホスト のヘッダーを使用してトラフィックを任意のターゲットグループにルーティングするようにルールを書くことができます。本日より、この機能を拡張、汎用化して、皆さまが標準およびカスタム HTTP ヘッダーとメソッド、クエリ文字列、ソース IP アドレスに基づいてルールを書けるように (その結果、トラフィックをルーティングできるように) なりました。さらに、そのルールと条件もパワフルになりました。ルールは複数の条件 (AND 条件すべて) が設定可能になり、その各条件も複数の値 (OR 条件のいずれか) とのマッチを指定できます。 この新機能で、お使いのアプリケーションアーキテクチャはシンプル化され、ルーティング用のプロキシフリートの必要性がなくなり、望まないトラフィックをロードバランサーでブロックできます。ユースケースをいくつかご覧ください。 ボットやクローラのトラフィックを人的トラフィックから分離する。 顧客または顧客グループをセル (別のターゲットグループ) にアサインし、そのトラフィックをルーティングする。 A/B テストを実施する。 カナリアリリース手法によるデプロイ、またはブルー/グリーンデプロイを実施する。 メソッドベース (たとえば、あるターゲットグループには PUT、別のターゲットグループには GET など) で、マイクロサービスハンドラーにトラフィックをルーティングする。 IP アドレスまたは CDN ベースで、アクセス制限を実行する。 オンプレミスまたはインクラウドのターゲットグループにトラフィックを選択的にルーティングする。 デバイスのさまざまなタイプやカテゴリに、異なるページやユーザーエクスペリエンスを配信する。 高度なリクエストルーティングの使用法 本機能は、現在お使いの Application Load Balancer で既存のルールを編集するだけでご利用になれます。まず、プレーンテキストの固定レスポンスを返すシンプルなルールから始めます […]

Read More

新規 – Amazon Redshift の同時実行スケーリング – 常に最高のパフォーマンス

Amazon Redshift は、エクサバイト規模まで拡張可能なデータウェアハウスです。現在、何万ものAWS 顧客 (NTTドコモ、Finra、Johnson & Johnson を含む) が Redshift を使用してミッションクリティカルな BI ダッシュボードを実行し、リアルタイムのストリーミングデータの分析や、予測分析ジョブを実行しています。 こうした中、ピーク時に同時実行クエリの数が増えると、問題が発生します。多くのビジネスアナリストが BI ダッシュボードに目を向けるようになったり、長期間実行されるデータサイエンスのワークロードが他のワークロードとリソースを奪い合うようになると、Redshift はクラスター内で十分なコンピューティングリソースが利用可能になるまでクエリをキューに入れます。こうすることで、すべての作業は確実に完了しますが、ピーク時にパフォーマンスが影響を受ける可能性があります。次の 2 つの選択肢があります。 ピーク時のニーズに合わせてクラスタをオーバープロビジョニングする。この選択肢は当面の問題は解決しますが、必要以上にリソースとコストを浪費します。 一般的なワークロードに合わせてクラスターを最適化する。この選択肢を採用すると、ピーク時に結果を待つ時間が長くなり、ビジネス上の重要な決定が遅れる可能性があります。 新しい同時実行スケーリング 今回、第 3 の選択肢を提示したいと考えています。必要に応じてクエリ処理能力を追加するように Redshift を設定することができます。これは透過的かつ数秒の短時間で発生し、ワークロードが何百もの同時クエリに増加しても高速で一貫したパフォーマンスを提供します。追加の処理能力は数秒で準備ができるので、事前のウォームアップまたはプロビジョニングは必要ありません。1 秒あたりの請求額で、使用した分だけお支払いいただき、メインクラスターの実行中は 24 時間ごとに 1 時間の同時実行スケーリングクラスターのクレジットが累積されます。余分な処理能力は、不要になった時点で取り除かれるので、前述したバースト性のあるユースケースに対処するのに最適な方法です。 特定のユーザーまたはキューにバーストパワーを割り当てることができ、既存の BI および ETL アプリケーションを引き続き使用することができます。同時実行スケーリングクラスターは、さまざまな形式の読み取り専用クエリを処理するために使用され、柔軟に動作できます。詳細については、同時実行スケーリングを参照してください。 同時実行スケーリングの使用 この機能は、既存のクラスターに対して数分で有効にできます。 テスト目的で新しい Redshift パラメーターグループから始めることをお勧めします。そこで、まず 1 つ作成することから始めます。 次に、クラスターの Workload Management Configuration を編集し、新しいパラメータグループを選択し、[Concurrency Scaling Mode] を [auto] に設定して、[Save] をクリックします。 […]

Read More