こんにちは、CRE部 技術支援チームです。
皆さんは、データベース（以下DB）を利用する際、何らかの理由で負荷が高まりサーバーのレスポンスが遅くなった経験がありませんか？
このような時、キャッシュサーバーを有効に活用することで、DBサーバーの負荷低減やリクエストへのレスポンス時間の改善ができるかもしれません。
今回はキャッシュサーバーとして利用できる代表的なオープンソースのインメモリーDBであるRedisのクラスター構成を試してみます。
Redisはデータを全てメモリー内に持つため、非常に高速なパフォーマンスを実現できます。データベースのキャッシュの他、中間処理を行うためのデータストア、セッション情報などの一時的なデータの保存場所としての活用が可能です。
本記事ではサーバータイプによってRedisの処理性能がどのように変わるのか、Redis1台のみの構成とRedis clusterの構成をそれぞれ準備してベンチマークを実施しました。
構成イメージ
前提条件
本記事は、以下の前提知識がある方を想定しています。
- ニフクラの基本的なコントロールパネルの操作、サービスを利用に関する知識
- Linuxの基本的な操作、設定に関する知識
利用リソース
east-11にプライベートLANを作成し、サーバーを7台作成します。
| リソース | 数量 |
|---|---|
| プライベートLAN | 1 |
| サーバー（サーバーOS：Rocky linux 8.6） | 7 |
環境構築
構築条件
| 項目 | 内容 |
|---|---|
| 利用ゾーン | east-11 |
| redisバージョン | 6.0.16 |
| 性能計測ツール | memtier_benchmark (ver1.3.0 ) |
1.プライベートLANの作成
Redisのサーバー間通信の経路として、プライベートLANを作成します。
本検証ではプライベートLANに付与するIPアドレス帯を「192.168.1.0/24」としています。
作成方法の詳細は以下をご参照ください。
クラウドヘルプ（プライベートLAN：作成）
2.仮想サーバーの作成
各サーバーのホスト名と役割は以下の通りです。
| ホスト名 | 役割 | プライベートIP |
|---|---|---|
| redis01 | Redis (master) | 192.168.1.2 |
| redis02 | Redis (master) | 192.168.1.3 |
| redis03 | Redis (master) | 192.168.1.4 |
| redis04 | Redis (slave) | 192.168.1.5 |
| redis05 | Redis (slave) | 192.168.1.6 |
| redis06 | Redis (slave) | 192.168.1.7 |
| redisstress | ベンチマーク実行サーバー | 192.168.1.8 |
| redisstress2 | ベンチマーク実行サーバー | 192.168.1.9 |
サーバーに適用するファイアウォールについては以下のように作業端末のグローバルIPアドレスのみを許可しています。
ファイアウォール設定
| プロトコル | ポート | 接続元 | 用途 |
|---|---|---|---|
| TCP | 22 | 作業端末のグローバルIPアドレス | SSH接続 |
作成方法の詳細は以下をご参照ください。
クラウドヘルプ（サーバーの作成）
クラウドヘルプ（ファイアウォールグループの新規作成）
3.Redisサーバーの準備
redis01～06の各サーバーでRedisのインストール、設定を行います。
今回はRedis Clusterの最小構成である3台のmasterのそれぞれにslaveを1台ずつ追加した計6台の構成にしています。
クラスター構成の設定方法の詳細は公式のドキュメントをご参照ください。
4.ベンチマーク実行サーバーの準備
Redisに付属している redis-benchmark はクラスター構成のベンチマークに対応していないため、今回は memtier_benchmark を使用します。
memtier_benchmarkはRedis clusterにも対応したベンチマークツールです。
ツールの詳細やインストール手順等はgithubのREADMEをご参照ください。
計測条件
下記の表にあるようにシングル構成、クラスター構成のそれぞれでサーバータイプを都度変更してベンチマークを実行します。
Redisサーバー
| 項目 | 内容 |
|---|---|
| サーバータイプ | h2-small2、h2-medium、h2-large、h2-xlarge8、h2-wlarge16 |
| 構成 | シングル構成、クラスター構成(master 3台、slave 3台 の計6台構成) |
| io-threads | サーバタイプごとに以下の値を指定h2-small2：1h2-medium：1h2-large：3h2-xlarge8：5h2-wlarge16：7 |
※ 上記に記載のないオプションは、デフォルトのまま計測しています。
※ io-threadsの値はredis.conf内の以下のコメントに沿って設定しています。
# By default threading is disabled, we suggest enabling it only in machines # that have at least 4 or more cores, leaving at least one spare core.
ベンチマーク実行サーバー
| 項目 | 内容 |
|---|---|
| サーバータイプ | h2-tlarge32 |
memtier_benchmarkは以下のパラメータを指定し、2台のベンチマーク実行サーバーで同時に実行します。
- シングル構成
memtier_benchmark -s 192.168.1.2 -p 6379 -t 12 -c 10 -R --ratio=1:10 -d 32 --test-time=120
- クラスター構成
--cluster-mode のオプションを付けることでクラスター構成のベンチマークが実行できます。
ベンチマークツールの都合で読み込みのリクエストもmasterで実行されます。
memtier_benchmark -s 192.168.1.2 -p 6379 --cluster-mode -t 12 -c 10 -R --ratio=1:10 -d 32 --test-time=120
それぞれのパターンで3回ずつ計測し、出力されたOps/sec のTotalsの値の平均値を取得します。 2台のベンチマーク実行サーバーで取得した値の合計を結果として採用します。
ベンチマーク結果
シングル構成
シングル構成でのベンチマーク結果は以下のグラフの通りになりました。
- CPUのコア数が増えるに従って性能は向上しているが、上昇幅は少ない。
- h2-small2とh2-wlarge16の比較で、CPUコア数は1から8に増えているが処理性能は167％程度に留まっている。
クラスター構成
クラスター構成でのベンチマーク結果は以下のグラフの通りになりました。
比較のためにシングル構成での結果も含めたグラフにしています。
- クラスター構成でもシングル構成と同様の傾向で性能が向上した。
- 計測したすべてのサーバータイプでシングル構成と比較してクラスター構成の性能が上回り、273～317％の性能となった。
- クラスター構成はh2-small2であっても、シングル構成のh2-wlarge16の189%程度の性能となった。
まとめ
今回はRedis clusterの性能をシングル構成の場合と比較し、Redis clusterで高い性能が発揮できることが確認できました。Redis clusterを利用することで可用性の向上だけでなく、性能向上も期待できそうです。
どちらの構成でもCPUコア数の増加に伴う処理性能の向上は緩やかであるため、CPUよりもメモリサイズでサーバータイプを選択すればよさそうです。
クラウド環境であればサーバーのスペックや台数を容易に変更できるので、必要な構成やキャッシュのサイズに応じてサーバーを素早く用意することができます。
Redisを利用するときのサーバータイプや構成の検討の一助になれば幸いです。
注意事項
- 本記事ではOS上の操作についても記載していますが、ニフクラではOS以上はご利用者様の責任範囲となりますのでご留意ください。
- 本記事については検証結果の一つとなります。実際に構成を検討されるときは、それぞれの要件を鑑みて十分に検証を実施してください。
- 本記事の他社サイトへのリンクにつきまして、リンク切れの際はご容赦ください。
- 本記事で記載した各サービス/ニフクラの機能等は、2022年10月時点の情報です。利用時には各サービス/ニフクラの機能の最新情報をご確認いただきご利用ください。
