Category: Amazon DynamoDB

CyberZ について CyberZ はスマートフォンに特化した広告マーケティング会社として 2009 年に設立しました。スマートフォン広告における運用・効果検証、交通広告やウェブ CM の制作など、幅広いマーケティング事業を展開しています。日本に加えて、サンフランシスコ、韓国、台湾にも支社を構え、国内広告主の海外進出および海外広告主の日本展開支援も行っています。また、メディア事業として動画配信プラットフォーム「 OPENREC.tv 」、 e スポーツ事業として、国内最大級のeスポーツイベント「 RAGE 」を運営しています。 CyberZ 100 % 子会社としては、オンラインエンタテインメント事業、プロダクション事業をおこなう「株式会社 eStream 」、 e スポーツに特化した広告マーケティング事業「株式会社 CyberE 」の事業展開をしています。 ​ ​ OPENREC.tv はゲーム配信を中心とした高画質・低遅延のライブ配信プラットフォームサービスです。 Wowza Streaming Engine / Low Latency HLS を使用した遅延の少ない配信基盤や、 Redis / Socket.io を利用したリアルタイムチャット機能などを AWS 上で構築しており、リレーショナルデータベースは Amazon Aurora を、 NoSQL は Amazon DynamoDB や Amazon ElastiCache (Redis) を使用しています。 ​ […]

Amazon AthenaはS3上に置かれたファイルにクエリ（SQL）を実行できるサーバレスのサービスです。先日GAしたFederated Query機能を利用すると、クエリの範囲をS3に加えて多数のデータソース（例えば他のRDBやAmazon DynamoDB等）に広げ、複数のデータソースにまたがってSQL処理することが可能になります。（Federated Queryの機能説明はこちらにあります） 先日(4/17)、「AWSの基礎を学ぼう」というオンライン勉強会に講師として呼んでいただく機会があったので、このFederated Queryを使ったハンズオンキットを作成しました。今回これをダウンロード可能にしましたので、紹介します。

業界を取り巻く環境 世界的なパンデミックが日本にも影を落としている中、ストリーミングを使ったライブイベントの配信が驚異的な伸びを示しています。2020年の早い段階から、大規模なイベントや対面集会が次々に中止に追い込まれました。オリンピックが延期され、プロスポーツは無観客となりました。企業においても入社式や集合教育、株主総会といったものがソーシャルディスタンスの導入により大きな影響を受けています。この流れの中、ライブイベント配信を支える企業にはこれまで無縁だったビジネスを含め、様々な業界から無数の依頼が舞い込んでおり、その全てに対応するには非常に難しい環境にあります。

本投稿は、Sr.Solutions Architect, Developer Acceleration の Tim Bruce よる記事を翻訳したものです。 ゲーム開発は、要件が急速に変化するため非常に繰り返しの多いプロセスです。ゲーム開発者の多くは、可能な限り多くの時間を機能の構築のために費やしたいと思っており、サーバー設定、インフラストラクチャ管理、スケーリング技術の習得に時間を費やしたくないと考えています。 AWS のサーバーレスサービス を利用することで、4つの大きなメリットが得られます。1つ目は、運用オーバーヘッドを削減することで、企画からリリースまでのプロセスを短くします。2つ目は、運用に必要なハードウェアとソフトウェアを過剰にプロビジョニングしないため、コスト削減を実現できる可能性があります。3つ目は、サーバーレスはユーザーのアクティビティに応じてスケールします。最後は、サーバーレスサービスには組み込みの統合機能があるため、サービス統合に労力をかけることなくゲーム開発に集中できます。 AWSを利用するゲーム開発者は、これらのメリットを活用することで、チームがサーバーやソフトウェアのセットアップや保守といった差別化につながらないタスクに時間を費やすのではなく、ゲーム体験の向上やコンテンツ開発により多くの時間を費やすことができます。これにより、ゲーム体験とコンテンツがより良いものとなり、リリースまでの時間も短縮されます。 本ブログ記事では、「サーバーレスファースト」アーキテクチャを持つゲームについて紹介します。 Simple Trivia Service はウェブベースのゲームであり、貴社のゲームにも適用可能な複数のアーキテクチャパターンを持っています。

多くのゲームでデータベースが不可欠の部分であることは周知の事実です。けれども、ゲーム開発者としては、データベースのエンジニアリングではなく、優れたゲームの構築にすべての時間と専門知識を捧げたいでしょう。 わかります。私も、データストレージについて考えるのではなく、コリジョンボリュームの修正、フレームレートの引き上げ、あるいは完璧な制御システムの作成に気をかけたいです。では、それを簡単に行いましょう。この記事では、AWS の高速で柔軟な NoSQL サービスである Amazon DynamoDB を使用して、ゲームにデータベースを追加するのがいかに簡単であるかを示します。 DynamoDB は、キーをデータに関連付ける非リレーショナルデータベースです。データベース、特にゲームでの使用に詳しくない場合は、ゲームでのデータベースの基本的な使用法と、リレーショナルデータベースと非リレーショナルデータベース (ときに SQL と NoSQL と呼ばれる) の違いについて説明したこの記事「素晴らしいゲームのためのマネージドデータベース」をご覧ください。 Dynamo DB テーブルの作成 DynamoDB は、NoSQL データベースですが、SQL データベースから借用した用語テーブルを使用します。この場合のテーブルは、実際にはデータベースに格納されるアイテムの主要な機能を定義したものにすぎません。 DynamoDB には、テーブルを識別するためのテーブルのプライマリキーが常にあり、このキーはデータベースに保存されているすべてのアイテムに対して一意である必要があります。 便利なヒントは、プライマリキーが複数の値のハッシュになる可能性があることです。したがって、単一の一意の属性がない場合は、異なる属性を組み合わせて一意の値を作成できます。たとえば、名前とバージョン番号を持つアイテムです。「broadsword」という名前のアイテムは 10 個あり、「version 1」のアイテムは 100 個ありますが、「broadsword version 1」は 1 個しかありません。 DynamoDB には、オプションで、アイテムをすばやく並べ替えることができるソートキーもあります。たとえば、プレイヤーのソートキーはプレイヤークラスであるかもしれません。これにより、ゲーム内のすべてのファイタークラスのリストを取得するクエリが高速化されることでしょう。データベース内のアイテムを一意に識別するための代替方法でするセカンダリキーを持つこともできます。 このデモでは、プレイヤーキャラクターの属性を表す非常にシンプルなオブジェクトを作成します。オブジェクトには一意のプレイヤー ID、プレイヤーレベル、強さと知力の 2 つの統計が含まれます。プレイヤー ID がプライマリキーになり、このデモ用のソートキーやセカンダリキーはありません。 注意: 自分で練習したい場合は、ソートキーとして機能するプレイヤークラスを追加できます。 DynamoDB テーブルを作成する手順は次のとおりです。 AWS コンソールを開きます。 DynamoDB を検索して選択します。 DyanamoDB コンソールのホームページから [テーブルの作成] を選択します。 […]

AWS 公共部門ブログチームより、 米国のNPOがどのようにクラウドを用いて「投票」という伝統的行為をアップグレードし、「投票率」の向上に繋げているか ──その事例を以下にご紹介します。 ＊　＊　＊　＊ 生まれ育った実家から遠く離れた街に住んでいるために、選挙での投票機会をこれまで何度か逃したことのある大学院生 Seth Flaxman は、友人でありクラスメートでもある Kathryn Peters と一緒に、投票期日の予告をしてくれる「リマインダーシステム」を構築しました──これで、再び選挙を逃すことはありません。投票をシンプルでシームレスな体験にするというビジョンをかかげ、Seth と Kathryn は、多くの若者が投票機会を逸してしまうという”現状”を変えるための無党派のNPO（非営利組織）である 「Democracy Works」を立ち上げました。 Democracy Works は、民主主義のインフラストラクチャをアップグレードし、有権者と選挙管理人の双方にとって「投票者エクスペリエンス」を向上させるために必要な「ツール」の構築に着手しました。Democracy Works のフラッグシップ・プロジェクトである 「TurboVote」 は、地方自治体から全国規模まで、あらゆる種類の選挙で「有権者自身の登録～そしてその登録の管理～実際の投票」までの流れを支援する取り組みです。国内最大規模の大学、NPO、そして投票率を高めたいと願う多数の企業が連帯した効果もあり、2018 年には TurboVote に登録した有権者は 600 万人に達しました。 AWS によりTurboVoteはスケール TurboVote の取り組みが、初めて 100 万人のユーザーに到達するまでに、Democracy Works は 5 年を費やさねばなりませんでした。しかしその後、AWSクラウドを活用したスケーリングにより、2018 年だけで記録的な 500 万人の新規ユーザーにサービスを提供することができました。 TurboVote のように特定のイベントで利用がスパイクしがちなツールにおいては、長期間にわたり訪問者数が少ない時期もありますが、他方で連邦選挙が近づく時期には、1 週間で数百万人のサイト訪問者を受け入れることになります。Amazon EC2 と Amazon DynamoDB を使用するとオンデマンドでリソースを拡張できるため、TurboVote は、年間を通じて専用のインフラストラクチャに料金を支払うことなく、アクセスが多い日にのみ、数万人もの同時ユーザーのアクセスを処理することができます。 前回2018年の中間選挙があった11 月 6 日に向け、 […]

 Amazon DynamoDB などの NoSQL データベースを使用する場合、リレーショナルデータベースで慣れているものとは異なる最適化を選択する傾向があります。リレーショナルデータベースの経験から、最初は別の方法で実行するように指示されていたため、簡単ではありませんでした。 これを支援するために、AWS は Windows および macOS で利用可能なクライアント側アプリケーションである Amazon DynamoDB 向け NoSQL Workbench をリリースしました。これを使用して、スケーラブルで高性能なデータモデルを構築し、クエリの開発とテストを簡素化できます。NoSQL Workbench を使用すると、次のことができます。 1 つ以上のテーブルを使用してデータモデルを定義します。 データモデルを視覚化して、さまざまなシナリオでどのように機能するかを理解します。 複数のプログラミング言語用のデータプレーン操作を構築します。 このブログ記事では、一般的に利用可能になった NoSQL Workbench を使用して、複数の顧客の URL ブックマークの管理という一般的なユースケースのデータモデルを設計しています。比較的ユースケースが単純な場合でも、多くの興味深い考慮事項があります。 データモデラー このアプリケーションでは、ブックマークと顧客アカウントに関する情報を保存する必要があります。まず、保存したい属性のリストを、保存する予定の簡単な説明とともに書き留めます。 顧客 customerId – ユニバーサル一意識別子 (UUID) email fullName ­– 例: “Shirley Rodriguez” userPreferences – アプリのユーザー設定を記述する JSON オブジェクト creationDate updateDate ブックマーク URL – “https://…” customerId […]

Amazon DynamoDB では、1 か月あたり数リクエストから 1 秒あたり数百万のリクエストまで、簡単にスケーリングできる完全マネージド型のキーバリューデータベースサービスをお客様に提供しています。DynamoDB は、あらゆる規模で一貫した 1 桁のミリ秒の応答時間を実現することにより、世界最大規模のアプリケーションを複数サポートしています。実質的に無制限のスループットとストレージでアプリケーションを構築できます。DynamoDB グローバルテーブルは、データを複数の AWS リージョンにレプリケートして、グローバルに分散されたアプリケーションのデータにローカルで高速にアクセスできるようにします。マイクロ秒のレイテンシーでさらに高速なアクセスが必要なユースケースでは、DynamoDB Accelerator (DAX) が完全マネージド型のインメモリキャッシュを提供しています。 2019 年 11 月に、Amazon DynamoDB の Amazon CloudWatch Contributer Insights をプレビューとして発表しました。本日、すべての AWS リージョンで一般的にご利用いただけるようになったことをお知らせします。 Amazon DynamoDB の Amazon CloudWatch Contributer Insights 2019 年 11 月に開始された Amazon CloudWatch Contributor Insights は、ログデータを分析し、時系列視覚化データを作成して、システムパフォーマンスに影響を与える上位のコントリビューターを確認できるようにしています。これを行うには、Contributor Insights ルールを作成して、CloudWatch Logs (AWS のサービスからのログを含む) と、自社のサービスまたはオンプレミスサーバーから送信されたカスタムログを評価します。たとえば、不良ホストを見つけたり、最も重いネットワークユーザーを特定したり、エラーを最も多く生成している URL を見つけたりできます。 DynamoDB の上にアプリケーションを構築する開発者にとっては、トラフィックの傾向や頻繁にアクセスするキーなどのデータベースアクセスパターンを理解して、DynamoDB のコストとパフォーマンスを最適化するのに役立ちます。DynamoDB […]

この記事は、Amazon DynamoDB へのデータの取り込みに今日どのようなソリューションが存在するかを再検討するとともに、Amazon S3 バケットから DynamoDB テーブルへの CSV ファイルの一括取り込みのための能率化されたソリューションについて説明して、AWS アカウントへの簡単なデプロイメントのために、このソリューションの AWS CloudFormation テンプレートを提供します。 Amazon DynamoDB は、規模を問わず 1 桁台のミリ秒でのパフォーマンスを実現する key-value /ドキュメントデータベースです。今日、AWS の何十万人ものお客様が、モバイル、ウェブ、ゲーミング、アドテクノロジー、IoT、および低レイテンシーのデータアクセスを必要とするその他アプリケーションのために DynamoDB の使用を選択しておられます。一般的なユースケースは、DynamoDB へのデータの一括取り込みの実装です。大抵の場合、このデータは CSV 形式であり、すでに Amazon S3 内に保存されている場合があります。この一括取り込みは移行取り組みを迅速化するための鍵であり、取り込みのパイプラインジョブを設定する必要性を軽減し、全体的なコストを削減して、Amazon S3 からのデータの取り込みをシンプル化します。 この記事では、DynamoDB に加えて、ソリューションを作成するために AWS の以下のサービスを 200～300 レベルで使用します。 Amazon S3 AWS Lambda AWS CloudFormation 前提条件 この記事のソリューションを完成させるには、以下が必要です。 AWS アカウント。 DynamoDB、Amazon S3、Lambda、および AWS CloudFormation にアクセスできる IAM ユーザー。 DynamoDB […]

これは、TVer Technologies Inc. のソフトウェアエンジニアであるウツミケイスケ氏によるゲスト投稿です。同社の言葉を借りると、「 TVer Technologies Inc. は、テレビ放送と同期されたウェブサイトを利用して、ユーザーにインタラクティブなエンターテイメントサービスを提供しています 」との事です。 TVer Technologies Inc. は、日本のテレビ視聴者向けにウェブサイトとアプリベースのインタラクティブコンテンツを提供しています。当社のアプリケーションの多くは、Amazon DynamoDB をデータベースとして使用して、登録ユーザー情報を保存し、テレビ放送中のライブ投票イベントでユーザーの投票活動の履歴を記録します。当社のアプリケーションは、毎朝の番組や季節ごとのポップミュージック番組でよく用いられています。このブログ記事では、DynamoDB のオンデマンド読み取り/書き込みキャパシティーモードを使用して、TV ライブ投票イベントで使用されるシステムのコストとパフォーマンスを最適化する方法を確認します。 視聴者の投票期間はテレビ番組の放映時間に制限されているため、ほとんどのライブ投票プロジェクトでは、ユーザーアクセスは数時間しか見られません。この数時間で、アクセスリクエストが急増するのはほんの数分間です。ピーク時以外のワークロードは、ピーク時と比較してほとんどありません。両者を比べると、1:100 または 1:10,000 の割合です。 次のグラフは、視聴者をウェブサイトに投票させるテレビ番組中のウェブサービスへのアクセスリクエストの記録を示しています。投票がなかったときは、視聴者からの投票活動へのアクセスがないため、リクエストはありませんでした。具体的には、19:30 から 20:15 の間、ユーザーからの投票アクティビティがなかったため、リクエストはありませんでした。それから 20:15 に、視聴者が投票を開始し、システムがユーザーのデータを記録し始めたため、数分間スパイクが見られました。プログラムが 22:30 に終了するまで、投票時間中に短いスパイクが繰り返されるこのパターンが不規則に広がっています。Amazon CloudWatch Logs がレコードを収集したため、数値は 1 分あたりの平均値です。ピーク時に記録された実際の数は、非ピーク時の 2～3 倍でした。 Amazon DynamoDB オンデマンドを使用する理由 このケースでは、Amazon DynamoDB オンデマンドが最も有用であることがわかりました。DynamoDB の Auto Scaling を使用することもできましたが、TV プログラムでの計画外のプロモーションが原因でリクエストが突然または予期せず急増した場合、DynamoDB の Auto Scaling では十分に早く追いつけないでしょう。DynamoDB オンデマンドを使用すると、お金を節約し、手動による介入を減らすことができ、遅滞がありません。 一部のライブプログラムには、プログラム中、イベントの厳密なスケジュールがありません。したがって、トラフィックが急増する時間帯を事前に予測することは困難です。ピーク時のトラフィックに備えて DynamoDB のキャパシティーを事前にプロビジョニングした場合、実際にピークがいつ発生したかに関係なく、そのリソースに対して料金を支払う必要があります。DynamoDB […]