Category: Compute

私の同僚 Deepak Singh が、コンテナに関してたくさんお伝えしたいことがあります！ – Jeff; AWS 上で Kubernetes を利用している多くのお客様がいます。実際、Cloud Native Computing Foundationによると、Kubernetes のワークロードの63％が AWS 上で動作しています。AWS は Kubernetes を実行するうえで人気の場所ですが、お客様が Kubernetes クラスターを管理するためには、依然として多くの手動設定が必要となります。Kubernetes のマスターをインストールして運用し、Kubernetes のワーカーのクラスターを構成する必要があります。Kubernetes クラスターで高可用性を実現するには、異なる AZ 間で少なくとも三つの Kubernetes マスターを実行する必要があります。各マスターは、それぞれで対話し、障害が発生した場合に備え情報を共有し、負荷分散、フェールオーバーを他のマスターに確実に実行するように構成する必要があります。そして、すべての設定と実行が完了しても、マスターとワーカーのソフトウェアのアップグレードとパッチ適用を行う必要があります。これらは運用の専門家とその努力必要としており、我々はお客様からもっと簡単にしてほしいと言われてきました。 Amazon EKS の紹介 Amazon Elastic Container Service for Kubernetes (Amazon EKS) は、Kubernetes クラスターの専門家でなくてもKubernetesを AWS 上で簡単に使用することができるフルマネージドサービスです。開発者の皆様にこのサービスを気に入ってもらえるいくつかの点があります。まず、Amazon EKS は オープンソースの Kubernetes を基に実行されますので、Kubernetes コミュニティの全ての既存のプラグインとツールを使用できます。Amazon EKS 上で動作するアプリケーションは、オンプレミスのデータセンターやパブリッククラウドで動作しているかにかかわらず、標準の Kubernetes 環境で動作するアプリケーションと完全に互換性があります。つまり、コード変更なしで簡単にあなたの Kubernetes アプリケーションを […]

AWS上でコンテナを運用管理するお客様の手助けになるようAmazon Elastic Container Service(Amazon ECS)をアナウンスしたのは約3年前でした。Amazon ECSを利用することで、クラスター管理やオーケストレーション用ソフトウェアを運用することについて心配する必要がなくなり、大規模に高い可用性を持ってワークロードを稼働させることが可能になりました。 2017/11/29、AWSは AWS Fargateをアナウンスしました。下回りとなるインスタンス群の管理をせずとも、コンテナを基本的な計算単位として利用することができる技術です。Fargateをご利用いただくことで、コンテナを動かすためにクラスター内の仮想マシンのプロビジョニング、設定やスケールを行う必要はもうありません。Fargateは現在Amazon ECSから利用可能ですが、将来的にはAmazon Elastic Container Service for Kubernetes (Amazon EKS)もサポートする予定です。 Fargateでは、アプリケーションの要件に対して最も近い設定を柔軟に行うことができ、請求は秒単位となります。 Amazon ECSとFargate Amazon ECSは、コンテナを大規模に稼働させることを可能にします。また、このサービスは、VPC networking、load balancing、IAM、Amazon CloudWatch LogsやCloudWatch metricsといったAWSプラットフォームとネイティブに連携しています。これらの連携により、ECSタスクはAWSプラットフォームの中でファーストクラスオブジェクトとして扱うことができます。 タスクを起動するためには、適切なインスタンスタイプと数を選び、Auto Scalingを設定し、パフォーマンス向上のためにクラスターのサイジングを管理するといったクラスターの立ち上げが必要ですが、Fargateでは、それらを全て忘れることができ、アプリケーションの定義、権限やスケーリングについてのポリシー設定に専念することができます。

コンテナは、開発者がアプリケーションを開発・パッケージ・デプロイするのに強力な手法の１つです。AWSでは、十万以上のアクティブなECSクラスタが稼働しており、毎週数億の新しいコンテナが起動しています。これは、2016年からすると400%を超えるお客様成長率です。Amazon ECSやKubernetesといったコンテナのオーケストレーションソリューションは、コンテナワークロードのデプロイ・管理・スケールをより容易にし、敏捷性を増します。しかし、それらのどのソリューションも下回りとなるインフラストラクチャの可用性、キャパシティやメンテナンスを行う必要が依然としてあります。AWSにおいて、私たちはこれを差別化とならない重労働を取り除く機会と考えました。私たちは、コンテナがもたらすスピード、敏捷性や不変性のメリットを十分にお客様にご利用いただき、インフラストラクチャの管理ではなくアプリケーションの構築に注力いただきたいと思っています。 AWS Fargate AWS Fargateは、コンテナをデプロイする最も簡単な方法です。端的に言うと、FargateはEC2に似ていますが、仮想マシンを提供する代わりに、コンテナを提供します。これにより、下回りとなるインスタンス群の管理をせずとも、コンテナを基本的な計算単位として利用することができる技術です。やるべきことは、コンテナイメージ構築し、CPUやメモリの要件を指定し、ネットワークやIAMポリシーを定義し、そしてコンテナを起動することです。Fargateでは、アプリケーションの要件に対して最も近い設定を柔軟に行うことができ、請求は秒単位となります。

お客様からAWSへの優れたリクエストをいただく際、私達は詳細に要望をお聞きし、多くの質問をし、理解をしてニーズに応えられるようベストを尽くしています。これらの活動の結果として私達はサービスや新機能をリリースしています。 一方で私達は決して特定のお客様専用の一度きりの仕組みを作りこんだりはしません。その方法は混乱を生み、スケールさせる事を困難にしますし、私達のやり方ではありません。 そうではなく、全てのAWSのお客様は私達が作ったもの全てにアクセスでき、全員が利益を得ることが出来ます。VMware Cloud on AWSがこの戦略での良い実例でしょう。VMware社は私達に、VMwareの仮想化スタックをAWSクラウドのハードウェア上で直接稼働させたい、それによってお客様がAWSがオファーする拡張性、セキュリティ、信頼性を手に入れることが出来るとリクエストしました。 私達は仮想化層をネストする事によるパフォーマンス低下を望んでいない他のお客様からもベアメタルハードウェアに興味があると聞いていました。お客様は物理リソースにアクセスし、パフォーマンスカウンターやIntel® VTといった、仮想化環境では通常サポートされないローレベルのハードウェア機能を利用したいと考えていました。また、非仮想化環境でしか稼働できないライセンスのソフトウェアを稼働させるために必要としている方もいました。 ネットワーク、ストレージ、その他EC2関連機能を仮想化プラットフォームの外に出して、専用ハードウェアに移動させる努力を数年間に渡って続けてきており、より良い環境を提供できるための下地が出来ています。この活動は以前のこのブログ（今すぐご利用可能 – Amazon EC2 コンピューティング最適化インスタンス C5）で紹介しており、ハードウエアアクセラレーターでの性能向上を提供できています。 そして現在ではVMware社からのリクエストにあったように、ベアメタルのハードウェアをVMwareハイパーバイザーとともに用意し、これまで通り全てのAWSのお客様に提供しています。では次は何が出来るようになるのか、ぜひ見てみましょう！

私たちはここで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コンポーネントのインストール : 2017年11月以降のMicrosoft Windows Server AMIイメージにはVSSコンポーネントはプリインストールされています。もし使用しているWindowsインスタンスのパッケージが最新でない場合は、VSSコンポーネント(AwsVssComponents)をAWS-ConfigureAWSPakageコマンドをSystems ManagerのRun Commandから呼び出してインストールする必要があります。 より詳しいVSS有効化スナップショット取得のためのEC2インスタンスのセットアップについてはこちらAmazon EC2 ドキュメントを参照ください。 […]

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

新しくコンピューティングに最適化された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 […]

私たちは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 […]

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

本日より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 […]