Posted inUbuntu

Ubuntu 24.04におけるRedis Serverのインストールと最適化ガイド：インメモリキャッシュとセキュリティ設定

Ubuntu tutorial - IT technology blog
Ubuntu tutorial - IT technology blog

トラフィックが毎分数万リクエストに達すると、PostgreSQLやMySQLなどのリレーショナルデータベースが最初のボトルネックになりがちです。複雑なJOINクエリでは、応答に50msから200msほどかかることもあります。アプリケーションとデータベースの間にインメモリキャッシュ層を導入することで、この課題を解決できます。読み書きのレイテンシがわずか0.5ms〜2ms程度であるRedisは、現在最も広く採用されている選択肢です。

UbuntuにおけるRedisデプロイ方式の比較

設定作業に入る前に、インフラ環境に適したインストール方式を選択する必要があります。Ubuntu 24.04 LTS（Noble Numbat）では、主に以下の3つのアプローチがあります。

  • APTによるネイティブインストール（Native Service）：Redis公式パッケージを使用し、プロセスマネージャーとしてsystemdを利用します。
  • Dockerコンテナでの実行：独立したサービスとしてコンテナ化し、Docker EngineやDocker Composeで管理します。
  • ソースコードからのコンパイル（Build from source）：公式サイトからtarballをダウンロードし、gccやmakeを用いてビルドします。

各方式のメリット・デメリット分析

以下は、3つのデプロイ方式を比較した表です。

評価項目 ネイティブAPT（推奨） Dockerコンテナ ソースからのコンパイル
パフォーマンスとリソース 最高。コンテナエンジンのメモリ消費がなく、メモリバスI/Oに直接アクセス可能。 host networkを設定しない場合、bridgeネットワークのオーバーヘッドでレイテンシが約5〜10%増加。 CPUアーキテクチャに応じた最適化フラグを有効化できるため、パフォーマンスは極めて高い。
保守とアップデート 極めて容易。apt upgrade redis-serverコマンドひとつでバージョン更新が可能。 イメージタグの管理、データボリューム、付随するDockerデーモンの管理が必要。 煩雑。パッチ適用のたびに最新ソースの取得、リビルド、手動設定が必要。
プロセス管理 systemdおよびjournaldと標準で緊密に統合。 Dockerデーモンのリスタートポリシーに依存。 redis.serviceのユニットファイルを自前でゼロから作成する必要がある。

サーバー環境にはどの方式を選ぶべきか？

Kubernetes上で分散マイクロサービスアーキテクチャを運用している場合は、Dockerを利用するのが合理的です。一方で、モノリスアプリケーション（Laravel、Node.js、Djangoなど）をホストする単一のVPSを運用している場合や、専用のキャッシュサーバーを構築する場合は、ネイティブAPTの選択を推奨します。

この方式であれば、サーバーのRAMを最大限に活用できます。Dockerデーモンによる150〜200MB程度のメモリオーバーヘッドを気にする必要もありません。また、systemctlによるサービス監視や運用も非常にシンプルになります。

Ubuntu 24.04でのRedisインストールと設定手順

ここでは、本番環境で安全に運用できるRedis Serverを構築するための6つのステップを解説します。

ステップ1：Redis.io公式リポジトリからのインストール

Ubuntu 24.04の標準リポジトリで提供されるパッケージは、バージョンが固定されていることが一般的です。最新のバグ修正やパフォーマンス改善を取り入れるため、Redis.ioの公式リポジトリから取得することをおすすめします。

# リポジトリの取得と検証に必要なツールのインストール
sudo apt update
sudo apt install -y lsb-release curl gpg

# Redis GPGキーをダウンロードしてシステムに追加
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg

# Redis公式リポジトリの登録
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list

# パッケージリストの更新とインストール
sudo apt update
sudo apt install -y redis-server

ステップ2：メモリ上限とデータ退避ポリシー（Eviction Policy）の設定

デフォルト設定では、Redisにはメモリ使用量の上限が設定されていません。メモリが枯渇すると、LinuxのOOM（Out-Of-Memory）Killerがサーバー上で最もメモリを消費しているプロセス（通常はMySQLやRedis自身）を強制終了してしまいます。

設定ファイルを開きます。

sudo nano /etc/redis/redis.conf

次の2つのパラメータを探して設定します（例として4GB RAMのVPSでRedisに2GBを割り当てる場合）：

# Redisが使用可能な最大メモリ容量を制限
maxmemory 2gb

# メモリ上限到達時のデータ退避ポリシー
maxmemory-policy allkeys-lru

純粋なキャッシュ層としてRedisを利用する場合、allkeys-lruが最も適した選択肢です。このアルゴリズムは、新しいキーを格納するために直近で最も参照されていないキーを自動的に削除します。セッション情報やログイン認証トークンなど、誤って削除されたくないデータを同居させる場合は、TTL（有効期限）が設定されたキーのみを退避対象とするvolatile-lruへの変更を検討してください。

ステップ3：接続ポートのセキュリティ強化

KinsingやRedigoなどのボットネットは、オープンなRedisインスタンスを探してroot権限を奪取するために、インターネット上のポート6379を常時スキャンしています。以下の2つの設定は必須です。

  1. ローカルホスト（または内部プライベートIP）のみでリッスンする：

    /etc/redis/redis.confのbind設定を確認し、0.0.0.0ですべてのインターフェースに対して公開されていないことを確実にします。

    bind 127.0.0.1 -::1
protected-mode yes
  2. 認証パスワード（Requirepass）の設定：

    requirepass行のコメントアウト#を解除し、30文字以上の推測されにくいランダムなパスワード文字列を設定します。

    requirepass c8F29aKx91LmP30qWs7TvYbRtU4VnZ5e!

ステップ4：Redis向けのLinuxカーネルチューニング

Redisがfork()機構を利用してディスクにスナップショットを保存する際、子プロセスは親プロセスと同等の仮想メモリ割り当てを要求します。利用可能な空きRAMが不足していると、この処理は失敗します。ログに表示される警告を解消するため、vm.overcommit_memory = 1を有効化します。

# 稼働中のカーネルに即座に設定を反映
sudo sysctl vm.overcommit_memory=1

# サーバー再起動後も設定を維持するため設定ファイルへ追記
echo 'vm.overcommit_memory = 1' | sudo tee -a /etc/sysctl.conf

ステップ5：変更の反映と自動起動の有効化

設定ファイルを編集した後は、新しい設定値を適用するためにサービスを再起動する必要があります。

# Redisサービスの再起動
sudo systemctl restart redis-server

# OS起動時の自動起動を有効化
sudo systemctl enable redis-server

# サービス状態の確認
sudo systemctl status redis-server

画面上に緑色でActive: active (running)と稼働時間が表示されていれば、サービスは正常に起動しています。

ステップ6：Redis CLIでの接続およびセキュリティ確認

ターミナルを開き、CLIからの応答を確認してパスワード認証が正しく機能しているかをテストします。

redis-cli

アクセス権限の検証およびサンプルのデータ書き込み・読み出し手順：

# 認証前にpingコマンドを送信
127.0.0.1:6379> ping
(error) NOAUTH Authentication required.

# 設定したパスワードで認証
127.0.0.1:6379> auth c8F29aKx91LmP30qWs7TvYbRtU4VnZ5e!
OK

# テストキーの書き込みと読み出し
127.0.0.1:6379> set user:1001 "山田太郎"
OK
127.0.0.1:6379> get user:1001
"山田太郎"

# redis-cliの終了
127.0.0.1:6379> exit

よくあるトラブルシューティング

再起動コマンドでエラーが発生した場合は、原因を推測するのではなく、systemdのリアルタイムログを確認して詳細なエラーメッセージを特定しましょう。

sudo journalctl -u redis-server -e --no-pager

特によく見られるトラブルの主な原因は以下の通りです。

  • /etc/redis/redis.conf内の構文ミスや不要な空白文字の混入。
  • ポート6379が別のプロセス（または停止していない古いRedisコンテナなど）によって既に使用されている。
  • データディレクトリ/var/lib/redisの所有権がredisユーザーではなくrootに変更されてしまっている。

以上の手順を正確に実施することで、スムーズに動作し、メモリを安全に自動解放しながら、不正なポートスキャン攻撃から堅牢に保護された本番仕様のRedis Serverが完成します。

Share:
Tags: