Amazon Web Services ブログ

AWSでパートナー ソリューション アーキテクトを務めるFrancisco Javier Garcia Romeroによる記事です。 企業の中核となるSAPワークロードに対するAmazon Web Services (AWS)の採用の速度は、過去数年間着実に拡大し続けています。2018年も既に、AWSクラウドへのSAPワークロードの移行と展開における需要と関心がこれまで以上に高まっていることを感じています。 AWS Partner Network (APN) プレミアコンサルティングパートナーでAWS SAPコンピテンシーを保有するLinkeは、新しいSAPの導入、SAP HANAへのデータベース移行、あるいはAWSサービスとSAPシステムの統合プロジェクトを含む、SAPを中心とした企業のデジタル変革戦略の実行を支援します。

AWSでSAP専門のパートナー ソリューション アーキテクトを務めるJohn Studdertによる記事です。 SAPは世界中の大企業の中枢を担うミッションクリティカルなソフトウェアを提供していることで知られています。私たちのお客様の多くは、重要なSAP本稼働システムをAmazon Web Services (AWS)上で長年にわたって運用してきました。 AWS Partner Network (APN) アドバンスドコンサルティングパートナーでAWS SAPコンピテンシーを保有するLemongrassは、2010年以降、SAP on AWSだけに注力しています。お客様の移行と構築作業において一貫して大きな成果を上げており、さらにMiCloudアプリケーションスイートによるマネージドサービスを提供しています。

新しいことを始めるのは何かと大変です。どこから手をつければよいのでしょうか? どのリソースが不慣れな分野を手助けしてくれるのでしょうか? さらに手助けが必要なときは何を頼ればよいのでしょうか? 新規に AWS アカウントを登録いただいたお客様、すでにご登録いただいているお客様のどちらにも、初めて知ることは常に出てきます。私たちのサービスは、絶えず変化するお客様のニーズに応えるために進化しているからです。お客様が AWS で構築する際に滞りなく設定できるように、こちらの AWS サイトで利用できるビッグデータのトレーニングやリソースについて、このクイックリファレンスガイドをまとめました。

モノリシックでミッションクリティカルな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 […]