Amazon Web Services ブログ

本日、Windows 向け Amazon EC2 Elastic GPU の一般提供を発表しました。Elastic GPU はアプリケーションのグラフィックパフォーマンスを高速化するために Amazon Elastic Compute Cloud (EC2) インスタンスにアタッチできる GPU リソースです。Elastic GPU は Medium (1GB)、Large (2GB)、XLarge (4GB)、2xlarge (8GB) のサイズで提供されています。G3 または G2 (OpenGL 3.3 アプリケーション向け) といった GPU インスタンスタイプを使用する代わりとして、低コストで利用できるサービスです。Elastic GPU は様々なインスタンスタイプと使用することができ、アプリケーションに適切なコンピューティング、メモリ、ストレージバランスを選べるように柔軟性を提供しています。そして今日から Elastic GPU を us-east-1 と us-east-2 でプロビジョンできるようになりました。 Elastic GPU は eg1.medium で 0.05 USD/時間からご提供しています。1 時間 5 セントです。Elastic GPU を t2.medium […]

今回は、私が実に便利だと思う Amazon Aurora の機能、Fast Database Cloning について簡単にご紹介します。Aurora の基盤となる分散ストレージエンジンを利用して、データベースのコピーオンライトで素早く経済的にクローンを作成することができます。 私のこれまでのキャリアの中で、開発、実験、分析に使用するための代表的なデータサンプルを待つことに多くの時間を費やしてきました。たとえば 2 TB のデータベースがあった場合、タスクを行う前にデータのコピーの準備を待つのに何時間も掛かることがあります。RDS MySQL でさえ、スキーマの移行テストやいくつかの分析を行う前に、スナップショットコピーが完了するのを何時間も待つ必要があります。Aurora はこの問題を実に興味深い方法で解決しています。 Aurora の分散ストレージエンジンは、通常であれば実現が不可能なことをできるようにしたり、従来のデータベースエンジンでは経済的に難しいことを可能にします。各ページにポインタを作成することで、ストレージエンジンが Fast Database Cloning を有効にします。そして、ソース内のデータやクローンで変更を行うと、コピーオンライトプロトコルがそのページのコピーを新たに作成し、ポインタを更新します。つまり、これまで 1 時間を要した 2 TB スナップショットの復元タスクを約 5 分で完了することができるのです。そして、その時間の大半は新しい RDS インスタンスのプロビジョニングに費やされます。 同じストレージにポイントしているため、クローン作成の所要時間はデータベースのサイズによります。また、コピー全体ではなく変更を行ったページのストレージ分だけを支払うため、経済的にクローンを作成できます。データベースクローンは耐久性保証を含む通常の Aurora データベースクラスターです。 では、データベースのクローンを作成してみましょう。まず、Aurora (MySQL) インスタンスを選び [Instance Actions] で [create-clone] を選択します。 次にクローン名を 「dolly-the-sheep」 にし、プロビジョンします。 約 5 分半でクローンが利用可能になり、大規模なスキーマ変更をいくつか行ってもパフォーマンスへの影響は見られませんでした。Aurora チームが高速化した DDL オペレーションを有効にしているため、スキーマ変更自体は従来の MySQL で行うよりも早く完了することができました。自分で変更を追加していく間に他のチームメンバーにスキーマ変更をテストさせる場合は、これに続いてクローンのクローンを作成したり、クローンのクローンのクローン (など) を作成することもできます。RDS の視点から見ると、クローンがファーストクラスデータベースであるということは重要なポイントです。スナップショット、バックアップ、モニタリングなど、他の […]

去年、新しい AWS Application Load Balancer について紹介した時に、それを使用して Layer 7 (アプリケーション) ルーティングを EC2 インスタンス、そしてコンテナで実行しているマイクロサービスに実装する方法も説明しました。 長期に渡る AWS への移行の一部として、ハイブリッドアプリケーションを構築しているお客様もいらっしゃいます。こうしたお客様からは、単一の Application Load Balancer を使用して既存のオンプレミスリソースと AWS クラウドで実行している新しいリソースの両方でトラフィックを分散させたいという声が寄せられています。また、別のお客様からは、2 つ以上の Virtual Private Clouds (VPC) に渡るウェブやデータベースサーバーにトラフィックを分散させたり、特定のポート番号を使用しながら特定の IP アドレスと同じインスタンスで複数のサービスをホストしたり、Server Name Indication (SNI) をサポートしないクライアントに IP ベースの仮想ホスティングを提供したいという声も寄せられています。さらに別のお客様からは、きめ細かなアクセス制御を実装するために複数のインターフェイスとセキュリティグループを使用しながら、同じインスタンス (場合によってはコンテナ内) でサービスの複数のインスタンスをホストしたいというリクエストも頂いています。 これらはハイブリッド、移行、災害復旧、オンプレミスのユースケースやシナリオといった幅広い状況で発生します。 IP アドレスへのルート こうしたユースケースに対処するため、Application Load Balancer が直接 IP アドレスにトラフィックをルートできるようになりました。こうしたアドレスは ALB と同じ VPC、同じリージョンにあるピア VPC、ClassicLink を経由した VPC とリンクしている EC2 インスタンス、VPN […]

Elastic Load Balancing(ELB)は、Auto ScalingとAmazon CloudWatchを含む3つの組みの一部としてローンチした2009年以来、AWSの重要な要素になっています。それから、私たちは多数の機能を追加し、そしてApplication Load Balancerをリリースしました。コンテナで稼働するアプリケーションに対するアプリケーションレベルでのコンテンツベースルーティングをサポートする様に設計されており、Application Load Balancer はマイクロサービス、ストリーミング、リアルタイムワークロードと相性が良いです。 長年にわたって、私達のお客様はあらゆる規模のwebサイトや、アプリケーションをサポートする為にELBを利用しています。1, 2台のT2インスタンス上で動くシンプルなサイトや、ハイエンドインスタンスで構成される大きなフリート上で動き大量のトラフィックを捌く複雑なアプリケーションにまで利用されています。ELBはバックグラウンドでトラフィックを監視し、需要に応じる様に自動的にスケールしています。このプロセスには、余裕をもったバッファが含まれていて、長年にわたってより迅速になりより反応性があがってきたことで、生放送やフラッシュセール、ホリデーシーズンををサポートするためにELBを利用しているお客様にとっても、よく動作します。しかしながら、リージョン間の瞬時のフェイルオーバーや急激なワークロードの変動（スパイク）などの状況では予想されるトラフィックの急増に対してELBをプリプロビジョニングをするようお客様と協力して対応してきました。 新しい Network Load Balancer 今日、新しいNetwork Load Balancer(NLB)を発表します。NLBは超低遅延で高いスループットを維持しながら利用者の努力なしに、秒間何百万リクエストを捌く様に設計されています。Network Load Balancerはターゲットグループやターゲットの完全なプログラム制御を含めて、Application Load BalancerとAPI互換性があります。最も重要な機能のいくつかは以下の通りです。 固定IPアドレス – 各Network Load Balancerは 各VPCサブネットの範囲に対して1つの固定IPアドレスを提供します。us-west-2aにあるサブネットにターゲットがあり、他のターゲットがus-west-2cのサブネットにあった場合、NLBは2つのIPアドレス(サブネットあたり1つ)を作成し管理します。そのIPアドレスに対する接続は そのサブネット内のインスタンス全体に分散します。さらに制御をするために、各サブネットに対して既存のElasticIPを割り当てることも可能です。IPアドレスを完全に制御することで、Network Load BalancerはIPアドレスを、DNSレコードやファイアウォールルールなどにハードコードされる必要がある場合でも利用可能です。 ゾーナリティ(Zonality) – サブネット単位のIP機能はパフォーマンスの向上により遅延を減少させ、アイソレーションとフォールトトレランスを通じて可用性を向上させ、Network Load Balancerの利用をクライアントアプリケーションから透過的にします。Network Load Balancerは、自動フェイルオーバーを可能にしながら、特定の送信元からの一連のリクエストを1つのサブネットのターゲットにルーティングします。 送信元アドレスの保持 – Network Load Balancerでは、到達コネクションのオリジナルの送信元IPアドレスと送信元ポートを維持するので、アプリケーションソフトウェアはX-Forwarded-Forやプロキシプロトコルや他のワークアラウンドをサポートする必要がありません。これは、VPC Security Groupsを含む一般的なファイアウォールルールをターゲット上で利用可能であることを意味しています。 長時間の接続 – NLBは組み込まれたフォールトトレランスによりコネクションを扱うため、NLBは何ヶ月も何年にもわたってオープンなコネクションを処理できるため、IoTやゲーム、メッセージングアプリケーションに最適です。 フェイルオーバー – Route53による ヘルスチェックによって、NLBはリージョン内およびリージョン間のIPアドレス間のフェイルオーバーをサポートします。(訳注: NLB単体では複数AZをサポートします) Network […]

いよいよ、AWS Cloud Roadshow 2017 powered by Intel®が始まります。 AWS Cloud Roadshow 2017 powered by Intel® は、広島、大阪、名古屋、福岡の 4 都市を巡る無料クラウドカンファレンスです。 本イベントでは、各地域で活躍を拡げる著名企業様によるクラウド導入事例セッションや AWS クラウドの最新テクノロジートレンドをご紹介するテクニカルセッションなどを通して、AWS が提供する様々なサービスのベストプラクティスを知ることができます。 また最終セッションでは、JAWS-UG Nightとして、AWSユーザーグループ主催のイベントがあります。私も各会場のUG Nightで過去3か月のAWSのアップデート纏めをお話させていただく予定です。 会場では、弊社アーキテクトや営業による案件相談やアーキテクチャ相談も可能です。 またお申込み可能ですので、是非以下よりお申し込みください。 広島(9/8) 大阪(9/21) 名古屋(9/27) 福岡(10/31) それではみなさんにお会いできることをAWSチーム一同おまちしております。 – プロダクトマーケティングエバンジェリスト 亀田 治伸

昨年、VMware Cloud on AWS を構築するために VMware と一緒に行っている作業についてお話ししました。そこでご報告したように、これはお客様待望の、伸縮性とセキュリティを維持しながら VMware SDDC スタックをベアメタル AWS インフラストラクチャ上で直接実行する、ネイティブな完全マネージド型製品です。これにより、当社のセキュリティを最重視したアーキテクチャの基盤部分であるネットワーキングとシステムレベルのハードウェア機能はもとより、AWS のスケーラビリティと弾力性の利点を活かすことができます。 VMware Cloud on AWS では、お客様が習得済みの知識とすでにお持ちのものを活用できます。お客様の既存のスキル、トレーニングへの投資、運用経験、ソフトウェアライセンスへの投資は、パブリッククラウドに移行しても応用して適用できます。この移行の中で、データセンターの構築や運用、ハードウェアの近代化、一時的または短期の需要に合わせたスケーリングは忘れて構いません。また、AWS の膨大なコンピューティング、データベース、分析、IoT、AI、セキュリティ、モバイル、デプロイメントおよびアプリケーションの各サービスを利用できます。 初期提供 Early Access ベータプログラムで多くのお客様やパートナーからいただいたフィードバックを反映させて、本日、VMworld において、VMware および Amazon は VMware Cloud on AWS の初期提供を発表しました。最初は米国西部 (オレゴン) リージョンで VMware および VMware Partner Network のメンバーを通して提供されます。これは、データセンター拡張、アプリケーションのデプロイおよびテスト、アプリケーションの移行などの一般的なユースケースをサポートするようにデザインされています。 この製品の販売、配信、サポート、請求は VMware が担当します。この製品はカスタムサイズの VM をサポートし、VMware でサポートされている任意の OS を実行します。シングルテナントのベアメタル AWS インフラストラクチャを活用してお持ちの Windows Server ライセンスをクラウドに持ってくることができます。各 SDDC (Software-Defined […]

本日、Amazon Web Servicesは、AWS Tools for Microsoft Visual Studio Team Services（VSTS）を発表しました（訳注：原文のBlog記事は2017/8/15にポストされました）。 ツールは無料で使用することができ、Visual Studio Marketplaceで配布されます。 VSTS内とTeam Foundation Serverでホストされたビルドとリリースのパイプラインで、AWSサービスと対話するためにこれらのタスクを使用することができます。 例えばタスクを利用してAmazon S3バケットとの間でコンテンツをコピーしたり、パイプラインにタスクを追加してAWS Elastic Beanstalk、AWS CodeDeploy、またはAWS Lambdaにビルド出力をデプロイしたりすることができます。 ツールはオープンソースとして提供されGitHubで公開されています。 この記事では、ツールのインストール方法、中に含まれるタスクの概要、セットアップを検証するための簡単なシナリオを実行し、いかに簡単に使使えるかを見ていきます。 後続の記事では、タスクの詳細とVSTSパイプラインでの使用方法について詳しく説明する予定です。   インストール AWS Tools for Microsoft Visual Studio Team Servicesのインストールは素早くて簡単です！ 最初にVisual Studio Marketplaceにアクセスしてください。 以下に示すように、ツールをインストールするには2つのオプションがあります。 オンラインのVSTSアカウントにインストールするか、ツールをダウンロードしてオンプレミスのTeam Foundation Serverインスタンスにインストールすることができます。 やることはこれだけです！ これでこの拡張機能のタスクは、アカウントまたはオンプレミスのインスタンスで使用できるようになりました。この最初のリリースで提供されているタスクを簡単に確認してみましょう。 先に述べたように、続く記事ではこれらのタスクのいくつかをより深く見ていくことになります。 AWS CloudFormation Create/Update Stack： このタスクでは、テンプレートファイルとオプションのパラメータファイルを使用して、AWS CloudFormationでスタックを作成または更新できます。 タスクはスタックがすでに存在するかどうかによって、既存のスタックを更新するか、新しいスタックを作成するかを自動的に切り替えます。 どちらの「モード」かを選択する必要はないため、パイプラインでの使用が便利です。 テンプレートとパラメータファイルを選択するだけでなく、変更セットを使用してスタックを作成または更新することも、変更セットを自動的に実行するオプションを追加することもできます（正常に検証された場合）。 また「Execute […]

Elastic Load BalancingのApplication Load Balancer機能の利点を活かして、スケーラブルなアプリケーションを構築してみたいですか？ Application Load Balancerを使えば、コンテンツベースのルーティングやHTTP/2、WebSocketプロトコルの機能を追加したり、コンテナや拡張メトリクスなどを追加することができます。 AWS OpsWorks Stackのユーザーから、レイヤーに新しいApplication Load Balancerをどのようにしたら追加できるかをAWSにご質問されていました。そこでAWSは、簡単にこれらを統合するためのChef 12のレシピのセットを開発し、オープンソースにすることを決めました。本記事ではOpsWorks StackにおけるChef 12 LinuxレイヤーでApplication Load Balancerと連携させるための手順を紹介します。 手順 特に記載がない限り、すべてのステップはOpsWorksコンソール内で完結されるものとします。 alb_supportレシピの概要 alb_support::attach_to_alb: こちらのレシピはApplication Load Balancerのターゲットグループにインスタンスをアタッチする実際の作業を行います。Setupライフサイクルイベントにより既存のが実行され、追加される必要があり、インスタンスがApplication Load Balancerにアタッチされる前にレシピが実行される必要があります。 alb_support::detach_from_alb: こちらのレシピはロードバランサーからインスタンスをデタッチします。Shutdownライフサイクルイベントにこちらのレシピを追加するようにしてください。Shutdownライフサイクルイベントにより実行される一連のレシピを実行後にこちらのレシピが実行され、こちらによりインスタンスはApplication Load Balancerからデタッチされ、コネクションはdrainされます。 alb_support:install および alb_support::uninstall_http_server: デフォルトのApplication Load Balancerのヘルスチェックをパスする簡単な方法、およびそのロードバランサーが想定した通りに動作していることを視覚的に示す方法として、AWSは80番ポートを使用するNGINXサーバをインストールおよびアンインストールして、デフォルトのテストページを提供するサンプルレシピも提供しています。 ステップ１：Application Load Balancerを作成する 80番ポートを使ってデフォルトのTCPリスナーとHTTPヘルスチェックをシンプルなALBを作成します。ターゲットグループにインスタンスを追加しないようにしてください。こちらはオープンソースのChefレシピによって処理されるためです。 ステップ２：Chef 12 stackを作成する 新しいChef 12 stackを作成します。必ずカスタムChef cookbooksの利用を有効にして、次の設定を行ってください。 Repository typeでは、Gitを選択します。 Repository URLでは、https://github.com/awslabs/opsworks-example-cookbooks を使用します。もし既に動作中のスタックがあれば、そのリポジトリからalb_cookbookをダウンロードして、ご自身のChefリポジトリにマージして、次のセクションを継続することができます。 ステップ３：stack内のインスタンスにElastic […]

こんにちは。プロフェッショナルサービスの宮本です。AWS Black Belt オンラインセミナー9月の配信について，ご案内させて頂きます。AWSのコスト最適化とリザーブドインスタンスについてのセミナーが追加になりましたので、改めて最新版の配信予定についてお知らせいたします。   9月の開催予定 サービスカット 9/6(水) 18:00-19:00 Amazon AppStream 2.0 9/13(水) 18:00-19:00 Amazon Aurora 9/19(火) 18:00-19:00 AWS DMS ※通常とは異なり、火曜日開催となりますのでご注意ください。 9/27(水) 18:00-19:00 Amazon CloudFront + AWS Lambda@Edge ソリューションカット 9/5(火) 12:00-13:00 AWSでのDDoS対策 9/12(火) 12:00-13:00 AWSのコスト最適化/リザーブドインスタンス お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

昨日、.NET Core 2.0がリリースされ（訳注：このブログ記事の原文は2017/8/15に発行されています）、AWSでは .NET Coreプラットフォームに追加された新機能と完成度にとても興奮しています。今後数か月以内に、AWSサービスをアップデートして、.NET Core 2.0のファーストクラスのサポートを提供します。 2つの簡単な方法ですぐにAWS上で.NET Core 2.0を使い始めることができます。   AWS Elastic Beanstalkの利用 Elastic Beanstalkを使用すると、Webアプリケーションを簡単に展開できます。現在、.NET Frameworkおよび.NET Core 1.1がサポートされています。 Elastic Beanstalkプラットフォームは、すぐに.NET Core 2.0をサポートするように更新されるでしょう。 それまではデプロイメントパッケージをカスタマイズして、デプロイ中のインスタンスに.NET Core 2.0をインストールするようにBeanstalkに指示することができます。 ASP.NET CoreアプリケーションがBeanstalkにデプロイされると、AWS-windows-deployment-manifest.jsonというJSONマニフェストがツールキットによって作成され、Beanstalkにアプリケーションのデプロイ方法を指示します。 以前のブログ記事では、このマニフェストのカスタマイズ方法について説明しました。 この機能を使用して、デプロイ前にPowerShellスクリプトを実行して.NET Core 2.0をインストールすることができます。 最初のステップとして、ASP.NET Core 2.0プロジェクトにaws-windows-deployment-manifest.jsonというファイルを追加します。 aws-windows-deployment-manifest.jsonのプロパティウィンドウで、[Copy to Output Directory]フィールドを必ず[Copy Always]に設定してください。 このファイルは、通常、ツールキットによって生成されますが、ツールキットがファイルがすでに存在することが判明した場合は、代わりにデプロイメントウィザードで指定された設定で既存のファイルを変更します。   次に、下の内容をコピーしてaws-windows-deployment-manifest.jsonに貼り付けます。 これはASP.NET Coreアプリケーションをデプロイし、デプロイの前に./Scripts/installnetcore20.ps1 PowerShellスクリプトを実行することを示しています。   { “manifestVersion”: 1, “deployments”: { “aspNetCoreWeb”: [ { […]