기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 우선 순위가 지정된 애플리케이션 평가 이전 단계의 주요 결과 중 하나인 [포트폴리오 검색 및 초기 계획](portfolio-discovery-initial-planning.md)은 세부 평가를 위해 [애플리케이션 하위 집합의 우선순위를](prioritization-and-migration-strategy.md#prioritizing-applications) 지정하는 것이었습니다. 이 섹션에서는 애플리케이션에 대한 자세한 평가를 살펴봅니다. 초기에 몇 가지 애플리케이션의 세부 정보를 살펴보면 가속화가 촉진됩니다. 평가 및 미래 아키텍처 설계 프로세스는 잠재적 차단기를 표시하고 더 큰 규모의 마이그레이션을 주도하는 중요한 작업을 명확히 합니다. 이러한 작업에는 랜딩 존과 같은 AWS 기반을 설정 AWS하거나 기존 랜딩 존을 확장 및 검증하기 위한 요구 사항 수집이 포함됩니다. 이 평가는 마이그레이션 단계와 전략을 고려해야 할 때이기도 합니다. 이 단계의 주요 결과는 다음과 같습니다. + 우선 순위가 지정된 애플리케이션의 검증된 목록 + 문서화된 현재 상태 아키텍처 + 마이그레이션 후보를 위한 문서화된 초기 대상 아키텍처 및 마이그레이션 전략 + 식별된 마이그레이션 패턴 및 도구 + 문서화된 플랫폼 요구 사항(보안, AWS 인프라 및 운영) + 마이그레이션 계획을 위한 문서화된 전환 고려 사항 + 예상 AWS 실행률 # 세부 평가 데이터 요구 사항 이해 다음 표에서는 마이그레이션의 애플리케이션 및 관련 인프라에 대한 전체 포트폴리오 보기를 얻는 데 필요한 정보를 설명합니다. 테이블은 다음 약어를 사용합니다. + R, 필수 + O, 선택 사항의 경우 + 해당 없음, 해당 없음 **애플리케이션** | **속성 이름** | **설명** | **검색, 설계 및 마이그레이션 전략** | **예상 실행률** | **권장 충실도 수준(최소)** | | --- |--- |--- |--- |--- | | 고유한 식별자 | 애플리케이션 ID를 예로 들 수 있습니다. 일반적으로 기존 CMDBs 또는 기타 내부 인벤토리 및 제어 시스템에서 사용할 수 있습니다. 조직에 고유 ID가 정의되지 않은 경우 고유 IDs를 생성하는 것이 좋습니다. | R | O | 높음 | | 애플리케이션 이름 | 이 애플리케이션이 조직에 알려진 이름입니다. 해당하는 경우 상용 off-the-shelf(COTS) 공급업체 및 제품 이름을 포함합니다. | R | R | 높음 | | COTS입니까? | 예 또는 아니요. 상용 애플리케이션인지 아니면 내부 개발인지 여부 | R | R | 높음 | | COTS 제품 및 버전 | 상용 소프트웨어 제품 이름 및 버전 | R | R | 높음 | | 설명 | 기본 애플리케이션 함수 및 컨텍스트 | R | O | 높음 | | 중요도 | 예: 전략적 또는 수익 창출 애플리케이션 또는 중요한 함수 지원 | R | O | 높음 | | Type | 예: 데이터베이스, 고객 관계 관리(CRM), 웹 애플리케이션, 멀티미디어, IT 공유 서비스 | R | O | 높음 | | 환경 | 예: 프로덕션, 사전 프로덕션, 개발, 테스트, 샌드박스 | R | R | 높음 | | 규정 준수 및 규제 | 워크로드에 적용되는 프레임워크(예: HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) 및 규제 요구 사항 | R | O | 높음 | | 종속성 | 내부 및 외부 애플리케이션 또는 서비스에 대한 업스트림 및 다운스트림 종속성 | R | 해당 사항 없음 | 높음 | | 인프라 매핑 | 애플리케이션을 구성하는 물리적 및/또는 가상 자산에 매핑 | R | R | 높음 | | 라이선스 | 상품 소프트웨어 라이선스 유형(예: Microsoft SQL Server Enterprise) | R | R | 높음 | | 비용 | 소프트웨어 라이선스, 소프트웨어 운영 및 유지 관리 비용 | 해당 사항 없음 | R | 중간-높음 | | 사업부 | 예: 마케팅, 재무, 영업 | R | O | 높음 | | 소유자 세부 정보 | 애플리케이션 소유자의 연락처 정보 | R | O | 높음 | | 아키텍처 유형 | 예: 웹 애플리케이션, 2티어, 3티어, 마이크로서비스, 서비스 지향 아키텍처(SOA) | R | R | 높음 | | Recovery Point Objective(RPO), Recovery Time Objective(RTO) 및 /service-level Agreement(SLA) | 현재 서비스 - 관리 속성 | R | R | 높음 | | 수익 창출 애플리케이션 또는 비즈니스 전략 애플리케이션? | 예, 애플리케이션이 회사 수익에 직간접적으로 영향을 미치거나 비즈니스에서 전략적으로 간주되는 경우 가능합니다. | R | O | 중간-높음 | | 사용자 수(동시) | 예: 내부 또는 외부 사용자 또는 내부 및/또는 외부 사용자/고객 | R | R | 중간-높음 | | 사용자 위치 | 사용자 세션의 오리진 | R | R | 중간-높음 | | 위험 및 문제 | 알려진 위험 및 문제 | R | O | 중간-높음 | | 마이그레이션 고려 사항 | 마이그레이션과 관련이 있을 수 있는 추가 정보 | R | R | 중간-높음 | | 마이그레이션 전략 | 예를 들어 마이그레이션을 위한 AWS 6R 중 하나 | R | R | 중간-높음 | | 데이터베이스 세부 정보 | 예: 파티셔닝, 암호화, 복제, 확장, SSL(Secure Sockets Layer) 지원 | R | R | 높음 | | 지원 팀 | 예: 애플리케이션 운영 팀 이름 | R | O | 중간-높음 | | 모니터링 솔루션 | 이 애플리케이션을 모니터링하는 데 사용되는 제품 | R | O | 중간-높음 | | 백업 요구 사항 | 의 필수 백업 일정 AWS | R | R | 중간-높음 | | DR 정보 | 예:이 애플리케이션의 재해 복구 구성 요소 | R | R | 중간-높음 | | 대상 AWS 요구 사항 | 예: 구성 요소, 계정 배치, 네트워킹, 보안 | R | R | 높음 | **인프라** | | | | | | | --- |--- |--- |--- |--- | | **속성 이름** | **설명** | **검색, 설계 및 마이그레이션 전략** | **예상 실행률** | **권장 충실도 수준(최소)** | | 고유한 식별자 | 서버 ID를 예로 들 수 있습니다. 일반적으로 기존 CMDBs 또는 기타 내부 인벤토리 및 제어 시스템에서 사용할 수 있습니다. 조직에 고유 ID가 정의되지 않은 경우 고유 IDs를 생성하는 것이 좋습니다. | R | O | 높음 | | 네트워크 이름 | 네트워크의 자산 이름(예: 호스트 이름) | R | O | 높음 | | DNS 이름(정규화된 도메인 이름 또는 FQDN) | DNS 이름 | O | O | 중간-높음 | | IP 주소 및 넷마스크 | 내부 및/또는 퍼블릭 IP 주소 | R | R | 높음 | | 애셋 유형 | 예: 물리적 또는 가상 서버, 하이퍼바이저, 컨테이너, 디바이스, 데이터베이스 인스턴스 | R | R | 높음 | | 제품 이름 | 상용 공급업체 및 제품 이름(예: VMware ESXi, IBM Power Systems, Exadata) | R | R | 높음 | | 운영 체제 | 예: REHL 8, Windows Server 2019, AIX 6.1 | R | R | 높음 | | 구성 | 할당된 CPU, 코어 수, 코어당 스레드 수, 총 메모리, 스토리지, 네트워크 카드 | R | R | 높음 | | 사용률 | CPU, 메모리, 스토리지 피크 및 평균. 데이터베이스 인스턴스 처리량. | R | R | 높음 | | 라이선스 | 상품 라이선스 유형(예: RHEL Standard) | R | R | 높음 | | 공유 인프라입니까? | 인증 공급자, 모니터링 시스템, 백업 서비스 및 유사한 서비스와 같은 공유 서비스를 제공하는 인프라 서비스를 나타내는 예 또는 아니요 | R | O | 높음 | | 애플리케이션 매핑 | 이 인프라에서 실행되는 애플리케이션 또는 애플리케이션 구성 요소 | R | O | 높음 | | 통신 데이터 | 예: 프로세스 수준에서 서버 간 | R | 해당 사항 없음 | 중간-높음 | | 대상 AWS 요구 사항 | 예: 인스턴스 유형, 계정, 서브넷, 보안 그룹, 라우팅 | R | R | 높음 | | 마이그레이션 전략, 패턴 및 도구 | 예를 들어 마이그레이션을 위한 6R 중 하나, 특정 기술 패턴, 마이그레이션 도구 | R | O | 높음 | | 위험 및 문제 | 알려진 위험 및 문제 | R | O | 중간-높음 | # 세부 애플리케이션 평가 세부 애플리케이션 평가의 목표는 대상 애플리케이션 및 관련 인프라(컴퓨팅, 스토리지 및 네트워크)를 완전히 이해하는 것입니다. 위험을 방지하려면 충실도가 높은 데이터가 필요합니다. 예를 들어 조직은 애플리케이션을 완전히 이해하고 있다고 가정하는 것이 일반적입니다. 이는 자연스러운 현상이며 대부분의 경우 마찬가지입니다. 그러나 비즈니스에 대한 위험을 최소화하려면 프로그래밍 데이터를 최대한 확보하여 제도적 지식과 정적 문서를 검증하는 것이 중요합니다. 이렇게 하면 검색 프로세스의 부담을 덜 수 있습니다. 비즈니스별 정보, 전략적 로드맵 등과 같은 대체 소스에서 나오는 데이터 요소에 집중할 수 있습니다. 핵심은 마이그레이션 중 및 마이그레이션 후 마지막 순간의 변경을 방지하는 것입니다. 예를 들어 마이그레이션할 때는 서버를 지속적인 마이그레이션 웨이브에 포함해야 할 수 있는 식별되지 않은 종속성에 따른 변경을 피하는 것이 중요합니다. 마이그레이션 직후 트래픽을 허용하거나 추가 서비스를 배포하려면 관련 플랫폼 요구 사항에 따른 변경을 피하는 것이 중요합니다. 이러한 종류의 예상치 못한 변경은 보안 및 운영 문제의 위험을 높입니다. 자세한 애플리케이션 평가를 수행할 때 프로그래밍 방식의 검색 도구를 사용하여 트래픽 패턴과 종속성을 검증하는 것이 좋습니다. 평가를 시작할 때 애플리케이션 이해관계자를 식별해야 합니다. 일반적으로 다음과 같습니다. + 사업부 책임자 + 애플리케이션 소유자 + 아키텍트 + 운영 및 지원 + 클라우드 지원 팀 + 컴퓨팅, 스토리지 및 네트워크와 같은 특정 플랫폼 팀 자세한 검색을 위한 두 가지 접근 방식이 있습니다. 하향식 검색은 애플리케이션 또는 사용자로 시작하여 인프라로 이동합니다. 이는 애플리케이션 식별이 명확할 때 권장되는 접근 방식입니다. 반대로 상향식 검색은 인프라에서 시작하여 애플리케이션 또는 서비스와 해당 사용자에게 전달됩니다. 이 접근 방식은 인프라 팀이 마이그레이션 프로그램을 주도하고 application-to-infrastructure 매핑이 명확하지 않은 경우에 유용합니다. 일반적으로 둘 다 조합하여 사용할 가능성이 높습니다. 애플리케이션을 자세히 살펴보려면 기존 아키텍처 다이어그램을 사용하는 것이 좋습니다. 사용할 수 없는 경우 현재 지식을 기반으로 생성합니다. 간단한 리호스팅 또는 재배치 마이그레이션 전략의 경우에도이 작업의 중요성을 과소평가하지 마세요. 아키텍처 다이어그램을 작성하면 클라우드에서 사소한 변경으로 신속하게 해결할 수 있는 비효율성을 식별할 수 있습니다. 하향식 접근 방식을 수행하는지 상향식 접근 방식을 수행하는지에 따라 초기 다이어그램은 애플리케이션 구성 요소와 서버 및 로드 밸런서와 같은 서비스 또는 인프라 구성 요소를 표시합니다. 주요 구성 요소와 인터페이스를 식별한 후 검색 도구 및 애플리케이션 성능 모니터링 도구의 프로그래밍 방식으로 데이터를 사용하여 검증합니다. 도구는 종속성 분석을 지원하고 구성 요소 간의 통신 정보를 제공해야 합니다. 이 애플리케이션을 구성하는 각 구성 요소를 식별해야 합니다. 다음으로 내부 및 외부의 다른 애플리케이션 및 서비스에 대한 종속성을 문서화합니다. 종속성과 매핑을 검증하는 도구가 없는 경우 수동 접근 방식이 필요합니다. 예를 들어 인프라 구성 요소에 로그인하고 스크립트를 실행하여 열린 포트 및 설정된 연결과 같은 통신 정보를 수집할 수 있습니다. 마찬가지로 실행 중인 프로세스와 설치된 소프트웨어를 식별할 수 있습니다. 수동 검색에 필요한 노력을 과소평가하지 마세요. 프로그래밍 방식 도구는 더 큰 간격(일반적으로 작은 백분율)으로 발생하는 종속성을 제외하고 며칠 내에 대부분의 종속성을 캡처하고 보고할 수 있습니다. 수동 검색은 모든 데이터 포인트를 수집하고 병합하는 데 몇 주가 걸릴 수 있으며 오류와 누락 데이터가 발생하기 쉽습니다. 우선 순위가 지정된 각 애플리케이션 및 매핑된 인프라에 대한 [데이터 요구 사항](understanding-detailed-assessment-data-requirements.md) 섹션에 지정된 정보를 가져옵니다. 다음으로 다음 설문지를 사용하여 자세한 평가 프로세스를 안내합니다. 식별된 이해관계자와 만나 이러한 질문에 대한 답변을 논의합니다. ## 일반 + 이 애플리케이션의 중요도 수준은 어느 정도입니까? 수익이 발생하나요? 비즈니스 전략 또는 지원 비즈니스 애플리케이션입니까? 다른 시스템에서 공유하는 핵심 인프라 서비스입니까? + 이 애플리케이션에 대해 진행 중인 변환 프로젝트가 있습니까? + 내부 또는 외부 대상 애플리케이션입니까? ## 아키텍처 + 현재 아키텍처 유형(예: SOA, 마이크로서비스, 모놀리스)은 무엇입니까? 아키텍처에는 몇 개의 티어가 있습니까? 긴밀하게 결합되어 있습니까, 아니면 느슨하게 결합되어 있습니까? + 구성 요소는 무엇입니까(예: 컴퓨팅, 데이터베이스, 원격 스토리지, 로드 밸런서, 캐싱 서비스)? + APIs란 무엇입니까? API 이름, 작업, URLs, 포트 및 프로토콜을 포함하여 이에 대해 설명합니다. + 구성 요소와이 애플리케이션 또는 서비스 간에 허용되는 최대 지연 시간은 얼마입니까? ## 운영 + 이 애플리케이션은 어떤 위치에서 작동하나요? + 애플리케이션과 인프라는 누가 운영하나요? 내부 또는 AWS 파트너 팀에서 운영하나요? + 이 애플리케이션이 다운되면 어떻게 되나요? 누가 영향을 받나요? 어떤 영향이 있나요? + 사용자 또는 고객은 어디에 있나요? 애플리케이션에 어떻게 액세스하나요? 동시 사용자 수는 몇 명입니까? + 마지막 기술 새로 고침은 언제였나요? 향후 새로 고침이 예약되나요? 그렇다면 언제입니까? + 이 애플리케이션에 대해 알려진 위험과 문제는 무엇입니까? 중단, 중간 심각도 및 심각도가 높은 인시던트의 기록은 무엇입니까? + 사용 주기(영업 시간)는 어떻게 됩니까? 운영 시간대는 어떻게 됩니까? + 변경 고정 기간은 어떻게 됩니까? + 이 애플리케이션을 모니터링하는 데 사용되는 솔루션은 무엇입니까? ## 성능 + 수집된 성능 정보는 무엇을 표시하나요? 사용량이 급증하거나 일정하고 예측 가능한가요? 사용 가능한 성능 데이터의 기간, 간격 및 날짜는 어떻게 됩니까? + 이 애플리케이션의 일부이거나이 애플리케이션과 상호 작용하는 예약된 배치 작업이 있습니까? ## 소프트웨어 수명 주기 + 현재 변화율(주간, 월간, 분기별 또는 연간)은 얼마입니까? + 개발 수명 주기(예: 테스트, 개발, QA, UAT, 사전 프로덕션, 프로덕션)는 무엇입니까? + 애플리케이션 및 인프라의 배포 방법은 무엇입니까? + 배포 도구란 무엇입니까? + 이 애플리케이션 또는 인프라는 지속적 통합(CI)/지속적 전달(CD)을 사용하나요? 자동화 수준은 어느 정도입니까? 수동 작업이란 무엇입니까? + 애플리케이션 및 인프라의 라이선스 요구 사항은 무엇입니까? + 서비스 수준 계약(SLA)이란 무엇입니까? + 현재 테스트 메커니즘은 무엇입니까? 테스트 단계는 무엇입니까? ## 마이그레이션 + 마이그레이션 고려 사항은 무엇입니까? 이때이 애플리케이션을 마이그레이션할 때 고려해야 할 사항에 유의하세요. 보다 완전하고 정확한 평가를 위해 다른 이해관계자로부터이 질문에 대한 답변을 얻습니다. 그런 다음 이들의 지식과 의견을 대조합니다. ## 복원력 + 현재 백업 방법은 무엇입니까? 백업에 사용되는 제품은 무엇입니까? 백업 일정은 어떻게 됩니까? 백업 보존 정책이란 무엇입니까? + 현재 Recovery Point Objective(RPO) 및 Recovery Time Objective(RTO)는 무엇입니까? + 이 애플리케이션에 재해 복구(DR) 계획이 있습니까? 그렇다면 DR 솔루션은 무엇입니까? + 마지막 DR 테스트는 언제였나요? ## 보안 및 규정 준수 + 이 애플리케이션에 적용되는 규정 준수 및 규제 프레임워크는 무엇입니까? 마지막 및 다음 감사 날짜는 언제입니까? + 이 애플리케이션은 민감한 데이터를 호스팅하나요? 데이터 분류란 무엇입니까? + 데이터가 전송 중 또는 저장 시 암호화됩니까, 아니면 둘 다 암호화됩니까? 암호화 메커니즘이란 무엇입니까? + 이 애플리케이션은 SSL 인증서를 사용하나요? 발급 기관이란 무엇입니까? + 사용자, 구성 요소 및 기타 애플리케이션 및 서비스에 대한 인증 방법은 무엇입니까? ## 데이터베이스 수 + 이 애플리케이션에서는 어떤 데이터베이스를 사용하나요? + 데이터베이스에 대한 일반적인 동시 연결 수는 몇 개입니까? 최소 연결 수와 최대 연결 수는 얼마입니까? + 연결 방법은 무엇입니까(예: JDBC, ODBC)? + 연결 문자열이 문서화되어 있습니까? 그렇다면 어디에 있습니까? + 데이터베이스 스키마란 무엇입니까? + 데이터베이스가 사용자 지정 데이터 형식을 사용하나요? ## 종속성 + 구성 요소 간의 종속성은 무엇입니까? 해결할 수 없고 구성 요소를 함께 마이그레이션해야 하는 종속성을 기록해 둡니다. + 구성 요소가 여러 위치로 분할되나요? 이러한 위치(예: WAN, VPN) 간의 연결은 무엇입니까? + 다른 애플리케이션 또는 서비스에 대한이 애플리케이션의 종속성은 무엇입니까? + 운영 종속성이란 무엇입니까? 예를 들어, 패치 기간과 같은 유지 관리 및 릴리스 주기입니다. # AWS 애플리케이션 설계 및 마이그레이션 전략 애플리케이션의 미래 상태를 설계하고 문서화하는 것은 주요 마이그레이션 성공 요인입니다. 아무리 단순하든 복잡하든 모든 유형의 마이그레이션 전략에 대한 설계를 만드는 것이 좋습니다. 설계를 생성하면 아키텍처가 변경될 것으로 예상되지 않는 경우에도 애플리케이션을 최적화할 수 있는 잠재적 차단기, 종속성 및 기회가 표시됩니다. 또한 마이그레이션 전략 렌즈를 AWS 사용하여에서 애플리케이션의 미래 상태에 접근하는 것이 좋습니다. 이 단계에서는이 마이그레이션의 AWS 결과로 애플리케이션이 어떻게 보일지 정의해야 합니다. 결과 설계는 마이그레이션 후 추가 진화를 위한 기반 역할을 합니다. 다음 목록에는 설계 프로세스를 지원하는 리소스가 포함되어 있습니다. + [AWS 아키텍처 센터](https://aws.amazon.com/architecture/)는 AWS Well-Architected 프레임워크와 같은 도구와 지침을 결합합니다. 또한 애플리케이션에 사용할 수 있는 참조 아키텍처를 제공합니다. + [Amazon Builders' Library에는](https://aws.amazon.com/builders-library/) Amazon이 소프트웨어를 빌드하고 운영하는 방법에 대한 여러 리소스가 포함되어 있습니다. + [AWS Solutions Library](https://aws.amazon.com/solutions/)는 수십 가지 기술 및 비즈니스 문제에 AWS대해에서 심사한 클라우드 기반 솔루션 모음을 제공합니다. 여기에는 대규모 참조 아키텍처 모음이 포함됩니다. + [AWS 권장 가이드](https://aws.amazon.com/prescriptive-guidance/)는 설계 프로세스 및 마이그레이션 모범 사례를 지원하는 전략, 가이드 및 패턴을 제공합니다. + [AWS Documentation](https://docs.aws.amazon.com/) 에는 사용 설명서 및 API 참조를 포함한 AWS 서비스에 대한 정보가 포함되어 있습니다. + [시작하기 리소스 센터](https://aws.amazon.com/getting-started/)는 빌드를 시작할 수 있도록 몇 가지 실습 자습서와 기초를 배울 수 있는 심층 분석을 제공합니다 AWS. 클라우드 여정의 현재 위치에 따라 AWS 근거가 이미 존재할 수 있습니다. 이러한 AWS 기반에는 다음이 포함됩니다. + AWS 리전 가 식별되었습니다. + 계정이 생성되었거나 온디맨드로 가져올 수 있습니다. + 일반 네트워킹이 구현되었습니다. + 기본 AWS 서비스가 계정 내에 배포되었습니다. 반대로 프로세스 초기에는 AWS 기초가 아직 설정되지 않았을 수 있습니다. 설정된 기반이 없으면 애플리케이션 설계 범위가 제한되거나 이를 정의하기 위한 추가 작업이 필요할 수 있습니다. 이 경우 애플리케이션 설계 작업과 함께 랜딩 존의 기본 설계를 정의하고 구현하는 것이 좋습니다. 애플리케이션 설계는 AWS 계정 구조, 네트워킹, Virtual Private Cloud(VPCs), Classless Inter-Domain Routing(CIDR) 범위, 공유 서비스, 보안 및 클라우드 운영과 같은 요구 사항을 식별하는 데 도움이 됩니다. [AWS Control Tower](https://aws.amazon.com/controltower/)는 랜딩 존이라는 안전한 다중 계정 AWS 환경을 설정하고 관리하는 가장 쉬운 방법을 제공합니다.는를 사용하여 랜딩 존을 AWS Control Tower 생성합니다. AWS Organizations랜딩 존은 클라우드로 이동할 때 수천 명의 고객과 협력하는 AWS 모범 사례 기반 경험을 지속적으로 계정 관리 및 거버넌스하고 구현합니다. ## 애플리케이션 미래 상태 먼저이 애플리케이션의 초기 마이그레이션 전략을 수립합니다. 이 시점에서 전략은 미래 상태 설계의 일부로 변경될 수 있으므로 초기 전략으로 간주되어 잠재적 제한을 발견할 수 있습니다. 초기 가정을 검증하려면 [6Rs 의사 결정 트리를 참조하세요](prioritization-and-migration-strategy.md#migration-r-type). 또한 잠재적 마이그레이션 단계를 문서화합니다. 예를 들어이 애플리케이션은 단일 이벤트로 마이그레이션됩니까(모든 구성 요소가 동시에 마이그레이션됨)? 아니면 단계별 마이그레이션입니까(일부 구성 요소는 나중에 마이그레이션됨)? 특정 애플리케이션에 대한 마이그레이션 전략은 고유하지 않을 수 있습니다. 이는 여러 R 유형을 사용하여 애플리케이션 구성 요소를 마이그레이션할 수 있기 때문입니다. 예를 들어 초기 접근 방식은 변경 없이 애플리케이션을 리프트 앤 시프트하는 것일 수 있습니다. 그러나 애플리케이션의 구성 요소는 다양한 처리가 필요할 수 있는 다양한 인프라 자산에 있을 수 있습니다. 예를 들어 애플리케이션은 각각 별도의 서버에서 실행되는 세 가지 구성 요소로 구성되며, 서버 중 하나는 클라우드에서 지원되지 않는 레거시 운영 체제를 실행합니다. 이 구성 요소에는 리플랫포밍 접근 방식이 필요한 반면, 지원되는 서버 버전에서 실행되는 다른 두 구성 요소는 리호스팅할 수 있습니다. 마이그레이션 중인 각 애플리케이션 구성 요소 및 관련 인프라에 마이그레이션 전략을 할당하는 것이 중요합니다. 그런 다음 컨텍스트와 문제를 문서화하고 현재 상태를 정의하는 기존 아티팩트를 연결합니다. + 이 애플리케이션을 마이그레이션하는 이유는 무엇입니까? + 제안된 변경 사항은 무엇입니까? + 어떤 이점이 있나요? + 주요 위험이나 차단 요인이 있나요? + 현재 단점은 무엇인가요? + 범위 내 및 범위 밖이란 무엇입니까? ## 반복성 설계 작업 전반에 걸쳐이 애플리케이션에 대한이 솔루션과 아키텍처를 다른 애플리케이션에 재사용할 수 있는 방법을 고려합니다. 이 솔루션을 일반화할 수 있습니까? ## 요구 사항 보안을 포함하여이 애플리케이션의 기능 및 비기능 요구 사항을 문서화합니다. 여기에는 선택한 마이그레이션 전략에 따라 현재 및 미래 상태 요구 사항이 포함됩니다. 자세한 애플리케이션 평가 중에 수집된 정보를 사용하여이 프로세스를 안내합니다. ## To-be 아키텍처 이 애플리케이션의 향후 아키텍처를 설명합니다. 소스 환경(온프레미스) 및 대상 AWS 환경(예: 대상, 계정 AWS 리전, VPCs 및 가용 영역)의 구성 요소가 포함된 재사용 가능한 다이어그램 템플릿을 생성하는 것이 좋습니다. 마이그레이션 중인 구성 요소와 새 구성 요소 테이블을 생성합니다. 이 애플리케이션과 상호 작용하는 다른 애플리케이션 및 서비스(온프레미스 또는 클라우드)를 포함합니다. 다음 표에는 예제 구성 요소가 나열되어 있습니다. 참조 아키텍처 또는 검증된 구성을 나타내지 않습니다. | **이름** | **설명** | **세부 정보** | | --- |--- |--- | | 애플리케이션 | 외부 서비스(인바운드 연결) | 서비스는 노출된 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 | Database | 서버 E 및 F를 대체합니다. | | 모니터링 및 알림 | 변경 제어 | Amazon CloudWatch | | 감사 로깅 | 변경 제어 | AWS CloudTrail | | 패치 및 원격 액세스 | 정비 | AWS Systems Manager | | 리소스 액세스 | 보안 액세스 제어 | AWS Identity and Access Management (IAM) | | Authentication | 사용자 액세스 | Amazon Cognito | | 인증서 | SSL/TLS | AWS Certificate Manager | | API 1 | 외부 API | Amazon API Gateway | | 객체 스토리지 | 이미지 호스팅 | Amazon Simple Storage Service(Amazon 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 전략 권장](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/) 사항을 참조하세요. ## 마이그레이션 패턴 및 도구 애플리케이션 및 인프라 구성 요소에 대해 정의된 마이그레이션 전략을 사용하면 이제 특정 기술 패턴을 탐색할 수 있습니다. 예를 들어와 같은 마이그레이션 도구를 사용하여 리호스팅 전략을 구현할 수 있습니다[AWS Application Migration Service](https://aws.amazon.com/application-migration-service/). 상태 또는 데이터를 복제할 필요가 없는 경우 Amazon Machine Image(AMI)와 애플리케이션 배포 파이프라인을 사용하여 애플리케이션을 재배포하여 동일한 결과를 얻을 수 있습니다. 마찬가지로 애플리케이션을 리플랫포밍하거나 리팩터링(리아키텍트)하려면 , [AWS App2Container](https://aws.amazon.com/app2container/) [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/), [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/) (AWS SCT), 등의 도구를 사용할 수 있습니다[AWS DataSync](https://aws.amazon.com/datasync/). 컨테이너화의 경우 [Amazon Elastic Container Service(Amazon ECS),](https://aws.amazon.com/ecs/) [Amazon Elastic Kubernetes Service(Amazon EKS)](https://aws.amazon.com/eks/) 또는를 사용할 수 있습니다[AWS Fargate](https://aws.amazon.com/fargate/). 재구매 시 특정 제품에 대한 AMI 또는의 서비스형 소프트웨어(SaaS) 솔루션을 사용할 수 있습니다[AWS Marketplace](https://aws.amazon.com/marketplace/). 목표 달성에 사용할 수 있는 다양한 패턴과 옵션을 평가합니다. 장단점과 마이그레이션 운영 준비 상태를 고려합니다. 분석에 도움이 되도록 다음 질문을 사용합니다. + 마이그레이션 팀이 이러한 패턴을 지원할 수 있나요? + 비용과 혜택의 균형은 무엇입니까? + 이 애플리케이션, 서비스 또는 구성 요소를 관리형 서비스로 이동할 수 있습니까? + 이 패턴을 구현하기 위한 노력은 무엇입니까? + 특정 패턴의 사용을 금지하는 규정 또는 규정 준수 정책이 있습니까? + 이 패턴을 재사용할 수 있나요? 재사용 가능한 패턴이 선호됩니다. 그러나 패턴은 한 번만 사용되는 경우도 있습니다. 재사용 가능한 대체 패턴과 일회용 패턴의 작업 간의 균형을 고려하세요. [AWS 권장 가이드](https://aws.amazon.com/prescriptive-guidance/)에는 다양한 마이그레이션 패턴과 기법이 포함되어 있습니다. ## 서비스 관리 및 운영 마이그레이션을 위한 애플리케이션 설계를 생성할 때는 운영 준비 상태를 AWS고려하세요. 애플리케이션 및 인프라 팀과 준비 요구 사항을 평가할 때는 다음 질문을 고려하세요. + 운영할 준비가 되었나요? + 인시던트 대응 절차가 정의되어 있습니까? + 예상되는 서비스 수준 계약(SLA)은 무엇입니까? + 의무 분리가 필요합니까? + 여러 팀이 지원 작업을 조정할 준비가 되었습니까? + 무엇에 대한 책임은 누구에게 있습니까? ## 전환 고려 사항 마이그레이션 전략과 패턴을 고려할 때 애플리케이션이 마이그레이션되는 시점에 알아야 할 중요 사항은 무엇입니까? 전환 계획은 설계 후 활동입니다. 그러나 예상할 수 있는 활동 및 요구 사항에 대한 고려 사항을 문서화합니다. 예를 들어 해당하는 경우 개념 증명을 수행하기 위한 요구 사항을 문서화하고 테스트, 감사 또는 검증 요구 사항을 간략하게 설명합니다. ## 위험, 가정, 문제 및 종속성 아직 해결되지 않은 모든 미해결 위험, 가정 및 잠재적 문제를 문서화합니다. 이러한 항목에 명확한 소유권을 할당하고 진행 상황을 추적하여 전체 설계 및 전략의 구현을 승인할 수 있습니다. 또한이 설계를 구현하기 위한 키 종속성을 문서화합니다. ## 실행 비용 추정 대상 AWS 아키텍처의 비용을 추정하려면 [AWS 요금 계산기](https://calculator.aws/)를 사용합니다. 설계에 정의된 대로 인프라 구성 요소를 추가하고 예상 실행 비용을 구합니다. 애플리케이션 구성 요소에 필요하고 사용할 AWS 서비스에 아직 포함되지 않은 소프트웨어 라이선스의 팩터입니다.