Docker化した時系列モデルに「記憶」を持たせる:RedisとDockerボリュームで状態を永続化する実践ガイド

売上予測や株価予測ができる優秀な時系列モデルを作ったのに、いざ本番環境にデプロイしたら動かなくなった——そんな経験はありませんか?これはよくある悩みです。ローカルマシンでは完璧に動いていたモデルが、Dockerコンテナにデプロイした途端、「記憶喪失」になったかのように、昨日学んだことをすべて忘れてしまい、明日の予測がまったく役に立たなくなるのです。

しかし心配はいりません。これはモデルの欠陥ではありません。時系列モデルの設計思想と、Dockerコンテナの設計思想が根本的に衝突していることが原因です。

時系列モデルは「記憶」が命です。過去を記憶してこそ未来を予測できます。一方、Dockerコンテナはステートレス(状態を持たない)であることを前提に作られており、再起動のたびにメモリがまっさらになります。この根本的な矛盾により、強力なモデルが本番環境では無価値なものへと変わってしまうのです。

本記事ではこの問題を解決します。時系列モデルに「永続的な記憶」を与える方法を学びましょう。具体的には、Redisをモデルの外部脳として使い、Dockerボリュームによってその記憶をどんな再起動にも耐えられるようにします。ハンズオン形式の例題を一歩ずつ進めながら、賢くて信頼性の高いシステムの構築方法を身につけられます。

この記事で扱う内容

• この記事はこんな人におすすめ
• 問題の理解
  • そもそも時系列モデルとは?
  • 問題1:コンテナは設計上、揮発的
  • 問題2:予測間でのコンテキスト消失
  • 問題3:再起動時のモデルの記憶喪失
• 解決策:外部状態ストア
• ハンズオン実装
  • まずは壊れたアプローチから
  • ボリュームで修正する方法
  • コードが状態を処理する仕組み
  • ヘルスチェックエンドポイントのテスト
• スケーリングについて
  • Redis Clusterによる水平スケーリング
  • Redis Sentinelによる高可用性
  • マネージドRedisサービスの活用
• 避けるべき落とし穴
• まとめ

この記事はこんな人におすすめ

このチュートリアルを最大限に活用するために、いくつか準備しておくと良いものがあります。コードやコマンドライン操作を含むため、少しの下準備が大きな助けになります。

• このプロジェクトの主なツールはDockerとDocker Composeです。お使いのマシンにインストールし、起動しておいてください。
• Docker、Python、Flaskフレームワークの基礎に慣れていると、内容を追いやすくなります。チュートリアル内のコマンドを実行するので、コマンドラインの基本的な経験もあると便利です。
• ただし、Redisを使ったことがなくても心配いりません。知っておくべきことは「高速なインメモリデータベースである」という一点だけです。あとは記事の中で順に説明します。

これをガイド付きツアーだと思ってください。好奇心さえあれば、基本的なツールが揃っている限り、十分に楽しめます。

問題の理解

解決策に入る前に、まず時系列モデルとは何かを明確にし、なぜそれをコンテナ化することが難しいのかを見ていきましょう。

そもそも時系列模型とは?

簡単に言えば、時系列モデルとは時間の経過とともに収集されたデータポイントを分析し、将来の値を予測するモデルです。天気予報を想像してみてください。気象学者は今の空だけを見ているわけではありません。過去数時間〜数日間の気温、気圧、風のパターンを見て、明日の天気を予報します。

時系列モデルもデータに対して同じことを行います。対象はウェブサイトのアクセス数でも、株価でも、エネルギー消費量でも構いません。重要なのは「履歴こそがすべて」という点です。過去の出来事の連なりが、未来に関する知的な予測に必要な文脈を提供してくれるのです。

さて、このようなモデルをDockerに載せると何が壊れるのでしょうか。

問題1:コンテナは設計上、揮発的

Dockerコンテナはステートレスであることを意図しています。これはほとんどのAPIにとって素晴らしい特性です。ユーザープロフィールのエンドポイント?ステートレスでOK。感情分析モデル?ステートレスでOK。入力を受け取り、出力を返し、その間のことはすべて忘れる——それで正しく機能します。

しかし時系列モデルはそうはいきません。過去の予測からのコンテキストが必要です。それがなければ、あなたのモデルは実質的に「盲目」になってしまうのです。

問題2:予測間でのコンテキスト消失

各予測が完全に孤立して実行されます。モデルは単一のデータポイントを受け取り、その前に何があったのかを知らないまま推測を行います。これでは時系列モデリングの目的そのものが台無しです。

「リクエストのたびに全履歴データを読み込めばいいのでは?」と思うかもしれません。しかしそのアプローチには2つの理由で失敗します。

• 遅い。数千件のデータポイントがある場合、本当に遅くなります。
• スケールしない。複数の時系列や高頻度のリクエストを扱うようになると、すぐにパフォーマンスの壁にぶつかります。

問題3:再起動時のモデルの記憶喪失

新しいバージョンをデプロイしたり、コンテナがクラッシュしたりするたびに、蓄積された状態はすべて消えます。モデルはゼロからやり直しです。本番環境では到底許容できません。

解決策：外部状態ストア

状態をコンテナの中に置く代わりに、外に出しましょう。Redisがモデルの記憶装置になります。

アーキテクチャの全体像は次の通りです。

クライアントリクエスト → Flask API → Redis → コンテキスト付き予測

コンテナ自体はステートレスで交換可能なまま保たれます。しかしシステム全体としては、Redisを通じて状態を維持できるのです。

ハンズオン実装

それでは実際に構築してみましょう。まずデモリポジトリをクローンします。

git clone https://github.com/ag-chirag/docker-redis-time-series
cd docker-redis-time-series

まずは壊れたアプローチから

docker-compose.initial.ymlファイルは、やってはいけない例を示しています。

services:
 api:
 build: ./flask-api
 ports:
 - "5000:5000"
 redis:
 image: redis:alpine

何が足りないかに気づきましたか?ボリュームがありません。Redisはデータをコンテナのファイルシステムに保存するため、データは一時的なものになります。

起動してみましょう。

docker compose -f docker-compose.initial.yml up

いくつか予測リクエストを送ります。

curl -X POST https://localhost:5000/predict \
 -H "Content-Type: application/json" \
 -d '{
 "series_id": "demo",
 "historical_data": [
 {"timestamp": "2024-01-01T12:00:00", "value": 10},
 {"timestamp": "2024-01-01T12:01:00", "value": 20},
 {"timestamp": "2024-01-01T12:02:00", "value": 30}
 ]
 }'

Redisが正常に動作していることを示すレスポンスが返ってきます。

{
 "data_points_used": 3,
 "prediction": 40,
 "redis_connected": true
}

ここでサービスを再起動します。

docker compose down
docker compose -f docker-compose.initial.yml up

もう一度予測を実行し、data_points_usedフィールドを確認してください。値がリセットされています。履歴データはすべて消えてしまったのです。まさに私たちが避けたい状況です。

ボリュームで修正する方法

正しいdocker-compose.ymlは永続化を追加しています。

services:
 api:
 build: ./flask-api
 ports:
 - "5000:5000"
 environment:
 - REDIS_HOST=redis
 redis:
 image: redis:alpine
 command: redis-server --appendonly yes
 volumes:
 - redis_data:/data
volumes:
 redis_data:

そもそもボリュームとは?仕組みは?

Dockerボリュームは、コンテナ専用の「外付けハードディスク」と考えてください。デフォルトでは、コンテナが書き込むデータは一時レイヤーに保存され、コンテナ削除時に破棄されます。ボリュームを使えば、そのデータを恒久的に保存できます。

仕組みは以下の通りです。

1. Dockerはホストマシン上に、どのコンテナのファイルシステムとも独立した特別なストレージ領域を作成・管理します。docker-compose.yml の下部にある volumes: redis_data: セクションは、redis_dataという名前付きボリュームの作成をDockerに指示しています。
2. Redisコンテナが起動するとき、volumes: - redis_data:/data の行が「外付けハードディスクの接続」を指示します。これにより redis_data ボリュームが、コンテナ内の /data ディレクトリにマウントされます。
3. 以降、コンテナ内のRedisプロセスが /data ディレクトリにデータを書き込むたびに(そのように設定済み)、実際にはホストマシン上の redis_data ボリュームに書き込まれます。
4. docker compose down を実行するとRedisコンテナは破棄されますが、redis_data ボリュームは無傷です。外付けハードディスクを抜くようなもので、データは安全なまま残ります。次に docker compose up を実行すると、真新しいRedisコンテナが作成され、ボリュームが再接続され、Redisは以前のデータをそのまま見つけられます。

この仕組みこそが、ステートフルなサービスに「再起動に耐える記憶」を与える鍵となります。

修正版を起動しましょう。

docker compose up --build

状態を蓄積するために複数回予測を送ります。

for i in {1..5}; do
 curl -X POST https://localhost:5000/predict \
 -H "Content-Type: application/json" \
 -d "{\n \"series_id\": \"demo\",\n \"historical_data\": [{\"timestamp\": \"2024-01-01T12:0$i:00\", \"value\": $((i*10))}]\n }"
done

さて、ここからが本番のテストです。すべてを再起動します。

docker compose down
docker compose up

もう一度予測を実行し、data_points_usedを確認してください。過去の全データポイントが含まれています。モデルは中断した箇所からぴったり再開できるのです。

これが機能するのは、ボリュームがコンテナのライフサイクルから独立して存在しているからです。

コードが状態を処理する仕組み

flask-api/app.py のFlask APIは、ソート済みセット(sorted set)を使って各データポイントをRedisに保存します。

def store_data_point(series_id, timestamp, value):
 key = f"ts:{series_id}"
 redis_client.zadd(key, {json.dumps({"ts": timestamp, "val": value}): timestamp})

予測時には最近の履歴を取得します。

def get_recent_data(series_id, limit=100):
 key = f"ts:{series_id}"
 data = redis_client.zrange(key, -limit, -1)
 return [json.loads(d) for d in data]

Redisのソート済みセットを使えば、時刻順の並べ替えは自動的に行われます。そしてボリュームが、このデータを再起動後も確実に保持してくれるのです。

ヘルスチェックエンドポイントのテスト

すべてが正しく接続されているか確認しましょう。

curl https://localhost:5000/health

次のようなレスポンスが得られるはずです。

{
 "model_loaded": true,
 "redis_connected": true,
 "status": "healthy"
}

redis_connected が false の場合は、Dockerのログを確認してください。よくある原因はネットワーク設定の不備や、Redisが正常に起動していないことです。

スケーリングについて

この構成はシングルインスタンスのデプロイには十分機能します。トラフィックが増えた場合には、いくつかの選択肢があります。

Redis Clusterによる水平スケーリング

高いスループットが必要な場合は、複数のRedisノードにデータを分散させましょう。Redis Clusterはシャーディングを自動的に処理してくれます。

Redis Sentinelによる高可用性

フェイルオーバー機能を追加すれば、状態ストアが単一障害点になることを防げます。SentinelはRedisインスタンスを監視し、プライマリに障害が発生するとレプリカを昇格させます。

マネージドRedisサービスの活用

AWS ElastiCache、Azure Cache for Redis、Google Cloud Memorystoreなどのマネージドサービスを使えば、運用負担を任せられます。あなたはモデル開発に集中し、Redisの信頼性はクラウド事業者が担当します。

重要なポイントはこうです。APIコンテナはステートレスのまま保ち、状態ストアだけを独立してスケールさせる。

避けるべき落とし穴

繰り返し強調しますが、本番デプロイ前に必ず永続化をテストしてください。

ボリュームが機能すると思い込まない

実際にコンテナを再起動し、状態が保持されることを確認しましょう。本番環境でボリュームのマウントを忘れたせいでデプロイが失敗したケースを、筆者は実際に見たことがあります。

Redisのメモリ上限を無視しない

Redisはすべてをメモリ上に保持します。メモリ使用量を監視し、ワークロードに適した maxmemory ポリシーを設定してください。メモリが枯渇すると、Redisはキーの退去(eviction)を始めるか、書き込みを拒否します。

監視を省略しない

ヘルスチェックを追加し、Redisの接続状態を監視し、予測のレイテンシを追跡しましょう。障害が発生したときにすぐ検知できるようにすべきです。怒ったユーザーからの苦情で初めて気づく、なんてことにならないように。

まとめ

時系列モデルには記憶が必要です。Dockerコンテナはデフォルトでは記憶を失います。解決策はシンプル——状態とコンピューティングを分離することです。

Redisを外部状態ストアとして使い、Dockerボリュームでその状態を永続化しましょう。そうすればモデルは賢いまま、コンテナは交換可能なまま、そしてデプロイは信頼できるものになります。

完全に動作するコードは github.com/ag-chirag/docker-redis-time-series で公開されています。クローンして、実行して、壊してみて、そこから学んでください。

最後に覚えておいてほしいのは、動作する最もシンプルな解決策が、たいていの場合、正しい解決策だということです。必ずしもKubernetesやStatefulSetが必要なわけではありません。Docker Composeとボリュームだけで十分なこともあるのです。

無料でプログラミングを学ぼう。freeCodeCampのオープンソースカリキュラムは、これまでに4万人以上の人々を開発者の仕事へと導いてきました。さあ、始めてみましょう。