일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 최소권한
- terraform기초
- GDPR
- aws따라하기
- aws기초
- 직무분리
- AWS구축
- linux명령어
- terraform따라하기
- AWS실습
- blue/green배포
- AWS 공격테스트
- 리눅스기초
- Linux
- 리눅스기초명령어
- aws기본
- 쉘스크립트
- AWS CI/CD
- Cissp sdlc
- AWS배포자동화
- 리눅스명령어
- 리눅스
- AWS CodeDeploy
- opt/anaconda3/bin/jupyter_mac.command
- aws terraform
- aws
- 주피터노트북 설치
- cissp
- terraform with aws
- terraform기본
ysuekkom의 IT study note
클라우드, 도커, 컨테이너, 쿠버네티스 ? 본문
이번 포스팅에서는 데브옵스, 클라우드를 검색하면 따라나오는 도커와 컨테이너 그리고 쿠버네티스(k8s)에 대해서 정리해보는 시간을 가지려고 한다. 많이 접하고 들어봤지만, 그래서 그게 뭔데!라고 하면 말로 설명하기 쉽지 않아 하는 사람들이 많다.
아 그게, 그러니까, 그래 그거!
본 포스팅에서는 대략적인 구조와 관계에 대해서 "간단히" 정리하는 포스팅이다. 사전적인 개념 정의나 각각 개념에 대한 상세한 내용은 구글링을 통해 검색하길 바란다.
정리해보자!
클라우드 이해하기
클라우드를 이해하기 위해서 3가지 개념을 먼저 짚고 넘어가보자.
●CSP(Cloud Service Provider)
CSP는 말 그대로 클라우드 서비스 제공자를 말한다. 3개 CSP는 현재 AWS(아마존), Azure(마이크로소프트), GCP(구글)가 있다. 국내 CSP 사업자로는 KT, NAVER, NHN등이 있다. 국내 점유율은 23.3월 기준 1위 AWS, 2위 KT, 3위 네이버클라우드이다.
각 CSP 사업자별 특징(강점 등)과 기업에서 CSP 선택 시 고려할 사항에 대해서는 여기를 참고하자.
●MSP(Managed Service Provider)
MSP는 CSP가 제공하는 클라우드를 판매하고 서비스를 제공하며 운영한다. 기술지원 및 컨설팅 교육 등을 제공하는 사업자로 보면 된다. 대표적인 MSP로는 메가존클라우드, 베스핀글로벌, SK C&C, LG CNS 등이 있다.
●ISV(Independent SW Vendor)
CSP에 전문 SW를 제공하는 사업자로 보안, NW, 모니터링 솔루션을 제공한다. 기술 요구 사항을 해결하기 위한 모든 유형의 SW, SaaS 제품을 제공하는 사업자다. Cisco, GitLab, Redhat, HashCorp 등등 솔루션별 굉장히 많은 기업들이 있다.
다음으로 클라우드를 어디까지 제공할 것인지에 따라, IaaS, PaaS, SaaS로 나뉘게 된다. 기본적으로 클라우드는 공동책임모델을 가지며, 각 서비스에 따라 보안 책임 범위가 조금씩 달라진다.
●IaaS(Infrastrucure as a Service)
가상화, 서버, 스토리지, 네트워크 등 "확장성이 높고 자동화된 컴퓨팅 리소스를 가상화하여 제공"하는 서비스이다. 즉 인프라를 제공한다고 생각하면되고, 서비스를 제공받는 기업의 관리 영역은 Application ~ OS단 까지로 본다.
●PaaS(Platform as a Service)
응용프로그램 개발에 필요한 플랫폼을 제공하는 서비스로, 간단히 말해 기업은 개발만 수행하면 되는 모델로 보면 된다. 즉, 런타임 ~ NW까지 클라우드를 서비스로 제공받으며, 기업 관리 영역은 Application & Data가 된다.
●SaaS(Software as a Service)
개발도 필요 없이 모든 것을 CSP사가 서비스 형태로 제공하는 구독형 모델이다. 예를 들어 Office365, Google WorkSpace 등이다. CSP사가 Application ~ NW 모두를 제공한다.
●CaaS(Containers as a Service)
컨테이너 기반 추상화/가상화로 애플리케이션을 관리하고 배포할 수 있도록 지원하는 클라우드 서비스.
컨테이너화 된 애플리케이션의 통합/배포를 서비스하기 때문에 벤더사에 종속되지 않아 엔터프라이즈 유연성을 가지며, 이동성, 간편한 유지관리, 배포 속도 향상, 비용 절감 등의 이점이 있다.
참고
k8s 와 CaaS의 차이점
컨테이너를 관리한다는 점에서 관련성이 있으나, k8s는 컨테이너 플랫폼(인프라 솔루션)이고
CaaS는 컨테이너를 관리하는 구독 기반 서비스(관리 솔루션)이다.
CaaS는 종종 컨테이너 관리를 위해 k8s를 사용한다.
k8s를 통해 LB 등을 수행하며, 배포된 애플리케이션의 상태를 관리한다.
클라우드 서비스 배포 모델에 대해서 알아보자.
1. Private
내부 데이터센터 혹은 전산실에 구축하는 형태로 생각하자. 보안 강화가 강조되는 환경 은행이나 공공기관 등에 사용되며, 주요 클라우드 서비스를 인터넷에 연결하지 않고 사용한다.
public클라우드 환경에서 제공되는 서비스가 제공되지 않을 수 있다. 실제 필요한 서비스를 확인 후, 구성이 필요하다.
2. Public
클라우드 소스(서버/NW)를 타사 CSP가 소유하고 운영한다. Internet을 통해 제공되는 형태이다.
즉, 모든 HW/SW/기타 인프라를 클라우드 공급자가 소유하고 관리하는 형태이다.
장점으로는 사용한 서비스의 요금만 지불하게 되어 초기 투자비에 대한 부담이 없다.
스타트업과 같은 소규모 신생 기업에게 인프라 운영 비용을 효율적으로 가져갈 수 있다.
3. Hybrid
퍼블릭클라우드와 프라이빗클라우드를 함께 사용하며 유연하게 운영하는 방법이다.
퍼블릭클라우드와 프라이빗 클라우드의 장점을 모두 가져갈 수 있다. 웹서버나 글로벌 컨텐츠는 퍼플릭클라우드로, 기업의 기밀과 보안관련된 사항은 프라이빗클라우드로 유연하여 사용한다.
4. Muti
2곳 이상의 CSP사 클라우드를 사용하는 구성(public or private)으로, 많은 Enterprise기업이 사용한다.
그 이유로는(장점) 벤더사에 종속되지 않으며,
-서비스 가용성과 연속성을 높일 수 있음(무중단)
-서비스 요구 수준에 따라 각기 다른 CSP사 선택 가능(유연성)
-시스템 백업용으로 사용(안정성/이중성) 이 있다.
-관리의 복잡성(기술 스택에 대한 가시성 확보 어려움)
-대기 시간 증가(CSP사 간 딜레이 발생 가능)
-각 CSP의 인터페이스 및 SW의 종류가 많아짐에 따라 취약성 증대(공격 표면 증가) 등의 단점이 있다.
클라우드 네이티브란?
클라우드의 이점을 극대화하는 것으로, 클라우드 컴퓨팅 모델의 장점을 최대한 활용할 수 있는 애플리케이션을 구축하고 개발하여 실행하는 방법론을 의미한다.
즉, DevOps, CI/CD등 앞서 설명한 온프레미스, 하이브리드, 멀리클라우드로 자유롭게 확장가능하고, 안정적인 인프라 기술을 제공하는 것으로 보면 된다. 기업의 우선 순위에 맞게 설계가 가능하며, 인프라의 유연성을 확보하기 위해 클라우드 네이티브의 중요성은 기업 경쟁력과 이어진다. 아주 중요하다고 생각한다.
클라우드 네이티브 핵심 기술
1. MSA
서비스의 형태가 변하면서 모바일과 웹 환경의 API 통신으로 변화하였다.
각각의 서비스를 작게 쪼개어 컴포넌트 별로 나누어 조합하는 방법이다.
이렇게 쪼개어진 컴포넌트는 서비스 형태로 구현되어 API를 이용, 다른 서비스들과 통신하게 된다.
2. Agile
기존 SW 개발 모델의 WaterFall 방식에서 애자일 방식으로의 변화다.
전 단계가 끝나야 그 다음 단계로 넘어가며 각 스텝별로 결과물이 있었던 Waterfall 모델과는 달리,
작업 계획을 짧은 단위로 세우고, 개발하여 신속하고 유연한 개발/대응이 가능한 방법이다.
3. DevOps
데브옵스는 Develop + Operation의 혼용어로 개발과 운영을 함께하는 개발 방법론이다.
기존 개발과 운영의 각기 다른 수행으로 인해 오는 간극을 최소화하고 유연하고 신속하게 대응할 수 있다.
4. Cloud
도커와 컨테이너의 등장 배경
인프라
클라우드의 가상서버 환경은 동일한 Hypervisor위에서만 실행된다.
즉, CSP1의 hypervisor1에서 생성한 가상서버는 CSP2의 hypervisor2위에서 실행할 수 없다는 것이다.
하지만 멀티클라우드를 사용하는 기업처럼 여러 CSP사를 이용하는 기업은 어떻게 하는걸까?
위에서 언급한 유연한 클라우드 네이티브 구현을 어떻게 해야할까?
이때 바로 컨테이너가 등장한다!
컨테이너(Container)?
운영체제를 가상화한 개념으로, 가상서버에서 실행되는 애플리케이션 등을 가상서버처럼 동작하도록 만든 것이다. 즉, 운영체제가 아닌 하나의 실행파일이다. 컨테이너는 "도커"라는 컨테이너 엔진을 사용한다.
컨테이너 엔진이 같으면 어떤 Hypervisor에서든 사용가능하게 된다. CSP마다 다른 Hypervisor를 사용하는데, 이 말은 즉 컨테이너 엔진만 같으면 어떤 CSP에서든 사용이 가능하단 소리다.
즉 도커환경이면 다~ 호환된다는 말!
멀티클라우드와 클라우드네이티브 구현을 위해서 반드시 도커가 필요한 이유가 되겠다.
클라우드 네이티브 핵심 요소
1. Container
SW 개발부터 실행까지 한 번에 제공한다. 어디서든 빠르고 쉽게 배포 및 운용 환경을 가능하게 하는 핵심 요소
도커(Docker)에 애플리케이션에 필요한 모든 실행 파일과 라이브러리 존재
-개발자 입장: 앱 인프라(공통) 환경 제공, MSA 지원, 빠른 개발 및 테스트 환경을 제공
-운용자 입장: 간편한 구축 및 운용, 표준화된 개발, QA 프로덕션 환경 제공, 높은 컴퓨팅 밀도, 요구사항에 따른 손쉬운 인프라 확장 및 축소 가능
>>컨테이너 도입 후 컨테이너 이미지 하나면 소스코드 -> 컨테이너 이미지 -> Registry(컨테이너 이미지 저장) -> 각 CSP or 온프레미스
컨테이너 장점
-경량화(빠른 속도)
-효율성: OS 영역을 공유, 자원 할당이 필요 없음
-이식성: 컨테이너 작동 환경이면 어디서든 이식하여 애플리케이션 실행 가능
-비용절감, 확장성, 무중단 서비스 etc..
2. MSA
Micro Service Architecture의 약자로 Loose Coupling(느슨한 결합)을 의미한다. 각 서비스들이 독립적으로 실행되고 서로 통신하지만, 문제 발생 시, 서로 크게 영향을 받지 않는 유연한 서비스 구조를 일컫는다.
클라우드에서 애플리케이션을 개발하면 어떤 구조로 아키텍처를 설계할까?
모놀리딕 아키텍처와 마이크로 서비스 아키텍처가 있다.
-모놀리딕 아키텍처
-마이크로서비스 아키텍처
모놀리딕의 단점을 커버한다.(모놀리딕의 단점이 MSA의 장점)
독립성, 효율성, 신속한 적용이 가능하다.
하지만 아래와 같은 단점이 수반된다.
- 관리가 어려움
- 서비스 통신이 복잡하며, 관리가 어렵다
- 데이터 정합성 확보가 어렵다: 서비스간 트랜잭션이 보장되지 않아 실패에 대한 정합성을 보장하지 않기 때문
MSA 도입 시 고려 사항**
1. Why
도입 목적을 명확히 해야한다. 단점과 장점의 특성을 파악하여, 비즈니스 모델과의 결합을 통해 최적 효율을 설계해야한다.
2. 기술&조직&운영의 모든 관점을 고려해야 한다.
3. 도입에 필요한 기술의 이해가 필수적이다.
API, 부하분산, 서비스 Mesh 구조, 변화관리, 형상관리, DevOps, 이벤트 처리, 로그 관리 등등..
MSA 설계 원칙
1. 느슨한 결합으로 상호 의존성을 낮춘다. 독립적인 기능 수행을 목표로 함
2. 효율적 운영
-Service Mesh 구조로 설계하기
매 순간 통신해야하는 MSA를 찾고, 연결하는 과정을 자동화하며 로드밸런싱 기능 수행
-Service 앞단 Proxy(SideCar)
서비스 장애 시, 각 Proxy별 공유를 통해 장애 전파를 방지한다. 부하분산으로 전체 서비스 품질을 향상시킴
3. 쿠버네티스(k8s)
"컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈 소스 시스템"
컨테이너의 개발과 운영의 효율성을 극대화 하는 것으로 Container Orchestration이다. 컨테이너 관리 자동화 도구로 보면 된다.
(서비스 추가 > 컨테이너 추가 > 가상서버 연결 > 리소스가 여유로운 가상서버에 컨테이너 생성 ...etc : 스케줄러 확인 등)
쿠버네티스 장점
1. 애플리케이션 배포 단순화
애플리케이션에 필요한 리소스 관리, 배포, 모니터링 자동화 기능
2. HW의 효율적인 활용 가능
리소스 사용량을 기반으로 HW 리소스를 최적 사용, 관리 할 수 있음
3. 자동복구 및 오토스케일링
가용성과 신뢰성을 확보할 수 있음
멀티 클라우드 환경에서의 k8s
타 CSP 업체에서도 설치/관리 가능한 통합 관리 솔루션을 제공한다. 따라서 CSP사에 따라 설치/관리 가능한 통합 관리 솔루션을 제공한다.
-AWS: EKS
Amazon Elastic Kubernetes Service로 AWS 클라우드와 온프레미스 데이터센터에서 k8s를 실행하는데 사용되는 관리형 AWS의 k8s 관리형 서비스.
- 가용성과 확장성 제공: Container 예약, 애플리케이션 가용성 관리, 클러스터 데이터 저장
- 신뢰성 제공 및 가용성 활용: AWS의 관리형 서비스(모니터링, 보안 등)의 성능 활용 및 통합 제공
- 일관성: 온프레미스에서 AWS EKS로의 연속성 및 일관성 제공
-GCP: Cloud Anthos
-Azure: Azure Arc
4. DevOps
사용자에게 안정성과 신속성을 제공하기 위해서는 "개발 > 테스트 > 배포 > 운영"의 프로세스 통합이 필요해졌다.
DevOps는 개발과 개선, 운영을 빠르게 수행할 수 있게 한다. 즉 무중단 서비스 기반 CI/CD를 가능하게 한다.
개발과 운영간 프로세스를 Seamless하게 연결하고, 자동화 방법을 통해 개발 및 배포 효율성을 극대화 한다.
CI/CD?
-CI: Continuous Integration, 지속적인 통합 "개발>통합>저장>빌드>테스트"
-CD: Continous Deployment
애플리케이션 개발 단계를 자동화하여, 사용자의 니즈와 기능 개선 등을 짧은 주기로 제공하는 방법이다.
기본적인 개념은 지속적입 통합, 지속적인 서비스 제공, 지속적인 배포에 있다.
개발 및 테스트, 배포에 이르는 애플리케이션의 라이프사이클 전체를 지속적인 자동화와 지속적인 모니터링을 제공하며, 이를 CI/CD 파이프라인이라 한다.
기존의 WaterFall 방식에서 벗어난 Agile 방식으로, DevOps or SRE(Site Responsibility Engineering)방식으로 지원 된다.
"실행 파일 테스트>배포>운영>모니터링"을 하나의 파이프라인으로 구성하여
언제나 즉시, 신속하고 간편하게 배포가능하게 함
간단 요약
1. 초기 클라우드 도입 시 CSP사(공급사) 별 하이퍼바이저에 따라 App이 실행되지 않음.
2. 컨테이너 개발 및 운영 환경이 확장 됨.
3. 다른 하이퍼바이저 환경에서 개발된 App이어도 컨테이너 엔진이 같으면 실행 됨.
4. 컨테이너 엔진 도커의 등장과 확장 배경.
5. 컨테이너 관리 도구인 쿠버네티스의 등장.
마치며
수없이 많이 들어봤을 도커, 컨테이너, CI/CD, 쿠버네티스 등등에 대한 전반적인 연결성과 개념 이해에 도움이 되었으면 좋겠다.
"간단히" 정리하자면, 클라우드가 도입되면서 CSP사 즉, 클라우드 공급사에 따라 다른 하이퍼바이저를 사용하는데, 개발 당시 환경의 하이퍼바이저가 아니면 애플리케이션이 실행되지 않는다.
멀티 클라우드(여러 CSP사의 클라우드 서비스를 사용하는 것) 환경에서 이는 문제가 되었고, 이 문제점을 해결하는 것이 바로 도커이다. 도커는 컨테이너 엔진인데, 컨테이너 엔진이 같으면 다른 하이퍼바이저 환경에서 개발된 애플리케이션이라고 해도 실행이 되기 때문이다.
이 도커(=컨테이너 엔진)와 함께 등장한 것이 바로 쿠버네티스다. 쿠버네티스는 컨테이너 오케스트레이션으로, 컨테이너 관리 도구이다.
(참고)
https://kubernetes.io/ko/docs/concepts/
https://www.samsungsds.com/kr/insights/how_to_choose_a_csp.html
https://aws.amazon.com/ko/eks/features/
https://namu.wiki/w/%EC%95%A0%EC%9E%90%EC%9D%B
https://www.redhat.com/ko/topics/devops/what-is-ci-cd
https://www.samsungsds.com/kr/insights/220222_kubernetes1.html