Dockerを使ったRedis入門：基礎から活用までを徹底解説

1. はじめに

現代のWebサービスやアプリケーション開発において、データの高速な処理と永続化は不可欠です。その中で、インメモリデータストアとして絶大な人気を誇るのがRedisです。Redisは、単なるキャッシュにとどまらず、メッセージキュー、ランキングシステム、セッション管理など、多岐にわたる用途で利用されています。

一方で、開発環境の構築や本番環境へのデプロイにおいて、アプリケーションとその依存関係を効率的に管理することは常に課題となります。そこで登場するのが、コンテナ仮想化技術であるDockerです。Dockerは、アプリケーションと実行環境を「コンテナ」と呼ばれる独立したパッケージにまとめ、どこでも一貫した動作を保証します。

本記事では、この強力な二つの技術、RedisとDockerを組み合わせることで、いかに開発・運用が効率的かつ堅牢になるかを、基礎から実践的な活用、そして高度な利用法まで徹底的に解説します。約5000語にわたる詳細な解説を通じて、あなたはDockerとRedisを使いこなし、次世代のアプリケーション開発に自信を持って取り組めるようになるでしょう。

なぜRedisとDockerなのか？

Redisの高速性: Redisはデータをメモリ上に保持するため、非常に高速な読み書きが可能です。これにより、レスポンスタイムの短縮やスループットの向上が期待できます。
Redisの多機能性: 単純なキーバリューストアだけでなく、リスト、セット、ハッシュ、ソート済みセットなど多彩なデータ構造をサポートし、様々なアプリケーションロジックをシンプルに実装できます。
Dockerの環境構築の容易さ: Dockerを使えば、OSや既存の環境に依存することなく、数コマンドでRedisの環境を構築できます。開発者間の環境差異に悩まされることがなくなります。
Dockerのポータビリティ: 開発環境で構築したRedisコンテナを、テスト環境、ステージング環境、本番環境へとそのまま移行できます。これにより、「私のマシンでは動くのに」という問題が解消されます。
Dockerのリソース隔離: Redisをコンテナとして実行することで、ホストOSや他のアプリケーションからリソースが隔離され、安定した動作が期待できます。

この記事の目的と対象読者

本記事は、以下のような方を対象としています。

Redisを使った開発に興味があるが、まだ触れたことがない方。
Dockerの基本的な概念は知っているが、具体的なアプリケーション（Redis）との連携方法を知りたい方。
Redisをより効率的かつ堅牢に運用したいと考えている開発者や運用担当者。
Docker Composeを使ったマルチコンテナアプリケーションの構築方法を学びたい方。
Redisの高度な機能（高可用性、セキュリティ、パフォーマンス）をDocker環境で実現する方法を知りたい方。

さあ、RedisとDockerの素晴らしい世界への旅を始めましょう。

2. Redisの基礎

Redis（Remote Dictionary Server）は、オープンソースのインメモリデータ構造ストアです。一般的には、キーバリューストア（KVS）の一種として分類されますが、単なるKVSを超えた豊富なデータ構造と機能を提供します。ディスクへの永続化も可能ですが、基本的にはメモリ上で動作するため、非常に高速なデータアクセスが特徴です。

Redisとは何か？

インメモリデータストア: データを主記憶（RAM）に保持します。これにより、従来のディスクベースのデータベースと比較して、桁違いに高速な読み書きを実現します。
キーバリューストア（KVS）: データは「キー」と「値」のペアで保存されます。キーは一意であり、値には様々なデータ構造を取ることができます。
NoSQLデータベース: リレーショナルデータベースのような厳密なスキーマを持たず、柔軟なデータモデルに対応します。
シングルスレッド: Redisのコマンド処理は基本的にシングルスレッドで行われます。これはシンプルな設計と高速な処理を両立させるためですが、I/O操作（ディスク永続化など）は別スレッドで行われます。
永続化: メモリ上のデータは、RDB (Redis Database) スナップショットとAOF (Append Only File) ログという2つの方法でディスクに永続化できます。これにより、Redisサーバーが再起動してもデータが失われることを防ぎます。

Redisの主要なデータ構造と使用例

RedisがKVS以上の価値を持つ理由は、その豊富なデータ構造にあります。それぞれのデータ構造は、特定のユースケースに最適化されています。

文字列 (Strings)
- 概要: 最も基本的なデータ構造で、バイナリセーフな文字列（テキスト、JPEG画像、シリアライズされたオブジェクトなど）を最大512MBまで保存できます。カウンターとしても利用できます。
- コマンド例: SET key value, GET key, INCR key
- 使用例:
  - キャッシュ: Webページの出力、データベースクエリの結果
  - セッション管理: ユーザーセッションIDとセッション情報の保存
  - カウンター: Webサイトのアクセス数、いいねの数
リスト (Lists)
- 概要: 挿入順序が保持される文字列のコレクションです。両端から要素を追加・削除できるため、キューやスタックとして利用できます。
- コマンド例: LPUSH key value1 value2, RPUSH key value1 value2, LPOP key, RPOP key, LRANGE key start stop
- 使用例:
  - メッセージキュー: 非同期処理のタスクキュー
  - 最新のニュースフィード: 最新のN件の投稿リスト
  - チャットアプリケーションのタイムライン
セット (Sets)
- 概要: 順序を持たない文字列のコレクションで、重複する要素は格納されません。集合演算（和集合、差集合、積集合）が可能です。
- コマンド例: SADD key member1 member2, SMEMBERS key, SISMEMBER key member, SINTER set1 set2
- 使用例:
  - ユニークな訪問者の追跡
  - タグの管理: 特定のオブジェクトに付けられたタグの集合
  - ソーシャルネットワークでの共通の友達（集合演算）
  - ユーザーの興味・関心のコレクション
ソート済みセット (Sorted Sets)
- 概要: セットと同様に重複しない文字列のコレクションですが、各メンバーには「スコア」と呼ばれる浮動小数点数が関連付けられます。スコアに基づいてメンバーがソートされます。ランキングの実装に最適です。
- コマンド例: ZADD key score1 member1 score2 member2, ZRANGE key start stop [WITHSCORES], ZREVRANGE key start stop, ZSCORE key member
- 使用例:
  - ゲームのハイスコアランキング
  - 人気投票のリアルタイムランキング
  - リーダーボード
ハッシュ (Hashes)
- 概要: フィールドと値のペアを格納するデータ構造です。単一のキーの下に複数のフィールドと値を持ち、オブジェクトの表現に適しています。
- コマンド例: HSET key field1 value1 field2 value2, HGET key field, HGETALL key, HDEL key field
- 使用例:
  - ユーザープロファイルの保存: user:100というキーにname, email, ageなどのフィールドを格納
  - 商品の詳細情報
  - セッションデータ（Redis Stringsよりも構造化されたセッション情報に最適）
その他 (Streams, Bitmaps, HyperLogLog, Geospatial Indices)
- Streams: append-onlyなデータ構造で、ログの収集やイベントストリーム処理に利用されます。
- Bitmaps: ビット単位の操作が可能で、非常に効率的なフラグ管理やユニークユーザーのカウントなどに利用されます。
- HyperLogLog: 多数のユニークなアイテムを非常に少ないメモリで概算するデータ構造です。
- Geospatial Indices: 地理空間データを保存し、指定した場所の周辺にあるアイテムを検索するのに利用されます。

Redisのユースケース

Redisの多機能性と高速性により、様々なアプリケーションで利用されています。

キャッシュ: 最も一般的なユースケース。データベースやAPIからの高コストなクエリ結果をRedisに保存し、高速な読み取りを提供します。
セッション管理: Webアプリケーションのユーザーセッション情報を保存します。特に分散環境で有効です。
メッセージキュー/ブローカー: Producer-Consumerパターンで、非同期タスクのキューとして利用されます。Pub/Sub機能も提供します。
リアルタイムアナリティクス: リアルタイムでデータを集計し、ダッシュボードなどに表示します。
リーダーボード/ランキング: ゲームのハイスコアや、人気商品のランキングなどをリアルタイムで更新・表示します。
レイトリミッター: APIへのリクエストレートを制限するために使用されます。
全文書検索: Redis Searchモジュールを使用することで、高速な検索エンジンとして機能します。

Redisのこれらの機能は、Dockerと組み合わせることで、さらに強力で柔軟な開発・運用が可能になります。

3. Dockerの基礎

Dockerは、アプリケーションとその依存関係を「コンテナ」と呼ばれる軽量な仮想環境にパッケージ化し、どこでも同じように動作させるためのプラットフォームです。従来の仮想マシン（VM）とは異なり、OS全体を仮想化するのではなく、ホストOSのカーネルを共有することで、非常に高速な起動と低リソース消費を実現します。

Dockerとは何か？

コンテナ仮想化: アプリケーションとその実行に必要なもの（コード、ランタイム、システムツール、ライブラリなど）を1つのパッケージにまとめて、どこでも一貫して動作するようにします。
VMとの違い:
- VM: ゲストOSごとにOS全体を起動するため、リソース消費が大きく、起動が遅い。完全に分離された環境。
- Dockerコンテナ: ホストOSのカーネルを共有し、プロセスレベルで隔離される。非常に軽量で高速に起動し、リソース消費も少ない。

Dockerの主要なコンポーネント

Docker Engine: Dockerの主要なコンポーネントで、以下の要素から構成されます。
- Docker Daemon (dockerd): ホストマシン上で動作し、コンテナの構築、実行、管理を行います。
- Docker CLI (docker): ユーザーがDocker Daemonと対話するためのコマンドラインインターフェースです。
- REST API: Docker DaemonとCLIが通信するためのAPIです。
Docker Image (Dockerイメージ): コンテナを作成するための読み取り専用のテンプレートです。アプリケーションのコード、ライブラリ、依存関係、実行に必要な設定などが含まれています。Docker Hubなどのレジストリから取得したり、Dockerfileから自分で構築したりできます。
Docker Container (Dockerコンテナ): Dockerイメージの実行可能なインスタンスです。イメージを基に、独立したプロセスとして実行されます。コンテナは隔離されており、それぞれのコンテナは互いに影響を与えません。
Dockerfile (Dockerファイル): Dockerイメージを自動的に構築するための手順を記述したテキストファイルです。このファイルによって、誰でも同じ手順で同じイメージを再現できます。
Docker Hub: Dockerイメージの公開レジストリです。公式イメージやコミュニティが作成したイメージを検索・ダウンロードできます。プライベートレジストリも利用可能です。
Docker Compose: 複数のDockerコンテナを連携させてアプリケーションを構築するためのツールです。YAMLファイルを使って、複数のコンテナサービス（例：Webサーバー、データベース、キャッシュサーバー）の設定を一元管理し、コマンド一つでまとめて起動・停止できます。

Dockerの基本的なコマンド

Dockerの操作は主にdockerコマンドラインツールを通じて行われます。

docker pull <image_name>[:tag]: Docker Hubなどのレジストリから指定したイメージをダウンロードします。タグを指定しない場合、latestタグがデフォルトでダウンロードされます。
bash docker pull redis docker pull ubuntu:20.04
docker images: ローカルにダウンロードされているDockerイメージの一覧を表示します。
bash docker images
docker run [OPTIONS] <image_name>[:tag] [COMMAND] [ARG...]: 新しいコンテナを作成し、実行します。
- -d (detached mode): コンテナをバックグラウンドで実行します。
- --name <container_name>: コンテナに任意の名前を付けます。
- -p <host_port>:<container_port>: ホストOSのポートをコンテナのポートにマッピングします。
- -v <host_path>:<container_path>: ホストOSのパス（またはDockerボリューム）をコンテナのパスにマウントし、データの永続化を実現します。
- --rm: コンテナが停止したときに自動的に削除します（デバッグ用途などに便利）。
  bash docker run -d --name my-nginx -p 80:80 nginx
docker ps [-a]: 実行中のコンテナの一覧を表示します。-aオプションを使うと、停止中のコンテナも表示します。
bash docker ps docker ps -a
docker stop <container_id_or_name>: 実行中のコンテナを停止します。
docker rm <container_id_or_name>: 停止中のコンテナを削除します。
bash docker stop my-nginx docker rm my-nginx
docker exec [OPTIONS] <container_id_or_name> <command> [ARG...]: 実行中のコンテナ内でコマンドを実行します。
- -it: インタラクティブなTtyセッションを割り当て、標準入出力を接続します。コンテナ内でシェルを実行する際などに利用します。
  bash docker exec -it my-nginx bash
docker logs [OPTIONS] <container_id_or_name>: コンテナの標準出力/標準エラー出力のログを表示します。
- -f (follow): リアルタイムでログを追跡します。
  bash docker logs my-nginx docker logs -f my-nginx
docker build [OPTIONS] <path_to_dockerfile>: DockerfileからDockerイメージを構築します。
- -t <image_name>[:tag]: 構築するイメージに名前とタグを付けます。
- .: Dockerfileが存在するカレントディレクトリをビルドコンテキストとして指定します。
  bash docker build -t my-app:1.0 .

Dockerネットワークの基礎

Dockerコンテナは、デフォルトで分離されたネットワーク上に存在します。コンテナ間の通信や、ホストOSとの通信を制御するために、様々なネットワークドライバが提供されています。

bridge (デフォルト): ホスト上に仮想ブリッジを作成し、コンテナはそれぞれ独自のIPアドレスを持ち、このブリッジを介して通信します。外部からはポートマッピングを通じてアクセスします。
host: コンテナがホストOSのネットワークスタックを共有します。コンテナはホストと同じIPアドレスとポートを使用します。隔離性は失われますが、パフォーマンスは向上します。
none: ネットワークインターフェースを持ちません。完全に隔離された環境です。
ユーザー定義ブリッジネットワーク: docker network createで作成するカスタムネットワーク。デフォルトのブリッジネットワークよりも高度な機能（DNSによる名前解決、より良い隔離性）を提供し、複数のコンテナを接続する際に推奨されます。Docker Composeを使用すると自動的に作成されます。

Dockerボリュームの基礎

コンテナ内のデータは、コンテナが削除されると失われます。データの永続化には「ボリューム」を使用します。

Docker Volumes: Dockerが管理する領域にデータを保存します。コンテナが削除されてもボリュームは残り、新しいコンテナにマウントできます。データ管理がDockerに任せられるため、最も推奨される方法です。
bash docker volume create my_data docker run -v my_data:/app/data ...
Bind Mounts: ホストOS上の既存のディレクトリやファイルを直接コンテナにマウントします。開発中にローカルのソースコードをコンテナに同期させるなど、ホストとコンテナ間でファイルを共有したい場合に便利です。
bash docker run -v /path/to/host/data:/app/data ...

Docker Composeの概要

Docker Composeは、複数のコンテナからなるアプリケーションを定義し、実行するためのツールです。docker-compose.ymlというYAMLファイルに、各サービス（コンテナ）の定義、ネットワーク、ボリュームなどを記述します。

定義: サービス（コンテナ）、イメージ、ポートマッピング、ボリュームマウント、環境変数、依存関係などをYAMLファイルで一元的に定義。
実行: docker-compose upコマンド一つで、定義されたすべてのサービスを起動。
管理: docker-compose downで全てのサービスを停止・削除。

これでDockerの基本的な概念とコマンドを理解しました。次に、これらを活用してRedisを動かしていきます。

4. DockerでRedisを動かす

いよいよDockerを使ってRedisを起動してみましょう。Docker Hubには公式のRedisイメージが公開されており、これを利用するのが最も簡単です。

基本的なRedisコンテナの起動

まず、Redisのコンテナを最もシンプルな形で起動してみます。

“`bash

1. 最新のRedisイメージをダウンロード (もし持っていなければ)

docker pull redis

2. Redisコンテナを起動

-d: デタッチドモード (バックグラウンド実行)

–name my-redis: コンテナに ‘my-redis’ という名前を付ける

-p 6379:6379: ホストの6379番ポートをコンテナの6379番ポートにマッピング

redis: 使用するイメージ名

docker run -d –name my-redis -p 6379:6379 redis
“`

コマンドを実行すると、以下のようなコンテナIDが表示されるはずです。

a1b2c3d4e5f6... (コンテナID)

コンテナが起動しているか確認しましょう。

bash docker ps

出力例:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a1b2c3d4e5f6 redis "docker-entrypoint.s…" 10 seconds ago Up 9 seconds 0.0.0.0:6379->6379/tcp my-redis

STATUSがUpになっていれば、Redisサーバーが正常に起動しています。ホストの6379ポートを通じて、このRedisサーバーにアクセスできるようになりました。

Redis CLIでの接続と基本操作

Redisコンテナが起動したら、redis-cliを使ってRedisサーバーに接続し、簡単な操作を行ってみましょう。redis-cliはRedisのコマンドラインインターフェースです。Redisイメージにはredis-cliも含まれているため、コンテナ内で直接実行できます。

“`bash

実行中のmy-redisコンテナ内でredis-cliを実行

-it: インタラクティブなターミナルセッションを割り当てる

docker exec -it my-redis redis-cli
“`

これでredis-cliプロンプトが表示されます。

127.0.0.1:6379>

いくつかのRedisコマンドを実行してみましょう。

127.0.0.1:6379> SET mykey "Hello Redis from Docker!" OK 127.0.0.1:6379> GET mykey "Hello Redis from Docker!" 127.0.0.1:6379> INCR mycounter (integer) 1 127.0.0.1:6379> INCR mycounter (integer) 2 127.0.0.1:6379> LPUSH mylist "item1" "item2" "item3" (integer) 3 127.0.0.1:6379> LRANGE mylist 0 -1 1) "item3" 2) "item2" 3) "item1" 127.0.0.1:6379> QUIT

これで、Dockerコンテナ内でRedisが正常に動作し、データが保存されていることを確認できました。

データの永続化

Redisはインメモリデータベースですが、データはディスクに永続化できます。Dockerコンテナはデフォルトでは一時的なファイルシステムを持つため、コンテナが削除されるとデータも失われます。これを防ぐために、Dockerボリュームを使ってデータを永続化する必要があります。

Redisの永続化方法には主にRDB (Redis Database) とAOF (Append Only File) の2つがあります。

RDB: ある時点のデータのスナップショットをディスクに保存します。デフォルトで有効になっており、dump.rdbというファイルが作成されます。
AOF: Redisサーバーが受信したすべての書き込みコマンドをログファイルに追記します。これにより、Redisが再起動する際にログを再生してデータを復元します。より高いデータ永続性を持ちます。

Dockerでこれらのデータを永続化するには、コンテナの/dataディレクトリ（Redisがデフォルトでデータを保存する場所）をホストOS上の永続的な場所にマウントします。

1. Docker Volumesを使用する (推奨)

Dockerがボリュームのライフサイクルを管理するため、最も推奨される方法です。

“`bash

1. まず、既存のmy-redisコンテナを停止して削除します (もしあれば)

docker stop my-redis
docker rm my-redis

2. Redis用のDockerボリュームを作成します (初回のみ)

docker volume create redis_data

3. Redisコンテナを起動し、作成したボリュームをマウントします

-v redis_data:/data: ‘redis_data’という名前のボリュームをコンテナの’/data’ディレクトリにマウント

docker run -d –name my-redis-persistent -p 6379:6379 -v redis_data:/data redis
“`

これでRedisコンテナにデータを書き込むと、そのデータはredis_dataボリュームに保存されます。たとえmy-redis-persistentコンテナを削除して再作成しても、同じredis_dataボリュームをマウントすれば、以前のデータが復元されます。

ボリュームの中身は以下のコマンドで確認できます。

bash docker volume inspect redis_data

Mountpointのパスを確認し、そのパスに移動すればdump.rdbファイルなどが見つかります。

2. Bind Mountsを使用する

ホストOS上の特定のディレクトリにデータを保存したい場合に便利です。

“`bash

1. 永続化用のディレクトリをホストOS上に作成 (例: ~/redis_data)

mkdir -p ~/redis_data

2. Redisコンテナを起動し、ホストのディレクトリをマウントします

-v ~/redis_data:/data: ホストの’~/redis_data’ディレクトリをコンテナの’/data’ディレクトリにマウント

docker run -d –name my-redis-bind-mount -p 6379:6379 -v ~/redis_data:/data redis
“`

これで、my-redis-bind-mountコンテナで保存されたデータは、ホストの~/redis_dataディレクトリにdump.rdbなどのファイルとして保存されます。

設定ファイルの適用

Redisの設定は、redis.confファイルを通じて行われます。Dockerコンテナでカスタム設定を使用したい場合、ホストOSに設定ファイルを用意し、それをコンテナにマウントする方法が一般的です。

例として、Redisの最大メモリ設定（maxmemory）を変更してみましょう。

redis.confファイルを作成:
ホストOSの適当な場所（例: ~/redis_config/redis.conf）に以下の内容でファイルを作成します。

“`conf

~/redis_config/redis.conf

最大メモリを512MBに設定し、LRU (Least Recently Used) ポリシーで古いキーを削除

maxmemory 512mb
maxmemory-policy allkeys-lru

Redisログを標準出力に出力 (Dockerのログとして収集するため)

logfile “”
``logfile “”とすることで、Redisのログが標準出力に送られ、docker logs`コマンドで確認できるようになります。
Redisコンテナを起動し、設定ファイルをマウント:
“`bash
# 既存のRedisコンテナを停止・削除
docker stop my-redis-persistent my-redis-bind-mount && docker rm my-redis-persistent my-redis-bind-mount

設定ファイルとデータをマウントしてRedisを起動

docker run -d –name my-redis-custom \
-p 6379:6379 \
-v ~/redis_config/redis.conf:/usr/local/etc/redis/redis.conf \
-v redis_data:/data \
redis redis-server /usr/local/etc/redis/redis.conf
`` ここで重要なのは、最後のredis-server /usr/local/etc/redis/redis.conf部分です。これは、redis`イメージがデフォルトで実行するコマンドをオーバーライドし、指定した設定ファイルを使ってRedisサーバーを起動するように指示しています。
設定が適用されたか確認:
redis-cliで接続し、CONFIG GET maxmemoryコマンドで確認します。

bash docker exec -it my-redis-custom redis-cli 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "536870912" # 512MBは536870912バイト 127.0.0.1:6379> CONFIG GET maxmemory-policy 1) "maxmemory-policy" 2) "allkeys-lru"
正しく設定が適用されていることが確認できます。

これで、Dockerコンテナ内でRedisを起動し、データの永続化とカスタム設定の適用方法を習得しました。次に、複数のコンテナを連携させるDocker Composeについて見ていきましょう。

5. Docker Composeを使ったRedis環境の構築

単一のコンテナであればdocker runコマンドで十分ですが、実際のアプリケーションではデータベース、Webサーバー、キャッシュサーバーなど、複数のサービスが連携して動作します。このようなマルチコンテナアプリケーションの定義と管理を容易にするのがDocker Composeです。

なぜDocker Composeを使うのか？

設定の一元管理: 複数のサービス（コンテナ）の設定、ネットワーク、ボリュームなどを単一のdocker-compose.ymlファイルに記述できます。
簡単な起動・停止: docker-compose upコマンド一つで、定義されたすべてのサービスを依存関係を考慮して起動できます。docker-compose downで一括停止・削除も可能です。
サービスの連携: Docker Composeはデフォルトでユーザー定義のブリッジネットワークを作成し、そのネットワーク内のサービス名をホスト名として名前解決できるようにします。これにより、コンテナ間の通信が非常に簡単になります（例: Webアプリケーションからredisというホスト名でRedisにアクセス）。
環境の再現性: docker-compose.ymlファイルを共有するだけで、開発チーム全員が同じ環境を簡単に再現できます。

`docker-compose.yml`の基本構造

docker-compose.ymlはYAML形式のファイルで、以下の主要なセクションを持ちます。

“`yaml
version: ‘3.8’ # Docker Composeファイルのフォーマットバージョン

services: # アプリケーションを構成する各サービスを定義
:
image: # 使用するDockerイメージ
ports: # ポートマッピング (ホスト:コンテナ)
– “80:80”
volumes: # ボリュームマウント (ホスト/ボリューム:コンテナ)
– ./data:/app/data
environment: # 環境変数
– ENV_VAR=value
depends_on: # 依存関係 (サービス起動順序)
–
networks: # ネットワーク指定
– my_network

:
# …

volumes: # 永続化ボリュームの定義
:

networks: # ネットワークの定義
:
“`

単一Redisインスタンスの構築例

まずは、Docker Composeを使って単一のRedisインスタンスを起動する例から見ていきましょう。

docker-compose.ymlという名前でファイルを作成し、以下の内容を記述します。

“`yaml

docker-compose.yml

version: ‘3.8’

services:
redis: # サービス名。後でWebアプリからこの名前でアクセスできます
image: redis:latest # 使用するRedisイメージ
container_name: my-compose-redis # コンテナに任意の名前を付ける
ports:
– “6379:6379” # ホストの6379ポートをコンテナの6379ポートにマッピング
volumes:
– redis_data:/data # redis_dataボリュームをコンテナの/dataにマウントし、データを永続化
command: redis-server –appendonly yes # RedisのAOF永続化を有効にする
restart: always # コンテナが停止した場合に常に再起動する

volumes:
redis_data: # redis_dataという名前のボリュームを定義
“`

services.redis: redisというサービス名でコンテナを定義します。
image: redis:latest: Docker Hubから最新のRedisイメージをプルして使用します。
ports: - "6379:6379": ホストの6379ポートとコンテナの6379ポートを紐付けます。これにより、ホストからlocalhost:6379でRedisにアクセスできます。
volumes: - redis_data:/data: 後で定義するredis_dataという名前のボリュームを、コンテナ内の/dataディレクトリにマウントします。Redisの永続化ファイル（dump.rdbやappendonly.aof）はこのディレクトリに保存されます。
command: redis-server --appendonly yes: Redisサーバーを起動する際のコマンドをオーバーライドし、AOF永続化を有効にしています。
restart: always: コンテナが予期せず終了した場合や、Dockerデーモンが再起動した場合に、自動的にこのコンテナを再起動するように設定します。
volumes.redis_data:: redis_dataという名前のDockerボリュームを定義します。これにより、Composeが管理する永続的なストレージが作成されます。

ファイルを保存したら、ターミナルでこのdocker-compose.ymlファイルがあるディレクトリに移動し、以下のコマンドを実行します。

bash docker-compose up -d

up: docker-compose.ymlで定義されたサービスを起動します。
-d: デタッチドモード（バックグラウンドで実行）で起動します。

コンテナが起動したか確認します。

bash docker-compose ps

NAME COMMAND SERVICE STATUS PORTS my-compose-redis "docker-entrypoint.s…" redis running 0.0.0.0:6379->6379/tcp

これで、Docker Composeを使ってRedisコンテナを起動し、データの永続化も設定できました。

CLIで接続してみましょう。

“`bash

サービス名を使ってredis-cliに接続

docker-compose exec redis redis-cli

あるいは、コンテナ名を使って接続

docker exec -it my-compose-redis redis-cli

“`
データが永続化されていることを確認するために、一度データを保存し、コンテナを再起動して再度データを確認してみましょう。

“`bash

redis-cliで何かデータを保存

127.0.0.1:6379> SET mytestkey “This data should persist!”

OK

127.0.0.1:6379> SAVE # 明示的にRDBファイルを保存 (AOFが有効なので自動で保存されますが、確認のため)

OK

127.0.0.1:6379> exit

コンテナを停止・再起動

docker-compose restart redis

再度接続してデータを確認

docker-compose exec redis redis-cli

127.0.0.1:6379> GET mytestkey

“This data should persist!”

“`
データが維持されていることを確認できたら、コンテナを停止・削除します。

bash docker-compose down
docker-compose downは、docker-compose.ymlで定義されたサービス（コンテナ、ネットワーク）を停止し、削除します。volumesセクションで定義されたボリュームはデフォルトでは削除されません。ボリュームも削除したい場合は、-vオプションを追加します。

bash docker-compose down -v # ボリュームも削除

WebアプリケーションとRedisの連携例

次に、Python Flask (またはNode.js Express) のシンプルなWebアプリケーションとRedisをDocker Composeで連携させる例を見ていきましょう。ここではPython Flaskを例に取ります。

プロジェクト構造:

my-app/ ├── app.py ├── requirements.txt └── docker-compose.yml

app.py (Python Flask アプリケーション):
簡単な訪問者カウンターアプリケーションです。Redisに接続し、訪問数をインクリメントして表示します。

“`python

app.py

import os
from flask import Flask
from redis import Redis

app = Flask(name)

Redisホスト名を ‘redis’ に設定 (docker-compose.ymlのサービス名)

ポートはデフォルトの6379

redis_host = os.environ.get(‘REDIS_HOST’, ‘redis’)
redis_port = os.environ.get(‘REDIS_PORT’, 6379)
redis_db = os.environ.get(‘REDIS_DB’, 0)

redis_client = Redis(host=redis_host, port=redis_port, db=redis_db, decode_responses=True)

@app.route(‘/’)
def hello():
try:
visits = redis_client.incr(‘visits’)
return f’Hello, I have been visited {visits} times!’
except Exception as e:
return f’Error connecting to Redis: {e}’, 500

if name == ‘main‘:
app.run(host=’0.0.0.0’, port=5000, debug=True)
“`
requirements.txt:
FlaskとRedisクライアントライブラリを記述します。

Flask==2.3.2 redis==4.5.5
docker-compose.yml:
WebアプリケーションとRedisサービスを定義します。

“`yaml

docker-compose.yml

version: ‘3.8’

services:
web: # Webアプリケーションサービス
build: . # カレントディレクトリのDockerfileを使ってイメージをビルド
ports:
– “5000:5000” # ホストの5000ポートをコンテナの5000ポートにマッピング
environment: # 環境変数でRedisのホスト名を指定
– REDIS_HOST=redis # Redisサービスのコンテナ名をホスト名として利用
depends_on: # webサービスはredisサービスに依存
– redis
restart: always

redis: # Redisサービス
image: redis:latest
container_name: my-compose-redis # コンテナに任意の名前を付ける
volumes:
– redis_data:/data # データを永続化
command: redis-server –appendonly yes
restart: always

volumes:
redis_data: # Redis用のボリュームを定義
“`
- services.web.build: .: webサービスはDockerイメージをビルドして作成されます。Dockerfileは作成しませんが、Composeはbuild: .があれば自動的にPythonイメージをベースにした簡単なイメージをビルドします。（厳密にはPythonアプリをコンテナ化するにはDockerfileが必要ですが、Composeのbuildはそれ自体でPythonアプリをコンテナ化できるわけではなく、DockerFileが必要になります。ここでは便宜上、Docker ComposeがPythonアプリのビルドに必要なDockerfileがあることを前提としています。通常、以下のDockerfileを別途作成します。）
- 補足: webサービスのためのDockerfile
  上記のdocker-compose.ymlでbuild: .を使う場合、webサービスのためのDockerfileが必要です。my-app/Dockerfileとして以下の内容で作成してください。
  
  “`dockerfile
  
  Dockerfile
  
  FROM python:3.9-slim-buster # 軽量なPythonイメージをベースにする
  
  WORKDIR /app # コンテナ内の作業ディレクトリを設定
  
  COPY requirements.txt . # requirements.txtをコピー
  RUN pip install –no-cache-dir -r requirements.txt # 依存関係をインストール
  
  COPY . . # アプリケーションのコードをコピー
  
  CMD [“python”, “app.py”] # アプリケーションを実行
  “`
- services.web.environment.REDIS_HOST=redis: webコンテナの環境変数REDIS_HOSTにredisという値を設定します。これにより、app.py内でredis_clientがRedisサービスに接続する際に、サービス名redisを使って名前解決を行います。Docker Composeが自動的に作成する内部ネットワーク内で、サービス名がDNS名として機能します。
- services.web.depends_on: - redis: webサービスはredisサービスに依存することを宣言します。これにより、redisサービスが先に起動してからwebサービスが起動するようになります。（ただし、これは起動順序を保証するものであり、Redisが完全に起動して接続可能になることを保証するものではありません。アプリケーション側でリトライロジックを実装するのがより堅牢です。）

実行手順:

my-appディレクトリを作成し、その中にapp.py、requirements.txt、Dockerfile、docker-compose.ymlを上記の通り配置します。
ターミナルでmy-appディレクトリに移動します。
以下のコマンドを実行して、アプリケーションとRedisを起動します。

bash docker-compose up -d --build
* --build: Dockerfileに変更があった場合にイメージを再ビルドします。
コンテナが起動していることを確認します。

bash docker-compose ps
webとredisの両方のサービスがrunningになっていることを確認してください。
Webブラウザでhttp://localhost:5000にアクセスします。
ページをリロードするたびに、表示される訪問者数がインクリメントされるはずです。これは、WebアプリケーションがRedisコンテナに正常に接続し、visitsキーの値を更新していることを示します。
Redisコンテナのログを確認して、アクセスがあったことを確認できます。

bash docker-compose logs redis
PythonアプリからのINCR visitsコマンドがログに記録されているはずです。

これで、Docker Composeを使って複数のサービスを連携させ、簡単に開発環境を構築する方法を習得しました。この構成は、本番環境へのデプロイにも応用できます。

6. Redisの高度な活用とDockerでの実践

ここでは、Redisをよりセキュアに、高可用性で、そしてパフォーマンス良く運用するための高度な設定や戦略について、Docker環境での具体的な実践方法を交えながら解説します。

セキュリティ

Redisはデフォルトでパスワード認証が設定されていません。インターネットに直接公開するような環境では、悪意のあるアクセスから保護するために、最低限のセキュリティ対策を講じる必要があります。

1. パスワード認証 (`requirepass`)

Redisの最も基本的なセキュリティ対策は、パスワード認証を設定することです。

redis.confファイルにパスワードを設定:
~/redis_config/redis.conf (先ほど作成したファイル) に以下の行を追加します。

“`conf

~/redis_config/redis.conf (追記)

requirepass your_strong_password_here # 強力なパスワードに変更してください
“`
注意: ここに直接パスワードを記述するのは開発環境向けです。本番環境では、環境変数やシークレット管理ツール（Docker Secrets, Kubernetes Secretsなど）を使用することを強く推奨します。
docker-compose.ymlを更新:
redisサービスがこの設定ファイルを読み込むようにし、かつwebサービスがそのパスワードを知る必要があります。パスワードは環境変数として渡すのが一般的です。

“`yaml

docker-compose.yml (更新)

version: ‘3.8’

services:
web:
build: .
ports:
– “5000:5000”
environment:
– REDIS_HOST=redis
– REDIS_PASSWORD=your_strong_password_here # Webアプリにパスワードを渡す
depends_on:
– redis
restart: always

redis:
image: redis:latest
container_name: my-compose-redis
volumes:
– ./redis_config/redis.conf:/usr/local/etc/redis/redis.conf # 設定ファイルをマウント
– redis_data:/data
command: redis-server /usr/local/etc/redis/redis.conf # 設定ファイルを指定して起動
restart: always

volumes:
redis_data:
“`
app.pyを更新:
Redisクライアントがパスワードを使って接続するように変更します。

“`python

app.py (更新)

import os
from flask import Flask
from redis import Redis

app = Flask(name)
redis_host = os.environ.get(‘REDIS_HOST’, ‘redis’)
redis_port = os.environ.get(‘REDIS_PORT’, 6379)
redis_db = os.environ.get(‘REDIS_DB’, 0)
redis_password = os.environ.get(‘REDIS_PASSWORD’) # 環境変数からパスワードを取得

redis_client = Redis(
host=redis_host,
port=redis_port,
db=redis_db,
password=redis_password, # ここにパスワードを追加
decode_responses=True
)

… (以下のコードは変更なし)

“`
再起動と動作確認:

bash docker-compose down # 古いコンテナを停止・削除 docker-compose up -d --build # 新しい設定で起動
Webブラウザでhttp://localhost:5000にアクセスし、正しく動作することを確認します。
docker-compose exec redis redis-cliで接続しようとすると、パスワードを求められるか、認証エラーになるはずです。
認証するには、AUTH your_strong_password_hereと入力します。

2. ポートの公開範囲の制限

本番環境では、Redisのポート（6379）を直接インターネットに公開すべきではありません。アプリケーションサーバーからのみアクセスできるように、内部ネットワークに限定するのが一般的です。

Docker Composeの場合、portsマッピングを削除するだけで、ホストOSから直接Redisにアクセスできなくなりますが、Docker Composeによって作成される内部ネットワーク上では、サービス名（この場合はredis）を通じて引き続きアクセス可能です。

“`yaml

docker-compose.yml (redisサービスからportsを削除)

version: ‘3.8’

services:
web:
# …

redis:
image: redis:latest
container_name: my-compose-redis
# 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
restart: always

volumes:
redis_data:
`` この変更により、webサービスは引き続きredisというホスト名でRedisにアクセスできますが、ホストOSからlocalhost:6379`で直接Redisに接続しようとしても拒否されます。

監視とログ

Redisの健全性を保つためには、適切な監視とログの収集が不可欠です。

docker logs: Dockerコンテナの標準出力にRedisのログを送信していれば（redis.confでlogfile ""と設定）、docker logs <container_name>で簡単にログを確認できます。docker-compose logs <service_name>も同様です。
bash docker-compose logs redis -f # リアルタイムでRedisのログを追跡
Redis INFOコマンド: Redisサーバーの稼働状況、メモリ使用量、クライアント接続数、レプリケーション状態など、詳細な情報を取得できます。
bash docker-compose exec redis redis-cli INFO
特定のセクションの情報だけを取得することも可能です。例: INFO memory, INFO clients。
Redis MONITORコマンド: Redisサーバーに送られるすべてのコマンドをリアルタイムで監視します。デバッグに非常に便利です。
bash docker-compose exec redis redis-cli MONITOR
本番環境での長期的な使用は推奨されません（パフォーマンスオーバーヘッドがあるため）。

パフォーマンス最適化

Redisのパフォーマンスを最大限に引き出すためには、いくつかの考慮事項があります。

メモリ管理 (maxmemoryとmaxmemory-policy): Redisはインメモリデータベースなので、メモリ使用量の管理は非常に重要です。maxmemoryで上限を設定し、maxmemory-policyでメモリ上限に達した際のデータの削除戦略を定義します。
- noeviction: (デフォルト) メモリ上限に達してもキーを削除せず、書き込み操作を拒否します。
- allkeys-lru: LRU (Least Recently Used) アルゴリズムで最も最近アクセスされていないキーを削除します。一般的なキャッシュ用途で推奨されます。
- allkeys-random: ランダムにキーを削除します。
- volatile-lru, volatile-ttl など、EXPIREコマンドで有効期限が設定されたキーのみを対象にするポリシーもあります。
  これらの設定は、前述の通りredis.confで設定し、Dockerコンテナにマウントします。
データ構造の選択: 各データ構造は特定のユースケースに最適化されています。目的に合ったデータ構造を選択することで、効率的なメモリ使用と高速な操作が可能になります。
パイプライン (Pipelining): 複数のRedisコマンドを一度にサーバーに送信し、まとめて結果を受け取ることで、ネットワークのラウンドトリップタイム (RTT) のオーバーヘッドを削減し、スループットを向上させます。クライアントライブラリでサポートされています。
AOF同期設定 (appendfsync): AOFはデフォルトで1秒ごとにディスクに同期されますが、appendfsync alwaysに設定すると書き込みごとに同期され、データ損失のリスクは最小限になりますが、パフォーマンスが著しく低下します。逆にappendfsync noにすると同期頻度が低くなりパフォーマンスは向上しますが、データ損失のリスクは高まります。用途に応じて適切な設定を選びましょう。

高可用性（HA）: Redis Sentinel

単一のRedisインスタンスは SPOF (Single Point of Failure) となります。本番環境では、Redis SentinelやRedis Clusterといった高可用性ソリューションを導入するのが一般的です。ここでは、比較的導入しやすいRedis SentinelをDocker Composeで構築する例を解説します。

Redis Sentinelは、Redisのマスター-レプリカ構成を監視し、マスターがダウンした場合に自動的にフェイルオーバー（レプリカを新しいマスターに昇格させる）を行うシステムです。少なくとも3つのSentinelインスタンスを推奨します。

構成概要:
* 1つのRedisマスター
* 1つ以上のRedisレプリカ (旧スレーブ)
* 3つ以上のRedis Sentinelインスタンス

ファイル構成:

my-redis-ha/ ├── redis-master.conf ├── redis-replica.conf ├── sentinel.conf └── docker-compose.yml

設定ファイルの作成:
- redis-master.conf:
  conf # redis-master.conf port 6379 daemonize no # Dockerではフォアグラウンドで実行 protected-mode no # 内部ネットワークからのアクセスを許可 logfile "" # ログを標準出力に dir /data # 永続化ディレクトリ appendonly yes # AOFを有効に # requirepass your_strong_password_here # 必要であればパスワード設定
- redis-replica.conf:
  conf # redis-replica.conf port 6379 daemonize no protected-mode no logfile "" dir /data appendonly yes replicaof redis-master 6379 # masterをredis-masterサービスとして認識 # masterauth your_strong_password_here # マスターにパスワードがある場合
- sentinel.conf:
  “`conf
  # sentinel.conf
  port 26379
  daemonize no
  protected-mode no
  logfile “”
  # sentinel monitor
  # master_name: Sentinelが監視するマスターの名前
  # ip: マスターのIPアドレス (Docker Composeではサービス名がDNSで解決される)
  # port: マスターのポート
  # quorum: フェイルオーバーを開始するために合意が必要なSentinelの数
  sentinel monitor mymaster redis-master 6379 2
  # sentinel auth-pass # マスターにパスワードがある場合
  
  フェイルオーバータイムアウト
  
  sentinel failover-timeout mymaster 60000
  
  マスターがダウンしたと判断するまでの時間
  
  sentinel down-after-milliseconds mymaster 5000
  ``quorumは、フェイルオーバーを開始するために「マスターがダウンしている」と判断する必要があるSentinelインスタンスの最小数です。合計Sentinel数が3の場合、quorum`を2に設定するのが一般的です。
docker-compose.ymlの作成:
マスター、レプリカ、3つのSentinelインスタンスを定義します。

“`yaml

docker-compose.yml (HA構成)

version: ‘3.8’

services:
redis-master:
image: redis:latest
container_name: redis-master
volumes:
– ./redis-master.conf:/usr/local/etc/redis/redis.conf
– redis_master_data:/data
command: redis-server /usr/local/etc/redis/redis.conf
restart: always
networks:
– redis_net

redis-replica-1:
image: redis:latest
container_name: redis-replica-1
volumes:
– ./redis-replica.conf:/usr/local/etc/redis/redis.conf
– redis_replica_1_data:/data
command: redis-server /usr/local/etc/redis/redis.conf
restart: always
depends_on:
– redis-master
networks:
– redis_net

redis-replica-2:
image: redis:latest
container_name: redis-replica-2
volumes:
– ./redis-replica.conf:/usr/local/etc/redis/redis.conf
– redis_replica_2_data:/data
command: redis-server /usr/local/etc/redis/redis.conf
restart: always
depends_on:
– redis-master
networks:
– redis_net

redis-sentinel-1:
image: redis:latest
container_name: redis-sentinel-1
volumes:
– ./sentinel.conf:/usr/local/etc/redis/sentinel.conf
command: redis-sentinel /usr/local/etc/redis/sentinel.conf
restart: always
depends_on:
– redis-master
– redis-replica-1
– redis-replica-2
networks:
– redis_net

redis-sentinel-2:
image: redis:latest
container_name: redis-sentinel-2
volumes:
– ./sentinel.conf:/usr/local/etc/redis/sentinel.conf
command: redis-sentinel /usr/local/etc/redis/sentinel.conf
restart: always
depends_on:
– redis-master
– redis-replica-1
– redis-replica-2
networks:
– redis_net

redis-sentinel-3:
image: redis:latest
container_name: redis-sentinel-3
volumes:
– ./sentinel.conf:/usr/local/etc/redis/sentinel.conf
command: redis-sentinel /usr/local/etc/redis/sentinel.conf
restart: always
depends_on:
– redis-master
– redis-replica-1
– redis-replica-2
networks:
– redis_net

networks:
redis_net: # 内部ネットワークを定義

volumes:
redis_master_data:
redis_replica_1_data:
redis_replica_2_data:
`` * 全てのRedisおよびSentinelサービスは、redis_netという共通のネットワークに属します。これにより、サービス名（redis-master,redis-replica-1など）を使って互いに通信できます。 *depends_on`は起動順序を制御します。SentinelはRedisインスタンスの起動を待ちます。
HA構成の起動:

bash docker-compose -f my-redis-ha/docker-compose.yml up -d
動作確認とフェイルオーバーテスト:
- 現在の状態を確認:
  任意のSentinelのCLIに接続し、INFO Sentinelコマンドを実行します。
  
  bash docker-compose -f my-redis-ha/docker-compose.yml exec redis-sentinel-1 redis-cli -p 26379 INFO Sentinel
  mastersセクションでmymasterの状態がokであること、slaves（レプリカ）が認識されていることを確認します。
- マスターへの接続:
  アプリケーションは、Sentinelに接続してマスターの情報を取得し、そのマスターに接続するように実装します。Python redisライブラリの場合、Sentinelクラスを利用します。
  
  “`python
  
  アプリケーションからのRedis接続例 (HA構成向け)
  
  from redis.sentinel import Sentinel
  
  sentinels = [(‘redis-sentinel-1’, 26379), (‘redis-sentinel-2’, 26379), (‘redis-sentinel-3’, 26379)]
  
  sentinel_client = Sentinel(sentinels, socket_timeout=0.1, password=’your_strong_password_here’) # パスワードがある場合
  
  sentinel_client = Sentinel(sentinels, socket_timeout=0.1)
  
  master = sentinel_client.master_for(‘mymaster’, socket_timeout=0.1)
  replica = sentinel_client.slave_for(‘mymaster’, socket_timeout=0.1) # Python 4.xではslave_forはreplica_forに名称変更
  
  master.set(‘mykey’, ‘HA Test’)
  print(f”Master set: {master.get(‘mykey’)}”)
  “`
- 手動フェイルオーバーテスト:
  マスターコンテナを停止します。
  
  bash docker stop redis-master
  しばらく待つと（down-after-millisecondsで設定した時間後）、Sentinelがマスターのダウンを検知し、レプリカのいずれかを新しいマスターに昇格させるフェイルオーバープロセスを開始します。
  Sentinelのログを確認すると、フェイルオーバーのメッセージが表示されるはずです。
  
  bash docker-compose -f my-redis-ha/docker-compose.yml logs redis-sentinel-1
  新しく昇格したマスターのコンテナ名を確認するには、再度INFO Sentinelを実行します。
  
  bash docker-compose -f my-redis-ha/docker-compose.yml exec redis-sentinel-1 redis-cli -p 26379 INFO Sentinel
  そして、停止したredis-masterコンテナを再度起動すると、それは新しいマスターのレプリカとして参加するはずです。
  
  bash docker start redis-master

このSentinel構成は、Redisの高い可用性を実現するための強力な手段です。

Redis Cluster: より大規模なデータセットや高いスループットを必要とする場合、Redis Clusterが選択肢となります。データが複数のノードにシャーディング（分散）され、自動的なフェイルオーバーとノードの追加・削除が可能です。ただし、設定はSentinelよりも複雑になります。本記事では詳細な構築は割愛します。

バックアップとリカバリ

データの永続化設定を行っていても、災害やオペレーションミスに備えて定期的なバックアップは重要です。

RDB/AOFファイルの取得:
永続化を設定していれば、コンテナの/dataディレクトリにdump.rdbやappendonly.aofファイルが生成されます。これらのファイルをホストOSにコピーすることでバックアップを作成できます。

“`bash

現在のRedisコンテナ名を確認

docker ps –filter “name=my-compose-redis”

コンテナからファイルをコピー

docker cp my-compose-redis:/data/dump.rdb ./redis_backup/dump.rdb
docker cp my-compose-redis:/data/appendonly.aof ./redis_backup/appendonly.aof
“`
Dockerボリュームを使用している場合は、そのボリュームがホスト上のどこにマウントされているかを確認し、直接ファイルをコピーすることも可能です。
リカバリ:
バックアップしたファイルを新しいRedisコンテナの/dataディレクトリに配置して起動すれば、データが復元されます。Docker Composeでボリュームをマウントしていれば、バックアップファイルをボリューム内に配置することで復元が可能です。
自動バックアップ戦略:
- Cronジョブ: ホストOSのcronを使って、定期的にdocker cpコマンドを実行し、RDB/AOFファイルをバックアップディレクトリにコピーします。
- Docker Volume Backupツール: tianon/docker-volume-backupのようなツールや、Restic, BorgBackupなどの汎用バックアップツールをコンテナ内で利用する。
- クラウドストレージへの同期: バックアップファイルをS3などのクラウドストレージにアップロードします。

7. 実践的なヒントとトラブルシューティング

RedisとDockerを組み合わせて運用する際に役立つヒントと、一般的なトラブルシューティングの方法について解説します。

コンテナの健康チェック (`HEALTHCHECK`)

本番環境では、コンテナが起動しているだけでなく、「正常にサービスを提供できる状態」であるかを監視することが重要です。DockerのHEALTHCHECK命令を使うと、コンテナのヘルスステータスを自動でチェックできます。

docker-compose.ymlのredisサービスにhealthcheckを追加する例:

“`yaml

docker-compose.yml (healthcheck追加)

version: ‘3.8’

services:
redis:
image: redis:latest
container_name: my-compose-redis
volumes:
– redis_data:/data
command: redis-server –appendonly yes
restart: always
healthcheck: # ヘルスチェック設定
test: [“CMD”, “redis-cli”, “–raw”, “INFO”] # redis-cliでINFOコマンドを実行
interval: 5s # 5秒ごとにチェック
timeout: 5s # 5秒でタイムアウト
retries: 5 # 失敗したと判断するまでのリトライ回数
start_period: 10s # コンテナ起動後、最初の10秒はチェックを待つ

volumes:
redis_data:
`` この設定により、Dockerは5秒ごとにredis-cli INFOコマンドを実行し、Redisサーバーが応答するかをチェックします。docker psのSTATUSカラムにhealth: starting,health: healthy,health: unhealthy`が表示されるようになります。

Docker Hubの公式イメージの活用

Docker Hubの公式イメージ（例: redis）は、ベストプラクティスに従って構築されており、セキュリティスキャンも行われているため、安心して使用できます。また、様々なバージョンのタグが提供されているため、特定のRedisバージョンが必要な場合にも対応できます。

docker pull redis:7.0.10のように、バージョンタグを指定して特定のバージョンを利用するのが推奨されます。latestは予期せぬ変更をもたらす可能性があるため、本番環境では避けるべきです。

メモリ使用量の確認

Redisはインメモリデータベースなので、メモリ使用量の監視は非常に重要です。

Dockerコマンド:
bash docker stats <container_id_or_name>
実行中のコンテナのリソース使用量（CPU、メモリ、ネットワークI/O、ディスクI/O）をリアルタイムで確認できます。
Redis INFO memoryコマンド:
Redis自身が報告するメモリ使用量を確認できます。used_memory_humanが実際に使用しているメモリ量です。
bash docker-compose exec redis redis-cli INFO memory

ログの確認とデバッグ

docker logs <container_name>: Redisコンテナの標準出力/エラー出力は、このコマンドで確認できます。エラーメッセージや警告はここに出力されます。
docker exec -it <container_name> bash（またはsh）: コンテナ内でシェルを起動し、手動でファイルを調べたり、コマンドを実行したりしてデバッグできます。
redis-cli DEBUGコマンド: Redisのデバッグ機能。例えばDEBUG SEGFAULTで意図的にクラッシュさせることも可能です。

ネットワーク関連のトラブルシューティング

ポートが公開されていない: docker psでPORTSカラムを確認し、期待通りにポートがマッピングされているか確認します。
コンテナ間の通信問題: Docker Composeを使用している場合、サービス名がDNS名として解決されることを確認します。例えば、Webサービスからredisというホスト名でRedisに接続できない場合、webコンテナ内でping redisを実行してみるなどして、ネットワーク接続をテストします。
Firewall: ホストOSのファイアウォール（iptables, ufwなど）がDockerコンテナからの、またはコンテナへの通信をブロックしていないか確認します。

`docker system prune`でのクリーンアップ

Dockerを長く使っていると、不要なイメージ、コンテナ、ボリューム、ネットワークなどが蓄積され、ディスクスペースを消費します。定期的にクリーンアップしましょう。

警告: このコマンドは削除してよいものをよく確認してから実行してください。特にボリュームは、永続化されたデータが含まれる場合があります。

bash docker system prune # 停止中のコンテナ、未使用のネットワーク、ダングリングイメージ、ビルドキャッシュを削除 docker system prune -a # 全ての停止中のコンテナ、使用されていないイメージを削除 (注意深く！) docker volume prune # 使用されていないボリュームを削除
各コマンドは、削除されるオブジェクトのリストを表示し、確認を求めます。

8. まとめ

本記事では、「Dockerを使ったRedis入門：基礎から活用までを徹底解説」と題し、RedisとDockerのそれぞれの基礎から、両者を組み合わせた環境構築、そしてセキュリティ、高可用性、パフォーマンスといった高度なトピックまで、幅広く深く掘り下げてきました。

RedisとDockerの組み合わせのメリットを再確認

迅速な環境構築: docker runやdocker-compose upコマンド一つで、Redis環境を瞬時に立ち上げられます。
開発環境の統一: チームメンバー間で全く同じRedis環境を共有でき、「私のマシンでは動くのに」問題を解消します。
ポータビリティ: 開発から本番まで、どこでも同じコンテナが動作するため、デプロイがスムーズになります。
リソースの隔離と効率性: Redisは他のアプリケーションから独立したコンテナで動作し、ホストOSのリソースを効率的に利用します。
拡張性と高可用性: Docker Composeやコンテナオーケストレーションツール（Kubernetesなど）を活用することで、Redis SentinelやRedis Clusterといった高可用性構成を容易に実現できます。
運用管理の簡素化: ログ収集、監視、バックアップといった運用タスクも、Dockerの仕組みと連携させることで効率化されます。

Redisは単なるキャッシュツールではなく、リスト、セット、ハッシュ、ソート済みセットといった多彩なデータ構造を駆使することで、アプリケーションの様々な要件を満たす強力なデータストアであることを学びました。そして、そのRedisの能力を最大限に引き出すのがDockerというコンテナ技術です。

次なるステップ

本記事で得た知識は、あなたの開発・運用スキルを次のレベルへと押し上げるための強固な基盤となるでしょう。ここからさらに学びを深めるための次なるステップをいくつか提案します。

Dockerfileの習熟: 独自のRedisイメージを構築したり、アプリケーションイメージをより最適化したりするために、Dockerfileのベストプラクティスを学ぶ。
Redisのモジュール: Redis Search, RedisJSON, RedisGraphなど、公式・コミュニティ製のRedisモジュールを試してみる。
より高度な高可用性/スケーラビリティ: KubernetesなどのコンテナオーケストレーションツールでRedis SentinelやRedis Clusterをデプロイし、大規模な本番環境での運用を経験する。
監視ツールの統合: PrometheusとGrafanaなどの監視スタックをDocker Composeに追加し、Redisのメトリクスを可視化する。
クラウドサービスとの連携: AWS ElastiCache for Redis, Google Cloud Memorystore for Redis, Azure Cache for Redisなどのマネージドサービスを検討し、自社で運用する手間を削減する方法を学ぶ。

RedisとDockerの組み合わせは、現代のソフトウェア開発において非常に強力なツールセットです。この記事が、あなたのアプリケーション開発と運用に新たな可能性を開く一助となれば幸いです。この知識を活かし、より堅牢で高性能なシステムを構築してください。

Dockerを使ったRedis入門：基礎から活用までを徹底解説

1. はじめに

なぜRedisとDockerなのか？

この記事の目的と対象読者

2. Redisの基礎

Redisとは何か？

Redisの主要なデータ構造と使用例

Redisのユースケース

3. Dockerの基礎

Dockerとは何か？

Dockerの主要なコンポーネント

Dockerの基本的なコマンド

Dockerネットワークの基礎

Dockerボリュームの基礎

Docker Composeの概要

4. DockerでRedisを動かす

基本的なRedisコンテナの起動

1. 最新のRedisイメージをダウンロード (もし持っていなければ)

2. Redisコンテナを起動

-d: デタッチドモード (バックグラウンド実行)

–name my-redis: コンテナに ‘my-redis’ という名前を付ける

-p 6379:6379: ホストの6379番ポートをコンテナの6379番ポートにマッピング

redis: 使用するイメージ名

Redis CLIでの接続と基本操作

実行中のmy-redisコンテナ内でredis-cliを実行

-it: インタラクティブなターミナルセッションを割り当てる

データの永続化

1. Docker Volumesを使用する (推奨)

1. まず、既存のmy-redisコンテナを停止して削除します (もしあれば)

2. Redis用のDockerボリュームを作成します (初回のみ)

3. Redisコンテナを起動し、作成したボリュームをマウントします

-v redis_data:/data: ‘redis_data’という名前のボリュームをコンテナの’/data’ディレクトリにマウント

2. Bind Mountsを使用する

1. 永続化用のディレクトリをホストOS上に作成 (例: ~/redis_data)

2. Redisコンテナを起動し、ホストのディレクトリをマウントします

-v ~/redis_data:/data: ホストの’~/redis_data’ディレクトリをコンテナの’/data’ディレクトリにマウント

設定ファイルの適用

~/redis_config/redis.conf

最大メモリを512MBに設定し、LRU (Least Recently Used) ポリシーで古いキーを削除

Redisログを標準出力に出力 (Dockerのログとして収集するため)

設定ファイルとデータをマウントしてRedisを起動

5. Docker Composeを使ったRedis環境の構築

なぜDocker Composeを使うのか？

docker-compose.ymlの基本構造

単一Redisインスタンスの構築例

docker-compose.yml

サービス名を使ってredis-cliに接続

あるいは、コンテナ名を使って接続

docker exec -it my-compose-redis redis-cli

redis-cliで何かデータを保存

127.0.0.1:6379> SET mytestkey “This data should persist!”

OK

127.0.0.1:6379> SAVE # 明示的にRDBファイルを保存 (AOFが有効なので自動で保存されますが、確認のため)

OK

127.0.0.1:6379> exit

コンテナを停止・再起動

再度接続してデータを確認

127.0.0.1:6379> GET mytestkey

“This data should persist!”

WebアプリケーションとRedisの連携例

app.py

Redisホスト名を ‘redis’ に設定 (docker-compose.ymlのサービス名)

ポートはデフォルトの6379

docker-compose.yml

Dockerfile

6. Redisの高度な活用とDockerでの実践

セキュリティ

1. パスワード認証 (requirepass)

~/redis_config/redis.conf (追記)

docker-compose.yml (更新)

app.py (更新)

… (以下のコードは変更なし)

2. ポートの公開範囲の制限

docker-compose.yml (redisサービスからportsを削除)

監視とログ

パフォーマンス最適化

高可用性（HA）: Redis Sentinel

フェイルオーバータイムアウト

マスターがダウンしたと判断するまでの時間

docker-compose.yml (HA構成)

`docker-compose.yml`の基本構造

1. パスワード認証 (`requirepass`)

コンテナの健康チェック (`HEALTHCHECK`)

`docker system prune`でのクリーンアップ

コメントする返信をキャンセル