Author: AWS Japan Staff

以前より、AWS の多くのお客様からプログラムを使用してコストや使用状況レポートを分析する方法をリクエスト頂いていました (詳しくは New – AWS Cost and Usage Reports for Comprehensive and Customizable Reporting をご覧ください)。リクエストをお寄せくださったお客様は、いくつものリージョンにわたり AWS を使用して複数のビジネスを行い、幅広く様々なサービスをご利用されている傾向があります。AWS では請求レポートやコストに関する詳細情報をご提供しているため、これはビッグデータに関与する問題であり、AWS サービスを使用すれば簡単に解決することができます。今月初旬に私が休暇を取っていた間に、AWS はコストや使用状況レポートを や Amazon QuickSight にアップロードできる新機能をリリースしました。今回はその新機能についてご説明します。 Redshift にアップロード まず、新しい Redshift クラスターを作成してみました (すでに実行しているクラスターがある場合は新たに作成する必要はありません)。私が作成したクラスターは次の通りです。 次に請求レポート機能が有効になっていることを確認しました。 そしてコストと請求レポートに行き、Create report をクリックしました。 次にレポート名を指定 (MyReportRedshift) し、時間制に設定してから Redshift と QuickSight 両方のサポートを有効にしました。 最後に配信オプションを選択しました。 次のページでレポートを作成することを確認し、Review and Complete をクリックしました。レポートが作成され、最初のレポートは 24 時間以内にバケットに届くという通知が届きました。 待機している間に PostgreSQL を EC2 インスタンス (sudo yum […]

AWS では毎日なにかしら興味深いことが起きていることに私が気付いたのは 2012 年のことでした。市販用にパッケージされたソフトウェアの流通が一般的だったその当時、クラウドは着実にそして継続的に、その開発を進行させていました。このブログをご覧の皆さんに、すべてのアクティビティをご説明するため、そして AWS が開発するイノベーションのペースについて分かりやすく解説するために、2012 年の春、初の AWS ウィークリーレビューを公開しました。初回、ブログをまとめフォーマットを作り投稿するまでのプロセスに掛かった時間は約 5 分ほどでした。公開後、読者の皆さんから素晴らしいフィードバックをお寄せ頂き、その後 4 年間に渡り毎週新しいブログを投稿してきました。そして時間が経つに連れて AWS はもちろん、次第に規模が大きくなっていった AWS ファンのコミュニティ、開発者、パートナーからのコンテンツによる内容も増えていきました。しかし残念なことに、ウィークリーレビューを公開していくために情報を探し保存そしてリンクをフィルターして投稿という流れに大きく時間を取られるようになっていきました。今年の始めに公開した 4 月 25 日付けのウィークリーレビューを書き上げるには 4 時間も時間を費やすことになり、残念ながらウィークリーレビューの投稿は、その週をもって中止することに決定しました。その後、読者の皆様から何件ものメールやツイートを頂き、よりオープンでスケーラブルな新しいモデルを使用したレビュー再開の可能性について検討することにしました。 協力者の幅を拡大 そしてこの度、AWS ウィークリーレビューが GitHub プロジェクトとして復活することになりました (https://github.com/aws/aws-week-in-review)。これに伴い寄稿者のお誘い (AWS ファン、ユーザー、ブロガー、パートナー) をスタートします。流れとしては、毎週月曜日の朝、私が前週のプルリクエストをレビューしてから承認、その週のウィクーリーレビューを午前 10 時 (太平洋標準時) までに公開します。投稿内容の目的と質を維持するため、スタイルやコンテンツがガイドラインに適しているプルリクエストを私が承認します。その時点で私が次週のファイルも作成するので、ご自分に関係性のある新しいコンテンツを検索し表示することができます。 コンテンツとスタイルのガイドライン 寄稿者に該当するガイドラインは次の通りです。 関連性 – 寄稿する内容はすべて AWS に直接関連していること。 所有権 – 寄稿内容の所有権は寄稿者が持つこと。 有効性 – リンクはすべて一般公開されている内容であること (無料およびゲートしているコンテンツは問題なし)。 適時性 – 寄稿した内容はすべて関連の日付に作成されたものであること。 中立性 – […]

これは、AWS Week in Review の最初のコミュニティ型エディションです。先週のブログ投稿 (AWS Week in Review – Coming Back With Your Help!) にお応えして、他の 9 名の寄稿者がこの投稿を現実のものとしてくれました。すばらしいスタートです。今週は 20 件にいくかどうか見てみましょう。 月曜日 8 月 22 日 は、Acquia (APN テクノロジーパートナー) がどのように AWS を利用して FedRAMP コンプライアンスを実現しているかについて説明しました。 [backspaceblog] は、アプリケーションのフロントエンドセキュリティ (「Shared Responsibility – Stopping threats at the source」) と、脅威が AWS に到達することを防ぐためにアプリケーションで使用できる技術について説明しました。 は、リソースレベルの分析を使用して最もコストがかかっているリソースを特定する方法と、それらの洞察を使用してクラウドコストを最適化する方法を AWS ユーザーに示しました。 火曜日 8 月 23 日 は、新しい […]

数か月前に公開したブログ I Love My Amazon WorkSpace では、私が Amazon WorkSpaces をフルタイムで使用するようになった理由や、大ファンになった経緯についてご説明しました。 ブログを公開後、似たような感想を何人もの AWS ユーザーからお寄せいただきました。そこで今回は、今まで以上に経済的で柔軟性と実用性に優れた WorkSpaces を実現させたポイントについてご紹介します。 時間単位で WorkSpaces を利用 – WorkSpace の料金を時間単位で支払えるようになりました。 ルートボリュームを拡大 – 新たにリリースした WorkSpaces のルートボリュームは 80 GB になりました。 次に各新機能の詳細についてご説明します。 時間単位で WorkSpaces を利用 WorkSpace へのアクセスはパートタイムで充分というユーザー (厳密に言えば組織) にとって、このオプションはメリットになるでしょう。すでにご提供していた月額オプションに加え、WorkSpace の使用量を時間単位で支払えるようになりました。これは AWS コストの節約にもつながります。パートタイム社員、出張の多い方、他のパートタイム社員と仕事を分割している方、複数の短期間プロジェクトに携わっている方などにとって、このオプションは最適です。企業研修プログラム、教育、リモート管理などにも大いに役立ちます。AlwasysOn と AutoStop という新しいモードが 2 つあります。 AlwaysOn – これは既存のモードです。WorkSpace が常に実行しているので瞬時にアクセスすることができます。お支払いは月額払いになります。 AutoStop – 新しいモードです。ログインすると WorkSpace が開始し、請求対象となる時間もその時点で開始します。指定した期間以上に切断状態が続くと、自動的に停止するようになっています。 AutoStop […]

AWS OpsWorksはアジアパシフィック（ソウル）リージョンで利用可能になりました。さらに、次の新しいリージョンエンドポイント：EU（フランクフルト）、EU（アイルランド）、US West（北カリフォルニア）、南アメリカ（サンパウロ）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、そしてアジアパシフィック（東京）で利用可能になりました。 以前は、これらのリージョンにあるOpsWorksのリソースにアクセスするためには US East(バージニア北部）のエンドポイントを使う必要がありました。今回の発表により、スタックと同じリージョンにあるエンドポイントを利用可能になりました。これによりAPIの遅延を減らし、レスポンスタイムの改善、そしてクロスリージョンに依存した障害のインパクトを限定することが可能です。 リージョンエンドポイントのリストの詳細はAWSリージョンとエンドポイントをご覧ください。 OpsWorksの詳細： 製品ページ ドキュメント 舟崎が翻訳しました。原文はこちらです。

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をクリックして、鍵が有効化され利用できるようになりました: […]

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リリースで利用可能であり、簡単にインストールできます: Snowball Toolsページから適切なファイルをダウンロードしてローカルディレクトリに展開する アダプタの構成が適切かどうかを確認する(アダプタはデフォルトで8080ポートをリッスンします) Snowballをネットワークに接続しそのIPアドレスをビルトインディスプレイから取得する コンソールを開いてアンロックコードとジョブマニフェストを取得する IPアドレス、アンロックコード、マニフェストファイルを指定してアダプタを起動する アダプタが起動すれば、ローカルエンドポイント(オンプレミスホストのIPアドレスとリスナーポート)を使うよう構成するだけでご自身のS3セントリックツールが利用できます […]

コンテナは素晴らしいのですが、それを管理することは非常に難しい問題です。私達のお客様は、マイクロサービスからバッチジョブにいたるまで、多くのワークロードでコンテナをAWS上で使ってきました。彼らが私達に教えてくれたのは、EC2インスタンスやコンテナの状態を含むクラスタ管理はトリッキーで、特に環境が大きくなってくると問題になってくるということでした。また、AWSプラットフォームで利用可能な、ロードバランサー、スケーリング、セキュリティ、モニタリング等の機能とコンテナとの連携は重要な要件であるとも教えてくれました。Amazon ECSはこれら全ての要求とそれ以上に応えるために設計されました。 我々はお客様がコンテナ化したアプリケーションを本番環境で稼働させることを簡単にするためにAmazon ECSを作りました。コンテナ管理のためのソフトウェアをインストールしたり運用したりする必要は全くなく、これらは全てサービスとして提供されます。必要となるEC2のキャパシティをクラスタに追加して、使いたいコンテナイメージをアップロードするだけで良いです。Amazon ECSが残りの面倒をみてくれて、EC2インスタンスのクラスタ上にコンテナをデプロイしてそのヘルス状態を監視してくれます。ExpediaやRemind等のお客様は、Amazon ECSを開発ワークフローに組み込み、その上にPaaSプラットフォームを構築しています。他には、PreziやShippableは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 […]

昨年、開発者がモバイル、web、エンタープライズそしてIoTアプリケーション向けバックエンドWebサービスを構築できるようにするため、Amazon API Gateway を紹介しました（Amazon API Gateway – Build and Run Scalable Application Backend to learn more を参照)。そのときから、AWSの顧客は AWS Lambda、Amazon 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をクリックしてください。 名前、説明を入力し、それからスロットリングとクオータのオプションを必要に応じて設定します。 […]

私たちは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の１つとして発表します。これはレイヤー7で実行され、幾つかの先進的な機能をサポートしています。元々のロードバランサー(これからはクラシックロードバランサーと呼ばれます)は引き続き利用可能で、レイヤー4とレイヤー7の両方の機能を提供します。 アプリケーションロードバランサーはコンテントベースのルーティングと、コンテナで実行されるアプリケーションをサポートします。業界標準の２つのプロトコル (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つのプロトコルサポートを追加しました: WebSoecketとHTTP/2です。 WebSocketはクライアントとサーバの間で、長期間のTCPコネクションを利用可能にしてくれます。これは、HTTP接続を開いたままにして長い間隔の”ハートビート”を利用する様な古い方式の代替として、より効率の良いものとなっています。WebSocketはモバイルデバイスには特に良くて、電源の消費を最小にしながら、株価やスポーツの得点などの動的なデータを配信するのに利用できます。ALBはws://とwss://プロトコルを使ってWebSocketをネイティブサポートしています。 HTTP/2はHTTP 1.1プロトコルから多数の改善がされたものになります。この新しいプロトコルは1つのコネクションで上で複数のリクエストをサポートしています。これによって、ネットワークトラフィックを削減し、またプロトコルはバイナリをベースにしています。 アプリケーションロードバランサーはストリーミングやリアルタイム、そしてWebSocketのワークロードを最適化された方式で扱うために設計されています。リクエストとレスポンスをバッファリングせずに、ストリーミングとして扱います。これによって、レイテンシを削減しアプリケーションのパフォーマンスが向上します。 ALBを作成する では、アプリケーションロードバランサーを作成し、トラフィックを捌ける様にしてみましょう！ Elastic […]