빌드 단계 모범 사례

이 섹션의 권장 사항은 프로젝트의 빌드 단계를 더 원활하게 진행하는 데 도움이 됩니다. 빌드 단계에는 코드, 개발, 배포 및 구현 활동이 포함됩니다. 설계 검토 및 승인 세션, 빌드 대상, 타임라인, 종료 기준을 조율하기 위한 킥오프 미팅으로 구성되는 경우가 많습니다. 이 단계는 모든 AWS 서비스에 대해 코드가 작성되고, 피어 리뷰되고, 배포되는 단계입니다.

다음 권장 사항에서는 테스트 또는 검증 활동도 다룹니다.

일일 스탠드업 미팅을 주최합니다.

어떤 프로젝트 방법론을 사용하든 일일 스탠드업 미팅을 주최합니다. 일일 스탠드업은 애자일 방법론과 관련이 있지만 워터폴 모델을 비롯한 다른 방법론에서도 매우 유용한 팀 연결 메커니즘이기도 합니다. 다양한 방법론에서 모범 사례를 가져오는 하이브리드 프로젝트 프레임워크를 사용할 수도 있습니다.

고려 사항:

• Jira 보드와 같은 간단한 것을 사용하여 모든 작업에 대한 스토리를 만들 수 있습니다. 이 보드는 일일 스탠드업을 위한 가이드가 될 것입니다. 팀에 충분한 역량과 전문 지식이 있다면 Scaled Agile Framework(SAFe) 방법론을 사용하여 에픽을 생성할 수도 있습니다. 그러나 대부분의 인프라 팀은 복잡한 스크럼 보드 관리에 따른 관리 오버헤드를 원하지 않으므로 간단한 도구를 사용하는 것이 좋습니다. 또한 보드가 있으면 팀이 수행하는 작업에 대한 보고서를 생성할 수 있고 범위를 제어할 수 있는 메커니즘도 얻을 수 있습니다.

• 그린필드 SAP 프로젝트에서는 범위를 잠근 후 많은 SAP 또는 경계 애플리케이션이 추가되는 경우가 드물지 않습니다. 프로젝트 범위를 제어하고, 우선순위를 지정하고, 가시성을 제공하는 적절한 메커니즘이 없다면 프로젝트의 순조로운 진행을 위해 추가 리소스를 요청하거나 작업의 우선순위를 재지정하기 어려울 것입니다.

통합 빌드 사양 시트 사용

모든 환경과 풍경에 맞는 단일 빌드 사양 스프레드시트를 사용합니다. 이렇게 하면 쉽게 찾고 검색할 수 있는 단일 문서가 만들어집니다. 인시던트로부터 쉽게 복구할 수 있도록 버전 관리를 활성화하는 것이 좋습니다. SAP Basis 팀과 협력하여 형식을 마련합니다. Basis 팀은 SAP 시스템 관련 세부 정보를 추적하고 단일 사양을 통해 사내 클라우드 팀이 프로젝트 완료 후 신속하게 소유권을 확보하고 모든 메타데이터를 한 곳에서 확인할 수 있습니다.

다음은 하나의 샘플 서버 요구 사항으로 주요 서버 빌드 메타데이터를 캡처하는 데 사용되는 템플릿의 예입니다.

AWS 서비스 할당량 파악

Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 대해 프로비저닝할 수 있는 가상 CPU(vCPU) 수에 대한 할당량이 있습니다. EC2 인스턴스를 배포할 때는 EC2 인스턴스 유형에 따라 일정한 수의 vCPU가 필요합니다. 모든 AWS 계정에는 프로비저닝할 수 있는 vCPUs 수에 대한 소프트 제한이 있습니다. EC2 인스턴스를 배포하면 소프트 제한이 자동으로 vCPU 약 100~150개 증가합니다. 그러나 여러 EC2 인스턴스(예: 20개)를 동시에 배포하려고 하면 소프트 제한을 초과할 수 있습니다. 이러한 제한이 발생할 수 있다고 생각되면 EC2 인스턴스를 배포하기 전에 할당량 증가 요청을 제출하세요. 이렇게 하면 배포 중 서비스 할당량 한도에 도달하는 것을 방지할 수 있습니다.

보안을 위한 키 교체 전략 개발

AWS Key Management Service (AWS KMS)를 사용하면 고객이 암호화 키를 쉽게 생성 및 관리하고 다양한 AWS 서비스와 다양한 애플리케이션에서 사용을 제어할 수 있습니다. SAP 구현의 경우 AWS KMS 키는 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장되고 SAP 바이너리 및 SAP HANA 파일 시스템에 사용되는 저장 데이터를 암호화하는 데 사용됩니다. KMS 키는 Amazon Simple Storage Service(Amazon S3) 버킷에 저장되어 소프트웨어 미디어 및 백업을 보관하는 데이터와 /usr/sap/trans 및 용 Amazon Elastic File System(Amazon EFS) 파일 시스템에도 사용됩니다/sapmnt.를 AWS KMS 사용하면 AWS 관리형 키 또는 고객 관리형 키를 유연하게 사용할 수 있습니다. 빌드 단계 초기에 보안 키 관리 전략과 결정을 문서화하고 공유하는 것이 좋습니다. 고객 관리형 키에서 AWS 관리형 키로 전환하는 등 프로젝트 중간에 보안 정책이 변경되면 SAP 환경을 완전히 다시 빌드해야 할 수 있으며, 이는 프로젝트 타임라인에 영향을 미칠 수 있습니다.

키 사용 및 교체에 대해 모든 보안 이해관계자의 동의를 얻습니다. 클라우드 또는 온프레미스 환경에 대한 기존 키 교체 정책을 고려하고 AWS에서 사용할 수 있도록 이러한 정책을 수정합니다. 주요 관리 전략에 대한 합의를 도출하는 데 어려움이 있는 경우 의사결정권자가 보안 기준 및 수준 설정 고려 사항을 이해할 수 있도록 교육을 실시합니다. 환경을 구축하기 전에 주요 교체 결정을 내리는 것이 중요합니다. 예를 들어 고객 관리형 키에서 AWS 관리형 키로 변경하려는 경우 Amazon EBS에 문제가 발생하여 암호화 키를 온라인으로 변경할 수 없습니다. EBS 볼륨을 새 키로 다시 빌드해야 합니다. 이를 위해서는 SAP 인스턴스를 다시 빌드해야 하는데, 이는 이상적인 시나리오가 아닙니다.

마찬가지로 프로젝트가 Vormetric과 같은 외부 키 관리 솔루션을 사용하고 키 구성 요소를 로 가져오는 경우 보안 의사 결정자가 외부 KMS 키와 AWS KMS 키 간의 키 교체 차이(자동 교체)를 인식해야 AWS KMS합니다. 보안 정책에 따라 외부 KMS 키를 사용하고 교체하면 키 구성 요소뿐만 아니라 키의 Amazon 리소스 이름(ARN)도 변경되므로 EBS 볼륨을 다시 생성해야 하고 전체 SAP 시스템은 소규모 마이그레이션을 거쳐야 합니다. 반면 고객 관리형 키 또는의 AWS 관리형 키에 대해 자동 교체 AWS KMS를 활성화하면 키 구성 요소가 변경되지만 키 ARN은 동일하게 유지되므로 EBS 볼륨은 영향을 받지 않습니다. 키 교체에 대한 자세한 내용은 AWS KMS 설명서의 키 교체 AWS KMS를 참조하세요.

또 다른 보안 접근 방식은 표준 대시보드를 통해 사용할 수 있는 데이터베이스 및 운영 체제 암호 교체 AWS Secrets Manager 에를 사용하는 것입니다. 또한 악의적인 활동으로부터 환경을 보호하기 위해 재해 복구 환경의 AWS Identity and Access Management (IAM) 역할을 프로덕션 환경과 격리해야 합니다.

사용하지 않는 서버 폐기

유용성이 소진된 후 즉시 PoC(개념 증명) 서버를 폐기하는 것이 좋습니다. 사용하지 않는 서버를 실행하면 비용이 많이 들 수 있습니다. 그린필드 SAP 구현을 위해 빌드하는 모든 서버를 추적하고 빌드 단계에서 활발히 사용하지 않는 서버를 중지하고 폐기하는 것이 중요합니다. 서버를 폐기하기 전에 EC2 인스턴스의 Amazon Machine(AMI) 백업을 만들 수 있습니다. 그런 다음 나중에 똑같은 서버를 가동해야 하는 경우 백업을 복원할 수 있습니다.

구현 프로젝트가 끝날 때까지 서버 폐기를 미룰 필요가 없습니다. 프로젝트 수명 주기 내내 그리고 구현을 완료한 후 유지 관리 또는 운영 단계에서 사용하지 않는 서버의 사용량을 모니터링하고 서버를 중지하고 결국 폐기해야 합니다. 요금이 빠르게 누적되므로 SAP Basis 팀원이 이러한 서버를 폐기하도록 교육하려면 처음에 프로세스를 설정해야 합니다.