Docker で Redis をデプロイする完全ガイド：永続化とパスワード認証でデータ消失を防ぐ

ようやく Redis コンテナを起動できた。いくつか API を試して、読み書きも問題なし。翌日 PC を開いてサービスを確認したら——データがすべて消えていた。心が冷え切りました。

Docker コンテナを再起動しただけで、Redis の中身が最初からなかったかのようになること、ありませんか。ログイン状態、カート、キャッシュが一気に消える。さらに厄介なのは、原因も対策も分からないことです。

初めてこの問題に当たったとき、私もかなり慌てました。小規模プロジェクトの検証環境でデータが突然消え、本番には影響しませんでしたが、無力感は今でも覚えています。後から分かったのですが、コンテナは本質的に「一時的」——削除すればデータは消え、永続化を設定していなければ再起動でも同じです。

本記事では、次を手順どおりに解説します。

• RDB と AOF 永続化：コンテナ再起動でもデータを残す
• パスワード認証：未認証アクセスやマイニング被害を防ぐ
• 設定ファイルのマウント：運用しやすい本番構成にする
• 本番のベストプラクティス：ログ、ヘルスチェック、性能チューニングなど

バックエンド開発、運用エンジニア、Docker 初心者のどなたでも、この記事どおりに進めれば 本番レベルの Redis コンテナ を構築できます。

なぜ Redis コンテナはデータを失うのか？

例えるなら、Docker コンテナはホテルの部屋です。チェックアウトすれば中身は片付けられます。コンテナも同様で、削除すれば中のデータは消えます。

Redis はデフォルトでコンテナ内のファイルシステムに保存します。/data/dump.rdb や /data/appendonly.aof などです。問題は、これらが コンテナ内部 にあることです。コンテナが削除・再作成されると、データも一緒に消えます。

実例：あるスタートアップが検証環境で永続化なしの Redis Docker を使い、サーバー再起動後にセッションがすべて消失。検証環境でも、コンテナ化ではデータ永続化が必須 と痛感しました。

統計では、Redis コンテナのデータ消失の約 70% は永続化未設定が原因です。ほぼ誰もが一度は踏む落とし穴です。

Docker Volume の役割

Volume（データボリューム）が鍵です。重要ファイルをクラウドに置くイメージで、ホストに保存します。

-v でホストディレクトリをマウントすると、データはホスト側に残ります。コンテナを削除してもデータは残り、再起動後も読み込めます。本番では Volume マウントが必須 です。

要約すると：

• Volume なし = データはコンテナ内 = 削除で消失
• Volume あり = データはホスト = コンテナ削除後も残る

基本の Redis コンテナをすばやくデプロイ

永続化の前に、最もシンプルな Redis コンテナを立ち上げ、永続化なしの状態を体感しましょう。

基本コンテナの起動

ターミナルで次を実行します。

docker run -d --name redis-basic -p 6379:6379 redis:latest

意味は次のとおりです。

• -d：バックグラウンド実行
• --name redis-basic：管理しやすい名前
• -p 6379:6379：コンテナ 6379 をホスト 6379 にマッピング
• redis:latest：最新 Redis イメージ

ローカルにイメージがなければ自動取得し、コンテナが起動します。

コンテナの動作確認

docker ps

redis-basic が Up なら正常です。コンテナに入り、読み書きを試します。

docker exec -it redis-basic redis-cli

set test "hello"
get test

"hello" が返れば Redis は動作しています。

この基本構成の問題点

一見問題なさそうですが、次の 3 点が致命的です。

1. 永続化なし：再起動でデータ消失
2. パスワードなし：誰でも接続・読み書き可能
3. デフォルト設定のみ：メモリ上限や永続化方針をカスタムできない

再起動して確認してみましょう。

docker restart redis-basic
docker exec -it redis-basic redis-cli
get test

多くの場合、先ほどの test キーは消えています。永続化未設定の典型例です。

RDB 永続化（スナップショット方式）

Redis の永続化は RDB と AOF の 2 種類。まずはシンプルな RDB からです。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

RDB とは？

RDB（Redis Database）はメモリデータのスナップショットです。一定間隔で全データを dump.rdb に保存します。

復旧は速い が、最後のスナップショット以降のデータは失う 可能性があります。5 分ごとに保存なら、最悪 5 分分が失われます。

RDB の設定パラメータ

save で制御します。形式は次のとおりです。

save <秒数> <変更キー数>

例：

• save 900 1：900 秒（15 分）以内に 1 キー以上変更で保存
• save 300 10：300 秒（5 分）以内に 10 キー以上変更
• save 60 10000：60 秒以内に 10000 キー以上変更

いずれか 1 つを満たせばスナップショットが走ります。

Volume マウントで永続化を実現

RDB だけでは不十分で、ホストに Volume をマウントします。コンテナ削除後も dump.rdb がホストに残ります。

mkdir -p ~/redis-data

docker run -d \
  --name redis-rdb \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server --save 60 1 --dir /data

ポイント：

• -v ~/redis-data:/data：ホスト ~/redis-data をコンテナ /data にマウント
• --save 60 1：60 秒以内に 1 キー変更で保存（検証用。本番は間隔を長く）
• --dir /data：RDB の保存先

永続化の動作確認

docker exec -it redis-rdb redis-cli
set user:1 "张三"
set user:2 "李四"

60 秒待ってスナップショットを発火させ、コンテナを再起動します。

docker restart redis-rdb

docker exec -it redis-rdb redis-cli
get user:1

"张三" が返れば成功です。ホストの ~/redis-data に dump.rdb があるはずです。

AOF 永続化（追記ログ方式）

RDB は手軽ですが、最後のスナップショット以降のデータを失うリスクがあります。安全性を重視するなら AOF を使います。

AOF とは？

AOF（Append Only File）は書き込み操作だけを追記するログです。set、del、incr などのたびに appendonly.aof に記録します。

RDB が写真なら、AOF は録画に近いイメージです。RDB は定期的に 1 枚、AOF は操作をリアルタイムに記録します。

データ安全性は高い が、ファイルは RDB より大きく、復旧はやや遅いです。

AOF の 3 つの同期戦略

1. appendfsync always：毎回ディスクへ同期

   • 最も安全、ほぼデータロスなし
   • 性能は最低。高並行には不向き

2. appendfsync everysec：1 秒ごとに同期（推奨）

   • 性能と安全性のバランス
   • 最大 1 秒分のロス
   • 本番ではこちらを推奨

3. appendfsync no：OS に任せる

   • 性能は最高
   • ロスが大きくなりがち。非推奨

AOF 付き Redis の起動

mkdir -p ~/redis-data

docker run -d \
  --name redis-aof \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server --appendonly yes --appendfsync everysec --dir /data

主なパラメータ：

• --appendonly yes：AOF を有効化
• --appendfsync everysec：1 秒同期
• --dir /data：データディレクトリ

しばらくすると appendonly.aof ができます。

ls ~/redis-data/

混合永続化（Redis 4.0+ 推奨）

Redis 4.0 以降は 混合永続化 が推奨されます。RDB の速さと AOF の安全性を組み合わせます。

設定ファイルに次を追加します。

aof-use-rdb-preamble yes

再起動時は RDB スナップショットを先に読み込み（高速）、その後 AOF の差分を再生して完全性を確保します。

Redis 4.0 以上なら、RDB と AOF のどちらか一つに悩むより混合モードが無難です。

設定ファイルで Redis を管理する（本番推奨）

ここまでは --appendonly yes のようなコマンド引数で設定していました。パラメータが増えるとコマンドが長く、保守も難しくなります。

本番の定番は 設定ファイル です。

設定ファイルを使う理由

• 設定を一箇所に集約できる
• Git でバージョン管理しやすい
• チームで同じ設定を共有可能
• 変更時に長いコマンドを打ち直す必要がない

長期運用する Redis では、設定ファイルを使うのが現実的です。

標準設定ファイルの取得

公式の redis.conf をコンテナから取り出せます。

mkdir -p ~/redis-config
docker run --rm redis:latest cat /etc/redis/redis.conf > ~/redis-config/redis.conf

設定ファイルのカスタマイズ

~/redis-config/redis.conf を開き、次を調整します。

1. ネットワーク

# 全 IP から接続可（本番は社内 IP に限定推奨）
bind 0.0.0.0

# 保護モード無効（パスワード設定後は off 可）
protected-mode no

2. パスワード認証

requirepass YourStrongPassword123

3. 永続化

save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

aof-use-rdb-preamble yes

dir /data

4. 最大メモリ

maxmemory 512mb
maxmemory-policy allkeys-lru

5. ログ

loglevel notice
logfile ""

設定ファイルでコンテナを起動

docker run -d \
  --name redis-prod \
  -p 6379:6379 \
  -v ~/redis-config/redis.conf:/usr/local/etc/redis/redis.conf \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server /usr/local/etc/redis/redis.conf

末尾の redis-server /usr/local/etc/redis/redis.conf で指定ファイルを読み込みます。

設定の反映確認

docker exec -it redis-prod redis-cli -a YourStrongPassword123
config get save
config get appendonly
config get maxmemory

ファイルの値と一致すれば反映済みです。

Redis パスワード認証（3 つの方法）

実話です。パスワード未設定の Redis が公網に露出し、マイニングに使われた事例があります。ジョークではなく実際の話です。

なぜパスワードが必須か

Redis はデフォルトでパスワードがありません。6379 が露出していれば、誰でも読み書きできます。本番では パスワード設定が最低ライン です。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

方法 1：コマンドライン引数

docker run -d \
  --name redis-pwd \
  -p 6379:6379 \
  redis:latest \
  redis-server --requirepass "MyStr0ng#P@ssw0rd"

手軽ですが、本番非推奨。シェル履歴にパスワードが残ります。

方法 2：設定ファイル（推奨）

redis.conf に次を追加します。

requirepass YourStrongPassword123

先ほどの手順でマウントして起動します。履歴に残らず、チーム管理もしやすい本番の定番です。

パスワードの目安：

• 16 文字以上
• 大小英字・数字・記号を含む
• よくある単語や誕生日は避ける

方法 3：実行中に動的設定

docker exec -it redis-pwd redis-cli
config set requirepass "NewPassword123"

再起動で消える ため、緊急時の一時対応向けです。

パスワード付きで接続する

方法 1：起動時にパスワード指定

docker exec -it redis-pwd redis-cli -a "MyStr0ng#P@ssw0rd"

方法 2：接続後に AUTH

docker exec -it redis-pwd redis-cli
auth MyStr0ng#P@ssw0rd
set test "hello"

誤ったパスワードでは次のエラーになります。

(error) NOAUTH Authentication required.

auth で再認証してください。

アプリケーション側の接続設定

接続文字列にパスワードを含めます。

redis://:YourStrongPassword123@localhost:6379

コード例（Node.js）：

const redis = require('redis');
const client = redis.createClient({
  host: 'localhost',
  port: 6379,
  password: 'YourStrongPassword123'
});

Docker Compose でデプロイ（チーム向け推奨）

ここまでは docker run でした。コマンドが長く、毎回打ち直すのは大変です。チームや複数コンテナなら Docker Compose が向いています。

Docker Compose を使う理由

• 設定を docker-compose.yml に集約し、Git 管理できる
• ワンコマンド起動で手順を覚えなくてよい
• メンバー全員が同じ環境を再現できる
• Redis + MySQL + Nginx など複数サービスをまとめて管理できる

完全な docker-compose.yml 例

version: '3.8'

services:
  redis:
    image: redis:7.2-alpine
    container_name: redis-prod
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - ./redis-config/redis.conf:/usr/local/etc/redis/redis.conf
      - ./redis-data:/data
    command: redis-server /usr/local/etc/redis/redis.conf
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

volumes:
  redis-data:
    driver: local

要点：

• image: redis:7.2-alpine：軽量 Alpine 版
• restart: always：異常終了時に自動再起動
• volumes：設定とデータをマウント
• healthcheck：10 秒ごとに Redis の生存確認

ワンコマンド起動

同じディレクトリで：

docker-compose up -d

-d はバックグラウンド実行。ネットワーク・Volume・コンテナが自動作成されます。

稼働状態の確認

docker-compose ps

ログの確認

docker-compose logs -f redis

-f は tail -f のように追従表示です。

コンテナの停止

docker-compose down

コンテナは削除されますが、Volume のデータは残ります。

コンテナの再起動

docker-compose restart redis

設定の拡張

他サービスも同じファイルで管理できます。

version: '3.8'

services:
  redis:
    # Redis 設定...

  mysql:
    image: mysql:8.0
    # MySQL 設定...

  app:
    build: .
    # アプリ設定...
    depends_on:
      - redis
      - mysql

プロジェクト起動時に Redis・MySQL・アプリがまとめて立ち上がり、依存関係も自動で処理されます。

よくあるトラブルと本番のベストプラクティス

コンテナは動いても、運用では必ず問題が出ます。ここではトラブルシュートと本番の実践をまとめます。

Redis ログの確認

まずログを見ます。

直近 100 行：

docker logs --tail 100 redis-prod

追従表示：

docker logs -f redis-prod

Compose の場合：

docker-compose logs -f redis

起動成否、設定エラー、異常接続などが分かります。

コンテナのヘルスチェック

Docker に Redis の正常性を任せ、異常時は再起動させられます。

docker-compose.yml に追加：

healthcheck:
  test: ["CMD", "redis-cli", "ping"]
  interval: 10s
  timeout: 3s
  retries: 3

10 秒ごとに redis-cli ping を実行し、3 回連続失敗で unhealthy になります。restart: always と組み合わせれば自動復旧しやすくなります。

性能チューニング

1. 最大メモリの制限

Redis はデフォルトでメモリを使い切ります。本番では上限を設けます。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

maxmemory 512mb
maxmemory-policy allkeys-lru

allkeys-lru は満杯時に最も使われていないキーを削除します。

2. 危険コマンドの無効化

本番で危ないコマンド例：

• FLUSHALL：全データ削除
• FLUSHDB：現在 DB を削除
• KEYS *：全キー列挙でブロック

設定で無効化できます。

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS ""

3. 永続化頻度の調整

書き込みが非常に多い場合は RDB 間隔を緩められます。

save 900 1
save 300 10
save 60 10000

キャッシュ用途でロス許容なら、さらに緩くする選択もあります。

セキュリティ強化

1. 公網への露出を避ける

Redis をそのままインターネットに晒さない。リモート接続は SSH トンネルや VPN を使います。

内网 IP にバインド：

bind 127.0.0.1 192.168.1.100

2. 強固なパスワード

requirepass Th1s!sA$tr0ngP@ssw0rd2024

3. 定期バックアップ

永続化があってもバックアップは必要です。毎日深夜に RDB/AOF をコピーする例：

#!/bin/bash
DATE=$(date +%Y%m%d)
cp ~/redis-data/dump.rdb ~/redis-backup/dump-$DATE.rdb
cp ~/redis-data/appendonly.aof ~/redis-backup/appendonly-$DATE.aof

本番デプロイのチェックリスト

デプロイ前に確認：

• ✅ 永続化（RDB+AOF 混合推奨）
• ✅ パスワード認証
• ✅ データ Volume をホストにマウント
• ✅ カスタム設定ファイル（デフォルトのままにしない）
• ✅ ログ確認手段
• ✅ ヘルスチェック
• ✅ maxmemory 制限
• ✅ 危険コマンドの無効化または rename
• ✅ 定期バックアップ
• ✅ 公網非公開（または VPN/SSH トンネル）

Redis 性能の監視

docker exec -it redis-prod redis-cli -a your_password
info memory

永続化状態：

info persistence

接続数：

info clients

ここまで進めれば、本番レベルの Redis コンテナ ができているはずです。永続化、認証、設定の整理が揃っています。

まとめ

冒頭のシナリオに戻りましょう。金曜に Redis をデプロイし、月曜にデータが消えた——原因は永続化未設定で、データがコンテナ内にしかなく再起動で消えたことです。

本記事の要点：

• RDB：定期スナップショット。復旧は速い。バックアップ向き
• AOF：書き込みを記録。安全性が高く、最大 1 秒程度のロス
• 混合永続化（推奨）：RDB の速さと AOF の安全性
• パスワード認証：3 通りの設定。本番では必須
• 設定ファイル：再現性のある運用
• Docker Compose：設定即コードでワンコマンド起動

今動いている Docker Redis があれば、すぐ確認してください。

1. Volume はマウントしたか？（-v ~/redis-data:/data）
2. 永続化は有効か？（RDB / AOF / 混合）
3. パスワードは設定したか？（requirepass）
4. 設定ファイルはカスタムしたか？（デフォルトのままにしない）

本番ではこの 4 点が最低ラインです。

次回デプロイの参考にブックマークし、チームで共有して統一規約を作ると、同じ落とし穴を減らせます。

本記事の設定は Redis 7.x 系を前提にしています。バージョンが異なる場合は Redis 公式ドキュメント で項目の差分を確認してください。