Z-CMS が server restart なしで plugin を load する仕組み

Restart 前提の plugin management が scale しない理由

Plugin install のたびに server を restart する方式は個人 website では許容できます。しかし、多数の tenant、active session、background job、real-time connection を扱う CMS では disruption になります。Z-CMS は plugin を独立して install、activate、drain、replace、remove できる managed runtime として扱います。

Dynamic import は最初の一歩にすぎない

Dynamic import は code を load できますが、安全な unload は提供しません。Module cache、古い event listener、cron job、database connection が残る可能性があります。Hot plugin management は module loading の工夫ではなく lifecycle の問題です。

Plugin lifecycle

基本 lifecycle は Downloaded → Verified → Installed → Initialized → Activated → Running → Deactivated → Uninstalled です。

Update では、新 version の download、signature verification、compatibility validation、migration check、新 runtime の start、health check、active version switch、旧 runtime の drain を行います。

Downloaded → Verified → Installed → Initialized
→ Activated → Running → Deactivated → Uninstalled

Manifest-driven initialization

Manifest は entry point、対応 CMS version、必要 permission、登録 hook、migration を Core に伝えます。Activation と health check が成功するまで runtime は production event を受け取りません。

Hard-coded call ではなく hook registry

Core service は event を registry に dispatch します。Registry は active plugin を resolve し、適切な isolate に execution を route します。Plugin を disable すると registration は即座に削除され、application restart は不要です。

Current Runtime A (Active)
New Runtime B (Starting)
        ↓
Load → Activate → Health Check
        ↓
Registry Switch A → B
        ↓
Runtime A Draining

Managed resource と deactivation

Plugin は listener、schedule、subscription、temporary resource を作成できます。SDK は registration を managed API 経由にし、Z-CMS が resource ownership を記録して deactivate 時に自動 cleanup できるようにします。

適切な deactivate method は推奨されますが、Core cleanup は plugin developer の実装だけに依存しません。

Blue-green plugin update

新 version は現行 version と並行して start します。Load、activate、smoke test に成功してから registry pointer を切り替えます。Health check に失敗した場合、旧 version が active のまま残ります。

Active execution の draining

旧 runtime は新しい execution の受付を停止し、進行中の処理だけを継続します。Active execution counter と maximum drain timeout により、不要な request interruption を防ぎます。

Migration、rollback、versioned storage

Plugin update に data migration が含まれる場合、Z-CMS は migration ID と recovery point を記録し、compatibility check と新 runtime start を完了してから switch を commit します。Reversible migration は activation failure 時に自動 rollback できます。

以前の verified bundle を保持することで、迅速な rollback と再現可能な incident investigation が可能になります。

Circuit breaker と development mode

失敗を繰り返す plugin は Active から Degraded、Suspended へ移行できます。Development mode では file watcher が bundle を rebuild し、新 isolate を作成して activation 後に runtime を swap するため、backend 全体を restart せずに hot reload できます。

結論

Server restart なしの plugin load には、validation、runtime creation、registry switching、managed cleanup、draining、migration handling、rollback、health monitoring を含む完全な lifecycle が必要です。Z-CMS は plugin version を交換可能な runtime unit として扱います。

Key takeaways

• Security boundary は plugin の善意ではなく Core 側で enforce する必要があります。
• Lifecycle、permission、tenant context、observability は同じ platform contract の一部です。
• 優れた developer experience は、安全な runtime と supply chain の設計によって持続可能になります。

GitHub: https://github.com/zscontributor/z-cms
Website: https://z-cms.org