RESOURCES

SaaS (Software as a Service) 전달 모델은 많은 기업들에게 설득력 있습니다. 민첩성, 시장 대응성, 인프라 비용의 공유 — 이것들 모두 기업이 제품을 구축, 운용 및 수익을 창출하는 방식에 대한 접근 방식을 바꿀 수 있는 기회를 제공합니다. 그러나, 실제로는 동일한 조직이 기존의 단일 테넌트 제품에 상당한 투자를 하는 경우가 많습니다. SaaS은 매우 흥미롭지만, 팀이 애플리케이션을 완전히 재구성하고 멀티 테넌트 환경의 일반적인 특성과 원칙을 즉시 채택 할 수 있을 것으로 기대하는 것은 비현실적입니다.

 

따라서 조직은 큰 혼란 없이 솔루션을 SaaS 모델로 점진적으로 이동할 수 있는 창의적인 방법을 찾아야 합니다. SaaS의 이점이 도움이 될 수 있지만, 미리 주의점을 예측하여 SaaS로 전환하는 것이 중요합니다. 궁극적으로, SaaS의 최고의 특성을 물려 받고 비즈니스를 가능하게 하는 제품으로 이러한 변환에서 벗어나기를 원합니다. 단순한 리프트 앤 시프트 또는 준 SaaS 형태 등은 장기적인 목표를 약화시킬 수 있습니다.

 

SaaS 마이그레이션에 대한 모든 논의는 SaaS 모델에서 구축, 제공, 기술 지원 및 판매하는 것이 의미하는 모든 범위를 고려 해야 합니다. 이는 마이그레이션 논의는 애플리케이션 변환의 기술, 비즈니스 및 운영 측면에 대한 SaaS의 영향을 검토 해야 함을 의미합니다. 마이그레이션은 SaaS 환경의 모든 가동 부분을 지속적으로 검토하여 앞으로의 경로가 SaaS의 전체 가치를 수용함을 보장 해 줄 수 있는 몇 차례의 움직임을 결정 해야 합니다.

 

이 넓은 범위를 감안할 때 이 자료를 두 개의 블로그 게시 글에서 다룰 것입니다. 이 첫 번째 블로그 게시 글에서는 마이그레이션을 위한 최소 침범 모델을 살펴 볼 예정입니다. 여기에서의 포인트는 솔루션의 기본 설계에 대한 변경을 제한하려는 마이그레이션 전략을 식별하는 데 중점을 둡니다. 이 전략은 최소한 현재 솔루션의 중요한 재작성이나 구조 조정에 투자하지 않고 AWS의 보상을 얻기를 희망하는 많은 기업들에게 매우 일반적인 전략입니다. 다음 블로그 게시 글에서는 애플리케이션의 디자인과 아키텍처를 완전히 다시 생각할 수 있는 덜 제한적인 모델을 살펴 보겠습니다.

 

다음 섹션에서는 최소 침범적인 마이그레이션 전략의 장점을 검토합니다. 또한 마이그레이션을 지원하기 위해 비즈니스의 관리 및 운영 측면을 어떻게 변경 해야 하는지 살펴 보겠습니다. 전반적으로 이 두 블로그 게시물은 SaaS 애플리케이션의 마이그레이션 요구에 적합한 패턴에 대한 통찰력을 제공합니다.

 

당신은 어떤 멀티 테넌트입니까?

마이그레이션 전략을 파고 들기 전에 멀티 테넌시에 대한 논의에 확고한 기반을 두는 것이 중요합니다. 대부분의 개발자의 입장에서 멀티 테넌시는 모든 테넌트를 단일 인프라 공간에서 실행하는 것과 같습니다. 실제로 SaaS와 관련된 많은 민첩성 값이 이 공유 모델에 의존합니다. 비용, 구축, 관리 및 경쟁력 민첩성 – 모두 공유 인프라의 장점을 통해 큰 혜택을 받습니다.

 

문제는 이러한 멀티 테넌트가 모든 비즈니스 또는 모든 도메인에 실용적이지 않다는 것입니다. 실제로 성공적인 SaaS 솔루션을 제공하는 데 사용되는 여러 가지 모델이 있습니다. 실제로, 일부의 경우 SaaS 로의 이동은 단순히 관리 책임을 서비스 제공사에게 이전하는 것일 수 있습니다. 따라서 마이그레이션 노력을 위한 궁극적이고 보편적인 목표를 갖기를 원하지만 멀티 테넌시의 목표 최종 상태가 다를 수 있다고 가정하는 것도 공정합니다. 결과적으로 마이그레이션 전략도 다양 해야 합니다.

 

이러한 멀티 테넌시의 유동적인 정의를 고려 하면, 마이그레이션 전략에 대한 검토는 여러 가지 SaaS 멀티 테넌트를 포함 해야 합니다. 마이그레이션 프로세스는 테넌트 인프라의 일부 또는 전부가 독립적으로 실행될 수 있는 SaaS 모델을 허용 해야 합니다. 서비스 제공사와 테넌트에게 이러한 솔루션은 공유 인프라 솔루션만큼 SaaS가 아닙니다.

 

그러나 피해야 하는 함정은 마이그레이션 클러치로, ‘격리 (Isolation)’를 사용하는 것입니다. 테넌트와 비즈니스가 궁극적으로 공유 인프라 모델로부터 혜택을 얻을 수 있다다면 이것이 최종 목표가 되어야 합니다. 격리의 편리함이 해당 목표를 향해 마이그레이션 하는 능력을 약화시키게 두지 마세요.

 

기초 구축하기

성공적인 마이그레이션은 아무리 복잡하더라도 시스템 조각을 조각화 하고 새 모델 별로 1개씩 마이그레이션하려는 점진적인 사고 방식이 중요합니다. 점진적으로 접근하면 SaaS 기술 및 운영 가치 시스템의 채택을 지원할 토대를 마련하는 데 필요한 프레임 워크를 식별하고 소개 할 수 있는 자연스러운 기회가 제공됩니다. 로깅, 테넌트 구성, 서비스 구성, 데이터 액세스, 측정 — 이것들은 모두 정책과 테넌트 인식을 추상화하는 라이브러리를 도입해야 할 영역입니다.

 

도구와 프레임 워크를 구축하는 데 몇 개월이 걸리지 않는다는 점에 유의 해야 합니다. 새로운 모델로 시스템의 첫 번째 부분을 제공할 때 이러한 기본 개념이 나타나고 사고프로세스의 일부가 되어야 한다는 사실을 깨닫는 것입니다.

 

시작점

공통된 출발점을 제안하기에는 너무 많은 애플리케이션 디자인이 있고, 또 동시에 매우 자주 발생하는 아키텍처 패턴이 있습니다. 프레임 워크, 툴 및 일반적인 지침으로 많은 개발자들이 n- tier 형태의 개발을 따랐고, 그 결과 많은 애플리케이션이 다음 아키텍처의 몇몇 특징에 부합합니다.

 

이 아키텍처에는 기본적으로 애플리케이션 자산을 관리하고 전달하는 데 사용되는 웹 계층이 있습니다. 이 계층에는 트래픽을 웹 서버로 분산 시키는 로드 밸런서가 있습니다. 애플리케이션의 비즈니스 로직은 애플리케이션의 데이터베이스에 액세스하는 애플리케이션 계층 (주로 일부 데이터 액세스 계층을 통해)에 있습니다.

 

서비스 제공자는 이 아키텍처가 각 고객의 요구에 따라 복제 및 사용자 지정되는 온-프레미스 솔루션을 호스팅 하거나 제공합니다. 이러한 환경은 완전한 격리에서 작동하는 경향이 있으며 종종 다른 애플리케이션 버전을 실행 중일 수 있습니다. 각 설치 과정은 단일 테넌트의 요구사항들을 대응 한다고 가정하고 설계 또는 아키텍처에는 멀티 테넌시 개념이 없습니다.

 

또한 이 모델의 스케일 단위가 다소 거칠다는 것을 알 수 있습니다. 웹 서버와 애플리케이션 서버가 있습니다. 애플리케이션 서버의 일부 기능이 병목 현상을 일으키는 경우 이를 해결하는 유일한 방법은 애플리케이션 서버를 추가하는 것입니다. 컴퓨팅 리소스 (인스턴스)의 규모와 프로파일을 애플리케이션 기능의 보다 세분화 된 요소와 실제로 일치시킬 수는 없습니다.

 

이 아키텍처 모델에는 변형이 있지만 기본은 많은 기존 솔루션과 공유됩니다. 특정 비즈니스 기능 (배치 프로세스, 캐싱 등)을 대상으로 하는 서비스 제품 군으로 분리 된 애플리케이션 계층이 더 많을 수 있습니다. 공식적인 데이터 액세스 계층이 도입 된 것을 볼 수 있습니다. 이러한 다름에도 기본 모델과 접근 방식은 거의 변하지 않습니다.

 

이제 더 분해 된 마이크로 서비스 아키텍처로 이동 한 경우 SaaS 멀티 테넌시로 마이그레이션하는 경로가 더 간단해집니다. 해당 마이그레이션 모델에 대한 설명은 이 블로그 게시 글에서는 다루지 않습니다.

 

최소 침범적 마이그레이션 테마

위에서 설명한 아키텍처를 감안할 때 실제 문제는 기존 애플리케이션의 디자인이나 아키텍처를 근본적으로 변경하지 않고 기존 환경을 SaaS 모델로 마이그레이션하는 방법입니다. 전체 솔루션을 다시 작성하지 않고도 멀티 테넌시를 도입하기 위해서는 어떻게 해야 할 지, 마이그레이션 작업의 일환으로 배포 자동화 및 기타 SaaS 민첩성 원칙을 어떻게 해결할 지, 이러한 문제들은 마이그레이션 로드맵을 구성하려고 할 때 조직이 직면하는 문제들 입니다.

 

이 문제를 접근하는 방법은 여러 가지가 있지만 일부 패턴이 다른 패턴보다 더 일반적 입니다. 이 게시 글에서 살펴볼 마이그레이션 모델 목록은 다음과 같습니다.

 

• 사일로 마이그레이션 모델– 각 테넌트마다 별도의 인프라를 도입하여 단일 온 보딩 및 인증 경험을 통해 대응합니다.
• 계층화 된 마이그레이션 모델 – 애플리케이션의 계층이 멀티 테넌트 모델로 점진적으로 마이그레이션 됩니다.
• 데이터 마이그레이션 모델 – 스토리지 모델은 멀티 테넌트 모델로 마이그레이션되고 나머지 애플리케이션은 격리 된 테넌트 인프라에 남아 있습니다.

 

다음 섹션에서는 최소 침범적 마이그레이션 테마를 각각 검토하고 각 모델에 수반되는 주요 고려 사항을 살펴 봅니다. 또한 이 솔루션들이 상호 배타적이지 않다는 점에 유의 해야 합니다.

 

사일로 마이그레이션 모델

많은 조직에서 사일로 모델은 마이그레이션을 처리하는 가장 자연스럽고 매력적인 접근 방법을 나타냅니다. 사일로 모델의 기본 개념은 공유 인프라 모델이 너무 방대하기 때문에 한번에 소화 할 수  없다는 것입니다. 다음 이미지는 AWS 위에서 사일로 모델이 어떻게 보이는지에 대한 개념도를 제공합니다.

 

보시다시피 이 모델은 앞에서 설명한 원래 아키텍처에서 대부분의 핵심 개념 (데이터베이스, 애플리케이션 및 웹 계층)을 유지합니다. 사일로 모델은 각 테넌트마다 별도의 인프라 스택을 만듭니다. 이 유형의 마이그레이션은 가능한 한 기존 디자인의 변경 사항을 제한하고 AWS 서비스와 구성을 가장 적합한 곳에서 활용 하려고 합니다. 예를 들어, 아키텍처의 웹 및 애플리케이션 계층은 여러 가용 영역에 걸쳐있는 Auto Scaling 그룹에 배포됩니다. 각 테넌트는 독립적으로 확장되지만, 여전히 인프라에 탄력성을 적용하며 테넌트 로드를 기반으로 웹 및 애플리케이션 서버 수를 동적으로 확장 할 수 있습니다. 일부 애플리케이션의 경우 멀티 AZ 모델이 지금까지 달성 못했던 가용성과 내구성도 추가 됩니다.

 

사일로 마이그레이션에는 종종 AWS 스토리지 서비스 중 하나로의 이동이 포함됩니다. 예를 들어, SQL Server 데이터베이스에서 테넌트를 실행중인 경우 Amazon RDS (Amazon Relational Database Service)를 사용하여 스토리지 요구를 지원할 수 있습니다. 이를 통해 더 많은 책임을 AWS에 전가 할 수 있으며 운영 팀은 규모와 가용성을 최적화하기 위해 RDS가 제공하는 다양한 옵션을 활용할 수 있습니다.

 

사일로 모델은 새로운 테넌트를 온보드 할 때 몇 가지 새로운 방식을 소개 합니다. 이상적으로는 사일로 환경에서도 가능한 한 온보드 경험과 관계된 문제를 최소화 하려고 합니다. 이는 완전히 자동화된 신규 테넌트 프로비저닝을 통해 다른 SaaS 환경에서 볼 수 있는 것과 동일한 모델을 모방한 UI 및 가입 프로세스를 제시하는 것을 의미 합니다.

 

자동화된 프로비저닝으로 전환과 툴을 사용하여 테넌트 인프라를 감싸는 것이 초기 마이그레이션 작업의 초점입니다. 여기에서의 투자란 보다 민첩한 방향으로 이동할 수 있는 기회를 나타내며 고유 테넌트 구성 요구의 중앙 집중화 및 자동화를 촉진합니다. 여기에서 경험이 많으면 많을수록 설계와 아키텍처를 지속적으로 발전시킬 수 있는 좋은 위치에 있게 됩니다.

 

다행히 이 라이프사이클의 자동화는 AWS와 해당 파트너 에코시스템에서 지원하는 DevOps 툴의 핵심입니다. 이러한 툴을 사용하면 시스템의 반복성과 안정성을 향상시키는 강력하고 지속적인 전달 파이프 라인을 구축하는 데 필요한 모든 빌딩 블록을 갖추게 됩니다.

 

계층화된 마이그레이션 모델

계층화 된 마이그레이션 모델에서는 솔루션 레이어를 멀티 테넌시로 이동할 수 있는 기회를 찾는 데 중점을 둡니다. 이 방법의 핵심은 솔루션의 일부가 단일 테넌트 디자인을 유지하면서 공유 멀티 테넌트 모델로 점차 이동할 수 있는 레이어를 만드는 것입니다.

 

다음 다이어그램은 애플리케이션의 레이어 또는 레이어 마이그레이션을 시작하는 방법에 대한 예시를 제공합니다. 이 모델에서는 단일 테넌트 모델과 동일한 웹 및 애플리케이션 레이어를 볼 수 있습니다. 그러나 여기서 웹 계층은 테넌트 컨텍스트로 구현 되어 공유 된 멀티 테넌트 계층입니다.

 

이 다이어그램에서 웹 계층이 공유되는 동안 각 테넌트마다 고유 한 애플리케이션 계층이 있음을 알 수 있습니다. 웹 계층은 테넌트 컨텍스트를 기반으로 해당 테넌트의 애플리케이션 계층에 트래픽을 맵핑 합니다.

 

이 모델의 장점은 전체 멀티 테넌트 문제를 해결하지 않고도 더 많은 공유 개념을 물리 칠 수 있다는 것입니다. 실제로 선택된 계층은 애플리케이션 계층 일 필요는 없습니다. 환경에서 임의의 계층을 선택하여 멀티 테넌트 모델로 마이그레이션 할 수 있습니다. 그런 다음 적합하다고 생각되면 나머지 레이어를 천천히 잘라냅니다.

 

사일로 및 데이터 마이그레이션 모델과 마찬가지로 계층화 된 모델은 자동 프로비저닝으로의 병렬 마이그레이션에 의존합니다. 여기서 중요한 차이점은 이제 프로비저닝 해야 하는 범위가 변경된다는 것입니다. 웹 계층은 다소 일정하게 유지 될 수 있지만 새로운 테넌트 배포마다 새로운 애플리케이션 계층이 필요하게 됩니다.

 

데이터 마이그레이션 모델

데이터의 멀티 테넌트로의 이동은 SaaS화의 가장 어려운 측면 중 하나 일 수 있습니다. 대부분의 경우, 애플리케이션 코드는 데이터를 저장하는 데 사용되는 구조 및 기술과 밀접하게 관련되어 있습니다. 이러한 결합에도 불구하고 데이터 계층은 아키텍처 내에서 마이그레이션의 자연스러운 대상이 될 수 있는 매우 명확한 경계를 나타냅니다.

 

여러 측면에서 멀티 테넌트 데이터로의 마이그레이션은 위에서 설명한 계층화 된 마이그레이션 모델의 또 다른 변형입니다. 그러나 이 마이그레이션 모델은 상향식 전략처럼 느껴지는 경향이 있습니다. 이 전략에서는 스택을 애플리케이션 디자인의 세부 정보로 이동하기 전에 먼저 멀티 테넌트 데이터의 문제를 해결 해야 합니다.

애플리케이션에서 이미 데이터 액세스 계층을 도입 한 경우 데이터 마이그레이션이 훨씬 쉬워집니다. 이 계층은 일반적으로 세부 정보를 추상화하고 API 또는 스토리지 기술에 대한 바인딩을 제한합니다. 이 데이터 계층이 존재하면 데이터를 멀티 테넌트 모델로 정상적으로 마이그레이션 할 수 있습니다. 여기서 목표는 데이터 액세스 계층의 클라이언트에 대한 영향을 제한하면서 기본 데이터 액세스 구현을 테넌트 인식 및 파티셔닝을 포함하는 것으로 교체하는 것입니다.

 

이 시간을 사용하여 애플리케이션의 스토리지 기술을 재평가 할 수도 있습니다. 예를 들어 관계형 모델에서 NoSQL 로의 전환을 고려할 수 있습니다. 그러나 이러한 특성의 이동은 종종 마이그레이션 초기 단계에서 다루기에는 너무 침범 적인 것으로 간주됩니다. 나중에 애플리케이션을 더 작은 서비스로 분해하기로 결정한 경우에 각 서비스의 요구에 맞는 스토리지 모델을 선택할 수 있습니다.

 

어떤 경로를 선택하든 AWS는 다양한 스토리지 옵션을 선택할 수 있습니다. 예를 들어 관계형 모델에서 마이그레이션 하는 경우 Amazon RDS (Aurora, MySQL, SQL Server 등)의 일부인 관계형 솔루션 중에서 선택할 수 있습니다. 스토리지 마이그레이션 전략에 Amazon DynamoDB (NoSQL), Amazon Redshift (데이터웨어 하우징) 및 Amazon ElastiCache 가 포함될 수도 있습니다. AWS 스토리지 솔루션을 선택할 때 AWS Database Migration Service 및 AWS Schema Conversion Tool 을 사용하여 기존 데이터의 마이그레이션을 관리 할 수도 있습니다.

 

데이터 표현을 변경하면 기존 데이터를 새로운 멀티 테넌트 표현으로 마이그레이션 할 수도 있습니다. 여기서 일반적인 관행은 테넌트를 하나씩 이동하여 위험을 줄이고 프로세스를 보다 관리하기 쉽게 만드는 것입니다. 또한 이 접근 방식을 사용하여 각 테넌트가 새로운 구조로 이동함에 따라 시스템 성능을 실시간으로 파악할 수 있습니다. 그러면 모든 테넌트가 새 환경으로 마이그레이션 되기 전에 스토리지 구성을 조정할 수 있습니다.

 

이 단계적 데이터 마이그레이션은 테넌트의 온 프레미스 솔루션에서 AWS로 마이그레이션과도 연계 될 수 있습니다. 테넌트 데이터 변환은 각 테넌트가 AWS 환경에서 프로비저닝 되고 배포 될 때 적용됩니다.

 

AWS 스토리지 서비스로 마이그레이션 하면 AWS Identity and Access Management (IAM) 및 Amazon CloudWatch 매트릭스를 넣을 기회를 만듭니다. IAM을 사용하면 스토리지 액세스를 제어하고 테넌트가 영역 외부의 데이터에 액세스 할 수 없도록 합니다. CloudWatch를 사용하면 스토리지 활동에 대한 지표를 표시하고 관리 및 모니터링 경험을 향상시키는 더 많은 데이터 포인트를 제공 할 수 있습니다.

 

관리 및 모니터링 마이그레이션

관리 및 모니터링은 우리가 설명한 각 마이그레이션 모델에 보편적으로 적용됩니다. 기존 솔루션의 마이그레이션에 대해 논의하고 있으므로 이미 일정 수준의 관리 및 모니터링 도구가 있을 수 있습니다. 예를 들어, 대부분의 솔루션에는 시스템 상태를 확인할 수 있는 도구와 함께 로그 정보를 집계하고 분석하는 메커니즘이 이미 있습니다. 그러나 마이그레이션의 일환으로 SaaS 중심의 가치 시스템을 도입하기 시작하면서 이러한 도구를 어떻게 진화 시켜야 할까 생각하게 됩니다.

 

SaaS 솔루션의 일부 측면은 단일 테넌트로 유지되지만, 테넌트 활동을 1개의 단일, 통합된 시스템 상태 대시보드로 집약하는 관리, 모니터링 환경을 구축하는 것을 검토 해야 합니다. SaaS 민첩성은 시스템 상태에 대한 상세한 정보 확보 여부와, 경우에 따라, 여러 테넌트에 걸쳐 발생하는 문제에 빠르게 대응 하는 것에 달려 있습니다. 이러한 경험은 또한 단일 테넌트의 활동과 상태에 대한 가시성을 제공 해야 합니다. 기능 또는 성능상의 문제가 발생하고 있는 테넌트를 확인, 지원하기 위해서는 이 테넌트별 상태 표시가 필수적 입니다.

 

마이그레이션 초기 단계부터 관리 및 모니터링 영역을 접근 함으로써 환경이 발전함에 따라 더 많은 멀티 테넌트 개념을 지원할 수 있는 훨씬 나은 위치에 있게 됩니다. 이 초기 투자를 통해 더 많은 AWS 지표 데이터가 여러분의 관리 및 모니터링보기에 통합 할 수 있습니다. 환경 상태를 평가하기 위해 CloudWatch에서 지표와 이벤트를 가져오거나, 애플리케이션에 고유 한 세부 정보를 표시하기 위해 사용자 정의 CloudWatch 지표를 도입 할 수도 있습니다.

 

전반적으로 SaaS 로의 마이그레이션은 관리 및 모니터링 전략을 재평가 할 수 있는 기회를 나타냅니다. 이 기회를 활용하여 현재 툴을 넘어서서 채택 하고 있는 SaaS 가치 시스템에 가장 적합한 솔루션 조합을 결정 해야 합니다.

 

AWS 및 AWS 파트너 네트워크 (APN) 에코 시스템의 파트너에는 많은 모니터링 요구를 해결하는 데 사용할 수 있는 솔루션이 있습니다. 이 솔루션을 사용하면 복잡한 멀티 테넌트 환경을 지원하는 데 필수적인 다양한 활동 보기를 구성 할 수 있습니다.

 

운영 마이그레이션

마이그레이션 작업의 대부분은 애플리케이션 설계 및 아키텍처에 중점을 두기 때문에 마이그레이션의 운영 측면을 종종 간과하는 경우가 있습니다. SaaS 마이그레이션 모델에서 솔루션을 AWS로 옮길 때는 운영 영역을 간소화하고 자동화 할지에 대한 방법을 검토 해야 합니다.

 

AWS와 해당 에코 시스템은 SaaS 오퍼링의 운영 프로파일을 구성하고 향상시키는 데 사용할 수 있는 다양한 도구 세트를 제공합니다. 이러한 도구와 도구와 함께 제공되는 원칙은 SaaS 마이그레이션 작업의 핵심 요소여야 합니다. 조직에서 아직 DevOps를 채택하지 않은 경우 SaaS 마이그레이션은 기술 및 문화적 전환을 DevOps 사고 방식으로 시작할 수 있는 최적의 기회입니다. 많은 측면에서 DevOps 로의 전환은 민첩성 및 제품의 지속적이고 빠른 진화를 지원하는 새로운 SaaS 문화 마이그레이션의 핵심이 될 것입니다.

 

이 자동화를 조기에 적용하면 애플리케이션 설계 및 아키텍처의 발전을 단순화하는 기반을 구축 할 수 있습니다. 자동화 모델이 설정되면 이러한 메커니즘을 시스템의 새로운 영역에 적용하는 것이 더 간단 해집니다.

 

일부 조직에서는 DevOps 및 자동화에 대한 초기 투자 비용이 높은 경우도 있지만, 이러한 개념은 SaaS 서비스사업자에게는 너무 기초적인 부분이기 때문에 더 이상 미룰 수 없습니다. DevOps를 우선 순위로 설정하면 팀에 새로운 조직 구조 및 관계가 필요할 수 있는 영역을 드러냅니다.

 

AWS 스택에는 DevOps 마이그레이션에 도움이 되는 여러 도구가 포함되어 있습니다. AWS CloudFormation , AWS Elastic Beanstalk 및 AWS OpsWorks를 사용하여 인프라를 프로비저닝하고 배포를 자동화 할 수 있습니다. AWS는 또한 AWS CodeCommit , AWS CodePipeline 및 AWS CodeDeploy 와 같은 도구를 제공하며, 지속적인 배포 오케스트레이션을 지원합니다. 이러한 솔루션은 종종 AWS 에코시스템에서 생성 한 DevOps 자동화 도구와 관련되어 사용됩니다. 예를 들어 AWS CloudFormation을 사용하여 인프라 구성 및 프로비저닝을 자동화 할 수 있습니다. AWS CodePipeline과 AWS CodeDeploy를 함께 사용하여 지속적인 배포 솔루션을 구성 할 수 있습니다. AWS에서의 DevOps의 상세 내용에 대해서는 AWS DevOps 페이지를 참고 해주시길 바랍니다.

 

위에서 설명한 마이그레이션 패턴은 종종 SaaS 환경에 추가 구성 계층을 추가한다는 점에 주의 해야 합니다. 테넌트 인프라를 격리 한 경우 해당 테넌트에 대한 고유 한 구성이 있을 수도 있습니다. 이러한 구성 변형은 DevOps 라이프 사이클에서 참조 할 수 있는 저장소에 캡처, 버전 화 및 저장 되어야 합니다. 이는 SaaS 환경이 반복 가능하고 안정적인 프로세스로 구축 되도록 하는 데 필수적입니다.

 

미터링 기기

SaaS 환경에서는 미터링을 결코 간과해서는 안됩니다. 미터링 데이터는 테넌트가 인프라 리소스를 어떻게 소비할지를 이해하는 것이 핵심입니다. 이 데이터는 종종 최적화에서 제품 계층화 전략에 이르기까지 모든 것에 영향을 줄 수 있는 서로 다른 다운 스트림 의사 결정을 제공합니다.

 

선택한 마이그레이션 모델이 측정 옵션에 영향을 줄 수 있습니다. 완벽한 사일로 환경에서는 주어진 테넌트와 어떤 리소스가 연결되어 있는지 결정 하기 위한 명확한 경계가 있습니다. 그러나 공유 인프라가 있는 경우 테넌트 소비를 계측 할 수 있는 방법에 대해 더 많은 생각을 해야 합니다.

 

AWS는 미터링 전략을 보완하는 데 사용할 수 있는 다양한 모델을 제공합니다. 연결된 계정에서 태그 지정, 리소스 그룹화 및 식별에 이르기까지 모든 것을 사용할 수 있습니다. 마이그레이션 작업 초기 단계에서 미터링 전략을 수립하면 비즈니스에 유용한 데이터를 캡처 하기 위해 미터링 모델이 어떻게 진화 해야 하는지 결정하는 데 도움이 됩니다.

 

인프라 프로파일 재검토

어떤 특징이든 관계없이 마이그레이션은 애플리케이션의 인프라 프로필을 다시 검토 할 수 있는 기회입니다. SaaS 로의 전환과 새로운 AWS 인프라 구성의 가용성은 솔루션에 새로운 차원의 규모와 가용성을 제공 할 수 있는 자연스러운 기회를 제공합니다. 또한 이전 환경에 의해 이전에 제한되었던 새로운 기능을 활성화 할 수도 있습니다.

 

AWS로 마이그레이션 할 때 고려해야 할 새로운 기술 및 운영 옵션이 많이 있습니다. AWS에서 지원하는 컴퓨팅, 스토리지, 스케일 및 가용성 모델은 솔루션을 위한 새로운 설계 및 아키텍처의 영역을 만들 수 있습니다. AWS로 전환하면 솔루션의 성능 및 비용 프로필을 최적화하는 데 사용할 수 있는 새로운 다이얼 및 Nobs가 도입되며, 솔루션 성능과 비용 프로파일의 최적화에 사용 됩니다.

 

운영상 조직은 이 마이그레이션을 더 많은 관리, 규모 및 가용성 부담을 AWS로 전환 할 수 있는 기회로 사용함으로써 자체 SaaS 애플리케이션에 더 많은 시간과 에너지를 집중할 수 있는 리소스를 확보합니다.

 

여기서 중요한 점은 마이그레이션은 비즈니스 혁신에 관한 것입니다. 기술, 운영 및 문화적 변화에 따라 환경을 강화하여 SaaS 기반을 확고히 하고, 기술과 사고 방식을 장기적인 민첩성 목표에 맞추는 방식으로 SaaS를 시작하는 것입니다.

 

이 블로그 게시 글에서는 디자인이나 아키텍처를 처음부터 변경하지 않고 애플리케이션을 SaaS로 마이그레이션하는 방법을 찾는 데 중점을 두었습니다. 이 시리즈의 2 부에서는 마이그레이션이 애플리케이션 아키텍처 및 디자인의 기본 사항을 재고 할 수 있는 기회로 사용되는 시나리오를 살펴 봅니다. 이 접근 방식은 애플리케이션 설계의 모든 측면을 재구성하고 SaaS 솔루션의 규모, 가용성 및 민첩성 영역을 향상시키기 위해 새로운 모델에 맞게 조정할 수 있습니다.

 

원문 URL: https://aws.amazon.com/jp/blogs/apn/migrating-applications-to-saas-a-minimally-invasive-approach/

 

 

** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.