テスト環境
この記事で取り上げるテスト環境は、合計4台のマシンです：
- マシンA：m1.xlarge EC2US-West-2/Oregon での例
- マシンB：m1.xlarge EC2 EU-西/アイルランドでの例
- : Intel Core i7-2600K 3.4GHz
- マシンD：インテル Core i3-550 3.2GHz
一部のテストでは MySQL5.6.13-community を使用し、他のテストでは Percona Server5.6.13 を使用しました。
外部暗号化技術
このテストでは、本物のvpnを使わずに、つまりSSHチャンネルの宝庫を使わずに、最も一般的な方法でステーション間の接続を作成しました。MySQL/SSLが使用するデフォルトのSSL暗号化コンポーネントは、DHE-RSA-AES256-SHAです。少し説明すると、これは、ハッシュ関数としてSHA1アルゴリズムを使用し、認証にRSAを使用し、256ビットのAES暗号をDiffie-Hellman鍵交換。SSHバージョン2プロトコルはデフォルトでDHE/RSA/SHA1を使うので、チャンネルを確立するときにAES256-CBC暗号化方式を指定するだけでいいのです。興味本位で、SSH チャネルで CTR モードの AES256 も使ってみることにします。これはブロックを暗号化するので、理論的には少し速くなりますが、少なくともこのテストでは、最終的な結果は、違いはわずかです。
このテストに使用するマシンはマシンCとマシンDで、どちらも同じギガビットイーサネットVLANチェーン内にあります。 テストスクリプトはパート1のスクリプトと同様で、目標は100個の接続を可能な限り高速に作成することです。各テスト構成は 10 回実行され、以下の表は平均値と標準偏差の一覧です。また、この特定のテストでは、すべてのキーの長さは4096ビットであり、すべてのテストはPercona Server 5.6.13で実行されたことに注意してください。
また、図表がお好きな方は、こちらをご覧ください。
暗号化しないのが最速であることは明らかですが、MySQL ネイティブ SSL アプローチと比較して、SSH トンネルを介して接続を作成する場合のパフォーマンス損失はそれほど多くありません。100cpsまたは22cpsのいずれかが非現実的ですが、ほとんどの人にとって、470-480cpsの数を生成する各個別スレッドはまだ使用可能であると推測します。
高遅延リンクでの接続性能
テストデータは記事の後半で紹介します。SSL接続の安定性はネットワーク遅延の影響を受けるという事実です。 上の結果からわかるように、SSLの使用は低遅延リンクでのパフォーマンスに大きな影響を与えます。あるケースでは、ネットワークの単純な往復時間のレイテンシを考えると、MySQLの組み込みSSLサポートを使用しても、ハイブリッド暗号化はパフォーマンスにあまり影響を与えない可能性があります。 そこでこのテストでは、2つの異なるAmazon EC2インスタンスを分割しました。 北カリフォルニアにあるアプライアンスCをクライアントとして使用し、MySQLクラスタとPerconaサーバでテストを実行しました。 SSL暗号コンポーネントはデフォルト設定で使用し、テストスクリプトは前回と同様に10回実行しました。もちろん、生データはテストの二次的なもので、ネットワークの遅延がSSLのパフォーマンスにどのように影響するかを確認するためだけのものです。
まず、CからBへ。
そしてCからAへ。
rtt min/avg/max/mdev = 42.543/44.648/59.994/3.194 ms
予想通り、テストデータは、地理的に少なくとも数百メートル離れた大陸を越えたサーバに接続するよりもはるかに低いことは明らかですが、MySQL クラスタの反応を除外すると、実際にはそれほどパフォーマンスが低下していないことがわかります。下の表は、C から B への接続と C から A への接続を比較したものです。
以下はいくつかの考察です。第一に、1024ビットのSSL暗号化は、サーバーが40msまたは170ms離れている場合、パフォーマンスにあまり影響を与えません。第二に、待ち時間が長くなると、SSL暗号化のオーバーヘッドが増加するため、失われた接続が影響を受けます。 これは、特にSSLが使用されているかどうかによって接続のスループット性能が大きく影響される一般的なシナリオでは理にかなっています。 もちろん、MySQL クラスタと Percona サーバの 4096 ビット暗号化の価格は、上記のすべてを無意味なものにします。MySQL Cluster 4096 ビット暗号化のパフォーマンスを向上させるために使用される特別なツールがいくつかありますが、Percona Server ではあまり影響がないようです。どちらのテストでもPEBCATだと言えたので、もし他の人もテストしているのであれば、同じ構造になっているかどうか知りたいと思っています。
最終的な感想
MySQL 5.6.13と4096ビットSSLの問題はともかく、この記事が追いかけていること、そして前任者が言っていることは非常に明確だと思います。エンドツーエンドで暗号化されたMySQL転送が必要な場合、レプリケーションやコネクションプーリングを使用する作業量であれば、MySQLの内蔵SSLサポートでおそらく十分ですが、アプリケーションは大量の接続を作成および破棄する必要があり、SSH経由のトンネリングだけで暗号化の負荷を軽減できます。しかし、アプリケーションは多くのコネクションを作成したり破棄したりする必要があります。
