플랫폼 재구성: 사용자 지정 앱을 클라우드로 이동

지난 십여년 동안 주요 프로그래밍 언어로 제작된 맞춤 개발형 애플리케이션은 거의 모두 플랫폼 재구성할 수 있습니다. 소스 코드 소유자로서 개발자는 애플리케이션이 클라우드 환경에서 실행되는 것을 방해하는 코드의 안티패턴을 찾아 변경할 수 있습니다.

정황상 최소의 노력만 기울여도 되건 완전히 클라우드 네이티브로 가건 다음 두 가지를 이해함으로써 플랫폼 재배치에 대한 이해가 시작됩니다.

1
아래의 성숙 모델에 표시된 것처럼 예정대로 진행될 클라우드와 12 Factor 애플리케이션 디자인의 수준은 모두 다릅니다.
2
각 애플리케이션이나 유사 애플리케이션 그룹에 적합한 전략을 선택하는 것이 성공의 관건입니다.

플랫폼 재구성이란?

플랫폼 재구성은 기존의 기능을 보존하면서도 클라우드에서 실행하기 위해 기존의 플랫폼에서 애플리케이션을 업그레이드하고 거기에 최소 가능 12 요인을 준수하는 것입니다. 종종 애플리케이션 서버 및 관련 데이터베이스 관리 시스템 (RDBMS)을 수평 확장 가능한 서비스로서의 데이터스토어, 경량 오픈소스 소프트웨어 (OSS) 서버, 기타 클라우드 서비스 대 온프레미스같은 수직 확장 기술의 현대화도 포함됩니다. 이런 수준의 노력이 클라우드 컴퓨팅의 기본 혜택만을 돌려줄지언정 모든 애플리케이션에 클라우드 네이티브의 모든 혜택이 필요한 것은 아니므로 일부 애플리케이션에서는 완벽하게 훌륭합니다.



”[Pivotal Cloud Foundry]는 우리의 신속한 전달 능력을 향상시켰습니다... 기존 방식대로 했을 경우 우리는 Chef를 통해 모든 것을 구성했습니다. 우리는 서버를 구축했습니다. 위태로운 빌드 시스템이죠. 어떤 기능을 프로덕션하려면 몇 주씩 걸리기도 했습니다. 지금은 이런 도구 세트로 CI/CD 성능을 쓸 수 있으니 PCF는 과연 제작 과정을 단축시켰습니다. 우린 뭐든지 5분 안에 푸시할 수 있었습니다... 정말 드라마틱한 향상이었어요.”

Philip Glebow
IT 아키텍처 디렉터, Product Architect Gap Inc/GapTech




왜 플랫폼 재구성인가?

낮은 CapEx 및 OpEx

라이센스, 운영, 관리 비용이 비싼 전기능 구성 애플리케이션 서버에서 이전하는 것은 2004년 이래 일관된 시장 트렌드가 되었습니다. 이제 클라우드에 탐을 수 있는 경량 서버는 특히 수년 동안 Apache Tomcat이 장악해온 Java에서는 기준이 되었습니다.

확장성 증가, 공급자 이동성

수직 확장성은 본질적으로 제한되어 있습니다. 클라우드 플랫폼은 몇 초만에 동적으로, 심지어 자동으로 수평 크기를 조정할 수 있습니다. Cloud Foundry같은 오픈 소스 플랫폼은 단일 클러스터에서 250,000개 컨테이너를 실행할 수 있습니다. 그런데 왜 서비스 개념의 인프라스트럭처 (IaaS) 제공업체 한곳으로 고정시키는 걸까요? 현대적 플랫폼의 애플리케이션은 방화벽 안팍에 존재하는 다양한 IaaS 제공업체에 이식할 수 있습니다.

하드웨어 리소스 사용과 비용 최적화

애플리케이션 컨테이너화와 가상화는 하드웨어나 IaaS의 배포 밀도를 증가시켜 시스템 리소스 사용이나 유휴 시간 동안의 할당 취소 또는 재할당을 극대화할 수 있습니다.

향상된 소프트웨어 라이센싱 및 전달 모델

클라우드 플랫폼은 거의 모든 업계의 거물들, 주요 재산, 많은 비즈니스 사용자의 주요 연구개발 투자 분야입니다. 이들 플랫폼은 유틸리티와 가입비가 있는 기존의 소프트웨어 라이센스 모델을 파괴합니다. 또한 클라우드 플랫폼은 클라우드에서 실행해야 하는 수많은 포인트 솔루션을 감소시킵니다.

운영 제어를 유지하면서도 개발자 생산성 증가

많은 클라우드 플랫폼들은 프로그래밍 언어 전반에 사용되는 매우 단순하고 일관된 개발자 도구뿐만 아니라 확장성 모델이 포함된 특별한 핵심 플랫폼 요소들을 기본 서비스로 제공합니다. 개발자들이 셀프 서비스할 경우 플랫폼 전반의 액세스 제어와 감사 내역 사용 환경을 즉시 프로비저닝할 때 운영팀은 소비 매개변수를 설정할 수 있습니다. 그러면 앱 스토어를 사용해 개발자가 소비할 클라우드 서비스를 수집하기 위해 앱 스토어를 사용할 수 있습니다.

DevOps의 일반적인 관리 및 모니터링 도구 사용

현대적 클라우드에는 에이전트 없이도 건강한 관리가 이뤄지며, 핵심 애플리케이션, 서비스, 플랫폼 메트릭스에 대해 거의 실시간으로 통합된 뷰를 제공합니다. 개발자와 운영자는 클라우드 환경에서 동일한 시스템의 상태와 가용 데이터에 대해 함께 이해하게 됩니다.



클라우드 네이티브 완성도 모델
클라우드 네이티브
  • 마이크로서비스 아키텍처
  • API 우선 디자인
클라우드 복원
  • 내결함성 및 복원력 있는 디자인
  • 클라우드 불가지론 런타임 구현
  • 번들형 메트릭스 및 모니터링
  • 자동 관리 오류 테스트
클라우드 친화적
  • 12 Factor 애플리케이션 방법론
  • 수평 확장 가능
  • 고가용성 플랫폼 사용
클라우드 준비 완료
  • 영구적인 디스크 액세스 허용 불가
  • 독립형 애플리케이션
  • 플랫폼 관리형 포트 및 네트워킹
  • 플랫폼 관리형 지원 서비스 사용


[플랫폼 재구성] 고려 시
염두에 두십시오.

지난 십여년 동안 출시된 기성의 상용 소프트웨어는 원래 클라우드 용으로 설계된 것이 아니므로 원 공급업체만이 플랫폼 재구성할 수 있습니다. 클라우드는 오늘날 개발 중인 대부분의 애플리케이션의 궁극적 대상임이 분명하지만 모든 애플리케이션에 지금 당장 클라우드 네이티브 아키텍처가 필요한 것은 아닙니다. 앱의 비즈니스 중요도나 규모가 클수록 클라우드 네이티브 아키텍처를 더 잘 이해하게 됩니다. 반대로 가치를 전해주는 핵심 비즈니스와는 거리가 먼 애플리케이션이 많을수록 플랫폼 재배치만으로도 득을 볼 수 있습니다. 어떻게 해야 적절한 전략을 선택할 있을까요?

자동화 중심이 지속적인 전달형 소프트웨어를 적용하려면 소프트웨어 구축 및 제공 방법을 바꿔야 합니다. 아래 질문에 대답하는 팀들만 클라우드 플랫폼 재배치를 도울 수 있습니다.

비즈니스 추진 요인

비즈니스에 사용자 지정 애플리케이션이 얼마나 중요합니까? 앱이 버틸만한 수준의 위험이며, 변경은 얼마나 자주있습니까? 도메인 전문가가 있습니까?

경제적 추진 요인

앱은 어느 정도 규모의 하드웨어와 소프트웨어 투자를 받을 만합니까? 제시된 예상 결과치에 대해 어느 정도의 플랫폼 재구성 시간대면 적당합니까? 수익 / 비용 절감과 관련해서 어느 정도의 이익 또는 영향을 예상합니까?

기술적 추진 요인

적절한 코드 기반이거나 12 요인이 충돌하는 복잡한 상황입니까? 적절한 프레임워크와 런타임을 사용합니까? 어떤 종류의 작업입니까?

조직적 변경

귀하의 회사는 기능형 사일로를 제거하고 서비스를 구축하고 운영할 자급자족형 팀을 구성할 준비가 되어 있습니까? 변경 관리 프로세스가 직원의 개입없는 배포 파이프라인을 용인할 수 있습니까?

클라우드 네이티브가 되면 (전부는 아니더라도) 12대 원칙들을 대부분 준수해야 합니다. 마이그레이션 애플리케이션의 경우 덜 복잡하므로 플랫폼 재구성에 드는 수고도 덜합니다. 아래 표에는 기존의 엔터프라이즈 애플리케이션과 플랫폼 재구성된 애플리케이션 간의 차이점이 요약되어 있습니다.



플랫폼 재구성된 애플리케이션과 기존의 애플리케이션의 차이
플랫폼 재구성 애플리케이션
기존의 엔터프라이즈 애플리케이션
자동 크기 조정. 크기와 무관한 인프라스트럭처 자동화는 인간의 실수에 따른 중지 시간을 없앱니다. 컴퓨터 자동화는 그와 같은 문제가 전혀 없으며 배포 크기와 상관없이 동일한 규칙을 일관되게 적용합니다. 수동 크기 조정. 수동 인프라스트럭처에는 수동으로 직접 서버, 네트워크, 스토리지 구성을 담당하고 관리하는 운영 직원이 있습니다.
적정 용량. 플랫폼 재구성된 애플리케이션은 애플리케이션에 대한 지속적인 요구를 기반으로 배포 시에 리소스를 동적으로 할당 및 재할당할 수 있습니다. 용량 과다. 전통적인 IT는 애플리케이션 전용의 맞춤형 인프라스트럭처 솔루션 (“눈송이”)을 설계하므로 해당 애플리케이션의 배포가 지연됩니다. 수요 충족분 이상의 확장 여유분이 거의 없는 최저 용량 추정치에 기준했을 때 솔루션은 흔히 용량 과다 상태입니다.
보안 향상. 플랫폼 재구성된 애플리케이션은 애플리케이션, 앱 런타임, 파일 시스템, 내장형 OS 수준에서 무중단으로 패치할 수 있습니다. 롤백은 단순하고 빠릅니다. 일정에 따른 중지 시간. CVE에 반응하고 패치를 적용하려면 조정과 일정에 따른 중지 시간이 필요한데, 보통 운영 시간 이후에 실시합니다. 흔히 변경은 롤백을 곤란하게 만듭니다.
변경 불가 인프라스트럭처. 다양한 환경을 보장한하므로 매번 같은 방법으로 신뢰성 있게 구축되고, 변경할 수 없고, 환경 불일치로 인한 애플리케이션 오류가 크게 감소합니다. 고유한 환경. 운영자는 크기와는 무관하게 올바른 문제 진단에 늦고, 또한 크기와 무관하게 복잡도로 인해 적절한 구현에 실패합니다. 손으로 직접 작성한 코드에는 잠재적으로 인프라스트럭처에 인적 오류가 발생할 가능성이 있습니다.
컨테이너 관리 방식. Docker, RunC, 및 Garden Linux 컨테이너의 앱들은 Google에서 영감을 얻은 BOSH와 250k+ 컨테이너/인스턴스 능력을 갖춘 PCF Elastic Runtime이 완벽하게 관리합니다. 오류는 애플리케이션 인스턴스, 프로세스, 가상 머신, 가용성 영역 레이어에서 자가 치유됩니다. 로컬 OS. 앱은 하드웨어의 OS에서 직접 실행되거나 가상화됩니다. 서버는 상태 저장 가능하고 해당 구성을 유지 관리할 것으로 예상됩니다. 애플리케이션 런타임 수준에서는 전형적으로 고가용성을 가집니다.
자동 DNS, 포트, 라우팅, 크기 조정. 클라우드 환경에서 팀은 세세하게 관리하지 않습니다. 클라우드 제공업체가 라우팅, 크기 조정 등을 포함한 포트 할당을 관리합니다. 수동 구성. DNS, 라우팅, 크기 조정, 포트 할당 등 모든 구성은 수동으로 진행됩니다.


플랫폼 재구성과 Pivotal

Pivotal은 조직의 플랫폼 재구성 평가와 실행을 돕습니다. 심지어 고객을 위해 결과로 초래된 애플리케이션을 플랫폼 상에서 운영하는 것도 돕습니다. 업계 전반의 대기업에서 스타트업에 이르는 모든 규모의 비즈니스는 배포 전에도, 진행 중에도, 그리고 그 이후에도 Pivotal의 소프트웨어, 서비스, 클라우드로의 변환 인도 경험을 신뢰합니다.

Pivotal과 함께 플랫폼 재배치용 대상 애플리케이션을 식별하고 비즈니스에 필요한 수준의 노동과 이익의 상보관계를 조정하십시오.

Agile 방법론을 사용하여 가치 전달 이전에 여러 달 동안 포트폴리오를 분석하고 10주 내에 반복적으로 결과를 제공하는 Pivotal Labs 접근 방식을 이용하십시오.

클라우드에서 애플리케이션 실행 가능해지기 전에 신속하게 실행 가능한 최소 12 요인 개수를 찾아 분명히 언급해 두십시오.

클라우드 네이티브 디자인의 장점이 모두 필요한 앱들은 플랫폼 재구성되어야 하므로 추출 가능하면서도 점증적 마이그레이션과 비즈니스로 이어지는 가치 흐름을 유지하는 모놀리식 접근 방식의 경계를 식별하십시오.

클라우드 네이티브 플랫폼인 Pivotal Cloud Foundry에서 애플리케이션을 배포하고 관리하여 가치 전달 속도를 향상시키십시오.



Pivotal 적용 사례
A top insurance company successfully replatformed, refactoring 10 logical applications of varying complexity during a 10-week engagement with Pivotal. The business also improved application quality by introducing automated testing.
A top healthcare company transitioned from JBoss to Spring Boot / Spring Cloud Config Server and containerized 12-factor applications. The organization eliminated app server setup, increased uptime with dynamic configuration, and increased scalability and 24/7 availability with blue-green deployments—all by only accomplishing approximately 50 percent of the 12 factors.
A top insurance company transitioned from JBoss, replatforming 8-12 simple apps so they could teach themselves how to replatform and later refactor—developing cookbooks for modernization patterns and sharing knowledge.



Pivotal Cloud Foundry
완전 자동화된 셀프 서비스 배포 실시


Spring
Accelerates cloud-native Java application development


Pivotal Labs
팀의 소프트웨어 빌드 방법 변환 - 한 번에 하나의 스토리


플랫폼 재구성 관련 추가 리소스 보기

전체 리소스 보기

Get started with Replatforming
웨비나: 거대 조직 부수기

Watch Now

지금 데스크톱이나 클라우드에서 무료 소프트웨어 시작하기

시작

Build software people love at SpringOne Platform

자세한 정보

Read Next
DevOps