설계 단계 모범 사례

그린필드 SAP 구현의 설계 단계는 성공적인 빌드 단계를 위한 토대입니다. 이 단계에서는 인프라 이해관계자와 협력하여 요구 사항을 수집하고 아키텍처를 문서화합니다. 고려해야 할 추가 조정 사항도 있습니다. 다양한 프로젝트 이해관계자가 타임라인, 풍경 전략, 고가용성(HA) 및 재해 복구(DR) 환경을 포함한 SAP on AWS 아키텍처에 동의하는지 확인해야 합니다. 이 섹션에서는 프로젝트의 설계 단계에서 발생할 수 있는 몇 가지 문제를 해결하기 위한 권장 사항을 제공합니다.

납품 타임라인 및 풍경 다이어그램 생성

비즈니스 혁신 프로젝트 타임라인을 공유하는 즉시 인프라 납품 타임라인을 수립합니다. 이를 통해 미리 계획을 세우고 인프라 팀 내에서 조율할 수 있습니다. 타임라인 수립을 위한 주요 의견은 SAP 프로젝트 팀의 시스템 통합 사업자(SI)가 제공합니다. 다시 검토하여 SAP Basis 팀이 작업을 완료해야 하는 날짜와 SAP Basis 팀이 SAP 애플리케이션을 설치할 수 있도록 인프라를 준비해야 하는 시기를 파악합니다.

고려 사항:

• 납품 타임라인을 시각적으로 표시하면 팀이 구축 계획, 소요 기한, 발생 가능한 리소스 경합 등을 빠르게 파악할 수 있습니다. 또한 주요 이해관계자가 구축 중인 환경, 프로젝트 기간,와 SAP Basis 팀 간의 핸드오프 AWS 를 이해하기 쉬운 방식으로 시각화할 수 있습니다.

  

• 일반적인 그린필드 SAP 구축 기간은 1년 이상입니다. 여기에는 인프라 팀이 인프라 구성 요소를 적극적으로 구축하지 않는 시간도 포함되므로 해당 기간 동안의 활동과 결과물을 고려하는 것이 중요합니다. 매핑할 활동의 예로는 HA 설정 및 테스트, DR 설정 및 테스트, 성능 테스트, 구축 자동화 스크립트 등이 있습니다.

• 그린필드 구현에서는 풍경과 환경의 개념을 이해하기 어려울 수 있습니다. 환경과 풍경(N, N+1, N+2)을 구분하는 색상으로 구분된 타임라인은 이해관계자가 이러한 정보 매트릭스를 빠르게 이해하는 데 도움이 될 수 있습니다.

  다음은 일반적인 개괄적 SAP 풍경 다이어그램의 예입니다. 상자는 애플리케이션 모음(예: SAP S/4HANA)인 환경을 나타내고, 풍경은 특정 릴리스에 사용되는 환경 모음입니다.

  

• 로드맵을 생성할 때 상위 수준 로드맵을 다시 살펴보고 팀이 설립될 때까지 분기별로 장기 계획을 수행하는 것이 좋습니다. 마이그레이션 외에도 Cloud Center of Excellence(CCoE), 운영 자동화, 보안 및 규정 준수, 클라우드 재해 복구를 위한 워크스트림과 같은 다른 로드맵 항목을 포함합니다.

리전 서비스 이해 및 의사결정 문서화

기본 리전을 올바르게 선택할 수 AWS 리전 있도록 설계 단계를 시작할 때 특정에서 사용할 수 있는 서비스를 이해하고 논의하는 데 시간을 할애하는 것이 좋습니다. 특히 SAP에는 고성능 인스턴스가 필요한 경우가 많으므로 기본 또는 보조 리전에서 이러한 리소스를 사용할 수 있는지 확인해야 합니다. SAP 애플리케이션에 대해 인증된 인스턴스 유형을 선택합니다. 선택한 AWS 리전 에서 인스턴스 유형을 사용할 수 있는지 확인하세요. 이를 확인하는 빠르고 쉬운 방법은 인스턴스 유형 제공에 대해AWS Command Line Interface (AWS CLI) 명령을 사용하는 것입니다. 구현에 사용하려는 서비스가 현재 해당 리전에서 제공되지 않는 경우 해당 리전의 인프라를 주문하는 데 소요되는 리드 타임을 고려하세요.

리전 관련 결정을 확인, 재확인 및 문서화합니다. 이러한 결정을 대규모 프로젝트 팀 전체에 전달하여 주요 이해관계자에게 알립니다. 프로젝트에 대한 아키텍처 검토 위원회가 있는 경우 이 주제를 제시하여 결정이 확정되기 전에 모든 사람이 고려할 기회를 갖도록 합니다.

고려 사항:

• 주요 고려 사항은 SAP와 통합되는 경계 시스템입니다. 경계 또는 위성 애플리케이션을 호스팅하는 경우 지연 시간에 대한 불필요한 논의를 방지하기 위해 동일한 기본 리전에서 SAP를 호스팅하는 AWS것이 가장 좋습니다. 지연 시간이 문제가 되지 않는다는 것을 확인하더라도 경계 애플리케이션이 SAP 애플리케이션과 다른 리전에 구축되는 이유를 이해관계자에게 설명하기는 어렵습니다.

• 재해 복구(DR) 테스트를 현실적으로 조정할 수 있도록 DR 사이트도 SAP 및 SAP와 통합되는 시스템에 대해 동일해야 합니다. 시스템마다 솔루션이 다를 수 있습니다. 예를 들어 BusinessObjects 또는 Winshuttle AWS Elastic Disaster Recovery 과 같은 대규모 SAP 시스템은에서 작동하지 않을 수 있으며 Amazon Relational Database Service(Amazon RDS) 데이터베이스를 사용하는 다른 솔루션이 필요할 수 있습니다.

이름 지정 규칙 설정

호스트, SAP 환경, Virtual Private Cloud(VPC) 및 AWS 계정에 대한 명명 규칙을 철저히 검사하고 문서화합니다. 기존 표준이나 규칙을 따라야 합니다. 그린필드 구현에서는 이름 지정 규칙을 처음부터 정의해야 할 수도 있습니다. 일관성을 유지합니다. 예를 들어 VPC Pre-Prod, SAP 환경 UAT 및 AWS 계정 TST를 호출하는 경우 지원 관점에서 이러한 세 이름을 연결하는 것이 어려울 수 있습니다. 합의를 도출하고 모든 문자에 의미가 있는 이름을 지정하되 융통성을 발휘할 수 있는 여지를 남겨둡니다. 예를 들어, 나중에 다른 리전으로 전환해야 하는 경우를 대비하여 리전 이름을 서버 이름에 하드코딩하지 마세요. 온프레미스 서버에 사용 중인 이름 지정 규칙을 사용하지 마세요. 대신, 조직에 아직 없는 경우 유연한 클라우드 이름 지정 규칙을 권장합니다.

고려 사항:

• 변경될 수 있는 정보에는 AWS 태그 지정을 사용합니다.

• 프로덕션 VPC에 비 프로덕션 환경을 두지 마세요. 이것이 요구 사항인 경우 동의하기 전에 타당한 이유가 있는지 확인합니다.

모든 결정을 문서화합니다.

각 결정의 모든 변동, 결정을 내린 사람, 날짜, 참석자 등을 철저하게 문서화하는 것이 좋습니다. Atlassian Confluence 또는 스프레드시트와 같은 공공 장소에 결정을 저장하고 결정에 대한 적절한 승인을 보장합니다. 이해관계자 또는 팀원이 이러한 합의를 잊어버리고 설계 또는 구축 단계 후반에 결정에 이의를 제기할 수 있습니다. 이러한 경우 모든 질문을 해결할 수 있는 데이터를 즉시 사용할 수 있도록 해야 합니다. 다음은 문서화해야 할 주요 결정의 예입니다.

• 리전 결정

• HA 관련 애플리케이션

• 재해 복구 결정

• 프로젝트 단계 중 환경 지원 모델

• 백업 및 복원 방법과 도구

• VPC 구조

• AWS 계정 결정

• 보안 결정

또한 모든 제품 기능 요청을 추적하고 팀이 변경 사항을 구현하는 데 걸린 시간을 문서화합니다.