EC2で大量のSSL接続をコスト効率よく終了する
私は最近、小さなEC2インスタンス（m1.small）で毎秒約2,000の新しい接続リクエストを処理するようにテストされたNode.jsベースのWebソケットサーバーをセットアップしました。 m1.smallインスタンスのコストと、HAProxyなどのWebSocket対応プロキシサーバーの背後に複数のインスタンスを配置する機能を考慮すると、結果には非常に満足しています。
ただし、SSLを使用したテストはまだ行っていないことに気付いたため、いくつかのSSLオプションを調べました。プロキシサーバーでSSL接続を終了することが理想的であることが明らかになりました。これは、プロキシサーバーがトラフィックを検査し、X-Forward-Forなどのヘッダーを挿入して、サーバーが要求の送信元のIPを認識できるようにするためです。
私が調べたSSL終了ソリューションは、Pound、stunnel、およびstudであり、これらはすべて443での着信接続を終了し、ポート80でHAProxyに渡され、次に接続がWebサーバーに渡されます。ただし、残念ながら、c1.medium（高CPU）インスタンス上のSSLターミネーションプロキシサーバーにトラフィックを送信すると、すべてのCPUリソースが非常に迅速に消費され、1秒あたりのリクエスト数は50程度でした。上記の3つのソリューションすべてを使用してみましたが、いずれにせよ、すべてOpenSSLに依存していると想定しているのとほぼ同じように機能しました。 64ビットの非常に大きなHighCPUインスタンス（c1.xlarge）を使用してみたところ、パフォーマンスはコストに比例してしか変化しないことがわかりました。したがって、EC2の価格に基づくと、1秒あたり2,000件の非SSLリクエストに対して60p/mであるのに対し、1秒あたり200件のSSLリクエストに対して約600p/mを支払う必要があります。前者の価格は、1秒あたり1,000または10,000のリクエストを受け入れる計画を開始すると、すぐに経済的に実行不可能になります。
また、Node.jsのhttpsサーバーを使用してSSLを終了しようとしましたが、パフォーマンスはPound、stunnel、studと非常に似ていたため、このアプローチに明確な利点はありませんでした。
したがって、誰かが助けてくれることを望んでいるのは、SSL接続を提供するために吸収しなければならないこのばかげたコストをどのように回避できるかをアドバイスすることです。ハードウェアはSSLの暗号化と復号化用に設計されているため、SSLハードウェアアクセラレータの方がはるかに優れたパフォーマンスを提供すると聞きましたが、現在すべてのサーバーにAmazon EC2を使用しているため、個別のデータがない限り、SSLハードウェアアクセラレータを使用することはできません。物理サーバーを中心に配置します。アマゾン、グーグル、フェイスブックのようなものが、これのコストが非常に高いときに、SSLを介してすべてのトラフィックをどのように提供できるかを知るのに苦労しています。そこにはもっと良い解決策があるに違いありません。
アドバイスやアイデアをいただければ幸いです。
ありがとうマット
まず、ベンチマークを開始するのは良いことです。そこからの私の本能は、あなたがどのキーサイズを使用しているのか疑問に思います。終了できるはずだと私には思えます 毎秒200接続をはるかに超える 。 1024より大きいキーサイズを使用している場合、 パフォーマンスが急速に低下することを知ってください 。
より小さなキーを使用していても問題が発生する場合は、EC2が提供するGPU製品を詳しく調べます。 SSLShader 1秒あたりの特定の接続数の後、費用効果の高い切り替えになる可能性があります。
また、@ ceejayozによるElasticLoadBalancerの言及を調査することにはメリットがあります。
ベンチマークが間違っている可能性があります。毎秒200人のユニークな新しいSSL訪問者を本当に期待しているとは思えませんか？これらの接続のいずれかが最近訪問した人からの再接続である場合は、SSLキャッシュを使用する必要があります-この種のこと：
server.on（ 'newSession'、function（id、data）{tlsSessionStore [id] = data;}）;
server.on（ 'resumeSession'、function（id、cb）{cb（null、tlsSessionStore [id] || null）;}）;
そしてもちろん、ベンチマークは、アプリケーションにとって意味のある、未使用の新しい接続と再開/再利用されたセッションの正しい比率としてテストに表示される必要があります。
また、前述のように、選択した暗号とキーサイズも、おそらく速度に影響します。
SSL速度はアルゴリズムと必要なセキュリティレベルに依存するようです。EC2インスタンスのベンチマークはまだ行っていませんが、BEASTを回避するために事前に選択されたSSLアルゴリズムでGoogleスタイルのECDHEキー交換を有効にすることについて、とにかくみんなといくつかのヒントを共有したいと思いましたおよびその他のSSLの設定ミス。
始めるためのいくつかの良いリンク:(まだすべてを持っている場所はありません。ハンドブックを書く必要がありますが、それまでは、誰かがリンクやヒントを提供したい場合は、この投稿をコミュニティwikiにしました！）
- https://www.ssllabs.com/ （既存のサイトのテストツール）
- http://www.imperialviolet.org/ （皮肉なことにSSLではありません）
- ECDHEとDHE： https://security.stackexchange.com/questions/14731/what-is-ecdhe-rsa
- http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
- https://security.stackexchange.com/questions/15350/how-to-mitigate-ssl-tls-protocol-initialization-vector-implementation-informatio
- https://forum.startcom.org/viewtopic.php?f=15&t=2469 （私のスレッド。まもなく更新します）
そして、SSLがなぜそうではないのかについての会話については https://www.vbulletin.com/forum/showthread.php/401411-Time-to-improve-the-site-security を見てください。最近は「SSLだけ」。