このサービスは、Memcachedと互換性のあるプロトコルです。
それがどのように機能し、Web開発者とシステム管理者にとって実用的な価値があるかどうかを見てみましょう。
開始するには、AWS管理インターフェイスでElastiCacheアイテムを選択し、支払いを行う銀行カードの詳細を指定する必要があります。
その後、起動自体に進むことができます。
ご注意 -現在、このサービスは米国東部(バージニア州)の5つの地域のいずれかでのみご利用いただけます。
ElastiCacheの重要な概念はキャッシュクラスターです。
クラスター内で、必要な数のノードを(手動または自動で)開始できます。
新しいクラスターを開始して、そのパラメーターを設定します。
重要なポイント:
- ノードタイプ -クラスター内の各ノードの物理特性(RAM、CPU)。 単一のクラスターでは、すべてのノードが必ず同じ構成になります! それらの数のみが異なります。
- エンジン -実際、これはmemcachedとのプロトコル互換性だけでなく、memcached自体です。 おそらく、将来的には他のオプションがいくつかあるでしょう。
次に、 セキュリティグループとキャッシュパラメータグループを設定します。
キャッシュパラメータグループはこれまでのところ(?)ユニークで、これまでのところ(?)は構成できません。
セキュリティグループの設定についてもう少し詳しく説明します。
グループ設定は、EC2のセキュリティグループの名前(キャッシュクラスターのノードにアクセスする仮想マシン)を示します。
AWSアカウントID。
いくつかの「微妙な」ポイント:
- EC2 Security Groupは、sg- *というフォームの識別子ではなく、グループの名前を指定します(私自身は最初に考えました)。 誤ったデータを指定すると、ほとんどの場合、わかりやすいエラーメッセージさえありません。
グループの名前を多かれ少なかれ明示的に指定する必要があるという事実は、 APIの説明からのみ続きます 。
elasticache.us-east-1.amazonaws.com
?Action=AuthorizeCacheSecurityGroupIngress
& EC2SecurityGroupName =default
&CacheSecurityGroupName=mygroup
&EC2SecurityGroupOwnerId=1234-5678-1234
&Version=2011-07-15
&SignatureVersion=2
&SignatureMethod=HmacSHA256
&Timestamp=2011-02-12T01%3A29%3A15.746Z
&AWSAccessKeyId=YOUR-ACCESS-KEY
&Signature=YOUR-SIGNATURE
- すべてのファイアウォール管理はEC2セキュリティグループレベルで実行されるため、任意のネットワークからAmazon ElastiCacheへのアクセスを開くことはできません。 つまり、他のAmazonサービス(一般的にはEC2)からのみこのサービスを操作できます。
- EC2セキュリティグループだけでなく、AWSアカウントIDも示されているため、別のアカウントからアクセスすることができます。
その結果、すべての設定が行われた後、必要な数のキャッシュクラスターノードが起動されます(1つのノードで実験しました)。 各ノードに対して、EndPointが定義されています-アプリケーションのアクセス先となるhost:portのペアのみです。
* * *
実地試験に合格しました! :)
実験のために、2つのCMSを取りました。最も人気のあるコマーシャル-1C -Bitrixと、最も人気のあるオープンソース-Joomla (人気に関するデータ-iTrackの評価による )です。
ビトリックス
memcacheをキャッシュのストレージとして使用するには、次の2つのオプションを使用できます。
1.構成ファイルdbconn.phpで指定します。
define("BX_CACHE_TYPE", "memcache");
define("BX_MEMCACHE_HOST", "testcache.lfffta.0001.use1.cache.amazonaws.com");
define("BX_MEMCACHE_PORT", "11211");
2.または(「Web Cluster」および「Business Web Cluster」の古いエディションのみ)製品設定の管理インターフェースで、必要な数のmemcachedサーバーを指定します(さらに、この方法では、任意の数のサーバーを指定でき、分散キャッシュを使用できるようにします):
EC2(小規模)仮想マシンでのテストでは、「1C-Bitrix」10.0のデモバージョンが、配布キット(「オンラインストア」)からの典型的なコンテンツとともにインストールされました。 マシンは、ネットワークへの影響を最小限に抑えるために、キャッシュクラスターが立ち上げられているのと同じAZ(可用性ゾーン)に展開されます。
大規模な詳細なテストは必要なく、Amazon ElastiCacheを使用する場合にのみプロジェクトの速度を評価するため、負荷テストに本格的なツール(tsungやJMeterなど)は使用しませんでしたが、単純なabに限定しました。
2つのスレッドで500件のリクエストを作成します(すぐにテストを数回実行して平均値を取得したと言います)。
誰かがテスト方法論についてコメントするかもしれません。 繰り返しますが、2つのことだけを比較します。AmazonElastiCacheを使用しないサイトの作業と、それを使用したサイトの作業です。 絶対数は面白くなく、相対データのみです。
# ab -n 500 -c 2 ec2-xx-xx-xx-0.compute-1.amazonaws.com
最初のテスト-標準キャッシュ(ディスク-EC2仮想マシンのファイルシステム)を使用します。
ドキュメントパス:/ ドキュメントの長さ:25910バイト 同時実行レベル:2 テストにかかった時間:53.748秒 完全なリクエスト:500 失敗したリクエスト:0 書き込みエラー:0 転送された合計:13324000バイト 転送されるHTML:12955000バイト 1秒あたりのリクエスト:9.30 [#/秒](平均) リクエストあたりの時間:214.993 [ms](平均) リクエストあたりの時間:107.497 [ms](平均、すべての同時リクエスト全体) 転送速度:242.09 [キロバイト/秒]受信 接続時間(ミリ秒) 最小平均[+/- sd]最大中央値 接続:0 0 0.8 0 19 処理:51215 313.9 197 5090 待機中:51215 313.9 196 5090 合計:51215 313.9 197 5090
9.3リクエスト/秒
ElastiCacheを接続し、新しいテストを実行します。
同時実行レベル:2 テストにかかった時間:67.987秒 完全なリクエスト:500 失敗したリクエスト:0 書き込みエラー:0 転送された合計:13323973バイト 転送されるHTML:12954973バイト 1秒あたりのリクエスト:7.35 [#/秒](平均) リクエストあたりの時間:271.947 [ms](平均) リクエストあたりの時間:135.973 [ms](平均、すべての同時リクエスト全体) 転送速度:191.39 [Kバイト/秒]受信 接続時間(ミリ秒) 最小平均[+/- sd]最大中央値 接続:0 0 0.0 0 0 処理:114 272 101.1 279 1293 待機中:114 272 101.1 279 1293 合計:114272 101.1 279 1293
1秒あたり7.35リクエスト
遅い!
ローカルディスクキャッシュは、memcachedよりも効率的に機能します。memcachedでは、TCP / IPを介して「通信」します。 (同じマシン上でローカルに発生したmemcachedも高速に動作することをすぐに個別に説明します。)
* * *
ジュムラを見てみましょう
テストの条件は似ています-Joomla 1.7をEC2仮想マシン(同じAZにある小さな)に典型的なデモコンテンツとともに配置します。
テストを実行します-同じab:
同時実行レベル:2 テストにかかった時間:107.028秒 完全なリクエスト:500 失敗したリクエスト:0 書き込みエラー:0 転送された合計:8247000バイト 転送されるHTML:8068000バイト 1秒あたりのリクエスト:4.67 [#/秒](平均) リクエストあたりの時間:428.110 [ms](平均) リクエストあたりの時間:214.055 [ms](平均、すべての同時リクエスト全体) 転送速度:75.25 [キロバイト/秒]受信 接続時間(ミリ秒) 最小平均[+/- sd]最大中央値 接続:0 0 0.0 0 0 処理:159 428 797.5 388 17777 待機中:159 428 797.5 388 17777 合計:159 428 797.5 388 17777
1秒あたり4.67リクエスト
なんとなく...
管理パネルを開いて、デフォルトでキャッシュがオフになっていることを確認します。
あなたはそれを有効にすることができます、2つのモードがあります-保守的とプログレッシブ。
標準ストレージであるファイルシステムを使用します。 最初のケースでは、 1秒あたり6.6クエリが取得され、2番目では7.2 が取得されます。
同時実行レベル:2 テストにかかった時間:69.440秒 完全なリクエスト:500 失敗したリクエスト:0 書き込みエラー:0 転送された合計:8036000バイト 転送されるHTML:7857000バイト 1秒あたりのリクエスト:7.20 [#/秒](平均) リクエストあたりの時間:277.761 [ms](平均) リクエストあたりの時間:138.880 [ms](平均、すべての同時リクエスト全体) 転送速度:113.01 [Kバイト/秒]受信 接続時間(ミリ秒) 最小平均[+/- sd]最大中央値 接続:0 0 0.7 0 17 処理:123 277 72.3 267 852 待機中:123 277 72.4 267 852 合計:123277 72.3 267852
memcacheストレージに接続します。
一般的に、Joomla開発者が計画したとおり、これは管理インターフェイスを介して実行できます。
ただし、原則としてmemcacheを使用する機能は、次のコードで確認されます。
public static function test()
{
if ((extension_loaded('memcache') && class_exists('Memcache')) != true ) {
return false;
}
$config = JFactory::getConfig();
$host = $config->get('memcache_server_host', 'localhost');
$port = $config->get('memcache_server_port', 11211);
$memcache = new Memcache;
$memcachetest = @$memcache->connect($host, $port);
if (!$memcachetest) {
return false;
} else {
return true;
}
}
テスト関数がfalseを返した場合、memcacheは原則としてストレージを選択するメニューに表示されません。
つまり、接続パラメーターを最初に示すために、configuration.php構成ファイルにパラメーターを明示的に登録するか、「デフォルト」のmemcached(localhost:11211)を実行する必要があります。
configuration.phpで指定します。
public $memcache_persist = '1';
public $memcache_compress = '0';
public $memcache_server_host = 'testcache.lfffta.0001.use1.cache.amazonaws.com';
public $memcache_server_port = '11211';
テスト:
同時実行レベル:2 テストにかかった時間:140.928秒 完全なリクエスト:500 失敗したリクエスト:3 (接続:0、受信:0、長さ:3、例外:0) 書き込みエラー:0 2xx以外の応答:3 転送された合計:8002436バイト 転送されるHTML:7823370バイト 1秒あたりのリクエスト:3.55 [#/ sec](平均) リクエストあたりの時間:563.712 [ms](平均) リクエストあたりの時間:281.856 [ms](平均、すべての同時リクエスト全体) 転送速度:55.45 [Kバイト/秒]受信 接続時間(ミリ秒) 最小平均[+/- sd]最大中央値 接続:0 0 0.0 0 0 処理:142563 397.1 461 3942 待機中:142563 397.1 460 3942 合計:142564 397.1 461 3942
3.55お問い合わせ
予想-遅い。 :(
しかし、予想外に-キャッシュをまったく使用しない場合よりもさらに遅くなります。 :(
最後に、より強力なキャッシュノードを使用して、テスト用に別のキャッシュクラスターを取得しようとしたことをすぐに言わなければなりません。 「テストサンプル」と比較して、パフォーマンスがわずかに向上しました。
* * *
要約する
要するに-中規模のプロジェクト(大半)の場合、現時点ではAmazon ElastiCacheはあまり意味がありません... :(
- 構成-同じ(または別の)インスタンスでローカルmemcachedをセットアップする場合と同等(より複雑でない場合)。
- 価格-EC2に相当(小さなElastiCache 1.3 GB-1時間あたり0.095ドル、小さなEC2 1.7 GB-1時間あたり0.085ドル)。
- 他のAWSサービスでのみ使用できます。
- キャッシュクラスタ全体ではなくノードごとに個別のエンドポイントを使用すると、スケーラビリティなどを使用できます。 複数のmemcachedサーバーに接続できる製品でのみ(たとえば、同じ1C-Bitrix Webクラスターで)。
どのような場合にElastiCacheを使用することが可能であり、必要であり、有用であるか:
- 巨大な(そして-重要-上下にスケーラブルな)キャッシュが必要な大規模プロジェクト。 ElastiCacheでは、自動スケーリングの特定のルールを設定することにより、CloudWatchで非常に多数の異なるメトリック(送信データとヒットの数からCPU使用率、使用済み/未使用メモリの量まで)を使用できます。
- キャッシュサーバーの可用性が重要なプロジェクト(ElastiCacheはキャッシュクラスターノードの状態を監視し、問題が発生した場合にそれらを自動的に復元します)。
一般的に言えば、もちろんAmazonは正しい方向に向かっており、ますます多くのクラウドサービスを提供しています。 ユーザーの選択肢が多いほど良い。
まあ、ElastiCacheを使えば、時間が経つにつれて、より速く、より安価に作業できるようになることを願っています。