まめ畑

ゆるゆると書いていきます

ElastiCacheとELBとtwemproxy その2

AWS memcache redis

以前、
http://d.conma.me/entry/2013/01/22/195331
のエントリで、Internal ELB + twemproxy + ElastiCacheの構成で、スループットが劇的に低下してしまう問題について書きましたが、その後色々と調査をしてみました。


Internal ELBのウォームアップを行い、都度コネクションを切っていたものを接続したままにし、コマンドを送信するように変更してみました。
しかし、結果は前回の結果と同様のものとなりました。
他にも色々とtwemproxyやカーネルパラメータなどの調整を行なってみたのですが、劇的な効果はありませんでした。

Internal ELB の代わりにhaproxyを使用してパフォーマンスを測定してみました。
条件は、haproxy * 1 / twemprxoy * 4 / ElastiCasche(large) * 4 の構成で、その他の条件は前回と同様です。
結果は、約26,928 commands/sec となりました。
twemproxy + ElastiCache の構成と比較して2分の1程度の速度になりましたが、Internal ELBを使用した場合と比較して5倍程高速です。


以前、DBとInternal ELBの構成でパフォーマンスを測定した際も、DB単体では6,000qps程でたのですが、Internal ELBを挟んだところ4,000qps程で頭打ちになったため、大体こあたりの数値がウォームアップ申請などを行なって性能向上させていないInternal ELBの限界ではないかと思っています。

インスタンス1台あたり4,000rpsなどの制限が無いか確認するため複数インスタンスから同様に負荷をかけてみましたが、負荷を掛けるノードの数に応じて1台あたりのレスポンス速度が低下したためInternal ELBそのもの性能の用です。
また、twemproxy自体の性能かどうかを確認するために、haproxy経由で複数ノードから負荷をかけてみましたが、そちらは1台あたりの速度は低下しなかったため、twemproxyとElastiCacheの性能上限というわけでもありませんでした。


AWSのNWの性能に関しては完全に公開されていないため、新しいミドルウェアや構成などを使う場合、最低でも予測ピーク負荷をかけて各サービスなどがどのくらいの性能が出るかなどを確認することが重要です。
また、AWSのサービスはスケールに応じてIPアドレスの追加・変更があるためドメインでアクセスを行うのですが、膨大な数のサーバや大量のリクエスト毎にDNSへの問い合わせを行うと、DNSへのクエリでアプリケーションの性能劣化も観測されたため、ある程度のキャッシュの必要がありますが、このキャッシュが長いとIPアドレスの変更などが行われた際に、アクセスができなくなるため、DNSレスポンスのキャッシュ期間の調整やIP変更を検知してキャシュをクリアするという方法が必要です。(haproxyだとreloadとか)