Amazon Web Services ブログ

強力なAWSプラットフォームの特徴、コンテナ向けに

コンテナは素晴らしいのですが、それを管理することは非常に難しい問題です。私達のお客様は、マイクロサービスからバッチジョブにいたるまで、多くのワークロードでコンテナをAWS上で使ってきました。彼らが私達に教えてくれたのは、EC2インスタンスやコンテナの状態を含むクラスタ管理はトリッキーで、特に環境が大きくなってくると問題になってくるということでした。また、AWSプラットフォームで利用可能な、ロードバランサー、スケーリング、セキュリティ、モニタリング等の機能とコンテナとの連携は重要な要件であるとも教えてくれました。Amazon ECSはこれら全ての要求とそれ以上に応えるために設計されました。

我々はお客様がコンテナ化したアプリケーションを本番環境で稼働させることを簡単にするためにAmazon ECSを作りました。コンテナ管理のためのソフトウェアをインストールしたり運用したりする必要は全くなく、これらは全てサービスとして提供されます。必要となるEC2のキャパシティをクラスタに追加して、使いたいコンテナイメージをアップロードするだけで良いです。Amazon ECSが残りの面倒をみてくれて、EC2インスタンスのクラスタ上にコンテナをデプロイしてそのヘルス状態を監視してくれます。ExpediaRemind等のお客様は、Amazon ECSを開発ワークフローに組み込み、その上にPaaSプラットフォームを構築しています。他には、PreziShippableはECSを使ってコンテナを実行するための運用の複雑さを削減し、より多くの時間をアプリケーションの機能を提供することに使えるようにしています。

AWSは高い信頼性とスケーラビリティを持ったフルマネージドのサービスとして、ロードバランサー、Auto Scaling、IAM、ロギング、そしてモニタリングを提供してます。この1年間、EC2インスタンスで利用できるものと同じものを利用できるように、ECSを通じたこれらAWSプラットフォームの機能とのネイティブな連携を続けてきました。

Amazon ECSはここ最近で、アプリケーションロードバランサーの対応(本日)、IAMロールの対応(7月)、そしてAuto Scalingの対応(5月)に提供しました。これからも、より多くのAWSプラットフォームをコンテナに持ってくることを楽しみにしています。

それでは、新しい特徴を見てみましょう!

アプリケーションロードバランサー

負荷分散とサービスディスカバリは、どのマイクロサービスアーキテクチャでも必要不可欠なものです。Amazon ECSはElastic Load Balancingを使っているので、負荷分散のレイヤーで管理やスケールをする必要はありません。またELBをサポートする他のAWSサービスも直接扱うことができます。例えば、AWS Certificate Manager (ACM)でサービスの証明書を自動的に管理したり、Amazon API Gatewayで呼び出しの認証を行ったりできます。

本日、ECSは新しいアプリケーションロードバランサーをサポートすることを発表できることをとても嬉しく思います。高いパフォーマンスを持ったアプリケーションレイヤで行われる負荷分散の選択肢で、コンテントベースのルーティングルールを定義することができます。アプリケーションロードバランサーは、マイクロサービスの実行を簡潔にしてくれる2つの機能を含んでいます: 動的ポートと、複数サービスで1つのロードバランサーを共有できる機能です。

動的ポートによって、ポートの衝突を心配する必要がなくなるので、クラスタ上でのタスクの開始がとても簡単になります。以前は、Elastic Load Balancerをアプリケーションのトラフィックのルーティングに使っていると、ECSタスクではホスト側のポートを固定で定義する必要がありました。これは、各アプリケーションが使っているポートを管理しなければならないという運用の複雑さを招き、また1つのタスクしか1つのインスタンスに配置できないのでクラスタの効率も下げていました。これからは、ECSのタスク定義では動的ポートを指定することができ、EC2インスタンスがスケジュールされた時に未使用のポートが割り当てられます。ECSスケジューラは自動的にそのタスクをアプリケーションロードバランサーのターゲットグループに登録する時にこのポートを使います。使いはじめるには、アプリケーションロードバランサーをEC2コンソールAWS Command Line Interface (CLI)で作成できます。そしてECSコンソールでタスク定義を作る時にコンテナのホストポートを0としておきます。このコンテナはスケジュールされた時に自動的にエフェメラルポートのレンジからポートを受け取ります。

以前は、ECSサービスとロードバランサーの間には1対1のマッピングしかありませんでした。これからは、パスベースのルーティングを使うことで、複数のサービスでロードバランサーを共有できます。各サービスがそれぞれのURIを定義することで、サービスにトラフィックを向けることができます。加えて、基本的なサービスディスカバリをサポートするために、そのサービスのDNS名を環境変数に指定することができます。例えば、株価のサービスを http://example.com/stock で、天気のサービスを http://example.com/weather で、同一のロードバランサーから提供することができれば、ニュースポータルは株価と天気のサービスのどちらにもロードバランサー経由でアクセスすることができます。

ECSタスクのIAMロール

Amazon ECSでは、EC2コンテナインスタンスのIAMロールを使って、コンテナからのAPIリクエストを簡略化することはいつでもできます。これによって、AWSのベストプラクティスである、AWSの認証情報をコードや設定ファイル内に保存しない、が実現できますし、同時に自動的なキーローテーションといった利点も得ることができます。

最近発表したECSタスクのIAMロールを使うことで、EC2コンテナインスタンスではなくECSタスクに直接IAMロールを紐付けられ、基盤をよりセキュアにすることができます。このやり方であれば、例えばS3にアクセスするためのIAMロールを指定されたタスクと、DynamoDBテーブルにアクセスするためのIAMロールを使っている別のタスクを、同一のEC2インスタンス上で実行することができます。

サービスAuto Scaling

3つ目の強調したい特徴が、サービスのAuto Scalingです。サービスAuto ScalingとAmazon CloudWatchアラームを使うことで、EC2インスタンスを増やしたり減らしたりするのと同じやり方で、ECSサービスをスケールさせるポリシーを定義することができます。サービスAuto Scalingによって、負荷が上がった時にはスケールアウトすることで高い可用性を維持したり、負荷が下がったサービスとクラスタをスケールインすることでコストを最適化することができ、これらは全て自動的かつリアルタイムで起こります。

タスクの希望数、最小数、そして最大数を選び、1つ以上のスケーリングポリシーを作成するだけで、あとはサービスAuto Scalingが処理してくれます。サービススケジューラはアベイラビリティゾーンを意識してくれるので、ECSタスクが複数のゾーンに渡って分散しているかを気にする必要もありません。

今日から利用可能です

これらの特徴は既に利用可能なので、今日から使いはじめることができます!

Jeff;

原文: Powerful AWS Platform Features, Now for Containers (翻訳: SA岩永)

Amazon API Gatewayのための利用プラン

昨年、開発者がモバイル、web、エンタープライズそしてIoTアプリケーション向けバックエンドWebサービスを構築できるようにするため、 Amazon API Gateway を紹介しました( Amazon API Gateway – Build and Run Scalable Application Backend to learn more を参照)。そのときから、AWSの顧客は  AWS LambdaAmazon Elastic Compute Cloud (EC2)、そしてAWSの外で稼働するサーバ上で実行されるAPIの実装を行ってきました。多くの場合、我々の顧客は彼らのAPIの上でアプリケーションを開発するパートナー開発者のエコシステムを作ることを計画しています。API Gateway を利用することで、我々の顧客は彼らの顧客それぞれにAPIキーを作成することが可能です。
これらのキーはAPIの各ユーザを特定し、キーの所有者がアクセス可能なサービスのセットとサービスのステージ(テスト、ベータそして本番といった環境)をAPI開発者がコントロールすることが可能です。APIはしばしばビジネス価値の代わりとして提供されるため、我々の顧客はAPIを構築し、それらへのアクセスを規制し、使用量に基づいて課金することによって、それらを収益化したいと我々に教えてくれました。
新しい利用プラン
このユースケースをサポートするため、API GatewayのUsage Planをご紹介します。この新機能により、開発者はAPIを構築、収益化することと、彼らの周りでエコシステムを作ることが可能になります。異なるレベルのアクセス(Bronze、Silver、Gold)、異なるカテゴリのユーザ(学生、個人、プロフェッショナルもしくはエンタープライズ)などに対して利用プランを作成することができます。プランは名前が付けられ、APIに対するアクセスの以下の面をコントロールします。

  • スロットリング – リクエストレート全体(平均秒間リクエスト)とバーストキャパシティ
  • クオータ – 一日あたり、週あたり、もしくは月あたりに可能なリクエストの数
  • API / ステージ – アクセス可能なAPIとAPIのステージ

仮に利用プランを使うことを選択するならば、あなたのAPIそれぞれがプランと紐付けられなければなりません。幸い、API Gatewayはデフォルトプランを作成し、それらにAPIを紐付けることができます。あなたがやろうとすることを確認するだけです。

デフォルトプランはスロットリングもクオータもありませんし、APIの挙動を変更しません。

利用プランの作成
Let’s step through the process of creating a Usage Plan.  利用プランの作成プロセスを一つずつ見ていきましょう。API Gatewayのコンソールを開き、Usage Plans、に移動しCreateをクリックしてください。 名前、説明を入力し、それからスロットリングとクオータのオプションを必要に応じて設定します。

スロットリングはToken Bucket モデルを使って実装されています。バケットはバースト値により示されるトークン数を保持するのに十分な大きさで、指定レートで新規トークンを取得します。各APIリクエストはバケットから1つのトークンを削除します。Token Bucketを使うことで、時折のバーストに対応するケイパビリティを持った安定したリクエストのストリームをサポートするAPIを持つことが可能になります。 2つの異なる方法でスロットリングを利用したり考えたりできます。ビジネス的な観点からは、それにより各顧客が生成可能なリクエストがどの程度かコントロールするために利用プランを使うことができます。技術的な観点からは、APIとして実装するために使われているサービスを過度なリクエストから遮断することができます。もし、それらのサービスがAWSの外で実装されていて、要求に合うようスケールできないならば、これは特に重要なことです。

Nextをクリックし、そしてそれから利用プランを通じてアクセスされるAPIとAPIステージを選択します。

プラン作成のために Next をクリックし、それからいくつかのAPIキーを追加します。既存のキーを追加する、もしくは新しいものを作成することが可能です。

料金プランを既存のAPIキーにアタッチすることを計画しているならば、キーは同じステージに関連する複数のプランを参照できないので最初にキーからデフォルトプランを削除しなければなりません。2つ目のブラウザタブ内でAPIキーを開き、デフォルトプランの右にある”x”をクリックすることでこれができます。

(プランにキーを追加しているタブ上で)1つもしくは複数のAPIキー(APIのサブスクライバを示す)を選択し、Doneをクリックします。

あなたのユーザ(サブスクライバ)がAPIキーを使ってAPIコールを開始したら間もなく、プランで指定された通りに彼らの利用量はスロットルされ、制限されます。Usageをクリックすることでいつでも彼らの利用量を見ることができます。

クオータはリアルタイムに適用され守られます。利用量のデータは最大30分遅れます。

Export Usage Dataをクリックすることで利用量のデータはダウンロード可能です。

その後、望み通りにデータを処理し、分析することが可能です。例えば、コールごとベースでサブスクライバに請求書発行することが可能です。

サブスクライバの一つがAPIを非常によく利用していて、期間内のクオータに近づきつつある場合、利用プランを変更することなく彼らに利用を増やすことを許可することができます。Extensionをクリックして、期間内の残りを用意するために許可するリクエスト数を入力するだけです。

利用プランを使用する
先だって言及したように、利用量に対する請求書発行やAPIを中心としたエコシステムを作るのに利用プランを使えます。

アクセスをコントロールしたり、監視することができ、必要に応じて選択的に特別なアクセスを個別のサブスクライバに許可することができます。例えば、特定のAPIステージに対するアクセスを許可するAPIキーと利用プランを作成することができます。多くのサブスクライバは本番ステージへのアクセスが必要です。少しのサブスクライバは開発もしくはベータテストのステージへのアクセスが必要です。

まとめの前に、APIキーは識別のためであり、認証のためではないことを指摘しておきます。キーはリクエストの署名のためには使われず、セキュリティ機構として使うべきではありません(これは完全に Cognito Your User Poolsのユースケースです)。

今すぐ利用可能
この機能は今すぐ利用可能で、本日より使う始められます。


Jeff;(翻訳はSA西谷が担当しました。原文:New – Usage Plans for Amazon API Gateway

【新発表】AWS アプリケーションロードバランサー

私たちはElastic Load Balancing (ELB)を2009年にAWSで発表しました(New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatchを見るとこの時からAWSがどれだけ変化してきたかがわかると思います)。Elastic Load BalancingはAWS上で動くアプリケーションのキーコンポーネントとなりました。Auto Scalingとの連携によって、Elastic Load Balancingは高い可用性を保ちながらアプリケーションをスケールアップ・ダウンする仕事を非常に簡単にしてくれました。

レベル

よく知られているOSIモデルでは、ロードバランサーは一般的にレイヤー4 (ネットワーク)かレイヤー7 (アプリケーション)で実行されます。

レイヤー4のロードバランサーはネットワークプロトコルのレベルで動作しネットワークパケットの中身を見ないので、HTTPやHTTPSの機能は無視します。別の言い方をすれば、これは全てを知る必要なく負荷を分散する仕組みになります。

レイヤー7のロードバランサーはより洗練されていて強力です。パケットの中を見て、HTTPとHTTPSのヘッダにアクセスし、(他の情報も合わせて)より賢い方法で負荷をターゲットに分散させることができます。

AWS上のアプリケーションロードバランサー

本日、私たちは新しいアプリケーションロードバランサーをELBの1つとして発表します。これはレイヤー7で実行され、幾つかの先進的な機能をサポートしています。元々のロードバランサー(これからはクラシックロードバランサーと呼ばれます)は引き続き利用可能で、レイヤー4とレイヤー7の両方の機能を提供します。

アプリケーションロードバランサーはコンテントベースのルーティングと、コンテナで実行されるアプリケーションをサポートします。業界標準の2つのプロトコル (WebSocketとHTTP/2)をサポートし、またターゲットのインスタンスやコンテナのヘルス状態の可視化も追加されています。コンテナやEC2インスタンスで動いているウェブサイトやモバイルアプリケーションは、アプリケーションロードバランサーを使うことで利益を得ることができるでしょう。

それでは、これらの機能を一つ一つ見ていって、最後に新しいアプリケーションロードバランサーを自身で作成してみましょう!

コンテントベースのルーティング

アプリケーションロードバランサーはHTTPヘッダーにアクセスし、リクエストを異なるバックエンドにルーティングすることができます。例えば、/apiがURLパスに含まれているリクエストを1つのサーバグループ(これをターゲットグループと呼びます)に送り、/mobileが含まれるリクエストをもう1つのグループに送りたいとします。こういった手法でリクエストをルーティングすることで、複数のマイクロサービスをそれぞれ独立して実行しスケールさせることができます。

この後見ることになりますが、1つのアプリケーションロードバランサーでは、リクエストをターゲットグループへ向けてルーティングするURLベースのルールを10個まで定義することができます。さらにこの先、他のルーティング方式も実装することを計画しています。

コンテナベースアプリケーションのサポート

多くのAWSのお客様がマイクロサービスをコンテナ化し、Amazon EC2 Container Serviceの上で動かしています。これによって1つのEC2インスタンス上で1つ以上のサービスを実行することができますが、古いロードバランサーではポートマッピングやヘルスチェックを注意する必要があるという幾つかの課題が存在しました。

アプリケーションロードバランサーはコンテナベースのアプリケーションを認識しサポートしてくれます。これによって1つのインスタンス上で、複数のポートをlistenしている幾つかのコンテナを同一のターゲットグループの下に紐付けることができ、またより詳細なポートレベルのヘルスチェックを実施できます。

メトリクスの改善

アプリケーションロードバランサーはヘルスチェックをポートベースで実施しレポートします。ヘルスチェックは許容するHTTPのレスポンスのレンジを指定でき、詳細なエラーコードも含まれます。

コンテントベースのルーティングにより、メトリクスをマイクロサービス毎に収集することも可能になりました。これはとても良い副作用であり、各マイクロサービスは自身のターゲットグループを特定のEC2インスタンス群で実行できます。こうした可視化の改善により、各サービスの負荷に応じてスケールアップ・ダウンが可能になりました。

アプリケーションロードバランサーはいくつかの新しいCloudWatchのメトリクスを追加していて、その中には全体のトラフィック(GB単位)、アクティブなコネクション数、また1時間単位のコネクションレートが含まれます。

プロトコルとワークロードの追加サポート

アプリケーションロードバランサーは2つのプロトコルサポートを追加しました: WebSoecketHTTP/2です。

WebSocketはクライアントとサーバの間で、長期間のTCPコネクションを利用可能にしてくれます。これは、HTTP接続を開いたままにして長い間隔の”ハートビート”を利用する様な古い方式の代替として、より効率の良いものとなっています。WebSocketはモバイルデバイスには特に良くて、電源の消費を最小にしながら、株価やスポーツの得点などの動的なデータを配信するのに利用できます。ALBはws://wss://プロトコルを使ってWebSocketをネイティブサポートしています。

HTTP/2はHTTP 1.1プロトコルから多数の改善がされたものになります。この新しいプロトコルは1つのコネクションで上で複数のリクエストをサポートしています。これによって、ネットワークトラフィックを削減し、またプロトコルはバイナリをベースにしています。

アプリケーションロードバランサーはストリーミングやリアルタイム、そしてWebSocketのワークロードを最適化された方式で扱うために設計されています。リクエストとレスポンスをバッファリングせずに、ストリーミングとして扱います。これによって、レイテンシを削減しアプリケーションのパフォーマンスが向上します。

ALBを作成する

では、アプリケーションロードバランサーを作成し、トラフィックを捌ける様にしてみましょう!

Elastic Load Balancingコンソールでは、どちらのタイプのロードバランサーも作成できます:

アプリケーションロードバランサーをクリックし、名前を入力し(MyALB)、インターネット向けを選択します。HTTPSをリスナーとして追加します:

同じ画面で、自分のVPCを選択し(VPCだけの機能なので)、必要なアベイラビリティゾーンのサブネットを選択し、アプリケーションロードバランサーにタグをつけ、セキュリティの設定に進みます:

HTTPSのリスナーを作成したので、このアプリケーションロードバランサーは証明書が必要です。既存のIAMやAWS Certificate Manager (ACM)の証明書を選ぶか、ローカルの証明書をアップロードするか、または新しい証明書をリクエストすることができます:

次に、セキュリティグループを設定します。今回は新しいものを作成することにします。もちろん、既に作成済のVPCやEC2のセキュリティグループを使うこともできます:

次のステップは最初のターゲットグループ(main)を作成し、ヘルスチェックを設定します(デフォルトのままにします):

これでターゲットを選択する準備ができました。ターゲットは、アプリケーションロードバランサーを通ったトラフィックを受けるEC2インスタンス群になります。ここでは、80番ポートをlistenしているターゲットを選択します:

最後のステップでこれまでの選択を確認し、ALBを作成します:

作成をクリックすると、アプリケーションロードバランサーは作成中になり、1分程度でアクティブになります:

追加のターゲットグループを作成できます:

そして、/apiのリクエストをこのターゲットにルーティングする新しいルールを追加できます:

アプリケーションロードバランサーはAuto ScalingAmazon ECSAWS CloudFormationAWS CodeDeploy、そしてAWS Certificate Manager (ACM)といった複数のAWSサービスと連携しています。追加のサービスとの連携についても作業をしているところです。

移行

もし現在クラシックロードバランサーを使っていて、アプリケーションロードバランサーに移行したいという場合、新しいロードバランサーコピーツールを見てみて下さい。このPythonのツールは既存のクラシックロードバランサーと同じ設定でアプリケーションロードバランサーを作成するのを手伝ってくれます。また既存のEC2インスタンスを新しいロードバランサーに登録することもできます。

利用可能リージョンと価格

アプリケーションロードバランサーは全てのAWSコマーシャルリージョン(東京リージョンも含まれます)で今日から使いはじめることができます!

アプリケーションロードバランサーの1時間あたりの利用料金は、クラシックロードバランサーより10%低くなっています。

アプリケーションロードバランサーを使うと、時間単位の課金とLoad Balancer Capacity Units (LCU)の使用量に応じた課金が発生します。LCUは1秒当りの新規コネクション数、アクティブなコネクション数、そしてデータ転送量で計測されます。この3つの指標を計測して、最も高いものを基準に課金されます。1つのLCUは以下のいずれかをサポートできます:

  • 2 KBの証明書の場合: 25 接続/秒、3000アクティブ接続、2.22 Mbpsのデータ転送
  • 4 KBの証明書の場合: 5 接続/秒、3000アクティブ接続、2.22 Mbpsのデータ転送

LCUの利用料は微量で1 LCUに1時間当り$0.008となります。我々の計算では、ほとんどのお客様でクラシックロードバランサーからアプリケーションロードバランサーに切り替えることで、ロードバランサーのトータル費用は実質的に削減されると思います。

Jeff;

原文: New – AWS Application Load Balancer (翻訳: SA岩永)

Amazon Elastic Block Store(EBS)アップデート-スナップショットストレージの値下げとPIOPSボリュームのIOPS/GB比率の改善

Amazon Elastic Block Store(EBS)はEC2インスタンスにアタッチして利用できる、永続化されたブロックレベルストレージです。EBSを利用することで、必要なパフォーマンスを備えたSSDベースのボリュームをプロビジョンし、マネジメントコンソールによる手作業やプログラムによってバックアップとして利用できるスナップショットを作成することが可能になります。

本日、これらの機能に対する改善についてお知らせをいたします。プロビジョンドIOPSボリュームにおけるプロビジョン可能なIOPS値の制限を緩和するとともに、スナップショットストレージの費用を47%削減いたします。この改善により、EBSはこれまでよりもパワフルで経済的なものになるでしょう。

IOPS/GB比率の改善
プロビジョンドIOPSのコンセプトをご紹介したのは2012年のことでした(詳細は過去のポストをご覧ください)。プロビジョンドIOPSボリュームを利用すると、それぞれのEBSボリュームに必要なレベルのパフォーマンスを確保することができます。設定可能なIOPSの値はボリュームのサイズに依存しており、最大20,000IOPSまでの範囲でボリュームが大きくなるほどより高いIOPSを指定することが可能です。

これまでは、1GBあたり最大30IOPSの範囲で指定が可能でした。これからは1GBあたり最大50IOPSまでを指定できるようになります。プロビジョンドIOPSボリューム(io1)は年間を通じて、99.9%に時間に対して指定したIOPS値のプラスマイナス10%の範囲のパフォーマンスを発揮するように設計されています(詳細についてはEBSについてのよくある質問をご覧ください)。

極めて負荷の高い処理を実行するために、小容量で高いIOPSを持つプロビジョンドIOPSボリュームを利用しているケースがあります。本日発表した改善により、こういった小容量で高いIOPSを求めるユースケースにおいて、さらに容量を小さくすることが可能になります。つまり、従来は20,000IOPSを指定するには最低667GBの容量が必要だったものが、本日からは400GBを確保すれば良いということになるのです。

この改善は全ての一般利用可能なAWSリージョンにおいて、新たにボリュームを作成する際に適用されます。

スナップショットストレージの値下げ
また、全てのAWSリージョンにおいてEBSスナップショットの費用を47%値下げいたします。

スナップショットはこれまでよりも経済的になりました。この改善の結果として、より高頻度にバックアップを取ることが可能になり、これによって障害や人為的ミスからのリカバリタイムが短くなることが期待できます。もしEBSボリュームのバックアップを取っていないようでしたら、今が始めるチャンスです!

この値下げは2016年8月1日にさかのぼって自動的に適用されます。また、AWS Storage Gatewayのゲートウェイキャッシュ型ボリュームのスナップショットについても同様に適用されます。

— Jeff;

原文:Amazon Elastic Block Store (EBS) Update – Snapshot Price Reduction & More PIOPS/GiB(翻訳:SA小林)

サービス開始 – Amazon S3 が IPv6 をサポート

ご存知かもしれませんが、インターネットに接続されたすべてのサーバーとデバイスには独自の IP アドレスが必要です。遡ること 1981 年、RFC 791 (“インターネットプロトコル”) により IP アドレスとは 32 ビットのエンティティで、かつ組織の異なる IP アドレスの必要数に対応するよう設計された 3 つの異なるネットワークとサブネットサイズ (クラス A、B、C – 基本的に大中小のサイズ) を有するものと定義されました。やがてこの形式は無駄が多いとみなされるようになり、より柔軟な CIDR (Classless Inter-Domain Routing) 形式が標準化され使用されました。32 ビットエンティティ (一般に IPv4 アドレスとして知られる) はよく用いられてきましたが、インターネットの継続的な成長により、最終的には利用可能なすべての IPv4 アドレスが割り当てられ使用されてしまうでしょう。

この成長に対応し今後の展開に道を開くよう、ネットワーク、デバイス、サービスプロバイダーは IPv6 へと移行中です。128 ビット/IP アドレスの IPv6 にはたっぷりのアドレス空間 (単純計算すると 128 ビットには 35 億個の IP アドレスを 10 穣個 (1 穣は 10 の 27 乗)、つまり宇宙の星の数ほどの人数に割り当てられるのに十分な数) があります。膨大なアドレス空間が IPv6 の明白なメリットである一方、そのほかにより繊細なメリットもあります。これには拡張性、動的アドレスの割り当てに関するより良いサポート、および追加のセキュリティの組み込みサポートが含まれます。

本日、Amazon S3 バケットのオブジェクトが IPv6 アドレス経由、新しい「デュアルスタック」エンドポイント経由でアクセスできるようになったことを発表します。DNS ルックアップがこの型のエンドポイントで実行される場合、IPv4 アドレスでは “A” レコードが返されますが、IPv6 アドレスでは “AAAA” レコードが返されます。ほとんどの場合、顧客環境のネットワークスタックでは自動的に AAAA レコードを優先し IPv6 アドレスを使用して接続します。

IPv6 経由で S3 コンテンツにアクセスする
IPv6 経由でコンテンツにアクセスを開始するには、次のような新しいデュアルスタックエンドポイントに切り替える必要があります:

http://BUCKET.s3.dualstack.REGION.amazonaws.com

または:

http://s3.dualstack.REGION.amazonaws.com/BUCKET

AWS Command Line Interface (CLI) または AWS Tools for Windows PowerShell をお使いなら、 --enabledualstack フラグを使用してデュアルスタックエンドポイントに切り替えます。現在 AWS SDKs を更新しており、 use_dualstack_endpoint の設定の使用をサポートし、来週半ばまでには本番環境に展開することを見込んでいます。それまで SDK の開発者ガイドを参照してこの機能を有効化する方法をご覧になってください。

知っておいていただきたい事項
IPv6 にスムーズに移行する上で知っておいて頂きたい事項がいくつかあります:

バケットと IAM ポリシー – IP アドレス経由でのアクセスを許可または制限するポリシーをご利用の場合、新しいエンドポイントに切り替える前に希望する IPv6 範囲が含まれるよう更新してください。そうしないとクライアントは AWS リソースへのアクセスを間違って取得、または喪失するかもしれません。対応する IPv6 アドレスを追加し、特定の IPv4 アドレスからのアクセスを除外するすべてのポリシーを更新します。IPv6 接続性 – ネットワークスタックは IPv4 アドレスより IPv6 アドレスを選択する傾向があるため、特定の状況下では異常事態が生じ得ます。クライアントシステムが IPv6 用に設定されても、IPv6 パケットをインターネットにルーティングするよう設定されていないネットワークに接続されるかもしれません。それでデュアルスタックエンドポイントに切り替える前に、必ずエンドツーエンド接続のテストをしてください。ログエントリ – ログエントリには必要に応じて IPv4 または IPv6 アドレスが含められます。内部アプリケーションまたはサードパーティアプリケーションを使用するログファイルを分析する場合、IPv6 アドレスを含むエントリを認識し処理できることを確認します。S3 機能サポート – IPv6 サポートはウェブサイトホスティング、S3 Transfer Acceleration、BitTorrent 経由のアクセスを除き、すべての S3 機能で利用可能です。リージョンサポート – IPv6 サポートはすべてのコマーシャル AWS リージョンと AWS GovCloud (US) で利用できます。China (Beijing) リージョンではご利用になれません。

Jeff

AWS ソリューション – Transit VPC

今日は新しい AWS ソリューションをご紹介します。とても興味深い機能です。AWS クイックスタートと同様に、これは AWS ソリューションアーキテクトがセキュリティと可用性のベストプラクティスを取り入れて構築した機能です。この新しい Transit VPC Solution は transit VPC と呼ばれる実に便利なネットワーク構築の実装方法を示します。この機能を使用して地理的に離れていたり、別々の AWS アカウントで実行している仮想プライベートクラウド (VPC) をグローバルネットワーク転送センターとして機能する一般的な VPC と接続することができます。このネットワークトポロジーはネットワーク管理を簡略化し、設定と管理を必要とする接続の数を減少することができます。さらに実装は仮想的に行うようになっているので、物理的なネットワーク機器は不要、コロケーション転送ハブの目の前にいる必要もありません。次の例をご覧ください。

この図では、transit VPC が中央にあり、その周囲に「スポーク型」の VPC と、企業データセンター、その他のネットワークが配置されています。transit VPC は複数の重要なユースケースをサポートします。

  • プライベートネットワーキング – 2 つ以上の AWS リージョンに渡るプライベートネットワークを構築できます。
  • 共有接続 – 複数の VPC はデータセンター、パートナーネットワーク、その他のクラウドと接続を共有できます。
  • クロスアカウント AWS の使用量 – VPC と AWS のリソースを複数の AWS アカウントに収めることができます。

ソリューションは AWS CloudFormation スタックを使用し、すべての AWS リソースを起動し構成します。500 Mbps から 2 Gbps のスループットオプション 3 つを提供します。それぞれ可用性を実現する接続ペアで実装されます。このスタックが使用する Cisco Cloud Services Router(CSR) が AWS Marketplace で入手可能になりました。既存の CSR ライセンス (BYOL モデル) を使用するか、CSR の使用量を時間単位で支払うことができます。transit VPC の実行に掛かる費用は、お客様がお選びになったスループットオプションとライセンスモデルによります。料金は 1 時間あたり 0.21 USD から 8.40 USD、プラス各スポーク VPC 1 時間あたり 0.10 USD の追加料金 (AWS リソース用) が適用されます。ソリューション特有のお客様専用 AWS Key Management Service (KMS) マスターキーに月額 1 USD の追加料金が適用されます。これらの料金はすべてネットワーク転送の料金には含まれません。テンプレートはクリエイティブに AWS Lambda 関数のペアをインストールしたり使用します。VGW Poller 関数は毎分実行されます。アカウントですべての AWS リージョンをスキャンし、VPN 接続がないスポーク VPC で適切にタグした仮想プライベートゲートウェイを探します。それが見つかると (必要に応じて) 対応するカスタマーゲートウェイと CSR への VPN 接続を作成し、S3 バケットにその情報を保存します。バケットの Put イベントが Cisco Configurator 機能をトリガーします。VPN 接続の情報を解析し必要な設定ファイルを生成したら SSH を使用して CSR にプッシュします。これにより VPN トンネルが現れ (BGP の作用を含む)、スポーク VPC で近隣の関係を確立します。この方法で Lambda を使用すると、活用されていない EC2 インスタンスを実行する必要なく、新しいスポーク VPC を素早くオンラインにさせることが可能になります。ソリューションの実装ガイドには、いつものように詳しい手順とセキュリティアドバイスが記載されています。

Jeff

PS – 一般的なネットワーク問題についてはネットワークのベストプラクティスガイダンスをご覧ください。

Amazon Kinesis Analytics - SQL を使用してリアルタイムにストリーミングデータを処理

ご存知の通り、Amazon Kinesis では、AWS Cloud でリアルタイムにストリーミングデータを操作するプロセスが大幅に簡素化されています。独自のプロセスおよび短期のストレージインフラストラクチャを設定および実行する代わりに、ただ Kinesis ストリームまたは Kinesis Firehose を作成し、そこにデータを流し込むように設定してから、それを処理または分析するアプリケーションを構築するのみです。Kinesis ストリームと Kinesis Firehose を使用してストリーミングデータソリューションを構築するのは比較的簡単なのですが、さらに簡素化したいと考えました。作業開発者、データサイエンティスト、または SQL 開発者であるかどうかにかかわらず、お客様がウェブアプリケーション、テレメトリ、およびセンサーレポートの大量のクリックストリームを、接続されたデバイス、サーバーログなどからすべてリアルタイムに標準クエリ言語を使用して処理できるようにしたいと考えました。

Amazon Kinesis Analytics
本日より、Amazon Kinesis Analytics がご利用いただけるようになりました。ストリーミングデータに対して SQL クエリを継続的に実行し、データが届くと同時にフィルタリング、変換、および集約できるようになりました。インフラストラクチャで時間を無駄にするのではなく、データの処理とそこからのビジネス価値の抽出に注力できます。強力なエンドツーエンドのストリームプロセスパイプラインを 5 分で構築できます。SQL クエリより複雑なものを作成する必要はありません。
データベーステーブルに対する一連の SQL クエリの実行を考慮する場合、クエリは通常、非常に素早く追加および削除されるのに対して、データはほぼ静的なままです。常に行が追加、変更および削除されますが、これは特定の時点で実行する単一のクエリを考慮する際、一般的には関係ありません。Kinesis Analytics のクエリをストリーミングデータに対して実行すると、このモデルと正反対のことが生じます。クエリは長時間実行され、新しいレコード、監視、またはログエントリが届くと同時に、データは毎秒何度も変化します。一度この仕組みを把握すると、クエリプロセスモデルが非常に理解しやすいことが分かります。レコードが届くと同時に処理する、持続的なクエリを構築するのです。所定のクエリで処理されるレコードのセットを制御するには、プロセス「ウィンドウ」を使用します。Kinesis Analytics では、3 つの異なるタイプのウィンドウがサポートされています。

タンブリングウィンドウは定期的なレポートに使用されます。タンブリングウィンドウを使用して、時間の経過と共にデータをまとめることができます。おそらく毎秒数千~数百万ものリクエストを受信するので、1 分ごとの受信数を知りたいと思うでしょう。現在のタンブリングウィンドウが閉じると、その後に次のウィンドウが開始します。ウィンドウがいっぱいになるたびに、新しい結果が生成されます。

スライディングウィンドウは、モニタリングとその他のタイプのトレンド検出に使用されます。例えば、スライディングウィンドウを使用してリアルタイムで動くエラー率の平均をコンピューティングできます。レコードがウィンドウに入り、レコードがその中にあるかぎり結果に反映され、ウィンドウは進行します。新しいレコードがウィンドウに入るたびに、新しい結果が生成されます。ウィンドウのサイズを調整して、結果の精度を制御できます。

カスタムウィンドウは、適切なグループが厳密に時間に基づいていない場合に使用されます。クリックストリームデータまたはサーバーログを処理している場合、カスタムウィンドウを使用してセッション化として知られるアクションを実行できます。つまり、各ユーザーが実行する最初と最後のアクション (受信データ内のセッション ID により識別される) によって、各クエリをバインドできます。各ユーザーが閲覧したページ数またはサイトで費やした時間をコンピューティングするクエリを作成できます。

これらすべてはいくらか複雑に聞こえるかもしれませんが、実装するのは非常に簡単です。Kinesis Analytics では、受信レコードのサンプルを分析し、最適なスキーマを提案します。それをそのまま使用することも、微調整して実際のデータモデルをさらに反映することもできます。スキーマが定義されると、組み込み SQL エディターを使用できます (ライブデータに対する構文チェックと簡単なテストを含む)。クエリの結果を Amazon S3Amazon RedshiftAmazon Elasticsearch Service、または Amazon Kinesis Stream を含む最大 4 つの送信先にルーティングするように、Kinesis Analytics を設定できます。初めての Amazon Kinesis Analytics アプリケーションを構築する場合、SQL ステートメントのペアを作成する必要があります (より複雑なアプリケーションには多くを使用する場合がありますが、必要なのは起動と実行の 2 つのみです)。

これは、中間 SQL 結果を保存するアプリケーション内のストリームを作成するためのステートメントです (ストリームは、選択および挿入でき、継続的にアップデートされる SQL テーブルのようなものです)。

1 つのアプリケーション内のストリームから SQL クエリを選択し、別のアプリケーション内のストリームに挿入します。

また、S3 を送信元とするデータを参照するよう、SQL ステートメントもレコードに追加できます。これはレコードを強化または変更し、追加のさらに詳細な情報を含める時に役立ちます。

動作中の Amazon Kinesis Analytics
動作中の Amazon Kinesis Analytics を数分見てみましょう。
Amazon Kinesis Analytics コンソールにログインし、Create new application をクリックします。名前とアプリケーションの説明を記入します。

データソース、クエリ、および送信先を管理できるようになりました。

既存の入力ストリームの 1 つを選択できます。

または、新しいストリームを設定できます (こちらを実行します)。

Create demo stream をクリックし、サンプルの株式相場表示機のデータが入力されるストリームを作成します。これには 30~40 秒かかります。Kinesis Analytics はストリームを参照し、スキーマを提案します。それをそのまま承認することも、微調整することもできます。

それから SQL エディターに移動します。アプリケーションの起動を提案しています。良いアイデアだと思うので、同意して Yes をクリックし、アプリケーションを起動します。

これが実際の SQL エディターです。

クエリをゼロから作成することも、テンプレートを使用することもできます。

継続的なフィルターを選びました。これが SQL です。

確認し、アグリーメントを承認し、Save and run SQL をクリックしました。数秒以内に結果が流れ始め、コンソールに表示されました。

SQL エディターを使用して、部門料金列を削除するようクエリを変更し、クエリを再度実行しました。この作業を行ってみて、CREATE STREAM ステートメントから列を削除する必要があることを学びました (振り返ってみると明白なのですが、これは長い 1 日の最後の作業でした)。こちらが修正した結果セットです。

ほとんどの場合、次のステップでは結果を新規または既存のストリームにルーティングすることになるでしょう。これはコンソールから実行できます。

数回のクリックとほんの少しの入力のみで、本番環境規模の株式相場表示機のストリームを処理できる Amazon Kinesis Analytics アプリケーションを作成できました。本番環境で使用される前に、この「デモ」には何の変更も必要ありません。素晴らしいです。

詳細 & お試し
いつものように、このすばらしい新サービスについては、やっと分かり始めたばかりです。詳細については、新しい投稿をご覧ください。Writing SQL on Streaming Data with Amazon Kinesis Analytics上記のステップは 5 分またはそれ以下で再現できるはずです。ぜひお試しされるようにお勧めします。アプリケーションを作成し、SQL クエリをカスタマイズし、大規模なストリーミングデータの処理方法を学んでください。

今すぐご利用可能
今すぐ Amazon Kinesis Analytics をご利用いただけます。今日からストリーミングデータに対してクエリの実行を開始できます。

Jeff

サーバーレスでChatbot コンテスト開催

AWS Serverless Chatbot コンテストの審査員にならないかとのオファーが来たので、喜んで引き受けることにしました。

Chatbot の構築
AWS LambdaAmazon API Gateway を使用して Slack 用の chatbot を構築してください。他の API (Slack Events API が便利) や追加サービス (AWS その他)、その他のデータソースも使用することができます。コンテストの参加作品はクリエイティブかつオリジナルであり、Stack ユーザーに本当の価値を提供できるものでなければなりません。AWS Free Tier は Lambda、API Gateway、そしてその他の AWS サービスへのアクセスを無料でご提供します。AWS の新規および既存のユーザーは Lambda リクエスト 100 万件、そして 400,000 GB/秒のコンピューティング時間を無料で利用することができます。AWS の新しいユーザーはサインアップしてから 12 か月間、API Gateway への API コールを毎月 100 万件ご利用いただけます。

コンテスト参加作品
Chatbot が完成したら、パッケージやマーケティングにも力を注ぐことをおすすめします。参加作品の一環として次のアイテムを提供することも忘れないでください。

  • Chatbot を実際に使用した様子を示すビデオ資料
  • 参加作品の機能やユニークな点に関する概要
  • パブリックまたはプライベート GitHub リポジトリのリンク (chatbot を実行するために必要なファイルすべてを含む)
  • chatbot のテスト手順と使用手順

コンテストの参加作品となる chatbot は新規または既存のアプリケーションどちらでも構いませんが、必ず Lambda と API Gateway を使用してください。コードはビデオで見せたように動作しなければなりません。提出物は必ず英語で作成してください。また、参加作品は同じ提出者、チーム、組織が提出したその他のアプリと大きく異なるものでなければなりません。

賞品
個人、チーム、社員数 50 人以下の組織が Serverless Chatbot Hero 賞に参加することができます。この賞には AWS re:Invent のチケット 1 枚、ホテルの割引、Serverless State of the Union スピーチで名前が挙がること、そして素敵なプレゼント、AWS クレジット 100 USD、さらに参加作品のボットを宣伝するチャンスなどが含まれます。このコンテストでは 8 つの賞を設ける予定です。大規模な組織は賞金なし、評価のみの賞に参加することができます。ルールと資格基準の詳細は FAQ をご覧ください。

スケジュール
コンテストのスケジュールは次のとおりです。

  • 2016 年 8 月 10 日 – 9 月 29 日 – 提出期間
  • 10 月 3 日 – 10 月 7 日 – AWS 審査員による決定期間
  • 10 月 15 日 – 受賞者の発表

 

今すぐ開始
コンテスト参加の手順を簡単にご説明します。

  1. ルールと資格基準のガイドラインをお読みください。
  2. AWS Serverless Chatbot コンテストに登録します。
  3. AWSSlack 開発者用のアカウントを作成します。
  4. リソースページにアクセスし、API とサービスの詳細をご覧ください。
  5. お客様の参加作品となる chatbot を構築してください。サンプルコード aws-serverless-chatbot-sample から始めることをおすすめします。
  6. 提出用のビデオ資料とその他の資料を作成してください。
  7. 2016 年 9 月 29 日の午後 5 時 (東部標準時) までに提出してください。

皆さんの参加作品をお待ちしています。

便利なオンラインセミナー
コンテスト参加に役立つ、今後開催予定のオンラインセミナーをご紹介します。

過去に開催したオンラインセミナーもご活用ください。

Jeff

Amazon CloudFront をカナダで展開

主にお客様からのご要望に基づき実現した多数の機能を備える Amazon CloudFront は、世界中のお客様に静的、動的、そしてインタラクティブなコンテンツを高速かつ低レイテンシーで提供する場合に最適です。AWS 無料利用枠の一環として、HTTP や HTTPS のリクエスト 200 万件までを処理するほか、追加料金なしに毎月 50 GB までのデータを転送することができます。

そしてこの度、カナダのトロントおよびモントリオールにも CloudFront エッジロケーションを追加いたしました。同地域のお客様に今まで以上に優れたサポートをご提供、そして全世界に渡るロケーション数は 59 か所になりました (詳細は全リストをご覧ください)。これには先日オンラインになったブラジルで 2 番目のエッジロケーション、サンパウロも含まれています。トロントおよびモントリオールのロケーション価格は、米国のエッジロケーションと同様です (詳しくは CloudFront の料金表をご覧ください)。カナダのエッジロケーションは価格クラス 100 になります。

アプリケーションがすでに CloudFront を使用している場合は、新しいロケーションを活用するために特別な操作を行う必要はありません。ロケーションにかかわらず、ユーザーは静的、動的、ストリーミングしたコンテンツへのアクセスを高速かつ低レイテンシーでお楽しみいただけます。

また、開発者の方は CloudFront の使いやすさとコスト効率の良さを実感いただけるでしょう。柔軟性を備えているため、予測が困難なトラフィック負荷を処理する場合でも過剰にプロビジョニングする必要がありません。次の新しい 3 つのロケーションでも今後 Amazon Route 53 をサポートしていく予定です。新しいロケーションを活用するために特別な操作を行う必要はありません。

Jeff

 

AWS IoT のジャストインタイム登録をリリース

去年 12 月、re:Invent (概要は AWS IoT – Cloud Services for Connected Devices をご覧ください) にて、 AWS IoT一般公開しました。
そして今年の始めには、私の同僚 Olawale OladehinUse Your Own Certificate with AWS IoT という記事で、自分の証明書を AWS IoT で使用する方法をご紹介しました。また、それ以前にも John RenshawPredictive Maintenance with AWS IoT and Amazon Machine Learning という記事で、AWS IoT の予測メンテナンスと Amazon Machine Learning について解説しています。

ジャストインタイム方式で登録
AWS IoT の柔軟性をさらに高めるため、本日よりデバイス証明書でジャストインタイム方式による登録が可能になりました。これにより Olawale が解説していた機能の拡張が実現し、何百万とある接続済みのデバイスを活用するシステム構築のプロセスを簡素化できるようになりました。証明書や関連デバイスをトラックするために別のデータベースを構築する必要がなく、デバイスと AWS IoT 間における初回通信時の一部として、新しい証明書を自動登録するように設定することが可能になりました。これを活用するには、まず各デバイスの証明書に署名する際に使用する認証機関 (CA) から始めます (これはデジタル証明書の使用において基本的なトラストチェーン型の良い例です)。この新機能を使い始めることは簡単ですが、その際はいくつかの重要な詳細事項に留意し、実行してください。主な手順は以下のとおりです。

  1. 他の証明書を署名する CA の証明書を登録しアクティベートします。
  2. その証明書を使用して各デバイスの証明書を生成し署名します。
  3. AWS IoT の証明書に対するデバイスを用意しアクティベートします。

AWS Lambda 関数を使用して最後の手順を実行することができます。この関数は AWS IoT Rule Engine Action を使用し、指定した MQTT トピックでリッスンします。新しい証明書が AWS IoT に渡されるたびに、そのトピックに通知が送信されます。その後、この関数がデバイスの証明書をアクティベートし、お客様のアプリケーションが必要とするその他の初期化もしくは登録に対処できるようになります。

詳細
この重要な新機能の詳細および必要な手順詳細を確認するには The Internet of Things on AWS BlogJust in Time Registration of Device Certificates on AWS IoT をご覧ください。

Jeff