원티드 프리온보딩 백엔드-Docker-4일차

전체 과정 설명

과정 설계 - 이론 + 실습시연 + 실제 면접 질문 + QnA(매 교시 시작시간 10분 + 수업 마지막 시간 30분 전 - QnA시간양은 유동적으로 조정)
- 4회동안 compact 하게 큰 그림을 그려봅시다 - 세부 사항 학습 자습 병행 (mac os / windows)
- 20% 핵심
포트폴리오에 어떻게 적용되는지 - 서비스 운영환경에 대한 경험 - 운영환경 구축 - CI/CD, 컨테이너

싱글 서버 도커의 한계 -> 쿠버네티스
배포 기본기 : 용어 / 배포 전략
추천 아키텍쳐
실습 - github action 사용해서 ecr 에 업로드하기
- AWS cloud 사용할 때 체크포인트
자습키워드 - 면접 질문

쿠버네티스란?

서버의 한계에서부터 생각해봅시다
- 물리적으로 서버 한대에 도커가 설치가 됨. 사용자가 늘어나서 서버를 늘려야한다면?
- -> [면접] 사용자가 늘어나는데 서버를 어떻게 바꾸어야할까요? - [용어] 스케일 업/아웃
  - 1. 사용자 수가 늘어날 때 서버를 늘리는 것은 일반적으로 필요한 조치.
  1. 성능 유지
  - 서버는 동시에 처리할 수 있는 요청의 수에 한계가 있습니다. 사용자 수가 증가하면, 동시 요청의 수가 늘어나고 이는 서버의 처리 능력을 초과할 수 있습니다. 서버를 늘려서 이러한 요청을 효과적으로 분산시키면, 시스템의 응답 시간을 개선하고 사용자 경험을 유지할 수 있습니다.
  1. 가용성 향상
  - 단일 서버에 문제가 발생하면 전체 서비스에 영향을 미칠 수 있습니다. 서버를 여러 대 운영하면 하나의 서버에 문제가 생겨도 다른 서버가 처리를 계속 수행할 수 있어 서비스의 중단 시간을 줄일 수 있습니다. 이는 고가용성을 보장하는 데 중요합니다.
    - [용어] 가용성 -> 지표! -> 메트릭스로 측정해서 표현해줄 수 있음
      - 서버에서 “가용성”이란 서버 또는 네트워크 시스템이 계획된 운영 시간 동안 얼마나 안정적으로 접근 가능하고, 정상적으로 기능하는지를 나타내는 지표입니다. 기본적으로, 가용성은 시스템이 사용자의 요구를 충족시키며 요청된 서비스를 제공할 수 있는 능력을 의미합니다.
      - 가용성의 중요 요소
        연속성과 신뢰성: 시스템이 예상치 못한 중단 없이 지속적으로 작동하고, 예정된 유지 관리 외에 다운타임이 최소화되어야 합니다.
        복구력: 시스템이 장애 발생 후 얼마나 빠르게 정상 상태로 복구될 수 있는지도 가용성에 중요합니다. 장애 복구 계획과 백업 시스템이 이를 지원합니다.
        확장성: 사용자 수나 데이터량의 증가 등, 시스템에 대한 요구가 변화할 때 시스템이 이를 수용하고 성능을 유지할 수 있는 능력.
      - 가용성을 높이는 방법
        하드웨어 중복: 중요한 서버 및 네트워크 구성요소를 복제하여 하나가 실패해도 다른 하나가 기능을 지속할 수 있게 합니다.
        로드 밸런싱: 여러 서버에 걸쳐 트래픽을 분산시키는 방법으로, 하나의 서버에 문제가 발생하더라도 전체 시스템이 계속 작동하도록 합니다.
        장애 조치(failover) 시스템: 주 서버가 실패할 경우 자동으로 백업 시스템으로 전환하여 운영을 지속할 수 있게 하는 시스템입니다.
        정기적인 백업 및 복구 테스트: 데이터를 정기적으로 백업하고, 장애 발생 시 복구 프로세스가 효과적으로 작동하는지 주기적으로 테스트합니다.
        분산 아키텍처: 지리적으로 분산된 데이터 센터를 사용하여 자연 재해나 지역적 장애의 영향을 최소화합니다.
      - 가용성의 측정
        가용성은 주로 퍼센테이지(%)로 표현되며, “업타임”이라고도 불립니다. 예를 들어, “99.9% 가용성”이라고 하면, 시스템이 한 해 동안 0.1%의 시간만큼만 작동하지 않는다는 것을 의미합니다. 이는 연간 대략 8.76시간의 다운타임에 해당합니다. 가용성이 높을수록 시스템이 더욱 신뢰성 있고 지속적으로 서비스를 제공할 수 있다는 것을 의미합니다.
        https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/reliability-pillar/availability.html
        가용성은 비즈니스 연속성과 직결되며, 고객 만족도 및 기업의 신뢰성을 결정하는 중요한 요소. 따라서 높은 가용성을 유지하는 것은 모든 IT 운영의 핵심 목표 중 하나
    - [팔로우업] 내 애플리케이션의 가용성을 테스트로 측정할 수 있을까?
      - 이 중 ‘부하테스트’는 꼭 해보세요!
      - 애플리케이션의 가용성을 테스트하고 측정하기 위한 몇 가지 방법 이러한 테스트는 애플리케이션의 신뢰성과 장애 대응 능력을 평가하는 데 중요.
      1. 모니터링 도구 사용
      - 실시간 모니터링: 애플리케이션과 인프라의 실시간 모니터링을 통해 성능 지표를 지속적으로 추적할 수 있음. 예를 들어, Datadog, New Relic, Prometheus 같은 도구들은 시스템의 중요한 메트릭을 수집하고, 문제가 발생할 때 알림을 제공함.
      - Uptime 모니터링 서비스: Uptime Robot, Pingdom 등의 서비스를 사용하여 애플리케이션의 가용성을 주기적으로 체크하고, 다운타임이 발생했을 때 즉시 알림을 받을 수 있음.
      1. 부하 테스트
      - 부하 테스트 도구 사용: Apache JMeter, Gatling, LoadRunner와 같은 도구를 사용하여 애플리케이션에 고객 예상 트래픽 이상의 트래픽을 생성하고, 애플리케이션의 성능을 측정함. 이를 통해 트래픽 증가 시 애플리케이션의 반응을 확인하고 최적화할 수 있음.
      1. 장애 조치(Failover) 테스트
      - 재난 복구 시나리오 실행: 정기적으로 장애 조치 테스트를 실행하여, 주요 시스템 구성요소가 실패했을 때의 대응을 평가함. 예를 들어, 데이터베이스 서버가 다운되는 경우, 자동 장애 조치가 얼마나 잘 작동하는지를 확인할 수 있음.
      1. 카오스 엔지니어링
      - 카오스 몽키 도구 활용: Netflix의 Chaos Monkey와 같은 도구를 사용하여 의도적으로 인프라 내에 장애를 일으켜 보고 시스템이 이를 어떻게 처리하는지 관찰함. 이는 시스템의 복원력을 강화하고 잠재적인 취약점을 발견하는 데 유용함.
      1. 벤치마킹
      - 성능 벤치마킹: 다른 유사 애플리케이션 또는 이전 버전의 애플리케이션과의 성능을 비교 분석함. 이를 통해 현재 애플리케이션의 성능 지표가 업계 표준이나 기대치를 충족하는지 평가할 수 있음.
      - 이러한 방법을 통해 애플리케이션의 가용성을 정기적으로 검토하고 평가함으로써, 시스템의 안정성을 유지하고 사용자 만족도를 높일 수 있음. 이는 또한 미래의 확장성 및 유지 관리 계획에 중요한 데이터를 제공함.

(계속) [면접] 사용자가 늘어나는데 서버를 어떻게 바꾸어야할까요? - [용어] 스케일 업/아웃
1. 부하 분산
- 서버를 추가하면 네트워크 트래픽과 데이터 처리 부하를 여러 서버에 분산시켜 각 서버의 부하를 줄일 수 있습니다. 이로 인해 각 서버가 더 안정적으로 운영될 수 있고, 전체 시스템의 효율성이 증가합니다.
- [용어] 부하
  - 서버에서 “부하”는 일반적으로 서버나 네트워크 시스템이 처리해야 하는 데이터 양, 요청 수, 또는 동시 사용자 수 등으로 인해 발생하는 작업량이나 스트레스를 의미함. 서버 부하가 증가하면, 서버의 성능에 직접적인 영향을 미칠 수 있음.
  - 부하의 주요 유형
    1. CPU 부하: 서버의 중앙 처리 장치(CPU)가 처리해야 하는 작업의 양임. 많은 계산이 필요한 작업이나 애플리케이션은 CPU 부하를 증가시킬 수 있음.
    2. 메모리 부하: 서버에서 사용 가능한 물리적 또는 가상 메모리가 충분하지 않을 때 발생함. 메모리가 포화 상태에 이르면 시스템의 성능이 저하될 수 있음.
    3. 디스크 I/O 부하: 디스크 읽기/쓰기 작업의 양이 많을 때 발생함. 데이터베이스 서버나 파일 서버는 디스크 I/O 부하가 높을 수 있음.
    4. 네트워크 부하: 네트워크를 통해 전송되는 데이터의 양이 많을 때 네트워크 부하가 발생할 수 있음. 이는 네트워크 속도를 저하시키고, 데이터 전송 시간을 증가시킬 수 있음.
  - 부하가 서버에 미치는 영향
    - 응답 시간 증가: 서버에 부하가 많을 경우, 처리 시간이 길어지고 사용자의 요청에 대한 응답이 늦어질 수 있음.
    - 시스템 다운: 부하가 지나치게 높아져서 서버가 더 이상 요청을 처리할 수 없는 경우, 시스템이 다운될 수 있음.
    - 리소스 경합: 여러 프로세스나 애플리케이션이 동시에 리소스를 요구할 때 발생함. 이로 인해 성능 저하가 나타날 수 있음.
  - 부하 관리 방법
    - 부하 분산 (Load Balancing): 부하 분산기를 사용하여 여러 서버에 요청을 균등하게 분배함으로써 각 서버의 부하를 줄일 수 있음.
    - 스케일링: 사용자의 요구와 트래픽에 따라 서버의 리소스를 증가시키거나 감소시키는 스케일 아웃(수평 확장) 또는 스케일 업(수직 확장)을 실행함.
    - 캐싱: 자주 요청되는 데이터를 캐시에 저장하여, 동일한 요청에 대해 서버가 반복적으로 같은 계산을 수행하는 것을 방지할 수 있음.
  - 부하 관리는 서버의 안정적인 운영과 최적의 성능을 유지하기 위해 필수적인 작업임. 서버 부하를 효과적으로 관리하면 시스템의 가용성을 향상시키고 사용자 만족도를 높일 수 있음.
1. 재난 복구
- 여러 지역에 서버를 분산시켜 두면 자연재해나 기타 예상치 못한 상황에서도 서비스의 연속성을 보장할 수 있습니다. 한 지역의 서버가 다운되더라도 다른 지역의 서버가 서비스를 지속할 수 있습니다.
1. 데이터 처리 능력 증가
- 사용자가 늘어남에 따라 데이터 처리 요구도 증가합니다. 데이터베이스 서버, 애플리케이션 서버 등을 추가함으로써 처리 능력을 높일 수 있습니다.
1. 확장성
- 사용자 수가 예상보다 빠르게 증가하는 경우, 시스템을 쉽게 확장할 수 있어야 합니다. 서버를 추가하는 것은 이러한 확장성을 제공합니다. 특히 클라우드 환경에서는 수요에 따라 자원을 신속하게 확장하고 축소하는 것이 가능합니다.
이러한 이유로, 사용자가 늘어남에 따라 서버를 적절하게 늘려 시스템의 안정성, 성능, 가용성을 유지하는 것이 중요합니다. 서버를 확장하는 것은 비용 증가로 이어질 수 있지만, 이는 사용자 만족도와 직결되므로 투자할 가치가 있습니다.

서버의 규모Scale 을 키워야한다.
그 중 현대에는 스케일 아웃 전략을 많이 사용함.
현대의 IT 인프라와 애플리케이션 설계에서 “스케일 아웃(Scale Out)” 즉, 수평 확장 방식을 더 많이 사용하는 이유는 여러 가지가 있음. 이 방법은 시스템의 처리 능력을 증가시키기 위해 추가적인 하드웨어 유닛이나 노드를 서버 클러스터에 추가하는 것을 의미함. 다음은 스케일 아웃을 선호하는 주요 이유들임:

유연성과 확장성
스케일 아웃은 서버나 리소스를 필요에 따라 추가하거나 제거할 수 있어 매우 유연함. 사용자 수나 처리해야 할 데이터가 증가함에 따라 서버를 추가적으로 배치하여 쉽게 확장할 수 있음. 이는 빠르게 변화하는 비즈니스 요구사항과 트래픽 패턴에 효과적으로 대응할 수 있게 해줌.
비용 효율성
수평 확장은 일반적으로 추가적인 고성능 서버를 구매하는 것보다 비용 효율적임. 저렴한 표준 하드웨어나 클라우드 리소스를 사용하여 시스템을 확장할 수 있기 때문에 초기 투자 비용과 운영 비용을 낮출 수 있음.
고가용성
스케일 아웃 아키텍처는 자연스럽게 고가용성을 제공함. 여러 노드에서 애플리케이션을 운영함으로써 하나의 노드가 실패하더라도 시스템 전체의 가동 중단 없이 다른 노드가 작업을 계속 수행할 수 있음. 이는 비즈니스 연속성을 보장하며, 장애 복구 시간을 최소화함.
부하 분산
수평 확장을 통해 트래픽이나 작업 부하를 여러 서버에 분산시킬 수 있음. 이는 단일 서버에 과부하가 걸리는 것을 방지하고, 시스템의 전체적인 처리 성능을 향상시킬 수 있음.
기술 발전과 클라우드 컴퓨팅
클라우드 컴퓨팅 기술의 발전은 스케일 아웃을 쉽고 접근하기 쉬운 옵션으로 만듦. 클라우드 서비스 제공자들은 사용자가 손쉽게 리소스를 추가하거나 줄일 수 있는 유연한 서비스를 제공함. 또한, 클라우드 기반의 스케일 아웃은 물리적 인프라에 대한 우려 없이 글로벌 사용자 기반을 효과적으로 서비스할 수 있게 해줌.

이러한 이유로, 스케일 아웃은 현대의 많은 조직들이 서버와 애플리케이션 인프라를 설계하고 확장하는 데 선호되는 접근 방식이 되었음. 이는 특히 데이터 집약적이고 사용자 수가 많은 애플리케이션에서 중요한 전략임.
-> 스케일 아웃을 통해 서버의 수가 늘어나고 도커 컨테이너의 수도 증가-> 이러한 컨테이너들을 효과적으로 관리하고 조정하는 것이 매우 중요해졌음-> 도커 오케스트레이션 기술의 대두

도커 오케스트레이션의 중요성

자동화된 관리: 도커 오케스트레이션 도구는 컨테이너의 배포, 관리 및 확장을 자동화하여, 수동 작업의 필요성을 크게 줄여줌. 이는 시간과 리소스를 절약할 수 있게 해줌.
확장성: 오케스트레이션 도구를 사용하면 컨테이너를 쉽게 스케일 아웃할 수 있음. 예를 들어, 트래픽이 증가할 때 자동으로 컨테이너의 수를 늘릴 수 있으며, 필요하지 않을 때는 줄일 수 있음.
부하 분산: 여러 컨테이너와 서버에 걸쳐 트래픽과 부하를 자동으로 분산시키는 기능을 제공함. 이는 서비스의 가용성과 성능을 향상시킴.
서비스 발견과 네트워킹: 오케스트레이션 도구는 컨테이너 간의 네트워킹과 서비스 발견을 관리함. 각 컨테이너가 필요한 리소스와 서비스를 찾아서 소통할 수 있도록 지원함.
상태 관리와 자가 치유: 시스템이 정의한 상태를 유지하도록 설정할 수 있으며, 문제가 발생했을 때 오케스트레이션 도구가 자동으로 문제를 해결하려고 시도함. 예를 들어, 실패한 컨테이너를 자동으로 재시작할 수 있음.

주요 도커 오케스트레이션 도구

Kubernetes: 현재 가장 널리 사용되는 컨테이너 오케스트레이션 플랫폼으로, 강력한 커뮤니티 지원과 다양한 기능을 제공함.
Docker Swarm: Docker에서 공식적으로 지원하는 오케스트레이션 도구로, Docker 엔진에 내장되어 있어 설정이 간편함.
Apache Mesos: 대규모 클러스터 관리에 적합하며, 데이터 센터를 하나의 리소스 풀처럼 다루어 높은 확장성과 장애 허용성을 제공함.
스케일 아웃 환경에서의 도커 오케스트레이션 도입은 이제 선택이 아닌 필수가 되었음. 이는 컨테이너화된 애플리케이션의 운영을 간소화하고, 자동화하며, 최적화하는 데 중요한 역할을 함.**

쿠버네티스

https://kubernetes.io/ko/

Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.
- It groups containers that make up an application into logical units for easy management and discovery.

논리적 단위로 그룹화! -> 파드

쿠버네티스에서 “논리적 단위로 그룹화한다”는 말은 컨테이너들을 효과적으로 관리하고 조정하기 위해, 관련 컨테이너들을 하나의 그룹, 즉 “파드(Pod)”라는 단위로 묶는 것을 의미함. 파드는 쿠버네티스에서 생성 및 관리되는 가장 작은 배포 단위이며, 일반적으로 서로 긴밀하게 협력하는 컨테이너들로 구성됨.
파드의 역할과 중요성

**공유 리소스와 통신**: 파드 안에 있는 컨테이너들은 같은 네트워크 네임스페이스와 스토리지를 공유할 수 있음. 이는 컨테이너들이 서로 통신하기 용이하게 하며, 필요한 데이터를 서로 쉽게 접근할 수 있게 해줌.
**컨테이너 조정**: 파드를 사용하면, 관련된 여러 컨테이너들을 한 그룹으로 관리할 수 있음. 이는 배포, 스케일링 및 관리를 간소화함. 예를 들어, 하나의 파드에 포함된 컨테이너들은 함께 시작되고 종료되며, 동일한 하드웨어 리소스를 공유함.
**서비스 디스커버리**: 파드는 하나의 로지컬 호스트로 취급됨으로써, 하나의 IP 주소와 포트 범위를 가짐. 이는 네트워크를 통한 서비스 발견과 라우팅을 단순화함.
**부하 분산과 자동 복구**: 쿠버네티스는 파드를 여러 노드에 걸쳐 자동으로 배포할 수 있으며, 파드가 실패할 경우 자동으로 복구(재시작)할 수 있음. 이를 통해 애플리케이션의 가용성과 내구성이 향상됨.
  - 파드를 사용하는 이유는 개별 컨테이너보다 관리가 더 용이하고, 특정 작업에 필요한 여러 컨테이너를 묶어 하나의 단위로 다룰 수 있기 때문임. 이는 복잡한 애플리케이션을 효율적으로 운영하는 데 큰 이점을 제공함.

https://kubernetes.io/ko/docs/concepts/overview/
쿠버네티스 구조
![1kSRH4T8S1YmAuHbpgQ3Ylw.png](https://miro.medium.com/v2/resize:fit:1200/1kSRH4T8S1YmAuHbpgQ3Ylw.png)
쿠버네티스는 복잡한 컨테이너화된 애플리케이션을 오케스트레이션하는 강력한 시스템임. 그 구조는 여러 컴포넌트와 리소스로 구성되어 있으며, 이들은 모두 함께 작동하여 애플리케이션의 배포, 관리, 확장을 자동화함. 쿠버네티스의 주요 구조는 다음과 같은 요소로 이루어짐:

마스터 노드 (Master Node)
- 마스터 노드는 쿠버네티스 클러스터의 제어 허브로서, 클러스터의 관리 및 조정을 담당함. 여기에는 여러 핵심 컴포넌트가 포함됨:
- API 서버 (kube-apiserver): 클러스터와의 모든 통신을 처리하는 엔드포인트임. 사용자, 외부 시스템, 클러스터 내부 컴포넌트들이 API 서버를 통해 상호작용함.
- 컨트롤러 매니저 (kube-controller-manager): 다양한 컨트롤러를 실행함. 이 컨트롤러들은 복제 컨트롤러, 엔드포인트 컨트롤러, 네임스페이스 컨트롤러 등이 있으며, 클러스터의 상태를 원하는 상태로 유지하는 데 필요함.
- 스케줄러 (kube-scheduler): 새로 생성된 파드를 적절한 노드에 배치하는 역할을 함. 파드의 요구 사항과 노드의 리소스 상태를 고려하여 배치 결정을 내림.
- etcd: 모든 클러스터 데이터를 저장하는 경량 데이터베이스 시스템임. 쿠버네티스의 모든 상태와 메타데이터를 저장하고, 클러스터의 신뢰할 수 있는 싱글 소스 오브 트루스로 작동함.
워커 노드 (Worker Nodes)
- 워커 노드들은 실제로 애플리케이션 컨테이너가 실행되는 서버임. 각 워커 노드는 다음과 같은 컴포넌트를 포함함:
- kubelet: 각 노드에서 실행되는 에이전트로, 마스터 노드의 지시를 받아 컨테이너가 파드 내에서 올바르게 실행되도록 관리함.
- kube-proxy: 네트워크 프록시 및 로드 밸런서 역할을 하는 컴포넌트로, 노드의 네트워크 규칙을 관리하고, 연결 및 트래픽 라우팅을 처리함.
- 컨테이너 런타임: 컨테이너를 실행하기 위한 환경을 제공함. Docker, containerd, CRI-O 등이 사용될 수 있음.
1. 추가적인 구성요소
  - 네트워크: 쿠버네티스는 파드 간의 통신을 위해 자체 네트워킹 모델을 제공함. 각 파드는 고유한 IP 주소를 가지며, 파드 간에는 플랫 네트워크에서 서로 통신할 수 있음.
  - 스토리지: 쿠버네티스는 볼륨을 사용하여 데이터를 저장함. 로컬
  - 스토리지, 네트워크 스토리지 (NFS, iSCSI 등), 클라우드 제공자의 스토리지 서비스 (예: AWS EBS, Azure Disk) 등 다양한 스토리지 옵션을 지원함.

쿠버네티스에서 노드(Node)는 파드(Pod)를 실행하는 물리적 또는 가상의 서버임. 파드는 쿠버네티스에서 기본적인 배포 단위로, 하나 이상의 컨테이너로 구성될 수 있음. 파드 내의 컨테이너들은 공유된 리소스와 정보를 가지며, 네트워크와 스토리지 같은 일부 측면에서 밀접하게 연관되어 함께 작동함. 이러한 구조는 파드가 독립적으로 배포하고 관리될 수 있도록 함과 동시에, 효율적으로 리소스를 공유할 수 있게 해줌.
파드의 구성 요소와 특징

컨테이너

파드는 하나 이상의 컨테이너를 포함할 수 있음. 이 컨테이너들은 동일한 네트워크 및 UTS(Unix Time Sharing) 네임스페이스를 공유하며, 필요한 경우 IPC(Inter-process Communication)를 통해 통신할 수 있음.
일반적으로, 각 파드는 하나의 주요 애플리케이션 컨테이너를 포함하고, 추가적으로 사이드카 컨테이너를 포함할 수 있음. 사이드카 컨테이너는 로깅, 모니터링, 네트워크 프록시 등의 보조 기능을 제공함.

공유 네트워크

모든 컨테이너는 동일한 IP 주소와 포트 공간을 공유함. 이는 외부에서 파드에 접근할 때 마치 하나의 엔티티처럼 보이게 하고, 컨테이너 간의 통신을 로컬호스트를 통해 가능하게 함.

공유 스토리지 볼륨

파드는 하나 이상의 볼륨을 정의할 수 있음. 이 볼륨은 파드 내의 컨테이너들 사이에 공유되어 파일 시스템을 통한 데이터 공유를 용이하게 함.
쿠버네티스는 다양한 유형의 볼륨을 지원하며, 이는 파드가 스토리지에 종속되지 않고, 어떤 노드에서든 동일하게 작동할 수 있도록 함.

생명주기와 관리

파드는 불변성을 가지며, 한 번 생성되면 그 내부의 컨테이너는 변경할 수 없음. 컨테이너를 업데이트 해야 할 경우, 파드를 새로 생성하고 교체하는 방식으로 처리함.
파드는 일반적으로 복제(replication)를 통해 고가용성을 보장받음. 쿠버네티스는 파드의 상태를 모니터링하고, 실패한 파드를 자동으로 대체하는 복제 컨트롤러나 레플리카셋을 사용하여 관리함.
노드 내에서 각 파드는 독립적인 실행 환경을 제공받으며, 노드의 리소스(CPU, 메모리)를 할당받아 사용함. 쿠버네티스 스케줄러는 파드를 적절한 노드에 스케줄링하여, 리소스 사용을 최적화하고 시스템의 전반적인 효율성을 높임. 이러한 구조 덕분에 쿠버네티스는 대규모, 분산된 컨테이너화된 애플리케이션의 관리를 간소화하고 자동화할 수 있음.
쿠버네티스 특징
- Self-healing
  - “쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, ‘사용자 정의 상태 검사’에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.”
- auto scaling
  - 쿠버네티스의 오토스케일링(auto-scaling)은 시스템이 자동으로 파드의 수를 조정하여, 변화하는 워크로드에 따라 애플리케이션의 리소스 요구를 충족시킬 수 있도록 해주는 기능임. 이는 특히 클라우드 환경에서 유용하며, 애플리케이션의 퍼포먼스를 유지하고 비용 효율성을 높이는 데 도움을 줌.
  - 쿠버네티스는 주로 두 가지 유형의 오토스케일링을 지원함:
  - Horizontal Pod Autoscaler (HPA)
    - HPA는 CPU 사용량 또는 다른 선택된 메트릭을 기반으로 파드의 인스턴스 수를 자동으로 스케일 아웃(증가)하거나 스케일 인(감소)함.
    - 예를 들어, 특정 파드가 CPU 사용량이 80%를 초과할 때 추가 파드를 생성하고, 사용량이 50% 미만일 때 파드 수를 줄일 수 있음.
    - HPA는 런타임에 리소스 사용률을 모니터링하고, 설정된 임계값에 따라 파드 수를 자동으로 조정함.
  - Cluster Autoscaler
    - 쿠버네티스의 클러스터 오토스케일러(Cluster Autoscaler)는 클러스터 내에서 노드(서버)의 수를 동적으로 조정하여 파드의 수요에 따라 클러스터의 리소스를 최적화하는 역할을 함. 여기에는 클러스터의 크기를 자동으로 확장하거나 축소하는 과정이 포함됨. 이러한 기능은 특히 클라우드 환경에서 유용하며, 사용량이 변동하는 애플리케이션에 이상적임.
    - 예를 들어, 모든 노드가 포화 상태이고 새로운 파드를 수용할 수 없는 경우, 클러스터 오토스케일러는 새로운 노드를 추가할 수 있음. 반대로 많은 노드가 사용되지 않고 리소스가 남아돌 때는 노드 수를 줄임.
- 예시: 온라인 쇼핑몰의 플래시 세일
  - 상황: 온라인 쇼핑몰에서 큰 할인 행사를 진행하고 있음. 이 행사는 일반적인 날보다 많은 트래픽을 유발하며, 행사 시작 직전과 진행 중에 트래픽이 급격히 증가함.
  - 문제: 이러한 급격한 트래픽 증가는 기존에 구성된 서버 노드들로는 충분히 처리할 수 없음. 새로운 사용자 요청을 수용하기 위해 추가 리소스가 필요함.
  - 클러스터 오토스케일러의 역할
    1. 트래픽 감지: 클러스터 오토스케일러는 쿠버네티스 클러스터의 리소스 사용률을 지속적으로 모니터링함. 파드가 필요로 하는 리소스와 현재 클러스터의 리소스 용량을 비교함.
    2. 노드 추가: 행사 시작 직전에 트래픽이 증가하면, 클러스터 오토스케일러는 자동으로 더 많은 노드를 클라우드 인프라에서 프로비저닝함. 이로써 새로운 사용자 요청을 수용할 수 있는 충분한 컴퓨팅 리소스를 확보할 수 있음.
    3. 부하 분산: 새롭게 추가된 노드는 기존 노드와 함께 트래픽을 분산 처리함. 이는 시스템의 전반적인 부하를 줄이고 사용자 요청에 대한 응답 시간을 최적화함.
    4. 노드 제거: 행사가 끝나고 트래픽이 정상으로 돌아오면, 클러스터 오토스케일러는 불필요해진 추가 노드를 자동으로 제거함. 이는 비용 절감과 리소스 효율성 증대에 기여함.
  - 이러한 오토스케일링 기능은 쿠버네티스가 다양한 워크로드와 변동성이 큰 트래픽 조건에서도 애플리케이션을 안정적으로 운영할 수 있도록 지원함. 또한, 리소스 사용을 최적화하고 운영 비용을 관리하는 데 큰 이점을 제공함.
Automated rollouts and rollbacks : workload resource deployment
- 쿠버네티스의 Automated rollouts와 rollbacks 기능은 애플리케이션의 배포 과정을 자동화하여, 새로운 버전의 애플리케이션을 안전하게 배포하고 필요한 경우 이전 버전으로 롤백할 수 있게 하는 기능임. 이러한 기능은 배포의 안정성을 향상시키고, 운영 팀의 수작업 부담을 줄여줌.
- Automated Rollouts (자동 배포)
  - 쿠버네티스에서 애플리케이션 또는 서비스의 새로운 버전을 배포할 때, 롤아웃은 새로운 버전을 점진적으로 적용하는 과정임. 이 과정에서 쿠버네티스는 새로운 파드를 순차적으로 생성하고, 문제가 없는 것을 확인하면서 점진적으로 트래픽을 새 버전으로 이동시킴.
  - 롤아웃 도중에 파드의 상태를 지속적으로 모니터링하여, 예상치 못한 문제나 에러 발생 시 롤아웃을 자동으로 일시 중지함. 이를 통해 잠재적인 장애가 전체 시스템에 영향을 미치기 전에 조치를 취할 수 있음.
- Automated Rollbacks (자동 롤백)
  - 롤백은 새로운 버전의 배포가 실패하거나 문제를 일으킬 경우, 자동으로 이전 버전으로 돌아가는 과정임. 롤백은 배포된 리소스의 이전 구성 상태로 되돌리는 것을 의미함.
  - 롤백을 통해 새로운 버전에서 발견된 문제로 인한 서비스 중단이나 장애를 최소화할 수 있음. 쿠버네티스는 배포 이력을 추적하고, 각 배포 버전의 상태를 관리함으로써 언제든지 안전하게 이전 상태로 되돌릴 수 있도록 지원함.
- 이 기능들은 특히 지속적인 통합 및 배포(CI/CD) 파이프라인의 일부로서 매우 유용함. 개발자들은 새로운 코드 변경사항을 자주 그리고 안전하게 배포할 수 있으며, 만약 문제가 발생하면 신속하게 이전 상태로 복구할 수 있음. 이를 통해 더 빠르고 자주 애플리케이션을 업데이트하면서도 사용자에게 지속적으로 안정적인 서비스를 제공할 수 있음.

CI/CD 를 사용하는 클라우드 서비스

AWS (Amazon Web Services)

AWS CodePipeline: 소스 코드에서 배포까지 전체 프로세스를 자동화하고 관리하고 있음
AWS CodeBuild: 소스 코드를 컴파일하고, 테스트를 실행하며, 소프트웨어 패키지를 생성하는 빌드 서비스
AWS CodeDeploy: 자동화된 소프트웨어를 AWS 인스턴스에 배포

Microsoft Azure

Azure Pipelines: 지속적 통합과 배포를 지원하고 있으며, GitHub 및 다른 버전 관리 시스템과 통합되고 있음
Azure DevOps Services: 개발 팀이 코드를 공유하고, 작업을 추적하며, 소프트웨어를 배포하기 위한 종합적인 서비스를 제공하고 있음

Google Cloud Platform (GCP)

Google Cloud Build: 코드를 컴파일하고, 테스트를 실행하며, 컨테이너를 빌드하기 위한 서비스임
Cloud Deployment Manager: 자동화된 배포와 리소스 관리를 제공하고 있음

GitLab

GitLab CI/CD: GitLab은 자체적으로 강력한 CI/CD 도구를 제공하고 있으며, 코드 저장소에서 바로 파이프라인을 구성하고 실행할 수 있음.

Docker 를 사용하는 클라우드 서비스

Amazon Web Services (AWS)
- Amazon Elastic Container Service (ECS): AWS에서 도커 컨테이너를 쉽게 실행, 중지 및 관리할 수 있게 해주는 컨테이너 관리 서비스임
- AWS Fargate: 서버를 관리할 필요 없이 컨테이너를 직접 실행할 수 있는 서버리스 컴퓨트 엔진임
- Amazon Elastic Kubernetes Service (EKS): 쿠버네티스 기반의 관리 서비스로, 도커 컨테이너를 쿠버네티스 클러스터에서 쉽게 실행할 수 있음
Microsoft Azure
- Azure Container Instances (ACI): 서버를 관리할 필요 없이 도커 컨테이너를 Azure에서 빠르게 시작하고 실행할 수 있음
- Azure Kubernetes Service (AKS): 쿠버네티스 기반의 관리 서비스로, 도커 컨테이너를 확장성 있게 관리할 수 있음
Google Cloud Platform (GCP)
- Google Kubernetes Engine (GKE): 도커 컨테이너를 쿠버네티스 클러스터에서 관리하고 확장하는 데 사용되는 서비스임
- Google Cloud Run: 도커 컨테이너를 서버리스 환경에서 실행할 수 있으며, 사용한 만큼만 비용을 지불하게 됨

실습 - github action 사용해서 ecr 에 업로드하기

참고. 만약 Repository fork 뜨면 github repo screte 못 불러오는 문제가 발생할 수 있습니다.

https://github.com/siyoungoh/nodejs-ecr
순서
- 1. AWS - ECR 리포지토리 만들기
- 1. AWS - github action 을 통해 접근할 수 있는 접근 권한 IAM 설정하기
- 1. github secrets 에 AWS 설정값 등록하기
1. AWS - ECR 리포지토리 만들기
1. AWS - github action 을 통해 접근할 수 있는 접근 권한 IAM 설정하기
1. User 생성 후, Accss key, screte 만들기
  - csv 로 저장한 후에 나중에 불러와서 github secrets 에 등록할 예정.

User 권한에 ECR 관련 권한 추가하기

  
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload",
                "ecr:PutImage"
            ],
            "Resource": "*"
        }
    ]
}

1. github secrets 에 AWS 설정값 등록하기
1. main 브랜치에 commit (github action 의 trigger)하면서 ECR에 제대로 배포되는지 확인하기

주요 배포 전략

로컬 환경 배포 VS 프로덕션 환경 배포

로컬 환경에서의 배포와 프로덕션 환경에서의 배포는 여러 중요한 차이점이 있음. 각 환경의 목적과 요구 사항에 따라 배포 방식, 설정, 관리 접근법이 달라짐.

목적과 사용 범위
- 로컬 환경 배포: 주로 개발자가 개인적으로 사용하는 환경으로, 개발 중인 애플리케이션의 코드 변경을 테스트하고 디버깅하는 데 사용됨. 이 환경은 실험적이고 빠른 변경이 가능하며, 실시간 사용자 트래픽이나 외부에서의 접근은 없음.
- 프로덕션 환경 배포: 실제 사용자가 사용하는 환경으로, 안정성, 보안, 성능이 매우 중요함. 이 환경은 고가용성과 높은 성능을 유지하기 위해 세심하게 관리되고, 변경 사항은 철저히 테스트 후에 적용됨.
설정과 구성
- 로컬 환경: 일반적으로 개발 편의성을 위해 간소화된 설정을 사용함. 예를 들어, 보안 설정이나 데이터베이스 연결이 실제 운영 환경보다 덜 복잡할 수 있음.
- 프로덕션 환경: 보안, 데이터 무결성, 백업 등을 포함한 모든 운영 관련 최적화가 필수적임. 또한, 트래픽 부하를 관리하기 위해 로드 밸런서, 클러스터링, 캐싱 전략 등이 구현됨.
테스트와 검증
- 로컬 환경: 개발자는 주로 기능적인 검증이나 단위 테스트를 수행함. 종종 통합 테스트도 로컬에서 수행되지만, 모든 종류의 테스트를 포괄하기에는 한계가 있음.
- 프로덕션 환경: 배포 전에 여러 단계의 테스팅 환경(개발, 테스트, 스테이징)을 거침. 이 과정에서 성능 테스트, 보안 테스트, 부하 테스트 등이 포함되어, 프로덕션에 배포되기 전에 애플리케이션이 모든 기준을 충족하는지 확실하게 검증됨.
배포 자동화와 롤백
- 로컬 환경: 배포는 대부분 수동으로 진행될 수 있으며, 간단한 스크립트를 사용할 수도 있음.
- 프로덕션 환경: 배포 프로세스는 자동화되어 있으며, 종종 지속적 통합/지속적 배포(CI/CD) 파이프라인을 통해 관리됨. 자동 롤백, 블루/그린 배포, 카나리 배포 등의 전략을 사용하여 신중하게 변경을 적용함.
모니터링과 로깅
- 로컬 환경: 기본적인 로깅 도구를 사용하거나 때로는 디버깅 출력만으로도 충분할 수 있음.
- 프로덕션 환경: 고급 모니터링 및 로깅 시스템을 구축하여 실시간으로 시스템 성능을 모니터링하고, 장애를 신속하게 탐지하며 대응할 수 있음.

이러한 차이점을 고려하여, 로컬과 프로덕션 환경에서의 배포 전략을 적절히 계획하고 실행하는 것이 중요함. 이는 애플리케이션의 개발 단계에서부터 실제 사용자에게 서비스를 제공하는 단계까지 효율적이고 안정적으로 이행될 수 있게 해줌.

배포 전략

배포 전략은 소프트웨어 업데이트를 사용자에게 제공하는 방법을 정의함. 각 전략은 특정 목표와 환경에 적합하며, 신뢰성 있는 배포와 빠른 롤백, 사용자 중단 최소화를 위해 사용됨.

1. 롤링 배포 (Rolling Deployment)

정의: 기존 인스턴스를 점진적으로 새 버전으로 업데이트하며, 언제든 일부는 옛 버전을 유지하게 됨.
장점: 단순하고 리소스를 추가할 필요가 없으며, 실시간으로 롤백이 가능함.
예시: AWS Elastic Beanstalk은 롤링 배포를 지원하여, 애플리케이션의 새 버전을 점진적으로 배포하면서 트래픽을 조정할 수 있음.

2. 블루/그린 배포 (Blue/Green Deployment)

정의: 블루(현재 버전)와 그린(새 버전) 두 개의 완전히 독립적인 환경을 준비하고, 트래픽을 새 버전으로 일시에 전환함.
k8s 에서 적용 : old 버전(blue)과 새 버전(green)이 정확히 같은 인스턴스 양으로 릴리즈된 다음에 정상 동작되는지 확인하고 로드밸런서 수준에서 green 으로 트래픽을 스위칭함.
- - 이미지 출처 : https://github.com/ContainerSolutions/k8s-deployment-strategies/tree/master/blue-green
장점: 즉각적인 롤백이 가능하며, 새 버전의 안정성을 확보한 후 트래픽을 전환할 수 있음.
예시: 사용자가 주로 사용하는 금융 서비스 애플리케이션에서, 블루/그린 배포를 사용하여 시스템 다운타임 없이 버전 업그레이드를 진행할 수 있음.

3. 카나리 배포 (Canary Deployment)

정의: 새 버전을 소수의 사용자에게 먼저 제공하고, 문제가 없을 경우 점차적으로 확대하여 전체 사용자에게 배포함.
일부 사용자에게 릴리즈된 다음 전체 rollout 진행. 새 릴리즈 안정성이 의문, 테스트가 부족할 때 사용.
- - 이미지 출처 : https://github.com/ContainerSolutions/k8s-deployment-strategies/tree/master/canary
장점: 리스크를 최소화하면서 새 버전의 성능을 실제 사용 환경에서 테스트할 수 있음.
예시: 대형 소셜 미디어 플랫폼에서 새로운 기능을 도입할 때, 소수의 사용자 그룹에게 먼저 적용하여 반응과 성능을 평가한 후 점진적으로 확대함.

4. A/B 테스팅

정의: 두 가지 이상의 버전을 동시에 배포하고, 각 버전의 성능을 비교 분석함.
통계 활용한 비즈니스 전략이지만, 카나리아 배포에 기능 추가해 구현할 수 있어서 소개함. 새로운 버전이 특정 조건에서 일부 사용자에게만 배포됨.
-
-
장점: 사용자의 반응과 선호도를 기반으로 가장 효과적인 버전을 선택할 수 있음.
예시: 온라인 리테일 업체가 두 가지 다른 홈페이지 디자인을 테스트하여, 구매 전환율이 더 높은 디자인을 최종적으로 선택함.