35. 도커와 마이크로서비스

모놀리식 아키텍처

이해

전통적인 아키텍처로, 기존에 사용하던 서비스 방법이다.

서비스가 하나의 애플리케이션으로 돌아가는 구조로, 기존의 개발 방식을 사용해 개발하여 간단히 배포가 가능하다.

하나의 서비스 또는 애플리케이션이 하나의 거대한 아키텍처로 이해되며, 다양한 기능을 동작하는 서비스를 서버에서 실행하여 서비스한다.

 

단점

서비스와 애플리케이션이 모두 묶여있으므로, 서비스를 스케일링하려면 이 아키텍처를 전부 복사해야한다.

즉, 기존의 애플리케이션을 그대로 복제하여 로드밸런싱을 해야한다는 것.

이 방식은 불필요한 서비스까지 모두 복제된다는 단점이 존재한다.

 

두 번째 단점은 종속관계의 라이브러리끼리 충돌하는 문제가 있다.

각각의 라이브러리는 서로 다른 기능을 제공하며, 특정 버전을 요구하는 경우가 있다.

만약 생각없이 업데이트를 진행하다 특정 라이브러리가 문제가 생길 가능성 또한 있다.

즉, 라이브러리를 매 업데이트마다 관리하기 매우 어렵다.

 

마지막으로, 조금만 수정해도 전체 빌드 및 배포가 필요하다는 문제가 있다.

모놀로틱 아키텍처는 소스코드 전체가 하나로 동작하기 때문에, 작은 수정만 존재해도 전체를 빌드하여 다시 배포해야 한다.

프로그램의 크기가 어느정도 커지면 한 번 컴파일에 30분~수 시간을 소모하게 된다.

만약 하루에 버그가 연달아 여러개가 발생하면, 이는 심각한 시간적 손실을 발생하게 된다.

---

마이크로서비스 아키텍처

이해

모놀리틱 아키텍처의 대안으로, 반대되는 개념의 아키텍처다.

서비스를 통합하여 관리하는 것과 반대로, 애플리케이션의 각각의 기능을 분리하여 개발 및 관리한다.

 

장점

모놀로틱 아키텍처의 단점을 해결하였다고 생각하면 된다.

개발자가 특정 비즈니스 로직에 대해서만 집중하여 개발 가능하여 서비스 단위로 빠른 개발이 가능하다.

또, 개별 서비스 단위로 개발, 패키징, 빌드, 테스트, 배포로 각 서비스마다 유연한 스케줄을 짜는것이 가능해 배포가 용이하다.

서비스 단위로 스케일링이 가능하여 불필요한 서비스는 줄이고 더 많은 자원이 필요한 서비스는 확장가능해, 서비스 단위 고효율 저비용 Scale-Out 구조를 가질 수 있다.

 

다만, 서비스가 분산되어 있는 분산 시스템 환경에서 Transaction 보장, 테스트, 배포, 관리를 하기란 상당히 어려움이 있다. 때문에 이를 자동을 해결하는 서비스를 주로 사용하는 편이다.

---

컨테이너

이해

컨테이너는 가상머신을 사용하여 각 마이크로 서비스를 격리(isolate)하는 기술이다.

컨테이너의 큰 특징은, 가상 환경을 제공할 때 하드웨어를 전부 구현하지 않는 특징이 있다. 때문에 아주 빠른 실행이 가능하다.

프로세스의 문제가 발생할 경우 컨테이너 전체를 조정해야 하기 때문에, 컨테이너에 하나의 프로세스를 실행하도록 하는 것이 권장된다. 마치 브라우저를 생각하면 된다.

 

성능

실제로 VM과 도커 컨테이너를 실행하면, 사용하는 자원량에 유의미한 차이가 존재한다.

 

관리

그렇다면 이 컨테이너는 어떻게 격리하고 관리할까?

기본적으로 컨테이너는 리눅스 커널 위에서 돌아간다. 리눅스 커널은 각 프로세스마다 리눅스 네임을 제공하는데, 이를 바탕으로 별도의 공간을 리눅스 네임으로 관리한다.

이 공간 안에서, 각 프로세스가 파일 시스템 마운트, 네트워크, 유저(uid), 호스트 네임(uts) 등에 대해 시스템에 독립적인 뷰를 제공한다.

 

또, 리눅스 컨트롤 그룹을 통해 프로세스로 소비할 수 있는 리소스 양(CPU, 메모리, I/O, 네트워크 대역대, device 노드 등)을 제한할 수 있다.

---

도커

이해

컨테이너 기술을 지원하는 다양한 프로젝트 중에 하나로, 컨테이너 기술을 알려준 일등공신이다. 사실상 컨테이너 기술의 표준이라고 보고 있다.

2014년 기준으로 가장 인기있는 클라우드 오픈 소스로, 다양한 운영체제에서 사용이 가능하고, 의존성 및 파일 시스템까지 모조리 패키징해 빌드, 배포, 실행을 단순화한다는 특징이 있다.

리눅스의 네임 스페이스와 cgroups와 같은 커널 기능을 사용하여 가상화하였다.

 

---

실습

도커를 설치하기 전, 패키지 업데이트를 진행한다.

 

이제, 명령어를 이용하여 도커를 설치한다. docker.io 패키지 먼저 설치한다.

설치가 완료되면, 아래와 같이 사용할 수 있는 명령어가 나온다.

 

도커로 인해 네트워크 설정이 변경된 것도 확인 가능하다.

 

해당 명령어로, nginx 이미지를 볼 수 있다. 이를 통해 현재 이미지 목록, 공식 인증 및 자동화 여부를 파악할 수 있다.

 

도커 이미지를 관리할 레포지토리를 편하게 저장하기 위해, 도커 허브를 설정한다. 회원가입 및 로그인을 하자.

 

도커 허브는 다양한 이미지 파일을 제공한다. 위에서 찾아본 nginx 이미지부터 정말 다양한 이미지를 제공한다. 이를 이용해 nginx 이미지를 최신 버전으로 업데이트 한다.

 

그 다음으로 busybox 패키지를 설치한다.

 

도커에서 웹 서버를 열려면, 외부 포트와 내부 포트를 연결해야한다.

이유는 단순하다. 내부에서만 웹 서버를 사용할 것이면 이 과정은 필요없으나, 외부에서 내부로 접근할 때 도커 웹 서버로 들어갈 수 있는 진입구를 내어줘야 하기 때문이다. 이를 외부 IP의 특정 포트로 물려놓는 것이다.

기본적으로 도커는 레지스트리에서 이미지를 PULL한 후, 컨테이너에 CREATE를 하고, 메모리에 START하는 과정이 필요하다.

그러나 이 모든 과정을 한번에 하는 명령어가 있는데, 이것이 RUN 명령어다.

이 명령어를 이용하여 기본적인 nginx 웹 서버를 하나 열 것이다.

 

외부, 및 내부에서 접근하는 것이 가능한 것을 확인할 수 있다.

내부

외부

 

도커의 장점은 프로세스 복제 및 생성이 매우 간편하다는 것이었다. 간단한 명령어 한 줄로 서비스 하나를 더 생성할 수 있는 것이다. 해당 과정은 8002번 포트로 서비스를 하나 더 생성한 것을 확인할 수 있다.

 

각 웹 컨테이너의 로그 파일을 확인할 것이다. 해당 명령어를 사용하여 로그 파일 경로를 확인한다.

 

이 후, root로 콘솔을 열어 해당 위치로 이동한다.

 

cat명령어로 해당 로그 파일을 열면, 도커 로그와 웹 로그가 서로 섞여있는 것을 확인할 수 있다. 즉, 외부 프로그램 등이 로그 연동을 하고 싶다면 이 파일에서 로그를 확인하면 되는 것이다.

 

사실 로그를 확인하는 명령어가 따로 있다. 이걸로도 확인할 수 있다.

 

---

도커 자체의 이벤트를 감시하는 명령어 또한 존재한다.

위 명령어를 입력하고 컨테이너를 이것저것 건드려보자.

 

컨테이너를 지우고 새로 만들었더니, 이벤트에 여러가지 내용이 적히는 것을 확인할 수 있다.

 

현재 모든 컨테이너를 전부 삭제해본다. 삭제는 반드시 중지 후 삭제가 진행되어야함을 명심하자.

 

컨테이너를 전부 지운 이유는 nginx 이미지를 삭제하기 위함이다. nginx 이미지가 이미 컨테이너에서 사용중이므로, 컨테이너를 없애 이미지를 없애는 실습을 할 것이다.

컨테이너가 없으니 이제 이미지를 지울 수 있다.

---

예전에 설치했던 bwapp을 다시 설치해보자. search 명령어로 bwapp을 찾고 설치할 것이다.

 

bWAPP이 잘 설치된 것을 볼 수 있다.

다만 이건 몇몇 기능이 제한된 상태로 설치된 것인데, 예를 들어 파일 업로드 같은 중요한 기능이 빠졌다.

때문에 이 기능을 살려야하는데, 이는 bWAPP을 관리하는 리눅스에서 설정하여야한다.

즉, 도커 컨테이너 내부로 들어가야한다는 것이다.

 

컨테이너 내부로 잘 들어간 모습을 확인할 수 있다.

 

이미지 파일에 대해서 모든 권한을 부여한다.

이렇게하면 파일 업로드가 정상적으로 작동하는 것을 확인할 수 있다.

---

도커 허브에 로그인을 해준다.

 

그 후, nginx 1.18버전을 이용하여 웹 서버를 하나 열어준다.

 

간단한 html 문서를 만들어본다.

 

이 문서를 웹 경로에 저장할 것이다. 해당 명령어를 입력하고 웹으로 접속하면 내용이 있는 것을 확인할 수 있다.

 

배포할 이미지나 파일이 있다면 이런식으로 배포를 하면 된다.

이제 도커 허브에 이 내용을 전부 commit 해보자.

 

그 후, 이미지 목록을 확인하면 이미지가 하나 생성된 것을 확인할 수 있다.

이 이미지는 그냥 현재 상태를 이미지로 만든 것이다.

 

이제 업로드용 이미지를 하나 만들어보자.

이렇게 진행하면 이미지가 하나 더 생긴것을 확인할 수 있다.

 

이제 만든 이미지를 push 하면 업로드가 된다!

 

이미지를 지울때도 마찬가지로, 버전 정보까지 전부 작성해야 지워진다.

 

이미지를 다운로드 받을때도 버전 정보까지 전부 작성해야 실행된다.

 

---

볼륨 생성 및 SQL 연결 실습을 해보자.

 

볼륨의 마운트 포인트까지 잘 잡힌 것을 확인할 수 있다.

 

이후 run 명령어로 mysql을 설치할 것이다.

그냥 설치만 하면 되는 것이 아니라, 초기 설정이 조금 필요하다.

-e 옵션으로 이를 표현하며, 이 과정에선 루트 비밀번호는 admin, 초기 데이터베이스는 test의 이름으로 생성하겠다는 옵션을 주었다.

 

리눅스 컨테이너 내부로 진입 후, 어드민 계정으로 전환한다.

 

DB를 확인하면, test이름의 DB가 있는게 보인다.

 

이 볼륨은 컨테이너가 삭제되어도 사라지지 않는 것을 확인할 수 있다.

 

컨테이너 삭제 후 볼륨이 살아있는 것을 확인하면, 새로 생성할 DB에 이 볼륨을 연결해준다.

---

컨테이너 네트워크 통로 구성을 해 줄 것이다.

따로 서브넷 설정은 하지 않고 그냥 순차적인 생성만 할 것이다.

 

이후, 네트워크 구성을 보면, 172.18번대가 부여된 것을 볼 수 있다.

 

그 후, nginx를 생성한 네트워크 구성에 연결한다.

 

생성된 nginx가 172.18 대역의 서브넷으로 잘 생성된 모습을 볼 수 있다.

 

이 네트워크 생성은 다양한 옵션을 설정할 수 있는데, 이 옵션에는 서브넷 설정, IP 범위, 게이트 웨이를 설정할 수 있다.

 

설정한 서브넷 대역으로 잘 생성된 것을 확인할 수 있다.

---

컨테이너 웹 서버와 파일을 동기화 해보자. 즉, 로컬 파일과 마운트 시킬것이다.

먼저 현재 있는 모든 컨테이너를 삭제할 것이다.

 

그리고 prune 명령어를 이용하여 남아있는 모든 관련 설정 파일, 이미지 및 네트워크 설정까지 삭제한다.

 

마운트는 아래와 같이 :를 중심으로 각자 동기화 할 주소를 적는다.

적는 순간 컨테이너에도, 로컬 환경에서도 해당 주소가 생성되며, 동기화는 실시간으로 진행된다.

 

당연하게도, 현재 아무런 index 페이지가 없기 때문에, 접속하면 html이 없다고 나온다.

 

그렇기 때문에, 마운트된 파일 경로에 새 html 문서를 연결하면 페이지가 나오게 된다.

---