AWS Partner Course : Container

0. 사전준비

https://cloud.google.com/learn/what-are-containers?hl=ko 

컨테이너란?  |  Google Cloud

- Container : 컨테이너는 소프트웨어 서비스를 실행하는 데 필요한 특정 버전의 프로그래밍 언어 런타임 및 라이브러리와 같은 종속 항목과 애플리케이션 코드를 함께 포함하는 경량 패키지. 컨테이너는 이러한 방식으로 운영체제를 가상화한다.

- Container vs VM

• 컨테이너는 VM보다 훨씬 더 경량
• 컨테이너는 OS 수준에서 가상화되고 VM은 하드웨어 수준에서 가상화
• 컨테이너는 OS 커널을 공유하며 VM에 필요한 것보다 훨씬 적은 메모리를 사용

- Container의 장점

• 독립성: 이 아키텍처는 클라우드 네이티브 애플리케이션을 서로 독립적으로 구축할 수 있도록 해줍니다. 이는 각각의 애플리케이션을 개별적으로 관리하고 배치할 수도 있다는 의미입니다.
• 복원성: 잘 설계된 클라우드 네이티브 애플리케이션은 인프라스트럭쳐가 중단되어도 온라인 상태를 유지할 수 있습니다.
• 표준 기반: 상호 운용성과 작업 로드 이식성을 위해 클라우드 네이티브 서비스는 오픈 소스 및 표준 기반 기술에 기반하는 경우가 많습니다. 이를 통해 벤더 종속성이 줄어들고 이동성이 향상됩니다.
• 비즈니스 민첩성: 클라우드 네이티브 애플리케이션은 네트워크에서 유연한 배포 옵션을 제공하며, 기존의 앱보다 작기 때문에 보다 쉽게 개발, 배포,반복 작업을 수행할 수 있습니다.
• 자동화: 클라우드 네이티브 애플리케이션은 DevOps 자동화 기능을 사용하여 정기적으로 릴리스되는 소프트웨어 변경 사항을 지속적으로 전달 및 배포할 수 있습니다. 또한 개발자는 blue-green 및 카나리아 배포와 같은 방법을 사용하여 사용자 경험을 방해하지 않고 앱을 개선할 수 있습니다.
• 작동 중지 시간 없음: Kubernetes와 같은 컨테이너 통합관리자 덕분에 기본적으로 다운타임 없이 소프트웨어 업데이트를 배포할 수 있습니다.

 

- Cloud

 

- On-Premise, Serveless

 

 

 

1. 클라우드 네이티브

- 정의

• 클라우드 제공 모델에서 제공하는 분산 컴퓨팅을 활용하기 위해 애플리케이션을 구축 및 실행하는 개념을 의미.
• 클라우드 네이티브 앱은 클라우드가 제공하는 확장성, 탄력성, 복원성, 유연성을 활용하도록 설계 및 구축된다.

 

 

-  App modernization : 클라우드 네이티브 개발

• 현재 트렌드는 일단 핵심기능을 탑재해서 빠르게 시장에 내놓는다.(속도)
• 이 후 고객의 피드백을 통해 신속하게 발전시킨다.(민첩)
• 이를 위해
  1. 아키텍쳐 변화 : Monolitihic → Micro Service Architecture로 변화 필요
  2. 운영 모델 : 어플리케이션을 구동하기 위해 HW, 인프라에도 많은 공수가 필요 → 직접 관리하지 않고 필요에 따라 
  3. 소프트웨어 딜리버리(배포 방식) : dev/prod 환경 일관성 유지에 시간 소비(dev(=CI)Ops(=CD))
  와 같은 과정을 자동화
• 이렇게 적용한 어플리케이션을 클라우드 네이티브라고 하며, 최적의 형태를 컨테이너라고 함. (AWS에서는 이 컨테이너를 오케스트레이션하는 서비스를 제공)

 

 

(컨테이너와 MSA는 상호적으로 부상하는데 원인이 된 것 같다)

 

 

 

- 신속한 혁신

• 어플리케이션 구성 요소화 : 마이크로 서비스
• 어플리케이션 수명 주기 보호 : 보안 자동화
• 인프라 간소화 : 관리형 서비스
• 실험 활성화 : 소규모 팀(= single threaded team, ownership)
• 빠른 업데이트 : CI/CD 자동화
• 운영 표준화 : Infrastructure as code(→ Container)
• 성능 및 안정성 향상 : 관측성(자동화처리된 것을 확인해야하니까)

 

- MSA의 장점 : compare with Monolithic

• 특정 서비스에 대한 서버 부하가 올 경우, 전체에 영향X 및 효율적인 서버 증설 
• 서비스마다 적합한 도구 선택 가능
• 안전하게 민첩성 향상 → 복원력 및 보안 개선
• 세분화된 확장으로 비용절감
• 위와 같은 장점들로 실험 및 혁신을 활발하게 가능한 환경

 

 

(모든 장점을 관통하는 장점은 각각의 서비스에 맞추어 효율적이고 최적화된 환경에서 개발이 가능하다는 것 같다)

 

 

 

- MSA 당면 과제

• 개별 서비스 및 API의 수와 복잡성 증가(→ 물리적, 기술적 분리된 서비스 관리 필요)
• 아키텍처, 모니터링 및 보안요구사항의 진화
• 조직 및 문화 차원이 변화 필요

→ 컨테이너 기술로 해결

 

 

- 컨테이너란

• 코드, 런타임환경, 시스템 도구, 라이브러리, 설정 파일 등 애플리케이션 구동에 필요하 모든 것들을 실행 가능 하도록 묶은 일종의 SW 패키지
• 컨테이너는 CPU, Memory, Storage, 네트워크 리소스를 OS 수준에서 가상화하여(↔OS를 포함하는 것은 아님) 다른 어플리케이션으로부터 논리적으로 격리된 샌드박스 환경을 제공
• Docker는 컨테이너를 보다 사용/관리하기 쉽게 만든 것(= 컨테이너 런타임)
• 어플리케이션 아티팩트 패키징
  code, configuration, runtime engine, dependencies
  ↔ 컨테이너
  OS host ↔ 컨테이너 런타임 ↔ 컨테이너
• 기본 하나의 host OS 사용
• 환경에서 SW 격리(각각의 프로세스를 가짐)
  → 컨테이너 이미지(어플리케이션 실행에 필요한 모든 것을 가진 파일) 필요
  컨테이너 이미지는 컨테이너 간 공유 가능(read only 라이브러리)
  컨테이너는 컨테이너 이미지를 가지고 실행시킨 인스턴스
  컨테이너 이미지 : 컨테이너 = read only 아티팩트 : read&write 인스턴스

 

- On-Premise / VM / Container

 

- 컨테이너의 이점

• 이동성 : 이동식 런타임 어플리케이션 환경
• 불변성 : 변경 불가능한 단일 아티팩트(= 컨테이너 이미지)
  cf) 컨테이너 이미지로 여러 개의 컨테이너 인스턴스 생성 가능
• 유연성 : 동시에 여러버전 실행
  ex) 8:2로 구버전, 신버전 배포상태로 서서히 신버전 비율 늘려갈 수 있음
• 속도 : 개발 주기 가속화
• 효율성

 

- Docker란