프로세스 관점 - AWS 권장 가이드
대규모 마이그레이션 준비대규모 마이그레이션 실행추가 고려 사항

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

프로세스 관점

프로세스는 일관성을 제공하지만 각 프로젝트가 고유하기 때문에 진화하고 변화에 취약합니다. 프로세스를 반복적으로 실행하면 실패, 학습, 채택 및 반복할 때 큰 이점을 더할 수 있는 개선의 여지가 있는 격차를 식별할 수 있습니다. 이러한 변화로 인해 향후 프로젝트와 비즈니스가 활용할 수 있는 새로운 아이디어나 혁신이 창출될 수 있으며, 이는 품질과 팀 신뢰를 제공하는 성장의 원동력이 됩니다.

마이그레이션 프로세스는 이전에 연결되지 않았을 수 있는 기술과 경계를 넘어 복잡할 수 있습니다. 이 관점은 대규모 마이그레이션을 위한 특정 요구 사항에 대한 프로세스와 지침을 제공합니다.

대규모 마이그레이션 준비

다음 단원에서는 마이그레이션 여정을 시작하는 데 필요한 핵심 원칙을 설명하고 성공에 중요한 이해관계자의 의견을 수렴합니다.

비즈니스 동인을 정의하고 타임라인, 범위 및 전략을 전달합니다.

대규모 마이그레이션에 가까워지면 서버를 마이그레이션하는 다양한 방법이 있음을 AWS빠르게 발견할 수 있습니다. 예를 들어 다음을 수행할 수 있습니다.

올바른 마이그레이션 경로를 결정하려면 비즈니스 동인으로부터 역방향으로 작업하는 것이 중요합니다. 궁극적인 목표가 비즈니스 민첩성을 높이는 것이라면 더 많은 수준의 혁신이 필요한 두 번째 패턴을 선호할 수 있습니다. 연말까지 데이터 센터를 비우는 것이 목표라면 리호스팅이 제공하는 속도 때문에 워크로드를 리호스팅하도록 선택할 수 있습니다.

대규모 마이그레이션에는 일반적으로 다음을 포함한 다양한 이해관계자가 포함됩니다.

  • 애플리케이션 소유자

  • 네트워크 팀

  • 데이터베이스 관리자

  • 경영진 후원자

마이그레이션의 비즈니스 동인을 식별하고 마이그레이션 프로그램 구성원이 액세스할 수 있는 프로젝트 헌장과 같은 문서에 해당 목록을 포함하는 것이 중요합니다. 또한 대상 비즈니스 성과에 가장 잘 맞는 핵심 성과 지표(KPIs)를 생성합니다.

예를 들어 한 고객은 데이터 센터를 비운 목표 비즈니스 성과를 달성하기 위해 12개월 이내에 2,000개의 서버를 마이그레이션하려고 했습니다. 그러나 보안 팀은이 목표에 맞지 않았습니다. 그 결과 데이터 센터 종료 날짜를 놓치지만 애플리케이션을 추가로 현대화할지 아니면 초기에 리호스팅하여 시기 적절한 데이터 센터 종료를 가능하게 하고 애플리케이션을 현대화할지에 대한 몇 달 동안의 기술적 논쟁이 있었습니다 AWS.

차단기를 제거하는 데 도움이 되는 명확한 에스컬레이션 경로 정의

대규모 클라우드 마이그레이션 프로그램에는 일반적으로 다양한 이해관계자가 참여합니다. 결국 수십 년 동안 온프레미스에서 호스팅된 애플리케이션을 잠재적으로 변경하고 있습니다. 각 이해관계자가 우선 순위가 충돌하는 것은 일반적입니다.

모든 우선 순위가 가치를 창출할 수 있지만 프로그램은 예산이 제한되고 목표 결과가 정의될 수 있습니다. 다양한 이해관계자를 관리하고 목표 비즈니스 성과에 집중하는 것은 어려울 수 있습니다. 이 문제는 마이그레이션 범위에 있는 수백 또는 수천 개의 애플리케이션에이 문제를 곱할 때 복잡해집니다. 또한 이해관계자는 다른 우선순위가 있는 다른 리더십 팀에 보고할 가능성이 높습니다. 이를 염두에 두고 대상 비즈니스 성과를 명확하게 문서화하는 것 외에도 차단기를 제거하는 데 도움이 되는 명확한 에스컬레이션 매트릭스를 정의하는 것이 중요합니다. 이렇게 하면 상당한 시간을 절약하고 다양한 팀을 공통 목표에 맞출 수 있습니다.

이를 보여주는 한 가지 예는 12개월 이내에 기본 데이터 센터를 비우는 것이 목표인 금융 서비스 회사입니다. 명확한 권한 부여 또는 에스컬레이션 경로가 없어 이해관계자가 시간 및 예산 제약에 관계없이 원하는 마이그레이션 경로를 생성했습니다. CIO로 에스컬레이션한 후 명확한 명령이 설정되었고 필요한 결정을 요청하기 위한 메커니즘이 제공되었습니다.

불필요한 변경 최소화

변화는 좋지만 변화가 많을수록 위험이 커집니다. 대규모 마이그레이션에 대한 비즈니스 사례가 승인되면 특정 날짜까지 데이터 센터를 비우는 등이 이니셔티브를 주도하는 목표 비즈니스 성과가 있을 가능성이 높습니다. 기술자들이 AWS 서비스를 최대한 활용하기 위해 모든 것을 다시 쓰는 것은 일반적이지만, 이는 비즈니스 목표가 아닐 수 있습니다.

한 고객은 회사의 전체 웹 규모 인프라를 2년 동안 로 마이그레이션하는 데 집중했습니다 AWS. 애플리케이션 팀이 애플리케이션을 다시 작성하는 데 몇 달을 소비하지 않도록 2주 규칙을 메커니즘으로 만들었습니다. 2주 규칙을 사용하여 고객은 수백 개의 애플리케이션을 여러 해에 걸쳐 이동해야 할 때 일관된 주기로 장기 마이그레이션을 유지할 수 있었습니다. 자세한 내용은 블로그 게시물 2주 규칙: 10일 후 클라우드용 애플리케이션 리팩터링을 참조하세요.

비즈니스 성과와 일치하지 않는 변경 사항은 최소화하는 것이 좋습니다. 대신 향후 프로젝트에서 이러한 추가 변경 사항을 관리하는 메커니즘을 구축합니다.

end-to-end 프로세스를 조기에 문서화

대규모 마이그레이션 프로그램의 초기 단계에서 전체 마이그레이션 프로세스와 소유권 할당을 문서화합니다. 이 설명서는 모든 이해관계자에게 마이그레이션 실행 방식과 역할 및 책임에 대해 교육하는 데 중요합니다. 또한이 설명서는 문제가 발생할 수 있는 위치를 이해하고 마이그레이션을 진행하면서 프로세스의 업데이트 및 반복을 제공하는 데 도움이 됩니다.

마이그레이션 프로젝트를 개발하는 동안 기존 프로세스를 이해하고 통합 포인트 및 종속성을 명확하게 문서화해야 합니다. 변경 요청, 서비스 요청, 공급업체 지원, 네트워크 및 방화벽 지원을 포함하여 외부 프로세스 소유자와의 참여가 필요한 장소를 포함합니다. 프로세스를 이해한 후에는 책임 있고, 책임감 있고, 상담되고, 정보에 입각한(RACI) 매트릭스에 소유권을 문서화하여 다양한 활동을 추적하는 것이 좋습니다. 프로세스를 완료하려면 마이그레이션의 각 단계와 관련된 타임라인을 식별하여 카운트다운 계획을 수립합니다. 카운트다운 계획은 일반적으로 워크로드 마이그레이션 전환 날짜 및 시간부터 역방향으로 작동합니다.

이 설명서 접근 방식은 1년 이내에 AWS 로 성공적으로 마이그레이션하고 4개의 데이터 센터를 종료한 다국적 가전 기업에 효과적이었습니다. 조직 팀 6개와 여러 서드파티가 관여하여 관리 오버헤드가 발생하여 back-and-forth 결정과 구현 지연이 발생했습니다. AWS 전문 서비스 팀은 고객 및 타사와 함께 마이그레이션 활동의 주요 프로세스를 식별하고 해당 소유자와 함께 문서화했습니다. 결과 RACI 매트릭스는 모든 관련 팀이 공유하고 합의했습니다. RACI 매트릭스와 에스컬레이션 매트릭스를 사용하여 고객은 지연을 일으키는 차단기와 문제를 완화했습니다. 그런 다음 일정에 따라 데이터 센터를 종료할 수 있었습니다.

RACI 및 에스컬레이션 매트릭스를 사용하는 또 다른 예에서 보험 회사는 4개월 이내에 데이터 센터를 나갈 수 있었습니다. 고객은 공동 책임 모델을 이해하고 구현했으며, 마이그레이션 전반에 걸쳐 각 프로세스 및 활동의 진행 상황을 추적하기 위해 세부 RACI 매트릭스를 따랐습니다. 따라서 고객은 구현 후 첫 12주 동안 350개 이상의 서버를 마이그레이션할 수 있었습니다.

표준 마이그레이션 패턴 및 아티팩트 문서화

이를 구현을 위한 쿠키 커터를 생성하는 것으로 생각하세요. 재사용 가능한 참조, 설명서, 실행서 및 패턴이 확장의 핵심입니다. 이러한 저널은 향후 마이그레이션 프로젝트가 재사용하고 피할 수 있는 경험, 학습, 위험, 문제 및 솔루션을 기록하여 마이그레이션을 크게 가속화합니다. 패턴 및 아티팩트는 프로세스를 개선하고 향후 프로젝트를 안내하는 데 도움이 되는 투자이기도 합니다.

예를 들어 한 고객이 1년 동안 애플리케이션을 세 개의 서로 다른 SI AWS 파트너가 마이그레이션하는 마이그레이션을 수행했습니다. 초기 단계에서 각 AWS 파트너는 자체 표준, 런북 및 아티팩트를 사용하고 있었습니다. 이렇게 하면 고객 팀에 여러 가지 스트레스가 가해졌습니다. 동일한 정보를 다양한 방식으로 제공할 수 있기 때문입니다. 이러한 초기 문제가 발생한 후 고객은 마이그레이션에 사용할 모든 설명서 및 아티팩트에 대한 중앙 소유권을 확립하고 권장 변경 사항을 제출하는 프로세스를 마련했습니다. 이러한 자산에는 다음이 포함됩니다.

  • 표준 마이그레이션 프로세스 및 체크리스트

  • 네트워크 다이어그램 스타일 및 형식 표준

  • 비즈니스 중요도를 기반으로 한 애플리케이션 아키텍처 및 보안 표준

또한 이러한 문서 및 표준에 대한 변경 사항은 매주 모든 팀에 전송되었으며 각 파트너는 변경 사항의 수신 및 준수를 확인해야 했습니다. 이렇게 하면 마이그레이션 프로젝트의 커뮤니케이션과 일관성이 크게 향상되었으며, 다른 사업부에서 별도의 대규모 마이그레이션 작업이 시작되었을 때 해당 팀은 기존 프로세스와 문서를 채택하여 성공을 크게 가속화할 수 있었습니다.

마이그레이션 메타데이터 및 상태에 대한 단일 정확한 소스 설정

대규모 마이그레이션을 계획할 때 다양한 팀을 일치시키고 데이터 기반 결정을 가능하게 하려면 사실의 출처를 설정하는 것이 중요합니다. 이 여정을 시작하면 구성 관리 데이터베이스(CMDB), 애플리케이션 성능 모니터링 도구, 인벤토리 목록 등 사용할 수 있는 많은 데이터 소스를 찾을 수 있습니다.

또는 데이터 소스가 거의 없으며 필요한 데이터를 캡처하는 메커니즘을 생성해야 할 수도 있습니다. 예를 들어 검색 도구를 사용하여 기술 정보를 검색하고 IT 리더를 조사하여 비즈니스 정보를 얻어야 할 수 있습니다.

다양한 데이터 소스를 마이그레이션에 사용할 수 있는 단일 데이터 세트로 집계하는 것이 중요합니다. 그런 다음 구현 중에 마이그레이션을 추적하는 데 단일 사실 소스를 사용할 수 있습니다. 예를 들어 마이그레이션된 서버를 추적할 수 있습니다.

제공된 데이터 세트를 사용하여 마이그레이션을 계획하는 데 AWS 중점을 두고 모든 워크로드를 로 마이그레이션하려는 금융 서비스 고객입니다. 이 데이터 세트에는 비즈니스 중요도 및 종속성 정보와 같은 주요 격차가 있으므로 프로그램이 검색 연습을 시작했습니다.

또 다른 예로, 동일한 업계의 한 회사가 서버 인프라 인벤토리에 대한 out-of-date 이해를 기반으로 마이그레이션 웨이브 구현으로 전환했습니다. 데이터가 잘못되어 마이그레이션 수가 감소하기 시작했습니다. 이 경우 애플리케이션 소유자는 이해되지 않았으므로 테스터를 제시간에 찾을 수 없습니다. 또한 데이터는 애플리케이션 팀이 완료한 폐기와 일치하지 않았으므로 서버는 비즈니스 목적으로 사용되지 않고 실행되고 있었습니다.

대규모 마이그레이션 실행

비즈니스 성과를 수립하고 이해관계자에게 전략을 전달한 후에는 지속 가능한 마이그레이션 이벤트 또는 파도로 대규모 마이그레이션의 범위를 확장하는 방법을 계획할 수 있습니다. 다음 예제에서는 웨이브 계획을 세우기 위한 주요 지침을 제공합니다.

안정적인 흐름을 보장하기 위해 마이그레이션 웨이브를 미리 계획합니다.

마이그레이션 계획은 프로그램의 가장 중요한 단계 중 하나입니다. “계획에 실패하면 실패할 계획입니다.”라는 말과 함께 진행됩니다. 마이그레이션 웨이브를 미리 계획하면 팀이 마이그레이션 상황에 보다 선제적으로 대응하면서 프로젝트가 빠르게 흐를 수 있습니다. 프로젝트 규모를 더 쉽게 조정할 수 있으며 프로젝트 수요가 증가하고 복잡해짐에 따라 의사 결정 및 예측을 개선합니다. 또한 미리 계획하면 변화에 적응하는 팀의 능력도 향상됩니다.

예를 들어 한 대규모 금융 서비스 고객이 데이터 센터 종료 프로그램을 진행하고 있었습니다. 처음에 고객은 마이그레이션 웨이브를 순차적으로 계획하여 한 웨이브를 완료한 후 다음 웨이브를 계획했습니다. 이 접근 방식은 준비 시간을 단축했습니다. 이해 관계자가 애플리케이션이 로 마이그레이션되고 있음을 알았을 때 AWS마이그레이션을 시작하기 전에 여전히 몇 가지 단계를 수행해야 했습니다. 이로 인해 프로그램에 상당한 지연이 발생했습니다. 고객이 이를 깨달은 후 몇 달 전에 마이그레이션 웨이브가 계획되었던 총체적이고 미래 지향적인 마이그레이션 계획 스트림을 구현했습니다. 이를 통해 애플리케이션 팀이 AWS 파트너 알림, 라이선스 분석 등과 같은 마이그레이션 전 활동을 수행할 수 있는 충분한 알림이 제공되었습니다. 그런 다음 프로그램의 중요 경로에서 이러한 작업을 제거할 수 있습니다.

웨이브 구현 및 웨이브 계획을 별도의 프로세스 및 팀으로 유지

파도 계획과 파도 구현 팀이 별도의 경우 두 프로세스가 병렬로 작동할 수 있습니다. 통신 및 조정을 사용하면 서버 또는 애플리케이션이 예상 속도를 달성할 준비가 되지 않아 마이그레이션 속도가 느려지지 않습니다. 예를 들어 마이그레이션 팀은 매주 30개의 서버를 마이그레이션해야 할 수 있지만 현재 웨이브에서는 10개의 서버만 준비됩니다. 이 문제는 종종 다음과 같은 원인으로 인해 발생합니다.

  • 마이그레이션 구현 팀은 웨이브 계획에 관여하지 않았으며 웨이브 계획 단계에서 수집된 데이터가 완료되지 않았습니다. 마이그레이션 구현 팀은 파도를 시작하기 전에 더 많은 서버 데이터를 수집해야 합니다.

  • 마이그레이션 구현은 사이에 버퍼 없이 웨이브 계획 직후 시작되도록 예약됩니다.

웨이브를 미리 계획하고 준비와 웨이브 구현 시작 사이에 버퍼를 생성하는 것이 중요합니다. 또한 웨이브 계획 팀과 마이그레이션 팀이 협력하여 올바른 데이터를 수집하고 재작업을 피하도록 하는 것이 중요합니다.

좋은 결과를 얻으려면 소규모로 시작하세요.

각 후속 웨이브에서 소규모로 시작하고 마이그레이션 속도를 높일 계획을 세우세요. 초기 웨이브는 서버가 10개 미만인 작은 단일 애플리케이션이어야 합니다. 후속 웨이브에 애플리케이션과 서버를 추가하여 전체 마이그레이션 속도를 높입니다. 덜 복잡하거나 위험한 애플리케이션의 우선순위를 정하고 일정에 따라 속도를 높이면 팀이 함께 작업하도록 조정하고 프로세스를 배울 시간을 확보할 수 있습니다. 또한 팀은 각 파도를 통해 프로세스 개선을 식별하고 구현할 수 있으며, 이는 이후 파도의 속도를 크게 개선할 수 있습니다.

한 고객이 연간 1,300개 이상의 서버를 마이그레이션하고 있었습니다. 파일럿 마이그레이션과 몇 가지 작은 파도로 시작하여 마이그레이션 팀은 이후 마이그레이션을 개선하는 여러 방법을 식별할 수 있었습니다. 예를 들어 이전에 새 데이터 센터 네트워크 세그먼트를 식별했습니다. 이들은 프로세스 초기에 방화벽 팀과 협력하여 마이그레이션 도구와의 통신을 허용하는 방화벽 규칙을 마련했습니다. 이렇게 하면 향후 파도가 불필요하게 지연되는 것을 방지할 수 있습니다. 또한 팀은 각 웨이브에서 더 많은 검색 및 전환 프로세스를 자동화하는 데 도움이 되는 스크립트를 개발할 수 있었습니다. 소규모로 시작하면 팀이 초기 프로세스 개선에 집중하는 데 도움이 되었고 신뢰도가 크게 향상되었습니다.

전환 기간 수 최소화

대량 마이그레이션에는 규모를 늘리기 위한 엄격한 접근 방식이 필요합니다. 일부 영역에서는 유연성이 너무 뛰어나 대규모 마이그레이션을 위한 안티 패턴입니다. 주간 전환 기간 수를 제한하면 전환 활동에 소요된 시간이 더 큽니다.

예를 들어 전환 기간이 너무 유연한 경우 서버가 각각 5개인 전환이 20개 있을 수 있습니다. 대신 서버가 각각 50개인 전환 2개를 가질 수 있습니다. 각 전환에 대한 시간과 노력이 비슷하기 때문에 전환 횟수가 적고 전환 횟수가 클수록 일정 관리의 운영 부담이 줄어들고 불필요한 지연이 제한됩니다.

한 대규모 기술 회사가 계약 만료 전에 몇 개의 임대 데이터 센터에서 마이그레이션하려고 했습니다. 만료를 놓치면 비용이 많이 드는 단기 갱신 기간이 발생합니다. 마이그레이션 초기에 애플리케이션 팀은 전환 며칠 전에 어떤 이유로든 마이그레이션을 옵트아웃하는 등 마지막 순간까지 마이그레이션 일정을 지시할 수 있었습니다. 이로 인해 프로젝트 초기 단계에서 많은 지연이 발생했습니다. 고객은 마지막 순간에 다른 애플리케이션 팀과 협상하여 작성해야 했던 경우가 많습니다. 고객은 결국 계획 원칙을 늘렸지만이 초기 실수로 인해 마이그레이션 팀에 지속적인 스트레스가 발생했습니다. 전체 일정이 지연되면 일부 애플리케이션에서 데이터 센터를 제시간에 사용하지 못하게 됩니다.

빠른 실패, 경험 적용 및 반복

모든 마이그레이션에는 처음에는 위험이 있습니다. 조기에 실패하면 팀이 병목 현상을 배우고 이해하며, 더 큰 파도에 학습한 교훈을 적용하는 데 도움이 됩니다. 다음과 같은 이유로 마이그레이션의 첫 번째 두 파도가 느려질 것으로 예상됩니다.

  • 팀원이 서로와 프로세스에 맞게 조정하고 있습니다.

  • 대규모 마이그레이션에는 일반적으로 다양한 도구와 사람이 포함됩니다.

  • end-to-end 프로세스를 통합, 테스트, 실패, 학습 및 지속적으로 개선하는 데 시간이 걸립니다.

문제는 공통적이며 첫 몇 번의 파도 중에 예상됩니다. 일부 팀은 새로운 것을 시도하고 실패하는 것을 좋아하지 않을 수 있으므로 이를 이해하고 조직 전체에 알리는 것이 중요합니다. 실패는 팀을 방해하고 향후 마이그레이션을 방해할 수 있습니다. 모든 사람이 초기 문제가 작업의 일부임을 이해하고 모든 사람이 시도하고 실패하도록 장려하는 것이 성공적인 마이그레이션의 핵심입니다.

한 회사는 24~36개월 동안 10,000개 이상의 서버를 마이그레이션할 계획이었습니다. 이 목표를 달성하기 위해 한 달에 거의 300개의 서버를 마이그레이션해야 했습니다. 그러나 이는 첫날부터 300개의 서버를 마이그레이션했음을 의미하지는 않습니다. 첫 번째 두 파도는 팀이 사물의 작동 방식과 누가 무엇을 할 수 있는 권한이 있는지 이해할 수 있도록 파도를 학습시키는 것이었습니다. 또한 CMDB 및 CyberArk와의 통합과 같이 프로세스를 개선할 통합을 식별했습니다. 이들은 학습 파도를 사용하여 실패, 개선 및 다시 실패하여 프로세스와 자동화를 개선했습니다. 6개월 후 매주 120개 이상의 서버를 마이그레이션할 수 있었습니다.

회고를 잊지 마세요.

이는 애자일 프로세스의 중요한 부분입니다. 팀이 소통하고, 조정하고, 배우고, 동의하고, 전진하는 곳입니다. 가장 기본적인 수준의 소급 적용은 되돌아보고, 어떤 일이 발생했는지 논의하고, 잘 된 점과 개선해야 할 점을 결정하는 것입니다. 그런 다음 이러한 논의를 기반으로 개선 사항을 구축할 수 있습니다. 소급적 표현은 학습한 교훈에 대한 개념을 중심으로 몇 가지 격식이나 프로세스를 래핑합니다. 대규모 마이그레이션이 성공하려면 프로세스, 도구 및 팀이 지속적으로 발전하고 개선되어야 하기 때문에 소급성이 중요합니다. 소급적 요인은 이에 중요한 역할을 할 수 있습니다.

기존 레슨 학습 세션은 프로그램이 끝날 때까지 수행되지 않으므로 다음 마이그레이션 웨이브가 시작될 때 이러한 레슨을 검토하지 않는 경우가 많습니다. 대규모 마이그레이션의 경우 학습한 교훈을 다음 웨이브에 적용해야 하며 웨이브 계획 프로세스의 핵심 부분이어야 합니다.

한 고객의 경우 전환에서 얻은 교훈을 논의하고 문서화하기 위해 주간 소급 조치가 진행되었습니다. 이러한 세션에서는 프로세스 관점 또는 자동화에서 간소화 범위가 있는 영역을 발견했습니다. 이로 인해 전환 중에 타사 도구 검증 및 Amazon CloudWatch 에이전트 설치를 포함한 수동 작업을 최소화하기 위해 특정 활동, 소유자 및 자동화 스크립트가 포함된 카운트다운 일정이 구현되었습니다.

또 다른 대규모 기술 회사에서는 이전 마이그레이션 파도 문제를 식별하기 위해 팀과 정기적인 소급 조치를 취했습니다. 이로 인해 프로세스, 스크립트 및 자동화가 개선되어 프로그램 진행 과정에서 평균 마이그레이션 시간이 40% 감소했습니다.

추가 고려 사항

많은 영역을 대규모 마이그레이션 프로그램에 고려해야 합니다. 다음 섹션에서는 고려해야 할 다른 항목에 대한 생각을 제공합니다.

진행 중 정리

예상한 것보다 10배의 비용이 들고 마이그레이션에 사용되는 리소스가 종료되고 정리될 때까지 프로젝트가 완료되지 않으면 마이그레이션이 성공한 것으로 간주되지 않습니다. 이 정리는 마이그레이션 후 활동의 일부여야 합니다. 이를 통해 사용하지 않는 리소스와 서비스를 환경에 그대로 두어 비용에 추가하지 않도록 할 수 있습니다. 마이그레이션 후 정리는 환경을 노출하는 위협과 취약성을 방지하기 위한 모범 보안 사례이기도 합니다.

로 전환하면 비용 절감과 보안 AWS 클라우드 이라는 두 가지 주요 결과가 있습니다. 사용하지 않는 리소스를 그대로 두면 클라우드로 전환하려는 비즈니스 목적이 무너질 수 있습니다. 정리되지 않은 가장 일반적인 리소스는 다음과 같습니다.

  • 테스트 데이터

  • 데이터베이스 테스트

  • 방화벽 규칙, 보안 그룹 및 네트워크 액세스 제어 목록(네트워크 ACL) IP 주소를 포함한 계정 테스트

  • 테스트를 위해 프로비저닝된 포트

  • Amazon Elastic Block Store(Amazon EBS) 볼륨

  • 스냅샷

  • 복제(예: 온프레미스에서 로 데이터 복제 중지 AWS)

  • 스페이스를 사용하는 파일(예: 마이그레이션에 사용되는 임시 데이터베이스 백업)

  • 마이그레이션 도구를 호스팅하는 인스턴스

잘못된 정리 관행의 한 예에서 SI AWS Partners는 마이그레이션 성공 후 복제 에이전트를 제거하지 않았습니다. AWS 감사 결과 이미 마이그레이션된 복제 서버와 EBS 볼륨의 비용은 매월 20,000 USD(USD)입니다. 문제를 완화하기 위해 AWS Professional Services는 오래된 서버가 아직 복제되고 있을 때 SI AWS 파트너에게 알리는 자동 감사 프로세스를 생성했습니다. 그런 다음 SI AWS 파트너는 미사용 및 오래된 인스턴스에 대해 조치를 취할 수 있습니다.

향후 마이그레이션의 경우 원활한 플랫폼 채택을 위해 마이그레이션 후 하이퍼케어 기간을 48시간으로 정의하는 프로세스가 채택되었습니다. 그런 다음 고객의 인프라 팀이 온프레미스 서버에 대한 서비스 해제 요청을 제출했습니다. 서비스 해제 요청이 승인되면 애플리케이션 마이그레이션 서비스 콘솔에서 해당 웨이브의 서버가 제거되는 것이 좋습니다.

추가 변환을 위한 여러 단계 구현

대규모 마이그레이션을 수행할 때는 데이터 센터 폐쇄 또는 인프라 혁신과 같은 핵심 목표에 집중하는 것이 중요합니다. 소규모 마이그레이션에서는 범위 크리프가 최소한의 영향을 미칠 수 있습니다. 그러나 며칠 동안 추가 노력에 수천 대의 서버를 곱하면 프로그램에 상당한 시간이 추가될 수 있습니다. 또한 추가 변경 사항으로 인해 지원 팀을 위한 설명서, 프로세스 및 교육에 대한 업데이트가 필요할 수도 있습니다.

잠재적 범위 크립을 극복하기 위해 마이그레이션에 대한 다단계 접근 방식을 구현할 수 있습니다. 예를 들어, 목표가 데이터 센터를 비우는 경우 1단계에는 워크로드를 가능한 한 빨리 AWS 로 다시 호스팅하는 것만 포함될 수 있습니다. 워크로드가 리호스팅되면 2단계는 대상 비즈니스 성과를 위험하게 하지 않고 혁신 활동을 구현할 수 있습니다.

예를 들어 한 고객이 12개월 후에 데이터 센터를 종료할 계획이었습니다. 그러나 마이그레이션에는 새로운 애플리케이션 성능 모니터링 도구 출시 및 운영 체제 업그레이드와 같은 다른 변환 활동이 포함되었습니다. 1,000개 이상의 서버가 마이그레이션 범위에 있었기 때문에 이러한 활동으로 인해 마이그레이션이 크게 지연되었습니다. 또한이 접근 방식에는 새 도구 사용에 대한 교육이 필요했습니다. 나중에 고객은 리호스팅에 초점을 맞춘 다단계 접근 방식을 구현하기로 결정했습니다. 이로 인해 마이그레이션 속도가 빨라지고 데이터 센터 폐쇄 날짜를 충족하지 못할 위험이 줄어들었습니다.