Amazon Web Services ブログ

Category: Compute

Amazon EC2 Systems Manager による Microsoft VSS を使用したスナップショットサポート

私たちはここでWindows AMIを稼働させるAmazon EC2におけるMicrosoftボリュームシャドウコピー(VSS)のサポートをアナウンスできることを嬉しく思います。VSSはMicrosoft Windows(主要なSQL ServerやExchange Serverなどのマイクロソフトアプリケーションを含む互換性のある)環境における非常に一般的なボリュームバックアップ技術です。VSSはファイルの書き込みなどのディスク処理をバックアップ処理実行中も適切に管理するため、アプリケーション一貫性を持ったバックアップが可能となります。 アプリケーション一貫性バックアップは、マシンまたはインスタンスに接続されたボリュームのバックアップと同時に実行され、メモリ内のすべてのデータと処理中のすべてのトランザクションをキャプチャします。 VSSが有効なAmazon EBSボリュームのスナップショット(以降、”VSS有効化スナップショット”と表記) は、Amazon EC2 Systems ManagerのRun Commandから使用可能です。AWSEC2-CreateVssSnapshot コマンドによってWindowsインスタンスのEC2にアタッチされたEBSボリュームを、バックアップ処理の間トランザクションデータの一貫性を失うことなく、アプリケーション一貫性を持ったスナップショットを取得可能です。この機能によってSQL Backupや、カスタムスクリプトなどによって提供されたアプリケーション固有のバックアップソリューションは不要となります。さらに、イメージレベルバックアップにおけるアプリケーション一貫性を維持するためのサードパーティ製ツールも不要になります。 AWSEC2-CreateVssSnapshotの使用方法 VSS有効化スナップショットは、Windowsが稼働するEC2インスタンスに対してAWSEC2-CreateVssSnapshotコマンドをEC2 Systems Manager Run Commandから呼び出すことで実行します。AWS管理コンソールやAWS CLIから実行したり、PowerShellスクリプトやLambda関数から呼び出すことも可能です。本ブログではEC2コンソールからコマンドで実行する例を示します。 EC2管理コンソールで、AWSEC2-CreateVssSnapshotコマンドのドキュメントを選択し、VSS有効化スナップショットを取得したいEBSボリュームを持つインスタンスを選択します。 インスタンスを選択した後、スナップショットに追加したい説明やタグを設定します。ブートボリュームをスナップショット処理から除外することも可能です。 起動されるとRun CommandはVSSコンポーネント(詳細については後述)に対して、EC2 Windowsインスタンス上のVSS対応アプリケーションのすべての処理中のI/Oをコーディネーションするよう指示します。これによってI/OバッファはEBSボリュームに対してフラッシュされ、すべてのI/Oはスナップショット取得が完了するまでフリーズされます。この結果アプリケーション一貫性が維持されます。スナップショットが取得された後、I/Oフリーズが解除され通常処理に復帰します。 Run Commandやスクリプトから取得したスナップショットは、EC2コンソール左側のEBSスナップショットメニューで確認できます。 このプロセスで正常に取得された全てのVSS有効化スナップショットには “AppConsistent:True”というタグが付与されます。本機能についてのより詳細についてはこちらAWSEC2-CreateVssSnapshot のドキュメントを参照してください。 VSS有効化スナップショットを取得するためのEC2インスタンスの準備 インスタンスへのスナップショット許可 : IAMコンソールを開き、”Amazon EC2″サービスに対する以下の権限を許可する新しいポリシーを作成します。 DescribeInstances CreateTags CreateSnapshot またIAMコンソールからAmazon EC2ロールAmazonEC2RoleForSSMに対して上記で作成したポリシーを適用します。さらにこのロールを直接EC2 Windowsインスタンスにアタッチします。 VSSコンポーネントのインストール : VSSコンポーネント(AwsVssComponents)をAWS-ConfigureAWSPakageコマンドをSystems ManagerのRun Commandから呼び出してインストールする必要があります。 より詳しいVSS有効化スナップショット取得のためのEC2インスタンスのセットアップについてはこちらAmazon EC2 ドキュメントを参照ください。 AWSEC2-CreateVssSnapshot使用する際には、対象のEC2インスタンスに対してEBSスナップショット作成およびタグ書き込み許可のIAM許可が必要となります。コンプライアンスやポリシーの理由から追加のIAM許諾をインスタンスに付与したくない場合には、カスタム可能なサンプルのスクリプトを活用可能です。このスクリプトの詳細についてはこちらAWSEC2-ManageVssIOに関するドキュメントを参照して下さい。 VSS有効化スナップショットのリストアプロセスは通常のEBSスナップショットと同様です。こちらのリストアのサンプルスクリプトも使用できます。このリストア用スクリプトで、指定されたEBSスナップショットからEC2 Windowsインスタンスにリストアすることが可能です。 […]

Read More

Amazon DynamoDB からのデータストリームを AWS Lambda と Amazon Kinesis Firehose を活用して Amazon Aurora に格納する

Aravind Kodandaramaiah は AWS パートナープログラムのパートナーソリューションアーキテクトです。 はじめに AWS ワークロードを実行するお客様は Amazon DynamoDB と Amazon Aurora の両方を使用していることがよくあります。Amazon DynamoDB は、どのような規模でも、一貫した、数ミリ秒台にレイテンシーを抑える必要のあるアプリケーションに適した、高速で柔軟性の高い NoSQL データベースサービスです。データモデルの柔軟性が高く、パフォーマンスが信頼できるため、モバイル、ウェブ、ゲーム、広告、IoT、他の多くのアプリケーションに最適です。 Amazon Aurora は、MySQL と互換性のあるリレーショナルデータベースエンジンで、オープンソースデータベースのコスト効率性と簡素性を備えた、高性能の商用データベースの可用性とスピードをあわせもったエンジンです。Amazon Aurora は、MySQL よりも最大 5 倍のパフォーマンスを発揮するだけでなく、商用データベースのセキュリティ、可用性、および信頼性を 10 分の 1 のコストで実現します。 DynamoDB と Aurora を連携させるために、カスタムウェブ解析エンジンを構築して、毎秒数百万のウェブクリックが DynamoDB に登録されるようにしたとします。Amazon DynamoDB はこの規模で動作し、データを高速に取り込むことができます。また、このクリックストリームデータを Amazon Aurora などのリレーショナルデータベース管理システム (RDBMS) にレプリケートする必要があるとします。さらに、ストアドプロシージャまたは関数内で SQL の機能を使用して、このデータに対してスライスアンドダイスや、さまざまな方法でのプロジェクションを行ったり、他のトランザクション目的で使用したりするとします。 DynamoDB から Aurora に効率的にデータをレプリケートするには、信頼性の高いスケーラブルなデータレプリケーション (ETL) プロセスを構築する必要があります。この記事では、AWS Lambda と Amazon […]

Read More

今すぐご利用可能 – Amazon EC2 コンピューティング最適化インスタンス C5

新しくコンピューティングに最適化されたC5インスタンスが、3つのAWSリージョン、6つのインスタンスサイズでリリースされ、今日から利用可能であることを発表することに興奮しています! これらのインスタンスは、バッチ処理、分散解析処理、高性能コンピューティング(HPC)、広告配信、スケーラブルなマルチプレーヤゲーミング、ビデオエンコーディングなどのコンピューティング重視のアプリケーション用に設計されています。 新しいインスタンスは、C4インスタンスに対して25%の価格/パフォーマンスの向上をもたらし、一部のワークロードでは50%を上回ります。 また、vCPUあたりの追加メモリ(新しいAVX-512命令を使用できるコードにおいて)は、2倍のベクターおよび浮動小数点演算のパフォーマンスを備えています。 AWSによって設計、構築された専用ハードウェアにさまざまな種類の作業をオフロードすることに長期的に視点を置き、最高のネットワーク、ストレージ、およびコンピューティングパフォーマンスを顧客に提供するために、私たちは長年にわたりノンストップで取り組んできました。 C5インスタンスタイプには、最新世代のハードウェアオフロードが組み込まれており、ハードウェアに手を加えて新しいハイパーバイザーを追加することで、さらに大きな前進を遂げています。新しいハイパーバイザーを使用すると、ホストハードウェアが提供するすべての処理能力にアクセスすることができます。同時に、パフォーマンスをより一貫して強化し、さらにセキュリティを強化します。 私たちはAWS re:Inventで、それに関する多くの技術的な詳細を共有します。 新しいインスタンス C5インスタンスは6つのサイズが利用可能です: Instance Name vCPUs RAM EBS Bandwidth Network Bandwidth c5.large 2 4 GiB Up to 2.25 Gbps Up to 10 Gbps c5.xlarge 4 8 GiB Up to 2.25 Gbps Up to 10 Gbps c5.2xlarge 8 16 GiB Up to 2.25 Gbps Up to 10 Gbps c5.4xlarge […]

Read More

新インスタンス- NVIDIA Tesla V100 GPUを最大8個搭載したAmazon EC2インスタンス P3

私たちは2006年に最初のm1.smallを発表した後も、お客様のご要望に応じて、そして常に進歩している最先端の技術を利用可能にするために、コンピュート能力、バースト可能な性能、メモリサイズ、ローカルストレージ、アクセラレータなどインスタンスを強化し続けています。 新しいP3インスタンス 本日、次世代のGPUを搭載したEC2インスタンスを4リージョンで公開しました。NVIDIA Tesla V100 GPUを最大8個搭載したP3インスタンスは、コンピュートインテンシブな機械学習、深層学習、流体計算、金融計算、地震解析、分子計算、ゲノム処理を想定して設計しました。 P3インスタンスは、最大2.7GHzで動作するIntel Xeon E5-2686v4プロセッサを搭載し、3種類のサイズを用意しています(VPCのみ、EBSのみ) Model NVIDIA Tesla V100 GPUs GPU Memory NVIDIA NVLink vCPUs Main Memory Network Bandwidth EBS Bandwidth p3.2xlarge 1 16 GiB n/a 8 61 GiB Up to 10 Gbps 1.5 Gbps p3.8xlarge 4 64 GiB 200 GBps 32 244 GiB 10 Gbps 7 Gbps p3.16xlarge 8 128 […]

Read More

Amazon Lightsail の更新 – Windows 仮想プライベートサーバーの起動と管理

Amazon Lightsail については、去年公開したブログ「Amazon Lightsail – AWS のパワーと VPS のシンプルさ (Amazon Lightsail – the Power of AWS, the Simplicity of a VPS)」でご紹介しました。昨年の公開以来、何千人ものユーザーがこの Lightsail を使用して AWS の利用を始めたり、Linux ベースの仮想プライベートサーバーを起動するようになりました。 そして本日より、Window 仮想プライベートサーバーのサポートも追加しました。ほんの数分で、Windows Server 2012 R2 を実行している VPS や Windows Server 2016、SQL Server 2016 Express を使う Windows Server 2016 を起動することができます。VPS を使用して、インフラストラクチャのセットアップや実行を必要とせずに .NET または Windows のアプリケーションを構築、テスト、デプロイすることができます。1 回または 2 回クリックするだけで、バックアップ、DNS 管理、オペレーションメトリクスにアクセスできます。 512 […]

Read More

Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ

本日よりAmazon EC2 Container Registry (Amazon ECR)で利用可能になったライフサイクルポリシーを使うことで、古い又は使われていないイメージを自動的に削除することで、コンテナイメージのレポジトリをきれいに保つことができるようになりました。 Amazon ECRはフルマネージドのDockerコンテナレジストリで、同時に何百ものプルを捌くための典型的なスケールの問題を心配することなく、Dockerコンテナイメージを保存し管理しデプロイすることができます。スケールの意味する所として、Amazon ECRを活発に利用している開発チームはしばしばたくさんのコンテナイメージのバージョンによってレポジトリが埋め尽くされていることを発見することがあります。これは問題になっているコードの変更を探すことを困難にし、不必要なストレージ料金も引き起こします。以前は、レポジトリをクリーンアップするには、手動で古いイメージを削除するのに時間を費やしたり、スクリプトを書いて実行する必要がありました。 今日からライフサイクルポリシーを使うことで、古いコンテナイメージを自動的に削除するためのいくつかのルールを定義することが可能になりました。ルールが実行された時に影響を受けるコンテナイメージを実際にプレビューで確認することも可能です。これによって、レポジトリはより組織化され問題になっているコードのリビジョンを簡単に見つけられ、そしてストレージコストも抑えられます。 それでは、ライフサイクルポリシーがどのように動くかを見てみましょう。 基本的なルール コンテナを使ってコードをデプロイすることの最も大きい利点の1つは、素早く簡単に過去のバージョンにロールバックできるということです。これにより、リスクを抑えてデプロイすることが可能になります。なぜならば、もし何かおかしかったら、過去のコンテナのバージョンに戻して、失敗したデプロイ以前の状態でアプリケーションを動作させることが簡単にできるからです。多くの人は、数個前のバージョンにロールバックするということはおそらくしないでしょう。もしこういった状況であれば、1つのシンプルなライフサイクルルールとしては、最新の30イメージを保持するというものが考えられます。 最新の30イメージ ECRレジストリの中から、Dry-Run Lifecycle Rules, Addを選択します。 Image Statusには、Untaggedを選択します。 Match criteriaでは、Count TypeにImage Count More Thanを入力します。 Count Numberには30を入力します。 Rule actionにはexpireを選択します。 Saveを選択します。どのイメージがクリーンアップされるかを見るには、Save and dry-run rulesを選択します。 もちろん、数による保持ではなく、コンプライアンスの理由で期限によっていくつかのイメージを保持したいチームも存在します。そういった場合には、90日以前のイメージをクリーンアップするという選択もできます。 最新90日分 先程作成したルールを選択し、Editを選びます。パラメータを変更して、タグがついていないイメージを90日だけ保持する様に変更します: Match criteriaでは、Count TypeにSince Image Pushedを入力します。 Count Numberには90を入力します。 Count Unitにはdaysを選択します。 タグ もちろん90日というのは任意の時間に設定できますが、ある特定の種類のイメージだけもっと長い期間保持するようなポリシーが必要なこともあります。そういった場合で、でも大掃除は続けたいというときには、タグがつけられたイメージだけ削除するというのを検討することも可能です。 こちらのルールのリストは、タグが無いもの、development、staging、そしてproductionなイメージへのルールの例をまとめてみたものです: タグのないイメージは90日以前を削除 developmentタグのついたイメージは90日以前を削除 stagingタグのついたイメージは180日以前を削除 productionタグのついたイメージは1年以前を削除 ご覧頂いた通り、新しいAmazon ECRのライフサイクルポリシーは強力で、必要なイメージだけを保持するのが簡単になり、もう必要のないイメージをクリーンアップしてくれます。この機能は本日よりAmazon […]

Read More

AWS CodePipeline, AWS CodeBuild, AWS Lambdaを使ったサーバーレス自動UIテスト

Webアプリケーションのユーザーインターフェイスをテストすることは、開発ライフサイクルの重要なパートです。 この記事では、AWS CodePipeline, AWS CodeBuild, AWS Lambdaなどのサーバーレス技術を利用してUIテストを自動化する方法を説明します。 S3でホストされているUIテスト用のWebサイトを構築しました。Seleniumを使用して、Chrome、Firefox、PhantomJS、およびWebDriver Wire Protocolの実装であるGhost DriverのヘッドレスWebKitブラウザで、クロスブラウザのUIテストを実行します。 テストが実行されているブラウザに基づいて、Pythonを使ってChromeDriver、FirefoxDriver、またはPhatomJSDriverのテストケースを作成しています。 この記事で紹介するAWS CloudFormationテンプレート、S3でホストされているテストおよびステータスWebサイト、AWS CodeBuildビルドスペックファイル、AWS Lambdaファンクション、テストを行うPythonスクリプトなどのリソースは、serverless-automated-ui-testing GitHubリポジトリで公開しています。   S3にホストされるテストWebサイト:AWS CodeBuildはカスタムコンテナをサポートしているため、FirefoxとChromeブラウザのプレビルドを含むSelenium/standalone-FirefoxとSelenium/standalone-Chromeコンテナをそれぞれ使用できます。Xvfbは、ディスプレイハードウェアなしで仮想メモリ内でグラフィカルオペレーションを実行します。 XvfbはインストールフェーズでCodeBuildコンテナにインストールされます。   Chrome and Firefoxテスト用のビルドスペック ChromeとFirefoxのテストのビルドスペックには、複数のフェーズがあります: 環境変数セクションには、ビルドプロジェクトの作成時またはビルドのトリガー時にオーバーライドされる一連のデフォルト変数が含まれます。 インストールフェーズの一部として、XvfbやSeleniumなどの必須パッケージがyumを使用してインストールされます。 pre_buildフェーズでは、テスト実行のためにテストベッドが準備されます。 ビルドフェーズでは、適切なDISPLAYが設定され、テストが実行されます。 version: 0.2 env:   variables:     BROWSER: “chrome”     WebURL: your s3 url     ArtifactBucket: “codebuild-demo-artifact-repository”     MODULES: “mod1”     ModuleTable: […]

Read More

今すぐ利用可能 – 4TBメモリ搭載のEC2インスタンス

今年の初めに、最大16TBメモリ搭載のEC2インスタンスを提供する計画をお伝えしました。本日、4つのAWSリージョンで4TBのDDR4メモリを搭載した新しいx1e.32xlargeインスタンスが利用可能になったことを発表いたします。以前の記事で書いたように、これらのインスタンスは、SAP HANAなどのメモリ重視のインメモリアプリケーションのために設計されています。 既に多くのお客様が、既存のx1.32xlargeインスタンス上で本稼働SAPアプリケーションを実行しています。本日のリリースによって、これらのお客様は、より大きなデータセットを保管・処理できるようになり、非常に大規模な本番環境でも稼働できるようになりました。 x1e.32xlargeは、x1.32xlarge同様に、4ソケットのIntel Xeon E7 8880 v3 Haswellプロセッサ 2.3GHz (128vCPUs)で実行され、大きなL3キャッシュやメモリ帯域幅を持ち、CステートとPステート制御による最適なパフォーマンスを提供します。 ネットワーク面では、インスタンスごとに最大8つのElastic Network Interfaces(ENIs)をサポートし、Elastic Network Adapter(ENA)によって、EC2プレイスメントグループ内で起動したときに最大25Gbpsのネットワーク帯域幅を提供します。インスタンスはデフォルトでEBS最適化されており、EBSボリューム専用の14Gbpsの帯域幅があり、インスタンスあたり最大80,000IOPSをサポートします。インスタンスには、1,920GBのSSDボリュームのペアも含まれています。 【いくつかのメモ】 x1e.32xlargeに関して、いくつか覚えておくべき事項があります: SAP認定 – x1e.32xlargeインスタンスは、SAP Business Suite on HANA(SoH)、SAP Business Warehouse on HANA(BWoH)、次世代ERPであるSAP S/4HANAや次世代データウェアハウスソリューションであるSAP BW/4HANAの本稼働HANA環境としてSAP社から認定およびサポートされる大規模なクラウドネイティブインスタンスです。もし、お客様が既にX1インスタンスでSAP HANAワークロードを実行されているのであれば、迅速かつ容易にスケールアップすることができます。SAP HANA on the AWS Cloud Quick Start Reference Deploymentは更新済みで、SAPとAWSのベストプラクティスに従って高い性能と信頼性を実現した構成の導入を支援します。SAP HANA Hardware DirectoryとSAP HANA Sizing Guidelinesも関連しています。 リザーブドインスタンス – リザーブドインスタンスのリージョン単位の柔軟性は、x1とx1eには適用されません。 【今すぐ利用可能】 x1e.32xlargeインスタンスは、米国東部(バージニア北部)、米国西部(オレゴン)、欧州(アイルランド)、そしてアジアパシフィック(東京)リージョンで、AWS Management Console、AWS Command Line Interface(CLI)、AWS SDKs、あるいはAWS […]

Read More

新機能 – DynamoDB VPCエンドポイントが出ました

今日(翻訳元記事2017年8月16日)からAmazon Virtual Private Cloud(VPC)でAmazon DynamoDB用エンドポイントがすべてのAWSのリージョンでご利用いただけます。AWS Management ConsoleまたはAWS Command Line Interface(CLI  コマンドラインインターフェイス)を使用して、すぐにエンドポイントをプロビジョニングできます。DynamoDBのVPCエンドポイントには追加費用はかかりません。 多くのAWSをお使い頂いているお客様は、セキュリティまたは分離の理由からAmazon Virtual Private Cloud(VPC)内でアプリケーションを実行します。以前は、VPC内のEC2インスタンスがDynamoDBにアクセスできるようにするには、2つのオプションがありました。インターネットゲートウェイ(NATゲートウェイを使用するかインスタンスの公開IPを割り当てる)を使用するか、すべてのトラフィックをVPNまたはAWS Direct Connect経由でローカルインフラストラクチャにルーティングしてからDynamoDBに戻すことができます。これらのソリューションには両方ともセキュリティとスループットの関係があり、NACLまたはセキュリティグループを構成してDynamoDBだけへのアクセスを制限することは困難でした。下の画像は上記のパターンのアーキテクチャです。 エンドポイントの作成 DynamoDBのVPCエンドポイントを作成しましょう。DescribeVpcEndpointServices APIコールを使用して、指定したリージョンでエンドポイントがサポートされていることを確認できます。 aws ec2 describe-vpc-endpoint-services –region us-east-1 { “ServiceNames”: [ “com.amazonaws.us-east-1.dynamodb”, “com.amazonaws.us-east-1.s3” ] } 上記の結果により、これらのエンドポイントをサポートしていることを確認出来ました。私は自分のVPCの1つを指定して、CLIまたはコンソールからの操作で簡単にエンドポイントをプロビジョニングできます。コンソールの使い方はこれから説明します。 最初に、VPCコンソールに移動し、サイドバーの[Endpoint]を選択します。そこから「Create Endpoint」をクリックして、この便利なコンソールに遷移します。 エンドポイントのAWS Identity and Access Management (IAM) ポリシーセクションに気づくでしょう。これは、通常のIAMポリシーでDynamoDBがサポートする詳細なアクセス制御をすべてサポートし、IAMポリシー条件に基づいてアクセスを制限できます。 今の例ではこのVPC内のインスタンスはフルアクセスし出来るようにして、「次のステップ」をクリックします。 これは私のVPC内のルートテーブルのリストに、これらのルートテーブルのどれに私のエンドポイントを割り当てるかを尋ねています。いずれかを選択して[Create Endpoint]をクリックします。 コンソールの警告メッセージに注意してください。パブリックIPアドレスに基づいてDynamoDBにソース制限がある場合、DynamoDBにアクセスするインスタンスのソースIPはプライベートIPアドレスになります。 DynamoDBのVPCエンドポイントをVPCに追加した後のアーキテクチャは次のようになります。 これでおしまいです!とても簡単で無料で利用する事ができます。是非利用してみて下さい。詳細が必要な場合は、ここでドキュメントを読むことができます。 (SA 成田が翻訳しました。元記事はこちら)

Read More

Lambda@Edge – エッジで HTTP リクエストを”賢く”処理する

昨年、Lambda@Edge のプレビューをアナウンスし、お客様に近いロケーションでHTTPリクエストを”賢く”処理する方法を説明しました。プレビューに応募しアクセスを許可された開発者は Lambda@Edge を有効に活用し、非常に有用な多くのフィードバックをいただきました。プレビュー中に HTTP レスポンスの生成、CloudWatch Logs のサポートを追加し、フィードバックに基いてロードマップを更新しました。 一般提供の開始 本日、 Lambda@Edge の一般提供を開始できることを嬉しく思います。次のように利用できます: A/B テストを行うために cookie を検査し、 URL を書き換える ユーザーエージェントヘッダに基づいて、特別なオブジェクトを返す オリジンにリクエストを許可する前に、特定のヘッダを検索することでアクセスコントロールを実装する ヘッダを追加、削除または変更して様々なキャッシュ済オブジェクトに誘導する HTTP レスポンスを生成する 古い URL 形式のサポート ヘッダや URL を変更または簡略化して、キャッシュ使用率を改善する 他のインターネットリソースへ HTTP リクエストを行い、その結果を使用してレスポンスをカスタマイズする

Read More