2023. 5. 5. 15:30ㆍ클라우드
해당 글은 [클라우드를 넘어 클라우드 네이티브까지] 2. 클라우드 이점을 최대로, 클라우드 네이티브 의 내용을 토대로 작성한 글입니다!
2023.04.26 - [클라우드와 클라우드 네이티브란?] - [1] 클라우드는 선택이 아닌 필수!
[1]클라우드는 선택이 아닌 필수!
해당 글은 [클라우드를 넘어 클라우드 네이티브까지] 1. 기업 생존과 직결된 클라우드 도입 의 내용을 토대로 작성한 글입니다! 요새 모든 사업 분야에서 디지털 트랜스포메이션(이하 D.T.)을 도
xpmxf4.tistory.com
위 글을 먼저 보고 오시는 것을 추천합니다!
위 글을 읽고 오셨다면 아마 여러분은
여러분의 새로운 서비스에 클라우드를 도입하고 싶거나
혹은 클라우드로의 전환의 대한 필요성을 느끼실겁니다.
도입과 전환이 마냥 쉬웠다면 모두가 바로 했겠지만,
세상이 그렇게 쉽지 않아요🙃
클라우드를 도입할 때는 다양한 요구사항과 도전에 직면하게 됩니다.
인프라를 자동으로 배포한다면, 기존 운영인력은 클라우드에 역할이 어떻게 바뀌지...?
기존의 온프레미스 환경과 클라우드를 어떻게 연결해서 사용해?
클라우드 서비스는 하나의 서비스를 여러 개로 쪼갠다는 데, 그럼 이에 대한 운영과 소통이 너무 늘어나는 거 아니야?
아마 위와 같은, 혹은 각자의 케이스에 따른 더 많은 고민들이 떠오를 거예요.
기존의 방식으로는 위와 같은 도전을 쉽게 해결할 수 없기에,
우리는 새로운 방식으로 접근을 해야 합니다.
바로 이러한 새로운 접근 방식을 클라우드 네이티브라고 하고
이번에 우린 이 클라우드 네이티브에 관해 배워보겠습니다!
1. 도입/전환 시의 고려사항
많은 클라우드의 도입/전환 시에 여러 고려사항들이 있고
이러한 고려사항들을 개발 와 운영 관점에서 분류한다면
크게 4 가지로 분류가 가능합니다.
(1) 인프라
2023.04.26 - [클라우드와 클라우드 네이티브란?] - [1]클라우드는 선택이 아닌 필수!
[1]클라우드는 선택이 아닌 필수!
해당 글은 [클라우드를 넘어 클라우드 네이티브까지] 1. 기업 생존과 직결된 클라우드 도입 의 내용을 토대로 작성한 글입니다! 요새 모든 사업 분야에서 디지털 트랜스포메이션(이하 D.T.)을 도
xpmxf4.tistory.com
위 글에서 나와 있듯이 클라우드의 형태는 보통 3가지로 분류하고
- 단일 클라우드
여러 지역 서비스의 분산으로 안정성 도모
하나의 클라우드 플랫폼이 제공하는 다양한 서비스끼리의 호환성이 좋다 - 멀티 클라우드
한 클라우드 플랫폼 전체가 망가지는 경우를 고려해
여러 플랫폼을 동시에 이용 - 프라이빗 클라우드
금융, 공공기관과 같이 보안이 제일 중요한 곳에 적합
각각의 장점이 본인의 상황에 더 크게 작용하는 것을 선택해야 합니다.
(2) 애플리케이션
온프레미스 환경에 맞춰진 아키텍처의 애플리케이션을
클라우드 환경에 맞도록 재구성할지,
아니면 그대로의 환경으로 놔둘지에 대한 고민도 필요합니다.
그 예시로 Spring vs Spring Boot + Spring Cloud를 예시로 들 수 있습니다.
우리가 아는 Spring 프로젝트들은 대부분 온프레미스 환경에 맞춰 천 아키텍처입니다.
이를 클라우드 환경에 맞춰진 아키텍처를 재구성한다면 Spring Cloud를 고려해 볼 수 있습니다.
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).
// 중략
They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
[해석] Spring Cloud는 개발자가 분산 시스템의 일반적인 패턴(예: 구성 관리, 서비스 검색, 회로 차단기, 지능형 라우팅, 마이크로 프록시, 제어 버스, 일회용 토큰, 글로벌 잠금, 리더십 선출, 분산 세션, 클러스터 상태)을 빠르게 구축할 수 있는 도구를 제공합니다.
Spring Cloud는 개발자의 자체 노트북, 베어메탈 데이터 센터, Cloud Foundry와 같은 관리형 플랫폼을 포함한 모든 분산 환경에서 잘 작동합니다.
[출처] : https://spring.io/projects/spring-cloud
도구 중 하나인 Spring Cloud Config를 사용하면 중앙 집중식 마이크로서비스 구성을 지원하여, 분산된 환경에서 설정 파일을 외부로 분리할 수 있으며, 모든 환경 구성을 간편하게 관리할 수 있습니다.
따라서, Spring Cloud를 사용해 기존의 아키텍처를클라우드 환경에 맞춘 아키텍처로의 전환을 고민할 수도 있습니다.
(3) 개발
자동화된 배포 프로세스를 어떻게 구축하냐에 대한 고려사항입니다.
하나의 프로젝트 이상을 진행해 보신 분들은 아실 거예요.
개발자들은 하루에도 수십, 수 백번 씩 코드의 업데이트를 이루고,
업데이트된 코드들의 배포라는 태스크가 매일매일 주어진다는 것을.
클라우드 아키텍처는 기존의 서비스를 여러 서비스로 분리시키는 데
그렇게 되면 그 분산된 서비스들에 대해 각각 코드 업데이트와 배포의 과정이
엄청나게 될 것입니다.
그래서 이에 대한 자동화된 프로세스의 필요성이 대두되죠.
(4) 협업
개발 측면에서의 고민에서 얘기했던 것처럼
분산된 여러 서비스들에 대해 관리하고 운영하는 것들에 대한 고민도
빠뜨릴 수 없습니다.
분산된 서비스들에 대한 개발 조직과 운영 조직 간에 효율적인 커뮤니케이션이 중요해진 것이죠!
2. 클라우드 네이티브란?
위에 고민 사항들을 잔뜩 읽다 보면
그냥 원래 하던 대로 개발/운영하는 것이 더 이득인 것처럼 보입니다!
하지만 이는 우리가 기존 방식을 생각하며 위에 대한 고민을 하기 때문입니다.
즉, 우리는 새로운 환경에 맞는 새로운 개발, 운영방식의 필요성을 느끼게 됩니다. (없다면 지금이라도 느끼죠 ㅎ)
이러한 새로운 개발/운영 방식을 우리는 클라우드 네이티브 라고 합니다.
클라우드 네이티브는 클라우드 컴퓨팅 환경에서 현대적 애플리케이션을 구축, 배포 및 관리할 때의 소프트웨어 접근 방식입니다.
[출처] : https://aws.amazon.com/ko/what-is/cloud-native/
이러한 클라우드 네이티브를 구현하기 위해서는 핵심 요소들을 알고 이용해야 합니다.
- DevOps (Dev + Ops)
개발 조직 + 운영 조직이 한 팀처럼 움직이는 프로세스, 혹은 팀 문화 - CI/CD (Continuous Integration / Continuous Deploy)
소스 개발에서 서비스 적용까지 하나의 프로세스를 자동화한 CI/CD 방법론 이해 - MSA(Micro Service Architecture)
멀티 클라우드, 온프레미스까지 자유롭게 확장 가능한 안정적인 기술 확보
위 설명을 읽고 이해가 바로 안 가는 것은 당연합니다!
밑에서 설명할 테니 일단 가볍게 읽고 넘어가주세요!
3. 클라우드 네이티브의 등장 배경
위의 고려사항에서 인프라의 관점을 얘기했었는 데
이에 대한 관점에서 클라우드 네이티브의 필요성에 대해 설명해 보겠습니다.
잠시 고리타분한 역사에 대한 이야기를 해보자면,
역사를 보면 항상 다음 스토리라인을 여러분은 느끼셨을 겁니다.
과거에 A 기술이 단점을 가지고 있었기에
해당 단점을 해결하고자 기술 B 가 나오게 되었다.
위 같은 이야기가 어떻게 보면 진부한 클리셰 같지만,
기술을 배우는 데 있어서 필요성을 느끼기 위한 좋은 클리셰이기도 합니다.
즉 클라우드 네이티브도
과거에 온프레미스 환경이 단점을 가지고 있었기 때문에
이러한 단점을 극복하고자 나온 방법론이라고 생각할 수 있죠!
그렇다면 과거의 기술, 즉 온프레미스 환경이 어땠는지 한번 알아보겠습니다!
(1) 물리 서버
과거 서버 컴퓨터를 일일이 하고 설치하던 시절에는
위와 같은 서버 컴퓨터를 구매해
일일히 사내 전산실에 설치하고
하나의 서버 컴퓨터에 하나의 OS,
그리고 그 위에 하나의 애플리케이션(기능)을 설치했습니다.
하지만 이런 방식은 2 가지 단점이 존재합니다.
- 평상시에는 사용량이 낮아 자원의 낭비 발생
- 새로운 물리 서버를 사용하는 경우(새롭게 컴퓨터 구매 및 설치)
실제 설치까지 수 주 ~ 몇 달까지 걸림
(2) 서버 가상화 기술 (물리서버 -> 가상머신)
방금 말한 단점을 보완하기 위해 서버 가상화라는 기술이 등장했습니다.
서버 가상화는 소프트웨어 애플리케이션을 통해 물리적 서버를 여러 개로 분리된 고유한 가상 서버로 나누는 과정입니다.
각 가상 서버는 자체 운영 체제를 독립적으로 실행할 수 있습니다.
[출처] : https://www.vmware.com/kr/topics/glossary/content/server-virtualization.html
즉 위처럼 하나의 물리 서버(HW)에서 여러 개의 가상 서버를 구동시켜
하나의 물리 서버로도 여러 애플리케이션을 구동할 수 있도록 하는 기술입니다!
근데 저기에 생소한 단어가 하나 있습니다!
바로 하이퍼바이저입니다. 바로 위에서 설명한
물리적 서버를 여러 개의 가상 서버로 나눠지도록 하는 소프트웨어 애플리케이션입니다!
하이퍼바이저는 단일 물리적 머신에서 여러 가상 머신을 실행하는 데 사용할 수 있는 소프트웨어입니다. 가상 머신에는 고유한 운영 체제와 애플리케이션이 있습니다.
하이퍼바이저는 필요에 따라 CPU 및 메모리와 같은 기본 물리적 컴퓨팅 리소스를 개별 가상 머신에 할당합니다.
따라서 물리적 IT 인프라의 최적 사용을 지원합니다.
[출처] : https://aws.amazon.com/ko/what-is/hypervisor/
즉 하이퍼바이저를 이용해, 새로운 서버를 생성하고 사용하는 것이 수 시간 내에 가능해진 것이죠!
하지만 서버 가상화도 단점이 존재합니다.
가상 서버들은 동일한 하이버 파이저 위에서만 실행이 가능하기 때문에
만약 한 회사가 다른 업체를 통해 서버 가상화를 이뤘다면,
가상화된 서버 간에 이전은 유연하지 못합니다.
위 그림을 예시로 들겠습니다.
왼쪽 서버는 vmware라는 하이퍼바이저 위에 생성된 가상 서버들이고
오른쪽 서버는 Hyper-V라는 하이퍼바이저 위에 생성된 가상 서버들입니다.
왼쪽의 가상 서버들은 오른쪽으로 이전이 불가능합니다.
왜냐하면 다른 하이퍼바이저가 생성한 환경이기 때문이죠.
즉, 다른 하이퍼바이저 환경에서 기존 가상서버를 운영하기 위해선
이전하려는 하이퍼바이저에 맞게 일일이 변환을 해야 합니다.
클라우드 업체는 모두 다른 하이퍼바이저를 사용하기 때문에
일일이 변환하는 것은 유연하지 못합니다.
즉 우리는 이제 클라우드 업체에 종속되지 않고,
빠른 구성 및 구동이 가능한 새로운 기술의 필요성을 느끼게 됩니다.
그래서 나오게 된 기술이 바로 컨테이너 기술입니다!
(3) 컨테이너 (Container)
컨테이너들은 컨테이너를 실행하는 엔진이 같으면 어느 클라우드에서든 사용이 가능합니다!
즉 다른 하이퍼바이저들을 사용하더라도, 하이퍼바이저 위에 동일한 도커라는 엔진을 설치한다면
우리는 애플리케이션 이전을 전처럼 일일이 변환할 필요가 없다는 얘기죠!
근데 도커는 원래 Host OS 위에 바로 설치하지 않나...? 리소스 사용도 더 자유로운 게 장점이라고 들었는 데?
해당 의문에 대한 YES입니다!
그렇다면 제 그림이 틀린 거 아니냐고요? 반만 맞다고 하겠습니다!
2023년 현재, 도커와 호환성 문제가 있는 시스템이나 애플리케이션은 상당히 줄어들었죠.
도커는 계속해서 발전하고 있으며, 많은 소프트웨어 및 애플리케이션 개발자들이 트렌드에 맞게 도커를 지원하도록 애플리케이션을 개발하고 있습니다. 다만, 아래와 같은 경우에 호환성 문제가 여전히 발생할 수 있습니다.
- 매우 구체적인 하드웨어나 소프트웨어 요구사항이 있는 시스템
특정 하드웨어 리소스에 직접 접근해야 하는 시스템이나 애플리케이션은
도커와 함께 사용하기 어려울 수 있습니다. - 업데이트되지 않은 구버전의 시스템이나 애플리케이션
도커에 최적화되지 않은 오래된 소프트웨어나 애플리케이션은 호환성 문제가 발생할 수 있습니다.
이 경우, 해당 소프트웨어나 애플리케이션을 업데이트하거나, 호환성이 높은 대체품을 찾아 사용해야 합니다.
하지만 대부분의 상황에서 도커는 리눅스, 윈도우, 맥 OS에서 잘 동작하며, 호환성 문제를 겪는 경우는 매우 드물어졌습니다.
즉 2023년에는 도커와 호환성 문제가 있는 시스템이나 애플리케이션을 찾기 어려우긴 합니다만
과거 클라우드 네이티브가 나온 시점에는 도커는 아직까지 발전이 이뤄지지 않았기 때문에 위 그림과 같은 경우를 볼 수 있는 것이죠!
4. 클라우드 네이티브 핵심 요소 4가지
(1) 컨테이너 기반 인프라
위에서도 잠시 나왔던 컨테이너에 대해 좀 더 자세히 알아보겠습니다!
컨테이너란 다음과 같습니다.
컨테이너라고 하는 표준 소프트웨어 패키지는 애플리케이션의 코드를 관련 구성 파일, 라이브러리 및 앱 실행에 필요한 종속성과 함께 번들로 제공합니다. 따라서 개발자와 IT 전문가는 여러 환경에서 애플리케이션을 원활하게 배포할 수 있습니다.
[출처] : https://azure.microsoft.com/ko-kr/resources/cloud-computing-dictionary/what-is-a-container/
앞서 얘기했던 서버 가상화 기술은 하나의 서버(가상 서버)에 하나의 애플리케이션만 설치가 가능해
컨테이너 기반 아키텍처를 통해, 하나의 서버 안에서도 여러 애플리케이션의 설치가 가능했습니다.
이로 인해 마이그레이션도 편해지고, 하나의 서버가 여러 기능도 수행이 가능해지죠!
하지만 다음 의문을 품을 수도 있습니다.
하이퍼바이저로 만든 가상 서버 안에 또 하이퍼바이저를 설치해 가상서버 안에 가상서버를 만들면 안 돼?
물론 기술적으로는 가능합니다.
하지만 이렇게 하지 않는 데는 이유가 있는 법.
다음 이유들로 우리는 이렇게 하지 않습니다!
- 성능 저하
가상 서버 위에 하이퍼바이저를 설치하면, 하드웨어 리소스에 대한
추가적인 추상화 계층이 생겨 성능 저하가 발생할 수 있습니다.
또한, 중첩된 가상화 환경에서의 오버헤드가 누적되어 전체 시스템의 성능에 부정적인 영향을 미칠 수 있습니다. - 복잡성 증가
중첩된 가상화 환경은 구성 및 관리가 복잡해질 수 있습니다.
이로 인해 가상화 인프라를 관리하는 데 더 많은 시간과 노력이 소요되며, 오류 발생 가능성이 높아질 수 있습니다. - 호환성 문제
일부 하이퍼바이저는 중첩된 가상화를 지원하지 않거나, 제한적으로 지원할 수 있습니다. - 보안 문제
중첩된 가상화를 사용하면, 보안 취약점이 노출될 수 있습니다.
이러한 취약점은 공격자가 하위 레벨의 가상 머신에 액세스 하여 전체 시스템을 탈취하는 데 이용될 수 있습니다.
즉 우리는 하나의 서버에서 여러 더 이상 서버 가상화보단,
가상 서버에서 실행되는 어플들을 가상 서버처럼 동작하도록 만든 컨테이너를 사용하게 됩니다!
컨테이너는 애플리케이션과 필요한 모든 파일을 하나의 런타임 환경으로 묶는 데 사용하는 기술입니다.
단일 구성단위로서 컨테이너는 모든 콘텍스트의 모든 운영 체제에서 쉽게 이동 및 실행할 수 있습니다.
[출처] : https://www.hpe.com/kr/ko/what-is/containers.html
위 설명에서 컨테이너는 런타임 환경으로 묶는다는 표현이 나오는 데,
이는 쉽게 말해 컨테이너는 하나의 실행 파일이라는 소리입니다.
따라서 하나의 서버를 여는 것보다 훨씬 빠르다는 소리이죠!
(2) MSA (Micro Service Architecture)
하나의 애플리케이션을 마이크로 서비스 블록(실행이 가능한 업무 단위)으로 쪼개고,
이 블록 간은 API를 통해 서로 통신하는 아키텍처를 바로 MSA라고 합니다!
이렇게 하나의 애플리케이션을 블록 단위로 쪼개면 다음과 같은 장점을 가지고 올 수 있습니다.
- 세부 기능 하나 업데이트를 위해 전체 서비스 중지/시작 안 해도 됨
- 개발 서비스 전체 장애/중지 방지
(3) DevOps
개발(Dev)과 운영(Ops)의 합성어로 설명하며, 고객에게 지속적으로 가치를 제공하도록 지원하는 사람, 프로세스 및 기술의 조합이라고 설명하고 있습니다
[출처] : https://learn.microsoft.com/ko-kr/azure/devops/user-guide/what-is-azure-devops?view=azure-devops
AWS에서는 DevOps를 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상하는 문화 철학, 방식 및 도구의 조합이 효과적인 협업과 지속적인 통합 및 전달을 가능하게 함으로써, 기업들이 더 나은 제품과 서비스를 빠르게 출시하고 시장에 적응할 수 있도록 도움을 제공합니다.
[출처] : https://aws.amazon.com/ko/devops/what-is-devops/
DevOps는 단절된 개발(dev)과 운영(ops) 간 프로세스를
seamless 하게 연결하고, 자동화 방법을 통해 효율성을 극대화하는 방법입니다.
협업 및 제품 개발 도구를 제공하는 회사 Atlassian 은 DevOps 원칙을 IT 서비스 및 엔지니어링 팀에 도입하면 서비스 품질, 팀 사기, 문제 해결 및 비즈니스 생산성을 크게 향상하는 것으로 입증했습니다.
실제로 DevOps 원칙을 채택한 기업은 평균적으로 고객 만족도가 45% 향상되고, 직원 생산성이 43% 증가하고, 디플렉션 비율이 41% 개선되며, IT 관련 비용이 38% 감소했다고 합니다.
[출처] : https://www.atlassian.com/ko/itsm/service-request-management/how-to-run-it-support-devops-way
IT 지원을 DevOps 방식으로 실행하는 방법 | Atlassian
DevOps 원칙을 IT 지원 팀에 도입하면 서비스 품질, 팀 사기, 문제 해결 및 비즈니스 생산성을 향상합니다.
www.atlassian.com
(4) CI/CD
CI/CD 란,
DevOps의 철학을 구현하기 위한 일련의 프로세스 이자, 다음 두 단어를 합친 단어입니다.
CI(Continuous Integration) : 지속적인 통합 + CD(Continuous Deployment) : 지속적인 배포
CI(지속적 통합)은 코드 변경 사항을 하루에 여러 차례 저장소에 통합하는 방식입니다.
CD에는 지속적 제공을 통해 코드 통합을 자동화하거나 지속적 배포를 통해 최종 빌드를
최종 사용자에게 자동으로 릴리스한다는 두 가지 의미가 담겨 있습니다.
CI/CD에서 빈번하게 수행되는 테스트로 코드 오류와 결함이 줄어들므로 CI/CD는
모든 DevOps 워크플로에 중요한 역할을 합니다.
[출처] : https://unity.com/kr/solutions/what-is-ci-cd
위 설명이 더할 나위 없이 깔끔한 설명입니다!
다만 우리가 CI/CD를 단순히 단어의 뜻처럼 통합, 배포만 하는 것이 아니라
지속적인 모니터링을 통해 observability를 구현, 테스트를 통해 오류와 결함을 줄인다입니다!
5. 예시
정말 먼 길 오셨습니다.
마지막은 긴 글 읽으시느라 고생 많으신 여러분을 위해 영상으로 대체하겠습니다 :)
영상에서는 위 개념들이 실제 사례에서 어떻게 적용되는지에 대한 예시입니다!
꼭 보시는 것을 추천드려요!
'클라우드' 카테고리의 다른 글
| [1]클라우드는 선택이 아닌 필수! (0) | 2023.04.26 |
|---|