Adobe Commerce 재해 복구 아이디어 자체 호스팅
이 문서의 재해 복구에는 실패한 배포가 포함됩니다. 전체 프로세스가 동일하지 않을 수 있지만 유사한 원칙이 적용됩니다. 재해는 프로덕션 배포 실패, 서버가 응답하지 않음, 익스플로잇 검색 및 기타 여러 시나리오로 인해 발생할 수 있습니다. 실패한 배포에 대한 복구 프로세스는 두 가지 간단한 단계만 거치면 될 수 있으며, 악용으로부터 복구하는 것은 훨씬 더 어려울 수 있습니다. 환경, 호스팅 변형 및 기타 복잡성의 복잡성으로 인해 이 문서에서는 아이디어와 개념을 제공하지만 사용자 스스로 조사를 계속해야 합니다. 이렇게 하면 비즈니스 요구에 맞는 전략을 설계할 수 있습니다.
복구 프로세스를 자주 수행
연습, 연습, 연습. 재해 복구 목록에 모범 사례가 가장 먼저 표시되는 데는 이유가 있습니다. 복구 계획을 설정하기는 쉽지만 결코 실행할 수는 없습니다. 충분한 연습을 하지 않으면 오류가 발생하기 쉽고 단계를 놓치기 쉬우며 실제 복구가 더 오래 걸릴 수 있습니다. 실제 복구에 대한 케이던스는 귀하와 비즈니스 파트너에게 달려 있습니다. 복구 프로세스를 연간 이벤트로 만드는 것도 좋지만, 회사 내 의사 결정권자와의 깊은 대화에는 몇 가지 주요 주제가 포함되어야 합니다. 이러한 주제는 연습이 중요하고 예상해야 하는 이유를 이해하는 데 도움이 됩니다. 다음은 대화를 시작하는 데 도움이 되는 몇 가지 주제입니다.
- 실제로 이벤트가 발생할 때 실제 가동 중지 시간이 줄어듭니다. 연습 드라이 런으로 1년에 한 시간 동안 사이트가 다운되는 경우 실제 이벤트의 실제 가동 중지 시간이 몇 시간 정도 줄어들 수 있습니다. 사이트를 복구하는 데 8시간 이상 걸리는 경우는 드물지 않습니다. 이 이벤트를 자주 연습하면 각 단계에 걸리는 시간을 줄일 수 있으며, 더 빨리 회복할 수 있습니다.
- 이러한 실습 실행에 대해 예약된 가동 중지 시간은 서버 패치, 인벤토리 조정 또는 정기적인 일정에 따라 수행되어야 하는 그 밖의 모든 조치와 동시에 발생할 수 있습니다.
- 동일한 시나리오 대신 다른 시나리오를 연습하십시오. 가끔 이전 날짜의 전체 복구를 수행합니다. 여기에는 데이터베이스의 보관된 사본을 찾아서 사용하는 작업, 날짜와 일치하도록 코드를 롤백하는 작업 등이 포함됩니다. 이전 커밋으로 롤백해야 하는 실패한 배포에서 복구하는 것이 더 쉽습니다.
- 복구 프로세스가 실제로 작동하는지 확인합니다. 경우에 따라 아카이브된 데이터베이스가 손상될 수 있습니다. 그렇게 함으로써, 모든 것이 복구될 수 있고 기능적이라는 것을 보장한다. 오래된 DB를 찾아서 복원하는 데는 시간이 걸리는데, 이 부분의 처리 기간이 어느 정도인지 알아야 한다.
- 구성의 모든 변경 사항이 문서화되었는지 확인합니다. 이렇게 하면 이전 데이터베이스의 모든 복구에서 새 구성 변경 사항이 제대로 작동하는지 확인할 수 있습니다. 예를 들어 지난 며칠 동안 API 키가 결제 프로세서로 변경된 경우. 좋은 변경 관리 프로세스를 통해 이러한 주요 업데이트를 찾으면 프로세스가 계획대로 진행될 수 있습니다.
DB 백업
데이터베이스 백업은 매우 규칙적이어야 합니다. 시간별, 일별, 주별, 월별 스냅샷을 갖는 것은 드문 일이 아닙니다. 결국 백업은 장기 스토리지로 이동해야 합니다. 이러한 장기 스토리지는 비즈니스 또는 기술 팀이 충분한 시간이 경과했다고 판단할 때마다 발생할 수 있으므로 신속한 복구가 더 이상 필요하지 않을 수 있습니다. 장기 스토리지에서 복구하면 복구 프로세스에 시간이 추가되므로 이 문제가 발생하는 시점을 결정할 때 주의해야 합니다. 데이터베이스 백업은 사람의 상호 작용에 의존하지 않고 자동화되어야 합니다. 이를 통해 안전하고 예측 가능한 복구 프로세스를 제공할 수 있습니다. 이것은 또한 어떤 법의학 활동에서도 도움이 되는데, 그러한 활동이 필요하다면, 실현 가능하고 신뢰할 수 있다. 악용이 감지된 후 또는 신용카드 사기 행위가 언제 발생했는지 또는 누군가 웹 사이트에 가입했을 때를 진단하려고 할 때 법의학 연구가 필요할 수 있습니다. 이러한 백업을 사용하는 방법에는 제한이 없지만 백업의 적절한 케이던스를 확보하는 것이 실제로 필요할 때 절약할 수 있는 유예 방법입니다.
다음은 데이터 보존 정책의 예입니다.
- 매 8시간마다 백업을 쉽게 액세스할 수 있어야 합니다.
- 지난 7일 동안의 일일 백업이며 쉽게 액세스할 수 있어야 합니다. 사본은 오프사이트로 이동할 수 있는 후보일 수 있습니다.
- 지난 4주 동안의 주간 백업은 오프사이트로 이동하는 것을 고려합니다.
- 지난 3개월 동안의 월별 백업은 오프사이트로 이동되었습니다.
- 오래된 백업은 장기간 오프사이트로 이동합니다.
코드로서의 인프라
이 방법론은 프로젝트에 필요한 전체 인프라 또는 부품을 재구축할 수 있는 도구와 코드를 보유하고 있음을 의미합니다. 서버에 문제가 발생하여 사용을 중단해야 할 때 필요할 수 있습니다. 새로운 서버를 신속하게 온라인 상태로 전환하고, 코드를 배포하고, PHP, Ngix 또는 Apache 구성 등을 수행할 수 있으므로 자동으로 다운타임이 줄어듭니다. 실행 설명서에 잘 설명되어 있는 단계라도 설정하는 것이 더 쉽습니다. 단계를 실행하는 데 훨씬 더 오래 걸립니다. 또한, 반응하지 않는 부위를 다시 온라인 상태로 만들기 위해 스트레스를 받는 동안 발생할 수 있는 사람의 오류를 고려하십시오.
보조 데이터베이스
다음과 같은 몇 가지 이유로 보조 데이터베이스를 사용하는 것이 유용할 수 있습니다.
- 기본 드라이브 장애 발생 시 대기 대기 상태 유지
- 애플리케이션의 준비 요청 허용
- mysqldump가 발생하도록 허용하고 데이터베이스를 잠그지 않고 일반 트랜잭션이 발생하도록 허용
- 고객 요청에 대한 정보를 처리하는 웹 사이트의 기능을 줄이지 않고도 외부 데이터 소스의 데이터 액세스를 허용합니다.
보조 데이터베이스를 warm standby(으)로 사용할 수 있습니다. 이 기능은 운영 데이터베이스 장애 복구 방법을 고려할 때 실행될 수 있습니다. 보조 데이터베이스를 기본 데이터베이스로 프로모션하는 것은 데이터베이스를 새로 만든 Mysql 인스턴스로 다시 작성 및 복원하는 것보다 복잡성이 낮습니다. 따라서 복구 작업 중 실제 가동 중지 시간이 줄어듭니다.
일부 요청을 보조 데이터베이스로 전환할 수 있습니다. 이 방법을 사용하는 경우 보조 데이터베이스를 읽기 전용으로 만드는 것이 좋습니다. Adobe Commerce 애플리케이션에서 이 보조 데이터베이스를 읽기 작업에 사용할 수 있도록 하면 읽기 요청 중 일부를 가져와 보조 데이터베이스가 응답할 수 있습니다. 그러나 이러한 변경은 모든 요청의 30-50%만 차지하지만 기본 데이터베이스에서 제거할 수 있는 모든 로드는 성공입니다.
롤백을 포함하는 배포 계획 만들기
모든 배포에는 롤백 계획이 포함되어야 합니다. 예, 모든 배포. 만약 여러분이 그것을 계획한다면, 여러분은 절대 놀라지 않고 나쁜 사건에 대해 준비하고 있습니다. 경우에 따라 가장 간단한 코드 업데이트가 어떤 이유로든 대참사적으로 실패할 수 있습니다.
데이터베이스에서 스키마 변경을 실행하기 위해 작고 간단한 가져오기 요청을 커밋한 팀의 실제 사례를 생각해 보십시오. 배치가 1분에서 5분, 10분으로 진행되면서 팀 고민이 더 커졌다. 이 시점까지 검증하고 고려하지 못한 사항은 스테이징 데이터베이스와 비교하여 프로덕션 데이터베이스와 일치하지 않는 것입니다. 운영 복제본으로 스테이징 환경을 새로 고칠 때 모든 고객 데이터를 제거하는 일반적인 방법이 있었습니다. 즉, 그에 앞서 모든 테스트와 QA가 배포를 완료하는 데 몇 분 정도 소요됩니다. 실제로는 2천만 명이 넘는 고객을 보유하고 있었으며 이러한 소규모 스키마 변경은 완료하기까지 매우 오랜 시간이 소요되고 있었다. 실제로 시간이 얼마나 걸릴지 몰랐기 때문에 mysql 프로세스를 종료하고 배포를 롤백하지 않을 수 없었습니다.
전체 프로세스가 유사하므로 배포에 대한 롤백 프로세스를 준비하는 데 몇 분 정도 소요됩니다. 그러나 git 저장소의 HEAD을 다시 설정할 커밋을 정확히 문서화하는 데 시간을 기울여야 합니다. 사용할 DB 스냅샷이나 현재 스냅샷이 항상 같은 위치에 있는 경우 현재 스냅샷을 찾을 위치를 정확하게 작성해야 합니다. 배포 상태를 논의해야 하는 시간과 상황이 자동으로 적용되는 시간을 정의했습니다. 예를 들어 배포가 15분 이상 걸리는 경우 프로젝트 관리자 및 다른 이해 당사자에게 작업이 계속되어야 하는지 문의하십시오. 그러나 프로젝트에 대한 프로젝트 관리자 및 설계자의 거부가 있는지 여부에 관계없이 프로세스가 45분 정도 소요되는 경우 자동으로 롤백 프로세스를 실행하고 모든 관련자에게 알립니다.
전체 과정 및 모든 단계에 여러 사람이 참여하는지 확인하십시오. 중간 수준의 개발자가 배포 프로세스, 롤백 절차 및 파일 위치를 검토하도록 하는 것은 이러한 개발자들이 관여할 수 있도록 하는 좋은 방법입니다. 그들은 결국 단계를 수행하고 있을 것이므로 전체 프로세스를 이해시키는 것이 장기적인 성공의 핵심입니다. 모든 사용자에게 배포를 취소할 수 있는 권한이 있는지 확인하십시오. 팀에 이 정도의 발언권을 주는 것은 힘을 주고 보람을 주는 것입니다. 후배 개발자가 진정 무언가가 누락되었다고 느낀다면, 그들은 목소리를 높여야 한다는 강박감을 느끼고 그들의 주의를 기울여야 합니다. 설계자와 프로젝트 관리자에게 두려움을 확인하거나 완화하도록 합니다. 프로젝트를 잘 관리하고 무결점 배포 기록을 유지하는 강력한 팀이 필요합니다.
도메인 이름 관리, DMS, SSL, WAF에 대한 액세스 확인
도메인 이름이 만료되기 때문에 DNS 레코드가 실수로 수정될 수 있고 SSL 인증서가 만료될 수 있으며, 이러한 경우 로그인하여 연결이 자주 발생하는지 확인할 수 있습니다. 매 분기마다 이 간단한 점검을 하면 특히 비상시에 정확하게 어디에 물건이 있는지 알 수 있다는 확신을 갖게 됩니다. DNS가 Amazon에서 관리되고 있다는 것을 확인하기 위해 등록에서 관리된다고 가정하지 마십시오. 이러한 기록들은 자주 사용되지 않기 때문에 어디에 있는지 잊어버리는 것은 높은 확률이다. 사용자 이름과 암호에 대한 서면 설명서만 신뢰하지 마십시오. 각 구성 요소에 로그인하고 원하는 구성이 실제로 해당 구성 요소에서 관리되는지 확인합니다. 너무 자주 경영진 이직이나 회사 인수 중에 상황이 바뀌고 한 사람만 상황을 알고 있습니다. 왜냐하면 이들은 업데이트를 수행한 사람들이기 때문입니다. 위치, 사용자 이름 및 암호가 공유 단어 문서에 의존한다는 것을 알지 못했습니다. 귀하와 귀하의 조직에 적합한 확인 프로세스를 찾으십시오. 그러나 3~6개월마다 이 작업을 수행하는 것이 좋은 출발점입니다.