HestiaからDirectAdminへのPrestaShop移行

HestiaからDirectAdminへのPrestaShop移行

PrestaShopの移行は、全体のスタックを移動することを意味する必要はありません。この場合、私は古いHestiaセットアップから新しいDirectAdminベースのホストにバックエンドを一晩で移動しました。フロントエンドは既存のプラットフォームに留まりました。ニュースレターとCRMサービスはそのままです。範囲は狭く、新しいバックエンドがマルチストアeコマースシステムのREST API、キャッシュ、cronを処理できるようにしました。

アクティブな作業は約3〜4時間かかりました。ファイル転送は簡単な部分でした。本当の仕事は、ルーティング、Redis、cron、キャッシュ無効化、ストア固有のAPIレスポンスが移行後も正しく機能することを証明することでした。

PrestaShop移行で移動したもの

バックエンドは、NVMeストレージ、割り当てられたCPU、割り当てられたRAMを備えた現代的な共有ホスティングプランに配置されました。ホスティングパネルは、期待されるパッケージとディスククォータを報告しました。

私はすべてを移動しませんでしたが、それは意図的でした。

移動したもの:

そのまま残したもの:

私はこのような狭いPrestaShop移行を好みます。なぜなら、ノイズを減らすからです。フロントエンド、マーケティングスタック、バックエンドを同時に移動すると、変数が多すぎます。ここでは、検証するための明確なビジネスシステムが1つ必要でした。

ルーティングが最初の問題だった

PrestaShopはマルチショップバックエンドとして動作します。つまり、1つのバックエンドが2つのストアに対して正しく応答する必要があります。古いホストでは、パネルルールと既存のURL動作が複雑さの一部を隠していました。新しいホストでは、REST呼び出しがPrestaShopがリクエストをリダイレクトまたは正規化する前にストアコンテキストを保持する必要がありました。

修正は、ストアプレフィックス付きのREST呼び出しを正しくルーティングすることでした:

それは紙の上では小さなことのように見えます。実際には、これはファイル、データベース、DNSが正しくても、移行が壊れていると感じさせるような詳細です。私の作業では、PHP、Redis、またはデータベースを責める前にルーティングを確認します。

Redisは助けになったが、キャッシュクリアがより重要だった

RedisはUnixソケットを介して有効化されました:

text /home/account/.redis/redis.sock

その後、PrestaShopはRedisをキャッシュバックエンドとして使用しました。APIレスポンスは改善されましたが、キャッシュは適切なタイミングでクリアされる場合にのみ重要です。

バックオフィスは真実の源です。誰かがPrestaShopで価格、商品説明、PageBuilderブロック、カテゴリ、またはキャンペーンを変更すると、フロントエンドAPIは新しいデータを提供しなければなりません。キャッシュを有効にするだけでは不十分です。私は、キャッシュクリアを関連するPrestaShopフックに接続する必要がありました。

私は直接その動作を確認しました:

それが「キャッシュが有効化されている」と「キャッシュが信頼できる」の違いです。eコマースでは、その違いはすぐに重要です。

Cronジョブには慎重なフィルタリングが必要だった

最初のHestia cronチェックでは、PrestaShopバックエンドに属さない別のサービスに属するジョブが見つかりました。それらのジョブは新しいホストには属さなかったため、この移行の一部ではありませんでした。

関連するPrestaShopジョブは古いライブHestiaサーバーにありました:

私は一時停止されたCRMジョブを移行しませんでした。また、Hestiaの内部システムジョブもスキップしました。DirectAdminには独自のメンテナンスとバックアップフローがあるため、パネルのゴミをコピーすることは混乱を招くだけです。

1つのデータベースダンプジョブは、慎重な開発ダンプとして最初にマッピングされました。ホスティングパネルがすでにバックアップを処理していることを確認した後、私はそれを削除しました。バックアップフローを複製することは、明確な回復理由がない限りノイズを生み出します。

バックエンド移動からのパフォーマンス結果

私は同じ公開RESTエンドポイントをストアごとに12回テストしました:

text /rest/pagebuilder/placements

結果は次のとおりです:

ステージサーバーはシンプルなリファレンスサーバーで、一貫して応答しました。新しいホストは両方のストアに対して依然としてより速く応答しました。

新しいホストはまた、サーバーロード平均が高く、約10-13を示しました。SSHは物理ホスト上のCPUスレッドをアカウントの割り当てよりも多く露出させたため、その数字自体は驚くべきものではありませんでした。アカウントは静かに見えました: Redisはほぼアイドル状態で、PHPワーカーはCPUを駆動せず、データベースは私が確認したときに低いアクティブクエリ負荷でした。

それが、私は共有ホスティングでロード平均を慎重に扱う理由です。それはホストを反映し、単に1つのアカウントだけではありません。プロバイダーが明確なCPUおよびRAM仕様を持つプランを販売している場合でも、CloudLinuxやLVEを通じてそれらの制限がどのように施行されるかを尋ねることは依然として役立ちます。

移行のための私のAIワークフロー

私はSSH、DirectAdmin API作業、サーバーチェック、crontab変更、タイミングテスト、PrestaShopオーバーライド作業のためのオペレーティングエージェントとしてCodexを使用しました。

レビューのために、私はオープンワークフローai-collab-bridgeを使用しています。アイデアはシンプルです: 1つのAIが変更を実装し、次に別のAIがdiff、コンテキスト、焦点を絞った質問を含むレビューパケットを受け取ります。Claude Codeは、緩い要約に反応するのではなく、第二の技術的な読者として作業をレビューできます。

それはPrestaShopの移行において重要です。なぜなら、多くの小さな決定があるからです:

AIは、そのチェックを示さなければならないときに役立ちます。「動作する」は不十分です。役立つ移行実行は、コマンド、ステータスコード、キャッシュ動作、cron状態、および意図的に移動されなかった部分を示します。

この移行から得た教訓

パネルの動作を盲目的にコピーしないでください。HestiaとDirectAdminはホスティングメンテナンスを異なる方法で解決します。HestiaパネルのcronはDirectAdminには属しません。

バックエンド移行は狭く保ってください。フロントエンドがすでに他の場所で実行されている場合、それを移動することはリスクを増やすだけです。

バックオフィスの視点からキャッシュを検証してください。eコマースの変更は、価格、在庫、コピー、キャンペーンの編集を通じて発生します。クリアされないキャッシュはビジネス上の問題になります。

同じエンドポイントを繰り返し測定してください。1つの`curl`リクエストはほとんど何も示しません。ストアごとに12回の実行は、はるかに明確な信号を提供しました。

スクリプトにデータベースパスワードをハードコーディングしないでください。必要に応じてアプリケーションの既存の設定から読み取り、ホスティングパネルにバックアップを所有させてください。

結果

移動後、バックエンドは私のテストで古いライブサーバーとステージリファレンスの両方よりも速く応答しました。RedisとLiteSpeedが助けになりました。DirectAdmin APIは、私が必要とするパネル設定には十分でした。OPcacheメモリはホストレベルの設定であることが判明したため、それはアプリコードではなくホスティングサポートに属します。

主な結果はTTFBが低下したことではありませんでした。重要な結果は、バックエンドが依然としてeコマースバックエンドのように動作したことです: バックオフィスがデータを所有し、APIがストアごとに応答し、キャッシュが変更時にクリアされ、cronが新しいホストに属するジョブのみを実行します。

FAQ

移行にはどれくらいの時間がかかりましたか?

アクティブなバックエンド移行には約3〜4時間かかりました。タイミングテスト、cron在庫、キャッシュ検証、サポートノートを含めると、作業は4〜5時間に近づきました。

なぜすべてを移動しなかったのですか?

フロントエンドはすでに他の場所で実行されていました。ニュースレター自動化とCRMはそれぞれ独自の環境を持っていました。狭いバックエンド移動はリスクを減らしました。

なぜRedisが重要だったのですか?

Redisはバックエンドキャッシュの速度を改善しましたが、実際の価値はキャッシュクリアがPrestaShopフックに接続されたときに得られました。それがなければ、バックオフィスの変更がAPIに届かない可能性があります。

なぜ共有ホスティングでロード平均を読み取るのが難しいのですか?

ロード平均はしばしばホスト全体のキューを示し、あなたのアカウントだけではありません。この移行では、アカウントは静かに見えましたが、ホストはより高い負荷を示しました。だからこそ、CloudLinuxやLVEの制限はサポートによって確認されるべきです。

なぜサーバー移行にAIを使用するのですか?

AIは、証拠とともに作業する際に役立ちます: 設定の読み取り、タイミングテスト、cronの比較、APIチェック、文書化された変更。オープンワークフローを通じたピアレビューは、別のモデルがリスクを検査するのを容易にします。