Amazon Web Services ブログ

Lumberyardのここ2回のリリースでは新たな基本システムをご紹介しましたが (EMotion FX や Script Canvas)、次の2回のリリースではこれらのシステムの最適化とエンジン全般の利用のし易さにフォーカスします。その第一弾としてLumberyard Beta 1.13をリリースしました！ Lumberyard Beta 1.13 のダウンロードはこちら 皆様からの様々なフィードバックにより200以上の機能向上、および安定性と使い易さを向上させられたことに感謝いたします。また、新たなクラウド機能によりエキスパートエンジニアの手を借りずに素晴らしいゲームプレイ体験を制作することに集中していただけます。今回の主な機能をご紹介させていただきます。 1. Gemの相互連携 Cloud gemに動的コンテンツ、リーダーボードやデイリーメッセージ等の有用なクラウド機能を簡単に実現できます。新たに1.13では、APIを公開して各バックエンドサービスを相互に利用できるようになりました。別の言い方をすると、Gemとの統合により更に複雑な機能をゲーム内に実現可能となります。 例えば、デイリーメッセージGemから、テキストスピーチGemを利用して音声合成しプレイヤーに語りかける事ができますプレイヤーアカウントGemとリーダーボードGemと連携して不正アカウントのスコアの削除して、プレイヤーの満足度向上にお役立ていただいたりできます。さらに音声合成によるゲーム内アンケートの確認や、プレイヤーの音声によるフィードバックを音声認識Gemで取得等々、これらも組み合わせの1例でしかなく、さらなる皆様のお取り組みを楽しみにしております。 2. 音声合成のカスタマイズ Text to Speech Cloud Gemも向上させました。Cloud Gem PortalでのSSML（Speech Synthesis Markup Language：音声合成マークアップ言語）対応も含め、より詳細に音質やアクセントを制御可能となりました。例えば米国英語音声でフランス語のフレーズを喋らせるような事も可能です。また、管理画面でのフィルタリング機能や音声パッケージの管理機能の向上等も行われました。 SSMLにより、合成される音声の音質・トーン・ペース等を柔軟に制御できるようになり、ゲーム内のモブキャラクターやカットシーンでの仮対応等を低コストに実現できます。 3. PhysX Gem（プレビュー） 今回のリリースには、NVIDIA PhysX Gemも含まれ、リアルなコリジョン判定や剛体シミュレーションの作成ができるようになります。Project ConfiguratorでGemを有効にしていただくことで、以下のコンポーネントをエンティティに追加できるようになります。 PhysX Collider – エンティティーのPhysX Mesh ShapeもしくはPhysX Rigid Body Physicsタイプのアサインされたシェイプコンポーネントをリンクすることで、コリジョン反応を提供できます。 PhysX Mesh Shape – コリジョン領域のジオメトリを提供します。 PhysX Rigid Body […]

この記事では、Oracle データベースから Amazon Aurora PostgreSQL データベースへの移行プロセスのデモを行うために、リソースをデプロイする AWS CloudFormation スタックを構築します。これは異種間移行であるため、How to Migrate Your Oracle Database to PostgreSQL で詳しく説明されているものと同様の 2 フェーズのアプローチに従います。 この記事は、AWS Schema Conversion Tool (AWS SCT) と AWS Data Migration Service (AWS DMS) の中核的な概念をより良く理解するために役立つ移行スタックの構築に焦点を当てます。また、データベースパラメータグループを使用して、移行のためにターゲットの Amazon Aurora PostgreSQL データベースでトリガーを無効化する方法についても説明します。 今回は、AWS DMS で Oracle データベース (HRDATA) が事前にインストールされた Amazon EC2 インスタンス、Amazon Aurora PostgreSQL クラスター、およびレプリケーションインスタンスをデプロイするために AWS CloudFormation を使用します。移行プロセスに役立てるため、Amazon Virtual Private […]

こんにちは、ソリューションアーキテクトの江原です。 先日(2018/3/27)開催致しました AWS Black Belt Online Seminar「AWS IoTでのデバイス管理、運用について」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の回答と併せてご紹介致します。

Felipe Garcia と Hugo Rozestraten は  Amazon Web Services の  Solutions Architect です。 この記事では、実際のお客様の事例をもとに、Amazon Redshift の前段に pgpool と Amazon ElastiCache を使ってキャシングレイヤを構築する方法を紹介します（訳注：原文執筆時にはRedshiftにキャッシュ搭載されていなかったのですが、現在はRedshiftには結果キャッシュの機能が備わっているため、キャッシュするだけのためにこのようなソリューションを作成する必要はありません。しかしpgpoolはキャッシュ以外にも利用できる柔軟なソリューションであり、それを分かりやすく示している資料として価値があるため、翻訳記事を掲載しています） 近年、業務アプリケーションはほとんどの場合データベースの利用を想定して構築されます。SQLによるデータベースへのクエリは広く普及した技術ですが、エンドユーザとアプリケーション間の協調を意識しないアーキテクチャ設計が、まったく同一のクエリの複数回実行といった無駄な処理を時として発生させます。このような冗長な処理は計算資源の無駄遣いであり、こういった無駄を省くことができれば他の処理に計算資源を有効活用することができるようになります。 キャッシュとは コンピュータ用語としてのキャッシュは、将来発生し得るリクエストに迅速に回答するためにデータを事前に蓄積しておくハードウェアコンポーネントまたはソフトウェアコンポーネントを指します。また、必要なデータがキャッシュの中に見つかることをキャッシュヒットといい、必要なデータがキャッシュの中に存在しないことをキャッシュミスといいます。キャッシュの存在により、重い計算の再実行や遅いデータストアからの読み出しが発生しなくなり、高速に結果を得られるようになります。より多くの要求がキャッシュで処理できれば、システムはより高いパフォーマンスを発揮することができます。 お客様事例：臨床研究での遺伝子情報の検索 この事例では、6-10名程度からなる科学者のチームが200万からなる遺伝子のコードの中から特定の遺伝子変異を探し出します。特定の遺伝子変異に隣接する遺伝子も重要な遺伝子で、これらにより異常や病気などが特定できるようになります。 科学者たちは、1つのDNAサンプルをチームで同時に解析し、その後ミーティングを開き自分たちの発見について議論し、結論へと到達します。 この事例では、Node.js のウェブアプリケーションにロジックを実装し、Amazon Redshift にクエリを発行しています。Amazon Redshfit に直接接続したアプリケーションでは、クエリのレイテンシは約10秒でした。アーキテクチャを変更しpgpoolを使用するようにしたところキャッシュにヒットした際に1秒未満で同一のクエリの結果を得られるようになりました。(言い換えると、キャッシュヒット時に10倍高速に応答できるようになりました。)　（訳注：現時点ではRedshiftに結果キャッシュの機能が存在するため、こういった仕組み無しでもキャッシュヒット時に高速な応答が実現されています） Pgpoolの紹介 Pgpool はデータベース・クライアントとデータベース・サーバの間で動作するソフトウェアです。リバースプロキシとして動作し、クライアントからの接続要求を受け、サーバへとそれをフォワードします。もともと PostgreSQL のために書かれており、キャッシング以外にも、コネクションプーリング、レプリケーション、ロードバランシング、コネクションキューイングといった機能を備えます。本稿では、キャッシング機能のみを検証しています。 Pgpool は、Amazon EC2 上でも、オンプレミス環境でも動作させることができます。たとえば、開発やテスト目的でEC2のシングル構成をとるこもできますし、本番環境のために Elastic Load Balancing 、Auto Scaling 構成のEC2複数台構成をとることもできます。 臨床研究の事例では、psql(コマンドライン)と Node.js アプリケーションから Amazon Redshift に対してクエリを発行していて、実際に期待通りに動作することが確認できています。ご自身の環境に適用する場合には、十分な検証を経た上での採用をおすすめいたします。   […]

Amazon ECS でサービスディスカバリがサポートされました。これにより、ECS サービスが Amazon Route 53 の予測可能でフレンドリーな DNS 名で自動的に登録することができるようになります。負荷やコンテナの健全状態に対応してサービスがスケールアップまたはダウンすると、Route 53 のホストゾーンは最新の状態が保たれ、他のサービスが各サービスの状態に基づいてコネクションを行う必要がある場所を発見できるようになります。次のアドレスで、架空のソーシャルネットワークアプリでサービスディスカバリのデモを見ることができます。https://servicediscovery.ranman.com/. サービスディスカバリ マイクロサービスや最新のアーキテクチャへの移行の一部には、障害や変化する負荷に迅速に対応できるダイナミックで、オートスケーリングでき、そして堅牢であるサービスを持つことが必要とされます。皆さんのサービスはおそらく、依存したり利用されるサービスが複雑に関連した依存関係のグラフ構造を持っているでしょう。最新のアーキテクチャのベストプラクティスは、これらのサービスが独自に依存関係を指定できるようにして疎結合にすることですが、ダイナミックな環境では各サービスが自力で自身が接続する先を見つける必要があるため、複雑になってしまう場合があります。 consul、etcd、またはzookeeperなどのサービスディスカバリの従来のアプローチは、すべてこの問題をうまく解決しますが、追加のインフラストラクチャをプロビジョンして管理する必要や、コンテナやインスタンス上にエージェントをインストールする必要があります。これまでは、サービスが互いに発見して接続できるように、独自のサービスディスカバリーシステムを構成して実行するか、すべてのサービスをロードバランサに接続する必要がありました。これからは、ECS コンソール、AWS CLI、または ECS API を使用して、コンテナ化したサービスのサービスディスカバリが可能になります。 Amazon Route 53 サービスレジストリとAuto Naming API の紹介 Amazon ECS サービスディスカバリは、Amazon Route 53 サービスレジストリと Auto Naming API とコミュニケーションすることにより動作します。このブログではこれまでそれらについて触れていないため、ここでは簡単にこれらの Route 53 API の動作について概説したいと思います。最初に、一部の用語について説明します。 名前空間 – 名前空間は、トラフィックを流すドメイン名を指定します (例: internal、local、corp)。これは、サービスが互いに発見できる論理的境界と考えることができます。名前空間は、 aws servicediscovery create-private-dns-namespace コマンドの呼び出しまたはECS コンソールで作成することができます。名前空間は、Route 53 のホストゾーンとほぼ同じです。名前空間にはサービスが含まれます。これは次に取り上げる用語です。 サービス – サービスは「auth」、「timeline」、「worker」などの名前空間にある特定のアプリケーションまたはアプリケーションのセットです。サービスはサービスインスタンスを含みます。 […]

こんにちは、ソリューションアーキテクトの玉井です。 先日(2018/3/22)開催致しました AWS Black Belt Online Seminar「AWS Snowball Edge」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の回答と併せてご紹介致します。

Hadoop User Experience (Hue) は、Amazon EMR および Apache Hadoop で使用する、オープンソースでウェブベースのグラフィカルユーザーインターフェイスです。Hue データベースには、ユーザー、グループ、許認可、Apache Hive クエリ、Apache Oozie ワークフローなどが格納されています。 Hue データベースを新しい EMR クラスターに移行したいとしましょう。例えば、Amazon EMR AMI (Amazon Machine Image) の古いバージョンからアップグレードしたいとします。Hue アプリケーションとそのデータベースには、数多くのカスタマイズがあります。これらのユーザーエンティティの再作成は必要なく、さらに既存の Hue データベースまたは Amazon RDS のリモートデータベースを新しいクラスターに移行することで、Hue のクエリとワークフロー履歴を保持する必要もありません。 デフォルトでは、Hue のユーザー情報とクエリ履歴は、EMR クラスターのマスターノード上のローカル MySQL データベースに格納されます。ですが、Amazon S3 に格納されている構成とリモートの MySQL データベースを Amazon RDS で使用して、1 つ以上の Hue 対応クラスターを作成できます。これにより、Amazon EMR クラスターを稼動させずに、Hue で作成するユーザー情報とクエリ履歴を保持することが可能となります。 この記事では、既存の EMR クラスターから Hue データベースへ移行するための手順を、ステップバイステップで説明します。

AWS DMS を完全に管理できるように、レプリケーションインスタンスの移行ログを管理する機能をAWSは導入しました。この機能を使用することで、特定のレプリケーションインスタンスの各タスク用のログがどれくらいストレージを消費しているかを確認することもできます。さらに、この機能を利用すると、あなたが都合の良いときにログファイルをパージできます。

こんにちは、ソリューションアーキテクトの有岡です。 先日(2018/3/19)開催致しました AWS Black Belt Online Seminar「データウェアハウスのAWSへの移行」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の回答と併せてご紹介致します。

Amazon DynamoDBチームはencryption at restに引き続き新しい機能を発表しました。AWS re:Invent 2017 では、グローバルテーブルの作成と DynamoDBテーブルのオンデマンドバックアップとリストアを発表しました。そして今日、継続的バックアップとしてPITR（ポイントインタイムリカバリ）を利用出来るようになりました。 AWS Management Consoleからワンクリックするか、簡単なAPIコール、またはAWSコマンドラインインターフェイス（CLI）を使用して継続的バックアップを有効にすることができます。DynamoDBはPITRが有効になってから35日以内であれば1秒単位でデータをバックアップし、1秒単位でリストアできます。誤った書き込みや削除を防ぐためにこの機能を構築しました。開発者がステージングではなくプロダクションに対してスクリプトを実行した場合や誤ったDeleteItemを実行した場合はPITRでカバー出来ます。その為予測できないようなシナリオにも利用出来ます。オンデマンドバックアップはアーカイブ目的のために必要なタイミングを指定できますが、PITRは偶発的なデータ消失に対する追加の保険として機能します。これがどのように機能するか見てみましょう。 継続的バックアップ マネジメントコンソールでこの機能を有効にするには、テーブルに移動して[ バックアップ ]タブを選択します。そこから、Enableをクリックするだけで有効になります。また、UpdateContinuousBackups API呼び出しを使用して継続的バックアップを有効にすることもできます。 継続的バックアップを有効にした後、最も遠い復元日と最新の復元日時を確認出来ます。 削除したい古いユーザーデータがたくさんある、というシナリオを例にとってみます。 私はlast_updateに格納されている日付に基づいてアクティブなユーザーだけに通知を送信したいと考えました。そしてサービスを使用していないユーザーを削除するために簡単なPythonスクリプトを書くことに決めました。 import boto3 table = boto3.resource(“dynamodb”).Table(“VerySuperImportantTable”) items = table.scan( FilterExpression=”last_update >= :date”, ExpressionAttributeValues={“:date”: “2014-01-01T00:00:00″}, ProjectionExpression=”ImportantId” )[‘Items’] print(“Deleting {} Items! Dangerous.”.format(len(items))) with table.batch_writer() as batch: for item in items: batch.delete_item(Key=item) すばらしい！これでサービスに2013年以来ログインしていない厄介な非アクティブユーザをすべて削除するはず・・・CTRL + C CTRL + C CTRL + […]