Amazon Web Services ブログ

モノリシックでミッションクリティカルなMicrosoft SQL ServerデータベースをオンプレミスからAWS（Amazon EC2ベースのSQL Server）に移行することは、しばしば困難な作業です。主な課題は次の通りです： 継続的なダウンタイム – ビジネスに悪影響を及ぼす可能性のあるカットオーバー中の継続的なダウンタイムウィンドウが発生する課題 データ同期の課題 – オンプレミスに配置されたデータベースとAWS上のデータベースを同期した状態に維持するための課題 柔軟性の欠如 – 移行のための段階的なアプローチを計画・実行する為の柔軟性を確保する課題 この記事では、重要なSQL ServerデータベースをAWSにリフト＆シフト（またはリフト＆トランスフォーム）するためのハイブリッドソリューションの構築方法について詳しく説明します。このソリューションでは、SQL Server 2016で導入された新しい機能である分散型可用性グループを使用します。この記事では、分散型可用性グループを使用して移行を制御し、柔軟性を高める段階的アプローチについても説明します。 分散型可用性グループの概要 分散型可用性グループは、2つの個別の可用性グループにまたがる特別なタイプの可用性グループ（AG）です。分散型可用性グループは複数の可用性グループの1つ（または複数のAGの中の1つ）と考えることができます。基礎となる可用性グループは、2つの異なるWindows Server Failover Cluster（WSFC）で構成されます。 分散型可用性グループアーキテクチャは、既存のオンプレミスWindows Server Failover Cluster（WSFC）をAWSに拡張するよりも効率的です。データは、オンプレミスのプライマリからAWS上の1つのレプリカ（フォワーダ）にのみ転送されます。フォワーダは、AWS上の他のリードレプリカにデータを送信する役割を担います。このアーキテクチャにより、オンプレミスとAWSの間のトラフィックフローが削減されます。 アーキテクチャ概要 次の図は、ソリューションの全体的なアーキテクチャを示しています。 図に示されているように、最初のWSFCクラスタ（WSFC1）はオンプレミスでホストされています。オンプレミス可用性グループ（AG1）はこのWSFCクラスタに配置されます。 2番目のWSFCクラスタ（WSFC2）はAWSでホストされます。 AWS可用性グループ（AG2）はこのWSFCクラスタに配置されます。 このユースケースでは、オンプレミスのSQL Serverインスタンスとデータベースは、従来の物理サーバーまたは仮想マシン（VM）によってホストされています。 AWSのSQL ServerインスタンスはAmazon EC2でホストされ、SQL ServerデータベースはAmazon EBSボリュームで構成されます。 AWS Direct Connectによって、オンプレミスからAWSへの専用ネットワーク接続を確立しています。 前述のアーキテクチャ図に示すように、オンプレミス可用性グループ（AG1）には2つのレプリカ（ノード）があります。これらの間のデータ転送は、自動フェイルオーバーを使用して同期します。オンプレミスレプリカの1つに障害が発生すると、AGは2番目のレプリカにフェールオーバーすることで、アプリケーションとユーザーはDBを使用できます。各可用性グループは、1つのプライマリレプリカと最大8つのセカンダリレプリカをサポートしています。高可用性の要件と拡張性のニーズに基づいて追加のレプリカを同期または非同期にする必要があるかどうかを判断します。 AWS可用性グループ（AG2）にも2つのレプリカがあり、それらの間のデータ転送は自動フェールオーバーで同期しています。 EC2インスタンスまたは1つのアベイラビリティゾーンに障害が発生すると、AGは別のアベイラビリティゾーンにある2番目のEC2インスタンスにフェールオーバーします。 このソリューションの一環として、分散型可用性グループを構成します。このグループには、オンプレミス可用性グループ（AG1）とAWS可用性グループ（AG2）の両方が含まれます。分散型可用性グループは、前述の図において赤い点線で示すように、データベースを非同期で同期させます。 フォワーダ（前述の図で緑文字で表されている）は、AWS内の他のリードレプリカにデータを送信する役割を担います。このデータ転送により、オンプレミスとAWS間のトラフィックフローが減少します。オンプレミスからAWSへのデータ転送はプライマリレプリカから一度だけ実施され、フォワーダは残りの伝播を処理します。 どの時点でも、書き込みに使用できるデータベースは1つだけです。残りのセカンダリレプリカデータベースは読み取り用に使用できます。前述のサンプルアーキテクチャ図では、社内のプライマリデータベースを読み取り/書き込み可能にし、AWSセカンダリデータベースを読み取りに使用できます。 AWSでリードレプリカを追加できることが重要なメリットです。この能力があれば、AWSへの移行に際して、読取り専用アプリをAWSに最初に移行することができます。また、データベースは、AWS上のアプリケーションとそのユーザーにも近くなります。 読み込みのワークロードをスケールアウトする場合は、AWSにさらに多くのリードレプリカを追加できますし、複数のアベイラビリティゾーンに配置することも可能です。このアプローチは、以下のアーキテクチャ図で表されます。この図では3つの異なるアベイラビリティゾーンに、それぞれリードレプリカを配置しています。 段階的な移行方法 分散型可用性アーキテクチャを使用することで、段階的な移行が可能となり、移行における柔軟性を高めることができます。 フェーズ1 この段階では、ほとんどの読取り専用アプリケーションをAWSに移行して、AWS上の読取り専用セカンダリデータベースにアクセスします。読み取り/書き込みを行うアプリケーションは、引き続きオンプレミスのプライマリ・データベースにアクセスします。 クラウド移行のこのフェーズでは、ストレステスト、機能テスト、およびデータベース作業負荷の回帰テストが重要な要素です。読取りワークロードをサポートするためにEC2インスタンスを正しくサイジングすることもこのフェーズの重要なステップです。 […]

このブログ記事では、AWS CodeStar プロジェクトの一部として単体テストを実行する方法についてご紹介します。AWS CodeStar は AWS 上でアプリケーションを素早く開発、ビルド、そしてデプロイするのに役立ちます。AWS CodeStar を使えば、継続的デリバリ（CD）のツールチェーンを構築しソフトウェア開発を一箇所に集約して管理することができます。 単体テストはアプリケーションのコードの個々の単位をテストし、問題を素早く特定し取り去るのに役立ちます。単体テストは、自動化された CI/CD プロセスの１部分を構成することで、バッドコードが本番環境にデプロイされてしまうことを防ぐのにも役立てられます。 多くの AWS CodeStar プロジェクト テンプレートには、単体テストのフレームワークがあらかじめ設定されています。そのため、自信を持ってコードのデプロイを開始することができるでしょう。この AWS CodeStar プロジェクトの単体テストは、ビルドステージにおいて実行されるように設定されているので、もし単体テストがパスしなかったらそのコードがデプロイされることはありません。単体テストを内包している AWS CodeStar プロジェクト テンプレートの一覧については、AWS CodeStar ユーザガイドの AWS CodeStar プロジェクト テンプレートを参照してください。

ゲーム開発者として、ローンチに至るまで情熱を絶やさずゲーム開発とファンコミュニティの育成に数年の歳月と投資をされてきたかと思います。最高のユーザー体験を提供することおいては、例えばネットワーク接続時のプレイヤーの待ち時間に対するバックエンドの選択肢等バックエンドインフラは一番の関心ごとではなかったかもしれません。 多くのゲーム開発者がピア・ツー・ピア（P2P）ネットワークでマルチプレイヤータイプのゲームを実現させています。開発当初は一見してコスト効果の高いソリューションに思えますが、我々は沢山の開発者がP2Pから クラウド上で可動する専用ゲームサーバー に切り替えられる案件を見てきました。ここでは、UbisoftやIllFonicのようなスタジオのFor HonorやFriday the 13th The Gameのチームが、なぜP2Pをやめクラウド上の専用ゲームサーバに乗り換えたのか、その理由のいくつかを見てみたいと思います 劣悪なレイテンシーと接続性からの脱却 P2Pネットワークでは同一エリアで強力なネットワーク接続があれば低レイテンシーな体験をプレイヤーにもたらしてはくれます。しかしながら、P2Pネットワークでの全体的なゲームのレイテンシーは、ホストとのネットワーク接続のレイテンシーに縛られます。 For Honorは、当初、P2Pネットワークモデルを採用してリリースされました。時間を経るに連れ、プレイヤーの体験に関してアーキテクチャの選択に起因するいくつかの問題がある事が明らかになり、セッションの移譲とNAT (Network Address Transaction) の問題解決やマッチメイキングとオンライン体験の安定性を得るために、UbisoftはAmazon GameLiftで稼働させる専用ゲームサーバモデルに移行する事を決定しました。 専用ゲームサーバは開発者側による細かな制御を可能にします。さらに、クラウド上でのホスティングを利用する事で、プレイヤーを低レイテンシーで安定したゲームサーバに接続する等の管理も容易にできるようになります。 ドロップアウト、ホストの優位性、マルチプレイヤーゲームのチート対策 プレイヤーは、ネット接続の問題、ゲームへの興味喪失等々様々な理由でゲームセッションからドロップアウトします。 ホストプレイヤーがゲームから抜けると、他の全てのプレイヤーのゲームの中断や瞬断を招きます。Friday the 13th The Game独自のユニークな非対称マルチプレイゲームではこの問題はより顕著でした。このゲーム内では、あの悪名高いジェイソンはマッチ中の他の全てのプレイヤーと敵対します。ホストプレイヤーがジェイソンに倒された場合に、墓からの観戦は望まずゲームからドロップアウトしてしまうので、全てのプレイヤーのゲームが中断してしまっていました。 P2Pネットワークでは不正やチートも容易にできてしまい、ホストはレイテンシー的に優位になる事が多々ありました。また、専用サーバモデルアーキテクチャに比べ、ホストプレイヤーのPCが認証を行うP2Pモデルではチートの検出も容易ではありませんでした。そして、ホストは他のプレイヤーに比べてレイテンシーが低いので度々優位になりました。専用サーバモデルを採用することで、ゲームの中断やチートの問題を抑え、全てのプレイヤーに平等なゲームプレイ体験を提供できるようになります。これらがIllFonicがAmazon GameLift上で専用サーバを稼働させるという選択をされ、マルチプラットフォーム（PC、Xbox One、PS4）間プレイを実現するに至った理由です。 UbisoftとIllFonicによるP2Pと専用サーバの知見がGDC 2018でシェアされました GameLiftチームによる「Exploring Trends of Multiplayer Game Infrastructure with Amazon Gamelift」セッションをぜひご確認ください。 UbisoftよりFor Honor開発者のDamien KiekenとRoman Campos Oriolaが、IllFonicよりFriday the 13th The Gameの技術ディレクターPaul Jacksonにより、彼らのバックエンドインフラやP2PネットワークからAmazon GameLift上の専用ゲームサーバへの移行に関してご紹介いただきました。また、Amazon GameLiftチームからもマルチプレイヤーゲームサーバのトレンドやマシンラーニング等も紹介されます。 GDC 2018 @ […]

Database Migration Playbooks（Amazon Web Services と NAYA Tech の共同プロジェクト）とは、異種間データベース移行計画を成功させるためのベストプラクティスに焦点を当てた一連のガイドです。このプレイブックは、AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Servies (AWS DMS) を含む、既存の自動化および半自動化されたAmazonデータベース移行ソリューションおよびツールを補完するものです。

「Oracle to Amazon Aurora Migration」プレイブックの初版では、Oracle 11g と12cのデータベース機能とスキーマオブジェクトを Amazon Aurora with PostgreSQL compatibility に移行するためのベストプラクティスに重点を置いています。移行するためには、PostgreSQLデータベースエンジン自体に組み込まれている機能と、様々なAWSサービスやソリューションの両方を使用しています。

Amazon Elastic File System はファイルベースのストレージへの共有アクセスが必要なクラウドネイティブなアプリケーション向けにファイルシステム選択肢の一つとなるよう設計されました。私たちは2016年中頃に EFS の提供を始めて、以降、”Direct Connect 経由のオンプレミス環境からのアクセス”や”保管データの暗号化”など重要な機能をいくつも追加してきました。また、EFS を提供する AWS リージョンの追加も行ってきており、直近では US West (北カリフォルニア) が追加されました。EFS 自体がそうであったように、これらの機能追加はお客様からのフィードバックにより為されたもので、益々拡大するお客様の声に応えたいという私たちの願望を反映しています。 伝送データの暗号化 今日、EFS をより便利なものにするために伝送データの暗号化サポートを追加しました。既にサポートしている保管データの暗号化と共に使用する場合、多層防御セキュリティ ストラテジーによる格納ファイルの保護が実現されます。 伝送データの暗号化の実装をより簡単にするために、EFS マウント ヘルパーもリリースします。このヘルパー(ソースコードと RPM 形式で提供)は、EFS への TLS トンネルの確立を助けてくれるもので、また ID によるファイルシステムのマウントもできるようにするものです。この 2 つの機能はそれぞれ独立しています。ヘルパーを使用して、伝送データの暗号化をしていなくても ID でファイルシステムをマウントできます。ヘルパーは実際の mount コマンドのデフォルトオプションの推奨セットも提供してくれます。 暗号化のセットアップ Amazon Linux インスタンスに EFS マウントヘルパーをインストールするところから始めます。 $ sudo yum install -y amazon-efs-utils 次に、EFS コンソールを開き、ファイルシステム ID を取得します。 そして、その ID […]

Amazon SageMaker では、見直し改善が迅速に行われ、お客様のために新機能をリリースし続けています。本日を皮切りに、SageMaker は多くの新しいインスタンスタイプ、SDK を使ったローカルテスト、そして Apache MXNet 1.1.0 および Tensorflow 1.6.0 のサポートを追加します。これらのアップデートのそれぞれを簡単に見てみましょう。 新しいインスタンスタイプ Amazon SageMaker のお客様に、ノートブック、トレーニング、およびホスティングのワークロードの規模最適化のための追加オプションをご利用いただけるようになりました。ノートブックインスタンスは、t2.micro、t2.small、および m4.large インスタンスを除いたほとんどすべての T2、M4、P2、および P3 インスタンスタイプをサポートします。モデルトレーニングでは、m4.large、c4.large、および c5.large インスタンスを除いたほとんどすべての M4、M5、C4、C5、P2、および P3 インスタンスがサポートされるようになりました。最後に、モデルホスティングでは、m4.large インスタンスを除いたほとんどすべての T2、M4、M5、C4、C5、P2、および P3 インスタンスがサポートされます。お客様の多くは、最新の P3、C5、および M5 インスタンスを活用して、ワークロードのために最高の価格/パフォーマンスを得ることができます。また、使用頻度の低いエンドポイントまたはノートブック用に、T2 インスタンスのバースト可能なコンピューティングモデルを利用することも可能です。 オープンソース化されたコンテナ、ローカルモード、および TensorFlow 1.6.0 と MXNet 1.1.0 本日、Amazon SageMaker は SageMaker SDK で MXNet と Tensorflow のエスティメータを動作させる MXNet および Tensorflow ディープラーニングコンテナをオープンソース化しました。シンプルなインターフェイスに従う Python […]

本日から Amazon Translateの一般提供が開始されました。昨年の AWS re:Invent で、私の同僚 Tara Walker が新しい AI サービスである Amazon Translate の プレビュー についての記事を書きました。今日から、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、および欧州 (アイルランド) で Amazon Translate にアクセスできるようになります。最初の 12 ヵ月間は毎月 200 万文字が無料利用枠対象となり、その後は 100 万文字ごとに 15 USD となります。一般提供では、ソース言語の自動推論、Amazon CloudWatch サポート、および単一の TranslateText 呼び出しで最大 5,000 文字など、数多くの新機能を利用できます。一般提供でのサービスを簡単に見てみましょう。 Amazon Translate の新機能 サービスの基本についてはすでに Tara の記事でまとめられているので、私は今日リリースされたサービスの新機能をいくつか取り上げたいと思います。では、コードサンプルから始めましょう。 import boto3 translate = boto3.client(“translate”) resp = translate.translate_text( Text=”????Je suis […]

AWS re:Invent 2017 において、AWS はプライベートプレビューの Amazon Transcribe を発表しました。そして本日、AWS はすべての開発者に対する Amazon Transcribe の一般提供を発表します。Amazon Transcribe は、開発者が Speech to Text 機能をアプリケーションに追加することを容易にする自動音声認識サービス (ASR) です。AWS は、プレビューでのお客様のフィードバックを元に見直しを続け、Amazon Transcribe に多くの改善を行いました。 一般提供における Amazon Transcribe の新機能 まず、AWS では SampleRate パラメーターをオプションにしました。これは、メディアのタイプと入力言語のみを知っておけばよいことを意味します。そして、より明瞭なトランスクリプトを提供するために音声内の複数の話者を区別する機能 (「いつ誰が話したか」)、そして製品名、業界固有の用語、または個人名の音声認識の正確性を向上させるカスタムボキャブラリの 2 つの新機能も追加しました。Amazon Transcribe の仕組みを思い出せるように、簡単な例を見てみましょう。私の S3 バケットにあるこの音声を変換します。 import boto3 transcribe = boto3.client(“transcribe”) transcribe.start_transcription_job( TranscriptionJobName=”TranscribeDemo”, LanguageCode=”en-US”, MediaFormat=”mp3″, Media={“MediaFileUri”: “https://s3.amazonaws.com/randhunt-transcribe-demo-us-east-1/out.mp3”} ) これにより、個々の話者が識別されている、これに似た JSON が出力されます (ここではレスポンスのほとんどを取り除いています)。 { […]

Amazon Simple Storage Service (S3) にデータを格納及び取り出しをされているすべての皆様に、二つの大きなニュースがあります。 新機能 S3 One Zone-IA ストレージクラス – この新しいストレージクラスは、現在の Standard-IA ストレージクラスよりも 20% ほど低価格です。地域間での冗長性による、より高い保護レベルを必ずしも必要としないデータを格納する用途に設計されているものです。 S3 Select の 一般公開 – このユニークなデータ取得オプションにより、シンプルな SQL式を使って S3 オブジェクトから一部のデータのみを取得することができ、400% もの性能改善を期待できる可能性があります。 両方見てみましょう！ S3 One Zone-IA (Infrequent Access) ストレージクラス この新しいストレージクラスは、一つの AWS アベイラビリティゾーン(Availability Zone 以下 AZ)にデータを格納しつつ、これまでの S3 ストレージクラスと同様に、99.999999999% の耐久性が提供されるよう設計されています。他のクラスとは違い、地震や洪水などにより一つの AZ を物理的に失う場合に耐えうるようには設計されていません。そのため、滅多に起こることではないものの、一つの AZ が破壊されるような災害時には、データは失われる可能性があるということです。S3 One Zone-IA ストレージは、オンプレミスデータのセカンダリバックアップとして利用したり、簡単に再作成できるようなデータ格納といった用途のための低価格オプションとなります。また、異なる AWS リージョンからの S3 クロスリージョンレプリケーション のターゲットとしてご利用いただくことも可能です。 […]

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 […]