1. 마이크레이션 전략
가장 일반적인 6가지 애플리케이션 마이그레이션 전략은 다음과 같습니다.
1. 리호스팅 — “리프트 앤 시프트”
많은 초기 클라우드 프로젝트는 클라우드 네이티브 기능을 사용하여 새로운 순 개발로 전환되지만, 조직이 비즈니스 사례를 충족하기 위해 마이그레이션을 신속하게 확장하려고 하는 대규모 레거시 마이그레이션 시나리오에서는 대부분의 애플리케이션이 재호스팅됩니다. 예를 들어, GE Oil & Gas는 클라우드 최적화를 구현하지 않더라도 리호스팅을 통해 약 30%의 비용을 절감할 수 있다는 사실을 발견했습니다.
대부분의 리호스팅은 도구(예: AWS VM 가져오기/내보내기, Racemi)를 통해 자동화할 수 있지만, 일부 고객은 레거시 시스템을 새로운 클라우드 플랫폼에 적용하는 방법을 배울 때 수동으로 수행하는 것을 선호합니다.
또한 애플리케이션이 이미 클라우드에서 실행 중인 경우 최적화/재설계하기가 더 쉽다는 사실도 발견했습니다. 조직에서 더 나은 기술을 개발할 수 있기 때문이기도 하고, 애플리케이션, 데이터 및 트래픽 마이그레이션이라는 어려운 부분이 이미 이루어졌기 때문이기도 합니다.
2. 리플래포밍-“리프트 팅커 및 쉬프트”
여기서는 가시적인 이점을 얻기 위해 몇 가지 클라우드(또는 기타) 최적화를 할 수 있지만, 그렇지 않으면 애플리케이션의 핵심 아키텍처를 변경하지 않을 수 있습니다. Amazon RDS(Amazon Relational Database Service)와 같은 Database-as-a-Service 플랫폼으로 마이그레이션하거나 애플리케이션을 Amazon Elastic Beanstalk와 같은 완전히 관리되는 플랫폼으로 마이그레이션하여 데이터베이스 인스턴스 관리에 소요되는 시간을 줄일 수 있습니다.
당사와 함께 일하는 대형 미디어 회사는 사내에서 실행한 수백 대의 웹 서버를 AWS로 마이그레이션했으며, 이 과정에서 WebLogic(비싼 라이센스가 필요한 Java 애플리케이션 컨테이너)에서 오픈 소스 동등한 애플리케이션인 Apache Tomcat으로 이동했습니다. 이 미디어 회사는 AWS로 마이그레이션함으로써 얻을 수 있는 절감 효과와 민첩성 덕분에 수백만 개의 라이센스 비용을 절감했습니다.
3. 재구매 — 다른 제품으로 이동
가장 일반적으로 구매는 SaaS 플랫폼으로의 전환으로 간주됩니다. CRM을 Salesforce.com으로, HR 시스템을 Workday로, CMS를 Drupal로 옮기는 것 등입니다.
4. 리팩토링 / 리아키텍팅 — 일반적으로 클라우드 네이티브 기능을 사용하여 애플리케이션 설계 및 개발 방법
이는 일반적으로 애플리케이션의 기존 환경에서 달성하기 어려운 기능, 확장성 또는 성능을 추가해야 하는 강력한 비즈니스 요구에 의해 주도됩니다.
민첩성을 향상시키거나 비즈니스 연속성을 향상시키기 위해 단일 아키텍처에서 서비스 지향(또는 서버 없는) 아키텍처로 마이그레이션하려고 합니까? 이러한 패턴이 가장 비싼 경향이 있지만, 제품-시장 적합도가 높으면 가장 이로운 패턴이 될 수도 있습니다.
5. Retire— 제거 필요
환경의 모든 항목을 검색했으면 각 기능 영역에 각 응용 프로그램을 소유하는 사용자에게 물을 수 있습니다. 엔터프라이즈 IT 포트폴리오의 10%(20%)가 더 이상 유용하지 않으며, 단순히 끌 수 있습니다. 이러한 절감 효과는 비즈니스 사례를 향상시키고, 팀의 주의를 사람들이 사용하는 것에 집중하지 못하게 하며, 보안해야 하는 영역을 줄일 수 있습니다.
6. Retain — 아무것도 하지 않음
아직 감가상각을 겪고 있거나, 최근에 업그레이드된 응용프로그램의 우선순위를 지정할 준비가 되지 않았거나, 그렇지 않으면 일부 응용프로그램의 마이그레이션을 원하지 않았을 수 있습니다. 비즈니스에 적합한 것만 마이그레이션해야 합니다. 포트폴리오의 중요성이 사내에서 클라우드로 변경됨에 따라 보유해야 할 이유가 줄어들 것입니다.
2. 수평적 확장
IT 자원의 관점에서의 확장은 IT자원을 사용량 요구에 따라 늘리거나 줄일 수 있는 능력을 말합니다.
수형적 확장
- 외부 확장: 자원의 수평적 할당
- 내부 확장: 자원의 수평적 배포
- 클라우드 환경에서의 일반적인 확장의 형태는 수평적 확장입니다.
3. 수직적 확장
- 상향 확장: 더 높은 사양의 IT 자원으로 교체하는 것
- 하향 확장: 더 낮은 사양의 IT 자원으로 교체하는 것
- 교체가 일어날 때 다운 타임이 발생하기 때문에 클라우드 환경에서 수직적 확장은 별로 일반적이지 않습니다.
'24DAY 백엔드' 카테고리의 다른 글
24DAY 백엔드 - 22DAY 웹 소켓 (0) | 2021.02.28 |
---|---|
24DAY 백엔드 - 21DAY 메시지 브로커 (0) | 2021.02.28 |
24DAY 백엔드 - 20DAY 겜색엔진, 아키텍처 패턴 (0) | 2021.02.24 |
24DAY 백엔드 - 19DAY 개발과 설계원칙 (0) | 2021.02.24 |
24DAY 백엔드 - 18DAY 테스팅 (0) | 2021.02.23 |