CAF
AWS 개념과 AWS Management Console에 익숙해지셨으니 , 기술적인 관점에서 제안하고 정보에 입각한 결정을 내릴 수 있을 것입니다. McKinsey 연구에 따르면 , 2030년까지 Fortune 500대 기업에서 클라우드가 1조 달러 이상의 가치를 창출할 것으로 예상하고 있습니다
고객과 클라우드의 가치에 대해 , 효과적으로 소통하는 AWS Partner는 클라우드 여정에서 고객에게 신뢰할 만한 조언자가 될 수 있습니다. 많은 고객이 클라우드로의 전환을 원하고 있지만 , 잘 정의된 경로 없이 여정을 시작하면 마이그레이션이 교착 상태에 빠지거나 광범위한 지연이 발생할 수 있습니다.
고객에게는 제대로 수립된 계획이 필요하며. 일반적으로 클라우드 채택에 대한 대화는 조금씩 진행됩니다. 이때 클라우드 여정의 초기 단계에서 고객과 협업하여 완전한 클라우드 전략을 수립하도록 지원할 수 있는 기회가 있습니다.
AWS는 고객과 협업하여 고객이 현재의 비즈니스와 IT 환경에서 , 클라우드에 보다 최적화된 아키텍처로 발전할 수 있도록 안내하는 구조화된 프레임워크를 구축했습니다
이것이 바로 AWS Cloud Adoption Framework, AWS CAF입니다. AWS CAF에서는 관점이라고 하는 6가지 집중 영역별로 구성된 지침을 제공합니다
각 관점은 기존 기술과 프로세스에서 격차를 파악하는 작업 스트림을 만드는 데 사용되며, 이는 입력으로 기록됩니다. 이러한 관점은 기능적으로 관련된 이해 관계자가 소유하거나 관리하는 고유한 책임을 다룹니다. 파트너는 조직의 솔루션을 수립하는 데 중요한 역할을 할 수 있으며 고객의 클라우드 전환 여정에 대한 비전을 형성하는 데 도움을 줄 수도 있습니다
조직마다 AWS 클라우드로 향하는 경로는 다르지만 , 현재 비즈니스와 IT 인프라에 대한 포괄적인 평가에서 시작되는 경우가 많습니다 그리고 비즈니스 워크로드를 AWS 클라우드로 원활하게 전환하는 것으로 마무리됩니다. AWS CAF는 고객 조직의 미래 상태를 시각화하도록 지원합니다
이는 고객의 비즈니스가 클라우드 마이그레이션에 잘 대비할 수 있도록. 준비 상태의 격차를 파악하고 , 전략적으로 해결하는 데 도움이 될 수 있습니다
다음으로 AWS CAF를 실행하는 방법에 대해 알아보겠습니다
트랜스포메이션 단계라고 부르는 과정을 통해 이를 수행합니다 트랜스포메이션 단계는 조직의 클라우드 여정을 안내하는 반복적인 단계입니다 트랜스포메이션 단계와 주요 결과의 일부를 살펴보겠습니다 구상 단계에서는 조직에 지속적으로 측정 가능한 가치를 제공하는 클라우드 전략의 기반을 마련하도록 지원합니다
이는 비즈니스 목표와 결과를 기술 실현과 연결하고 주요 조치를 파악하며 클라우드 이니셔티브의 우선순위를 결정하는 데 도움을 줍니다.
구상 작업이 완료되면 조율이 시작됩니다.
해당 단계에서는 클라우드 채택이 고객 조직에 어떤 의미가 있는지 판단하는 데 도움이 되는 유용한 실행 계획을 생성합니다
이는 이해 관계자를 위한 주요 이점을 제시하고, 최상의 접근 방식을 수립하며, 클라우드 여정 전반에 걸쳐 조직의 변경 관리를 안내하는 명확한 설명을 제공합니다.
시작 단계에서는 이전 단계의 실행 계획을 사용한 작업 스트림이 주요 결과입니다.
여기에는 프로덕션 클라우드 배포를 위한 작업 스트림, 클라우드 프로젝트 완료, 이해 관계자의 우려 사항, 사전 해결, 비즈니스 가치 증대를 위한 클라우드 사용 시작이 포함되어 있습니다.
비즈니스 가치를 시작하고 실현한 후에는 조직과 협업하여, 조직의 비즈니스 계획에 따라 성과를 달성하기 위해 결과를 측정하고 반복할 수 있습니다
이 단계에서는 조직의 크기 조정을 지원합니다 조직의 클라우드 투자와 관련된 ., 비즈니스 이점을 실현하고 유지할 수 있도록 프로덕션 파일럿을 확대하는 것처럼 보일 수도 있습니다..AWS Partner의 예시를 통해 AWS CAF의 작동 방식을 자세히 살펴보겠습니다.
파트너는 AWS CAF 구상 워크숍을 진행할 수 있습니다.이 대화형 세션은 고객 조직의 Stakeholder 분들이 클라우드 준비 비전을 ,공동으로 개발하는 데 도움을 줄 수 있습니다. 여기에는 이해 관계자 파악, 성공 지표 설정, 비즈니스 성과 증진 방법 이해, 이니셔티브 우선순위 설정 등이 포함되며 , 이를 통해 포괄적이고, 통합된 비전 계획을 수립할 수 있습니다. 비전을 수립하고 나면 , 다음 단계는 AWS CAF 조율 워크숍입니다
이 워크숍에서 여러분은 , 파트너로서 파악된 이해 관계자와 협업하게 됩니다. 이전에 수립한 비전을 성공적으로 구현하는 데 필요한 문제, 장애물, 도전 과제를 찾아 정리합니다. 고객이 추세를 파악하고, 작업 항목을 고안하고, 소유권을 할당하고, 클라우드 준비 상태를 달성하기 위한 , 명확하고 실행 가능한 계획을 수립하도록 지원합니다.
격차가 해소되고 고객이 최적의 클라우드 준비 상태에 도달하면 , 워크로드를 파악하고 마이그레이션 전략을 결정하고, 마이그레이션을 계획을 수행할 수 있습니다. 본질적으로 AWS Partner의 역할은 중요합니다. 단순한 가이드가 아니라 클라우드 준비 및 마이그레이션을 향한 ,고객 여정에서 신뢰할 수 있는 조언자 역할을 수행하게 됩니다.
지금까지 Cloud Adoption Framework에 대해 알아보았습니다. 그렇다면 실제로 클라우드를 사용하려면 어떻게 해야 할까요? 다음 동영상에서는 일반적인 클라우드 마이그레이션 전략을 다뤄보겠습니다. 그럼 다음 동영상에서 뵙겠습니다.
마이그레이션 전략
앞서 AWS CAF라는 구조화된 프레임워크를 학습했습니다. 이 프레임워크는 고객이 현재 비즈니스 및 IT 환경에서, 보다 클라우드에 적합한 아키텍처로 발전할 수 있도록 안내합니다. AWS CAF는 조직에 있을 수 있는 기존 격차를 발견하고, 준비 단계에 도달할 수 있도록 지원합니다. 마이그레이션하는 워크로드를 결정하려면 , 마이그레이션 환경, 개별 워크로드, 각 구성 요소가 다른 구성 요소와 어떻게 관련되어 있는지 완전하게 이해해야 합니다. 일반적으로 고객의 IT 환경에서 기존 워크로드를 발견하는 것으로 프로젝트를 시작합니다.
고객의 IT 환경에서 수집된 데이터를 사용하면 마이그레이션 전략을 선택할 때 , 더 나은 결정을 내릴 수 있습니다. 고객의 워크로드를 발견하기 위해서는 여러 도구를 사용할수 있는데요, 정보에 입각한 마이그레이션 전략을 수립하기 위해서는, 비즈니스 목표, 이해 관계자,비지니스 영향을 이해하는 것도 중요합니다.
고객과 애플리케이션 비즈니스 소유자가 , 자신의 환경에 적합한 마이그레이션 전략을 세우기 위해서는 다음과 같은 질문을 통해 필요한 데이타를 수집할수 있습니다.
누가 애플리케이션을 소유하거나 지원하고 있는지, 해당 애플리케이션은 어떤 비지니스 단워를 지원하고 있는지, 그리고 비지니스에서 애플리케이션의 상대적인 중요도는 어느정돈인지 와 같은 질문을 통해 수집한 데이타를 , 조직의 비즈니스와 기술 동인에 맞게 조율한 다음, 실제 마이그레이션 전략을 선택해야 합니다. 고객은 AWS로 마이그레이션할 때 , 마이그레이션 중인 애플리케이션에 가장 적합한 전략을 선택합니다.
AWS는 리팩터링, 리플랫포밍, 재구매, 리호스팅, 재배치, 유지, 사용 중지를 포함하는 7가지 일반적인 접근 방식을 제공합니다.
각 애플리케이션은 고유하므로 기업에서는 개별 애플리케이션에 여러 가지 전략을 , 사용하는 경우가 많습니다.
예를 들어 , 비즈니스 요구 사항을 충족하기 위해 신속하게 마이그레이션하고 크기를 조정해야 하는 경우 , 고객에게 리호스팅 전략을 권장할 수 있습니다.
또는 고객이 , 현재 애플리케이션 설계로는 달성하기 어려운 기능이나 성능, 규모를 확장해야 하는 경우 리팩터링 전략을 권장할 수 있습니다.
이 7가지 전략에 대해 좀 더 자세히 살펴보겠습니다 설명이 끝나면 , 예시를 통해 이러한 전략을 어떻게 적용할 수 있는지 보여드리겠습니다.
우선 , 재배치 전략부터 시작하겠습니다.
재배치란 가동 중단 시간을 최소화하고 기존 운영이나 기술 스택을 변경하지 않으면서 , 애플리케이션 또는 워크로드를 클라우드로 옮기는 것을 의미합니다. 재배치전략은 어떤 경우에 사용할수 있을까요? 예를들어, 온프레미스 데이타센타에서 VMware를 기반으로 애플리케이션을 실행 중이고 , 데이터 센터 임대가 갱신되지 않고 곧 만료될 예정이라고 가정해 보겠습니다.
이 마이그레이션 시나리오의 일반적인 사용 사례는, 고객에게 가장 친숙한 인프라를 사용하여 AWS로 신속하게 재배치하는 것입니다. 재배치 전략은 이러한 유형의 시나리오에서 가장 빠르게 사용할 수 있는 방법입니다.
일반적으로 사용되는 두 번째 마이그레이션 전략으로는 리프트 앤 시프트라고 하는 리호스팅전략입니다. 이 접근 방식에서는 기존 운영 체제나 애플리케이션 스택을 변경하지 않고 애플리케이션 또는 워크로드를 AWS로 마이그레이션합니다. 고객은 리프트 앤 시프트 전략을 사용하여 신속하게 마이그레이션한 후 , 애플리케이션의 현대화에 집중할 수 있습니다. 애플리케이션이 클라우드에 있으면 클라우드에 최적화된 상태로 만들기가 훨씬 간편합니다.
세 번째 마이그레이션 전략은 리플랫포밍입니다. 이는 자동차 엔진을 더 높은 성능의 엔진으로 교체하거나 , 새로운 기능을 추가하는 것과 같습니다. 실제로 고객 애플리케이션의 데이터베이스 계층을 관리형 서비스로 현대화하는 것처럼 보일 수 있는데요, 일상적인 작업에 걸리는 시간은 줄이고 , 비즈니스 로직에 집중하는 시간은 늘릴 수 있습니다.
다음 마이그레이션 전략은 애플리케이션 재구매입니다 기존 애플리케이션을 다른 버전이나 , 제품으로 교체하는 것이죠. 이 접근 방식은 기존 온프레미스 애플리케이션보다 더 많은 비즈니스 가치를 제공하는 전략을 , 찾고 있는 경우에 적합합니다. 이러한 이점으로는 어디서나 액세스할 수 있는 기능, 인프라 유지 관리가 필요하지 않다는 점과, 종량제 가격 모델 등이 있습니다. 애플리케이션을 재구매하면 일반적으로 유지 관리, 인프라, 라이선스 관련 비용을 줄일 수 있습니다.
다섯 번째 마이그레이션 전략은 리팩터링입니다. 클라우드 네이티브 애플리케이션을 만들기 위해 마이그레이션하기 전에, 애플리케이션 아키텍처를 다시 설계하거나 애플리케이션을 다시 작성하는 작업을 말합니다.
전반적으로 모놀리스 애플리케이션을 모듈식 아키텍처로 분해하면 , 새로운 기능을 추가하고, 성능을 개선하고, 고객의 현재 리소스에 맞게 크기를 조정하는 데 도움이 됩니다.
여섯 번째 마이그레이션 전략은 사용 중지입니다. 온프레미스 애플리케이션을 디스커버리하면 ,실행 중이지만 더 이상 필요하지 않거나 , 사용하지 않는 애플리케이션이 얼마나 많은지 알게되시는데요, 이렇게 고객이 더 이상 필요하지 않다고 판단하여 사용을 중지하고자 하는 경우에 유용한 전략입니다.
마지막 마이그레이션 전략은 유지입니다. 고객은 당분간 애플리케이션을 유지하거나 , 나중에 다시 사용할 수 있습니다. 이 전략은 라이선스 또는 기타 이유로 인해 일부 애플리케이션을 즉시 마이그레이션할 수 없는 경우에 유용합니다. 고객이 최근에 시스템을 업그레이드했다면 ,다음 갱신 때까지 애플리케이션 마이그레이션을 연기할수도 있고 또는 시간과 노력을 투자해야 하는 메인프레임 애플리케이션과 데이타베이스 시스템이라면 유지 전략이 유용할수 있습니다.
다양한 상황과 요구 사항에 맞는 특정 마이그레이션 스타일이 있습니다. 다시 한번 강조하지만, 마이그레이션에 있어서 모든 경우에 적용되는 하나의 접근 방식은 없습니다.
다음은 디지털 운영의 성능과 확장성을 개선하기 위해 , AWS Partner와 협업한 예시 시나리오입니다.
이 사례에서는 사용 중지, 재구매, 재배치, 리호스팅, 리팩터링 등의 마이그레이션 전략을 혼합하여 사용했습니다.
· 이 시나리오에서 파트너는 애플리케이션 소유자와 회의를 주최하고 더 이상 필요하지 않거나 소유권이 명확하지 않은 애플리케이션을 파악했습니다 .이렇게 파악된 애플리케이션은 사용 중지되었습니다.
· 또한 파트너는 고객과 협력하여 애플리케이션 중 하나를 사스(SaaS)형 모델로 전환하여 운영 오버헤드를 줄였습니다 이를 위해 재구매 전략을 사용했습니다.
· 파트너가 수행한 또 다른 작업은 디지털 시스템의 크기를 보다 효율적으로 조정하기 위해 컨테이너화된 내부 애플리케이션을 Amazon ECS로 옮기는 것이었습니다 이를 위해 재배치 전략을 사용했습니다.
· 애플리케이션 소유자와의 대화를 통해 파트너는 고객이 이미 기존 공급업체 라이선스 및 지원에 상당한 투자를 하고 있다는 점을 발견했습니다 그들은 이러한 애플리케이션을 그대로 Amazon EC2 인스턴스로 옮기는 리호스팅 전략을 사용했습니다.
· 마지막으로 파트너는 , EC2의 크기 조정 기능을 사용하기 위해 , 다중 계층 애플리케이션을 모듈식 아키텍처로 다시 작성할 것을 제안했습니다. 리팩터링 전략이 이러한 애플리케이션을 운영하는 데 필요한 성능과 비용을 개선하는 데 도움이 되었습니다.
AWS Partner는 고객에게 비즈니스 전문 지식 , 인프라 및 애플리케이션 마이그레이션 전문 지식, 마이그레이션 도구, 교육, 지속적인 지원을 제공하여 , 고객의 클라우드 여정을 가속화할 수 있도록 돕습니다 마이그레이션 전략에 대한 자세한 내용은 이 과정 마지막 부분에 제공되는 리소스를 참조하시기 바랍니다.
마이그레이션 전략을 결정한 다음에는 애플리케이션이 AWS 모범 사례를 어떻게 준수하는지에 대해 고려해야 합니다.
다음 교육 주제에서 몇 가지 유용한 팁을 소개해 드리겠습니다. 그럼 다음 동영상에서 뵙겠습니다.
AWS Well-Architected Framework
이제 특정 고객 사용 사례나 애플리케이션을 기반으로 , 적절한 애플리케이션 마이그레이션 전략을 파악할 수 있게 되었는데요. 그렇다면 해당 워크로드를 마이그레이션한 후에는 고객이 AWS 아키텍처 모범 사례를 따르고 있는지 어떻게 확인할 수 있을까요?
이를 위해 AWS Well-Architected Framework이 준비되어 있습니다.
이러한 지식 체계는 다양한 비즈니스 분야 및 사용 사례에 걸쳐 수년간 쌓아온 AWS Solutions Architect의 경험을 집대성한 결과입니다.
프레임워크를 사용하여 고객은 , 지속 가능성 목표 달성을 지향하는 동시에 , 클라우드에서 , 신뢰할 수 있고 안전하며 성능이 뛰어나고 비용 효과적인 시스템을 설계하고 운영하기 위한 아키텍처 모범 사례를 학습할 수 있습니다.
AWS Well-Architected Framework는 AWS 모범 사례에 따라 , 아키텍처를 측정하고 개선이 필요한 영역을 파악하는, 방법을 제공합니다.
프레임워크 안내가 권장되는 경우에 , 해당하는 고객의 비즈니스 목표를 알려드리자면 먼저, 고객이 인프라 지출을 줄이고자 할 때입니다. 그리고 고객이 직원을 보다 전략적인 업무에 투입하고 싶어 할 때입니다. 마지막으로 고객 애플리케이션의 예기치 않은 가동 중단 시간을 줄이거나 새로운 제품의 출시 시간을 단축하려고 할 때입니다.
그렇다면 AWS Well-Architected Framework는 무엇을 기반으로 할까요?
Well-Architected Framework 는 6가지 핵심요소로 구성되어있습니다.
첫 번째는 운영의 우수성입니다. 이 핵심 요소는 인력과 프로세스 효율성을 개선하는 데 중점을 둡니다. 이 핵심 요소의 예로는 변경 관리 및 자동화, 이벤트 대응 및 일상 작업을 성공적으로 관리하기 위한 표준 정의 등이 있습니다.
다음은 보안입니다. 이 원칙은 데이터와 정보, 시스템을 보호하는 데 중점을 둡니다. 이 핵심 요소의 예로는 최소 권한 액세스 제공, 자격 증명 관리, 시스템 보호, 보안 이벤트를 감지하고 효율적인 방식으로 대응하기 위한 , 제어 설정 등이 있습니다.
다음은 신뢰성입니다. 이 핵심 요소는 구성 요소, 서비스 또는 인프라 이벤트를 처리할 수 있는 , 복원력이 뛰어난 고가용성 시스템을 설계하는 데 중점을 둡니다. 이를 통해 고객은 예기치 않은 상황에서도 비즈니스를 계속 운영할 수 있습니다. 이 핵심 요소의 예로는 설정을 중심으로 하는 기본 요소, 교차 프로젝트 요구 사항, 복구 계획, 변경 처리 방법 등이 있습니다.
다음은 성능 효율성입니다. 성능 효율성 핵심 요소는 비즈니스 목적, 결과, 목표를 달성하기 위해 AWS 리소스를 효율적으로 사용하는 데 중점을 둡니다. 이 핵심 요소의 예로는 워크로드 요구 사항에 따라 적합한 리소스 유형 및 크기 선택, 성능 모니터링, 탄력성 보장 등이 있습니다.
다음은 비용 최적화입니다. 이 핵심 요소는 현재 지출의 가치를 극대화하는 데 중점을 둡니다.
예를 들어 자금이 어디에 지출되는지 파악하고, 애플리케이션에 가장 적합한 AWS 리소스를 선택하고, 장기적인 성공을 위해 시간 경과에 따른 지출을 분석할 수 있습니다.
마지막으로 지속 가능성입니다. 이 핵심 요소는 클라우드 워크로드 실행이 환경에 미치는 영향을 , 최소화하는 데 중점을 둡니다. 이 핵심 요소의 예로는 환경에 미치는 영향을 이해하고 활용도를 극대화하여 필요한 리소스를 최소화하고 다운스트림 영향을 줄이는 것 등이 있습니다.
고객의 아키텍처를 검토하고 PDF나 스프레드시트형태로 답변을 문서화할수있지만 , 이로 인해 워크로드와 포트폴리오의 성숙도를 측정하는 , 인사이트가 제한될 수 있습니다. 고객은 AWS Well-Architected Tool을 사용하여 워크로드와 포트폴리오의 성숙도를 문서화할 수 있습니다. 그런 다음 해당 데이터를 사용하여 투자를 유도하고 애플리케이션 상태에 대해 소통할 수 있습니다.
AWS 고객과 협업하여 AWS Well-Architected Framework와 AWS Well-Architected Tool을 통해 , 애플리케이션 워크로드를 검토했다고 가정해 보겠습니다. Well Architected Tool 을 통해 문제를 파악하고 , 해당 워크로드에 대해 위험 점수를 할당합니다. 이러한 점수를 바탕으로 고객에게 개선 노력의 우선순위를 ,어디에 두어야 하는지에 대해 , 더 나은 조언을 할 수 있습니다.
이러한 결과를 바탕으로, 고객에게 운영 절차에 대한 업데이트 나 AWS 클라우드 네이티브 서비스로 이전 과 같은 간단한 조치로 ,위험을 먼저 해결하도록 조언할 수 있습니다.
예를 들어 셀프 매니지드 애플리케이션 스택을 AWS 관리형 서비스로 전환하면 더 나은 확장성, 성능, 가용성을 제공하는 동시에 비용을 관리할 수 있습니다.
또 다른 이점은 인프라 관리 대신 비즈니스 로직에 더 많은 시간을 사용할 수 있다는 점입니다.
이러한 조정을 통해 고객은 애플리케이션 설계의 위험 점수를 개선할 수 있습니다.
파트너는 AWS Well-Architected Framework를 사용하여 , 고품질의 솔루션을 구축하고 , 모범 사례를 구현하고 개선하여 , 고객의 비즈니스 성과를 달성하기 위한 전문 지식을 얻을 수 있습니다.
AWS Well-Architected 검토는 고객과의 지속적인 관계를 통해 파트너로서 추가적인 비즈니스 성과와 잠재적인 수익을 발견할 수 있는 기회를 제공하기도 합니다.
AWS Well-Architected Framework에 대해 자세히 알아보려면 이 과정의 마지막 부분에 제공되는 리소스를 참조해주십시오.
참여해 주셔서 감사드리며 다음 동영상에서 뵙겠습니다.