セルフホスティング型Adobe Commerceの災害復旧のアイデア

この記事の障害回復には、展開の失敗が含まれます。 プロセス全体が同じとは限りませんが、同様の原則が適用されます。 障害の原因としては、実稼動デプロイメントの失敗、サーバーの応答不能、攻撃の検出、その他多くのシナリオが考えられます。 障害が発生した展開のリカバリ プロセスに必要な手順が 2 つだけである場合は、エクスプロイトからのリカバリが非常に困難になる可能性があります。 環境の複雑さ、ホスティングのバリエーション、その他の複雑さにより、この記事ではアイデアと概念を提供しますが、調査は自分で続行する必要があります。 これにより、ビジネスニーズに合った戦略を確実に設計できます。

リカバリ・プロセスを頻繁に実施

練習、練習、練習。 災害復旧リストでプラクティスが最初に表示される理由があります。 リカバリ計画の設定は非常に容易ですが、実行することはありません。 十分に練習しないと、エラーや手順のミスが発生しやすく、実際の回復に時間がかかる可能性があります。 プラクティスのリカバリの頻度は、お客様およびビジネス・パートナー次第です。 回復プロセスを毎年開催するのは十分なことかもしれませんが、会社の意思決定者との深い会話には、いくつかの主要なトピックを含める必要があります。 これらのトピックは、練習が重要な理由と期待される理由を理解するのに役立ちます。 会話を開始するのに役立つトピックを以下に示します。

DB バックアップ

データベースのバックアップはかなり定期的に行う必要があります。 時間別、日別、週別、月別のスナップショットがあることは珍しくありません。 バックアップは最終的に長期保管に移動する必要があります。 この長期的なストレージは、ビジネスまたはテクノロジー・チームが十分な時間が経過し、迅速なリカバリが不要になると判断した場合に発生する可能性があります。 長期ストレージからのリカバリは、リカバリ・プロセスに時間がかかるため、その時期を判断するには注意が必要です。 データベースのバックアップは自動化する必要があり、人間の操作に依存しないようにします。 これにより、十分な数のリソースを確保して、安全で予測可能なリカバリ・プロセスを実現できます。 これはまた、そのような活動が必要な場合は、フォレンジック活動にも役立ち、実行可能で信頼性があります。 エクスプロイトが検出された後や、クレジットカードの不正行為が発生した時期、または誰かが web サイトに参加した時期を診断しようとする際に、フォレンジック調査が必要になる場合があります。 これらのバックアップの使用方法に制限はありませんが、実際に必要なときにバックアップの頻度を適切に設定することで節約できます。

データ保持ポリシーの例を次に示します。

コードとしてのインフラストラクチャ

つまり、プロジェクトのパーツまたはインフラストラクチャ全体を再構築するためのツールとコードが用意されています。 これは、サーバーで問題が発生し、使用を中止する必要がある場合に必要になる可能性があります。 新しいサーバをオンラインに素早く導入したり、コードをデプロイしたり、PHP、Nginx、Apache の設定を行ったりできるなど、自動的にダウンタイムが短縮されます。 実行ブックに記載されている手順は、設定が簡単で、実行に時間がかかります。 また、ストレス下でレスポンシブなサイトをオンラインに戻す際に発生する可能性のある人的エラーについても考えます。

セカンダリデータベース

セカンダリ・データベースの使用は、次のような理由で役立ちます。

セカンダリ・データベースは warm standby として使用できます。 これは、プライマリ・データベースの障害からリカバリする方法を検討している場合に有効になる可能性があります。 セカンダリデータベースのプライマリへの昇格は、データベースを再構築して新しく作成した Mysql インスタンスに復元するよりも、複雑さが少なくなります。 これにより、リカバリ操作中の実際のダウンタイムが短縮されます。

要求の一部をセカンダリ・データベースに転送する機会があります。 この方法を使用する場合は、セカンダリ データベースを読み取り専用にすることをお勧めします。 Adobe Commerce アプリケーションでこのセカンダリデータベースを読み取り処理に使用できるようにすると、読み取りリクエストの一部を受け取り、セカンダリデータベースから応答できるようになります。 ただし、この変更はすべてのリクエストの 30～50% を占めるにすぎませんが、プライマリデータベースから奪える負荷は勝利です。

ロールバックを含む配置計画を作成します

すべてのデプロイメントにロールバック計画を含める必要があります。 はい、すべてのデプロイメントで可能です。 あなたがそれを計画するならば、あなたは驚いてはいけません、そして悪い出来事の準備ができています。 最も単純なコードのアップデートは、何らかの理由で致命的に失敗する場合があります。

データベース内のスキーマ変更を実行するために、小規模でシンプルなプルリクエストをコミットしたチームの実際の事例を考えてみましょう。 デプロイメントが 1 分から 5 分、10 分に進むにつれて、チームはさらに心配になりました。 これまで検証および検討に失敗したのは、ステージング データベースと比較して実稼動データベースからの相違でした。 実稼動のコピーを使用してステージング環境を更新する際に、すべての顧客データを削除するという一般的な方法がありました。 つまり、それ以前のすべてのテストと QA では、デプロイメントが完了するまでに数分しかかからないということでした。 実際、顧客は 2,000 万人を超え、この小規模なスキーマ変更は完了までに非常に長い時間がかかっていました。 これが実際にかかる時間がわからなかったので、mysql プロセスを終了し、デプロイメントをロールバックする必要がありました。

全体のプロセスは似たものになるので、デプロイメントのロールバックプロセスの準備には数分かかります。 ただし、Git リポジトリーのHEADをリセットするコミットを正確に文書化するには、時間がかかります。 使用する db スナップショットを正確に記述する必要があります。また、常に同じ場所にある場合は、現在のスナップショットをどこで見つけるかを正確に記述する必要があります。 デプロイメントのステータスについて話し合う必要がある時間と、状況が自動的に有効になる時間を定義してある。 例えば、デプロイメントに 15 分以上かかる場合は、プロジェクトマネージャーや他の関係者に、作業を継続するかどうか尋ねます。 ただし、ロールバックプロセスを自動的に実行し、プロジェクトのプロジェクトマネージャーやアーキテクトにためらいがあるかどうかに関係なく、プロセスに 45 分かかる場合はすべての関係者に通知します。

プロセス全体とすべてのフェーズに、複数の担当者が関与していることを確認します。 ミッドレベルの開発者に導入プロセス、ロールバック手順、ファイルの場所を確認してもらうのは、開発者を巻き込む優れた方法です。 最終的には担当者が手順を実行するので、長期的な成功を収めるには、プロセス全体を理解することが重要です。 すべてのユーザーに、デプロイメントを中止する権限を付与します。 この量の発言権をチームに与えることは、力を与え、やりがいを感じさせます。 ジュニア開発者が本当に何か足りないと感じたら、声を上げて注意を聞かせなければいけません。 アーキテクトとプロジェクトマネージャーが不安を確認したり、軽減したりできます。 プロジェクトを探し、完璧なデプロイメントの実績を維持している強力なチームを持つことが重要です。

ドメイン名管理、DMS、SSL、WAF へのアクセスの確認

ドメイン名の有効期限が切れると、DNS レコードが誤って変更される可能性や、SSL 証明書の有効期限が切れる可能性があります。ログインして接続が頻繁に行われることを検証する機能を備えていることを確認してください。 この簡単なチェックを四半期ごとに行うことで、特に緊急時に、物事がどこにあるかを正確に知っていることを確信できます。 DNS がAmazonで管理されていることを確認するためだけに、DNS がレジストラーで管理されていると想定しないでください。 これらのレコードは頻繁に使用されないので、どこにあるのかを忘れる可能性が高いです。 ユーザー名とパスワードだけを記載したドキュメントは信頼しないでください。 それぞれにログインし、探している設定が実際にそこで管理されていることを確認します。 経営者の離職時や会社の買収の際に状況が変わることが多く、何が起きたのかを知っているのは 1 人だけです。なぜなら、彼らがアップデートを行ったからです。 彼らは、あなたが場所、ユーザー名とパスワードが何であるかを共有の Word 文書に依存していることを認識していませんでした。 自分や組織に合ったチェックプロセスを見つけますが、3～6 か月ごとにこれを行うことは、出発点として適切です。

自己ホスティングリソース