FrontierStack で Redis を Docker で動かし、監視する

公開 2026-09-02

Redis は十分に高速なため、その存在を忘れられがちです。メモリ上限に達し、アプリケーションが残っていると想定していたキーをエビクトし始めるまでは。加えて、インターネットに開放されたまま放置されてきた不幸な歴史もあります。本ガイドでは両方を扱います。

ネイティブかコンテナか

サービス ▸ Redis はネイティブに導入します（Homebrew の formula、brew services のエントリ、ペインからの起動・停止）。ただし一般的な用途にはコンテナが適します。Redis は通常 1 つのアプリケーションの依存物であり、専用コンテナに入れればその関係が保たれます。使い捨て可能で、バージョンが明確で、プロジェクトの終了とともに消えます。

コンテナを作成する

Docker ペイン ▸ コンテナを作成… ▸ Redis プリセットで、ポート 6379、127.0.0.1 のみにバインドされた redis:alpine が得られます。

このバインド既定には独立した説明が必要です。パスワードなしで 0.0.0.0 に待ち受ける Redis は、インターネット上で最も確実に悪用される設定ミスのひとつで、自動スキャナが数時間で発見します。プリセットは localhost にバインドするため、何も変更しなければ安全な状態になります。解除する場合は、同じ作業のうちに requirepass を設定してポートをファイアウォールで塞ぎ、その後 セキュリティ ▸ 開放ポートで実際の待ち受け状態を確認してください。

ここで検討すべき選択肢が二つあります。プリセットにボリュームはなく、純粋なキャッシュ用途にはそれが正解ですが、データストアとして使うなら /data にボリュームを追加しないと再起動で全消失します。永続化が必要なら、詳細設定で --appendonly yes 相当の引数も追加してください。

実行前にコマンドを読む

プレビューは実際の docker run コマンドを表示するため、実行前にバインドアドレスとフラグを確認できます。作成を押すと、ログ・シェル・起動／停止／再起動を備えたコンテナが Docker ペインに現れます。

リンク済みサーバ上でも

フリート内の任意のホストにシートを向ければ、SSH 経由でそこにコンテナが作成されます。

何を監視するか

Redis はデータベースヘルスが対応する 5 エンジンのひとつで、専用ツールを用意せずとも SQL サーバと並べて扱えます。注視すべき数値は、maxmemory に対する使用量、エビクション数、直近のバックグラウンド保存の成否、接続クライアント数です。

見落とされがちな障害は永続化です。bgsave が失敗し続けていると（多くはディスクか権限の問題）、Redis はメモリから完璧に応答し続け、次回の再起動ですべて失われます。まさにダッシュボードではなくアラートに値する、静かな障害です。

AI 管理者に尋ねる

「アプリサーバの Redis は健全か、そして外部に公開されていないか？」と尋ねれば、メモリ状況・永続化の状態・バインドアドレスをまとめて回答します。

アプリ内のどこにあるか

実際の作業は データベース ▸ データベースヘルス ペインが担います。対象を選ぶと、稼働中の接続をすべて一覧表示し、注意すべきものを強調し、MySQL と PostgreSQL については、ログから推測するのではなく稼働中のサーバに対して「なぜ遅い／固まっているのか」を診断します。

データベースホストにエージェントをインストールする必要はありません。FrontierStack は既存の鍵を使って SSH でリンク済みサーバに接続し、データベース自身の管理インターフェース経由で読み取ります。

必要になる前にアラートを設定する

監視が役立つのは、壊れる前の瞬間です。フリートにホストを追加し、データベースヘルスを向け、チェックを定期実行させます。停止したデータベースは「問題なし」ではなく「データなし」として現れるため、明示的なアラートこそが、静かな障害を実際に届く通知へと変えます。