Intro
예전에 CNCF 재단에서 권장하는 Cloude Native 환경을 만들기 위한 landscape에 대해 살펴본 적이 있습니다. 주기적으로 업데이트를 하는 자료이기도 하고, 클라우드 기반의 어플리케이션을 구축하기 위해 어떤 제품을 선택해서 조합하여 사용할 수 있을지도 한눈에 파악할 수 있어 가끔 살펴보곤 했습니다.
오늘은 이 Cloud Native, CNCF재단, Cloud Native Trail Map와 함께, Landscape에서 확인할 수 있는 몇가지 대표적인 소프트웨어에 대해서 소개하고자 합니다.
Cloud Native (클라우드 네이티브)
가상화 기술이 발전하고 Cloud 환경의 발전이 가속화됨에 따라 애플리케이션의 구성 역시 Cloud 환경에 맞게 설계되어야 할 필요성을 갖게됩니다. Cloud Native는 클라우드의 이점을 최대로 활용할 수 있도록 애플리케이션을 구축하고 실행하는 접근 방식을 말합니다. 이런 애플리케이션은 클라우드 플랫폼에서 신속하게 구축 및 구현되고, 클라우드 전반에 걸쳐 민첩성과 복원력, 이식성을 향상시킵니다.
Cloud Native 패턴의 4가지 주요 원칙은 'Devops', Continuous Delivery(*CD)', 'Microservices', 'Containers'입니다. 4가지 모두 자동화를 통해 애플리케이션 개발 및 운영의 효율성 향상이라는 동일한 목표를 갖고 있습니다.
Cloud Native의 4가지 주요 원칙
DevOps
DevOps는 애플리케이션에 대한 빌드/테스트/릴리즈와 같은 작업을 더 빠르고, 일관되게 이루어 질 수 있도록 개발자와 IT운영자가 상호협력을 하는 문화/환경을 의미합니다. 주로 DevOps환경을 채택한 팀의 경우, 개발과 운영을 한개의 팀에서 같이하는 경우를 많이 볼 수 있습니다.
Continuous Delivery (CD)
Continuous Delivery(CD)를 통해 애플리케이션을 빠르고, 안정적이며, 빈번하게 출시할 수 있으며, 위험은 줄일 수 있습니다.
CI(Continuous Integration)/CD(Continuous Delivery)
CI(지속적인 통합): 개발자를 위한 자동화 프로세스를 의미합니다. CI를 성공적으로 구현할 경우, 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되고, 테스트에 통과하면 코드를 통합해 공유 repository에 저장합니다.
CD(지속적인 서비스 제공, 지속적인 배포로도 쓰임): 작업한 코드 및 변경사항들은 테스트를 거쳐 repository에 업로드되고 실 서비스 배포로 릴리즈까지 자동화하는 것을 의미합니다.
Micro-services (*MSA)
Micro-services는 자체적으로 실행되고, HTTP API를 통해 통신하는 작은 독립적인 서비스 집합으로 애플리케이션을 구축하기 위한 아키텍처 접근 방식입니다.
Containers
Containers는 단일 서버를 하나 이상의 '컨테이너'라는 단위로 동적 분할해서 경량화된 가상화환경을 제공합니다. VM(Virtual Machines)에 비해 효율성과 속도를 모두 제공합니다. 컨테이너에 대한 자세한 설명은 여기를 참고해주세요.
컨테이너(Container)와 도커 (Docker)
컨테이너에 대해서 알아보기 전에 가상화를 보고 오자 컨테이너 이전의 가상화 일반적으로 쉽게 사용한 가상화기술로 가상머신(Virtual Machine)이 있다. 가상머신은 운영체제 인스턴스 하나를 구
dalsacoo-log.tistory.com
Cloud Native을 통해 얻을 수 있는 주요 이점
- 자동화를 통한 자체 인프라 관리: 가상화 플랫폼을 기반으로 하는 임시 자동화를 넘어 애플리 케이션 계층까지 전체 인프라의 조정, 관리 및 자동화에 초점을 맞춥니다.
- 신뢰할 수 있는 인프라 및 애플리케이션: 클라우드 네이티브 방식을 통해 예기치 않은 이벤트나 장애로부터 훨씬 쉽고 빠르게 복구할 수 있습니다.
- 복잡한 애플리케이션에 대한 더 깊은 인사이트: Cloud Native툴은 애플리케이션을 쉽게 감시하고 디버그할 수 있습니다. 감시 로그를 통해 상태 관리, 모니터링 및 알림을 시각화할 수 있도록 지원합니다.
- 보안: 개발자가 사후가 아닌 처음부터 애플리케이션에 보안을 구축할 수 있게합니다.
- 보다 효율적인 리소스 사용: 컨테이너는 전체 시스템보다 무게가 가볍습니다. 컨테이너에 애플리케이션을 배치하면 리소스의 활용도가 더 높아집니다.
CNCF와 Cloud Native Architecture
CNCF
CNCF는 클라우드 네이티브로 전환할 수 있는 오픈소스 기술들을 추진하고 관리하는 재단으로, Linux Foundation의 산하단체입니다. 2021년 9월 기준, 134K+명의 CNCF 프로젝트 컨트리뷰터가 있으며, 727개의 기업에서 CNCF 멤버로 참여하고 있습니다.
Who we are | Cloud Native Computing Foundation
The Cloud Native Computing Foundation (CNCF) hosts critical components of the global technology infrastructure. CNCF brings together the world’s top developers, end users, and vendors and runs the…
www.cncf.io
Cloud Native Architecture
Cloud Native Architecture는 애플리케이션이 클라우드 내부의 분산환경에서 탄력적으로, 수평 확장 가능한 디자인 패턴을 기반으로 설계할 수 있도록 도와줍니다.
아래의 그림은 CNCF 재단에서 발표한 Cloud Native Architecture로, 4개의 계층으로 이루어져있습니다. 각각의 계층은 독립적이며, 계층 간에 의존성을 가지면 안됩니다. 아래의 그림의 "row"부분이 이런 계층을 보여줍니다.
(몇몇 자료를 보면, 과거에는 5개 계층으로 Infrastructure를 최하단 계층으로 제시한 것으로 보입니다. 하지만, 2021년 9월 현재 CNCF Cloud Native Landscape의 최하단 계층에서 Infrastructure가 빠져있어 제외하였습니다. 혹시 해당부분에 있어 잘 알고계신 분이 계시다면 의견주시면 감사하겠습니다.)
첫 번째 계층은 기반 계층으로써, infra를 provisioning할 수 있는 툴이 있습니다.
그 다음으로 애플리케이션을 실행하고 관리하는데 필요한 툴이 추가된 Runtime계층과 Orchestration & management계층이 있습니다.
맨 위의 Application definition & development계층의 경우, 데이터베이스, 이미지 구축 및 CI/CD 도구와 같은 애플리케이션을 정의하고 개발할 수 있는 툴이 있습니다.
Infra에서부터 시작해서 각 계층에 따라 실제 앱에 더 가까이 다가간다는 것을 이해할 수 있습니다.
위의 그림을 보게되면, 전 계층에서 실행될 수 있는 2개의 "column"인 Platform과 Observability & analysis가 있는데요. 이 부분은 밑에서 다루겠습니다.
Cloud Native Landscape
CNCF는 Cloud Native 참조 아키텍처 영역별로 전체적인 구성요소들을 정리한 Landscape를 제공하여 Cloud Native 기술 전체 호환성을 확보하는 방안을 제시합니다. 최하단 계층인 Special 계층부터 Application 계층까지 각각의 영역별로 살펴보도록 하겠습니다.
CNCF Cloud Native Interactive Landscape
This landscape is intended as a map through the previously uncharted terrain of cloud native technologies. There are many routes to deploying a cloud native application, with CNCF Projects representing a particularly well-traveled path.
landscape.cncf.io
그 전에 이 그림을 보는 방법을 설명드리자면,
- 큰 상자 프로젝트는 CNCF-hosted 오픈소스 프로젝트입니다. 연한 파란색과 보라색프레임은 아직 incubation 단계이고, 일부 진한 파란색 프레임은 졸업한 프로젝트입니다.
- 작은 흰색 상자의 프로젝트는 오픈소스 프로젝트 입니다.
- 회색 상자에 담긴 제품은 독점 제품입니다.
Special
Special에서는, Kubernetes의 인증된 서비스 프로바이더와 트레이닝 파트너사들을 확인할 수 있습니다.
Provisioning
Provisioning 계층은 Cloud Native 애플리케이션이 만들어지는 기반을 구축하고, 강화하는 데 필요한 툴들을 말합니다.
인프라 생성, 관리 및 구성 자동화에서부터 컨테이너 이미지 검색, 서명 및 저장에 이르기까지 모든 것을 다룹니다.
또한 policy를 정하거나 적용하고, 애플리케이션 및 플랫폼에 인증을 빌드하고, secret 배포를 처리할 수 있는 도구를 제공해서 보안 공간으로도 확장됩니다.
- Automation & configuration: DevOps 매니지먼트를 위한 자동화 및 구성 툴로, Chef, Ansible, Terraform 등이 여기에 속합니다.
- Container Registry: 앱의 실행 파일을 저장하는 툴로, Docker Hub, Habor 등이 여기에 속합니다.
- Security and compliance: 서로 다른 보안 영역을 처리하는 툴로, OPA(Open Policy Agent), Falco, Notary 등이 여기에 속합니다.
- Key Management: 인증된 사용자만 애플리케이션에 액세스할 수 있도록 암호화 기능을 지원합니다. Vault(다양한 유형의 키를 관리할 수 있는 일반적인 키 관리 도구), Spiffe, OAuth2 등이 여기에 속합니다.
Runtime
Runtime 계층은, 애플리케이션을 실행하는데 필요한 모든 툴입니다. CNCF Cloud Native 환경에서 Runtime은 특히 Container형 애플리케이션에 중요한 구성요소(run, remember, communication에 필요한 구성 요소)에 초점을 맞추는 지점에서 정의됩니다.
- Cloud Native Storage: Container형 애플리케이션에 대해 가상화된 디스크 또는 퍼티스턴스를 제공합니다. 스토리지의 경우 애플리케이션의 영구 데이터가 저장되는 곳으로, 흔히 퍼시스턴스 볼륨이라고 불립니다. 앱이 안정적으로 작동하려면 쉽게 액세스할 수 있어야하고, 데이터베이스/메시지 등을 저장해 앱이 재시작될 때 사라지지 않도록 해야합니다.
대표적인 프로젝트로 Minio(객체 스토리지를 위한 S3호환 API를 제공하는 인기있는 프로젝트), CSI, Velero(Kubernetes 클러스터 뿐 만 아니라 애플리케이션에서 사용하는 영구 데이터도 모두 백업 및 복원하는 프로세스를 간소화할 수 있는 프로젝트) 등이 있습니다. - Container Runtime: 컨테이너화된 응용 프로그램을 실행하는 소프트웨어입니다. 런타임이 없으면 컨테이너 이미지만 갖게되며, 컨테이너 내에서 앱을 실행하고 필요한 리소스를 제공합니다.
Standard container runtime을 구현한 대표적인 프로젝트로 Containered, CRI-O이 있습니다.
Container를 VM으로 실행할 수 있는 Kata와 같은 기술도 있고, gVisor와 같은 제품은 컨테이너와 OS사이에 추가적인 보안 계층을 제공합니다. - Cloud Native Network: 컨테이너는 Cloud Native Network를 통해 분산시스템의 노드(머신 또는 프로세스)와 연결되어 통신합니다. Kubernetes환경에 적합한 컨테이너 네트워크를 선택하는 것이 중요하며, 선택할 수 있는 툴도 많습니다.
Weeve Net, Antrea, Calico 및 Flannel은 모두 효과적인 오픈소스 네트워킹 계층을 제공합니다.
Orchestration & Management
보안 및 policy를 준수하는 표준에 따라 인프라 프로비저닝을 자동화(*Provisioning 계층)하고, 앱 실행에 필요한 툴(*Runtime 계층)을 설정하면, 엔지니어는 애플리케이션을 조정하거나 관리하는 방법을 찾아야합니다.
Orchestration & Management 계층은 컨테이너화된 모든 서비스(앱 구성 요소)를 그룹으로 관리하는 방법을 다룹니다. 기본적으로 확장가능한 Cloud Native 애플리이션은 이 계층에서 자동화와 복원력에 의존합니다.
- Scheduling & Orchestration: 컨테이너 클러스터를 배포 및 관리하기 위한 Orchestration과 Scheduling을 통해, 복원성있고 느슨하게 결합되며, 확장 가능합니다.
대부분의 Gmail이나 Netflix와 같은 대규모 애플리케이션은 분산 애플리케이션을 구성하는 여러 시스템에 분산됩니다. 이를 위해 서로 다른 시스템에서 실행되는 모든 구성 요소를 관리할 수 있는 소프트웨어인 클러스터 OS가 필요한데, 오케스트레이션 툴이 이를 충족합니다.
대표적으로 Kubernetes, Docker Swam, Mesos 등이 여기에 속하며, 이를 이용해 컨테이너 및 운영 환경을 관리합니다. - Coordination & Service Discovery: 애플리케이션이 여러 개별의 서비스로 구성되면서, 협업을 위해 네트워크를 통해 통신합니다. 이를 위해 필요할 때 서비스가 서로 찾을 수 있도록 네트워크 내의 서비스를 추적하는 툴을 제공합니다.
대표적인 제품으로 CoreDNS, etch, Zookeeper, Eureka 등이 있습니다. 이중 CoreDNS는 Kubernetes안에도 내장되어 있으며, 클러스터 DNS역할을 할 수 있는 범용적인 권한을 갖는 DNS 서버입니다. - Remote Procedure Call (RPC): 한 노드의 서비스가 네트워크를 통해 연결된 다른 노드의 서비스와 서로 통신할 수 있도록 하는 기술입니다. RPC를 사용하면 커넥션을 위한 코딩이 쉬워지고, 네트워크 계층과 서비스 간 통신이 매우 효율적으로 사용될 수 있습니다. 대표적으로 gRPC가 있으며, CNCF 프로젝트로 채택되었습니다.
- Service Proxy: 지정된 서비스에서 들어오거나 나가는 트래픽을 가로채 일부 로직을 적용해, 다른 서비스에 전달하는 도구입니다. 트래픽을 개별 애플리케이션에 전달하는 로드밸런서 처럼 간단할 수 있으며, 복잡하게 할 수도 있습니다. 유명한 프로젝트로 Envoy, Contour, NGINX 등이 있습니다.
- API Gateway: API Gateway는 앱 사용자를 위해 공통 UI를 갖춘 단일 진입 지점을 제공합니다. 애플리케이션 간 요청 수 제한 또는 인증과 같은 주요기능을 중앙에서 관리하도록 합니다. 또한 애플리케이션 간의 상호작용을 중앙에서 제어(제한 또는 활성화)하고 이를 추적하여 과금, 인증, 서비스 남용을 방지할 수 있습니다. 유명한 프로젝트로 Kong, Mulesoft 등이 있습니다.
- Service Mesh: Service mesh는 서비스 간 트래픽을 관리합니다. 이를 통해 플랫폼 운영 수준에서 코드 변경없이 클러스터 내에서 실행되는 모든 서비스에서 안정성, 관찰성 및 보안 기능을 추가할 수 있습니다. (Control plane 쪽의 제어만 들어가는 것으로 보임) 유명한 프로젝트로 Linkered, Consul, Istio 등이 있습니다.
App Definition and Development
이름에서 알 수 있듯이 App Definition and Development 계층은 엔지니어가 앱을 구축하고 기능을 수행할 수 있도록 하는 도구에 초점을 맞춥니다. 위에서 설명한 계층들의 경우, 모두 안전하고 신뢰할 수 있는 환경을 구축하고, 필요한 모든 앱 의존성을 제공하는 것과 관련이 있었습니다. 이 계층에서는 아래의 4가지를 확인할 수 있습니다.
- Database: 데이터 저장을 보장하고, 인증된 사용자만 액세스 할 수 있으며, 데이터를 검색할 수도 있습니다. 대표적으로 Postgres, MySQL, Redis 등이 있습니다.
- Streaming & Messaging: 애플리케이션이 메시지(이벤트 및 스트림)을 주고받을 수 있습니다. 네트워킹 계층이 아니라 메시지를 Queue에 넣고 처리하며, 개별 서비스는 메시징 서비스에 연결하여 이벤트를 게시하거나 메시지를 읽거나 혹은 둘다 수행합니다. 대표적인 프로젝트로 Spark, Kafka, RabbitMQ, Nats 등이 있습니다.
- Application Definition & Image Build: 컨테이너 이미지를 구성, 유지보수 및 실행하는데 도움을 주는 광범위한 서비스로, 개발 중심 툴과 운영 중심 툴로 나눌 수 있습니다. 개발 환경의 속도를 높이거나 단순화하거나, 새로운 Kubernetes extention을 작성하는 프로세스를 단순화함으로써 Kubernetes에 대한 경험을 최적화 할 수 있습니다. 유명한 프로젝트로 Helm, Buildpacks 등이 있습니다.
Helm은 Kubernetes유저가 많은 3rd-party앱을 배포하고 커스터마이즈할 수 있게 합니다. 또한, 직접 만든 앱의 배포 또한 커스터마이즈 할 수 있을 만큼 유연합니다.
BuildPacks의 경우, 응용프로그램 코드를 컨테이너에 빌드하는 프로세스를 단순화하는 것을 목표로 합니다. - Containuos Integration & Delivery (CI/CD): CI는 코드를 즉시 구축 및 테스트하여 배포가능한 artifact를 생성하도록 함으로써 코드변경을 자동화합니다. CD는 한단계 더 나아가 배포 단계를 통해 artifact를 푸시합니다.
시중에 가장 널리 사용되는 CI툴인 Jenkins와 같은 일부 기존 툴은 Kubernetes 생태계에 더 잘맞도록 개편되었습니다. Flux와 Argo와 같은 제품은 GitOps라는 새로운 CD방식을 개척했습니다. 대표적인 프로젝트로 Argo, Flagger, Spinnaker, Jenkins가 있습니다.
Observability and Analysis
장애를 최대한 신속하게 식별하고 해결함으로써 장애의 영향을 줄일 수 있도록 지원합니다. Observability and Analysis 범주는 모든 layer를 가로지르고 모니터링 하므로 특정 레이어에 내장되지 않습니다.
- Monitoring: 메트릭 수집을 위한 모니터링 솔루션(RAM 가용성과 같은 수치 시스템 매개 변수)으로, Datadog, Prometheus, Thanos 등이 있습니다.
- Logging: 이벤트 로그를 수집하기 위한 로깅 툴로, ElasticSearch & fluentD, Splunk 등이 있습니다.
- Tracing: 모니터링보다 한 단계 더 진전되어 사용자 요청 전파를 모니터링합니다. 이는 Service Mesh의 맥락에서 관련이 있으며, Open Tracing, Zipkin 등을 통해 응용프로그램 디버깅에 도움을 줄 수 있습니다.
- Chaos engineering: 운영 환경에서 소프트웨어를 테스트하여 약점을 식별하고 서비스 제공에 영향을 미치기 전에 이를 해결하기 위한 도구입니다.
Cloud Native Trail Map
더불어, Cloud Native Trail Map을 제공하여 Cloud Native 기술 적용에 대한 추천 경로도 제공합니다. 아래의 그림을 참고해서 애플리케이션을 Cloud Native 환경으로 전환하는데 도움을 받으셨으면 좋겠습니다.
참고 및 출처
https://ageofblue.tistory.com/entry/Cloud-Native-Architecture
https://github.com/cncf/landscape
cloud native landscape: https://thenewstack.io/an-introduction-to-the-cloud-native-landscape/
provisioning layer: https://thenewstack.io/the-cloud-native-landscape-the-provisioning-layer-explained/
runtime layer: https://thenewstack.io/the-cloud-native-landscape-the-runtime-layer-explained/
orchestration & management layer: https://thenewstack.io/the-cloud-native-landscape-the-orchestration-and-management-layer/
application definition & development layer: https://thenewstack.io/the-cloud-native-landscape-the-application-definition-and-development-layer/
'개발 > Docker & Kubernetes' 카테고리의 다른 글
| 컨테이너(Container)와 도커 (Docker) (0) | 2020.12.28 |
|---|---|
| Cloud Computing, 특징, 서비스 유형, 배치 모델 (0) | 2020.12.20 |
| [k8s study] 15. 쿠버네티스 인프라 관리 (0) | 2020.11.27 |
| [k8s study] 8. 모니터링과 로깅 (0) | 2020.10.06 |
| [k8s study] 4. 신뢰성있는 컨테이너 네이티브 애플리케이션 구현 (0) | 2020.08.29 |
댓글