Introduction to cloud-native applications

 

📚 읽은 글.

https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/introduction

Introduction to cloud-native applications

 

---

 

TL;DR

MS 에서 제공하고 있는 이 문서는 ☁️ cloud-native application 이 무엇인지 정의하고 소개하기 위해, 구어체 형식으로 내용을 전달하고 있습니다. 내용을 요약하면 아래와 같습니다.

 

• 현대의 cloud 환경에서 유연한 applications 를 만들기 위한 구조를 작성했고, 이는 cloud-native 라는 용어로 정착되었습니다.
• 과거의 monolithic 구조와 달리, cloud-native 구조는 작게 쪼개진 microservices 들의 조합으로 동작하며, 각각의 microservices 들은 완전히 독립적으로 동작합니다.
• 아래의 속성들을 가지는 application 을 cloud-native 하다고 할 수 있습니다.
  • 확장성 (scalability), 가용성 (availabilty), 탄력성 (resiliency)
  • 느슨하게 결합된 (loosely-coupled) microservices
  • 빠른 요구사항 반영 (speed & agility)
  • 5가지의 요소로 구성되는 cloud infrastructure 의 기초
    • Modern Design
    • Microservices
    • Containers
    • Backing Services
    • Automation
• Cloud-native system 은 container, container ochestrator, backing services 를 통해 달성될 수 있습니다.
• 그러나 모든 application 이 cloud-native 에 적합한 것이 아니며, 적절한 기준을 두고 선택할 필요가 있습니다.

 

가끔씩 Azure 나 .Net 등에 대한 광고 아닌 광고(...)들이 들어있는 글이지만, 충분히 읽어봐도 좋을 글인 것 같습니다.

 

 

---

 

📝 좀 더 길게 정리해 보자면

내용을 보기에 앞서서 먼저 문서의 구성을 살펴보겠습니다.

Introduction to cloud-native applcations 라는 이 문서는 아래의 3가지 부분으로 cloud-native app 을 소개하고 있습니다.

• Introduction to cloud-native applications ☁️
• Defining Cloud Native
• Candidate apps for Cloud Native

 

먼저 첫번째 파트인 Introduction to cloud-native appliations 에서는 monolithic apps 의 한계를 지적하고, 이를 해결하기 위해 cloud-native 도입이 필요하다고 설명합니다. 덧붙여 어떤 식으로 구성되어있는지도 이야기 합니다.

 

두번째 파트에서는, 꽤 많은 내용을 다루고 있지만 핵심은 cloud-native 란 무엇인지, 어떤 속성을 가져야 하는지, 그리고 어떤 구성요소들로 infrastructure 을 구성하여 시스템을 지지하는지 이야기 합니다.

 

그리고 마지막으로, 모든 application 이 cloud-native 에 적합한 것은 아니며, 어떤 apps 들이 cloud native 하게 되는 데에 가치를 가질 수 있는지에 대해서도 이야기하고 있습니다.

 

Introduction to cloud-native applications

아래의 이미지는, 우리가 과거 오랜시간 사용해 왔던 monolithic app 의 구조입니다. 

monolithic app 이 나쁜 것만은 아니고, 여러 성공한 어플리케이션들도 monolithic 구조를 따르고 있습니다.

 

Traditional monolithic design

 

그러나 문제는 시간이 지나면서 발생합니다.

Monolithic 구조로 작성한 app 은 점점 우리 손을 벗어나게 되고, 이에 대한 불안함은 점점 커질 수 밖에 없으며, 결국 우리는 Fear Cycle 이라는 상태에 빠지게 됩니다. Fear Cycle 은 아래와 같습니다.

• app 이 너무 복잡해져서, 결국 아무도 app 에 대해 이해할 수 없게 됩니다.
• app 에 변경을 적용하는 것이 두려워 집니다. - 변경은 의도치 않게 많은 비용을 발생시킬 수 있기 때문입니다.
• 새로운 기능을 추가하거나 수정하는 일은 점점 까다로워지고, 시간도 많이 들며, 구현하는 데 드는 비용도 커 집니다.
• 작은 변경을 가지는 release 라고 하더라도 전체 application 의 배포가 필요합니다.
• component 하나만 잘못되어도, 전체 시스템을 crush 할 수 있습니다.
• 새로운 기술이나 프레임워크를 적용하는 것은 선택할 수 없습니다.
• 애자일 방법론을 적용하기도 어렵습니다.
• 아키텍쳐는 점점 낡아가고, 예외사항은 늘어만 갑니다.
• 결국 컨설턴트는 application 을 새로 만들라고 합니다.

 

이러한 상황에서 많은 기업들은 해결책으로 cloud-native 를 도입했고 Fear Cycle 을 극복했습니다.

아래 이미지는 위의 monolithic app 을 cloud-native app 으로 재구성 한 것입니다.

 

Cloud-native design

 

이제 하나였던 monolithic application 은 많은 독립적인 microservices 들로 분리되었습니다. 각 서비스들은 독립적으로 움직이며, 컨테이너로 배포되고, 컨테이너 오케스트레이터(k8s 등) 에 의해 배포됩니다.

 

각 microservices 들은 각자의 datastore 를 가지고 있으며(어떤 서비스는 RDB, 어떤 서비스는 Redis cache, 어떤 서비스는 NoSQL DB 등), 모든 트래픽은 API Gateway 를 통해 라우팅 됩니다.

 

무엇보다 가장 중요한 것은, 이 system 이 현대 cloud 플랫폼들 아래의 features 들을 확보 할 수 있다는 점입니다.

• 확장성 (scalability)
• 가용성 (availabilty)
• 탄력성 (resiliency)

 

그리고 이러한 구조를 우리는 Cloud Native 라고 부르기로 했습니다.

 

Defining Cloud Native

CNCF 에서는 공식 문서에서 아래의 내용을 Cloud Native 의 정의로 제공하고 있습니다.

Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

 

오해의 소지가 있을까 원문을 그대로 옮겼지만, 결국 Cloud Native 는 "현대 클라우드 환경에서 확장 가능한(scalable) applications 를 구축하고 실행할 수 있도록 하는" 을 의미한다고 말하고 있습니다.

 

이러한 Cloud Native 의 접근 방식으로, containers, service meshes, microservices, immutable infrastructure, 선언적 APIs 등을 언급하고 있으며, Cloud Native 의 달성을 위해 느슨하게 결합된(loosely coupled) 시스템을 사용할 수 있다고 이야기 합니다.

 

또한 Cloud Native 는 속도(speed)와 민첩성(agility)을 중시합니다.

기존에는 시스템이 단순히 비지니스를 지원했지만, 현재는 비지니스의 속도와 성장을 가속화하는 무기이기도 하며, 그렇기 때문에, 아이디어를 즉시 시장에 내놓는 것은 필수적입니다. 아래는 그러한 것을 잘 하는 대표적인 회사들입니다.

 

회사명	Experience
Netfix	- 600 개 이상의 서비스 - 하루에 수백 번의 배포
Uber	- 1,000 개 이상의 서비스 - 한 주에 몇천 번의 배포
WeChat	- 3,000 개 이상의 서비스 - 하루에 1,000 번의 배포

 

다들 이제는 잘 알고 있지만, 위 회사들은 모두 수백개의 microservices 들로 구성된 시스템을 가지고 있습니다. 이를 통해 시장의 needs 에 발 빠르게 대응 할 수 있습니다.

 

Cloud Native 의 속도와 민첩성은 여러가지 요인에서 기인하는데, 가장 중요한 것은 클라우드 인프라이며, 아래 그림에 표시된 5가지 항목은 Cloud Native system 의 기초를 의미합니다.

 

Cloud-native foundational pillars

 

---

 

클라우드 네이티브 시스템은 이미 구성된 PaaS 나 managed services 등을 광범위하게 활용하고, automation 되어있는 대상들을 통해 간단하게 구성할 수 있는 인프라를 사용합니다.

 

말하자면 Pets vs. Cattle 로 이야기 되는 DevOps 의 개념 중, Cattle 의 모델을 받아들이고 이용한다고 할 수 있습니다.

여기서 말하는 Pets 와 Cattle 에 대해 간략하게 이야기하자면, Pets 와 Cattle 각각을 서버에 비유하여 설명하는 개념입니다.

 

Pets

• 서버는 물리적인 머신입니다.
• 각 서버들은 특별한 이름을 가지고, 특별대우를 받습니다.
• 만약 서버에 문제가 생기면, 많은 비용을 지불하더라도 서버의 문제를 해결합니다.
• 같은 서버에게 더 많은 리소스를 투자하여 scale up 할 수 있습니다.
• 만약 서버를 사용할 수 없게되면, 모두가 이 사실을 알게 됩니다.

Cattle(소떼) 모델

• 각 서버(혹은 서비스)는 VM 이나 컨테이너 입니다.
• 각 서버는 특별한 이름 없이, 그저 특정 (서버) 그룹의 일부일 뿐입니다.
• 서버를 추가함으로써 scale out 이 가능합니다.
• 서버를 사용할 수 없게 되더라도, 아무도 이 사실을 알지 못합니다.

 

---

 

그러면 이제 다시 본론으로 돌아와서, Cloud Infrasture 의 기초가 되는 항목들에 대해서 살펴보도록 하겠습니다.

 

Modern Design

Cloud Native application 을 어떻게 설계할 것이며,
어떤 원칙, 패턴, Best Practce 를 준수할 것인지.

 

 

The Twelve-Factor Application

The Twelve-Factor Application 은 cloud 기반의 applications 를 구성하는 데에 있어서 널리 쓰이는 방법론입니다. 이는 cloud 환경에서 최적화된 app 을 만들기 위한 원칙과, practices 들을 이야기하고 있습니다.

 

특히 환경의 변화에 쉽게 적응이 가능하다는 부분과, 선언적인 자동화(declarative automation) 부분은 주의깊게 볼 필요가 있습니다.

 

이에 대한 내용은 이전 작성한 포스팅이 있어 해당 내용을 참고하셔도 좋을 것 같습니다.

 

https://snacky.tistory.com/103

The Twelve-Factor App

 

다만 본문에서는 12가지 요소 이외에, The Twevle-Factor App 의 주창자인 Kevin Hoffman 님의 새로운 책, Beyond the Twelve-Factor App 에서 언급되는 3가지 항목을 추가로 더 이야기 하고 있기 때문에 해당 내용을 포함하여 적어둡니다.

 

No.	Factor	설명
1	Code Base	- 각 microservices 들에 대해 단일 codebase 가 존재 - codebase 는 version control 도구에 의해 추적되며, 다양한 환경에 배포 가능해야 함
2	Dependencies	- 각 microservices 들은 시스템에 영향을 끼치지 않도록, 의존성을 분리하고 패키징 함
3	Configurations	- config 정보는 microservice 외부로 분리되어 config 관리 도구에 의해 관리됨 - 다양한 배포환경에서 동일한 deployment 는 code 수정 없이, 적절한 config 수정만으로 가능함
4	Backing Services	- 보조 resources(data stores, cache, message broker 등)들은 addressable URL 을 통해 노출됨 - addressable URL 을 지정하면, application 에서 resources 들은 분리되어, 간단하게 교체 가능해짐
5	Build, Release, Run	- 각 release 는 build, release, run stages 단계를 엄격하게 분리해야 함 - 각 release 에는 unique ID 가 지정되고, rollback 기능을 지원해야 함 (현대 CI/CD 시스템이 이를 이애하는 데에 도움이 될 것)
6	Processes	- 각 microservice 는 다른 services 들로부터 분리된, 자체 프로세스로 실행되어야 함 - required state 는 분산 cache 나 data store 같은 backing service 를 통해 외부로 노출함
7	Port Binding	- 각 microservice 는 각자의 port 로 기능/인터페이스를 노출해야 함 - 이는 다른 microservices 들과의 분리를 위해 용이함
8	Concurrency	- services 들은 강력한 machine 에서 단일 인스턴스를 scale-up 하는 것이 아니라, 동일한 다수의 프로세스(copies) 를 통해 scale-out 됨
9	Disposability	- service 인스턴스는 일회용(쉽게 폐기 가능) 이어야 함 - fast startup 을 통해 scalability 를 증가 - graceful shutdown 을 통해 system 의 올바른 상태 유지
10	Dev/Prod Parity	- app lifecycle 전반의 환경을 최대한 유사하게 유지 (각 stage 의 환경 등) - 이러한 측면에서 container 를 사용하는 것은 동일 실행 환경 유지를 위해 매우 용이함
11	Logging	- microservices로부터 생성된 log 는 event streams 로 취급됨 - event aggregator 를 이용하여 data 를 처리함 - Splunk 나 Azure Monitor 와 같은 data-mining / log 관리 도구를 이용하여 log 데이터를 장기간 보관 가능
12	Admin Processes	- 일회성 프로세스로 admin/manage 작업을 실행함 - 이러한 작업에는 data cleaup 과 report 를 위한 pulling 분석이 포함될 수 있음 - 이러한 작업을 수행하는 도구는 production 환경에서 이용되어야 하며, app 과는 분리되어서 작동해야 함

 

No.	New Factor	설명
13	API First	- 모든 것은 service 형태로 만들어져야 함 - front-end client, gateway, 혹은 다른 service 에 의해 사용된다고 가정해야 함
14	Telemetry	- workstation 에서는 app 과 이 app 의 behavior 에 대해 자세하게 볼 수 있지만, cloud 상에서는 그렇지 않음 - 설계시에 domain-specific 한 health/system 데이터에 대한 monitoring collection 을 포함시켜야 함
15	Authentication / Autorization	- 처음부터 identity 에 대해 구현함 - public 클라우드에서 RBAC(role-based access control) 기능을 사용하는 것 대해   처음부터 고려가 필요함

 

Critical Design Considerations (추가적인 고려사항)

상기에 언급된 12+ factor 는 많은 설계 고려사항을 포함하지만, 이외에도 추가적으로 고민할 것들이 있습니다. 해당 내용은 원문의 각 챕터에 언급이 되어있으나, 본 포스팅에서는 범주를 벗어나기 때문에 추가적인 내용을 적지는 않았습니다. 그저 고려해야 할 항목 중 이런것들도 있다고 생각해주시면 좋을 것 같습니다.

 

Communication

• front-end client 가 어떻게 back-end core 서비스와 communication 할 것인지?
  • 직접 communication?
  • 유연성(flexibility), 제어(control), 보안(security) 을 제공하는 게이트웨이 파사드(gateway facade) 를 통해서?
• back-end core 서비스들이 다른 서비스들과 어떻게 communication 할 것인지?
  • 직접 HTTP 호출하는 방식으로 coupling 하여 성능(performance) 과 민첩성(agility) 에 영향을 주는 방식?
  • queue 나 topic 으로 분리된(decoupled) messaging 처리를 수행하는 방식?

Resiliency

• microservices 아키텍쳐는 시스템을 in-process 에서 out-of-process 네트워크 통신으로 바꿉니다.
• 분산 아키텍쳐에서
  • 서비스B 가 서비스A 의 요청에 응답이 없으면 어떻게 되는지?
  • 혹은 서비스C 가 일시적으로 사용할 수 없게 되어서, 다른 서비스들이 blocked 되면?

Distributed Data

• 설계상 각 microservice 는 자체적으로 데이터를 캡슐화 하고, public interface 를 통하여 이를 조회할 수 있습니다.
  • 그렇다면 여러 서비스에 걸쳐 데이터를 조회하는 tracsaction 은 어떻게 구현하는지?

Identity

• 당신의 서비스에 누가 접근하고 있는지, 그리고 어떤 권한을 가지고 있는지, 어떻게 판단하는지?

 

Microservices

cloud native system 은 현대적인 application 구축을 위해 널리 사용되는 microservices 구조를 차용합니다.

공유 구조를 통해 서로 interact 하는, 작고 독립적인 services 들의 집합으로 구성되는 microservices 구조는 다음과 같은 특성(characteristics)들을 지닙니다.

 

• 각각은 더 큰 domain 컨텍스트 내에서, 특정 business 기능을 구현합니다.
• 각각은 따로, 그리고 독집적으로 개발됩니다.
• 각각은 data stroage 기술(sql, nosql) 과 프로그래밍 플랫폼을 자체적으로 캡슐화 합니다.
• 각각은 자체 프로세스에서 실행되며, http/https, websockets, AMQP 등을 통해 다른 프로세스와 통신합니다.
• 전체 application 은 각 microservices 들의 조합으로 구성됩니다.

 

아래 이미지는 monolithic 시스템과 microservices 시스템을 비교하는 이미지 입니다.

monolithic 시스템이 single process 실행을 위해 layered 아키텍쳐를 어떻게 구성하는지 주목해서 볼 필요가 있습니다. monolithic 시스템은 주로 RDB 를 사용합니다.

반면에 microservices 시스템의 경우, 각 기능별로 (domain) logic 과 data 를 포함하는 services 들이 분리되며, 각 microservices 들이 자체 datastore 를 hosting 하도록 작성됩니다.

 

Monolithic deployment vs. microservces

 

12-factor 항목에 유의하여 microservices 시스템을 보는 것도 좋습니다.

 

 

Why microservices?

microservice 는 민첩성(agility) 를 제공할 수 있기 때문입니다.

본 포스팅 상단에 이미지에 있는 eCommerce 구조를 참고하여 아래 내용을 확인하면 좀 더 명확하게 이를 알 수 있습니다.

• 각 microservice 는 자동화된 lifecycle 을 가지고 있으며, 독립적으로 발전하고 배포됩니다.
  • 즉, 분기별 릴리즈 등을 통해 업데이트 배포할 필요 없이 각자 발전하고, 배포될 수 있습니다.
  • 또한, 전체 시스템을 중단시킬 위험이 적은 일부에 대해서만 업데이트 하는 것도 가능합니다.
• 각 microservice 는 각자 scale 될 수 있습니다.
  • 전체를 담당하는 단일 app 을 scaling 하는 대신, 네트워크 대역폭이나 처리 비용이 더 필요한 services 들만 scale out 합니다.
  • 이렇게 잘 정의된 scaling 방식을 통해, 시스템을 보다 효과적으로 제어하고, 시스템 확장에 따른 전반적인 비용을 감소시킬 수 있습니다 (일부만 확장되므로).

 

Containers

컨테이너(container) 라는 용어는, 이제와서는 cloud-native 에 관련해서는 너무나도 당연한 용어가 되었습니다. Cloud Native Patterns 의 저자는 컨테이너를 두고, "Containers are a great enabler of cloud-native software." 라고 이야기 합니다.

 

CNCF 에서 제공하는 Cloud-Native Trail Map (클라우드 기반으로 전환을 시도하는 기업을 위한 map) 에서도 microservice 의 컨테이너화는 첫번째 단계로 꼽힙니다.

 

microservice 를 컨테이너화 하는 것은 간단하고 직관적입니다. code, 종속성, 런타임은 컨테이너 image 라고 불리는 binary 로 패키지되고, 이 images 들은 컨테이너 레지스트리에 저장되며, 이 레지스트리들은 datacenter 나 public cloud 등에 위치합니다. docker 의 경우는 docker hub 라는 자체 public registry 를 제공하기도 합니다.

 

필요한 경우, 컨테이너 런타임이 설치된 곳이라면 어디든, image 를 instance 로 실행시킬 수 있습니다.

 

Multiple containers running on a container host

 

컨테이너들이 얼마나 twelve-factor application 의 Dependency 원칙을 잘 지키는지도 주목할 만한 부분입니다.

 

Why containers?

컨테이너를 사용하는 이유는 다음과 같습니다.

• 컨테이너는 portability 와 consistency 의 보장을 제공함
  • 모든 것을 single package 로 캡슐화 하여, microservice 와 이에 대한 dependencies 들을 infra 로부터 분리할 수 있음
• docker 런타임이 있다면, 동일한 container 를 어떤 환경에서든지 배포할 수 있음
  • 이를 통해, sw 라이브러리 등등 각 환경마다 설치가 필요한 항목들에 대한 workload 를 줄일 수 있음
• 기본 OS와 host 의 리소스를 공유하여, 컨테이너는 기존 VM 을 사용하는 경우보다 훨씬 작음
  • 이는 동일 리소스에서 실행할 수 있는 microservice 의 수가 증가함을 의미하기도 함

 

Container Ochestration

docker 와 같은 도구가 image 를 만들고, container 를 실행하지만, 동시에 이러한 것들을 관리하기 위한 도구도 필요합니다. 이는 container ochestrator 라는 특별한 SW 로 이루어집니다. 규모에 맞는 운영을 하기 위해서는, container ochestrator 의 존재는 필수입니다.

 

아래 이미지와 표는 일반적인 container ochestrators 가 제공하는 기능을 보여줍니다.

 

What container ochestrators do

 

Tasks	Explanation
Scheduling	container instances 를 자동으로 프로비저닝 합니다.
Affinity/anti-affinity	서로 가깝게, 혹은 멀리 떨어진 containers 들을 프로비저닝 하여, availablity 와 성능에 도움을 줍니다.
Health monitoring	failures 에 대해 자동으로 감지하고, 수정합니다.
Failover	실패한 instance 를 자동으로 helthy machines 에 다시 프로비저닝 합니다.
Scaling	요구사항(demand) 에 맞게 container instances 를 추가하거나 삭제합니다.
Networking	container 간 통신을 위한 networking overlay 를 관리합니다.
Service discovery	서로의 위치가 탐색 가능합니다.
Rolling upgrades	zero-downtime 업그레이드 배포를 할 수 있도록 하며, 문제가 있을 경우 자동으로 roll-back 합니다.

 

Twelve-Factor application 의 Disposability 와 Concurrency 항목에 대해 생각하며 Ochestrator 의 동작을 살펴보면 좋습니다. 많은 container ochestrators 들이 존재하지만 kubernetes 는 사실상의 표준(de-facto) 이 되었습니다.

 

Backing services

Cloud-Native systems 들은, data stores, message brokers, monitoring and identity services 와 같은, 많은 보조 resources 들에 의존하는데, 이들을 backing services 라고 부릅니다.

 

Common backing services

 

Backing services 부분은 twelve-factor 에서 "statelessness" 에 대한 항목(#6번)주목해서 보면 좋습니다.

 

물론, 자체 backing services 들을 운영할 수도 있겠지만 이는 라이센스에 대한 확인이나, provisioning, 리소스 관리 등 추가적인 관리가 필요해 집니다. 클라우드 프로바이더들은 다양한 backing services 들을 제공하므로 이를 사용하기만 하면 됩니다. 클라우드 프로바이더들이 이에 대한 scaling 이나 운영 전반에 대한 것을 책임져 줍니다. 이는 시간과 노동의 절약으로 이어집니다.

 

외부의 config 에 저장된 정보(URL 과 credentials 등) 를 통해, 동적으로 바인딩 된 attatched 리소스로서 backing service 를 다루는 것이 best practice 입니다. 이는 Twelve factor 의 #3 번 #4 번을 통해서도 확인할 수 있습니다.

 

이러한 패턴을 통해, code 의 변경 없이 backing services 들을 연결/분리 할 수 있습니다. backing service 를 QA 에서 staging 환경으로 변경할 때, 그저 config 변경을 통해, microservice 가 staging 환경의 backing service 를 가리키도록 하기만 하면 됩니다.

 

클라우드 벤더들은 이처럼 backing services 와 통신할 수 있는 APIs 들을 제공합니다. 이를 직접적으로 호출하는 구조는 매우 강하게 결함된(tightly compled) 상태이므로, 이보다는 느슨하게 결합될 수(loosely-coupled) 있도록 처리하여, 다른 backing services 로 변경되기 용이하도록 하는 것이 좋습니다.

 

Automation

앞서 살펴본 바와 같이, cloud-native systems 들은 microservices, container 및 최신 시스템 설계를 차용하여, 속도(speed) 와 민첩(agility) 를 달성합니다. 그러나, 이는 일부에 불과합니다. 이러한 시스템이 실행되는 cloud 환경을 어떻게 프로비저닝 할 것인지? 어떻게 app의 기능을 빠르게 배포하고 업데이트 할 것인지? 어떻게 cloud-native systems 를 완성시킬수 있는지? 등에 대한 의문이 남습니다.

 

Automating Deployments

Twelve-factor application 을 살펴보면, 거기서는 완성된 코드를 실행중인 app으로 변경하는 단계를 별도로 분리하기를 요청하고 있습니다.(12-factor 의 #5 참고)

 

최신의 CI/CD 는 이 원칙을 지키는 데에 도움이 됩니다. 배포의 각 단계를 제공하고, user 들이 쉽게 사용할 수 있는 일관되고 품질좋은 코드를 제공하는 데 도움을 줄 수 있습니다.

 

 

Deployment steps in a CI/CD Pipeline

 

위 그림은 아래와 같은 과정을 따릅니다.

 

• code repo 로부터 code push → binary artifact 로 빌드, 테스트, 패키징 (CI) → 특정 binary artifact, 외부 app, 환경 config 정보 등을 선택하여 immutable release 를 생성하고, 지정된 환경에 배포 (CD) → 마지막으로, release 된 기능이 실행 환경에서 실행됨

 

이러한 practices 는 SW 제공방식을 근본적으로 발전시켰으며, 분기별로 release 하던 기업들은 이제 on-deman (요구에 따라) release 를 하게 되었습니다. 목표는 더 적은 비용으로 문제를 해결할 수 있을 때 알아채는 것입니다. 시간이 길어질 수록 비용은 커지게 마련입니다. 이러한 CI/CD 과정을 통해  SW 품질을 향상시킬 수 있습니다.

 

---

 

Candidate apps for Cloud Native

Cloud-Native 의 장점에 대해 줄곧 이야기했지만, 실제로 이에 걸맞는 application 을 선정하는 것은 별도의 이야기입니다. 모든 비용 등을 고려하면 작은 application 에 cloud-native 를 적용하는 것은 더 큰 비용을 요구할 것입니다.

 

어떤 유형이 cloud-native application 에 적합한지는 아래의 항목들로 판단할 수 있습니다.

 

• 비지니스의 기능/역량을 끊임없이 발전시켜야 하는 전략적 enterprise system 의 경우
• 빠른 release 속도와 높은 신뢰성이 필요한 application 인 경우
• 전체 시스템의 재배포 없이, 특정 기능에 대해서만 release 가 필요한 경우
• 다양한 기술 스택에 대해 전문성을 갖춘 팀이 개발한 경우
• 독립적으로 scale 해야만 하는 components 를 포함하는 app 인 경우

 

여기에 추가하여 legacy 시스템도 이야기 할 수 있습니다. 새로운 app 을 작성하고 싶더라도, legacy 코드를 현대화(cloud-native 화) 해야 하는 경우도 있기 때문입니다.