Amazon Web Services ブログ

AWS Innovate 2020 : 多種多様なソリューションを学ぼう!

2020年3月10日 から開催している「AWS Innovate」をお楽しみいただいていますでしょうか? AWS Innovate はグローバルでも人気のある「クラウド活用のための無償オンラインカンファレンス」です.今回は 2020年3月10日 から 2020年4月17日 までの「計39日間」毎日開催をしており,「計42個のセッション」を何度でも視聴可能です.参加申込みは簡単です!以下の申込みサイトにアクセスをしましょう. AWS Innovate サイト AWS Innovate 申込みサイト(無料)   「AWS Innovate 2020 の見どころ」を紹介する連載も3週目となりましたが,いよいよラストです!本記事も AWS テクニカルトレーナーの吉田慶章が担当します.今までの連載では「基調講演」と「ハンズオン」を紹介してきましたが,まだまだ見どころはあります.本記事では,全セッションを紹介したい気持ちを抑えつつ,オススメをピックアップして,紹介します!今までの連載もあわせて読んでいただけると嬉しいです. AWS Innovate 2020 : 今年もスタート! | Amazon Web Services ブログ AWS Innovate 2020 : ハンズオンセッションで実践力を高めよう! | Amazon Web Services ブログ   見どころ : クラウドで信頼性の高いシステムを構築するための障害や故障との向き合い方 まず最初に紹介するのは「クラウドで信頼性の高いシステムを構築するための障害や故障との向き合い方 (Lv.200)」です.皆さんは「Everything fails all the time」という Amazon CTO […]

Read More

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

先日 (2020/03/18) 開催しました AWS Black Belt Online Seminar「Amazon Redshift」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200318 AWS Black Belt Online Seminar Amazon Redshift from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. どういった場合に行指向ストレージが向いているのでしょうか?(逆に言えば、Redshiftでの処理に向いていないクエリはあるのでしょうか) A. 多数のショートトランザクションが中心となるような場合に行指向ストレージが向いていると言えます。例えば、特定の行のみの情報を取得するような場合や、1行に対する更新処理や挿入処理が繰り返し行われることが多いシステムの場合、行指向ストレージが向いていることが考えられます。一般論になりますが、いわゆるOLTPの処理は行指向の方が向いていると言えます。一方で、比較的少量のトランザクションが中心で、クエリが多くの場合複雑で大規模な履歴データセットに対する集計を伴うような場合、Amazon Redshiftが向いていると言えます。AWSでは、目的別に応じて多様なデータベースをご用意しておりますので、利用シーンに合わせて選択いただければと思います。 Q. SQAにもスロットという概念あるのでしょうか? A. はい、SQAにもスロットという概念があります。SQA用のキューがデフォルトで存在し、該当のキューに対して、スロットが設定されています。Amazon Redshiftがクエリを実行する際には、必ず、デフォルトキュー、ユーザー定義のキュー、SQA用のキューいずれかが持つスロットが使用されることになります。ただし、SQA用のキューが確保しているメモリ容量やスロットの数については公開されておりません。 — 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。 皆様のご参加をお待ちしております。 — AWS Innovate Online Conference / AWS Startup Day Online 【全42セッション公開中】 […]

Read More

Amazon SageMaker の強化学習を使用して AI で駆動する Battlesnake を構築する

Battlesnake は、従来のスネークゲームを基礎にした AI コンペティションで、複数の AI を搭載したスネークが生き残りをかけて競います。Battlesnake は、あらゆるレベルの開発者のコミュニティを魅了しています。何百ものスネークが競い合い、オンラインの Battlesnake グローバルアリーナでランキング上位に入ることを目指します。Battlesnake はまた、1,000 人以上の開発者と非開発者が参加するオフラインイベントを開催しており、その様子は Twitch でストリーミング配信されています。開発者のチームは、コンペティションのためにスネークを作り、新しい技術スキルを学び、協力することを学び、楽しんでいます。チームは、最先端の深層強化学習 (RL) アルゴリズムから独自のヒューリスティックベースの戦略まで、さまざまな戦略を駆使してスネークを構築できます。 この記事では、Amazon SageMaker を使用して RL ベースのスネークを構築する方法を説明します。 従来のスネークゲームでは、スネークを上下左右に移動するようにコントロールします。スネークが壁、別のスネーク、またはスネーク自身の体にぶつかると、スネークは死にます。スネークが食物を食べると、体が長くなります。従来のスネークゲームと比べると、Battlesnake にはいくつか違う点があります。まず、スネークを制御するのは、プログラムです。2 頭のスネークが正面衝突すると、小さいスネークが死にます。また、飢えメカニズムがあります。100 手動いて食物を食べられなかったスネークは死にます。そのため、生存率を最大にする、他のスネークを積極的に攻撃する、または他のスネークを避けようとすることはすべて、プレイヤーが採用している実践的な戦略です。スネークはプログラムされたウェブサーバーとして実装され、Battlesnake エンジンはゲームの現在の状態を考慮して次の動きをクエリします。詳細については、Battlesnake ウェブサイトの「開始方法」を参照してください。 この記事では、SageMaker Battlesnake スターターパックを使用して、スネークの構築に必要な時間と労力を節約する方法を示します。SageMaker Battlesnake スターターパックは、RL でトレーニングされた AI 搭載のスネークを提供します。スターターパックは、独自の RL ポリシーと、RL アルゴリズムの上にカスタムヒューリスティックベースのルールを構築するツールをトレーニングするための環境も提供します。さらに、AI ボットをデプロイおよびホストするウェブインフラストラクチャが自動的に生成されます。SageMaker Battlesnake スターターパックでは、周囲のインフラストラクチャを気にすることなく、AI の開発に集中できます。 Amazon SageMaker Battlesnake スターターパックは、AWS CloudFormation の quick-create リンクを使用します。これにより、GitHub repo から AWS マネジメントコンソールへ 1 クリックデプロイを行えます。スタックを作成すると、次の […]

Read More

Amazon API Gateway マッピングテンプレートと Amazon SageMaker を使用して機械学習を搭載した REST API の作成

Amazon SageMaker を使用して、組織は機械学習モデルを構築、トレーニング、およびデプロイできます。コンシューマー向けの組織は、パーソナライズされた製品の推奨事項を作成したり、顧客の好みに基づいてアプリケーションの動作を自動で調整したりすることにより、顧客体験を豊かにすることができます。そのようなアプリケーションを構築する場合、コンシューマーデバイスで実行されているクライアントソフトウェアでランタイム推論エンドポイントを使用可能にする方法は、アーキテクチャ上の重要な考慮事項の 1 つです。通常、エンドポイントは、クライアントソフトウェアに一連の完全なアプリケーション機能を提供する REST など、ウェブ上で使いやすい従来のアプローチに基づいて、より広範囲な API の一部として提供されます。 Amazon API Gateway は、開発者があらゆる規模の API を簡単に作成、公開、保守、監視、保護できるようにするフルマネージド型サービスです。API Gateway を使用して、Amazon SageMaker エンドポイントの外部に面した単一のエントリポイントを提示できます。これには、次の利点があります。 クライアント向けの REST API と、基となる Amazon SageMaker ランタイム推論 API の間を変換することにより、基本実装仕様からクライアントを隔離 クライアントリクエストの認証と承認をサポート 調整、評価制限、およびクォータ管理を使用してクライアントリクエストを管理 AWS WAF が提供するファイアウォール機能を使用 キャッシングとリクエストの検証により、コスト削減と運用の最適化を実現 モデルの変更を安全に導入するためのカナリアデプロイメントを簡単に作成 この記事では、マッピングテンプレートと呼ばれる API Gateway 機能を使用して、REST API の一部として Amazon SageMaker 推論エンドポイントを処理する方法をお見せします。この機能により、REST API を Amazon SageMaker ランタイムエンドポイントに直接統合できるため、エンドポイントを呼び出すための中間コンピューティングリソース (AWS Lambda または Amazon ECS コンテナなど) […]

Read More

クエリの実行を速めるために Amazon Redshift のビューをマテリアライズする

AWS では、ネットワーク、コンピューティングリソース、またはオブジェクトストレージなどのクラウドサービスの管理とアクセスを簡略化するために、最新の仮想テクノロジーの構築を得意としています。 あるリレーショナルデータベース管理システム (RDBMS) では、1 つのビューはテーブルに適用された仮想化であり、データベースクエリの結果を表す仮想テーブルと言えます。ビューはスキーマの設計時によく使用されます。データのサブセット、要約されたデータ (集約または変換されたデータ) の表示、または複数のテーブル間でのデータアクセスの簡略化などがその用途です。Amazon Redshift などのデータウェアハウスを使用すると、1 つのビューで、Amazon QuickSight または Tableau などのビジネスインテリジェンス (BI) ツールの複数のテーブルからの集約データへ簡易的にアクセスできるようになります。 ビューによって使いやすさや順応性は高まりますが、データアクセスのスピードは落ちます。データベースシステムはアプリケーションがビューにアクセスするたびに、ビューを示す基盤となるクエリを評価しなければならなくなります。パフォーマンスが重要な場合、データエンジニアはその代替手段として、create table as (CTAS) を使用します。CTAS はクエリで定義されたテーブルです。このクエリはテーブルの作成時に実行され、アプリケーションは通常のテーブルとしてそれを使用できます。これの不便なところは基盤となるデータが更新されたときに、CTAS のデータセットは更新されないことです。さらに、 CTAS の定義はデータベースシステム内に保存されません。そのため、テーブルが CTAS によって作成されたかを知ることは不可能で、どの CTAS を更新する必要があるか、どれが最新かを追跡するのは困難になります。 今日は、Amazon Redshift の マテリアライズドビューをご紹介します。マテリアライズドビュー (MV) はクエリのデータを含むデータベースオブジェクトです。マテリアライズドビューはビューのキャッシュのようなものと考えられます。実行時にデータセットを構築、計算する代わりに、マテリアライズドビューはビューを作成した時点で計算を事前に実行し、データアクセスを保存および最適化します。データは通常のテーブルデータと同様に、クエリに使用できます。 分析クエリでマテリアライズドビューを使用すると、クエリの実行時間を桁違いに短縮できます。その理由はマテリアライズドビューを定義するクエリが、すでに実行済みで、データがデータベースシステムで利用できる状態になっているためです。 マテリアライズドビューは予測可能で何度も繰り返し実行できるクエリで特に便利です。大きなテーブルにリソースをたくさん使うクエリを実行する代わりに、アプリケーションはマテリアライズドビューに保存された計算済みのデータに対してクエリを実行できます。 ベーステーブルのデータが変動するときは、Redshift の SQL ステートメント “refresh materialized view“ を実行して、マテリアライズドビューを更新します。更新ステートメントの実行後、マテリアライズドビューには通常のビューで返されたのと同等のデータが含まれます。更新は増分のみ、または完全更新 (再計算) のいずれかになります。可能な場合、Redshift はマテリアライズドビューが最後に更新されてからベーステーブルで変更のあったデータのみを増分更新します。 それでは、その仕組み見てみましょう。販売情報を格納するためにサンプルスキーマを作成します。販売情報は販売トランザクションと商品が販売された店の詳細情報で構成されています。 都市別販売金額合計を表示するために、create materialized view SQL ステートメントを使用して、マテリアライズドビューを作成します。Redshift […]

Read More

GTID ベースのレプリケーションを使用したフォールバックオプションで Amazon Aurora MySQL へ移行する

本番アプリケーションを移行する場合、多くの場合、フォールバックオプションを備えていることが重要です。このブログ記事では、グローバルトランザクション識別子 (GTID) ベースのレプリケーションを使用して、Amazon RDS MySQL ワークロードを Amazon Aurora MySQL に移行する方法を説明します。また、問題が発生した場合にフォールバックメカニズムを使用する方法についても説明します。 GTID ベースのレプリケーションの詳細については、「Amazon Aurora for MySQL 互換エディションでグローバルトランザクション 識別子 (GTID) によるレプリケーションがサポートされるようになりました」をご覧ください。 この記事では、レプリケーショントポロジには、2 つのリードレプリカ (RDS MySQL リードレプリカと Aurora MySQL レプリカ) を持つマスター RDS MySQL インスタンスがあります。移行中に問題が発生した場合のフォールバックインスタンスとして RDS MySQL リードレプリカを使用し、元の RDS MySQL マスターが影響を受けないようにします。ただし、元の RDS MySQL マスターインスタンスをフォールバックオプションとして使用することもできます。移行が成功すると、Aurora MySQL レプリカが RDS MySQL レプリカインスタンスのマスターインスタンスになります。 GTID ベースのレプリケーションを使用する主な利点は、すべてのトランザクションに一意の識別子を割り当てられ、レプリケーショントポロジ内の各 MySQL サーバーがすでに実行したトランザクションを追跡できることにあります。GTID ベースのレプリケーションはトランザクションベースであるため、マスターとレプリカ間のデータの一貫性を簡単に判断できます。マスターでコミットされたすべてのトランザクションがレプリカにもコミットされている場合、2 つの間に一貫性があります。これにより、auto-positioning が可能になります。これは、binlog ファイルの名前または位置を指定することなく、レプリカがマスターインスタンスをポイントする機能です。 前提条件 このチュートリアルを実行するには、次の前提条件を満たしている必要があります。 […]

Read More

Redis 向け Amazon ElastiCache グローバルデータストアが利用可能に

インメモリデータストアは、アプリケーションのスケーラビリティのために広く使用されており、開発者は、頻繁にアクセスされる (揮発性または永続的) データを保存することの恩恵を長年にわたって享受しています。Redis のようなシステムは、データベースとバックエンドを着信トラフィックから疎結合化し、本来ならそれらに到達するはずだったほとんどのトラフィックを排し、ユーザーのアプリケーションレイテンシーを削減するのに役立ちます。 これらのサーバーを管理することが重要なタスクであることは明白で、何が起きようとも、それらを維持し、実行し続けるために細心の注意を払わなければなりません。以前の業務において、私のチームは、物理キャッシュサーバーのクラスターをホスティングスイート間で移動する必要がありました。1 つずつ外部バッテリーに接続し、外部電源プラグを抜き、それらをラックから取り出し、オフィス用の台車 (!) で他のスイートまで運び、再びそれらをラックに入れていたのです! サービスを中断することなく実行できましたが、これが完了すると私たち全員は安堵のため息をつきました。高トラフィックのプラットフォームでキャッシュデータを失うと、大変なことになるからです。そのことを考えれば羨ましい限りです。幸いなことに、クラウドインフラストラクチャはより柔軟です! インシデントが発生した場合のサービスの中断を最小限に抑えるために、Memcached および Redis のマネージドインメモリデータストアである Amazon ElastiCache に、クラスターモード、自動フェールオーバーを備えたマルチAZなど、多くの高可用性機能を追加しました。 Redis は多くの場合、低レイテンシートラフィックをグローバルユーザーに提供するために使用されることから、お客様は、AWS リージョンをまたいで Amazon ElastiCache クラスターをレプリケートできるようになることを望んでいます。当社はこれらに耳を傾け、解決に向けて動きました。そして本日、このレプリケーション機能が Redis クラスターで利用可能になったことをお知らせできることを大変嬉しく思います。 Amazon ElastiCache Global Datastore For Redis の紹介 簡単に言えば、Amazon ElastiCache Global Datastore for Redis を使用すると、1 つのリージョンのクラスターを最大 2 つの他のリージョンのクラスターに複製できます。お客様は、通常、次の目的でこれを行います。 ネットワークレイテンシーを削減し、アプリケーションの応答性を向上させるために、キャッシュされたデータをユーザーの近くに置く。 リージョンの一部または全部が完全に利用できない場合に備えた災害復旧機能を構築する。 グローバルデータストアのセットアップは非常に簡単です。最初に、アプリケーションから書き込みを受信するプライマリクラスターとしてのクラスターを選択します。これは、新しいクラスター、または Redis 5.0.6 以降を実行する既存のクラスターのいずれかにすることができます。次に、他のリージョンにプライマリから更新を受信する最大 2 つのセカンダリクラスターを追加します。 このセットアップは、単一ノードクラスターを除くすべての Redis 設定で使用できます。もちろん、単一ノードクラスターをレプリケーショングループクラスターに変換し、それをプライマリクラスターとして使用できます。 最後に重要なことですが、グローバルデータストアの一部であるクラスターは、通常どおりに変更およびサイズ変更できます (ノードの追加または削除、ノードタイプの変更、シャードの追加または削除、レプリカノードの追加または削除)。 簡単なデモを見てみましょう。 […]

Read More

Amazon Redshift マテリアライズドビューを使用して AXS で Etleap モデルを高速化する

Amazon Redshift のマテリアライズドビュー機能は現在一般公開されており、2019 年 12 月からプレビュー中のお客様およびパートナーにメリットをもたらしてきました。当社のお客様の AXS は、米国、英国、欧州、および日本のライブエンターテインメント会場向けのチケット販売、データ、およびマーケティングの分野における主要なソリューションプロバイダーです。Amazon Redshift パートナーである Etleap は、AWS 用に構築された抽出、変換、ロード、および変換 (ETLT) のサービスです。AXS は Etleap を使用して、ファイルサーバー、Amazon S3、リレーショナルデータベース、アプリケーションなどのさまざまなソースから Amazon Redshift にデータを取り込みます。これらの取り込みパイプラインは、適切な列タイプおよび並べ替えキーと分散キーを使用して、データを分析および構造化し、Amazon Redshift テーブルにロードします。 Etleap モデルでダッシュボードのパフォーマンスを改善する データを分析するために、AXS は通常、複数のソースから発生する大きなテーブルに対してクエリを実行します。AXS による Amazon Redshift の使用形態の 1 つとして、インタラクティブなダッシュボードを強化することを挙げることができます。ダッシュボードのロード時間を短縮するために、AXS は、ダッシュボードが使用するクエリに対する部分的な回答を事前にコンピューティングします。これらの部分的な回答は、行数の点において、当該回答が基づくテーブルよりも数桁小さくなります。ダッシュボードは、事前にコンピューティングされた部分的な回答を保持する Amazon Redshift テーブルをクエリすることによって、ベーステーブルを直接クエリする場合よりもはるかに高速にロードできます。 Etleap は、models と呼ばれる機能を通じて、このような事前コンピューティングの作成と管理をサポートしています。モデルは、SELECT クエリと更新時期のトリガーで構成されます。トリガーの例は、ベーステーブル、つまりモデルを定義する SELECT ステートメントが使用するテーブルへの変更です。このようにして、モデルはベーステーブルとの一貫性を保つことができます。 次のスクリーンショットは、2 つのベーステーブルの依存関係を持つ Etleap モデルを示しています。 Etleap は、モデルを Amazon Redshift のテーブルとして表します。モデルテーブルを作成するために、Etleap は、CREATE TABLE […]

Read More

Amazon Translate、AWS Lambda、および、新しいバッチ翻訳 API を使ってのドキュメント翻訳

ビジネスや個人向けに、世界中で共有されるデジタルのテキストドキュメントの数が増加し続けている中、翻訳機能への要求はさらに強まってきています。オンライン上には、ユーザーがテキストをコピー&ペーストすればその内容を希望の言語に翻訳できるツールが複数存在します。(分量に限度があり) その場しのぎで テキストを翻訳するのであれば、これも非常に有用だと言えますが、頻繁にこれを行うとなれば、退屈で時間だけがかかる仕事になります。 各組織では、製品やサービスを説明するためのコンテンツを大いに活用することで、問い合わせの方法を顧客に知らせたり、事業上の訴求ポイントなどを広告しています。こういったコンテンツでは、しばしばテキスト量が増えがちで、また、ほとんどは母国語で記述されているでしょう。その言語についての十分な知識のないユーザーが内容を理解しようとすることはやっかいなことです。そして、企業と顧客との関係においても、直接的な影響を与える可能性があります。ドキュメント一式をある言語から別な言語に素早くコスト効率良く翻訳できる、自動化されたソリューションが求められています。 このブログ記事では、ドキュメント翻訳に関する 2 つのソリューションについて解説していきます。その 1 つは、収集したドキュメントに非同期のバッチ翻訳を行うシンプルな翻訳手法のアプローチで、もう一方は、AWS Lambda と Amazon のリアルタイム翻訳を使い、ドキュメントを入手する度に同期的に翻訳を行う、より進んだアプローチです。お客様は、必要に応じ最適な方を選び、ご使用いただけます 同期バッチ翻訳を使うシンプルなアプローチ Amazon Translate は、現実的な価格で迅速かつ高品質な翻訳を実現するニューラル機械翻訳サービスです。ニューラル機械翻訳は、深層学習モデルを応用した自動翻訳の一形態です。これによれば、従来の統計学や規則をベースにした翻訳アルゴリズムと比べて、正確かつ自然な響きのある翻訳を提供できますこの翻訳サービスは、多様なコンテンツにも適格に対応するため、異なるユースケースやドメイン間での多様な文章を使ってトレーニングされています。この詳細については、Amazon Translate の製品ページをご参照ください。 近頃、Amazon Translate では、大量に集積したテキストや HTML ドキュメントの翻訳に使える、非同期のバッチ翻訳機能を公開しました。これにより、1 回の API 呼び出しのみで、ドキュメント一式をある言語から別な言語に翻訳できます。非同期バッチ翻訳を使うことで、ドキュメントやチュートリアル素材、あるいはブログなどを、日ごとに希望の言語に翻訳しローカライズすることが可能です。さらに、バッチ翻訳ジョブの進行状況をモニタリングしたり、指定した出力フォルダーから翻訳結果を取得することもできます。それでは、非同期バッチ翻訳の使用方法を確認していきましょう。 Amazon Translate のバッチ翻訳を試すために、ここでは、次に示すような 3 つのテキストファイルを使用します。 これらのテキストファイルは、こちらからダウンロードできます。 テキストファイル 1: Amazon Translate is a neural machine translation service that delivers fast, high-quality, and affordable language translation. テキストファイル 2: Neural machine translation is […]

Read More

Amazon DocumentDB (MongoDB 互換) で $dateFromString と executionStats を使用する

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージドのドキュメントデータベースサービスです。Amazon DocumentDB では、JSON データの保存、クエリ、およびインデックスの作成を簡単かつ直感的に行うことができます。Amazon DocumentDB を初めて使用する場合は、「Amazon DocumentDB (MongoDB 互換) でのランプアップ」をご覧ください。 Amazon DocumentDB では、MongoDB との互換性の改善を続けています。このブログを執筆している時点で、Amazon DocumentDB には 2 つの新機能を新たにサポートしています。 $dateFromString は、ドキュメントに対して強力な集計を作成できる集計パイプライン演算子です executionStats モード (explain() 用) は、クエリプラン内の各ステージの詳細な実行統計を提供します。 Amazon DocumentDB のサポートされている MongoDB API と集計パイプライン機能の詳細については、「サポートされている MongoDB API、オペレーション、およびデータ型」をご参照ください。 この投稿では、$dateFromString と executionStats のユースケースについて解説し、サンプルコードを介してこれらの新機能の使用方法をご紹介します。 $dateFromString $dateFromString 集計パイプライン演算子は、文字列形式の日付を DATE データ型に変換できます。$dateFromString は $dateToString の逆演算子です。 $dateFromString のしくみを理解するために、この投稿では、ビデオゲーム内で発生したイベントの日時を記録するサンプルデータセットを使用しています。ビデオゲームはイベントを文字列として記録しますが、アプリケーションはイベントフィールドを DATE データ型として分析できる必要があります。文字列から日付への変換を実行するには、$dateToString 集計演算子を使用します。 […]

Read More