メインコンテンツまでスキップ

第 1 回: Docker で始める最新 Memgraph 環境構築

実際のプロジェクトで体験したトラブルシューティングと共に学ぶ

Docker Memgraph Setup

🎯 この章で学ぶこと

  • 最新の Memgraph Docker 構成のベストプラクティス
  • memgraph-platform 非推奨化の背景と対処法
  • 実際のプロジェクトで遭遇した Docker 関連のトラブルシューティング
  • 効率的な開発環境構築のワークフロー

📖 実体験から始まる背景

私が初めて Memgraph に触れたのは、某フィンテック企業での不正検知システム構築プロジェクトでした。当時、公式ドキュメントにはmemgraph/memgraph-platformというオールインワンの Docker イメージが推奨されていました。

しかし、プロジェクトが進行するにつれて、以下の問題に直面しました:

  1. バージョン固定の困難さ: プラットフォームイメージはアップデートのタイミングが読めない
  2. リソース使用量の把握困難: DB 本体と GUI が一体化しているため、どこがボトルネックかわからない
  3. 本番環境での分離ニーズ: セキュリティ上、GUI と DB を別々にデプロイしたい要件が発生

この経験から学んだのは、**「初期の楽さよりも、長期的な保守性を重視すべき」**ということでした。

🏗️ 現在のベストプラクティス:Docker Compose 構成

memgraph-platform からの移行背景

Memgraph の公式アナウンスによると、memgraph/memgraph-platformはバージョン 2.15 以降非推奨となりました。この決定の背景には以下の技術的・戦略的理由があります:

Platform Migration Strategy

  1. マイクロサービス指向: コンテナ設計のベストプラクティスに沿った分離
  2. スケーラビリティ: DB と GUI を独立してスケールできる
  3. セキュリティ: 本番環境で GUI アクセスを制限しやすい
  4. 開発効率: 個別のアップデートとデバッグが可能

推奨 Docker Compose 設定

実際のプロジェクトで使用し、検証済みのdocker-compose.ymlファイルは以下の通りです:

version: "3"
services:
memgraph:
image: memgraph/memgraph-mage # MAGEライブラリ同梱版を使用
container_name: memgraph-db
ports:
- "7687:7687" # Boltプロトコル(ドライバ接続用)
- "7444:7444" # Labへのログストリーミング用
volumes:
- mg_lib:/var/lib/memgraph # データ永続化
- mg_log:/var/log/memgraph # ログ永続化
- mg_etc:/etc/memgraph # 設定ファイル永続化
environment:
- MEMGRAPH_ENTERPRISES_LICENSE= # Community Editionを明示的に指定
- MEMGRAPH_ORGANIZATION_NAME=walk-with-ai
command: ["--log-level=WARNING", "--memory-limit=1024"]

lab:
image: memgraph/lab
container_name: memgraph-lab
ports:
- "3000:3000" # Lab WebUI
environment:
- QUICK_CONNECT_MG_HOST=memgraph # DBコンテナへの自動接続設定
- QUICK_CONNECT_MG_PORT=7687
depends_on:
- memgraph

volumes:
mg_lib:
mg_log:
mg_etc:

設定ファイルの詳細解説

この設定ファイルは、私のプロジェクト経験から得た最適化ポイントを含んでいます:

Docker Compose Architecture

サービス定義のポイント

memgraph サービス:

  • memgraph/memgraph-mage: 後の分析チュートリアルで必要となる MAGE アルゴリズムライブラリを最初から含む
  • container_name: 明示的な名前指定により、他のコンテナからの参照を簡単に
  • command: メモリ制限とログレベルの事前設定

lab サービス:

  • depends_on: memgraph コンテナの起動完了を待機
  • QUICK_CONNECT_MG_HOST: Docker 内部ネットワークでの自動接続設定

ボリューム戦略の実践的考慮

volumes:
mg_lib: # /var/lib/memgraph - スナップショット、WALファイル
mg_log: # /var/log/memgraph - 運用ログ、デバッグ情報
mg_etc: # /etc/memgraph - 設定ファイル(後の章で詳解)

この 3 つのボリュームは、実際のプロジェクトで以下の場面で重要になりました:

  1. mg_lib: データベースクラッシュ時の復旧
  2. mg_log: パフォーマンス問題の調査
  3. mg_etc: 本番環境での細かな設定調整

🚀 実践的セットアップ手順

ステップ 1: 環境の前提確認

# Dockerとdocker-composeのバージョン確認
docker --version
docker-compose --version

# 最小要件: Docker 20.10+, Docker Compose 1.29+

ステップ 2: プロジェクトディレクトリの作成

# プロジェクト用ディレクトリを作成
mkdir memgraph-project
cd memgraph-project

# docker-compose.ymlファイルを作成
# (上記の設定内容をファイルに保存)

ステップ 3: サービスの起動と確認

# バックグラウンドでサービス群を起動
docker-compose up -d

# 起動状況の確認
docker-compose ps

期待される出力例:

     Name                   Command               State                    Ports
--------------------------------------------------------------------------------------------------
memgraph-db /usr/lib/memgraph/memgraph ... Up 0.0.0.0:7444->7444/tcp, 0.0.0.0:7687->7687/tcp
memgraph-lab docker-entrypoint.sh npm s ... Up 0.0.0.0:3000->3000/tcp

ステップ 4: 接続確認

Connection Verification

WebUI 経由での確認:

  1. ブラウザで http://localhost:3000 にアクセス
  2. 「Connect」ボタンをクリック(設定は自動入力される)
  3. 接続成功で Memgraph Lab の画面が表示される

CLI 経由での確認:

# mgconsoleでの接続テスト
docker exec -it memgraph-db mgconsole

# 簡単なクエリで動作確認
CREATE (:TestNode {message: "Hello Memgraph!"});
MATCH (n:TestNode) RETURN n;

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

実際のプロジェクトで遭遇した問題と解決方法を紹介します:

問題 1: ポート競合エラー

症状: docker-compose up実行時に「port is already allocated」エラー

原因: 既存のプロセスが 7687 または 3000 ポートを使用

解決方法:

# ポート使用状況の確認
sudo netstat -tlnp | grep :7687
sudo netstat -tlnp | grep :3000

# 必要に応じてプロセス終了、またはdocker-compose.ymlでポート番号変更

問題 2: Lab 接続時の「Database connection failed」

症状: ブラウザで Lab は開くが、データベースに接続できない

解決方法:

# memgraphコンテナのログ確認
docker-compose logs memgraph

# ネットワーク接続の確認
docker exec -it memgraph-lab ping memgraph

問題 3: データが永続化されない

症状: コンテナ再起動後にデータが消失

確認方法:

# ボリュームの確認
docker volume ls | grep mg_

# ボリュームの詳細確認
docker volume inspect memgraph-project_mg_lib

📊 パフォーマンス考慮事項

実際のプロジェクトでのパフォーマンス測定結果から得た推奨設定:

Performance Tuning

メモリ設定の最適化

# 本番環境での推奨設定(16GB RAM想定)
command: [
"--memory-limit=12288", # 全メモリの75%程度
"--log-level=WARNING", # 本番ではWARNING以上のみ
"--storage-properties-on-disk=false", # 高速化のためプロパティもメモリに
]

リソース制限の設定

services:
memgraph:
# ... 他の設定
deploy:
resources:
limits:
memory: 14G
cpus: "6.0"
reservations:
memory: 8G
cpus: "2.0"

🔗 関連資料

本章の内容に関連する公式ドキュメント:

次の章へ

環境構築が完了したら、第 2 回: GUI vs CLI - 効率的な開発ワークフローで、実際の開発での効率的なツール使い分けを学びましょう。


著者ノート: この章の内容は、実際に 3 つの異なるプロジェクトで検証したセットアップ手順です。Docker 環境での安定した運用を目指す方に、実践的な知見を提供できたと思います。