Category: Elastic Load Balancing*


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.comVimIsTheBest.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拡張が使われていません。
  • ACMかIAMにある全ての証明書を利用することができます。
  • 同一ドメイン向けの複数の証明書を1つのsecure listenerに紐付けることができます。ALBはクライアントのサポート範囲を含む複数の因子を元に適切な証明書を選択します。
  • もしクライアントがSNIをサポートしていない時には、ALBは(listener作成時に1つ指定する)デフォルト証明書を使います。
  • 3つの新しいELB API呼び出しが追加されます: AddListenerCertificates, RemoveListenerCertificates, そしてDescribeListenerCertificatesです。
  • (デフォルト証明書を除いて) ロードバランサ毎に最大25個の証明書を紐付け可能です。
  • リリース時点でこれらの新しい機能はAWS CloudFormationでサポートされています。

私の同僚のJon Zobristが作ったウェブサイトでこれらの新しい機能が稼働している例を見ることができます: https://www.exampleloadbalancer.com/.

全体を通して、私は個人的にこの機能を使っていきますし、多くのAWS利用者もこのメリットを受けることができると確信しています。Elastic Load Balancingチームには、これを我々のユーザに届けるためのハードワークをしてくれたことに感謝したいと思います。

Randall

原文: Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI (翻訳: SA岩永)

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

Elastic Load Balancing(ELB)は、Auto ScalingAmazon 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 Load Balancerの作成

EC2コンソールの画面を開き、Network Load Balancerを作成することができます。Load Balancers を選択し、Create Load Balancerをクリックします。

Network Load Balancerを選び、Createをクリックし、詳細を入力します。ターゲットVPCの各サブネットに対してElasticIPを選択することがで、Network Load Balancerにタグづけができます。

次にConfigure Routingをクリックし、新しいターゲットグループを作成します。名前を入力し、プロトコルとポートを選択します。トラフィックポートまたは代替に選んだポートに対するヘルスチェックも設定することができます。

Register Targetsとトラフィックを受けるEC2インスタンスをクリックし、 Add to registeredをクリックします。

全ての項目が問題無い事を確認し、Createをクリックします。

新しいLoad Balancerの状態はprovisioningで、1分程度の間にactiveに代わります。

テスト目的のために、コンソールからLoad BalancerのDNS名前を確認します。(通常はAmazon Route 53を使い、もっとわかりやすい名前を使用します。)

それから大量のトラフィックを送りました。(1秒か、2秒の間実行する事を意図していましたが、気をとられ、膨大な数のプロセスを生成してしまいました。これはうれしいアクシデントでした。)

$ while true;
> do
>   wget http://nlb-1-6386cc6bf24701af.elb.us-west-2.amazonaws.com/phpinfo2.php &
> done

もちろん、より規律あるテストではBees with Machine Gunsの様なツールを使用します!

トラフィックを流す様にするため少し休憩したのち、私のLoad BalancerのCloudWatchメトリックスを確認し、簡単に、突然のトラフィックの猛攻撃を処理することができたことを確認しました。

どの様な負荷をかけているか確認するために、EC2インスタンスをみました。(本当にうまくいったことがわかりました)

私の同僚達が私が実施したよりもより規律的なテストを実施しています。彼らはNetwork Load Blancerをセットアップし、それにはEC2インスタンスのオートスケールフリートを利用しました。彼らは数百台のEC2インスタンスにより構成される2番目のfleetをセットアップし、それぞれBees with Machine Gunsを実行し、非常に多数のリクエストとレスポンスサイズを生成する様に設定しました。秒間150万リクエストからはじめ、素早くダイアルを全部あげ、テストリソースの最大に達する前に、秒間300万以上のリクエスト、総帯域幅が30Gbpsに達しました。

Load Balancerの選択

いつものように、Load Balanerを選ぶ場合、アプリケーションの要求を考える必要があります。以下はいくつかのガイドラインです。

Network Load Balancer(NLB) – TCPトラフィックの負荷分散に理想的で、NLBは超低遅延を維持しながら秒間数百万のリクエストを取り扱う能力があります。NLBはAvailability Zone毎に1つの固定IPを使いながら、突発的で変動しやすいトラフィックパターンを取り扱う事に最適化されています。

Application Load Balancer(ALB) – HTTPおよびHTTPSトラフィックの高度なロードバランシングに理想的で、ALBはマイクロサービスやコンテナベースのアプリケーションを含むモダンなアプリケーションアーキテクチャをサポートする高度なリクエストルーティングを提供します。

Classic Load Balancer(CLB) – EC2 Classicネットワーク上に作成されたアプリケーションに最適です。

横並びでの比較には、Elastic Load Balancing Details の表を確認してください。

現在Classic Load Balancer を利用していて、Network Load Balancerに移行しようとしている場合には新しい Load Balancer Copy Utilityを確認してください。このPythonツールは既存のClassic Load Balancerと同じ設定でNetwork Load Balancerを作成する手伝いをします。また既存のEC2インスタンスを新しいload balancerに登録することもできます。

価格と利用状況

Application Load Balancerと同様に、価格はLoad Balancer Capacity Units、LCUに基づきます。費用はLCUあたり$0.006で、以下のディメンジョンの内、最も高い値に基づきます。

  • Bandwidth -LCUあたり1 GB
  • New Connections – LCUあたり800
  • Active Connections – LCUあたり100,000

ほとんどのアプリケーションは帯域幅バウンドで、Application またはClassic Load Balancerと比較すると
約25%のコスト削減(負荷分散について)になります。

Network Load BalancerはChina(Beijing)以外の商用リージョンの全てで利用可能で、AWS CloudFormation, Auto Scaling, Amazon ECSでもサポートされています。

Jeff;

原文: New Network Load Balancer – Effortless Scaling to Millions of Requests per Second (翻訳: SA浅野・岩永)