Cloud native 정리

 

• IT infra
  • traditional, cloud (public, private, hybrid , etc ..)
• monolithic & MSA
• cloud native & cloud computing
  • cloud native 
  • IaaS,PaaS,SaaS
• Impression

 

 

클라우드, 클라우드 컴퓨팅, SaaS, docker 등 우리는 다양한 클라우드의 개념들을 알고 있고 클라우드가 핫하다는 것을 인지하고 있다. 나 역시도 클라우드 써야 돼!! 클라우드가 유행이야라는 이야기는 많이 듣지만

"왜 사용해야 할까?"

"왜 사용해야 할까?"라는 질문에 대답을 하는 것이 참 어려웠다. 회사에서 작은 세미나를 발표하게 되면서 클라우드의 개념을 정리하게 됐는데 끄적끄적 작성해 보자.  

식상하지만 코로나 19로 인해 많은 기업들이 디지털 전환이 가속화가 되었다. 기존 온프레미스 시스템으로는 빠르게 변화하는 비즈니스 요구에 대응하는 게 한계가 있었다. 디지털 전환을 성공하기 위한 IT인프라로 '클라우드'가 나왔다.

많은 기사들과 레퍼런스를 보면 전환되는 이유의 주요인들은 비용절감, 전력 소비 완환, 개발 방식 다양화 등 다양한 이유가 있었다. 근데 근본적으로 일단 알아야 하는 것은 IT 인프라이다. 

인프라

인프라는 IT 환경을 운영하고 관리하는 데 필요한 구성요소이다. 클라우드 컴퓨팅 시스템이나 조직의 자체 시설 내부에 배포를 할 수 있다.

인프라의 구성 요소

인프라의 구성요소는 하드웨어, 소프트웨어, 네트워킹 구성요소, OS, 데이터 스토리지가 있으며 IT 서비스 및 솔루션을 제공해 준다. 

기본적으로 하드웨어 인프라는 회사 내에 있는 서버, 데이터센터, 개인용 컴퓨터, 스위치 등이 데이터 센터를 보관하고 냉각, 동력을 공급하는 시설들이다. 

소프트웨어 인프라는 우리에게 익숙한 웹 서버, 콘텐츠 관리 시스템, Linux와 같은 OS 등 기업에서 사용하는 앱 등을 제공해 주는 것이다. 

인프라의 유형 

인프라의 유형은 매우 다양하지만 오늘은 크게 두 가지로 나눠보려고 한다. 전통적, 클라우드로 나눠보려고 한다. 

전통적인 방식은 기업의 자체 시설에서 직접 소유하고 관리를 한다. 전통적인 인프라는 실행하는 데에 비용이 많이 든다. 반면 클라우드 방식은 전용 리소스를 사용해 프라이빗 클라우드를 자체적으로 구축할 수 있고 클라우드 업체의 클라우드 인프라를 대여해서 퍼블릭 클라우드도 사용할 수 있다. 또한 이 두 가지가 합쳐지거나 클라우드와 온프레미스를 결합한 형태인 하이브리도(하이브리드는 개념이 모호해진 경향이 있음)도 있다. 

"전통적인 방식은 소유, 클라우드 방식은 대여"

여기까지가 기본적인 클라우드 인프라의 구성요소에 관련된 개념이다. 그럼 다시 돌아와서 온프레미스에서 클라우드(it인프라)로 왜 전환해야 하는가? 에 대해서 알기 위해서는 개발 방식에 대해서 알아야 한다. 

---

Monolithic & MSA

전통적인 온프레미스의 개발방식 중에 모놀리식이 있고 클라우드 개발 방식 중에는 MSA가 있다. (클라우드, 온프레미스 내에 다양한 방법들이 있지만 대표적인 개발방식이다.)

Monolithic 

모놀리식 아키텍처는 전통적인 개발 방식이다. 하나의 프로젝트에 모든 기능을 포함시킨다. 모놀리식 아키텍처는 단일 애플리케이션 내에 서비스의 모든 로직이 통으로 들어있다고 생각하면 좋다. 예시를 들면 우리가 온라인 쇼핑몰 애플리케이션을 만든다고 생각해 보자. 처음에 WAR파일(웹 애플리케이션 패키징 파일)을 톰캣 서버로 만들고 그 안에 애플리케이션이 구성되어 있다. 쇼핑몰을 이용하려면 프론트엔드(UX) 부분도 있을 테고 사용자, 상품, 주문 등 관리 부분이 있을 것이다. 이러한 와르의 큰 형태와 밖에 있는 데이터베이스의 구조가 모놀리식 구조이다.

• 장점 : 간결하다. 중앙집중된 구조이기 때문에 분산된 앱에 비해 E2E 즉 엔드 투 엔드 테스트를 더 빠르게 할 수 있다. 여기서 E2E는 사용자 관점에서 앱의 흐름을 처음부터 끝까지 테스트하기 좋다. 비즈니스 로직, UI, 콘텐츠까지 모든 구성 요소가 코드가 들어있기 때문에 디버깅도 간편하다. 소규모 프로젝트를 할 때 단순하면서 견고한 구조를 만들 수 있다.

• 단점: 이런 구조에서 프로젝트의 규모가 커지면 빌드나 배포에 드는 시간이 오래 걸리기 시작한다. 또한 지금도 나는 코드와 파일 구조들이 많아지면 이해하기 어려운데 프로젝트의 규모가 더 커지면 특정 컴포넌트나 모듈에서 발생하는 성능 문제, 장애에 영향을 준다. 기능별로 확인하기 어렵다.

 

MSA 

일단 클라우드 네이티브 주요 구성 요소에는 MSA, container, CI/CD, devOps 등이 있다.

여기서 MSA는 Micro Service Architecture의 의미로 작고 독립적인 서비스들의 집합으로 구성된 애플리케이션 구조이다.

여러 개의 작은 서비스로 구성되어 각 서비스가 독립적으로 개발되고 배포되는 구조이기에 시스템이 분산되어 있으니 개발, 배포가 독립적으로 가능하고 확장성과 유지관리가 용이하다. MSA에서 중요한 요소 중 하나는 자동 확장이다. 자동 확장이란 특정 서비스에서 트래픽이나 부하가 증가할 경우 인스턴스를 추가하고 불필요한 인스턴스 서비스를 제거하는 것이 주요 포인트이다. 

MSA  주요 특징

독립적인 배포가 가능 (Independently deployable)

서비스 단위로 분리되었기 때문에 각각의 서비스들을 독립적으로 배포할 수 있다.

느슨한 결합 (Loosely coupled)

각 서비스에 대한 의존성을 최소화하므로 결합도가 낮다.

높은 유지성, 테스트 가능성 (Highly maintainable and testable)

분리된 서비스별로 관리되기 때문에 유지하기 편하고 테스트도 독립적으로 가능하다.

팀 단위 구성이 가능 (Owned by a small team)

서비스 단위로 팀 구성을 하여 개발/운영할 수 있다.

사업 단위(서비스 단위)의 조직 (Organized around business capabilities)

각 서비스의 단위를 사업의 단위로 판단할 수 있다.

 

장점 : 서비스별 독립적인 배포가 가능하다. 이것이 가장 큰 특징이자 장점이다. 전체 서비스의 중단 없이 개별적인 서비스를 자유롭게 배포할 수 있다. 또한 모놀리식의 한계점을 극복할 수 있다. 모놀리식 환경과는 다르게 특정 서비스의 부하로 스케일링이 필요할 경우 해당 서비스만 별도로 확장이 가능하다. 이러한 환경이 클라우드에 적합하다.

 

 

MSA의 구조를 알고 싶다면 아래의 글을 참고

https://wonit.tistory.com/490

[마이크로서비스] MSA의 핵심 구성 요소 - Service Mesh

 

모놀리식 아키텍처:

한 덩어리: 모든 기능이 하나의 애플리케이션에 통합됨

장점: 초기 개발이 빠르고, 배포가 단순함

단점: 유지보수가 어렵고, 확장성이 떨어짐

마이크로서비스 아키텍처(MSA):

독립적 서비스: 기능별로 독립된 서비스로 분리되어 개발됨

장점: 확장성과 유연성이 뛰어남, 유지보수가 용이함

단점: 통신 비용과 데이터 관리의 복잡성이 증가함

 

여기까지가 모놀리식과 MSA의 차이점, 장단점이다. 모놀리식의 한계를 극복하기 위한 방식으로 MSA의 방식이 등장했고 MSA는 클라우드 네이티브의 구성 요소 중 하나인데 클라우드 네이티브와 클라우드 네이티브는 클라우드 컴퓨팅의 장점을 활용하는 것인데 이 두 개념에 대해서 정리해 보자

---

cloud native & cloud computing

cloud native는 cloud computing의 장점을 최대한 활용하여 애플리케이션을 개발하는 방식을 의미한다. 기존 온프레미스 환경에서 클라우드 환경으로 옮기는 것이 아닌 처음부터 클라우드를 고려해서 개발하는 것을 말한다. 

주요 구성요소는 컨테이너, MSA, CI/CD, DevOps가 있다.

• 컨테이너: 애플리케이션을 컨테이너화하여 독립적으로 배포하고 관리함.
• MSA: 마이크로서비스 아키텍처를 사용하여 독립적인 서비스로 나누어 개발함.
• CI/CD: 지속적인 통합과 배포를 통해 빠른 배포와 피드백을 가능하게 함.
• DevOps: 개발과 운영의 협업을 통해 효율성을 극대화함.

그럼 cloud computing의 장점을 최대한 활용해서 만드는 방식이 클라우드 네이티브인데 cloud computing은 무엇일까? 

cloud computing의 모델을 살펴보자.

 

Cloud computing Model

클라우드 컴퓨팅은 Google, Microsoft, Dropbox, IBM 등 기술 분야 최대 기업이 주도하면서 시장에서 성장한 기술이다.

많은 양의 정보를 다루는 조직에는 데이터에 대한 더 높은 신뢰성과 보안이 필요하다. 클라우드 컴퓨팅은 컴퓨팅 리소스(스토리지 및 인프라)를 인터넷을 통해 서비스로 사용할 수 있는 주문형 서비스다. 개인과 기업이 물리적 리소스를 직접 관리할 필요가 없으며 사용한 만큼만 비용을 지불하면 된다.

클라우드 컴퓨팅에 여러 가지 모델이 있지만 3가지로 분류하면 iaas, paas, saas이다. 모든 것들이 '() as a service` 의 풀네임의 약자로 사용된다.

 

SaaS

SaaS 는 서비스를 제공해 주는 것이다. 말 그래도 S/W 를 제공해주는 것이고 만들어져 있는 것을 소비자들은 사용하는 것이다. 집으로 비유를 하게 된다면 SaaS는 모든 가구, 티비, 컴퓨터, 냉장고(안에 음식들)까지 다 있기 때문에 우리는 그것들을 사용하기만 하면 된다. 많은 회사에서 최종 목표로 생각하고 있을 거 같다. 넷플릭스와 우버 등 다양한 회사에서 SaaS로 전환을 했다.

SaaS에 대한 개념들보다는 PaaS, IaaS의 개념이 이해하기 어려운 거 같다.

IaaS

IaaS는 집으로 비유하면 빈방을 주는 것이다. 빈방에는 아무것도 없지만 앞으로 우리는 이곳에 많은 것들을 구매해야 할 테고 화장실이 있다면 화장실에 필요한 물품들, 가구들을 앞으로 다 구매하거나 설치해야 한다.

IaaS는 infra as a service라는 말로 인프라를 제공해 주는 서비스이다. 그렇기 때문에 앞에서 배웠던 infra. 서버, 데이터, 네트워크 등을 제공받는 것이다. 이곳에는 다양한 것들을 설치해서 서비스를 배포하거나 기본적으로 제공해주는 VM 가상머신 내에서 docker를 설치하여 안에 container를 구성하거나 웹을 배포한다거나 서비스를 제작하는 것이다.

• 인프라(서버나 스토리지 네트워크 같은 자원)를 제공해 준다.
• IaaS는 클라우드 컴퓨팅 서비스의 한 유형으로, 필수적인 컴퓨팅, 스토리지, 네트워킹 리소스를 온-디맨드로 제공한다. 
• IaaS를 사용하면 하드웨어 유지보수 비용을 줄이고, 실시간 인사이트를 얻을 수 있으며, IT 리소스의 유연한 확장이 가능하다.

PaaS

paas 는 platform as a service라는 말로 플랫폼을 제공해 주는 것이다. 지어진 집에 들어가는 것이다. 자취로 비유하면 빌트인이다. 이곳에 더 추가해도 되고 개발자들은 개발에 집중할 수 있고 이것을 토대로 우리는 IaaS 와 달리 CI/CD , monitoring 등을 굳이 할 필요가 없다. 도커를 사용하게 된다면 우리가 만들었던 프로그램들을 dockerImage로 만들거나 docker file로 만들어서 build만 하게 된다면 paas 영역에서는 ci/cd, monitoring을 자동적으로 해준다.

• 플랫폼(여러 사람들을 편리하게 해 준다, 개발자가 개발하기 편하게 해주는 환경)을 서비스로 제공해 준다.
• PaaS는 클라우드 기반의 개발 및 배포 환경을 제공하는 서비스
• 인프라, 미들웨어, 개발 도구 등을 포함하며, 사용자가 소프트웨어 라이선스와 기반 인프라를 직접 관리할 필요가 없다.

IaaS vs PaaS

IaaS는 결국 devOps 개발자가 필요하거나 전문가가 필요하다. 또한 monitoring, ci,cd 와 같은 여러가지 서비스 관리를 직접 설치하고 관리해야 하기 때문에 비용적인 측면이 많이 생길 수 있다. 하지만 우리가 다 직접 하는 것이기 때문에 이식성이 좋다.

PaaS는 개발에 더 집중할 수 있고 서비스 관리를 알아서 해준다. 하지만 paas에서 제공해 주는 서버와 여러 가지 옵션들이 제한적이기 때문에 또 다른 클라우드를 가져와 연결하거나 복잡할 수 있기에 이식성이 제한이 되지만 비용적인 측면으로 장점이 있다.

 

IaaS(Infrastructure as a Service):

인프라 제공: 서버, 스토리지, 네트워크 등의 인프라를 제공함.

비유: 호텔을 지을 땅을 제공함.

PaaS(Platform as a Service):

플랫폼 제공: 애플리케이션 개발에 필요한 플랫폼을 제공함.

비유: 호텔이라는 구조와 방을 제공하여 개발자가 서비스에만 집중하게 함.

SaaS(Software as a Service):

소프트웨어 제공: 사용자가 필요로 하는 소프트웨어를 제공함.

비유: 완성된 호텔 서비스를 이용함.

 

일단 여기까지가 cloud native의 전반적인 개념들이다. 아래 도식도는 직접 만들면서 개념들을 이해하려고 했다.

---

Impression

 

"상황에 맞게 사용하는 개발 방식과 인프라"

그럼 여기서... 클라우드를 꼭 써야 하나요?라는 질문이 오면 과거에는 "당연히 클라우드지!"라고 말하고 싶지만 공부를 하면서 느꼈던 것은 "상황에 맞게 사용한다"가 맞는 거 같다. 회사에서 프로젝트를 일단 배포해야 하는 상황이라면 모놀리식을 사용해서 기본적인 개발절차를 통해 프로젝트를 완성시킬 수도 있고, 기능이 다양하고 복잡할 수 있다면 클라우드의 방식으로 사용할 수도 있는 것이다. 상황에 맞게 사용하는 것이 제일 중요한 거 같다. 항상 유행하고 남들 다 하는 방식이라고 생각을 해서 클라우드만이 옳다고 생각했던 나에게는 이번 개념정리를 통해서 많은 것을 깨닫게 됐다.

"항상 왜 사용해야 하는지 생각해 보고 개발하기"

클라우드뿐만 아니라 개발을 임하는 자세를 바꿔야 한다고 생각한다. 프론트엔드를 공부하면서 react, nextJS, typeScript 등 다양한 방식들이 있고 프론트엔드는 계속해서 발전되고 있다. 나는 유행 따라 그냥 따라가려고 했던 모습들을 생각해 보면 왜 "이 언어, 프레임워크를 사용해?"라고 물어보면 "취업이나 프론트엔드를 따라가기 위해서는 이러한 것을 사용해야 돼요~!"라고 말했던 거 같다.  하지만 이것은 옳지 않은 개발 공부 방식이었다. 회사에서 JSP를 종종 사용하는데 속으로는 "왜 옛날 언어를 사용해야 하지..? 다 react 사용하잖아!"라고 생각했던 적이 있었다. 근데 JSP와 react를 둘 다 공부하면서 실행 속도를 비교하거나 디버깅, 회사 내에 큰 데이터들을 로드 등을 사용하면서 차이점(당연히 리엑트의 장점이 많긴 했다)을 숙지를 하니 왜 사용해야 하는지 깨닫는 순간이 종종 오는 거 같다. 취준때와 지금까지 이유 없이 사용했던 시간들이 많았지만 앞으로 개발을 할 때는 "왜?"라는 질문을 항상 머릿속에 갖고 공부를 해야겠다.

 

조만간  재밌는 개념인 Docker vs VM에 대해서 포스팅할 예정..