BLOG
SaaS에 대한 이전 블로그 포스트에서 저는(원문의 저자) 애플리케이션을 SaaS(Software as a Service) 모델로 마이그레이션하기위한 몇 가지 전략을 설명 드렸습니다. 해당 게시글은 기업들이 애플리케이션의 설계 또는 아키텍처의 기본 사항을 변경하지 않고 기존 솔루션을 AWS로 옮길 수 있도록 최소화의 침범 접근(Minimally invasive) 방식에 중점을 두었습니다.
이동 부품을 제한하는 것은 매력적인 마이그레이션 전략으로 보일 수 있지만, SaaS 및 AWS의 모든 잠재력을 실현하는 능력 또한 제한하게 됩니다.
설계와 아키텍처를 크게 변경하지 않는 한 클라우드 태생의 SaaS 애플리케이션과 관련 있는 광범위한 민첩성과 자동화를 수용하기가 어려워 질 수 있기 때문입니다.
따라서 오늘 게시글에서는 여러분의 애플리케이션의 설계와 아키텍처 활용을 멈추고, 다시 생각 해 볼 수 있는 SaaS 마이그레이션 모델을 살펴 볼 예정입니다. 여기서 강조할 점은 변화를 최소화하는 것이 아니라 솔루션을 AWS 및 SaaS 모범 사례 및 설계 원칙에 맞추기 시작하는 것으로 변화 됩니다. 이는 여러분의 비즈니스가 시장 및 경쟁 상황에 보다 신속하게 대응할 수 있도록 민첩성과 자동화의 가치를 채택 할 수 있는 솔루션으로 훨씬 더 나은 위치에 포지셔닝 되도록 돕습니다.
이전 블로그글에서 강조한 증가하는 마이그레이션이라는 주제가 금번 글에도 이어집니다. 여러분의 애플리케이션의 설계에 보다 침투하여 변경를 만드는 것을 고려 하더라도 여러 작은 단계들을 거쳐야 합니다. 이 접근 방식을 사용하면 시스템 마이그레이션 중에 포착된 지식을 기반으로 설계를 신속하게 평가하고 재구성할 수 있습니다.
다음 섹션에서는 이러한 마이그레이션 방식과 함께 제공되는 일반적인 고려 사항 중 일부를 간략하게 설명하고 이러한 특성의 변환과 함께 제공되는 주요 고려 사항 중 몇몇을 파헤쳐보겠습니다.
세분성은 민첩성을 추구합니다 (Granularity drives agility)
어떤 특정한 전략의 세부 사항을 파고 들기 전에, 마이그레이션을 구성하고 안내 할 가치 시스템(Value System)을 고려해야 합니다. 결국 실제로 코드를 파고 대대적으로 코드를 변경하려는 경우, SaaS의 이점을 완전히 실현할 수 있도록 기회를 극대화 할 수 있는 설계 원칙에 부합하길 원할 겁니다.
세분성 및 서비스 분해는 종종 논의의 중심에 있습니다. 대상이 될 민첩성 목표 중 다수는 일반적으로 애플리케이션이 일련의 소규모의 자율적 서비스로 분해되는 마이크로 서비스 모델을 채택하여 달성됩니다. 이러한 서비스는 배포 자동화, 복원력 향상, 성능 및 스케일 최적화 등을 위한 광범위한 옵션을 가능케 하는 핵심입니다. 기본적으로 다중 테넌트 인식 마이크로 서비스 모델로의 이동은 기본 개념이 되어 마이그레이션 접근 방식에 영향을 줄 수 있습니다. 서비스의 경계는 이제 복원력, 확장성 및 배포 프로필의 영향을 받습니다. 이전 환경의 논리적 서비스는 새 모델에서는 유효한 서비스를 나타내지 않을 수 있습니다. 더욱 현대적인 설계 원칙들을 도입하기 위한 민첩성과 결합된 AWS 서비스의 강점을 활용 할 수 있는 가능성은 여러분 시스템의 기초 구성과 관련 서비스들을 재고려 할 수 있는 기회를 나타냅니다.
실제로 각 조직마다 고유한 마이그레이션 경로가 있을 수 있습니다. 도메인의 요구 사항, 기존 기술 스택의 상태 및 비즈니스 압력 등은 모두 마이그레이션이 전개되는 방식에 중요한 영향을 미칩니다. 여기서 핵심은 궁극적으로 광범위한 기술, 운영 및 민첩성 목표에 맞는 과정을 그리는 동안 이러한 현실을 수용 할 수 있는 방법을 찾는 것입니다. 그 균형은 항상 SaaS 마이그레이션 프로젝트에 있어 가장 신경 써야 하는 부분입니다.
실행 모델 선택
마이크로 서비스로의 전환을 고려하더라도 이러한 마이크로 서비스를 호스팅하는데 사용될 인프라 및 아키텍처에 대해서도 고려해야 합니다. AWS를 사용하면 Amazon EC2 (Amazon Elastic Compute Cloud), Amazon ECS(Amazon EC2 Container Service) 및 AWS Lambda 기능 등 다양한 환경에서 서비스를 실행할 수 있습니다 .
이러한 모델 중 하나는 SaaS 서비스에 대해 완전히 유효한 경로를 나타냅니다. 인프라 프로파일 및 개발 모델은 다양하지만 각 모델의 가치 시스템은 크게 변경되지 않습니다. 마이그레이션 경로는 단순히 이러한 옵션을 평가하고 팀, 비즈니스 요구 및 아키텍처의 장기적인 진화 경로가 각 서비스의 프로필과 어떻게 정렬 될 수 있는지 결정해야 합니다.
SaaS 솔루션에 이러한 모델의 하이브리드 형태를 고려할 수도 있습니다. 예를 들어, 도메인 내의 몇몇 이벤트-중심 또는 배치 워크로드는 Lambda에 잘 매핑 되는 반면 다른 비트는 ECS에 더 적합 할 수 있습니다.
다음 섹션에서는 SaaS 시스템 아키텍처를 새 모델로 마이그레이션하는 것과 관련이 있는 몇 가지 기본 테마를 간략하게 설명해 드리겠습니다. 사용자 환경의 고유한 요구 사항에 따라 이들을 혼합하고 일치시킬 수 있습니다.
SaaS 설계안 마이그레이션 테마
여러분의 설계안을 마이그레이션을 하기 위한 모델은 몇 가지 캠프로 나뉩니다. 일부 접근 방식은 전체 마이그레이션을 수행해야 할 필요가 있으며 다른 접근 방식은 마이그레이션을 위한 격리된 병렬 경로를 생성해야 할 필요가 있습니다.
모든 경우에 있어 주요 접근법은 시스템의 일부 조각 또는 새로운 기능을 발라내고 새로운 다중 테넌시, 설계 및 아키텍처 원칙 기반으로 시스템의 해당 부분을 제공하는 것입니다. 새로운 영역이 구분 되면 시스템의 추가 구성 요소를 새로운 모델과 통합하거나 병합하는 방법을 모색합니다. 이로 인해 모든 시스템이 다시 작성되거나 일부 하이브리드 모델에서 전략적으로 마이그레이션 된 서비스가 필요할 수 있습니다. 여기에는 특별히 선호되는 솔루션이 없다는 점에 유의해 주십시오. 환경의 역동성과 비즈니스 여건에 따라 여러분의 요구에 가장 잘 맞는 전략이 결정 될 수 있습니다.
다음 섹션에서는 서비스 별 마이그레이션, 병렬 시스템 마이그레이션 및 신제품 마이그레이션과 같은 디자인 마이그레이션 전략의 세 가지 예를 중점적으로 설명하겠습니다.
서비스 별 마이그레이션 모델
우리의 목표가 시스템을 마이크로 서비스로 분해하고 이러한 서비스가 본질적으로 자율적 모델로 실행되는 것이라면, 이 자율성을 활용하여 설계를 점차적으로 마이그레이션 할 수 있어야 합니다. 이 아이디어는 시스템을 서비스로 분해하는 방법에 대해 대략적인 개념으로 표현하는 것으로 부터 시작하는 것입니다. 이 대략적인 모델을 사용하면 마이그레이션에 적합한 후보를 나타내는 하나 이상의 서비스를 찾을 수 있습니다.
이러한 초기 후보를 식별할 때 시스템의 몇몇 비중요 기능을 나타내는 서비스 또는 기능을 우선적으로 찾는 경향이 있습니다. 예를 들어 전자 상거래 솔루션을 마이그레이션하는 경우 고객 평점 엔진 서비스로 시작할 수 있습니다. 이 서비스는 선택 사항으로 간주될 수 있기 때문에 프로필에 잘 맞습니다. 어떤 이유로 평점 엔진에 문제가 발생하기 시작하면 시스템이 해당 기능을 비활성화(또는 클라이언트가 캐시) 시킨 채 계속 작동 할 수 있습니다.
다음 다이어그램은 서비스 별 마이그레이션 전략을 실행하는 방법을 개념적으로 보여줍니다.
다이어그램의 왼쪽에는 단일 테넌트 인프라(아마도 사일로 모델에 배포됨)가 있습니다. 오른쪽에는 Amazon ECS를 활용하여 다중 테넌트 인식 마이크로 서비스를 호스팅하는 대상 아키텍처가 있습니다. 이러한 새로운 서비스는 시스템의 대상 상태를 기반으로 구현되며 선호하는 설계 및 아키텍처가 내재된 모델로 코딩되고 배포되어야 합니다.
이러한 전환은 종종 시스템 서비스를 구성하는 방법의 기본 사항을 재고 해야 하는 것을 의미합니다. 마이크로서비스 가치와 SaaS 모범 사례를 한 번에 해결하려면 종종 광범위한 새로운 사례를 검토하고 채택해야 합니다. 새로운 각 서비스에서 실현되는 SLA, 미터링, 보안, 로깅, 분석 및 Fault Tolerance 모델에 대해 생각할 수 있습니다. 또한 이러한 서비스에 테넌트가 적용되는 방식, 특히 완전히 공유된 모델로 이동하는 경우에 대해서도 고려해야 합니다.
마이크로 서비스는 자체 스토리지 모델을 소유할 수도 있습니다. 실제로 다이어그램에서 초록색과 검은색 원으로 표시되는 두 개의 마이크로 서비스에는 자체 스토리지 공간이 있음을 알 수 있습니다. 한 서비스는 Amazon Relational Database Service(Amazon RDS)를 사용하고 다른 서비스는 Amazon DynamoDB를 사용합니다. 이 마이그레이션 노력을 통해 각 서비스 프로파일의 요구에 가장 적합한 스토리지 서비스를 파악해야 합니다. 한 서비스에 좋은 것이 다른 서비스에 적합하지 않을 수 있습니다.
이러한 초기 서비스에 대한 기준 환경을 설정하면 마이그레이션에서 큰 발전을 보일 것입니다. 새로운 모델에서 실행되는 단일 서비스를 사용하려면 서비스 및 인프라의 많은 기본 요소를 실행해야 합니다. 또한 빌드 및 배포 환경의 핵심 요소를 표면에 적용합니다.
이 토대가 마련되면 더 많은 서비스가 더 빠른 속도로 마이그레이션을 시작할 수 있습니다. 이는 다이어그램에서 왼쪽에서 오른쪽으로 이동하는 것으로 표시된 서비스로 표시됩니다. 이 전환 중에는 솔루션의 일부 측면이 기존 모델에 의해 서비스되고 일부는 새로운 마이크로 서비스 모델에 의해 서비스되는 하이브리드 모델에서 작동하게 됩니다.
본 예제에서는 ECS 기반 대상 환경을 선택했습니다. 그러나 이 접근 방식은 ECS와 관련이 없습니다. 동일한 시나리오가 Amazon EC2 또는 AWS Lambda 호스팅 마이크로 서비스를 사용하여 매우 유사하게 재생되는 경우도 생각해볼 수 있습니다. 세부 사항은 다양하지만 개념과 전략은 거의 동일합니다. 여기서 중요한 점은 이러한 새로운 마이크로 서비스를 정의하는 과정에서 솔루션 요구에 가장 잘 맞는 AWS 컴퓨팅 구성을 고려해야 한다는 것입니다. 실제로 일부 서비스는 EC2 모델에 더 적합하고 다른 서비스는 Lambda에 더 적합하다는 것을 알 수 있습니다.
해당 마이그레이션 모델은 비교적 간단하지만 마법의 총알이 아니며 고유한 어려움들 또한 있습니다. 그래도 기존 서비스에서 새로운 서비스로 자연스럽게 연결되어 마이크로 서비스 기반을 구축하고 서비스 별로 공유 인프라 환경을 발전시킬 수 있게 해 줍니다.
병렬 시스템 마이그레이션 모델
일부 기업은 기존 시스템을 깔끔하게 정리하기를 원합니다. 기존 환경과 새로운 환경 간의 상호 운용성을 지원하면 새로운 모델로의 전환 속도를 느리게 만드는 일정 수준의 복잡성이 발생합니다. 또한 새로운 환경과 기존 환경의 병렬 실행을 지원해야 할 필요성이 추가된 오버헤드로 간주될 수 있습니다.
이 병렬 수하물을 없애기 위해 병렬 마이그레이션 모델을 고려할 수 있습니다. 여기서 병렬 SaaS 제품의 새 버전을 구성하는 데 사용될 완전 병렬 개발 경로를 개척합니다. 이 접근 방식을 통해 SaaS 팀은 새로운 아키텍처, 제공 및 민첩성 목표를 채택한 완전히 독립된 새로운 제품을 점진적으로 제공할 것입니다.
어느 시점에서 이 새 버전의 기능이 허용 가능한 수준의 성숙도와 기능에 도달하면 SaaS 기업들은 일부 테넌트들을 새 시스템으로 향하게 됩니다. 예를 들어 특정 프로필을 충족하는 테넌트 또는 새로운 테넌트는 새로운 시스템에 탑승 할 수 있습니다.
이 접근법에 대한 이국적인 것은 없습니다. 새로운 시스템이 라이브 테넌트를 지원하려면 더 많은 시간과 에너지가 필요할 수 있기 때문에 더 많은 위험이 발생합니다. 또한 사용자 및 운영 피드백에 의한 점진적 진화 부족으로 인해 설계 및 아키텍처를 위한 가정 들을 평가하기가 어려울 수 있습니다.
병렬 시스템 마이그레이션의 가치는 팀과 전체 조직이 이러한 변경 사항이 기존 제품의 안정성에 어떤 영향을 줄지에 대한 우려없이 새로운 SaaS 기반을 탐색 할 수 있다는 것입니다. 이는 개발에 어느 정도의 자유를 가져다 줄 수 있고, SaaS 애플리케이션 개발 및 서비스와 관련된 문화적인 측면을 보다 빠르게 적용 시킬 수 있습니다.
신제품 마이그레이션 모델
이상적인 시나리오에서 살펴본 두 가지 옵션의 장점을 균형 있게 유지하려고 합니다. 선호되는 접근 방식은 기존 솔루션과의 통합 없이 반복 마이그레이션의 이점을 실현할 수 있는 방법입니다.
이 경로는 일반적으로 완전히 새로운 제품으로 시작하는 것을 의미합니다. 따라서 기존 제품에서 새로운 제품으로 하이브리드 브리지를 찾으려고 하는 대신 새로운 제품을 식별하고 해당 제품을 SaaS 모델의 그린 필드 기회로 사용할 수 있습니다.
이 접근법은 종종 이상적인 균형을 나타냅니다. 어떠한 제약 없이 SaaS 목표와 아키텍처 비전을 자유롭게 추구할 수 있습니다. 또한 기존 제품에서 제공하는 모든 기능과 일치하지 않아도 됩니다. 더 중요한 것은 이 접근 방식을 통해 기존 고객에게 영향을 주지 않으면서 다중 테넌트 아키텍처 및 제공 모델의 기본 사항을 강화하고 발전시킬 수 있습니다. 이 새로운 제품으로 기초가 확립되면 다른 SaaS 오퍼링을 새로운 모델로 마이그레이션하는 가장 좋은 방법을 결정할 수 있는 훨씬 나은 위치에 있게 됩니다.
이 접근법과 관련하여 명백한 도전 과제가 있습니다. 첫째, 고객에게 제공 할 수 있는 명확하고 새로운 제품이 없을 수도 있다는 점과 기존 제품 및 고객에게 비즈니스 가치가 높은 새로운 SaaS 기능을 제공하는 데 지연이 발생할 수 있다는 점입니다.
데이터 마이그레이션 고려 사항
애플리케이션 디자인을 새 모델로 마이그레이션하면 테넌트 데이터 저장 방법을 재고해야 합니다. AWS에서 테넌트 데이터 파티셔닝과 관련된 모든 고려 사항이 있습니다. 이러한 고려 사항은 금번 블로그 게시물의 범위를 벗어납니다.
데이터를 분할하는 방법에 관계없이 이 데이터를 잠재적으로 새로운 표현으로 마이그레이션하는 방법을 고려해야 합니다. 예를 들어, 마이크로 서비스 모델을 채택하는 경우 단일 통합 데이터 표현에서 서비스가 자율적이고 자체 데이터 뷰를 소유하는 보다 분산된 모델로 이동할 수 있습니다.\
데이터 표현, 최적화 및 마이그레이션은 전체 애플리케이션 분해 전략에서 핵심적인 역할을 수행해야 합니다. 애플리케이션의 새로운 서비스를 설계할 때 다양한 스토리지 전략과 AWS 스토리지 옵션이 접근 방식에 어떤 영향을 줄 수 있는지 생각하고 싶을 것입니다. AWS는 다양한 스토리지 솔루션을 제공하며 각 솔루션에는 SaaS 서비스와 연계해야 하는 강점과 기능이 있습니다.
‘큰 그림’에 집중하기
SaaS 솔루션의 디자인과 아키텍처를 다루면서 전반적인 ‘민첩성’ 목표에 계속 집중해야 합니다. 마이그레이션의 모든 단계에서 아키텍처 변경이 비즈니스 운영 및 민첩성에 어떻게 영향을 미치는지 고려 해야 합니다. SaaS 아키텍처를 보다 분해된 마이크로 서비스 모델로 마이그레이션하고 지속적 배포 하기 위해 각 조각들을 제자리에 배치하지 않으면 점수를 잃게 됩니다.
이러한 가치들을 전면 그리고 중앙에 유지한다는 것은 여러분 환경의 달라지는 모든 부분을 동시에 발전시키는 전략을 선택하는 것을 의미합니다. 빌드 및 배포 자동화, 인프라 자동화, 보안, 버전 관리, 데이터 마이그레이션, 운영 툴링 – 이러한 모든 기본적인 비트들은 실제 애플리케이션 서비스와 함께 작은 조각으로 제공되어야 합니다. 이러한 조각들이 집합적으로 등장하는 것을 보면 접근 방식에 민첩성을 불어 일으킬 수 있는 훨씬 더 나은 위치로 처음부터 놓여있게 해줍니다.
기회를 극대화하기
여러 측면에서 SaaS 애플리케이션들은 AWS에 이상적인 후보입니다. SaaS의 비즈니스, 기술 및 민첩성 요구는 AWS의 도구, 서비스 및 가치 제안과 밀접한 관련이 있습니다. AWS와 파트너 에코시스템은 SaaS 제공 업체가 SaaS 오퍼링의 성공을 극대화하기 위해 적용할 수 있는 광범위한 옵션을 제공합니다.
이 혁신적인 마이그레이션 경로를 설정하면 응용 프로그램 및 비즈니스 요구 사항이 사용 가능한 다양한 옵션 메뉴와 어떻게 조화를 이룰 수 있는지 다시 한 번 고려해야 합니다. 애플리케이션이 보다 분해된 모델로 전환됨에 따라 해당 서비스 요구에 가장 적합한 AWS 서비스 및 구성 옵션 조합을 고려할 수 있습니다. 또한 이러한 서비스의 확장 및 탄력성 정책을 구성하려는 방법에 대해 더 세밀하게 생각하기 시작할 것입니다.
또한 마이그레이션을 통해 타사 도구를 사용하여 SaaS 환경의 일반적인 요구 사항을 충족시키는 방법을 살펴볼 수 있습니다. AWS 파트너는 솔루션의 일부 핵심 요구 사항 (보안, 모니터링, 미터링 등)을 해결하는 데 도움이 되는 다양한 제품을 제공합니다. 이러한 오퍼링들은 SaaS 솔루션에 다양한 기능을 제공하여 애플리케이션의 떠 나은 기능들을 제공함에 더 많은 주의를 집중할 수 있도록 합니다.
궁극적으로 마이그레이션의 목표는 모든 것을 한번에 얻는 것이 아닙니다. AWS 서비스와 각종 도구들은 항상 진화하고 고객이 고려할 만한 새로운 기능들을 추가합니다. 따라서, 마이그레이션은 고객의 지속적으로 변화하는 요구를 지원하는 기반을 구축하되 현재 활용 가능한 것을 레버리지 할 수 있는 위치로 향하게 해야 합니다.
원문 URL : https://aws.amazon.com/ko/blogs/apn/migrating-applications-to-saas-rethinking-your-design/
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.