기술 마이그레이션 전략에 대한 전체 가이드: (최종 – 도메인 및 호스팅 마이그레이션)

게시 됨: 2020-12-28

마지막으로 블로그 시리즈를 마치기 위해 서버(도메인 및 호스팅) 마이그레이션에 대해 자세히 알아보겠습니다. 이미 애플리케이션 및 데이터베이스 마이그레이션의 범위를 백엔드 마이그레이션 프로세스의 핵심 요소로 지정했으므로 서버 마이그레이션으로 마무리하는 것이 합리적입니다.

일반적으로 웹사이트를 한 호스트에서 다른 호스트로 마이그레이션하는 것은 이전에 논의한 다른 마이그레이션 유형과 비교할 때 더 쉬울 수 있습니다. 실제로는 웹사이트에 새 주소를 제공하는 것과 같습니다. 이 기사의 나머지 부분에서는 이 마이그레이션 카테고리와 관련된 주요 측면과 모범 사례에 대해 자세히 설명합니다. 자, 더 이상 고민하지 않고 뛰어들자!

서버 마이그레이션이란 무엇입니까?

가장 기본적인 의미에서 서버 마이그레이션은 데이터가 한 서버에서 다른 서버로 배치되는 마이그레이션 기술입니다. 기본적으로 웹 사이트 및 해당 구성을 복사하여 기존 서버를 대체하도록 대상 서버를 구성하고 방문자를 새 서버로 안내하도록 DNS를 변경해야 합니다. 서버 마이그레이션은 많은 데이터에 의존하는 비즈니스에서 일반적이며 데이터의 민감한 특성으로 인해 성공적인 마이그레이션을 위해서는 신중한 계획이 매우 중요합니다.

왜 서버 마이그레이션인가?

서버 마이그레이션은 다음과 같은 다양한 이유로 발생할 수 있습니다.

  • 증가된 트래픽을 처리하기 위해.
  • 더 나은 성능과 더 빠른 응답 시간을 원합니다.
  • 향상된 제어, 관리 용이성 및 유연성을 원합니다.
  • 향상된 사용자 정의를 위해.
왜 서버 마이그레이션

반면에 비용 절감을 위해 저가형 서버로 다운그레이드하는 개인이 있습니다. 서버 마이그레이션에는 두 가지 주요 측면도 포함됩니다. 도메인 마이그레이션 및 호스팅 서버 마이그레이션. 이 블로그의 대부분에서는 두 범주를 모두 살펴보겠습니다. 예를 들어 호스팅 공급자를 전환하는 것(예: GoDaddy에서 AWS로)과 도메인 이름을 이전하는 것(예: example.com에서 example.info로)의 차이점.

도메인 이름 마이그레이션이란 무엇입니까?

간단한 용어로 도메인 마이그레이션은 데이터 보안 손실이나 손상 없이 한 도메인 이름(example.co)에서 다른 도메인 이름(example.info)으로 웹사이트를 이동하는 것을 의미합니다. 원칙적으로 도메인 이름을 전송할 때 서버 간에 파일 전송이 없기 때문에 백업이 필요하지 않습니다. DNS(Domain Name System) 정보는 변경 기록을 보유하기 위한 필수 조건으로 전송되어야 하지만. HTTP 웹 사이트가 HTTPS로 이동할 때와 같이 비보안 웹 사이트가 보안 웹 사이트로 이동될 때도 프로토콜 변경이 발생할 수 있습니다. 기본적으로 도메인 이름을 변경하는 이유는 다릅니다. 예를 들어 .com 과 같은 일반 도메인에서 .in 또는 .cn과 같은 보다 지리적으로 특정한 도메인으로 이동하는 것이 좋습니다.

호스팅 서버 마이그레이션이란 무엇입니까?

호스팅 서버 마이그레이션은 기본적으로 한 호스팅 서비스 제공업체에서 다른 호스팅 서비스 제공업체로 이동하는 것을 의미합니다. 마이그레이션할 때 마이그레이션 프로세스를 시작하기 전에 장치의 데이터베이스 파일과 함께 웹사이트의 전체 백업을 설정해야 합니다. 또한 모든 서버 측 스크립팅이 새 호스팅 플랫폼에 설치될 수 있고 웹사이트가 새 서버에서 원활하게 실행될 수 있는지 확인하십시오. 다음과 같이 한 호스트 공급자에서 다른 호스트 공급자로 마이그레이션하는 데에는 여러 가지 이유가 있을 수 있습니다.

  1. 새로운 기술 스택 또는 더 나은 서비스를 활용하려는 욕구
  2. 노후 인프라 교체의 필요성
  3. 고가용성을 달성하기 위해 호스팅을 확장하고 배포해야 하는 요구 사항입니다.
  4. 보안 문제 등
왜 사람들이 한 호스트 공급자에서 다른 공급자로 마이그레이션

서버 호스트 마이그레이션 유형

서버 호스트 마이그레이션 유형

관련된 운영 체제 및 기술에 따라 서버 마이그레이션은 일반적으로 다음으로 구성됩니다.

  • 클라우드 서버 마이그레이션 : 여기에는 주로 데이터를 확장 가능한 최신 클라우드 서버로 배치하는 작업이 포함됩니다.
  • 응용 프로그램 서버 마이그레이션 : 기본적으로 한 서버 환경에서 다른 서버 환경으로 소프트웨어 응용 프로그램을 전송하는 작업을 수반합니다. 이것은 기본적으로 서버 간에 파일이 이동할 때마다 발생합니다.
  • 메일 서버 마이그레이션 : 여기에서 데이터는 동일하거나 다른 호스트 내에서 이메일 서버 마이그레이션 간에 전달됩니다.
  • 가상 서버 마이그레이션 – 이 마이그레이션 도메인에는 가상 서버 또는 한 서버에서 다른 서버로 가상 머신 전송이 포함됩니다. GoDaddy, AWS, DigitalOcean, Alibaba Cloud 등과 같은 시장에서 사용할 수 있는 여러 서버 옵션이 있습니다. 그러나 하나를 선택하는 것은 주로 프로젝트의 요구 사항에 따라 다릅니다. 모든 호스팅 서버 마이그레이션에 적용되는 한 가지 공통 규칙이 있습니다. 이전 도메인 등록 기관에 60일 이상 등록한 경우에만 호스팅 서버를 변경할 수 있습니다. 해당 호스팅 사이트에서 사용할 수 있는 다른 규칙에 대해 알아볼 수 있습니다.

도메인 이름을 마이그레이션하는 방법은 무엇입니까?

도메인 이름 마이그레이션은 서버 마이그레이션과 달리 더 쉽게 추론할 수 있습니다. 도메인 이름을 마이그레이션하는 가장 일반적인 이유는 사용자가 도메인 이름이 더 길고 더 짧고 더 나은 버전을 원할 수 있기 때문입니다. 그러나 도메인 이름을 전환하기 전에 염두에 두어야 할 두 가지 시나리오가 있습니다.

  • 다른 사람이 이미 사용하고 있는 도메인 이름 구입: 도메인 경매에서 구입했거나 다른 사람에게서 직접 구입해야 하는 만료된 도메인 이름일 수 있습니다.
  • 이전에 사용된 적이 없는 완전히 새로운 도메인 이름을 구입합니다.

위의 두 시나리오의 차이점과 이것이 필수적인 이유를 이해하기 위해 예를 들어 보겠습니다. 이전에 등록된 도메인 이름을 구매하려는 경우 다음 문제 중 하나에 직면할 수 있습니다.

  • 그것은 당신의 사이트에 좋을 수도 있고 어떤 경우에는 나쁠 수도 있는 그것을 가리키는 링크를 가질 수 있습니다.
  • 귀하와 다른 목적으로 만들어진 주제와 다른 사이트에 이전에 첨부되었을 수 있습니다.
  • 일부 검색 엔진에서 불이익을 받거나 금지될 수 있습니다.
  • 귀하의 사이트는 소셜 미디어 사이트에서 금지될 수 있습니다.
  • 이전에 스팸 활동에도 사용되었을 수 있습니다.

도메인 이름 마이그레이션 프로세스

  • 도메인 이름 마이그레이션 프로세스는 매우 간단합니다. 간단한 단계를 따르기만 하면 금방 완료됩니다.
  • 먼저 Google 검색 콘솔에서 각 사이트의 모든 버전(http://, http://www, https:// 또는 https://www)을 확인해야 합니다. 또한 모든 하위 도메인(있는 경우)을 식별합니다.
  • 전체 사이트를 크롤링합니다. 이를 위해 온라인에서 사용할 수 있는 다양한 도구를 사용할 수 있습니다. 이렇게 하면 가능한 모든 URL을 식별하고 목록을 만드는 데 도움이 됩니다. 나중에 필요할 것입니다.
  • 301 영구 리디렉션을 사용하여 이전 도메인 이름에서 새 도메인 이름으로 리디렉션합니다.
  • 리디렉션을 테스트하여 여러 번 리디렉션하지 않는지 확인합니다. 사용자에게 혼란을 줄 수 있습니다.
  • Google 주소 변경 도구를 사용하여 새 도메인으로 이동한다는 사실을 Google에 알립니다. 이렇게 하면 리디렉션이 제대로 설정되었는지 확인하는 데 도움이 됩니다.
  • 새 도메인 이름을 가리키도록 Google Analytics의 설정을 업데이트하는 것을 잊지 마십시오. Google 애널리틱스에서 이전 데이터를 유지하려면 Google 애널리틱스 설정을 편집할 수 있습니다.
  • 생성한 URL 목록을 사용하여 사이트를 다시 크롤링하여 모든 이전 URL이 새 URL로 제대로 리디렉션되는지 확인합니다.

한 서비스 제공업체에서 다른 서비스 제공업체로 마이그레이션하는 방법은 무엇입니까?

앞서 암시했듯이 서버 마이그레이션은 정말 간단합니다. 웹 사이트는 일반적으로 마이그레이션 프로세스가 아무리 잘 계획되어 있더라도 서버 마이그레이션 프로세스 중에 약간의 가동 중지 시간에 직면합니다. 따라서 마이그레이션 프로세스를 실행하기 전에 마이그레이션 계획을 잘 준비해야 합니다.

일반적으로 서버의 트래픽이 가장 적을 때 마이그레이션 프로세스를 실행해야 합니다. 계획에 따라 이동해야 하며 그렇지 않으면 호스팅 서버 마이그레이션 프로세스가 실패할 가능성이 높습니다.

  • 호스팅 제공업체를 결정했으면 요금제를 구매하고 웹사이트를 새 호스트로 이전할 준비를 하세요. 웹 사이트가 새 웹 사이트로 완전히 마이그레이션될 때까지 이전 도메인 등록 대행자의 계획이 취소되지 않았는지 확인하십시오.
  • 이전 도메인 등록 기관에서 모든 데이터베이스 및 웹 사이트 파일을 백업하는 것과 같이 마이그레이션을 진행하기 전에 처리해야 하는 몇 가지 예방 조치가 있습니다.
  • PHPAdmin 또는 기타 타사 소프트웨어를 사용하여 데이터베이스를 가져올 수 있습니다. 그런 다음 웹사이트 파일과 데이터베이스를 도메인 등록 기관의 새 서버에 업로드합니다.
  • 데이터베이스를 업로드하기 전에 먼저 새 서버에 웹 앱을 설치한 다음 데이터를 백업하는 PHPAdmin 또는 기타 타사 소프트웨어에서 데이터베이스를 내보냈는지 확인하십시오.
  • DNS를 전환하기 전에 모든 이메일 계정을 새 서버에 추가하는 것을 잊지 마십시오. 또한 이메일 주소를 추가하는 것을 잊었을 경우 메일이 반송되지 않도록 "포괄" 주소를 만들 수도 있습니다.
  • 가장 좋은 방법은 각 이메일 주소에 대해 두 개의 계정을 만든 다음 도메인 이름 대신 POP 설정에서 각 메일 서버의 IP 주소를 사용하는 것입니다. 이 연습의 도움으로 DNS 전파 방법 중에 이메일을 놓치지 않을 것입니다.
  • 새 호스팅 서버에 모든 웹 사이트 파일이 있으면 모든 이미지, 텍스트 및 링크가 새 서버에서 올바른 위치에 있고 제대로 작동하는지 확인하기 위해 일련의 테스트를 수행해야 합니다.
  • DNS 레코드를 변경할 때 도메인 등록 대행자와 함께 제어판에서 DNS 레코드를 변경해야 합니다. 기본적으로 도메인 이름 서버를 새 호스트가 보낸 환영 메일의 서버로 변경해야 합니다. 2~4일 이내에 마이그레이션 프로세스가 성공적으로 완료됩니다.
  • 마지막으로 이전 호스팅 서비스 제공업체에서 호스팅 계정을 취소하는 것을 잊지 마십시오.

원활한 호스팅-서버 마이그레이션을 달성하기 위해 고려해야 할 예비 지침.

  1. 계획 단계
  • 원본 서버의 호스팅 플랫폼이 마이그레이션을 지원하는지 확인합니다.
  • 대상 서버에 적합한 대상 서버와 하드웨어를 신중하게 선택하십시오. 예를 들어 한 전용 서버에서 다른 전용 서버로 데이터를 전송하는지 여부와 같이 응용 프로그램에 차이가 있습니다. 또는 새로운 서버 구조가 여러 개의 서로 다른 시스템을 포함하는 클러스터를 기반으로 하는지 여부.
  • 대상 서버에 대해 지원되는 운영 체제 선택
  • 마이그레이션 후 대상 서버에서 도메인을 온라인 상태로 만드는 실행 가능한 방법을 선택합니다(예: 새 IP 주소로 마이그레이션 및 마이그레이션 후 해당 주소를 가리키도록 도메인의 DNS 레코드 업데이트). 원본 서버에 과부하가 걸리거나 리소스가 부족한 경우 가능하면 업무 시간 외에 마이그레이션 작업을 계획하는 것이 좋습니다.
  1. 서버 준비
  • 원본 서버에서 사용 중인 모든 사용 가능한 구성 요소가 대상 서버에도 설치 및 구성되었는지 확인합니다.
  • 원본 및 대상 서버에 충분한 디스크 공간이 있는지 확인하십시오.
  • 대상 서버에 필요한 양의 IP 주소를 추가합니다(모범 사례는 마이그레이션을 위해 두 서버에 동일한 양의 공유 및 전용 IP를 사용하는 것입니다).
  1. 테스트 단계 고려 사항
  • 잠재적인 위험을 측정하기 위해 종단 간 성능 테스트를 수행하는 것이 좋습니다. 이 시간 동안 위험도가 낮은 응용 프로그램을 시험해보고 개발 테스트를 수행한 다음 위험이 높은 응용 프로그램으로 이동합니다. 이러한 증분 프로세스를 통해 더 크고 복잡한 애플리케이션을 테스트하는 동안 프로세스에 대한 자신감을 점차적으로 구축할 수 있습니다.
  • 그럼에도 불구하고 배포 후가 그만큼 중요하며 서버는 마이그레이션 후 상당히 '집중 치료' 상태를 유지해야 합니다.
  1. 위험 완화

위험은 모든 서버 마이그레이션 작업과 동의어이며 가능한 한 많은 위험을 완화하는 것이 모범 사례의 일부입니다. 다음은 몇 가지 위험 시나리오의 예입니다.

  • 마이그레이션 후 애플리케이션이 예상대로 작동하지 않을 수 있는 가장 중요한 위험.
  • 부적절하게 작동하는 프로그램 또는 기능의 위험
  • 데이터 침해 및 데이터 손실.
  • 무단 인스턴스 생성
  • 간헐적으로 사용할 수 없는 위험이 있습니다. 이것은 항상 비즈니스 운영에 문제를 일으키고 문제를 해결하기 위한 강제 다운타임으로 이어질 수 있습니다.
마이그레이션 위험 시나리오 예

본질적으로 이러한 위험을 완화하는 가장 효과적인 방법은 마이그레이션을 완전히 접근하도록 계획하는 것입니다. 여기에는 주요 애플리케이션과 데이터 저장소를 주의 깊게 살펴보고 중요한 애플리케이션에 대한 안정적인 백업을 생성하는 것과 같은 비상 상황을 설정하는 것이 포함됩니다. 예를 들어, 일부 회사는 복잡한 마이그레이션에서 발생할 수 있는 다른 잠재적 문제를 식별하기 위해 마이그레이션 시뮬레이션(클라우드 시뮬레이션 도구 사용)을 준비합니다.

  1. 백업 방법 선택
  • 깨진 기록처럼 들리지 않으면 백업이 얼마나 중요한지 충분히 강조할 수 없습니다! 본질적으로 최상의 백업 접근 방식은 디스크의 이미지 백업을 생성하는 것입니다. 일반적으로 이미지 백업은 레지스트리 키, 라이센스 키, 설정 및 응용 프로그램별 데이터를 포함한 중요한 정보를 깊이 캡처합니다.
  • 또한 이미지 백업을 사용하면 물리적 서버 백업을 가상 머신(VM)으로 변환할 수 있습니다. 본질적으로 이 변환은 이전 시스템 데이터에 액세스해야 하는 경우 나중에 언제든지 회전할 수 있는 원래 시스템의 복사본을 유지합니다. 즉, 이미지 백업은 마이그레이션 프로세스에 중요한 안전망을 제공합니다.
  • 반면에 파일 기반 백업 접근 방식도 실행 가능한 대안입니다. 그러나 파일 기반 백업은 전체 운영 체제 또는 가상 머신을 백업해야 하는 경우 파일 시스템 수준에서 작동하기 때문에 파일 기반 백업으로는 충분하지 않을 수 있습니다.

이 프로세스가 진행되는 동안 다운로드한 백업 파일의 압축을 풀어서는 안 됩니다. 이 프로세스는 새 서버에서 완료되기 때문입니다.

  1. 롤백 계획이 있습니다.
  • 롤백 전략은 무언가 크게 잘못되거나 압도적인 여러 문제가 있는 경우 안전 장치입니다. 기본적으로 변경 사항을 되돌리고 서버를 마이그레이션 전의 원래 상태로 되돌릴 수 있습니다.
  • 서버 공급자가 그러한 조치를 취하고 있는지 확인하십시오.

서버 마이그레이션 체크리스트

  • 오늘 자세히 설명한 내용을 바탕으로 서버 마이그레이션을 시작하거나 고려할 때 가장 중요한 질문을 요약해 보겠습니다.
  • 새 서버에는 어떤 아키텍처가 있어야 하며 프로젝트 아키텍처가 요구 사항에 적합합니까?
  • 마이그레이션 및 후속 서버 구성에 사용할 수 있는 재정 자원과 전문가가 충분합니까?
  • 선택한 하드웨어가 프로젝트의 향후 개발을 위해 충분히 유연합니까?
  • 마이그레이션 프로세스는 시스템이 계속 작동하는 동안 발생해야 합니까, 아니면 프로세스 기간 동안 모든 활동이 중단되어야 합니까?
  • 리소스 가용성 및 마이그레이션의 복잡성 증가에 비례하여 운영을 유지 관리할 가능성이 있습니까?
  • 그렇다면 다운타임을 가능한 한 낮게 유지하기 위해 어떤 조치를 취할 수 있습니까?
  • 데이터베이스 항목의 무결성과 최신 상태를 어떻게 보장할 것인가?
  • 새 서버의 기능은 어떻게 테스트됩니까?
  • 데이터 마이그레이션이 완료된 후 특정 애플리케이션이 작동하지 않으면 어떻게 됩니까? 어떤 비상 사태 또는 해결 방법을 제정할 수 있습니까?

결론

이 블로그가 포괄적인 아이디어를 제공하고 도메인 마이그레이션과 호스팅 서버 마이그레이션의 차이점을 자세히 설명하기를 바랍니다. 마이그레이션은 훨씬 더 광범위한 주제이지만 마이그레이션 여정을 시작할 때 결정을 내리는 데 도움이 될 수 있는 모든 중요한 측면을 다루려고 노력했습니다.

이 블로그 시리즈는 기본적으로 마이그레이션 범위를 정의하고, 범위 이동을 피하고, 기술 스택을 현명하게 선택하고, 기술 마이그레이션, 데이터베이스 마이그레이션, 도메인 및 호스팅 서버 마이그레이션과 같은 다양한 마이그레이션 유형 이면의 복잡성을 이해하는 데 도움이 됩니다. 이 블로그 시리즈의 목적은 독자가 마이그레이션 및 마이그레이션의 기타 세부 사항에 대해 배우기 위해 Google에 흩어져 있는 웹 사이트를 검색하고 마이그레이션할 필요가 없도록 하는 것입니다. 이 블로그 시리즈가 유용했기를 바랍니다! 손쉽게 마이그레이션하는 방법에 대한 질문이 있으면 여기 Creole Studios에 문의하십시오.