해당 게시글은 국민대학교 이경용 교수님의
수업 내용을 바탕으로 작성하였습니다.
Monolithic Application vs Microservice Application
Monolithic Application
- 하나의 서버에 다른 목적을 가지는 여러 프로세스가 동작함.
- Scale-up이 적당한 경우가 많음
- Scale-out이 불가능한 경우가 많음
Microservice Application
- 독립적으로 배포 가능해야 하며, static한 외부 API 제공
- 배포 가능한 컴포넌트로 분리 후 배포
- 여러 컴포넌트 간 통신 프로토콜 정의 필요
장점
- 고가용성 시스템 구성
- 확장이 필요한 서비스만 확장 가능
- 필요에 따라 특정 서비스만 여러 서버에 복제하여 안정성을 높일 수 있음.
- 여러 서비스간 소프트웨어 종속 문제 해결 가능
- 다수 소프트웨어가 외부 라이브러리 사용 시 라이브러리 버전관리가 매우 어려울 수 있음
- 이를 해결 가능
시스템 가상화 기술 (Virtual Machine)
- Hypervisor (가상 머신 모니터)를 통한 여러 OS간 독립적 환경 제공
- Hypervisor가 HW에서 자원을 떼와서 각 VM에 할당하는 구조!
- 각 VM은 독립적인 별도의 커널, 시스템 프로세스 등을 관리함
- Hypervisor를 실행할 때 추가 오버헤드가 발생함.
- 별도의 커널을 갖기에, 서로 다른 OS를 동시 동작 가능
- Hypervisor을 통한 자원 공유로 인해 VM간 간섭은 덜함
- 오버헤드가 커서 Monolithic에 적합
Container
호스트 운영체제에서 동작하며 커널 및 많은 시스템 자원을 호스트 기기와 공유
각 컨테이너들은 별도의 file system을 가짐
호스트 운영체제에서 동작하는 하나의 프로세스로 간주할 수 있음.
- chroot : 파일 경로에 대한 접근 제한 (독립된 파일 서비스 제공)
- cgroup : Container 간 자원 격리
- namespace : 각기 다른 컨테이너 간 프로세스를 참조할 수 없게 격리하는 기능 (독립된 프로세스 공간 제공)
Hypervisor 없이 호스트의 커널을 공유하기에 컨테이너간 간섭이 클 수 있으나, 시스템 오버헤드가 작기에 MSA에 적합함.
(보안 상 취약한 부분임!)
컨테이너 기술의 대중화 - Docker
1. 컨테이너 기술
- 일반 사용자가 손쉽게 사용하기에는 어려움이 있었음 (LXC)
2. Docker
리눅스 컨테이너 기술을 일반 사용자가 쓰기 쉽도록 이미지 생성, 배포, 응용 실행을 가능한 서비스 개발.
DockerFile을 통해 Image를 생성
해당 이미지를 실행하기 위한 컨테이너를 생성 -> 컨테이너 안에서 Image 실행.
3. Docker 구조
- Image : 실행에 필요한 파일 시스템, 데이터, 프로그램 등을 포함
- Registry : 여러 컨테이너 이미지를 공유하는 공간 (Docker Hub)
- Container : 이미지로부터 생성된 별도의 실행 공간
도커 세부 동작 내용
- 사용자는 특정 image를 활용하여 명령어를 실행.
- Docker는 현재 구동중인 호스트에 해당 image가 존재하는지 확인.
- 호스트에 해당 이미지가 없을 경우, 등록된 repository로부터 이미지를 가져옴.
- 받아온 이미지를 실행 후, 사용자가 정의한 echo 명령어를 실행
이미지를 활용한 Docker 실행
Docker 실행 시 Image 필요 -> 이미지 생성을 위해선 Dockerfile이 필요함.
- Docker Image 생성을 위해 필요한 파일 및 특성 정의
- Docker 엔진은 Dockerfile을 참조하여 이미지를 생성함.
명령어 구조
$ docker run <image> -> image를 통해 Docker Container 실행
$ docker build -t <image> . -> dockerfile을 통해 이미지 생성
이미지 태그
Docker image는 버전 별 관리를 지원함. -> 버전을 태그로 분리할 수 있음.
(default : latest)
$ docker run <image>:<tag>
Dockerfile 활용 명령어 예제
- RUN : 베이스 이미지에서 실행할 명령어들
- MAINTAINER : 파일 작성자 정보 등
- EXPOSE : 컨테이너 포트 번호를 호스트 기기의 포트 번호와 직접 매핑시킴
- ENV : 환경 변수 설정
- USER : 이미지 생성 명령어들을 실행할 계정 (RUN, ENTRYPOINT 명령어에 적용
- WORKDIR : 이미지 생성 시 실행될 경로 지정 (상대 경로 활용 시 편리)
- COPY : 호스트 기기에 있는 파일을 컨테이너 이미지로 복사하게 해줌
- ENTRYPOINT : docker run 또는 start 수행 시 실행할 명령어.
Docker Image 레이어에 대한 이해
Docker에서 생성하는 이미지는 하나의 큰 파일이 아님
이미지는 여러 개의 레이어로 구성되어있음 -> VM 이미지와의 차이
- 여러 다른 이미지들이 각각의 레이어를 공유할 수 있음
- Dockerfile 내부 RUN 명령어가 하나의 레이어를 생성함.
- 이미지가 필요한 경우, Docker 엔진은 레이어 별로 다운로드 여부를 결정함
- 필요한 레이어가 존재한다면 새롭게 다운로드할 필요가 없음.
컨테이너 이미지 실행.
생성한 이미지를 통해 컨테이너를 실행
docker run --rm -d --name <image명> -p 8081:8080 <image>
- --name : 접근이 용이하도록 쉬운 이름 지정 (지정하지 않으면, 임의의 문자열이 생성됨)
- -p : host의 8081 포트는 컨테이너의 8080 포트로 연결
- -d : 백그라운드 실행
- --rm : 컨테이너 종료 시 컨테이너를 삭제하는 명령어
컨테이너 세부 정보 확인
$ docker images -> 빌드된 이미지 확인 가능
$ docker ps (동작 중인 컨테이너의 이름 및 명령어 등 출력)
$ docker ps -a (종료된 컨테이너 포함)
$ docker inspect <image명> (컨테이너 세부 정보 출력)
컨테이너 내부 접근
$ docker exec -it <container명> sh // 컨테이너 서비스의 shell에 접속
- -i : 표준 입력 유지
- -t : shell 표시
그랬더니 위 결과처럼 Host 기기에서의 $ ps aux 와는 다른 결과를 보였음.
- 호스트 기기에서 동작하는 프로세스는 보이지 않음
- PID는 호스트 기기에서 생성된 내용과는 분리되어 있음
즉, 컨테이너 내부의 PID는 namespace 기능을 사용하여, 다른 컨테이너 또는 호스트 기기로 분리.
또한, PID 뿐만 아니라 컨테이너 별로 별도의 File System을 가짐.
컨테이너 조작 명령어
$ docker stop <image명> - 실행 중인 컨테이너 정지
$ docker start <image명> - 정지된 컨테이너 시작
$ docker restart <image명> - 컨테이너 리부팅
$ docker rm <image명> - 컨테이너 삭제
컨테이너가 정지된 상태는 실제로 컨테이너가 삭제된 상태가 아님! (start를 사용해 언제든 다시 시작 가능)
컨테이너 자원을 삭제하기 위해서는 rm 명령어 사용
Docker 컨테이너의 네트워크 셋업
- Bridge (default) : 호스트 기기 안에서 별도의 Private IP가 할당되며, 해당 IP로 서로 통신 가능
- Host : 컨테이너가 호스트의 네트워크를 직접 사용. Host 상 컨테이너는 같은 포트 사용 불가
- None : 네트워크 인터페이스 사용 x
- Overlay : 여러 대의 서버로 구성된 Docker Swarm에서 사용. (container Orchestration)
Docker의 기본 네트워크 셋업
- Host (eth0) : 외부와 연결할 때 사용하는 IP가 할당된 Host Network Interface
- Bridge (docker0) : Host Network와 컨테이너의 Network를 연결
'Infra & Cloud > Cloud Computing' 카테고리의 다른 글
[Cloud Computing] Cloud Deployment Automation (1) | 2024.12.06 |
---|---|
[Cloud Computing] Cloud High Availability (2) | 2024.12.06 |
[Cloud Computing] Serverless Computing (1) | 2024.12.06 |
[Cloud Computing] 2. 클라우드 Basic Service (1) | 2024.11.26 |
[Cloud Computing] 1. Distribute System (0) | 2024.11.25 |