Amazon Web Services ブログ

Category: Networking & Content Delivery

Lambda@Edge デザインベストプラクティス

Lambda@Edge をより活用いただくために Lambda@Edge ベストプラクティスシリーズと題したブログを連載します。この中ではいくつかのユースケースを用いて Lambda@Edge をどのように利用すればよいか、CI/CD パイプラインにどのように組み込むべきか、ビジネスニーズに応える形で組み込まれていることを担保するためにはどのように考えればよいか等について取り上げます。 記念すべき初回は Lambda@Edge のデザインベストプラクティスについて取り上げます。いくつか一般的なユースケースをもとに関数をどのタイミングで実行するのが良いのか、それはどのような観点で選択されるべきかということについてパフォーマンス及びコスト最適化の観点から推奨構成について説明していきたいと思います。

Read More

OBS Studio から クラウド上の AWS Media Services への接続

全 5 回の Blog 連載のうちの 2 回目の連載である今回は、様々なエンコーダから AWS Media Services への接続および設定方法を学びます。AWS Media Services はカスタマーに対して、高いスケーラビリティを持つ over-the-top (OTT) ビデオ体験を提供することを可能にします。ライブチャンネルもしくはイベントを配信するには、カメラなどの機器からのビデオ信号をエンコードし、追加的な処理、パッケージング、配信のために、クラウドに送信します。 OBS STUDIO と AWS MEDIA SERVICESを利用したチャンネルの作成 こちらの例では、OBS(Open Broadcaster Software) Studio というソフトウェアと RTMP (Real-time Messaging Protocol) Pushを用いたストリームをセットアップし、クラウド上での動画処理およびパッケージングのための AWS Media Servicesの設定方法を、ステップ・バイ・ステップの手順でお見せします。 ワークフロー例のダウンロード こちらの例では、下記の方法を学びます。 RTMP push を使った伝送用エンコーダーとしての OBS Studio のセットアップ 伝送ストリームを AWS Elemental MediaLive で受けて、adaptive bitrate (ABR) のストリームにエンコードする設定方法 AWS Elemental MediaLive の出力を AWS […]

Read More

オンプレミスの AWS Elemental Live から クラウド上の AWS Media Services への接続

AWS Media Services は、あなたのカスタマーに対して、高いスケーラビリティを持つ over-the-top (OTT) ビデオ体験を提供することを可能にします。ライブチャンネルもしくはイベントを配信するには、クラウド上で追加的な処理、パッケージング、配信する前に、まず、撮影機器からのビデオ信号をエンコードする必要があります。まずは、(クラウドに対して)地上のカメラ、ソフトウェア、ハードウェアから始めていきましょう。 オンプレミスエンコーダと AWS Media Services を使用してライブビデオの作成を開始する 全 5 回の Blog 連載を通じて、様々なエンコーダをどのように設定して AWS Media Services に接続するのかを学ぶことが出来るでしょう。最初のこのワークフローでは、撮影現場の AWS Elemental Live エンコーダーを利用して、Real-time Transport Protocol (RTP) と forward error correction (FEC) のチャンネルを作成・設定し、クラウド上で処理およびパッケージングをするための AWS Media Services を設定する方法をステップバイステップで解説していきます。 下記の方法を学びます。 オンプレミスのアプライアンスである AWS Elemental Live を、FEC を有効にした RTP を使った伝送用エンコーダーとしてセットアップする方法 伝送ストリームを AWS Elemental MediaLive で受けて、adaptive bitrate (ABR) のストリームにエンコードする設定方法 […]

Read More

Amazon より 新しい .BOT gTLD が誕生

本日、 Amazon の新規汎用最上位ドメイン (gTLD) 、 .BOT の公開をお知らせします。.BOTドメイン をお使いいただくと、ボットにIDやポータルを提供することができます。フィットネスボット、 slack ボット、 e コマースボットなど、 .BOT のドメインを通じて全機能に簡単にアクセス可能です。「ボット」という言葉は .COM TLD 内で2016年、4番目に登録数の多いドメインキーワードであり、ひと月に6000以上の登録がありました。.BOT ドメインではお客様のボットへのインターネット ID の付与、そして SEO パフォーマンスの向上をご提供します。 本記事の執筆時点では .BOT ドメインの価格は $75 〜、 Amazon Lex 、Botkit Studio 、 Dialogflow 、 Gupshup 、 Microsoft Bot Framework 、 Pandorabots のようなサポートツールを使って検証し公開する必要があります。今後さらに多くのツールのサポートを予定していますが、お気に入りのボットフレームワークがサポート対象外の場合はお気軽にご連絡ください。contactbot@amazon.com ここからは、whereml.bot のポッドを例にドメインの登録とプロビジョニングの流れを紹介します。その後でホストゾーンとして Amazon Route 53 にドメインを設定する手順を見ていきましょう。では始めましょう。 .BOT ドメインの登録 まず https://amazonregistry.com/bot で新規ドメインを入力し、magnifying classをクリックして入力したドメインが利用可能かどうかを確認します。利用可能であれば、登録ウィザードに進みます。 次に、ボットの認証方法を選ぶ画面になります。私は全てのボットを […]

Read More

[AWS Black Belt Online Seminar] Amazon VPC 資料及び QA 公開

こんにちは、マーケティングの鬼形です。 先日(2018/4/18) 開催された AWS Black Belt Online Seminar「Amazon VPC」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20180418 AWS Black Belt Online Seminar Amazon VPC PDF 録画(オンデマンドセミナー) Q1. (自己紹介の質問) Market Place の何が好きか教えていただけるとうれしいです。 A. Network 担当ということで、様々なルータやファイアーウォール製品を時間単位で複数お試しができるので、検証が簡単にできるのが好きなところです。 Q2. 別々の VPC では物理的にネットワークが分離する認識で合っていますか。 A. 別々の VPC は論理的にネットワークが分離されます。 Q3. VPC を分ける単位のベストプラクティスはありますでしょうか。 A. ページ 76,77 でいくつか例をご紹介させていただきました。よりよいベストプラクティスをお探しの場合は是非 Well-Architectedをご参照ください。 Q4. 異なるリージョンのAZを、1つのリージョンから指定することはできますか。 A. リージョンの内部にアベイラビリティゾーン(AZ)が存在するので、指定することはできません。それぞれのリージョンから AZ を選択してください。 Q5. (サブネット作成時の)ネームタグの命名規則について推奨はありますか。 A. 特に推奨はありませんが、わかりやすいように私は […]

Read More

Amazon ECS サービスディスカバリ

Amazon ECS でサービスディスカバリがサポートされました。これにより、ECS サービスが Amazon Route 53 の予測可能でフレンドリーな DNS 名で自動的に登録することができるようになります。負荷やコンテナの健全状態に対応してサービスがスケールアップまたはダウンすると、Route 53 のホストゾーンは最新の状態が保たれ、他のサービスが各サービスの状態に基づいてコネクションを行う必要がある場所を発見できるようになります。次のアドレスで、架空のソーシャルネットワークアプリでサービスディスカバリのデモを見ることができます。https://servicediscovery.ranman.com/. サービスディスカバリ マイクロサービスや最新のアーキテクチャへの移行の一部には、障害や変化する負荷に迅速に対応できるダイナミックで、オートスケーリングでき、そして堅牢であるサービスを持つことが必要とされます。皆さんのサービスはおそらく、依存したり利用されるサービスが複雑に関連した依存関係のグラフ構造を持っているでしょう。最新のアーキテクチャのベストプラクティスは、これらのサービスが独自に依存関係を指定できるようにして疎結合にすることですが、ダイナミックな環境では各サービスが自力で自身が接続する先を見つける必要があるため、複雑になってしまう場合があります。 consul、etcd、またはzookeeperなどのサービスディスカバリの従来のアプローチは、すべてこの問題をうまく解決しますが、追加のインフラストラクチャをプロビジョンして管理する必要や、コンテナやインスタンス上にエージェントをインストールする必要があります。これまでは、サービスが互いに発見して接続できるように、独自のサービスディスカバリーシステムを構成して実行するか、すべてのサービスをロードバランサに接続する必要がありました。これからは、ECS コンソール、AWS CLI、または ECS API を使用して、コンテナ化したサービスのサービスディスカバリが可能になります。 Amazon Route 53 サービスレジストリとAuto Naming API の紹介 Amazon ECS サービスディスカバリは、Amazon Route 53 サービスレジストリと Auto Naming API とコミュニケーションすることにより動作します。このブログではこれまでそれらについて触れていないため、ここでは簡単にこれらの Route 53 API の動作について概説したいと思います。最初に、一部の用語について説明します。 名前空間 – 名前空間は、トラフィックを流すドメイン名を指定します (例: internal、local、corp)。これは、サービスが互いに発見できる論理的境界と考えることができます。名前空間は、 aws servicediscovery create-private-dns-namespace コマンドの呼び出しまたはECS コンソールで作成することができます。名前空間は、Route 53 のホストゾーンとほぼ同じです。名前空間にはサービスが含まれます。これは次に取り上げる用語です。 サービス – サービスは「auth」、「timeline」、「worker」などの名前空間にある特定のアプリケーションまたはアプリケーションのセットです。サービスはサービスインスタンスを含みます。 […]

Read More

Amazon CloudFront & Lambda@Edge で画像をリサイズする

多くの画像に対してリサイズを行ったり、新しいデザインレイアウトにウォーターマークを付与したり、ブラウザのサポートのためにフォーマットの最適化を行ったことはありませんか? 画像毎に事前処理を行う必要なく、必要に応じてその場ですぐに画像を自動生成できないかとおもったことはありませんか? Lambda@Edge はそれらを可能にし、ユーザーの利便性を向上させ、帯域使用量を削減します。

Read More

東京に5番目のエッジロケーションを開設。アトランタ(A)からチューリッヒ(Z)までAmazon CloudFrontの接続拠点数が100箇所に

アマゾン ウェブ サービス(AWS)が、グローバルなコンテンツデリバリーネットワーク(CDN)のAmazon CloudFrontのリリースしたのは、約9年前の出来事になります。14の接続拠点からなる高性能なエッジネットワークとして始まったこの新しいサービスは、現在、世界中からの数百万ビューアーの接続に対応するまで成長しました。本日、Amazon CloudFrontの成長が最も著しい地域の一つである日本で100番目の接続拠点(89のエッジロケーションと11のリージョナルエッジキャッシュ)を発表できることを嬉しく思います。100番目の接続拠点(POP)は、東京で5番目そして、日本で6番目のエッジロケーションとなります。 「Amazon CloudFrontのグローバル展開におけるこの節目は、お客様のアプリケーションをよりセキュアで高速、かつ信頼性の高いものにしたいと言う私達のこだわりの成果です。」とAWS Edge Services VPのPrasad Kalyanaramanは、語っています。「東京を100番目の接続拠点のロケーションとして発表できることを特に嬉しく思います。新たなロケーションへの展開やLambda@Edge、AWS Shieldなどの革新的な技術の導入などを通して今後も私達のグローバルのお客様にサービスを提供して行くことを楽しみにしています。」 100番目の接続拠点が東京で展開されることについて日本でも特にご利用が大きい数社のお客様から激励のコメントを頂いています: ソニー・インタラクティブエンタテインメント(SIE)は、PlayStation®のハードウェア及びソフトウェアの製造販売と、PlayStation™Network(PSNSM)などのサービスを手がけている会社です。 SIE、システム/ネットワークエンジニアリング オペレーション部門、課長の田中博規氏は次のように語っています。「このたびはCloudFront100番目のエッジロケーション開設おめでとうございます。CloudFrontは、PlayStation™Networkの安定的な配信と高いパフォーマンスを支える重要なサービスのひとつとなっています。同時に、ゲームコンテンツの高精細化・多機能化・大容量化に伴い、CloudFrontは、弊社のグローバルの利用帯域増に対応できる数少ないCDNサービスの一つです。ユニークで付加価値の高いCDNサービスとしてCloudFrontのさらなる発展を心より期待しています。」 キヤノン株式会社は、カメラ、ビデオカメラなどの精密機器を製造するメーカーです。キヤノン株式会社、映像事務機DS開発センター、主席の八木田 隆氏は次のように語っています。「CloudFrontの100番目のエッジロケーションがTokyoということを感慨深く感じると同時にエッジロケーションが増えていくことはとても喜ばしいことです。Amazon CloudFrontとCloudFrontのAWSサービスとの連携は、キヤノンのクラウドサービスのDynamic ContentsとStatic Contentsの両方の高速な配信に欠かせないものとなっています。ワールドワイドに展開されているCloudFront DistributionをAPIで簡単に制御できるため、我々のサービスの継続的統合と継続的デリバリー(CI/CD)及び自動化に寄与しています。」 三菱電機株式会社は、一般消費者から産業向けまで幅広い製品の製造とサービスを提供している会社です。三菱電機株式会社、インフォメーションシステム統括事業部、部長の岩城新一氏は次のように語っています。  「この度の100番目のエッジロケーション開設大変おめでとうございます。当社では3年前からCloudFrontを活用した大規模動画配信システムによるコンテンツ提供サービスを開始しております。開発当時を振り返りますと、システム設計段階からの手厚いご支援はもとより、システムのカットオーバー前の当社からの突然の負荷テストの依頼など無理なお願いも快く引き受けていただき、人的なサポート面でも大変お世話になったことを思い出します。また、御社の日米のチームがうまく連携していることもとても印象的でした。CloudFrontは立ち上げ初期のチューニング以降は一切問題がなく現在大変安定した配信をしています。Amazon CloudFrontの機能とエッジロケーションも継続して増えているので、日々急激に進化していることを肌で感じています。今後もCloudFrontがどのような進化を遂げていくのか期待をもって見守っていきたいと思っています。」 ディライトワークス株式会社は、ゲームの企画・開発・運営を行っており、その中でも『Fate/Grand Order』は現在、1,000万ダウンロードを突破しています。ディライトワークス株式会社、テクニカル・ディレクターの田村祐樹氏は次のように語っています。「ディライトワークスは、”ただ純粋に、面白いゲームを創ろう。”という開発理念のもとに、ゲームの創作をおこなっております。そこで重要な要素となるのが、より多くのユーザーにより高品質なコンテンツを届けることです。多くのCDNサービスがある中、高い品質、低いコスト、安定した配信と速いインバリデーションからAmazon CloudFrontの利用を決断しました。また、Amazon Route 53、AWS WAFやSSL証明書の自動更新が可能なAWS Certificate Manager(ACM)などの他のAWSサービスとの親和性も高いことにメリットを感じています。今後もCloudFrontとAWSから革新的なサービスに出会えることを期待しています。」 株式会社サイバーエージェントは、メディア事業、広告事業、ゲーム事業とインターネットを軸に様々な事業を展開しています。株式会社サイバーエージェント、メディア統括本部 最高技術責任者の福田一郎氏は、次のように語っています。「CloudFrontの100番目のエッジロケーションという節目が東京で迎えられるということを大変喜ばしく思います。CloudFrontが私達のサービスにとって、より安定・高速にサービス提供をするための一翼を担っていることは間違いありません。これからも、CloudFrontおよびAWSがより一層成長・発展していくことを願っております。」 Amazon CloudFrontの100の接続拠点は、23カ国、50都市と全世界に配置されています。この1年間で37のエッジロケーションを追加しネットワーク帯域を50%以上増設しています。追加された拠点には、新しく4カ国*と9都市が含まれまています: ドイツ、ベルリン;米国、ミネアポリス;チェコ共和国*、プラハ;米国、ボストン;ドイツ、ミュンヘン;オーストリア*、ウィーン;マレーシア*クアラルンプール;米国、フィラデルフィア;スイス*、チューリッヒ。 アマゾンウェブサービスは、ネットワークの拡大に積極的に取り組んでおり、 中東の新しいAWSリージョン開設の予定を発表できたことも嬉しく思います。その取組みに先立って2018年の第1四半期にアラブ首長国連邦に最初のエッジロケーションを解説します。 私達は、常に世界中のお客様により良いサービスを提供する方法を考えています。2016年のre:Inventカンファレンスでは、リージョナルエッジキャッシュという新しいキャッシュ階層の発表で11の接続拠点をネットワークに追加しました。これらの接続拠点は従来のエッジロケーションと比べ大きいキャッシュ容量がありエッジロケーションとお客様のオリジンサーバの間に配置されます。この配置によりビューアーにより近いところでお客様のコンテンツをより長い間キャッシュに残すことができるため、お客様のオリジンサーバの負荷を下げ、ファイルの取得を早くします。 私達は、CDNの評価は、世界にあるロケーションの数だけで決まらないないことも理解しています。Amazon CloudFrontの広大なネットワークに加え、ビジネス要件を満たすために必要な機能やパフォーマンスを満たせるように常にお客様の声に耳を傾けています。セキュリティは、私達にとって最大の優先事項であり、つい最近ではセキュリティポリシー機能のリリースとHIPAA対応を発表できたことを嬉しく思います。また数ヶ月前には、お客様がエンドユーザにより近い所でLambda関数が実行できるLambda@Edgeの一般提供をはじめました。また、開発者の利便性と使い勝手を良くするために、グローバルのキャッシュのインバリデーションと設定変更の伝搬にかかる時間を改善しました。CDNサービスによって、 インバリデーションや設定変更のパフォーマンスの定義が異なる場合があります。CloudFrontの場合、数ミリ秒でインバリデーションのリクエストを受け付け、殆どの場合60秒以内に「全世界のすべてのサーバーでキャッシュをクリア」したことを確認します。   話題性の高いロケーションでの拠点や新機能の追加以上に、私達は、世界中の様々な規模のお客様と共に協力できることを光栄に感じています。個人のブロガーや中小企業のオーナーから世界有数の大企業まで、私達にとって全てのお客様が重要であることお伝えすると同時に私達のグローバルなネットワークに加わっていただいていることを深く御礼申し上げます。 ·         Amazon CloudFrontチームより Amazon CloudFrontのご利用についてより詳しい情報をご希望の場合、こちらのWebページから最新のウェビナーの開催情報や資料を入手いただけます。

Read More

Application Load BalancerがSNIを利用した複数のTLS証明書のスマートセレクションをサポートしました

本日、我々はApplication Load Balancer (ALB)でServer Name Indication (SNI)を使った複数のTLS/SSL証明書のサポートをリリースしました。これによって、単一のロードバランサの背後に、それぞれ別の証明書を持ったTLSで保護されたセキュアなアプリケーションを複数配置することが可能になります。SNIを利用するためには、複数の証明書をロードバランサの同じセキュアリスナーに紐付ける必要があります。ALBは各クライアントに最適なTLS証明書を自動的に選択します。これらの新機能は追加料金無しでご利用可能です。 もし新しい機能をどうやって使えばいいかを手っ取り早く知りたければ、こちらをクリックして下さい。この機能に興味があり、Transport Layer Security (TLS)について復習したい場合は続きをお読み下さい。 TLS? SSL? SNI? SSLとTLSは技術的には異なるものですが、これらを入れ替え可能な用語として使いがちです。SSLはTLSプロトコルの技術的な祖先にあたります。以下では簡潔さのために、TLSという用語を使っていきます。 TLSはパスワード、クッキー、クレジットカード番号といったデータを安全に伝送するためのプロトコルです。これによって、送信されるデータのプライバシー、認証、完全性が実現されます。TLSは、ウェブサイトのIDカードに相当する証明書を基礎とした認証技術を利用します。もし、その証明書を署名し発行した人、すなわちCertificate Authority (CA)を信用するなら、あなたはその証明書の中のデータは正しいと信用します。あるブラウザがTLSが有効化されたあなたのALBに接続するとき、ALBはあなたのサイトの公開鍵を表示しますが、それはCAによって暗号的に証明されたものになります。この方法によって、クライアントは”本物のあなた”からデータを得ていることと、あなたのサイトの公開鍵を利用して安全な接続を確立可能なことを確実にすることができます。 SNIのサポートによって、同一のALBで1つ以上の証明書をもっと簡単に利用できるようになりました。複数の証明書を使いたい最も一般的な理由は、同一のロードバランサで異なるドメインを捌きたいときです。これは、ワイルドカードやsubject-alternate-name (SAN)署名書をALBで利用することで元々実現可能ですが、いくつかの制約があります。ワイルドカード証明書は単純なパターンに合致する関連するサブドメインでしか使えません。SAN証明書は複数の異なるドメインをサポートできますが、単一の認証局でそれぞれを認証する必要があります。つまり、新しいドメインを追加するときには毎回証明書を再認証して再配布する必要があることを意味しています。 フォーラムやReddit、そして私のメールボックスで最も頻繁に頂いていた要望の1つが、TLSのServer Name Indication (SNI)拡張を利用してクライアント毎に証明書を選択するようにしてほしいというものでした。TLSはHTTPの下のトランスポートレイヤを担当するため、クライアントがリクエストしたホスト名を見ることができません。SNIはクライアントがサーバに”私が欲しい証明書はこのドメインです”というのを初回接続時に伝えることで動作します。これによってサーバはクライアントに返答するための適切な証明書を選択することができます。全てのモダンなウェブブラウザとその他のクライアントの大多数はSNIをサポートしています。実際、CloudFrontに接続しているクライアントの99.5%以上がSNIサポートしていることを今現在確認しています。 ALBの証明書スマートセレクション ALBの証明書スマートセレクションはSNIを越えていきます。正しいドメイン名の配列だけでなく、証明書にはサーバがサポートしている鍵交換方式と暗号、さらに証明書を署名する時に使った署名アルゴリズム (SHA2, SHA1, MD5)が含まれています。TLS接続を確立する時に、クライアントは”ClientHello”メッセージを送ることでTLSのハンドシェイクを開始しますが、そのメッセージにはクライアントが利用可能なプロトコルバージョン、拡張、暗号アルゴリズムの組、そして圧縮方式の概要が含まれています。各クライアントが何をサポートしているかを元に、ALBのスマートセレクションアルゴリズムがその接続のための証明書を選択し、クライアントに送ります。ALBは古典的なRSAアルゴリズムも、より新しくて人気で高速な楕円曲線ベースのECDSAアルゴリズムも両方サポートしています。クライアントのECDSAサポートはSNI程は広まっていませんが、全てのモダンなウェブブラウザではサポートされています。より高速でCPUの利用も少ないので、超低レイテンシなアプリケーションや、モバイルアプリのバッテリ残量の節約には特に有効です。ALBはTLSのハンドシェイクから各クライアントが何をサポートしているかが分かるので、同一ドメインのRSAとECDSA証明書の両方をALBにアップロードすることでALBが各クライアントに最適なものを自動的に選択させることができます。 ALBでSNIを利用する ここではウェブサイトの例として、VimIsBetterThanEmacs.comとVimIsTheBest.comを使います。Amazon Route 53でこれらのドメインを購入しホストしておいて、2つの別々の証明書をAWS Certificate Manager (ACM)で発行しています。もし1つのALBでこれらのサイトを両方とも安全に配信したいと思ったら、コンソールから両方の証明書を追加することができます。 最初に、コンソールから私のロードバランサを選択し、listenerタブに行き、”view/edit cerfiticates”を選択します。 次に、左上の角にある”+”ボタンを使って証明書を幾つか選択して、”Add”ボタンをクリックします。 これ以上の手順はありません。GUI好きな方ではなかった場合も、AWS Command Line Interface (CLI) (またはSDK)経由でももちろん新しい証明書を追加することはできますのでご安心下さい。 aws elbv2 add-listener-certificates –listener-arn <listener-arn> –certificates CertificateArn=<cert-arn> 知っておくべきこと ALBのアクセスログには、クライアントがリクエストしたホスト名と使われた証明書のARNが含まれるようになります。もし”hostname”のフィールドが空 (“-“で表現されます)だったときには、そのクライアントではリクエストにSNI拡張が使われていません。 […]

Read More

新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング

Elastic Load Balancing(ELB)は、Auto ScalingとAmazon CloudWatchを含む3つの組みの一部としてローンチした2009年以来、AWSの重要な要素になっています。それから、私たちは多数の機能を追加し、そしてApplication Load Balancerをリリースしました。コンテナで稼働するアプリケーションに対するアプリケーションレベルでのコンテンツベースルーティングをサポートする様に設計されており、Application Load Balancer はマイクロサービス、ストリーミング、リアルタイムワークロードと相性が良いです。 長年にわたって、私達のお客様はあらゆる規模のwebサイトや、アプリケーションをサポートする為にELBを利用しています。1, 2台のT2インスタンス上で動くシンプルなサイトや、ハイエンドインスタンスで構成される大きなフリート上で動き大量のトラフィックを捌く複雑なアプリケーションにまで利用されています。ELBはバックグラウンドでトラフィックを監視し、需要に応じる様に自動的にスケールしています。このプロセスには、余裕をもったバッファが含まれていて、長年にわたってより迅速になりより反応性があがってきたことで、生放送やフラッシュセール、ホリデーシーズンををサポートするためにELBを利用しているお客様にとっても、よく動作します。しかしながら、リージョン間の瞬時のフェイルオーバーや急激なワークロードの変動(スパイク)などの状況では予想されるトラフィックの急増に対してELBをプリプロビジョニングをするようお客様と協力して対応してきました。 新しい Network Load Balancer 今日、新しいNetwork Load Balancer(NLB)を発表します。NLBは超低遅延で高いスループットを維持しながら利用者の努力なしに、秒間何百万リクエストを捌く様に設計されています。Network Load Balancerはターゲットグループやターゲットの完全なプログラム制御を含めて、Application Load BalancerとAPI互換性があります。最も重要な機能のいくつかは以下の通りです。 固定IPアドレス – 各Network Load Balancerは 各VPCサブネットの範囲に対して1つの固定IPアドレスを提供します。us-west-2aにあるサブネットにターゲットがあり、他のターゲットがus-west-2cのサブネットにあった場合、NLBは2つのIPアドレス(サブネットあたり1つ)を作成し管理します。そのIPアドレスに対する接続は そのサブネット内のインスタンス全体に分散します。さらに制御をするために、各サブネットに対して既存のElasticIPを割り当てることも可能です。IPアドレスを完全に制御することで、Network Load BalancerはIPアドレスを、DNSレコードやファイアウォールルールなどにハードコードされる必要がある場合でも利用可能です。 ゾーナリティ(Zonality) – サブネット単位のIP機能はパフォーマンスの向上により遅延を減少させ、アイソレーションとフォールトトレランスを通じて可用性を向上させ、Network Load Balancerの利用をクライアントアプリケーションから透過的にします。Network Load Balancerは、自動フェイルオーバーを可能にしながら、特定の送信元からの一連のリクエストを1つのサブネットのターゲットにルーティングします。 送信元アドレスの保持 – Network Load Balancerでは、到達コネクションのオリジナルの送信元IPアドレスと送信元ポートを維持するので、アプリケーションソフトウェアはX-Forwarded-Forやプロキシプロトコルや他のワークアラウンドをサポートする必要がありません。これは、VPC Security Groupsを含む一般的なファイアウォールルールをターゲット上で利用可能であることを意味しています。 長時間の接続 – NLBは組み込まれたフォールトトレランスによりコネクションを扱うため、NLBは何ヶ月も何年にもわたってオープンなコネクションを処理できるため、IoTやゲーム、メッセージングアプリケーションに最適です。 フェイルオーバー – Route53による ヘルスチェックによって、NLBはリージョン内およびリージョン間のIPアドレス間のフェイルオーバーをサポートします。(訳注: NLB単体では複数AZをサポートします) Network […]

Read More