Amazon Web Services ブログ

こんにちは。ゲームソリューションアーキテクトの吉田です。 昨日1/24(水)に第２回となるGaming Tech Nightを開催し、多くのゲーム開発者、インフラエンジニアの方々にご参加いただきました。Gaming Tech Nightは過去2016年に開催された、ゲームに特化した技術情報をお届けすることを目的としたAWS主催のイベントでしたが、今年からは定期開催イベントとして新しく生まれ変わりました。記念すべき再開１回目となる今回は、re:Born(再始動)というタイトルでサーバレスやCI/CDなど複数のテーマで計４セッションをお届けしました。   サーバレスアーキテクチャ入門 ~ Game Server Services 丹羽様 Game Server Services株式会社 代表取締役社長CEOの丹羽様より、サーバレスアーキテクチャについてご講演いただきました。入門というタイトルですが、サーバレスの定義から実装に関する注意点、実際に丹羽様が構築・運用する中で習得されたノウハウなどが詰まった内容の濃いセッションでした。これからサーバレスをはじめる方だけでなく、すでに構築・運用されている方々にも非常に参考になるポイントが多かったのではないかと思います。登壇資料はGS2 Blogで公開されています。   AWSにおけるモバイルゲーム向けAPIサーバの実装2018 ~ ソリューションアーキテクト 畑 ソリューションアーキテクトの畑より、モバイルゲームを対象としたAWSにおけるAPIサーバ実装について解説しました。典型的な実装パターンである３層Webアプリケーションパターンをはじめ、API Gateway+Lambda+DynamoDBを利用したサーバーレスアーキテクチャ、アプリケーション上で実装されたAWS SDKを通じて各AWSサービスのAPIに直接アクセスする2-Tierアーキテクチャなどの実装ポイントをご紹介しました。また、現在Public Preview中であるAWS AppSyncによる実装パターンにも触れました。API用のクエリ言語であるGraphQLは、クライアント〜サーバ間で共有される型が利用できたり、クライアント側からサーバのレスポンスデータの形式を指定できたりとモバイルゲームでも応用できる多くの利点があります。AWS AppSyncはマネージドなGraphQLのサービスであり、ゲーム開発者の方にもインフラを意識することなくご利用いただけます。ぜひPreviewにご参加ください。 Serverless backendformobilegame and_aws-appsync_gamingtechnight-2 from Amazon Web Services Japan   AWS上で実現するゲーム開発CI/CDパイプライン ~ ソリューションアーキテクト 森 ソリューションアーキテクトの森からは、AWSのCode系サービスを利用したゲーム開発におけるCI/CDパイプラインの実装例の解説とデモを披露しました。ソースコードをCodeCommitにpushし、CodeBuildによるビルド、CodeDeployによるステージング環境へのデプロイ、そしてステージングでのテスト完了後に再度CodeDeployを使って本番環境にという一連の流れをCodePipelineを自動化することが可能です。特にコードのビルドについては、ビルド用で常にインスタンスを確保されているお客様も多いと思いますが、CodeBuildはビルド実行時間のみの課金となりますので、コストが削減できるケースも多いと思います。ぜひゲーム開発のCI/CDにおいてもAWSのマネージドサービスをご活用ください。 Gaming cicd-pipeline gaming-technight-2 from Amazon Web Services Japan   AWSを最大限活用したロングヒット戦略 ~ Amazon […]

私たちは、AWS Glue の ETL(Extract、Transform、Load)を実行するためのスクリプトにおけるScalaのサポートを発表することに興奮しています。Scala が好きな人達は強力な武器を1つ手に入れることになり喜んでくれるでしょう。AWS Glue では Apache Spark をデータ加工のエンジンとして使用していますが、Scala は Apache Spark のネイティブな言語です。 洗練された言語としての機能が使える以外にも、Glue のスクリプトをScala で書くことはPython で書くことに比べて2つの利点があります。まずは、Python とApache Spark のScala ランタイム(JVM)の間でデータを移す必要がないので、Scala は大量のデータ移動を伴う加工整形処理がより高速です。サードパーティのライブラリで独自の変換を作成したり関数を呼び出すことができます。 次に、Scala はJava と互換性があるように設計されているため、外部Java クラスライブラリの関数をScala から呼び出すことが簡単です。 そのため、Scala のコンパイル結果は Java と同じバイトコードになりますしデータ構造を変換する必要もありません。 これらの利点を説明するために、GitHubアーカイブから入手可能なGitHub パブリックタイムラインの最近のサンプルを分析する例を説明します。このサイトはGitHubサービスへのパブリックリクエストのアーカイブで、コミットとフォークから、イシューとコメントまで35種類以上のイベントタイプを記録しています。 この記事は、タイムラインのネガティブなイシューを特定するScala スクリプト作成の方法を紹介します。このスクリプトではタイムラインサンプルのイシュー イベントを引き出し、Stanford CoreNLPライブラリのセンチメント推定機能を使用してタイトルを分析し、最もネガティブなイシューを浮き彫りにしています。 入門 スクリプトを作成する前に、AWS Glue Crawler を使ってデータ構造と特性を理解します。また、開発エンドポイントとZeppelin ノートブックをセットアップすることで、データをインタラクティブに探索してスクリプトを作成することもできます。 データをクロールする この例で使われているデータセットは、GitHub アーカイブからAmazon S3 のサンプルデータセットバケットにダウンロードされています。場所は以下の通りです： s3://aws-glue-datasets-<region>/examples/scala-blog/githubarchive/data/ <region>をあなたの作業中のリージョンに置き換えて最適なフォルダを選択してください。例えばap-northeast-1 などです。AWS Glue Developer Guide […]

多くのAWSのお客様がミッションクリティカルなワークロードをIBM Db2データベースプラットフォームを利用して実行しています。一般的に、こういったワークロードには、ノード障害やデータセンターサイトの障害時でも運用を続けられる高い可用性が必要とされます。 従来のIBMソフトウェアにおける高可用性手法は、共有ディスクと仮想IPアドレスを使用し、これをTivoli System Automation for Multi-Platforms (TSAMP)でコントロールするというものでした。このブログポストでは ネイティブのIBMとAWSの技術を用い、かつ自動化された手法を説明します。これによりミッションクリティカルなDb2ワークロードをAWS上で稼働でき、高可用性のDb2データベースを安心して提供できるようになります。 注：このガイドで使用するIBM Db2は、フル機能が90日間利用できるトライアル版のDb2 for Linux, Unix and Microsoft Windows バージョン11です。トライアル期間が終了したあとは、必要とするエディションを選択、購入し、ライセンスファイルを導入して利用することが可能です。このガイドで利用している機能が使用できるエディションは、Db2 Advanced Enterprise Server Edition、 Db2 Enterprise Server Edition、Db2 Advanced Workgroup Server Edition、Db2 Workgroup Server Editionです。より詳細な情報はIBM Webサイトを確認してください。（訳注：こちらにエディションの違いの詳細があります） この記事のステップを進めていくと、2つのアベイラビリティゾーン（AZ）にまたがって高可用性を実現するDb2 データベースを作成します。データはAZ1にあるプライマリーインスタンスとAZ2にあるスタンバイインスタンスの間でHADR(High Availability Disaster Recovery)機能でレプリケーションされます。もしプライマリーノードが利用できなくなった場合、TSAMPがそれを検知し、スタンバイインスタンスにフェイルオーバーさせます。Db2 クライアントアプリケーションは自動クライアントリルート機能 (IBM Automatic Client Reroute : ACR)により自動的に新しくプライマリーになったインスタンスに再接続されます。 事前準備のステップ このソリューションはAWSのデフォルトVPC (Virtual Private Cloud)にデプロイされます。デフォルトVPCはAWSアカウント作成時に自動的に各リージョンに作成されています。もしデフォルトVPCが無い場合は、次のステップに進む前に以下を実行してください。 同一リージョンの２つのパブリックサブネットを持つVPCを作成してください。それぞれのサブネットは別のAZに配置してください。 VPCにインターネットゲートウェイを配置してください。それぞれのサブネットはインターネットゲートウェイ経由でインターネットに出られるようにします。 最初にAmazon S3 […]

本日 東京リージョンにて、新たにアベイラビリティゾーンを追加しました。東京リージョンは、追加のアベイラビリティゾーンを合わせ、4つのアベイラビリティゾーンになりました。 AWSは、世界中に18の物理的なリージョンと51のアベイラビリティゾーンがあります。本日追加されたアベイラビリティゾーンは、シンガポールリージョンに続き52番目となり、東京リージョンでAWSのクラウドコンピューティングをご利用の10万以上のお客さまにご利用いただけます。 アベイラビリティゾーンは、自然災害やデータセンター単位の障害などビジネスに影響を与えるリスクを最小化するよう地理的に影響を受けない十分離れた場所にあり、フェイルオーバーを実現し事業継続性を確保できるインフラストラクチャです。各アベイラビリティゾーンは、独立した電源、空調、物理的なセキュリティを備え、広帯域でハイスピードの光回線のバックボーンに接続されています。AWSのお客さまは、アプリケーションを複数のアベイラビリティゾーンを利用することで高い耐障害性を実現することができます。また、100以上の Amazon CloudFront エッジロケーションにより遅延を最小化しつつ、ウェブサイト、アプリケーションおよびコンテンツの配信が可能となります。 すでに東京リージョンをお使いのお客さまは、追加されたアベイラビリティゾーンにおいて、東京リージョンで利用可能なすべてのサービスを利用できます。

Apache MXNet は、ディープラーニングネットワークをビルドし、トレーニングし、再利用するために開発者が利用できるオープンソースライブラリです。このブログ投稿では、NNPACK ライブラリを使用して推論を高速化する方法を説明します。確かに、GPU 推論が利用できない場合、NNPACK を Apache MXNet に追加することは、インスタンスからより大きなパフォーマンスを引き出すための簡単なオプションかもしれません。常にそうですが、「かかる労力は異なる場合があり」、常に自分自身でテストを実行する必要があります。 開始する前に、トレーニングと推論の基礎の一部を確認していきましょう。 トレーニング トレーニングとは、ニューラルネットワークがデータセット内の各サンプルに対して正しいラベルを正しく予測する方法を学習するステップです。1 回に 1 個のバッチ (通常 32〜256 サンプル) ずつ、データセットがネットワークに送出され、バックプロパゲーションアルゴリズムを利用して、重みづけを調整することにより、エラー数の合計が最小限に抑えられます。 完全なデータセットを調べることをエポックと呼びます。大規模ネットワークは、可能な限り高い精度を達成するために、何百ものエポックに対してトレーニングする場合があります。これには数日から数週間かかることもあります。強力な並列処理能力を備えた GPU を使用することで、最も強力な CPU に比べてさえも、トレーニング時間を大幅に短縮することができます。 推論 推論とは、実際にトレーニングされたネットワークを使用して新しいデータサンプルを予測するステップです。Amazon Rekognition のように単一の画像内のオブジェクトを識別しようとする場合など、一度に 1 つのサンプルを予測することや複数のユーザーからの要求を処理するときに、複数のサンプルを同時に予測することなどが可能です。 もちろん、GPU は推論でも同様に効率的です。しかし、多くのシステムは、コスト、消費電力、またはフォームファクタの制約のために GPU に対応できません。したがって、CPU ベースの推論では、高速で実行できることが依然として重要なトピックになっています。ここでは NNPACK ライブラリが Apache MXNet で CPU 推論を高速化するのに役立つため、NNPACK ライブラリが、が採用されます。 NNPACK ライブラリ NNPACK は、GitHub で利用できるオープンソースライブラリです。どのように役立つのでしょうか?コンボリューションニュートラルネットワークについてお読みいただいていることでしょう。これらのネットワークは、コンボリューションとプーリングを適用して入力画像内の機能を検出する複数のレイヤーからビルドされています。 この投稿では実際の理論には触れませんが、NNPACK が高度に最適化される方法でこれらのオペレーション (および行列の乗算のような他のオペレーション) を実施しているとだけ申しておきましょう。基礎理論にご興味があるようでしたら、この Reddit の投稿で著者が述べた研究論文を参照してください。 NNPACK […]

最新の AWS re:Invent 2 つのローンチに追いつこうとしているところです! 本日は、リージョン間の VPC ピアリングについてお話したいと思います。2014 年初頭以降、同じ AWS リージョンの仮想プライベートクラウド (VPC) 間でピアリング接続を作成することができるようになっています (詳細は、「New VPC Peering for the Amazon Virtual Cloud」を参照してください)。一旦確立されると、ピアリングされた VPC の EC2 インスタンスは、プライベート IP アドレスを使用して、同じネットワーク上にあるかのように、ピアリング接続を介して互いに通信できます。 re:Invent において、ピアリングモデルを拡張し、AWS リージョン全体で機能するようにしました。既存のモデルと同様に、同じ AWS アカウント内または一対のアカウント間でも機能します。私の以前の投稿に記載されているユースケースはすべて、引き続き適用されます。組織全体の VPC に共有リソースを集中させ、複数の部門ごとの VPC とピアリングすることができます。また、コンソーシアム、コングロマリット、または合弁企業のメンバー間でリソースを共有することもできます。 さらに、リージョン間 VPC ピアリングにより、AWS リージョン間に存在する高度な分離を活用しながら、リージョンにまたがる高度に機能的なアプリケーションを構築することができます。たとえば、計算やストレージリソースの地理的な場所を選択して、規制要件やその他の制約を遵守するのに役立てることができます。 ピアリングの詳細 この機能は、現在米国東部（バージニア州北部）、米国東部（オハイオ州） 、米国西部（オレゴン州）、および EU（アイルランド）リージョン、および IPv4 トラフィックでご利用いただけます。これらのリージョン内の任意の 2 つの VPC は、明確な、重複しない CIDR ブロックを有する限り、接続できます。これにより、すべてのプライベート IP アドレスが一意であることが保証され、一対の VPC […]

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、AWS は AWS Security Bulletin（セキュリティ情報）AWS-2018-013 を先日公開しました。このセキュリティ情報では、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 の3つのセキュリティ勧告に触れています。これらの勧告は Google Project Zero の調査に基づいたもので、Google Project Zero の発表はモダンコンピュータプロセッサ上でのサイドチャネル分析の新しい方法を発見したというものでした。これらの方法は、基礎的な技術、具体的には投機的実行に着目したもので、投機的実行は多くのベンダーのプロセッサに用いられています。そのため研究結果の対象となる範囲は幅広く、その範囲はハイパーバイザーからオペレーティングシステム、さらには Web ブラウザ、携帯電話からクラウドを構成するデータセンター内のサーバにまで及びます。   EC2 インスタンスの分離   Amazon EC2 のすべてのインスタンスは、上述の CVE に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 大多数の EC2 ワークロードに有意なパフォーマンスの影響は見られていません。   オペレーティングシステムへのパッチ   現代のオペレーティングシステムには、「ユーザー空間」プロセスからのカーネル分離、それぞれのプロセスの分離などの、いくつかのタイプのプロセス分離があります。影響を受けうるプロセッサ上でオペレーティングシステムが実行されている環境では、いかなる設定においても、公開された 3 つの問題すべてがプロセス分離に影響を与える可能性があります。ハイパーバイザで実装されている保護は、オペレーティングシステム内のプロセスレベルの分離にまで拡張されないため、リスクを軽減するためにオペレーティングシステムパッチが必要です。 準仮想化（PV）インスタンスでは、CVE-2017-5754 のプロセス間の問題に対処するためのオペレーティングシステムレベルの保護は無いことに注意してください。PV インスタンスは、前述のようにインスタンス間の問題について AWS ハイパーバイザーによって保護されます。しかしながら、PV インスタンスにおけるプロセスの分離（信頼できないデータ処理やコードの実行、ユーザのホスト）にご懸念をお持ちでしたら、長期的に見てセキュリティの恩恵を受けるため、HVM インスタンスタイプへの変更を強くお勧めします。PVとHVMの相違点（およびインスタンスアップグレードパスのドキュメント）の詳細については、以下の URL を参照してください。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html インスタンスのオペレーティングシステムにパッチを適用することで、同じインスタンス内で動作するソフトウェアを分離し、CVE-2017-5754 のプロセス間の問題を緩和することを強く推奨します。以下のオペレーティングシステムのパッチの詳細を記載します。 Amazon Linux & […]

こんにちは。ソリューションアーキテクトの有岡です。2018年2月のAWS Black Belt オンラインセミナーの配信についてご案内をさせて頂きます。 re:invent 2017の振り返りを終え、2018年2月のBlackBeltセミナーでは、ソリューションカットとしてAWS上での位置情報と動画配信ソリューション、Amazonのコンテナサービスをご紹介します。 サービスカットでは、クラウド型仮想デスクトップサービスのAmazon Workspaces、同じくBIツールのAmazon QuickSight、AWS Lambdaをエッジロケーションで活用する方法、エンタープライズのお客様でお使いになるケースの多いAWS Organizationsなど、盛り沢山でお送りします。   2月の開催予定 ソリューションカット 2月6日(火) 12:00～13:00 AWS における位置情報 2月13日(火) 12:00～13:00 動画配信 on AWS 2月20日(火) 12:00～13:00 Amazon Container Services サービスカット 2月7日(水) 18:00～19:00 Amazon Workspaces 2月14日(水) 18:00～19:00 AWS Organizations 2月21日(水) 18:00～19:00 AWS Lambda @ Edge 2月28日(水) 18:00～19:00 Amazon QuickSight お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同、みなさまのご参加をお待ちしております。    

Amazon Auroraのような高性能データベースシステムを設計する場合、一般的に最も幅広いワークロードを大きく改善出来るように取り組みたいと考えるかと思います。しかし時には、ゲームチェンジャーになりえる機会がある場合、特別な用途向けに改善を行うこともあります。 geospatial indexとはなにか、なぜ考慮する必要があるのか? 地理空間分析では、XY(Z)座標に沿った近さ、隣接性、重なりを識別することができます。 そのような分析を実行する必要があるアプリケーションには様々な例があります。タクシーアプリでは、利用可能な最寄りのタクシーを見つけることができます。不動産アプリは、サンフランシスコのPacific Heights地区で販売されている物件を探すことができます。 空間分析は、他にも多くの用途でも役立ちます: マーケティング – 店舗から2マイル以内のすべての見込み顧客をターゲットにプロモーションを行います 資産管理 – 顧客の位置と密度に基づいて影響を最小限に抑えるために修理ユニットを配置します リスク分析 – 顧客の居住地や職場の近くで車の盗難が発生した場合のリスクを見積もります 詐欺検出 – 前回のトランザクションからの距離に基づいて詐欺と考えられる取引の可能性を推定します ロジスティクス計画 – 運行の範囲を最小限にするように、トラブルのチケットを現場の技術者に割り当てます これらのアプリケーションは、高性能な空間データのインデックスから利益を得ることができます。残念なことに、Bツリーのような伝統的なインデックスは、Linlandのために作られたものであり、FlatlandやSpacelandではそうではありません。そのため、高性能な空間インデックスが必要です。 Rツリーとは? 最も一般的に使用される空間インデックスはRツリーです(詳細はこちらの論文を参照してください)。 MySQLとOracleはどちらもR-treeを使用しています。基本的な考え方は、バランスサーチツリーないにバウンダリーレクタングルを保存することです。リーフはデータポイントであり、各内部ノードは、その下のノードのミニマムバウンダリーレクタングルです。したがって、次の例では、長方形Aはリーフノードです。このノードは、矩形NおよびTによって順番に境界が作成されます。 Rツリーの主な問題は、安定していないことです(つまり、決定論的です)。挿入順序が異なると、異なるツリーが生成され、パフォーマンスの特性が大きく異なります。私たちのテストでは、ランダムな挿入順序では、最適な順序で構築されたツリーよりも1桁も性能が劣化したツリーが生成されました。これは、データの挿入順序が予測できず、変更可能なOLTP環境では明らかに問題になります。このような状況では、Rツリーは時間とともに性能が劣化します。1つの回避策は、データを定期的にインデックスを再構築することです。しかし、インデックスの再構築は負荷がかかります。加えて通常この作業は、手作業が必要であり、数時間かかることがあります。また、その期間中の他のトランザクションは遅くなる可能性があります。 そのため、Rツリーは人気がありますが、常に良好なパフォーマンスは得られません。 他にいい方法はあるのか？ 私たちはそう考えています！トランザクションと同時実行に最適なデータ構造があります。それはBツリーです。 あらゆる場面で使用され、高いパフォーマンスを発揮するのはデータベースにとって基本です。 しかし、ちょっと待ってください。私はB-treeが多次元データに対してうまく機能しないと言いました。それは本当です。2次元を1次元にマップするトリックがあります。 私たちは、space-filling z-order curves(空間充填zオーダー曲線)を使用して行います。これは、ポイントのz値は、その座標値のバイナリ表現をインターリーブすることによって計算されます。zオーダー曲線は、これらの点をz値の順に横切る線です。たとえば、次の図は、0≤x≤7、0≤y≤7の整数座標の場合のz値を示しています(10進数と2進数の両方を示しています)。 zオーダー曲線上のBツリーの単純な実装では不十分です。なぜこれが当てはまるのかを知るために、以下の例を見てみましょう。緑色の四角形内のすべての点をBツリーで検索すると、クエリー領域外に30個の余分なz値(黄色い三角形の警告標識が付いている物)がスキャンされます。 元のクエリをより少ない偽陽性z値をカバーする小さなクエリに分割することで、この問題を改善します。(これを行うために幾つかの方法を使用していますが、それはこの記事でお伝えする範囲を超えています) それは私たちがポイントするために必要なものすべてを提示します。ポリゴンはどのように空間充填曲線で動作するのでしょうか？ポリゴンが単一点のように見えるまでズームアウトしたとします。どの程度ズームアウトしなければならないかは、ポリゴンの”レベル”によります。各空間オブジェクトは、オブジェクトのレベルとzアドレスの組み合わせとしてBツリーに格納されます。zアドレスがポイントのように見えるまでズームアウトしたので、zアドレスをポイントのように扱うことができます。他のシステムでは、このレベルを手動で指定する必要があります。明らかに、予測不可能で変更可能なデータを扱うOLTPシステムでは動作しません。このレベルはユーザーの設定なしで自動的に設定します。 Auroraのgeospatial indexesは、MySQL 5.7よりもselect-only(1秒当たりの読み込み回数)ワークロードで10倍以上、write-only(1秒当たりの書き込み回数)で20倍以上優れています。具体的には、サイズが1 GB未満のデータセットでSysbenchを使用して、AuroraとAmazon RDS for MySQL 5.7をdb.r3.8xlargeインスタンスを用いて計測しました。select-onlyのテストでは、2,000クライアントとST_EQUALSクエリを使用しました。write-onlyテストでは、4,000のクライアントを使用しました。 ご質問がある場合は、aurora-pm@amazon.comまでご連絡ください。 About the Author Sirish Chandrasekaran is a product […]

Amazon Aurora PostgreSQL リードレプリカ(2018/1/23現在英語版ドキュメントのみとなっています)を Amazon RDS for PostgreSQL のインスタンスとして作成し、継続的に Amazon Aurora PostgreSQL へレプリケーション出来るようになりました。これにより、実稼働ワークロードを Amazon RDS for PostgreSQL から Amazon Aurora PostgreSQL に移行する際、アプリケーションとユーザーを Amazon Aurora PostgreSQL へ移す準備ができるまで、インスタンスタイプを同期させておくことで、ダウンタイムを最小化させることが可能です。 Amazon Auroraは、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えています。スケーラビリティ、耐久性、およびセキュリティの向上とともに、高いクエリ並列度、データサイズが大きい環境下で標準的なPostgreSQLデータベースのパフォーマンスを最大で3倍向上させます。詳細については、Amazon Auroraの製品ページをご覧ください。 翻訳は江川が担当しました。原文はこちらをご覧ください。