(※ 출처: VM ware 홈페이지)
앞선 클라우드 아키텍처와 클라우드 네트워크에서 클라우드의 전반적인 이해를 도왔다면 이제는 클라우드 환경에서 최적화된 애플리케이션 개발 및 운영 방식에 대해 알아보자
클라우드 네이티브(Cloud Native)
먼저 클라우드 네이티브의 어원을 뜯어보는게 이해하기 쉬울 것이다.
Native란 무엇일까?
우리는 해당 나라 혹은 문화, 사고, 커뮤니티, 언어를 어린 시절부터 자연스럽게 배워서 내재화 한 사람을 네이티브하다고 말한다.
즉, '클라우드 네이티브'는 애플리케이션이 클라우드 환경을 "태생적으로(native)" 고려하여 설계되었음을 의미하며,
더 쉽게 생각하자면 기존의 애플리케이션을 클라우드 환경에 옮긴(migrated)게 아닌 처음부터 클라우드 중심으로 만들어진 애플리케이션이라는게 핵심 개념이다.
우린 앞선 페이지에서 Cloud-Ready에서 Cloud-Friendly를 거쳐 Cloud-Resilient를 지나 Cloud-Native까지 도달한다고 배웠다.
Cloud-Ready에서 인프라의 확장성을 확보하고
Cloud-Friendly에서 확장성을 확보하고
Cloud-Resilient에서 파일의 자동화와 내결함성, 즉 탄력성을 확보하고
Cloud-Native까지 도달하게 되는 것이다.
지금까지의 과정은 Monolith 애플리케이션을 Cloud Native로 전환하기 위한 여정이라고 봐도 무방하다.
핵심 품질 특성
그렇다면 클라우드 네이티브의 핵심 품질 요소는 무엇이 있을까
- 확장성(scalability)
- 탄력성(elasticity)
- 내결함성(Fault Tolerance)
- 민첩성(Agility)
제일 핵심은 Agile이다.
비즈니스는 그대로 두되, 그 안의 서비스를 다시 구축하는것으로
기술적 변화에 탄력적이고 민첩하게 대응 가능한게 핵심 특성이다.
단순히 클라우드에서 동작하는 것이 아니라, 클라우드의 장점을 최대한 활용할 수 있도록 구조를 변경하는데,
구조를 변경하기 위해 MSA, Serverless, Kubernetes(이하 K8s)등의 최적화 아키텍처를 적용시킨다
그리고 해당 과정을 Re-architecturing이라고 한다.
[참고]
- Refactoring(리팩토링)
- 기존 애플리케이션의 구조를 유지하면서 코드 및 인프라를 최적화
- 애플리케이션의 핵심 로직은 그대로 유지하면서, 클라우드 환경에서 더 안정적으로 동작하도록 개선
- Re-architecting(리아키텍처링)
- 애플리케이션을 근본적으로 다시 설계하여 클라우드 네이티브 아키텍처로 전환
물론 해당 과정을 점진적으로 접근해야 성숙도와 완성도가 상승한다
Re-architecting은 전환 비용도 높고 실패도 많이 하기 때문.
클라우드 네이티브 애플리케이션의 이해
Cloud Native Application이 가져가야할
아키텍처 | 기술 | 프로세스 측면 에 대해서도 알아보자
아키텍처 측면
- Inner(서비스 내부 구조와 관련된 아키텍처)
- 어떻게 나눌지, 비즈니스의 관점
- 문제의 격리
- 단순화 및 책임 명확화
- outter(서비스 간 상호작용 관련된 아키텍처)
- 서비스간의 연계
- 장애나 대응 복구체계
- 효율적으로 리소스 관리왜 inner/outer로 나눴을까?
해야할 역할을 명확히 나눈것!
✔ Inner Architecture(내부 구조) → 애플리케이션의 핵심 로직을 어떻게 구성할지 결정
✔ Outer Architecture(외부 구조) → 클라우드 인프라에서 어떻게 배포, 확장, 운영할지 결정
기술적 측면
- 인프라의 탄력성과 기술의 개방성
- 컨테이너의 안정적 배포
- 컨테이너의 상태체크/자동복구
프로세스 측면
- 개발/운영의 연속성 및 자동화
- 다운도되고, 연결해야할 기술도 늘어남 → 이에따라 사람이 하나하나 처리하기 힘들어짐
- 따라서 자동화시켜야함(CI/CD)
- Devops 체계로 사람이 변화해야한다
MSA(Microservices Architecture)의 이해
MSA와 클라우드 네이티브는 서로 깊이 연관된 개념이다.
앞선 글에서 클라우드 네이티브로 구조가 변경되기 위해 MSA 아키텍처를 사용한다고 하였다.
MSA는 클라우드 네이티브 아키텍처를 실현하는 중요한 구성 요소 중 하나로 먼저 Monolith(덩어리)와 MSA의 차이점에 대해 알아본다면 더 쉽게 이해할 수 있다.
해당 그림이 Monolithic과 MSA의 전부이다.
Monolithic
Monolith는 덩어리라는 뜻으로 거대한 하나의 애플리케이션을 의미한다.
애플리케이션의 모든 기능이 하나의 코드베이스에서 개발되고, 배포되는 구조로서
단일 코드베이스, 단일 배포, 하나의 데이터베이스 등을 특징으로 꼽을수있다
✅ 당연하게도 개발이 단순하고 배포도 쉽고 데이터의 일관성 또한 유지하기 쉽지만,
❌ 규모가 커질수록 유지보수가 어렵고, 배포속도도 느리며, 장애가 발생했을때 모든 기능이 마비될 위험이 있다.
MSA
MSA는 Monolithic과 반대로 다루기 어려운 큰 구조를 작은 단위로
나눠서 개발하고, 실행하고 운영하는 정 반대의 개념이라고 볼 수 있다.
divide and conquer 개념으로 구조를 나눠 더 많으 쓰는 기능은 인스턴스를 늘려 유연성있게 문제를 해결한다.
독립적인 서비스와 분산 시스템, 각 서비스별 데이터 관리를 특징으로 꼽을 수 있다.
✅ 작은 단위로 나눠서 개발하니 당연하게도 확장성이 우수하고 유지보수가 용이하며, 시장 변화나 고객의 요구에 빠르게 대응이 가능하다.
또한, 한 기능이 장애가 발생했을때 다른 인스턴스로 대체하며 서비스 중단을 막을 수 있는 장점이 있다.
❌ 단, 서비스가 많아 서로 통합 소통하는데 어려움이 있어 서비스간의 통신의 부담이 있고, 배포 자동화가 필수적이라 (CI,CD,쿠버네티스)등의 추가적인 운영이 필요하다.
MSA의 구성
그렇다면 MSA의 내부/외부 구성은 어떻게될까
Inner
- 업무중심의 내부 아키텍처 구성
- 고객의 요구 사항에 맞게 서비스 내부의 구조, 로직, 인터페이스 설계
Outer
- 기술중심의 외부 아키텍처 구성
- 지능적으로 빌드, 배포, 운영이 가능하도록 환경 설계
쉽게 이해하자면
아파트를 지을때 아파트 평수, 인테리어 화장실의 갯수 등이 Inner Architecture로 볼수있고,
복도, 엘레베이터, 수도관, 관리실 등 아파트의 주변환경을 구성하는게 Outer Architecture이라고 이해하면 편하다.
Outer Architecture의 핵심요소
outer architecture는 6가지 핵심요소를 가진다.
컨테이너 기반의 빌드/배포 구조
- 빌드 과정 자체가 표준화
REST API 기반 표준 인터페이스
- 서비스간 느슨한 구조 연결
복제 기반의 고가용성 구조
- 한명이 하던일을 여러명이 나눠하면서 특정 복제품이 장애가 발생하더라도 전체로 확산방지
반 중앙화/정규화 기반 분산 데이터 구조
- 서비스별로 자기 데이터를 가짐으로써 데이터 변화로 인한 서비스간 영향 문제 해결
오픈소스/최신 기술의 리스크 회피/검증 구조
- 발생할 수 있는 문제를 운영환경에서 사용시 검증 및 회피할수있는 구조로 개선
PaaS 기반의 지능화된 운영 방식
- 지능화, 자동화(CI/CD)
이렇게,
모놀리식이 아닌 MSA로,
애플리케이션을 컨테이너(Docker) 로 패키징하여 배포,
오케스트레이션 Kubernetes을 활용한 자동화된 배포&스케일링,
DevOps와 CI/CD를 통한 지속적인 통합 및 배포의 자동화
를 통해 클라우드 네이티브 애플리케이션을 만들 수 있게 된다.
물론,
애플리케이션의 라이프 사이클 관리 복잡도가
증가하고 데이터의 일관성 보장이 어려우며, 적응 기술 관리가 쉽지 않지만 시대적 대세이며 기업의 서비스 혁신과 경쟁력 강화에 기여하므로 필수적인 기술이라고 볼 수 있다.
CI/CD
DevOps
Container
Kunbernetes
Orchestration
위 용어와 기술들은 다음에 다시 자세하게 다루도록 하자
