Ch01. 새로운 인프라 환경이 온다.
마이크로서비스 아키텍처
마이크로서비스 아키텍처 (MSA: Microsdervices Architecture)는 시스템 전체가 하나의 목적을 지향하지만, 개별 기능을 하는 작은 서비스를 각각 개발해 연결합니다.
주문, 배달 등의 도메인 기능과 보안, 인증 등과 관련된 기능이 독립된 서비스를 구성하고, 각각의 서비스가 독립적으로 동작할 수 있는 완결된 구조입입니다.
이러한 구조의 장점은, 개발도니 서비스를 재사용 하기 쉽고, 향후 서비스 변경 및 유지보수 시에 달느 서비스에 영향을 미치지 않아 확장이 용이합니다. 따라서 사용자의요구 사항에 따라 가용성을 즉각적으로 확보해야 하는 IaaS 환경에 적합합니다.
하지만 모놀리식 아키텍처보다 복잡도가 높고, 각 서비스가 서로 유기적으로 통신하는 구조기에 네트워크 통신 호출 횟수가 증가하므로 성능에 영향을 미칠 수 있습니다.
MSA 아키텍처는 다음과 같은 구성을 가집니다.
각 도메인 서비스에 관련된 기능과 데이터베이스를 독립적으로 가지고 있는 구조를 볼 수 있습니다.
각 서비스는 API 게이트웨이와 REST API를 이용해 통신하여 사용자의 요청을 전달합니다.
디스커버리: 서비스의 개수는 고정이 아니기 때문에 어떤 서비스가 등록되어있는지 확인하기 위해 사용합니다.이벤트 버스: 수많은 서비스의 내부 통신을 이벤트로 일원화하고 이를 효과적으로 관리합니다.
이러한 구조를 통해 각 마이크로 서비스는 해당 서비스에 특화된 데이터베이스를 선택할 수 있습니다.
또한 고객의 요구사항 변동에 따라 서비스를 새로 추가하는 경우에도 기존의 이벤트 버스에 연결하여 유연하게 대응이 가능하며, 재사용성이 뛰어납니다.
컨테이너 인프라 환경에 적합한 아키텍쳐
어떤 아키텍쳐가 정답이라는 법은 없습니다.
각 주어진 환경에 따라 최적의 기술을 선택할 뿐입니다. 현재 많은 서비스에서 그러하듯이, 작은 서비스에서는 모놀리식 아키텍처로 시작해, 성장 이후에는 MSA로 전환할 수 있습니다.
작은 서비스에서 모놀리식 아키텍처를 선호하지만, 소규모더라도 MSA로 프로젝트를 구현할 경우 장점도 있습니다. 기능에 집중한 안정적인 서비스 구현이 가능하고, 재사용성이 뛰어나 각 서비스들을 구조화하기 때문에 장기적으로는 유지보수 측면에서 매우 유리합니다.
컨테이너 인프라 환경에서 제공하는 컨테이너는 MSA 서비스와 1:1 로 완벽 대응하며, 여러 유용한 두고드을 사용하면 비용을 낮추고 생산성을 향상시킬 수 있습니다.
컨테이너 인프라 환경을 지원하는 도구
컨테이너 인프라 환경은 크게 다음과 같이 구성됩니다.
- 컨테이너
- 컨테이너 관리
- 개발 환경 구성 및 배포 자동화
- 모니터링
가장 많이 사용하는 도구들은 다음과 같습니다.
도커 - Docker
도커는 컨테이너 환경에서 독립적으로 애플리케이션을 실행할 수 있도록 컨테이너를 만들과 관리하는 것을 도와주는 컨테이너 도구입니다.
도커로 애플리케이션을 실행하면, 운영체제 환경에 상관 없이 독립적인 환경에서 일관된 결과를 보장할 수있습니다.
기타 유사 도구 : 컨테이너디(Containerd), 크라이오(CRI-O), 파드맨(Podman) 등
쿠버네티스 - Kubernetes
쿠버네티스는 다수의 컨테이너(도커)를 관리하는데 사용합니다.
컨테이너의 자동 배포, 배포된 컨테이너에 대한 동작 보증, 부하에 따른 동적 확장 등의 기능을 제공합니다.
API 게이트웨이, 서비스 디스커버리, 이벤트 버스, 인증 및 결제 등의다양한 서비스를 효율적으로 관리할 수 있는 환경을 제공하고 이를 내외부와 유연하게 연결해줍니다.
유사 도구 : 도커 스웜(Docker Swarm), 메소스(Mesos), 노마드(Nomad)
쿠버네티스가 가장 유력하게 쓰이고 있습니다.
젠킨스 - Jenkins
젠킨스는 지속적 통합 (CI, Continuous Integration) 과 지속적 배포 (CD, Continuous Deployment)를 지원합니다.
CI/CD는 개발한 프로그램의 빌드, 테스트, 패키지화, 배포 단계를 모두 자동화해 개발 단계를 표준화합니다.
따라서 컨테이너 인프라 환경과 같이 단일 기능을 빠르게 개발햏 적용하는 애자일 환경에 매우 적합합니다.
유사 도구로는 뱀부(Bamboo), 깃허브 액션(Github Action), 팀시티(Teamcity) 등이 있지만 Jenkins와 Github Action이 가장 많이 쓰입니다.
프로케테우스, 그라파나
프로메테우스(Prometheus)와 그라파나(Grafana)는 모니터링을 위한 도구로,
프로메테우스는 데이터를 수집하고, 그라파나는 프로메테우스로 데이터를 관리자가 보기 좋게 시각화합니다.
프로메테우스와 그라파나는 컨테이너로 패키징돼 동작하며, 최소한의 자원으로 쿠버네티스 클러스터의 상태를 시각적으로 보여줍니다.
컨테이너 인프라 환경은 각 서비스에 소규모 기능이 나누어 개발되기 때문에 중앙 모니터링이 필요합니다.
이때 프로메테우스 + 그라파나의 조합이 프로메테우스가 오픈 소스이고, 서로 연동이 잘 지원되어 많이 사용합니다.
Ch02. 테스트 환경 구성
virtualBox, Vagrant 설치
virtualBox는 아래 Github 레포지토리에 있는 번들팩을 설치하였고, Vagrant는 다음 명령어를 통해 brew로 설치하였습니다.
https://github.com/sysnet4admin/_Book_k8sInfra
해당 명령어로는 vagrant 최신 버전이 설치되고, Github 레포지토리에 있는 virtualBox 버전과 호환이 되지 않을 수 있습니다.
해당 github에서 제공되는 vagrant 설치 파일은 손상되었는지 열리지 않으니, 아래 경로에서 2.2.9v 을 다운로드받아야 합니다.
https://releases.hashicorp.com/vagrant/2.2.9/
brew install vagrant vagrant-manager
Vagrant 구성하고 테스트하기
vagrant를 설치한 경로에서 터미널을 실행하여 vagrant init 명령어를 실행하여 프로비저닝에 필요한 기본 코드를 생성합니다.
(mac에서 기본 설치 경로는 /user 경로에서 숨김파일 보기 시에 다음과 같이 존재합니다.
vagrant init: 프로비저닝을 위한 기초 파일 생성vagrant up: Vagrantfile을 읽어 프로비저닝 진행vagrant halt: 베이그런트에서 다루는 가상 머신 종료vagrant destroy: 베이그런트에서 관리하는 가상 머신 삭제vagrant ssh: 베이그런트에서 관리하는 가상 머신에 ssh로 접속vagrant provision: 베이그런트에서 관리하는 가상 머신에 변경된 설정 적용
vagrant init 명령어를 실행하면, /user 기본 경로에 Vagrantfile이 생성된 것을 확인할 수 있습니다. 해당 파일을 에디터 프로그램으로 열고, config.vm.box = "base" 라는 내용이 있는지 확인합니다.
이후 터미널에서 vagrant up 으로 바로 실행해 보면, 아래와 같은 에러가 발생합니다. 설치하려는 이미지가 'base'로 명시되어 있지만 베이그런트가 해당 이미지를 찾지 못했기 때문입니다.
이제는 에러가 발생하지 않도록 운영체제 이미지를 선택하여 다운받습니다.
저자가 Vagrant Cloud에 올린 이미지인 sysnet4admin/CnetOs-k8s 로 아까 보았던 config.vm.box에 이미지 설정값을 변경합니다.
해당 이미지는 아래 링크에서 확인할 수 있습니다.
https://portal.cloud.hashicorp.com/vagrant/discover?query=sysnet4admin
변경사항을 저장하고, 다시 vagrant up 명령어로 실행하면 가상 머신 이미지를 다운로드합니다.
🚥 다음과 같은 오류가 나는 경우 VirtualBox의 확장팩을 설치하지 않아서 그렇습니다. 아래 링크에서 해당 버전의 확장팩을 다운로드합니다. 이후 VirtualBox에서 [설정] -> [확장] 탭에서 확장팩 다운로드를 확인합니다.
There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below. Command: ["startvm", "2112ee81-7ac6-4023-8897-bb6d427ce30a", "--type", "headless"] Stderr: VBoxManage: error: The virtual machine 'ogu_default_1724171839724_55889' has terminated unexpectedly during startup with exit code 1 (0x1) VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine
참고
