Amazon Web Services ブログ

Amazon DynamoDB: ゲームのユースケースと設計パターン

  ゲーム会社は、ゲームステート、プレイヤーデータ、セッション履歴、およびリーダーボードなどのゲームプラットフォームのあらゆる部分で Amazon DynamoDB を使用しています。これらの会社が DynamoDB から得る主なメリットは、1 桁ミリ秒で測定される一貫した低レイテンシーを確保しながら、何百万もの同時ユーザーとリクエストに確実にスケールする DynamoDB の能力です。それに加えて、完全マネージド型サービスである DynamoDB には運用上のオーバーヘッドがありません。ゲーム開発者は、データベースの管理ではなく、ゲームの開発に集中することができます。また、単一の AWS リージョンから複数のリージョンへの拡大に関心を持つゲームメーカーは、マルチリージョンでのアクティブ/アクティブ型のデータレプリケーションのために DynamoDB のグローバルテーブルに頼ることができます。 このブログ記事では、DynamoDB を使用するゲーム会社の最も一般的なユースケースと設計パターンについて詳しく説明します。 この記事で使用される用語 この記事では、以下のデータモデリング用語を使用します。 1:1 モデリング: パーティションキーをプライマリキーとして使用する 1 対 1 関係のモデリング。 1:M モデリング: パーティションキーとソートキーをプライマリキーとして使用する 1 対多関係のモデリング。 N:M モデリング: テーブルとグローバルセカンダリインデックスがあり、パーティションキーとソートキーをプライマリキーとして使用する 多対多関係のモデリング。 ゲームのユースケースと設計パターン ユースケース 設計パターン ゲームステート、プレイヤーのデータストア 1:1 モデリング、1:M モデリング プレイヤーのセッション履歴のデータストア 1:1 モデリング、1:M モデリング リーダーボード N:M モデリング ユースケース: ゲームステートとプレイヤーのデータストア プレイヤーのゲームステートとその他のプレイヤーデータを保存するための DynamoDB の使用は、ゲーム会社がミリ秒単位のアクセスレイテンシーを維持しながら、多数の同時プレイヤーに対応することを可能にします。その例として、世界中に […]

Read More

AWS DeepRacer リーグが開発者のさらなる楽しみとワクワクを目指してスタート!

  開発者から機械学習の開発者まで AWS DeepRacer リーグは、スキルレベルを問わず開発者が参加できる世界初の自走型レーシングリーグです。カリフォルニア州サンタクララで先週、開幕しました。2019 年のシーズン最初のチャンピオンに輝いたのは Chris Miller でした。Chris はカリフォルニア州サンタクルズに本拠を置く Cloud Brigade の創業者です。機械学習についてさらに理解を深めるため、AWS Summit を訪れました。 AWS では、スキルレベルを問わず全ての開発者に機械学習を身近なものにし、機械学習の体験を楽しく易しいものにすることに注力しています。サンタクララにおいて、最上位の完走者 3 人は全員オンサイトのワークショップの1つでモデルを構築し、その過程をとても楽しみました。 Chris Miller はウィニングラップタイム 10.43 秒を達成しましたが、今後 re:Invent 2019 で行われる決勝に進み、AWS DeepRacer Championship Cup獲得を目指すことになります。AWS Summit にやってくるまで、Chris には機械学習の経験がありませんでした。 Chris は語ります。「今日ここに来た時点では機械学習は未経験でした。まさにそれを学ぶためにやって来ましたし、そのためのすばらしい手段でした」 カリフォルニア州フレモントから参加した Rahul Shah は 2 位に入りました。Rahul にとって、自身で作成したモデルが好成績を収めたことはうれしい驚きで、AWS DeepRacer はたいへん楽しいものでした。Rahul は機械学習には過去数年間取り組んできましたが、強化学習は今回が初めてでした。 「今回の取り組みは簡単でした。開発者なら誰でもうまくできますよ。DeepRacer は AWS Summit の本当に楽しくてワクワクするイベントです」と、Rahul は語ります。 3 位で完走したのはカリフォルニア州サンマテオの Adrian Sarno […]

Read More

只今準備中 – インドネシアの AWS リージョン

昨年、2 つの新しい AWS リージョンを立ち上げました。米国で 2 つ目となる GovCloud リージョンと、AWS 初となるスウェーデンの北欧リージョン です。また、南アフリカのケープタウン、イタリアのミラノでも新リージョン開設のために準備中であることを発表しました。 未来のジャカルタ 今日は皆さんに嬉しいお知らせです。現在、AWS ではアジアパシフィック (ジャカルタ) リージョンの開設に向けて作業を進めています。この新しいリージョンはジャボデタベック (グレータージャカルタ) を拠点とし、3 つのアベイラビリティーゾーンで構成されます。このリージョンは、インドネシアでワークロードを実行し、データを保存する能力を AWS のお客様とパートナーに提供します。AWS アジアパシフィック (ジャカルタ) リージョンは既存の北京、ムンバイ、寧夏、ソウル、シンガポール、シドニー、東京、そして近日利用開始となる中国 (香港特別自治区) に次いでアジアパシフィック地域で 9 つ目のリージョンとなります。 AWS のお客様はすでに、世界中で 20 のインフラストラクチャリージョンにまたがる 61 のアベイラビリティーゾーンを活用しています。今日の発表は、グローバルリージョン (運用可能なリージョンと準備中のリージョン) の合計数を 25 に引き上げます。 AWS は、インドネシアの新規および既存のお客様にサービスを提供し、アジアパシフィック全体のパートナーと連携することを心待ちにしています。AWS アジアパシフィック (ジャカルタ) リージョンを加えることで、インドネシアのお客様が、分析、人工知能、データベース、IoT、機械学習、モバイルといった各種サービスの先進テクノロジーを活用し、さらにイノベーションを推進できるように支援します。無論、新リージョンはインドネシアでデータの処理や格納をご希望の既存の AWS カスタマーにもご利用いただけます。当社は、AWS Educate、AWS Activate などのプログラムを使用して、デジタルの未来のために、インドネシアの開発者を支援しています。多くのスタートアップやアクセラレーターがそうであるように、数多くの大学やビジネススクールがインドネシアの教育プログラムにすでに参加しています。 ご期待下さい! 今回およびその他の今後の AWS リージョンに関する追加情報は、分かり次第すぐにお知らせしますので、お待ちください! — Jeff;

Read More

Amazon Comprehend が、カスタムモデルのリソースタグ付けをサポート開始

Amazon Comprehend の顧客は、カスタム分類およびエンティティタイプのモデルを使用してさまざまなユースケースを解決しています。たとえば、毎日の利用客からのフィードバックを「ロイヤルティ」、「売上」、「製品の不良」などのカテゴリに分類する分類子を構築しています。 カスタムのエンティティモデルを使用すると、在庫システムの製品 ID など、独自の用語やフレーズについてテキストを分析することができます。Amazon Comprehend は、こうしたモデルの作成から生じる複雑さを取り除きました。必要なものは、ラベルとサンプルテキストを含む CSV ファイルだけです。 使いやすさにおけるこの大きな前進のために、より多くのチームのより多くの従業員がプロジェクトのためにカスタムモデルを作成しています。このようにより多くのチームにわたってより多くのモデルが広まるため、内部的な請求および使用管理のために各モデルに関連した使用量およびコストを項目別に分類できるようにする必要があります。 このリリースでは、Amazon Comprehend のカスタム分類子およびカスタムのエンティティモデルにリソースタグを割り当てることができるようになりました。こうしたリソースにタグ付けすると、それらのリソースの使用量やコストを識別、追跡、分類するのに役立ちます。たとえば、販売テキスト分析用のモデルとマーケティングテキスト分析用のモデルがあるとします。リソースのタグ付け機能を使用すると、SDK を使用して、あるいはコードなしの AWS マネジメントコンソールで新しいモデルを作成するときに、カスタムモデルリソースにタブラベルを付けることができます。モデルに対して使用量と請求が生成されると、これらのリソースタグを使用して使用量とコストが項目化されて表示されます。 カスタムモデルの作成中にリソースタグを追加することができます。次の例は、モデルをトレーニングする準備をしている間にカスタムモデルにタグを追加する方法を示しています。 カスタム分類子およびカスタムエンティティタイプへのタグ付けの詳細については、カスタム Comprehend を参照してください。 著者について Nino Bice は、AWS の自然言語処理サービス Amazon Comprehend の製品をリードするシニアプロダクトマネージャです。            

Read More

Amazon Comprehend で KMS 暗号化のサポートが開始されました

Amazon Comprehend は完全マネージド型の自然言語処理 (NLP) サービスで、重要なワークロードに対するテキスト分析を可能にします。たとえば、市場調査を分析することで PII 情報を含む主要な市場指標やデータを洗い出します。機密性の極めて高い暗号化データを取り扱うお客様は、今後、Comprehend を活用し、AWS Key Management Service との統合を介して暗号化データを処理できるようになります。 AWS KMS により、幅広い AWS のサービスとアプリケーションにおいて、キーの生成と管理、さらに暗号化の制御が容易になります。AWS KMS はお客様のキーを保護するために、FIPS 140-2 認証済みのハードウェアセキュリティモジュールを使用する安全で回復力のあるサービスです。AWS KMS は、AWS CloudTrail と統合されており、すべてのキー使用状況のログを提供し、規制やコンプライアンスのニーズを満たすのにも役立ちます。 データへのアクセスに Comprehend で KMS キーを使用できるようにするには、AWS マネジメントコンソール経由、または SDK と Amazon Comprehend の非同期トレーニングと推論ジョブのサポートを使って設定できます。利用を開始するには、まず AWS KMS サービスでキーを作成する必要があります。  KMS キーを作成する方法について詳しくは、次のサイトをご覧ください: https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html 非同期ジョブの設定時には、Comprehend が S3 でデータにアクセスするために使用する必要のある KMS 暗号キーを指定します。以下はジョブ設定時の詳しい解説の一部として Amazon Comprehend コンソールでエイリアス「Comprehend」を選択してキーを選択するところを示した例です。 AWS KMS キーを管理するには、AWS KMS 管理ポータルにアクセスするか、KMS […]

Read More

Amazon マネージドブロックチェーンのハイパーレジャーファブリックチャネルに新しいメンバーを追加する

このシリーズの前の記事では、Amazon Managed Blockchain を使用してハイパーレジャーファブリックネットワークを構築する方法を学びました。ネットワークを作成した後、ファブリックチェーンコード、RESTful API、およびユーザーインターフェイスアプリケーションからなる 3 層アプリケーションをデプロイしました。作成したネットワークはシングルメンバーネットワークであり、ハイパーレジャーファブリックの基礎を実験および学習するのに適しています。 ただし、より堅牢なテストまたは本番シナリオでは、マルチメンバー分散ネットワークが必要になる場合があります。ネットワークのメンバーは、一般的なビジネスプロセスに参加し、データを共有したり互いに協力したりすることで利益を得る実際の組織を表す場合があります。 この記事では、パート 1 で作成したファブリックネットワークに新しいメンバーを追加します。新しいメンバーを作成し、新しいメンバーのピアノードをプロビジョニングして、ピアを既存のチャネルに参加させます。新しいメンバーを別の AWS アカウント、またはパート 1 ネットワークと同じ AWS アカウントで作成できます。この記事では異なる AWS アカウントを使用していますが、どちらの方法でも機能します。新しいピアノードがチャネルに参加したら、ブロックが新しいピアに複製されているかどうかを確認してから、チェーンコードをインストールしてトランザクションを呼び出します。ピアノードは、ファブリックネットワーク内で完全に機能するノードになり、ファブリックレジャーの独自のコピーを維持しながらトランザクションを保証および検証することができます。 アーキテクチャの概要 この記事の手順に従うと、2 人のメンバーがいるマルチメンバーネットワークになり、各メンバーは異なる AWS アカウントが所有します。各アカウントが所有するメンバーにアクセスするには、そのアカウントの VPC で実行されているファブリックのクライアントノードまたはファブリックのクライアントアプリケーションを使用します。 次の図に示すように、ハイパーレジャーファブリックの順序サービス、メンバーの認証局 (CA)、およびメンバーのピアは、マネージドブロックチェーンが管理します。VPC エンドポイントを使用して、それらのエンドポイントを顧客の VPC に公開します。顧客の VPC とマネージドファブリックネットワーク間のすべてのネットワークトラフィックは AWS バックボーンを介して発生し、パブリックインターネットには公開されません。 前提条件: マネージドブロックチェーン上に既存のハイパーレジャーファブリックネットワークがあること 前のブログ投稿と同じ Git リポジトリで、既存のファブリックネットワークに新しいメンバーを追加する手順を見つけることができます。前回の記事はパート 5 で更新されました。パート 5 を開始する前に、少なくとも 1 人のメンバーでハイパーレジャーファブリックネットワークを実行しておく必要があります。これを行うには、前の投稿のパート 1 を完了してください。パート 1 から 4 を完了しても良いですが、パート 2 から 4 […]

Read More

Amazon SageMaker の自動モデルチューニングで、ランダム検索とハイパーパラメータスケーリングをサポート

Amazon SageMaker の自動モデルチューニングで強くお勧めできる 2 つの機能、ランダム検索とハイパーパラメータスケーリングを紹介します。この記事では、これらの機能について説明し、いつどのように有効にするかについて説明し、どのようにハイパーパラメータの検索におけるパフォーマンスを向上させることができるかを示します。お急ぎの場合は、デフォルト値で実行すると、ほとんどの場合はうまく機能します。しかし、もっと詳しく知りたい場合、もっと手動で制御したい場合は、読み続けてください。 Amazon SageMaker 自動モデルチューニングを初めて使用する場合は、「Amazon SageMaker 開発者ガイド」を参照してください。 ランダム検索とハイパーパラメータの対数スケーリング使用方法の実施例については、GitHub の Jupyter ノートブックの例を参照してください。 ランダム検索 ランダム検索を使用して、Amazon SageMaker に、ランダムな分布からハイパーパラメータ設定を選択するように指示します。 ランダム検索の主な利点は、すべてのジョブを並行して実行できることです。対照的に、デフォルトのチューニング手法であるベイズ最適化は、チューニングジョブの進行につれて過去のトレーニングから学習する順序アルゴリズムです。これにより、並列処理のレベルが大幅に制限されます。ランダム検索の欠点は、匹敵するモデル品質に到達するために、一般的にかなり多くのトレーニングジョブを実行する必要があることです。 Amazon SageMaker では、以下のように、チューニングジョブを作成するときに [戦略] フィールドを [ランダム] に設定するのと同じくらい簡単に、ランダム検索を有効にすることができます。 { “ParameterRanges”: {…} “Strategy”: “Random”, “HyperParameterTuningJobObjective”: {…} } AWS SDK for Python (Boto) を使用している場合は、HyperparameterTuner クラスで strategy=”Random” に設定します。 tuner = HyperparameterTuner( sagemaker_estimator, objective_metric_name, hyperparameter_ranges, max_jobs=20, max_parallel_jobs=20, strategy=”Random” ) 次のプロットは、左側のランダム検索で選択されたハイパーパラメータと、右側のベイズ最適化で選択されたハイパーパラメータを比較したものです。この例では、モデルチューニングのノートブックの例で作成した銀行マーケティングのデータセットを使用して、XGBoost アルゴリズムを調整しました。視覚化するために、alpha […]

Read More

Amazon DocumentDB の新しい集約パイプライン機能を使いパワフルな集約型クエリを記述する

 Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージド型のドキュメントデータベースサービスです。お客様は、現在ご使用のものと同じ MongoDB 向けアプリケーションコードや、ドライバー、およびツールを、そのまま Amazon DocumentDB 上で実行や管理をしたり、処理負荷の調整などに使えます。これにより、基本インフラストラクチャの管理に煩わされることなく、向上したパフォーマンス、スケーラビリティ、および可用性を活用することが可能です。 2 月のブログで解説した機能を基に、 今回、Amazon DocumentDB に新たな集約パイプライン処理に関するサポートが追加されました。この新機能には以下のものが含まれます。 7 個の集約文字列演算子 ($indexOfCP、$indexOfBytes、$strLenCP、$strLenBytes、$toLower、$toUpper、$split) 9 個の日付時間演算子 ($dayOfYear、$dayOfMonth、$dayOfWeek、$year、$month、$hour、$minute、$second、$millisecond) $sample 集約パイプラインステージ このブログでは、一般的なユースケースとして上記演算子の使用法を示しながら、そこに新しく加わった機能をご紹介していくことにします。 Amazon DocumentDB の使用開始 Amazon DocumentDB の初心者の方は、次のいずれかから使用を開始することができます。 Amazon DocumentDB の開始方法 Amazon DocumentDB Quick Start Using AWS CloudFormation Getting Started with Amazon DocumentDB (YouTube 動画)  新機能 Amazon DocumentDB クラスターを作成して接続したら、次の例をよく理解して拡張することができます。 1.集約文字列演算子 ドキュメント内に格納された文字列は、多様な利用法に応じ、必要とされる部分ごとに分けて取り出す操作が可能です。この文字列では、追加の処理や比較、あるいはデータのクリーンアップなどが行えます。アプリケーションコードで文字列処理を記述しなくても、集約文字列演算子を用いてデータ処理をデータベース内に落とし込むことができます。現状で、Amazon […]

Read More

Docker、Amazon ECS、スポットフリート: 素晴らしい組み合わせ

AWS コンテナのヒーロー、Tung Nguyen による寄稿。Tung は、AWS のクラウドインフラストラクチャとソフトウェアに焦点を当てたコンサルティング会社、BoltOps の社長兼創立者です。また、BoltOps Nuts and Bolts ブログの執筆も楽しんでいます。 EC2 スポットインスタンスでは、大幅な割引で予備の計算容量を使うことができます。Amazon ECS をスポットインスタンスと共に使用することは、おそらく AWS でワークロードを実行するための最良の方法の 1 つです。スポットインスタンスを使用すると、Amazon EC2 インスタンスで 50 ~ 90% を節約できます。この話を聞いたら、ブラックフライデー特別割引のような大きなチャンスに飛び込みたいと思うでしょう。しかし、ほとんどの人はスポットインスタンスについて知らないか、ためらってしまいます。これは、スポットに関するいくつかの誤った認識が原因である可能性があります。 スポットに対する誤った認識 スポットモデルでは、AWS はいつでもインスタンスを削除できます。これは、メンテナンスのアップグレード、そのインスタンスタイプに対する高い需要、古いインスタンスタイプ、または何らかの理由によるものである可能性があります。 そのため、人々はスポットに対して、最初はすぐ恐怖や誤った認識を持つようになります。 インスタンスをいつでも置き換えることができるというのは、どういう意味ですか? いいえ、インスタンスを起動してから 20 分以内に抹消されるという意味です。 私も最初は同じように感じました。実際、スポットインスタンスアドバイザーのウェブサイトには、次のように記載されています。 全リージョンとインスタンスタイプにわたる中断の平均頻度は 5% 未満です。 私自身の使用状況から、私はインスタンスが数週間実行されることを確認しました。証明が必要ですか? これは、当社の本番環境クラスターの 1 つのインスタンスからのスクリーンショットです。 何日なのかが気になるとおっしゃるなら… はい、228 日間連続です。これと同じくらい長い時間は稼働しないかもしれませんが、スポットインスタンスが、通常、開始から 20 分以内に中断されるという誤った認識は否定できます。 スポットフリート スポットインスタンスでは、特定のアベイラビリティーゾーンにある特定のインスタンスに対して、単一のリクエストを行います。スポットフリートでは、単一のインスタンスタイプをリクエストする代わりに、要件を満たすさまざまなインスタンスタイプを要求できます。多くのワークロードでは、CPU と RAM が十分に近い限り、インスタンスタイプの多くでは順調に動作します。 そのため、スポットフリートを使用して、インスタンスタイプと複数のゾーンにインスタンスベットを分散させることができます。スポットフリートを使用すると、すでに述べたように中断率が低いことに加え、システムが劇的に堅牢になります。また、オンデマンドクラスターを実行して、追加の保護機能を提供することもできます。 ECS、スポットフリート: 素晴らしい組み合わせ スケーラブルなシステムを非常に低いコストで実現できるため、これはワークロードを実行するためのお気に入り方法の […]

Read More

【開催報告】AWS Data Lake ハンズオンセミナー 2019 春

こんにちは。AWS ソリューションアーキテクトの上原誠(@pioh07)です。 4月5日に、「AWS Data Lake ハンズオンセミナー」を開催いたしました。去年から行ってきた恒例のワークショップで第6回目となります。去年も盛況でしたが、今回も100名くらいのお客様にご参加頂きました。 はじめに、AWSにおけるデータ活用のベストプラクティスである Amazon S3 を中心とした Data Lake について解説し、ビッグデータ分析基盤の考え方として有名なラムダアーキテクチャの解説を行いました。 当イベントでは、Amazon Athena や Amazon Redshift の各 AWS サービスを駆使して実際にラムダアーキテクチャを構築することがゴールです。とはいえ全てを構築するのはボリュームが大きいため、スピードレイヤー or バッチレイヤー or 全部入りでコース分けて取り組めるようハンズオンコンテンツを用意しました。最初にコースの説明を行い、出席いただいたお客様ご自身の課題に合わせてコースを選択頂き、ハンズオンを行っていただきました。今回、参加者も多くいらっしゃいましたので、サポートするソリューションアーキテクトも4名で対応させていただきました。 今回参加できなかった方も、ソリューションアーキテクトのサポートを受けながらハンズオンを行いログ分析を初めてみてはいかがでしょうか?   次回は初夏ごろに開催予定です。ご参加お待ちしております。    

Read More