[AI 서비스 개발] 확장성을 고려한 K8S 기반 소프트웨어 아키텍처 설계

- 프론트엔드, 백엔드, 에이전트 개발자가 잘 소통하기 위해서는 데이터의 특성과 쿠버네티스의 특성을 잘 알아야 함

=> 데이터는 어떤 구조를 가져야 할까? 사용자 환경에서 어떤 데이터와 지표를 수집해야 할까?

- 쿠버네티스 옵저빌리티: https://youtu.be/AVn8F6ki68U?si=yFa1pbN1CfGcvM2w

- 컨테이너, 도커, 쿠버네티스 : https://youtu.be/eRfHp16qJq8?si=hmCxpdwRRVlCSw5l

- K8s 도입하면서 겪은 일들: https://youtu.be/JBGsqsoGxEo?si=YSPOR0J5GVxSgY2c

 

1. Contrainer : 서버의 한 종류

* 서버: 프로그램(소프트웨어)가 실행되는 하드웨어

- 컨테이너를 사용하면 한 대의 서버에서 여러 개의 소프트웨어를 안전하고 효율적으로 운영할 수 있다.

- 소프트웨어가 다운되면 서비스 장애로 이어짐 → 하나의 서버에서는 하나의 소프트웨어를 실행하는게 안전함

- 하나의 소프트웨어에서 여러개의 소프트웨어를 실행하고 싶다 -> 공간을 구분하고자 함 : 가상화기술

- 가상화 기술

1) VM 가상머신: 프로그램을 실행하고 업그레이드하는데 오래 걸림

- 예: 서버가 10개 있다면 3개는 A개발자, 3개는 B개발자, 4개는 C개발자가 만든 애플리케이션 설치

2) 컨테이너 : VM보다 가볍고 빠르다

- 예: 서버가 10개가 있다면 10개 모두 A,B,C가 만든 애플리케이션이 설치되서 관리 됨

 

2. Docker

- 컨테이너를 관리하기 위한 도구로 일종의 프로그램

- dockerfile: 이미지를 만들기 위한 레시피

- docker build : 이미지를 생성(컨테이너의 설계도)

- docker run : 이미지를 실행(컨테이너 생성)

 

3. Docker Compose

- 단일 서버에서 여러 컨테이너를 관리하고 싶을 때

 

4. KUBERNETES(K8s)

- 서버가 여러 대 있는 환경에서 각각의 서버의 도커에게 대신 지시해주는 컨테이너 오케스트레이션

 - K와 S 사이에 8개의 문자가 있어서 K8s라고도 함

- 변화가 빠름(버전 호환 문제, 하위 호환성 유지)

 

1) 리소스

- 쿠버네티스의 요소들

- pod: 내 애플리케이션 서비스가 올라가는 곳(인스턴스 하나)

- svc: pod 앞단에서 네트워크 말단이 되는 리소스

- node: 장비(vm)하나

- ing: 네트워크 외부 트래픽을 받아서 네트워크를 관장하는 리소스

- deployment: 배포와 관련된 리소스

 

2) 도입 배경

- 서브 서비스 운영 → 서버를 따로 할당 받기에는 비용의 문제 → 쿠버네티스 도입

- MSA 환경(여러개의 애플리케이션으로 구성됨) → 기존 서비스는 VM에 운영 유지, 새로운 서비스만 K8s로 운영, 추후 맞는거로 통합

 

3) 배포 구조

- 개발자가 소스코드 작성 > Repository > 이미지 build/Push > yaml파일 > 이미지 Pull/Run 배포

 

4) 핵심개념

- 컨테이너 관리

- 자동화된 배포 및 스케일링

- 로드 밸런싱 및 서비스 디스커버리

- 자동 복구

- 롤링 업데이트 및 롤백