Amazon Web Services ブログ

Category: Compute

AWS でホストされたアプリケーション用のユーザーネットワークから Amazon VPC への接続

AWS では非常に多くのことが起こっており、十分な知識に基づく決定や、計画プロセスの例のまとめ方について支援を求める声が読者の方々からよく寄せられています。本日は、Amazon Marketplace の上級カテゴリーリーダー Jim Carroll が、AWS Marketplace における AWS ネットワーキングサービスとソリューションについて説明します。 -Ana 先月、当社は新しいロンドンの AWS リージョンについて発表しました。この新しいリージョンは当社のグローバルインフラストラクチャを拡大し、コスト効果のあるスケーリングを行い、コンプライアンスおよびデータレジデンシー要件を満たすための、より多くの地理的オプションをパートナーやお客様に提供します。この発表は私の記憶に生々しいものです。というのも、AWS Marketplace の AWS ネットワーキングサービスとソリューションに関してお客様と最近行った会話の中で、お客様はこれを利用して企業ネットワークを AWS クラウドの仮想プライベートネットワークと接続しているというお話を聞いたからです。通常、お客様は、次のいずれかのビジネスニーズまたはその組み合わせをサポートするために、AWS でこのアーキテクチャをデプロイしています。 AWS クラウドにアプリケーションを継続して移行する 離れた支社やリモート接続のために迅速かつコスト効果の高い方法でネットワークをスケールし、アプリケーションを AWS クラウドに移行中のエンドユーザーエクスペリエンスを向上させる コンプライアンスおよびデータレジデンシー要件を満たす 本日は、このようなビジネスニーズを持つお客様が利用できる VPN オプションを概説し、意思決定を簡単に行えるよう支援します。Amazon VPC では、AWS が管理する VPN の設定、AWS Direct Connect でのプライベート回線接続の使用、および VPN 接続のための VPC でのサードパーティーネットワーキングソフトウェアの有効化が可能です。ユーザーがデスクトップまたはモバイルデバイスから直接 AWS にアクセスできるようにする、クライアントからサイトへの VPN を選択することもできます。Steve Morad の 2014 年のホワイトペーパー「Amazon Virtual Private Cloud Connectivity […]

Read More

Amazon ECS におけるコンテナ インスタンス ドレイニングの自動化方法

同僚のMadhuri Periが素晴らしい記事を書いてくれました。AutoScalingグループのクラスタをスケールダウンする際にインスタンスからタスクを事前に削除するために、コンテナ インスタンス ドレイニングを利用する方法です。 —– Amazon ECSクラスタでは、クラスタからインスタンスを削除する必要があるタイミングというのがいくつかあります。例えば、システムを更新するとき、Dockerデーモンを更新するとき、あるいはクラスタのサイズをスケールダウンするときなどです。コンテナ インスタンス ドレイニング機能によって、クラスタ上のタスクに影響を与えることなく、コンテナインスタンスを削除することができます。この機能により、コンテナインスタンスがDRAINING状態である間はそのインスタンスに対して新しいタスクの配置がスケジュールされないようになり、利用可能なリソースがあればサービスがタスクをクラスタ上の他のコンテナインスタンスに移動してくれ、インスタンスを削除する前にタスクの移動が成功したことを待機できるようになります。 コンテナインスタンスの状態は、手動でDRAININGに変更することが可能です。しかしこの記事では、これらのプロセスを自動化するためにAutoScalingグループとAWS Lambdaを利用してコンテナ インスタンス ドレイニングを行う方法を説明します。 Amazon ECS オーバービュー Amazon ECSはコンテナ管理サービスです。クラスタやEC2インスタンスの論理グループ上でDockerコンテナの実行、停止、そして管理を容易にしてくれます。ECSを使ってタスクを実行するとき、タスクはクラスタに配置されます。Amazon ECSは指定されたレジストリからコンテナイメージをダウンロードし、そしてそのイメージをクラスタ内のコンテナインスタンス上で実行します。 コンテナ インスタンス ドレイニングの状態を扱う AutoScalingグループはライフサイクルフックをサポートしています。ライフサイクルフックは、インスタンスの起動や削除の前に独自の処理を完了するために呼び出されます。今回の例では、ライフサイクルフックは、2つの処理を実行するLambdaファンクションを呼び出します。 ECSコンテナインスタンスの状態をDRAININGに変更します。 コンテナインスタンス上にタスクが1つも残っていないことを確認します。もしドレイニング中のタスクがまだ存在する場合は、Lambdaファンクションを再度呼び出すためにSNSにメッセージを送信します。 コンテナインスタンス上で実行中のタスクがなくなるか、あるいはライフサイクルフックのハートビートタイムアウト(サンプルのCloudFormationテンプレートではTTL15分に設定)に達するか、どちらかの状態になるまでLambdaによってステップ2が繰り返されます。その後、制御はオートスケーリングのライフサイクルフックに戻され、そのインスタンスは削除されます。このプロセスを次の図に示します。 試してみましょう! この記事で説明した一連のリソースをセットアップするためにCloudFormationテンプレートを使用します。このCloudFormationテンプレートを使用するには、あなたのアカウントのS3バケットにLambdaデプロイメントパッケージをアップロードする必要があります。このテンプレートは次のリソースを作成します。 VPCと関連するネットワーク要素(サブネット、セキュリティグループ、ルートテーブルなど。) ECSクラスタ、ECSサービス、そしてサンプルのECSタスク定義 削除のライフサイクルフックと2つのEC2インスタンスが設定されたAutoScalingグループ Lambdaファンクション SNSトピック Lambdaを実行するために必要なIAMロール CloudFormationスタックを作成し、インスタンスの終了イベントをトリガーすることによってどのようにこのスタックが機能するのか見ていきます。 Amazon EC2のコンソールにおいて、AutoScalingグループを選択し、CloudFormationによって作成されたAutoScalingグループの名前(CloudFormationテンプレートのリソースのセクションから)を選択します。 操作、編集を選択し、インスタンスの希望の数を “1” に減らすようにサービスを更新します。これによって、2つのインスタンスのどちらか一方で終了プロセスが開始されます。 AutoScalingグループのインスタンスタブを選択します。1つのインスタンスのライフサイクルの状態が “Terminating:Wait” という値を示すはずです。 この状態になると、ライフサイクルフックが発火してSNSにメッセージが送信されます。そして、SNSメッセージトリガーに反応してLambdaファンクションが実行されます。 Lambdaファンクションによって、ECSコンテナインスタンスの状態がDRAININGに変更されます。その後、ECSサービススケジューラによってこのインスタンス上のタスクは停止され、利用可能なインスタンス上でタスクが起動されます。 ECSのコンソールに移動すれば、コンテナインスタンスの状態がDRAININGになっていることを確認できます。 タスクが全て完了すると、AutoScalingグループのアクティビティ履歴でEC2インスタンスの削除を確認できます。 どのように動作しているか 少しLambdaファンクションの内部的な動作を見てみましょう。ファンクションはまず最初に、受け取ったイベントのLifecycleTransitionの値が autoscaling:EC2_INSTANCE_TERMINATING にマッチするかをチェックします。 # もし受け取ったイベントがインスタンス終了中ならば・・・ if ‘LifecycleTransition’ […]

Read More

AWS Lambda – 2016 年を振り返って

2016 年は AWS Lambda、Amazon API Gateway、そして、サーバーレスコンピューティングテクノロジーにとって、控えめに言ってもすばらしい年となりました。もしかすると、AWS Lambda および Amazon API Gateway でのサーバーレスコンピューティングについて耳にしたことがない方がいらっしゃるかもしれませんので、これらのすばらしいサービスについてご紹介したいと思います。AWS Lambda を使用すると、サーバーをプロビジョニングまたは管理しなくてもコードを実行できます。このイベント駆動型のサーバーレスコンピューティングサービスにより、開発者は、ほぼすべての種類のアプリケーションまたはバックエンドで機能を簡単にクラウドへ移行できます。Amazon API Gateway は非常にスケーラブルで、信頼性が高く、堅牢な API を大規模にすばやく構築するのに役立ち、作成した API の維持およびモニタリングの機能も提供します。2016 年のサーバーレスの勢いの締めくくりとして、AWS チームは re:Invent でサーバーレスソリューションの構築をさらに簡単にする強力なサービス機能を発表しました。その機能には次のものがあります。 AWS Greengrass: Lambda および AWS IoT を使用して、接続された IoT デバイスのローカルでのコンピューティング、メッセージング、データのキャッシングを実行します。https://aws.amazon.com/blogs/aws/aws-greengrass-ubiquitous-real-world-computing/ Lambda@Edge Preview: グローバル AWS エッジロケーションでコードを実行でき、Amazon CloudFront のリクエストに応じてトリガーされることで、エンドユーザーのネットワークレイテンシーを削減できる Lambda の新しい機能です。https://aws.amazon.com/blogs/aws/coming-soon-lambda-at-the-edge/ AWS Batch Preview: 今後予定されているバッチジョブとしての Lambda 統合を含む AWS コンピューティングサービスにおけるワークロードの計画、スケジューリング、実行のコンピューティング用バッチです。https://aws.amazon.com/blogs/aws/aws-batch-run-batch-computing-jobs-on-aws/ AWS X-Ray: マイクロサービスアーキテクチャを使用してビルドされたもの、Java、Node.js、.NET で記述されたもの、EC2、ECS、AWS […]

Read More

事前にご確認ください – AWSにおける2016年12月31日(日本時間2017年1月1日)のうるう秒

2016年末最後の数秒をカウントダウンする場合は、最後に1秒を追加するのを忘れないようにしてください! 次回のうるう秒(通算27回目)が、UTC(世界標準時)の2016年12月31日 23:59:60として挿入されます(訳注:日本標準時では2017年1月1日 8:59:60になります)。これは地球上での時刻(協定世界時)と太陽時(天文時)とのずれを小さくするために行われ、この結果、UTCでは今年最後の1分は61秒あることになります。 参考)「うるう秒」挿入のお知らせ(総務省) 前回のうるう秒の際に出した情報(事前にご確認ください – AWSでのうるう秒対応)は引き続き有効で、今回も同様に処理されますが、少しの違いと進展があります: AWS調整時刻(AWS Adjusted Time) –うるう秒挿入前後の24時間の期間にわたって、うるう秒の1秒を少しずつ分散します(UTCで12月31日の11:59:59から、2017年1月1日12:00:00まで)。AWS調整時刻と協定世界時はこの期間が終了後に同期します。(訳注:この期間の1秒をごくわずかに遅くすることで、追加される1秒を長い時間のなかに分散する方法であり、これは前回うるう秒挿入時と同じ挙動です。詳しくは前回の情報をご確認ください。) Microsoft Windows – Amazonによって提供されたMicrosoft WindowsのAMIを利用しているインスタンスは、AWS調整時刻に従います。 Amazon RDS – 大多数のAmazon RDS インスタンスは (UTCで設定されている場合)“23:59:59” を2回記録します。しかし、Oracle 11.2.0.2、11.2.0.3、12.1.0.1 はAWS調整時刻に従います。Oracle 11.2.0.4と12.1.0.2について詳細な情報が必要な場合はAWSサポートにお問い合わせください。 サポートが必要ですか? このうるう秒挿入についてご質問がある場合は、AWSサポートにコンタクトいただくか、EC2フォーラムにポストしてください。 — Jeff; 翻訳:下佐粉 昭(@simosako) 原文:https://aws.amazon.com/blogs/aws/look-before-you-leap-december-31-2016-leap-second-on-aws/

Read More

EC2 Systems Manager – EC2 およびオンプレミスのシステムの設定と管理

去年、EC2 Run Command をご紹介して、最初に EC2 インスタンスで、次いでハイブリッドおよびクラウド間の環境で大規模なリモートのインスタンス管理をするための使い方をご説明しました。その過程で、Linux インスタンスのサポートを追加したため、EC2 Run Command は幅広く応用できる非常に便利な管理ツールになりました。 ファミリーへようこそ Werner が EC2 Systems Manager を で発表したので、ついにお話しできるようになりました。これは、同じように便利な 8 つの機能と共に EC2 Run Command の強化版を含む新しい管理サービスです。EC2 Run Command と同様に、Windows と Linux を実行するインスタンスとサービスで構成されたハイブリッドおよびクラウド間の環境をサポートします。 を開き、管理するインスタンスを選択して、実施するタスクを定義します (API および CLI のアクセスも可能)。機能拡張と新機能の概要を次に示します。 Run Command – コマンドの実行速度を制御し、エラー率が高くなりすぎたときにコマンドの発行を停止できるようになりました。 State Manager – 定期的に適用される、ポリシーで定義されたシステム設定を維持します。 パラメーターストア – ライセンスキー、パスワード、ユーザーリスト、その他の値の一元管理型 (オプションで暗号化された) ストレージを提供します。 メンテナンス時間 – 更新のインストール、その他のシステムメンテナンスの時間枠を指定します。 ソフトウェアインベントリ – 各インスタンスから、詳細なソフトウェアおよび設定のインベントリ (ユーザー定義の追加を含む) […]

Read More

AWS LambdaのC#サポートの発表

本日、AWS Lambdaのサポート言語としてC#を発表しました。新しいオープンソースの.NET Core 1.0ランタイムを使用すると、さまざまな一般的な.NETツールからC#コードをAWS Lambdaに簡単に公開できます。 .NET開発者は、C#言語と使い慣れた.NETツールを使用して、Lambda関数とサーバーレス アプリケーションを作成できます。 Visual Studio、Yeoman、およびdotnet CLIにおけるツール サポートによって、C#で記述された個々のLambda関数またはサーバーレスアプリケーション全体をLambdaおよび Amazon API Gatewayに簡単に展開できます。 LambdaはAWSサーバーレスプラットフォームの中核です。もともと2015年に発売されたLambdaでは、インフラストラクチャやスケーリングを心配することなく、Node.js、Python、およびJavaコードをAWSに展開することができます。これにより、開発者はアプリケーションのビジネスロジックに集中でき、インフラストラクチャの維持と拡張に時間を費やす必要がありません。今日まで、.NET開発者はこのモデルを利用することができませんでした。サポートされている言語のリストにC#を追加し、サーバーレスアプリケーションを作成すためにLambdaとAPIゲートウェイを利用する新しいカテゴリの開発者ができたことを嬉しく思っています。   C#でのLambda 単純なC#ラムダ関数を見てください。 既にNode.js、Python、JavaでLambdaを使っていたなら、これはよく分かるはずです: using System; using System.IO; using System.Text; using Amazon.Lambda.Core; using Amazon.Lambda.DynamoDBEvents; using Amazon.Lambda.Serialization.Json; namespace DynamoDBStreams { public class DdbSample { private static readonly JsonSerializer _jsonSerializer = new JsonSerializer(); [LambdaSerializer(typeof(JsonSerializer))] public void ProcessDynamoEvent(DynamoDBEvent dynamoEvent) { Console.WriteLine($”Beginning to process {dynamoEvent.Records.Count} […]

Read More

新機能 – Virtual Private Cloud での EC2 インスタンスの IPv6 サポート

インターネットは、特にモバイルアプリケーション、コネクテッドデバイス、そしてIoTの分野で引き続き成長しており、それが業界全体のIPv6への移行に拍車をかけています。米国政府機関は2010年に定められた指令に従って、パブリックに公開されたサーバーとサービスをできるだけすみやかにIPv6に移行するように取り組んでいます。128ビットのアドレス空間を持つIPv6では十分な拡張の余地があり、新しいアプリケーションやユースケースへの道が開かれます。 EC2のIPv6 今年の初めに、S3 (Transfer Accelerationを含む)、CloudFront、WAF、および Route 53のIPv6サポートを開始しました。本日、新しい大きなステップとして、Virtual Private Cloud (VPC) およびEC2インスタンスのIPv6サポートを開始しました。米国東部 (オハイオ) リージョンを皮切りに、他のリージョンも対応を進めていきます。 IPv6サポートは、新規および既存のVPCで利用できます。マネジメントコンソール上でチェックボックスにチェックを入れるだけで、VPCごとにオプトインすることができます (APIとCLIもサポートされます)。

Read More

Lambda@Edge – プレビュー

ちょうど先週、私が Hacker News上で書いたコメントがきっかけでAWSのお客様から興味深いメールを頂きました。 彼はS3上でホストしているシングルページのアプリケーションを動作させていて(こちらについてはAmazon S3で静的なWebサイトの運用が可能に をご覧下さい。)、Amazon CloudFrontを経由して少ないレイテンシーで提供していると教えてくれました。そのページは、AWS Elastic Beanstalk上でホストしているAPIを使って、それぞれのユーザー向けにカスタマイズして表示するいくつかの動的な要素を含みます。 彼が説明してくれた彼の課題はこちらです。 適切に検索エンジンのインデックスを取得するために、またFacebookやTwitterないで正しく表示するためのコンテンツのプレビューをするためには、それぞれのページが事前に表示されたバージョンを提供する必要があります。こちらを実現するには、一般ユーザーがヒットするたびに、私たちのサイトはノーマルのフロントエンドをCloudFrontから提供する必要があります。しかし、もしユーザーエージェントがGoogle / Facebook / Twitter等にマッチする場合は、その代りに私たちは事前に表示されたバージョンへリダイレクトさせる必要があります。 私たちはこのユースケースについてよく分かっており、興味深いソリューションを準備中であることを彼に秘密を漏らすことなく伝えました。他のお客様もまた、エッジにおいてクイックな判定によりカスタマイズしたいと伝えてくれてました。 お客様に近いロケーションでHTTPリクエストを”賢く”処理しなければならないユースケースがあることがわかりました。これらには、HTTPヘッダの検査および変更、アクセスコントロール(特定のcookieを必要とする)、デバイス検出、A/Bテスト、クローラーまたはbotsのための処理または特別な対応、レガシーシステムに適応させるためにユーザーフレンドリーなURLを書き換えるユースケースを含みます。多くのこれらのユースケースは、シンプルなパターンマッチングやルールによって表現可能なユースケースよりも多くの処理や判定を必要とします。 Lambda@Edge これらのユースケースのサポートを提供するために、私はLambda@Edgeのプレビューをラウンチしています。この新しいLambdaベースの処理モデルにより、ますます増加するAWSエッジロケーションのネットワーク内で動作するJavaScriptコードを書くことが出来ます。 CloudFrontのディストリビューションを通して流れるリクエストやレスポンスを処理する軽量なロジックを書くことができます。4つの異なるイベントに対するレスポンスの中でコードを実行できます。 Viewer リクエスト – あなたのコードは、コンテンツがキャッシュされるか否かに関わらず、あらゆるリクエストにおいて動作します。こちらがシンプルなヘッダ処理用のコードです。 exports.viewer_request_handler = function(event, context) { var headers = event.Records[0].cf.request.headers; for (var header in headers) { headers[“X-“.concat(header)] = headers[header]; } context.succeed(event.Records[0].cf.request); } Origin リクエスト – リクエストされたコンテンツがエッジでキャッシュされていない時に、Originに転送される前にコードを実行します。ヘッダを追加したり、既存のヘッダを編集したり、URLを編集したりすることが可能です。 Viewer レスポンス – キャッシュされているか否かに関わらず、すべてのレスポンスにおいてコードを実行します。Viewerに戻す必要のないヘッダをクリーンアップするためにこちらを利用できます。 Origin レスポンス – […]

Read More

新しい T2.Xlarge および T2.2Xlarge インスタンス

AWSのお客様はT2インスタンスを使う時に得られるコスト効率のよい、バーストベースのモデルを好まれています。これらのお客様は webサーバや開発環境、継続的なインテグレーション用のサーバ、テスト環境、そして小さなデータベース等の一般的な用途でのワークロードを動作させるのにT2インスタンスを使います。これらのインスタンスは豊富なベースラインパフォーマンスと、必要に応じてフルコアのプロセッシングパワーにまで透過的にスケールアップを提供します。(もしこちらがあなたにとって新しいニュースであれば、バースト可能な性能を持つ新しい低コストEC2インスタンスをご参照ください) 本日2つの新しいより大きなT2インスタンスサイズを追加します。- 16GiB メモリの t2.xlargeと32GiB メモリのt2.2xlarge です。これらの新しいサイズにより、お客様はより大きなリソースの要件のアプリケーション向けに T2のバーストモデルの価格とパフォーマンスのメリットを享受頂けます。(t2インスタンスのレンジを拡大するのは、今回が3度目になります;昨年の6月にt2.largeを、昨年の12月にt2.nanoを追加しました。 こちらがT2インスタンスのすべてのサイズ向けのスペックになります。(価格は最近のEC2の値下げを反映しています。US Eastリージョンの料金になります。) 名前 vCPU ベースラインパフォーマンス プラットフォーム メモリ CPU クレジット / 時間 価格 / 時間 (Linux) t2.nano  1  5%  32bit または 64-bit  0.5  3  $0.0059 t2.micro 1 10%  32bit または 64-bit 1 6 $0.012 t2.small 1 20%  32bit または 64-bit 2 12 $0.023 t2.medium 2 40%  32bit […]

Read More

進行中 ー Amazon EC2 Elastic GPUs

私は過去にGPUベースのコンピューティングのメリットについて書いてきました。最近では最大16個のGPUを搭載したP2インスタンスのリリースがありました。過去に指摘したように、GPUは驚異的なパワーとスケールを提供し、同時に結果を得るまでの時間と全体的な計算コストを削減する可能性があります。 今日、私たちが取り組んでいる新しいGPUベースの機能について少しお話したいと思います。 もう少しすると既存のEC2インスタンスタイプにグラフィックアクセラレーションを追加することができるようになります。 G2またはP2インスタンスを使用する場合、インスタンスサイズによってGPUの数が決まります。 これは多くの種類のアプリケーションでうまく機能しますが、他の数多くのアプリケーションでも、より新しい、より柔軟なモデルを利用する準備が整ったと考えています。 Amazon EC2 Elastic GPUs 発表されたAmazon EC2 Elastic GPUは、それぞれ異なる長所を提供します。アプリケーションに最適なEC2インスタンスのタイプとサイズを選択でき、また、インスタンスを起動する際にElastic GPUの使用を指定し、4種類のサイズから選択できます。 Name GPU Memory eg1.medium 1 GiB eg1.large 2 GiB eg1.xlarge 4 GiB eg1.2xlarge 8 GiB Elastic GPUをM4、C4、およびX1インスタンスで使用できるようになります。 現在、新しいインスタンスを起動するときに新しく作成されたEBSボリュームを設定する機能がありますが、 Elastic GPUについても同様に起動設定の際に希望のサイズを指定したり、実行中のインスタンスを停止、起動することにより変更が可能です。 OpenGLで始める Amazonに最適化したOpenGLライブラリは、自動的にElastic GPUを検出して使用します。 OpenGLのWindowsのサポートから始め、その後、Amazon Linux AMIやOpenGLの他のバージョンのサポートを追加する予定です。 また、DirectXやVulkanなど他の3D APIのサポートも検討しています(興味があるかどうかをお知らせください)。 既存のMicrosoft Windows AMIのリビジョンにAmazonに最適化したOpenGLライブラリを追加します。 OpenGLはレンダリングには最適ですが、レンダリングされたものはどうやって見ますか? 素晴らしい質問です! 1つの選択肢は、レンダリングされたコンテンツをHTML5と互換性のあるブラウザやデバイスにストリーミングするために、NICE Desktop Cloud Visualization(今年初めに買収 – Amazon Web Services to […]

Read More