AWS 애플리케이션 설계 및 마이그레이션 전략

애플리케이션의 미래 상태를 설계하고 문서화하는 것은 마이그레이션 성공의 핵심 요소입니다. 아무리 단순하든 복잡하든 모든 유형의 마이그레이션 전략에 대한 설계를 만드는 것이 좋습니다. 설계를 생성하면 아키텍처가 변경될 것으로 예상되지 않는 경우에도 잠재적인 차단, 종속성 및 애플리케이션을 최적화할 기회가 표시됩니다.

또한 마이그레이션 전략 렌즈를 AWS 사용하여에서 애플리케이션의 미래 상태에 접근하는 것이 좋습니다. 이 단계에서는이 마이그레이션의 AWS 결과로 애플리케이션이 어떻게 보일지 정의해야 합니다. 결과 설계는 마이그레이션 후 추가 진화를 위한 기반 역할을 합니다.

다음 목록에는 설계 프로세스를 지원하는 리소스가 포함되어 있습니다.

• AWS 아키텍처 센터는 AWS Well-Architected 프레임워크와 같은 도구와 지침을 결합합니다. 또한 애플리케이션에 사용할 수 있는 참조 아키텍처를 제공합니다.

• Amazon Builders' Library에는 Amazon이 소프트웨어를 빌드하고 운영하는 방법에 대한 여러 리소스가 포함되어 있습니다.

• AWS Solutions Library는 수십 가지 기술 및 비즈니스 문제에 AWS대해에서 심사한 클라우드 기반 솔루션 모음을 제공합니다. 여기에는 대규모 참조 아키텍처 모음이 포함됩니다.

• AWS 권장 가이드는 설계 프로세스 및 마이그레이션 모범 사례를 지원하는 전략, 가이드 및 패턴을 제공합니다.

• AWS Documentation 에는 사용 설명서 및 API 참조를 포함한 AWS 서비스에 대한 정보가 포함되어 있습니다.

• 시작하기 리소스 센터는 빌드를 시작할 수 있도록 몇 가지 실습 자습서와 기초를 배울 수 있는 심층 분석을 제공합니다 AWS.

클라우드 여정의 현재 위치에 따라 AWS 근거가 이미 존재할 수 있습니다. 이러한 AWS 기반에는 다음이 포함됩니다.

• AWS 리전 가 식별되었습니다.

• 계정이 생성되었거나 온디맨드로 가져올 수 있습니다.

• 일반 네트워킹이 구현되었습니다.

• 기본 AWS 서비스가 계정 내에 배포되었습니다.

반대로 프로세스 초기에는 AWS 기초가 아직 설정되지 않았을 수 있습니다. 설정된 기반이 없으면 애플리케이션 설계 범위가 제한되거나 이를 정의하기 위한 추가 작업이 필요할 수 있습니다. 이 경우 애플리케이션 설계 작업과 함께 랜딩 존의 기본 설계를 정의하고 구현하는 것이 좋습니다. 애플리케이션 설계는 AWS 계정 구조, 네트워킹, Virtual Private Cloud(VPCs), Classless Inter-Domain Routing(CIDR) 범위, 공유 서비스, 보안 및 클라우드 운영과 같은 요구 사항을 식별하는 데 도움이 됩니다.

AWS Control Tower는 랜딩 존이라고 하는 안전한 다중 계정 AWS 환경을 설정하고 관리하는 가장 쉬운 방법을 제공합니다.는를 사용하여 랜딩 존을 AWS Control Tower 생성합니다. AWS Organizations랜딩 존은 클라우드로 이동할 때 수천 명의 고객과 협력하는 AWS 모범 사례 기반 경험을 지속적으로 계정 관리 및 거버넌스하고 구현합니다.

애플리케이션 미래 상태

먼저이 애플리케이션의 초기 마이그레이션 전략을 수립합니다. 이 시점에서 전략은 미래 상태 설계의 일부로 변경될 수 있으므로 초기 전략으로 간주되어 잠재적 제한을 발견할 수 있습니다. 초기 가정을 검증하려면 6Rs 의사 결정 트리를 참조하세요. 또한 잠재적 마이그레이션 단계를 문서화합니다. 예를 들어이 애플리케이션은 단일 이벤트로 마이그레이션됩니까(모든 구성 요소가 동시에 마이그레이션됨)? 아니면 단계별 마이그레이션입니까(일부 구성 요소는 나중에 마이그레이션됨)?

특정 애플리케이션의 마이그레이션 전략은 고유하지 않을 수 있습니다. 이는 여러 R 유형을 사용하여 애플리케이션 구성 요소를 마이그레이션할 수 있기 때문입니다. 예를 들어 초기 접근 방식은 변경 없이 애플리케이션을 들어 올리고 이동하는 것일 수 있습니다. 그러나 애플리케이션의 구성 요소는 다양한 처리가 필요할 수 있는 다양한 인프라 자산에 상주할 수 있습니다. 예를 들어 애플리케이션은 각각 별도의 서버에서 실행되는 세 가지 구성 요소로 구성되며, 서버 중 하나는 클라우드에서 지원되지 않는 레거시 운영 체제를 실행합니다. 이 구성 요소에는 리플랫포밍 접근 방식이 필요한 반면, 지원되는 서버 버전에서 실행되는 다른 두 구성 요소는 리호스팅할 수 있습니다. 마이그레이션 중인 각 애플리케이션 구성 요소 및 관련 인프라에 마이그레이션 전략을 할당하는 것이 중요합니다.

다음으로 컨텍스트와 문제를 문서화하고 현재 상태를 정의하는 기존 아티팩트를 연결합니다.

• 이 애플리케이션이 마이그레이션되는 이유는 무엇입니까?

• 제안된 변경 사항은 무엇입니까?

• 어떤 이점이 있나요?

• 주요 위험이나 차단 요인이 있나요?

• 현재 단점은 무엇입니까?

• 범위 내 및 범위 밖이란 무엇입니까?

반복성

설계 작업 전반에 걸쳐이 애플리케이션에 대한이 솔루션과 아키텍처를 다른 애플리케이션에 재사용할 수 있는 방법을 고려합니다. 이 솔루션을 일반화할 수 있습니까?

요구 사항

보안을 포함하여이 애플리케이션의 기능 및 비기능 요구 사항을 문서화합니다. 여기에는 선택한 마이그레이션 전략에 따라 현재 및 미래 상태 요구 사항이 포함됩니다. 자세한 애플리케이션 평가 중에 수집된 정보를 사용하여이 프로세스를 안내합니다.

To-be 아키텍처

이 애플리케이션의 향후 아키텍처를 설명합니다. 소스 환경(온프레미스) 및 대상 AWS 환경(예: 대상, 계정 AWS 리전, VPCs 및 가용 영역)의 구성 요소가 포함된 재사용 가능한 다이어그램 템플릿을 생성하는 것이 좋습니다.

마이그레이션 중인 구성 요소와 새 구성 요소의 테이블을 생성합니다. 이 애플리케이션과 상호 작용하는 다른 애플리케이션 및 서비스(온프레미스 또는 클라우드)를 포함합니다.

다음 표에는 예제 구성 요소가 나열되어 있습니다. 참조 아키텍처 또는 검증된 구성을 나타내지 않습니다.

이름	설명	세부 정보
Application	외부 서비스(인바운드 연결)	서비스는 노출된 API의 데이터를 사용합니다.
DNS	이름 확인(내부)	기준 계정 설정의 일부로 배포된 Amazon Route 53
Application Load Balancer	백엔드 서비스 간에 트래픽을 분산합니다.	온프레미스 로드 밸런서를 대체합니다. 풀 A를 마이그레이션합니다.
애플리케이션 보안	DdoS 보호	를 사용하여 구현됨 AWS Shield
보안 그룹	가상 방화벽	포트 443(인바운드)의 애플리케이션 인스턴스에 대한 액세스를 제한합니다.
Server A	프런트 엔드	Amazon Elastic Compute Cloud(Amazon EC2)를 사용하여 리호스팅합니다.
Server B	프런트 엔드	Amazon EC2를 사용하여 리호스팅합니다.
서버 C	애플리케이션 로직	Amazon EC2를 사용하여 리호스팅합니다.
서버 D	애플리케이션 로직	Amazon EC2를 사용하여 리호스팅합니다.
Amazon Relational Database Service(RDS) – Amazon Aurora	데이터베이스	서버 E 및 F를 대체합니다.
모니터링 및 알림	변경 제어	Amazon CloudWatch
감사 로깅	변경 제어	AWS CloudTrail
패치 및 원격 액세스	유지 관리	AWS Systems Manager
리소스 액세스	보안 액세스 제어	AWS Identity and Access Management (IAM)
인증	사용자 액세스	Amazon Cognito
인증서	SSL/TLS	AWS Certificate Manager
API 1	외부 API	Amazon API Gateway
객체 스토리지	이미지 호스팅	Amazon Simple Storage Service(S3)
보안 인증 정보	자격 증명 관리 및 호스팅	AWS Secrets Manager
AWS Lambda 함수	데이터베이스 자격 증명 및 API 키 검색	AWS Lambda
인터넷 게이트웨이	아웃바운드 인터넷 액세스	VPC에 대한 인터넷 게이트웨이
프라이빗 서브넷 1	백엔드 및 DB	가용 영역 1 – VPC 1
프라이빗 서브넷 2	백엔드 및 DB	가용 영역 2 – VPC 1
퍼블릭 서브넷 1	프런트 엔드	가용 영역 1 – VPC 1
퍼블릭 서브넷 2	프런트 엔드	가용 영역 2 – VPC 1
백업 서비스	데이터베이스 및 EC2 인스턴스 백업	AWS Backup
DR	Amazon EC2 복원력	AWS Elastic Disaster Recovery

구성 요소가 식별되면 선호하는 도구를 사용하여 다이어그램에 구성 요소를 표시합니다. 애플리케이션 소유자, 엔터프라이즈 아키텍트, 플랫폼 및 마이그레이션 팀을 포함한 주요 애플리케이션 이해관계자와 초기 설계를 공유합니다. 다음과 같은 질문을 하는 것이 좋습니다.

• 팀이 일반적으로 설계에 동의하나요?

• 운영 팀이 지원할 수 있나요?

• 설계를 발전시킬 수 있나요?

• 다른 옵션이 있나요?

• 설계가 아키텍처 표준 및 보안 정책을 준수하나요?

• 누락된 구성 요소가 있습니까(예: 코드 리포지토리, CI/CD 도구, VPC 엔드포인트)?

아키텍처 결정

설계 프로세스의 일부로 전체 아키텍처 또는 특정 부분에 대한 더 많은 옵션을 찾을 수 있습니다. 이러한 옵션을 기본 설정 또는 선택한 옵션의 근거와 함께 문서화합니다. 이러한 결정은 아키텍처 결정으로 문서화할 수 있습니다.

새 독자가 한 옵션을 다른 옵션보다 사용하려는 결정의 옵션과 이유를 이해할 수 있도록 기본 옵션이 충분히 자세히 나열되고 설명되어야 합니다.

소프트웨어 수명 주기 환경

현재 환경에 대한 모든 변경 사항을 문서화합니다. 예를 들어 테스트 및 개발 환경은에서 다시 생성되며 마이그레이션 AWS 되지 않습니다.

태그 지정

각 인프라 구성 요소에 대한 필수 및 권장 태그 지정과이 설계의 태그 지정 값을 설명합니다.

마이그레이션 전략

설계의이 시점에서 마이그레이션 전략에 대한 초기 가정을 검증해야 합니다. 선택한 R 전략에 대한 합의가 있는지 확인합니다. 전체 애플리케이션 마이그레이션 전략과 개별 애플리케이션 구성 요소에 대한 전략을 문서화합니다. 앞서 언급한 것처럼 마이그레이션을 위해 애플리케이션 구성 요소가 다르려면 다른 R 유형이 필요할 수 있습니다.

또한 마이그레이션 전략을 주요 비즈니스 동인 및 결과에 맞게 조정합니다. 또한 다양한 마이그레이션 이벤트에서 구성 요소의 이동과 같은 마이그레이션에 대한 단계별 접근 방식을 설명합니다.

6R 결정에 대한 자세한 내용은 AWS Migration Hub 전략 권장 사항을 참조하세요.

마이그레이션 패턴 및 도구

애플리케이션 및 인프라 구성 요소에 대해 정의된 마이그레이션 전략을 사용하면 이제 특정 기술 패턴을 탐색할 수 있습니다. 예를 들어 리호스팅 전략은와 같은 마이그레이션 도구를 통해 구현할 수 있습니다AWS Application Migration Service. 상태 또는 데이터를 복제할 필요가 없는 경우 Amazon Machine Image(AMI) 및 애플리케이션 배포 파이프라인을 사용하여 애플리케이션을 재배포하여 동일한 결과를 얻을 수 있습니다.

마찬가지로 애플리케이션을 리플랫포밍하거나 리팩터링(리아키텍트)하려면 , AWS App2Container AWS Database Migration Service (AWS DMS), AWS Schema Conversion Tool (AWS SCT), 등의 도구를 사용할 수 있습니다AWS DataSync. 컨테이너화의 경우 Amazon Elastic Container Service(Amazon ECS), Amazon Elastic Kubernetes Service(Amazon EKS) 또는를 사용할 수 있습니다AWS Fargate. 재구매 시 특정 제품에 대한 AMI 또는의 서비스형 소프트웨어(SaaS) 솔루션을 사용할 수 있습니다AWS Marketplace.

목표 달성에 사용할 수 있는 다양한 패턴과 옵션을 평가합니다. 장단점과 마이그레이션 운영 준비 상태를 고려합니다. 분석에 도움이 되도록 다음 질문을 사용합니다.

• 마이그레이션 팀이 이러한 패턴을 지원할 수 있나요?

• 비용과 혜택의 균형은 무엇입니까?

• 이 애플리케이션, 서비스 또는 구성 요소를 관리형 서비스로 이동할 수 있습니까?

• 이 패턴을 구현하기 위한 노력은 무엇입니까?

• 특정 패턴의 사용을 금지하는 규정 또는 규정 준수 정책이 있나요?

• 이 패턴을 재사용할 수 있나요? 재사용 가능한 패턴이 선호됩니다. 그러나 패턴은 한 번만 사용되는 경우도 있습니다. 재사용 가능한 대체 패턴과 일회용 패턴의 작업 간의 균형을 고려하세요.

AWS 권장 가이드에는 다양한 마이그레이션 패턴과 기법이 포함되어 있습니다.

서비스 관리 및 운영

마이그레이션을 위한 애플리케이션 설계를 생성할 때는 운영 준비 상태를 AWS고려하세요. 애플리케이션 및 인프라 팀과 준비 요구 사항을 평가할 때는 다음 질문을 고려하세요.

• 운영할 준비가 되었나요?

• 인시던트 대응 절차가 정의되어 있습니까?

• 예상되는 서비스 수준 계약(SLA)은 무엇입니까?

• 업무 분리가 필요합니까?

• 서로 다른 팀이 지원 작업을 조정할 준비가 되었습니까?

• 누가 무엇에 대한 책임이 있습니까?

전환 고려 사항

마이그레이션 전략과 패턴을 고려할 때 애플리케이션이 마이그레이션되는 시점에 알아야 할 중요 사항은 무엇입니까? 전환 계획은 설계 후 활동입니다. 그러나 예상할 수 있는 활동 및 요구 사항에 대한 고려 사항을 문서화합니다. 예를 들어 해당하는 경우 개념 증명을 수행하기 위한 요구 사항을 문서화하고 테스트, 감사 또는 검증 요구 사항을 간략하게 설명합니다.

위험, 가정, 문제 및 종속성

아직 해결되지 않은 미해결 위험, 가정 및 잠재적 문제를 문서화합니다. 이러한 항목에 명확한 소유권을 할당하고 진행 상황을 추적하여 전체 설계 및 전략 구현을 승인할 수 있습니다. 또한이 설계를 구현하기 위한 키 종속성을 문서화합니다.

실행 비용 추정

대상 AWS 아키텍처의 비용을 추정하려면 AWS 요금 계산기를 사용합니다. 설계에 정의된 대로 인프라 구성 요소를 추가하고 예상 실행 비용을 구합니다. 애플리케이션 구성 요소에 필요하고 사용할 AWS 서비스에 아직 포함되지 않은 소프트웨어 라이선스의 팩터입니다.