SAP 시스템을 Microsoft Azure로 마이그레이션하기 위한 전략 분석
Azure에 SAP 워크로드 배포를 고려하는 대부분의 고객은 기존 온-프레미스 SAP 구현이 있습니다. 완전히 새로운 배포 수는 비교적 적습니다.
일반적으로 엔터프라이즈에는 ERP(전사적 자원 계획), 세계 무역, BI(비즈니스 인텔리전스) 등의 비즈니스 기능을 위한 SAP 시스템이 있습니다. 해당 시스템 내에는 샌드박스, 개발, 테스트, 프로덕션 같은 환경이 있습니다.
위 그림에서 각 가로 행은 환경입니다. 각 열은 비즈니스 기능(예: ERP, BI)을 위한 SAP 시스템입니다.
아래쪽에 있는 행 또는 계층이 중요도가 낮은 덜 위험한 환경입니다. 위쪽에 있는 행 또는 계층이 중요도가 높고 더 위험합니다. 스택 위로 이동함에 따라 마이그레이션 프로세스에 더 많은 위험이 있습니다. 따라서 프로덕션이 가장 중요한 환경이며 비즈니스 연속성에도 사용되는 사용자 승인 테스트(테스트) 환경이 두 번째로 중요합니다.
아래쪽에 있는 시스템은 컴퓨팅 리소스 수가 더 적고 가용성 및 크기 요구 사항이 더 낮으며 처리량이 더 적다는 점에서 규모가 더 작습니다. 그러나 스토리지 크기는 프로덕션 데이터베이스와 동일합니다.
수평 전략
수평 전략을 사용하는 경우 스택의 맨 아래에서 시작합니다. Azure를 실험하면서 사용 경험을 얻는 것이 안전한 방법이기 때문입니다. 운영, 배포, 승인 프로세스를 다시 정의하는 동안 사용하기에 좋은 전략이기도 합니다. Azure로 이동함에 따라 프로세스가 변경됩니다. 전략의 작동 방식은 다음과 같습니다.
- 위험을 제한하려면 영향이 적은 샌드박스 또는 교육 시스템으로 시작합니다. 문제가 발생하더라도 많은 사용자나 중요 업무용 비즈니스 기능에 영향을 미칠 위험이 거의 없습니다.
- Azure에서 SAP 시스템을 실행, 호스트, 관리하여 경험을 쌓으면서 배운 내용을 스택 위쪽의 다음 시스템 계층에 적용합니다.
- 각 계층에 대해 비용, 잠재적 절감액, 성능, 최적화 가능성을 예측하고 필요한 경우 조정합니다.
수직 전략
Azure에서 프로덕션 시스템을 사용하며 경험을 쌓으려면 수평 전략과 병행하여 덜 위험한 시스템에서 수직 전략을 사용합니다. 이렇게 하면 Azure에 맞게 내부 프로세스를 조정하고 팀원을 교육할 기회도 제공됩니다. 프로덕션에서 발생하는 이슈를 조기에 발견하기에 좋은 방법입니다. 전략의 작동 방식은 다음과 같습니다.
- 비용, 고객, SLA(서비스 수준 계약), 법적 요구 사항에 미치는 영향을 확인합니다. 먼저 거버넌스, 위험 및 규정 준수 시스템, OER(개체 이벤트 리포지토리) 시스템 등의 위험 수준이 가장 낮은 시스템을 샌드박스에서 프로덕션까지 이동합니다. 그런 다음, BI, ERP 등의 위험 수준이 높은 시스템을 이동합니다.
- 새 SAP 시스템이 있는 경우 온-프레미스에 배치하고 나중에 이동하는 대신 기본적으로 Azure에서 시작합니다. 다이어그램에서 해당하는 예는 OER입니다. OER은 위험 수준이 낮은 새로운 시스템입니다. 수평 전략을 사용하여 다른 일부 시스템을 Azure로 이동한 후에는 전체 OER 수직 스택을 Azure에 엔드투엔드(샌드박스에서 프로덕션까지)로 배포할 수 있습니다.
- 가장 중요한 시스템을 먼저 이동하지 않습니다. 마지막으로 이동하는 시스템은 위험 수준이 가장 높은 중요 업무용 시스템인 ERP 프로덕션 시스템입니다. 가장 성능이 뛰어난 가상 머신 SKU와 최대 규모의 스토리지가 필요합니다.
- 독립 실행형 시스템을 먼저 이동합니다. 일부 시스템은 ERP 및 GTS 시스템 등의 다른 시스템과 긴밀하게 연결되어 있습니다. 두 시스템 간에 많은 동기 실시간 트래픽이 있습니다. ERP를 Azure로 이동하면서 GTS는 온-프레미스에 유지할 경우 네트워크 대기 시간으로 인해 성능이 저하되므로 함께 이동합니다.
- 여러 SAP 시스템이 있는 경우 SAP 시스템 간 또는 SAP에서 SAP 에코시스템 외부 앱으로의 업스트림 및 다운스트림 종속성을 찾습니다. 대기 시간이 매우 중요한 트래픽 패턴 및 영역을 조사합니다.
- 긴밀하게 연결된 시스템이 있으면 성능 분석을 수행하여 시스템을 이동할 경우의 영향을 확인합니다. 영향이 크지 않으면 개별적으로 Azure로 이동했습니다(예: ERP와 무관한 Business Warehouse). 영향이 크면 마이그레이션 그룹을 만들어 함께 이동했습니다.
- 경우에 따라 기다리는 것이 좋습니다. 특정 시스템을 Azure로 바로 이동하지 않으려는 경우도 있습니다. 처리 요구 사항이 너무 높아 가상 머신이 충분히 크지 않은 경우 크기 조정 요구 사항과 관련이 있을 수 있습니다. 테스트를 실행하여 해당 시스템을 이동해도 고객과의 SLA에 영향을 주지 않도록 합니다.