높은 수준의 전략
조직이 클라우드로 이동할 준비가 되었다고 판단되면 여러 가지 상황별 결정을 내려야 합니다. 일반적인 안내 전략을 갖는 것이 중요합니다.
클라우드 마이그레이션 전략을 통해 해결하고자 하는 목표와 문제를 제시하면 비즈니스 및 기술 전략을 조정하는 데 도움이 될 수 있습니다. 무엇을 달성하고 싶습니까?
- 비용을 절감하거나 시장 출시 시간을 단축하려고 하십니까?
- 숙련된 직원을 유치하고 유지하는 데 어려움을 겪고 있습니까?
- 제품이나 서비스의 품질을 개선하기 위해 노력하고 있습니까?
- 이러한 목표가 시급한가, 아니면 장기적인가?
- 클라우드로 이동할 때 충족해야 하는 컴플라이언스 요구 사항이 있습니까?
이러한 요소는 클라우드 마이그레이션 전략이 어떤 모습이어야 하는지 결정하는 데 중요합니다.
공급업체 선택
동종 워크로드 요구 사항이 있는 비교적 소규모 조직의 경우 기술 중복성을 위해 여러 클라우드 공급업체에 투자하거나 공급업체 종속을 방지하기 위해 여러 클라우드 공급업체에 투자할 필요가 거의 없기 때문에 단일 공급업체 클라우드 전략이 가장 적합할 수 있습니다.
다양한 워크로드와 다양한 수준의 기술 요구 사항을 가진 글로벌 은행과 같은 훨씬 더 큰 조직은 각 프로젝트 팀이 요구 사항에 가장 적합한 공급업체를 선택할 수 있는 유연성을 제공하기 때문에 멀티 클라우드 전략을 추구할 가능성이 더 높습니다. 또한 대규모 조직일수록 충족해야 할 내부 및 외부 컴플라이언스 요구 사항이 있을 가능성이 높으며, 이를 위해서는 비교적 짧은 시간에 클라우드 공급업체 간에 워크로드를 이동할 수 있는 기능이 필요할 수 있습니다.
기존 데이터 센터와 클라우드 공급업체가 모두 참여하는 하이브리드 전략은 특히 클라우드로의 전환이 수년에 걸쳐 진행되는 경우 중견 기업과 대기업에도 적합할 수 있습니다. 이 전략은 비즈니스 내에서 클라우드 기술 구현에 대해 자세히 알아보면서 클라우드 마이그레이션 전술을 보다 동적으로 발전시켜야 하는 경우에도 관련이 있을 수 있습니다.
식스 R(Six R's)
클라우드 마이그레이션 목표와 공급업체 전략을 결정했다면 다음 단계는 워크로드를 클라우드로 마이그레이션하는 방법을 결정하는 것입니다.
먼저 기존 애플리케이션에 대한 감사를 수행해야 합니다. 이를 통해 클라우드로 이동하는 데 필요한 작업의 수준과 특성을 파악할 수 있습니다. 이 감사 중에 응용 프로그램을 담당하는 팀이 클라우드 마이그레이션에 대해 취하기를 원하는 접근 방식에 따라 응용 프로그램을 분류할 수 있습니다. AWS는 6가지 "일반적인 마이그레이션 전략" 을 간략하게 설명합니다. 이는 전반적으로 적용할 수 있으며, 각 팀은 조직의 규모와 관련된 복잡성에 따라 해당 시점의 특정 설정에 가장 적합한 전략을 선택할 수 있습니다.
1. 호스트 변경
첫 번째이자 가장 간단한 전략은 애플리케이션을 다시 호스팅하는 것입니다("리프트 앤 시프트"라고도 함). 여기에는 데이터 센터에서 실행되는 물리적 서버에서 클라우드에서 실행되는 가상 서버로 이동하는 작업이 포함됩니다. 일반적으로 이를 위해서는 코드 변경이 필요하지 않으며 프로세스 및 네트워킹과 같은 주변 기술에 대한 변경이 비교적 적습니다. 또한 조직에서 다른 클라우드 네이티브 사례에 필요한 클라우드 기술과 경험을 개발할 수 있습니다.
2. 리플랫포밍
"리프트, 팅커 앤 시프트"라고도 하는 이 접근 방식은 리호스팅과 유사하지만 애플리케이션 수준에서 여러 가지 기본 클라우드 서비스를 통합하여 한 단계 더 나아갑니다. 예를 들어, AWS IAM(Identity and Access Management)을 애플리케이션에 통합하여 기존의 데이터 센터 지향 IAM 시스템을 대체하거나 보완할 수 있습니다.
3. 환매
"drop and shop"이라고도 하는 이 접근 방식에는 기존 온프레미스 애플리케이션을 라이선스가 부여된 클라우드 기반 서비스로 교체하는 작업이 포함됩니다. 여기에는 비즈니스에서 사용하는 라이선스 모델을 변경하고, 유지 관리 비용을 낮추고, 잠재적으로 더 빠르고 쉬운 업그레이드 경로를 허용하는 것이 포함될 수 있습니다.
4. 리팩터링/재설계
보다 클라우드 네이티브 접근 방식은 기존 코드베이스를 수정하거나 확장하여 보다 현대적인 클라우드 서비스 내에서 작동하도록 하는 것입니다. 한 가지 예는 애플리케이션 코드를 컨테이너화하고, 구성을 실행하고, Amazon의 EKS 또는 Azure의 AKS와 같은 클라우드 기반 Kubernetes 서비스 내에서 실행하는 것입니다. 여기에는 기존 코드베이스가 작동하고 확장성을 높이기 위해 상당한 재작성이 포함될 수 있습니다. 진정한 클라우드 네이티브 도구(예: AWS Lambda 또는 Azure Functions와 같은 서버리스 도구)를 사용하려면 완전한 재작성이 필요할 수도 있습니다.
5. 은퇴
마지막 두 가지 "수동" 전략을 사용하면 워크로드가 클라우드로 전혀 마이그레이션되지 않습니다. 워크로드 감사는 중복되거나 더 이상 유지 관리할 가치가 없는 시스템을 발견할 수 있습니다. 이러한 애플리케이션은 사용 중지할 수 있습니다.
6. 보유
마지막 "수동적" 전략인 보존은 애플리케이션을 계속 실행하고 가까운 장래에 클라우드로 마이그레이션하지 않도록 선택하는 것입니다. 애플리케이션을 클라우드 외부에 유지하는 데에는 다음과 같은 여러 가지 이유가 있을 수 있습니다.
- 애플리케이션을 실행할 수 있는 위치에 대한 규제 제약 또는 보안에 대한 높은 내부 컴플라이언스 요구 사항
- Mission-criticality of software that can make planning a move to cloud technologies earlier in the migration cycle too risky and uncertain
- 애플리케이션 이동으로 인한 중단에 대한 비즈니스 사례 없음
- 클라우드 환경에서 지원되지 않는 레거시 시스템
어디서부터 시작해야 할까?
전반적인 전략을 결정하고 워크로드당 전술적 접근 방식을 분류하는 것 외에도 워크로드 이동을 지원하기 위해 클라우드 인프라를 구축하는 방법에 대한 계획이 필요합니다. 한 가지 접근 방식은 각 팀이 클라우드에서 자체 시스템을 구축하는 방법을 선택하도록 하는 것입니다. 그러나 이 접근 방식에는 팀이 안티 패턴 구현을 복제하고 서로의 실수를 반복하거나 내부/외부 컴플라이언스 규칙을 위반할 수 있기 때문에 몇 가지 단점이 있습니다.
또 다른 접근 방식은 일종의 중앙 집중식 "Center of Excellence" 또는 클라우드 인프라 팀을 만드는 것입니다. 이 팀은 다른 팀이 워크로드를 실행할 수 있는 핵심 시스템을 배치하도록 선택할 수 있습니다.
이러한 가드레일을 설정할 때 다른 요소보다 우선시해야 하는 특정 디자인 요소가 있습니다.
계정
클라우드 아키텍처의 가장 기본적인 단위는 클라우드 계정입니다. 조직 전체에서 하나의 계정을 사용하면 계정 한도에 부딪히기 때문에 거의 항상 확장에 실패합니다. 따라서 계정 경계를 결정하는 것이 중요합니다. 계정이 특정 사업부, 개별 팀 또는 소프트웨어 서비스 그룹을 나타내는 데 사용됩니까? 재무 부서에서는 어떻게 운영됩니까? 청구서는 누가 받아야 하나요? 비용이 빠르게 증가할 수 있으므로 초기에 이를 파악하는 것이 중요합니다.
증권 시세 표시기
다음으로 가장 기본적인 아키텍처 단위는 ID 및 액세스 관리 시스템입니다. 클라우드 인프라가 성장함에 따라 다양한 클라우드 서비스 및 데이터에 대한 사용자 액세스가 보안에 미치는 영향을 고려해야 하며, 빠르면 빠를수록 좋습니다. 이미 실행 중인 시스템에 이러한 규칙을 소급하여 적용하는 것은 복잡할 수 있습니다.
네트워킹
클라우드로의 마이그레이션에는 기존 네트워크의 가상화 또는 완전한 재설계가 포함됩니다. VPC(AWS) 또는 VNet(Azure) 서비스를 사용하면 계정 내에서 별도의 서비스 세트를 실행하도록 격리된 네트워크를 설정할 수 있습니다. 조직의 서비스와 IP 주소와 같은 기본 네트워크 리소스 간의 네트워크 간 통신 을 신중하게 고려해야 합니다.
데이터 마이그레이션
컴퓨팅 서비스를 클라우드로 이동하는 것은 쉽지만 데이터를 마이그레이션하는 것은 조금 더 어려울 수 있습니다. 주요 데이터 저장소는 이동을 위해 신중한 계획이 필요한 크고 복잡한 인프라일 수 있습니다. 이를 위해서는 조직의 성능, 컴플라이언스 및 운용성 표준을 준수하면서 데이터를 클라우드로 이동하는 방법에 대한 충분한 이해가 필요합니다.
결론
높은 수준의 클라우드 전략을 명확히 한 후 성공적인 클라우드 마이그레이션 전략을 개발하려면 비즈니스의 모든 측면에 대한 세심한 계획과 고려가 필요합니다. 귀사에 적합한 클라우드 벤더 전략(간단한 단일 벤더 마이그레이션, 멀티 클라우드 벤더 접근 방식 또는 하이브리드 전략)을 선택하는 것이 다음 단계입니다. 마지막으로, 애플리케이션 온보딩을 시작하기 전에 먼저 주요 인프라 구성 요소를 고려하여 클라우드 마이그레이션을 설계하는 것이 좋습니다.
이 블로그 게시물이 흥미롭고 가치 있는 글이 되었기를 바랍니다.
컨테이너/Kubernetes 및 서버리스 서비스에 대한 향후 블로그 게시물을 기대해 주세요.
클라우드로의 여정을 시작하는 경우 안전한 클라우드 마이그레이션을 위한 5가지 모범 사례에 대한 새로운 백서를 읽어 보시기 바랍니다.
체크포인트의 클라우드 보안 솔루션에 대한 자세한 내용은 여기에서 확인할 수 있으며, 체크포인트의 클라우드 보안 엔지니어 중 한 명과 함께 데모를 예약 하려면 여기를 클릭하세요.
안전한 클라우드 아키텍처를 설계하고 구현하는 방법을 이해하려면 이 백서를 확인하세요.
피드백