마이그레이션 전 워크로드 설계Architect workloads prior to migration

이 문서에서는 지정된 반복 내에서 작업 아키텍처를 정의하는 것과 관련된 활동을 검토하여 평가 프로세스를 확장합니다.This article expands on the assessment process by reviewing activities associated with defining the architecture of a workload within a given iteration. 증분 합리화에 대한 문서에서 설명하는 것처럼 마이그레이션이 필요한 비즈니스 변환 중에 몇 가지 아키텍처 가정이 수행됩니다.As discussed in the article on incremental rationalization, some architectural assumptions are made during any business transformation that requires a migration. 이 문서에서는 이러한 가정을 명확하게 하고, 피할 수 있는 몇 가지 장애물을 공유하고, 이러한 가정을 해결하여 비즈니스 가치를 가속화할 수 있는 기회를 식별합니다.This article clarifies those assumptions, shares a few roadblocks that can be avoided, and identifies opportunities to accelerate business value by challenging those assumptions. 이러한 아키텍처 증분 모델을 통해 팀은 더 빠르게 행동하고 비즈니스 결과를 얻을 수 있습니다.This incremental model for architecture allows teams to move faster and to obtain business outcomes sooner.

마이그레이션 전 아키텍처 가정Architecture assumptions prior to migration

다음 가정은 모든 마이그레이션 작업에서 일반적으로 발생합니다.The following assumptions are typical for any migration effort:

  • IaaS.IaaS. 일반적으로 워크로드 마이그레이션 중에는 주로 IaaS 마이그레이션을 통해 물리적 데이터 센터에서 클라우드 데이터 센터로 가상 머신이 이동되므로 최소한의 다시 개발 또는 재구성이 필요합니다.It is commonly assumed that migrating workloads primarily involves the movement of virtual machines from a physical datacenter to a cloud datacenter via an IaaS migration, requiring a minimum of redevelopment or reconfiguration. 이 접근 방식을 리프트 앤 시프트 마이그레이션 이라고 합니다.This approach is known as a lift and shift migration. 예외는 다음과 같습니다.(Exceptions follow.)
  • 아키텍처 일관성.Architecture consistency. 마이그레이션 중에 핵심 아키텍처가 변경되면 상황에 매우 복잡해집니다.Changes to core architecture during a migration considerably increase complexity. 새 플랫폼에서 변경된 시스템을 디버깅하면 격리하기 어려울 수 있는 많은 변수가 발생합니다.Debugging a changed system on a new platform introduces many variables that can be difficult to isolate. 이러한 이유로 워크로드는 마이그레이션 중에 약간만 변경하고 모든 변경 내용을 철저히 테스트해야 합니다.For this reason, workloads should undergo only minor changes during migration and any changes should be thoroughly tested.
  • 사용 중지 테스트.Retirement test. 마이그레이션 및 자산의 호스팅을 통해 운영 비용 및 잠재적인 자본 지출이 발생합니다.Migrations and the hosting of assets consume operational and potential capital expenses. 마이그레이션하려는 모든 워크로드를 검토하여 진행 중인 사용 방식이 유효한지 검사했다고 가정합니다.It is assumed that any workloads being migrated have been reviewed to validate ongoing usage. 사용하지 않는 자산의 사용을 중지하도록 선택하면 즉각적인 비용 절감 효과를 얻을 수 있습니다.The choice to retire unused assets produces immediate cost savings.
  • 자산 크기 조정.Resize assets. 할당된 리소스를 완전히 사용하고 있는 온-프레미스 자산은 거의 없다고 가정합니다.It is assumed that few on-premises assets are fully using the allocated resources. 마이그레이션을 수행하기 전에 자산의 크기가 실제 사용 요구 사항에 가장 잘 맞도록 조정될 것으로 간주됩니다.Prior to migration, it is assumed that assets will be resized to best fit actual usage requirements.
  • BCDR(비즈니스 연속성 및 재해 복구) 요구 사항.Business continuity and disaster recovery (BCDR) requirements. 워크로드에 대해 합의된 SLA를 릴리스 계획 이전에 비즈니스와 협의했다고 가정합니다.It is assumed that an agreed-on SLA for the workload has been negotiated with the business prior to release planning. 이러한 요구 사항은 사소한 아키텍처 변경을 발생할 가능성이 높습니다.These requirements are likely to produce minor architecture changes.
  • 마이그레이션 가동 중지 시간.Migration downtime. 마찬가지로 워크로드를 프로덕션으로 승격할 때 수반되는 가동 중지 시간은 비즈니스에 좋지 않은 영향을 미칠 수 있습니다.Likewise, downtime to promote the workload to production can have an adverse effect on the business. 경우에 따라 최소한만 가동을 중지하면서 전환해야 하는 솔루션은 아키텍처를 변경해야 합니다.Sometimes, the solutions that must transition with minimum downtime need architecture changes. 릴리스 계획 전에 가동 중지 시간 요구 사항의 일반적인 부분을 이해하고 있다고 가정합니다.It is assumed that a general understanding of downtime requirements has been established prior to release planning.
  • 사용자 트래픽 패턴.User traffic patterns. 기존 솔루션은 기존 네트워크 라우팅 패턴에 따라 달라질 수 있습니다.Existing solutions may depend on existing network routing patterns. 이러한 패턴으로 인해 성능이 크게 저하될 수 있습니다.These patterns could slow performance considerably. 또한 새로운 하이브리드 WAN(광역 네트워크) 솔루션을 도입하는 데 몇 주 또는 몇 개월이 걸릴 수도 있습니다.Further, introduction of new hybrid wide area network (WAN) solutions can take weeks or even months. 마이그레이션 전에는 방문 영역이 관련 트래픽 패턴 및 핵심 인프라 서비스의 변경 사항을 이미 고려 했다고 가정 합니다.Prior to migration, it is assumed that your landing zones have already considered the relevant traffic patterns and changes to any core infrastructure services.

잠재적 장애물 완화Mitigating potential roadblocks

항목별 가정을 통해 진행 상황을 느리게 만들거나 나중에 문제점을 야기할 수 있는 장애물이 파생될 수 있습니다.The itemized assumptions can create roadblocks that could slow progress or cause later pain points. 다음은 릴리스 전에 감시할 몇 가지 장애물입니다.The following are a few roadblocks to watch for, prior to the release:

  • 기술적인 문제 해결.Paying for technical debt. 일부 에이징 워크로드는 많은 양의 기술적인 문제를 수반합니다.Some aging workloads carry with them a high amount of technical debt. 기술 부채는 클라우드 공급자를 사용 하 여 호스팅 비용을 증가 시켜 장기적인 문제를 일으킬 수 있습니다.Technical debt can lead to long-term challenges by increasing hosting costs with any cloud provider. 기술적 문제로 인해 호스팅 비용이 비정상적으로 높아지는 경우 대체 아키텍처를 고려해야 합니다.When technical debt unnaturally increases hosting costs, alternative architectures should be evaluated.
  • 안정성 향상.Improving reliability. 표준 운영 기준은 클라우드에서 안정성 및 복구 수준을 제공 합니다.Standard operations baselines provide a degree of reliability and recovery in the cloud. 그러나 일부 워크 로드 팀은 아키텍처를 변경 하는 데 더 높은 Sla가 필요할 수 있습니다.But, some workload teams may require higher SLAs which could lead to architectural changes.
  • 높은 비용의 작업.High-cost workloads. 마이그레이션 중에는 실제 사용량에 맞게 크기를 조정 하도록 모든 자산을 최적화 해야 합니다.During migration, all assets should be optimized to align sizing with actual usage. 그러나 특정 비용 문제를 해결 하려면 일부 워크 로드에서 아키텍처를 수정 해야 할 수도 있습니다.But, some workloads may require architectural modifications to address specific cost concerns.
  • 성능 요구 사항.Performance requirements. 워크 로드 성능에 직접적인 영향을 주는 경우 추가 아키텍처 고려 사항이 필요할 수 있습니다.When workload performance has a direct business impact, extra architectural consideration may be required.
  • 응용 프로그램을 보호 합니다.Secure applications. 보안 요구 사항은 중앙에서 구현 되 고 포트폴리오의 모든 워크 로드에 적용 되는 경향이 있습니다.Security requirements tend to be implemented centrally and applied to all workloads in the portfolio. 그러나 일부 워크 로드에는 아키텍처 변경을 유발할 수 있는 특정 보안 요구 사항이 있을 수 있습니다.But, some workloads may have specific security requirements that could lead to architectural changes.

위의 각 조건은 잠재적인 마이그레이션 장애물의 표시기로 사용 됩니다.Each of the above criteria serve as indicators of potential migration roadblocks. 위의 조건은 일반적으로 워크 로드가 마이그레이션된 후에 해결 됩니다.The above criteria is usually addressed after a workload is migrated. 그러나 작업을 마이그레이션하기 전에 이러한 기준이 필요한 경우 마이그레이션 wave에서 제거 하 고 개별적으로 평가 해야 합니다.But if any of those criteria are required before a workload is migrated, it should be removed from the migration wave and evaluated individually.

Microsoft Azure Well-Architected 프레임 워크Microsoft Azure Well-Architected 검토 를 사용 하면 특정 작업의 기술적 소유자와 이러한 대화를 안내 하 여 작업을 배포 하는 데 필요한 다른 옵션을 고려할 수 있습니다.The Microsoft Azure Well-Architected Framework and Microsoft Azure Well-Architected Review can help guide those conversations with the technical owner of a specific workload to consider alternative options for deploying the workload. 이러한 워크 로드는 클라우드 도입 계획의 아키텍처를 위한 노력으로 분류 됩니다.Those workloads would then be classified as a rearchitecture effort in your cloud adoption plan. 워크 로드를 다시 구성 하는 데 필요한 추가 시간을 고려 하 여 이러한 대체 워크 로드 도입 경로를 마이그레이션 프로세스의 일부로 고려 하지 않아야 합니다.Given the extra time required to rearchitect a workload, these alternative workload adoption paths should not be considered part of the migration process.

비즈니스 가치 가속화Accelerate business value

일부 시나리오에는 가정된 IaaS 재호스팅 전략과는 다른 아키텍처가 필요할 수 있습니다.Some scenarios could require an different architecture than the assumed IaaS rehosting strategy. 다음은 몇 가지 예제입니다.The following are a few examples:

  • PaaS 현대화.PaaS modernization. 일부 기술 자산은 서비스 솔루션으로 최신 플랫폼으로 마이그레이션하여 마이그레이션 중에 위험을 줄일 수 있습니다.Some technology assets can be migrated to more modern Platform as a Service solutions, reducing risk during migration. Azure Migrate와 같은 자동화 된 마이그레이션 도구를 통해 현대화 기회를 제안 하 고 자동화할 수도 있습니다.Automated migration tools like Azure Migrate suggest and even automate modernization opportunities. 진행 중인 현대화의 몇 가지 예로는 DMS (Azure Database Migration Service )를 현대화 데이터베이스에 사용 하는 것과 같은 낮은 위험 변화가 있습니다.A few examples of in-flight modernization would include low risk changes like the use of Azure Database Migration Service (DMS) to modernize databases. PaaS 변환의 이점을 활용할 수 있는 방법 목록은 자산평가에 대한 문서를 참조하세요.For a list of approaches that could benefit from a PaaS conversion, see the article on evaluating assets.
  • 스크립팅된 배포/DevOps.Scripted deployments/DevOps. 워크로드에 기존 DevOps 배포나 다른 형태의 스크립팅된 배포가 있는 경우 해당 스크립트를 변경하는 비용은 자산의 마이그레이션 비용보다 낮을 수 있습니다.If a workload has an existing DevOps deployment or other forms of scripted deployment, the cost of changing those scripts could be lower than the cost of migrating the asset.
  • 수정 작업.Remediation efforts. 워크로드의 마이그레이션을 준비하는 데 필요한 수정 작업은 광범위할 수 있습니다.The remediation efforts required to prepare a workload for migration can be extensive. 경우에 따라 기본 호환성 문제를 해결하는 것보다 솔루션을 현대화하는 것이 더 적합할 수 있습니다.In some cases, it makes more sense to modernize the solution than it does to remediate underlying compatibility issues.

이러한 항목별 시나리오에서 대체 아키텍처는 가능한 최상의 솔루션일 수 있습니다.In each of these itemized scenarios, an alternative architecture could be the best possible solution.

다음 단계Next steps

새 아키텍처를 정의한 후 정확한 비용 추정치를 계산할 수 있습니다.After the new architecture is defined, accurate cost estimations can be calculated.