Author: AWS Japan Staff


AWS OpsWorksが9つのリージョンエンドポイントとアジアパシフィック(ソウル)リージョンをサポート

AWS OpsWorksはアジアパシフィック(ソウル)リージョンで利用可能になりました。さらに、次の新しいリージョンエンドポイント:EU(フランクフルト)、EU(アイルランド)、US West(北カリフォルニア)、南アメリカ(サンパウロ)、アジアパシフィック(ソウル)、アジアパシフィック(シンガポール)、そしてアジアパシフィック(東京)で利用可能になりました。

以前は、これらのリージョンにあるOpsWorksのリソースにアクセスするためには US East(バージニア北部)のエンドポイントを使う必要がありました。今回の発表により、スタックと同じリージョンにあるエンドポイントを利用可能になりました。これによりAPIの遅延を減らし、レスポンスタイムの改善、そしてクロスリージョンに依存した障害のインパクトを限定することが可能です。

リージョンエンドポイントのリストの詳細はAWSリージョンとエンドポイントをご覧ください。
OpsWorksの詳細:
製品ページ
ドキュメント

舟崎が翻訳しました。原文はこちらです。

新発表 – AWS Key Management ServiceでのBring Your Own Keys機能

AWS Key Management Service (KMS) は暗号鍵のシームレスな中央集中管理を提供します。私達のお客様は、鍵管理インフラストラクチャ(KMI)に関する、可用性、スケーラビリティ、物理的なセキュリティ、ハードウェアメンテナンスを自動的にハンドルするこのフルマネージドなサービスをとても気に入っています。また、KMSは、作成、ローテーション、ライフサイクル管理機能を持つ一つのダッシュボードで鍵管理を集中化します。初期費用無し、カスタマーマスターキー(CMK)1つ当たり月額$1の利用価格をベースとして、KMSは、S3, EBS, RDS, Redshift, およびその他のKMSとインテグレートされたAWSサービス内に保管されたデータを容易に暗号化することが出来ます。

多くのAWSのお客様は、鍵を作成して管理するのにKMSを利用しています。しかしながら、KMSが提供するその他の機能を活用しながら、鍵に対するローカルコントロールを維持したいというお客様がいらっしゃいます。お客様は私たちに、世代や鍵の保管場所に関するローカルコントロールは、よりセンシティブなワークロードをクラウドで稼働させるためのセキュリティとコンプライアンス要求を満たすのに役立つと仰っています。

Bring Your Own Keys 
このような重要なユースケースをサポートするために、本日、KMSにユーザー独自の鍵を持ち込むことが可能になったことを発表できることを嬉しく思います。この機能により、極めてセンシティブなワークロードが保護でき、AWSの外に鍵のセキュアなコピーを保持することが可能になります。この新しい機能により、RSA PKCS #1標準をサポートする全ての鍵管理およびHSM(Hardware Security Module)ソリューションからの鍵のインポートが可能になり、その鍵をAWSサービスおよびアプリケーションから利用することが可能になります。また、KMSは詳細な監査情報を提供するためにAWS CloudTrailと協調して動きます。全てをまとめると、高可用性を提供するためにAWSを利用すれば、鍵のライフサイクルと耐久性に強大なコントロールを得ることができます。今日のほとんどの鍵管理ソリューションはHSMをバックエンドに使っていますが、全てのHSMが鍵管理ソリューションを提供するわけでは有りません。

インポートプロセスは、AWSマネージメントコンソールを使う,  AWS CLIを使う,  あるいは KMS APIをコールすることによって開始できます。オープンな環境に秘密鍵を転送させないために、インポートプロセスでは、アカウントにユニークな、KMSによって提供される公開鍵を使って、事前にユーザーのKMIの鍵をラップすることが求められます。鍵をラップするために、PKCS #1 スキームを利用することができます。

私は、Importing Key Material in AWS Key Management Serviceの指示に従って、KMSコンソールでCreate keyをクリックすることから始めます:


エイリアスと説明を入力し、外部(External)を選択し、“I understand…”チェックボックスにチェックを付けました:


それから、鍵管理のためのKMS APIを許可するIAMユーザーのセットを選びます。(このステップは、次に行うようにKMSおよび外部キーの両方に適用されます。):


次に、鍵を使ってデータの暗号化/復号化ができるIAMユーザーのセットを選択します:


キーポリシーを確認し、ラッピングキーとインポートトークンをダウンロードしました。ラッピングキーは、私がKMSにインポートして使おうとしている256bitの秘密鍵を暗号化するのに利用する2048bitのRSA公開鍵です。インポートトークンは、私の鍵をKMSに正しくインポートさせるためのメタデータを含んでいます。


ZIPファイルを展開し、ラッピングキーを私のEC2インスタンス上のディレクトリ上に配置しました。それから、opensslコマンドを2度使いました:一度目は秘密鍵を生成するためで、2度目はその秘密鍵をラッピングキーでラップするためです。インポートする256bit鍵を生成するためにopensslを便利な方法で利用している事に注目してください。本番データ用としては、鍵の生成と保管にもっとセキュアな方法(商用の鍵管理やHSMソリューションが望ましい)を利用すべきです。

$ openssl rand -out plain_text_aes_key.bin 32
$ openssl rsautl -encrypt -in plain_text_aes_key.bin -oaep \
-inkey wrappingKey_fcb572d3-6680-449c-91ab-ac3a5c07dc09_0804104355 \
-pubin -keyform DER -out enc.aes.key

最後に、“I am ready to upload…”をチェックしてNextをクリックし、鍵の有効期限と共に鍵マテリアルを指定して、全ての情報が集まります。有効期限を過ぎた後はAWSから利用できなくなるので、要件がはっきりするまで有効期限無しのオプションを選択したいと考えるかもしれません。いつでも同じ鍵を再インポートして、有効期限を後からリセットすることができます。


Finishをクリックして、鍵が有効化され利用できるようになりました:

これが私がやらなければいけなかったことの全てです!

私は鍵の有効期限を設定したので、KMSは自動的に鍵の有効期限までの残り時間を追跡するためのCloudWatchメトリックを生成しました。このメトリックに対して、有効期限に近づいた時に鍵を再インポートするためのリマインダーとしてCloudWatchアラームを作成することが可能です。鍵が有効期限切れになったら、CloudWatchイベントが生成されます。これを利用してプログラマティックにアクションを取る事もできます。

Available Now

この新しい機能は、AWS GovCloud (US)および、中国(Beijing)を除く全てのコマーシャルAWSリ―ジョンでご利用可能です。本日から使いはじめることが出来ます。

Jeff;(翻訳はSA布目が担当しました。原文はこちら)

AWS Snowball アップデート – ジョブ管理API & S3 アダプタ

AWSは昨年秋のre:inventから、AWS Import/Export Snowballを導入しました。
Snowballアプライアンスは1度で、あるいは繰り返し大量のデータをAWSへ持ち込み/持ち出ししたいお客様のためにデザインされています。(詳細はAWS Import/Export Snowball – Amazon所有のストレージアプライアンスを利用して1週間あたり1ペタバイトのデータ転送を実現をご参照下さい。)
本日、Snowballに対する2つの重要な追加機能を発表します。以下がその内容です:

  • Snowball ジョブ管理API – Snowballジョブを作成し、管理するアプリケーション構築が可能な新しいSnowball API
  • S3 アダプタ – SnowballアプライアンスがまるでS3エンドポイントであるかのようにアクセスするための新しいSnowball S3アダプタ

もう少し詳細を見てみましょう。

Snowballジョブ管理API
従来Snowballのモデルは、インタラクティブでコンソールから操作するものでした。(基本的に、”Snowballを私に送ってください”という)ジョブを作成し、その後その進捗をモニタリングし、出荷、配送状況、着荷およびAWSへの返却を視覚的に追跡できました。これは、素晴らしいワンオフジョブでしたが、Snowballを既存のバックアップやデータ転送モデルと統合したいと考えるお客様のニーズに合うものではありませんでした。これらのお客様や ストレージパートナー様から頂いたリクエストに基づいて、本日、Snowballジョブ管理APIを導入しました。

Snowball ジョブ管理 APIによって、お客様とパートナー様は、Snowballを自身のデータ管理ソリューションの一部として統合することが可能になります。以下が主要なファンクションです:

  • CreateJob – インポート/エクスポートのジョブを作成し、アプライアンスの出荷を開始します
  • ListJobs – ジョブのリストとステータスを取得します
  • DescribeJob – 特定のジョブについての情報を取得します

より詳細については API リファレンス を参照してください!

この新しいAPIを利用したクリエイティブでイノベーティブなアプリケーションが出てくるのを楽しみにしています!思いついたことがあれば、コメントに残してください!

 

S3 アダプタ
新しいSnowball S3 アダプタによって、まるでAmazon S3 エンドポイントがオンプレミスで稼働しているかのようにSnowballにアクセスすることが出来ます。これによって、Snowballへのデータの出し入れに今お使いのS3セントリックなツールをご利用いただけます。アダプタは、複数のLinuxディストリビューション及びWindowsリリースで利用可能であり、簡単にインストールできます:

  1. Snowball Toolsページから適切なファイルをダウンロードしてローカルディレクトリに展開する
  2. アダプタの構成が適切かどうかを確認する(アダプタはデフォルトで8080ポートをリッスンします)
  3. Snowballをネットワークに接続しそのIPアドレスをビルトインディスプレイから取得する
  4. コンソールを開いてアンロックコードとジョブマニフェストを取得する
  5. IPアドレス、アンロックコード、マニフェストファイルを指定してアダプタを起動する

アダプタが起動すれば、ローカルエンドポイント(オンプレミスホストのIPアドレスとリスナーポート)を使うよう構成するだけでご自身のS3セントリックツールが利用できます . 例えば、こちらが s3 ls コマンドをオンプレミスホストで実行する方法です:

$ aws s3 ls --endpoint http://localhost:8080

Snowballにファイルをコピーした後に、期待したファイル数がコピーされたかどうかを簡単に検証することが出来ます。:

$ snowball validate

アダプタの最初のリリースは、バケットおよびサービスに対するGET、バケットとオブジェクトに対するHEAD、オブジェクトに対するPUTおよびDELETE、そしてすべてのマルチパートアップロードオペレーションを含む、S3 APIのサブセットをサポートします。ご自身のコードやサードパーティのツールを利用してアダプタにアクセスしようと思われている方は、テストを実施することをお勧め致します。

より詳細については、 Snowball Transfer Adapterを参照ください。

今利用できます!
これらの新しい機能は、今ご利用可能ですので本日から使いはじめることができます!

Jeff;(翻訳はSA布目が担当しました。原文はこちら)

強力な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