Docker - 서버관리의 역사

개발자가 개발을 잘하는 것은 당연히 중요하다. 하지만 SW마에스트로에서 여러 멘토님들께 멘토링을 들으면서, 개발을 잘하는 것도 중요하지만, 자신이 개발하고자 하는 애플리케이션의 목적과 요구사항에 맞춰서 적합한 기술을 선택하는 것에 대한 중요성을 많이 느낄 수 있었다. 이는 애플리케이션의 성능, 안정성, 보안성 등 비기능적인 요소를 디벨롭할 수 있도록 도와준다.

소프트웨어 마에스트로에서 진행하는 프로젝트에서 기능 개발에만 몰두하지 않고, 개발하기 전에 여러 가지 많은 고민과 설계를 바탕으로 개발을 하여, 소프트웨어 품질을 높이기 위해 많은 도전을 할 예정이다.

 

서론이 길었지만, 최근 Docker 멘토링에서 서버관리의 역사에 대해서 배웠다. 기술의 역사를 공부하는 과정에서 해당 기술이 왜 등장했는지에 대해서 이해할 수 있었고, 이를 통해 기술을 선택하는 과정에서 해당 기술을 사용하는 이유와 기술의 장단점을 쉽고 효율적으로 공부할 수 있었다.

 

따라서 이번 포스팅은  Docker가 등장하기 전에는 서버 관리의 역사와 Docker가 등장한 이유에는 서버 관리를 어떻게 하고 있는지에 대해서 멘토링에서 배운 내용과 추가적으로 공부한 내용을 정리하려고 한다.

 

적합한 기술을 선택하기 위해서는 해당 기술이 왜 등장했는지에 대해서 이해하는 것 또한 중요하다. 이는 기술을 사용하는 이유와 해당 기술의 장단점에 대해서 효율적으로 이해할 수 있다.

 

먼저, 서버 관리는 서버의 상태를 쉽게 관리하기 위해 발전되어 왔다.

 

1) 자체 서버 운영

자체 서버를 운영하는 당시에는 서버를 설정하기 위해 많은 시간과 노력이 필요로 했다. 

서버 주문 > 서버 설치 > CPU, 메모리 조립 > 네트워크 연결 > OS 설치 > 계정 설정 > 방화벽 설정 > ..

 

애플리케이션 배포 과정은 다음과 같다.

Add user > System Env > Firewall > Network > Dependencies > Java > Git clone > Package > Configuration > Migration > Proxy > Run

 

또한 다음과 같은 단점이 있다.

- 서버의 상태를 명령어로 다루기 때문에, 특정 사람만 서버를 관리할 수 있다.

- 서버 상태 관리가 복잡하고 어렵다.

- 만약 배포 과정에서 Java 버전 업그레이드된다면, 이후에 설정한 것들의 변경사항이 매우 많다.

- 똑같은 서버를 하나 더 만드는 것이 매우 어렵다.

 

즉, 서버의 상태를 코드가 아닌 명령어로 다루다 보니 관리하기 복잡하고 특정 인물만 해당 서버를 관리할 수 있다. 또한 똑같은 서버를 하나 더 만드는 것 또한 복잡하다.

 

2) 설정 관리 도구 등장

따라서 명령어로 서버를 관리하는 것이 아닌, 코드로 서버 상태를 관리하는 기술이 등장하였다.

- ex) ANSIBLE, Puppet, CHEF

 

명령어를 통한 서버관리를 지양하고 상태를 코드로 관리함으로써, 서버 운영의 협업이 가능해진다.

몇몇 사람만 서버를 관리하는 것이 아닌, 협업을 통해 소스관리와 코드리뷰를 할 수 있는 장점이 있다.

 

3) 가상 머신 등장

가상 머신의 등장으로 하나의 서버에 여러 개의 가상 서버를 설치할 수 있게 되었다.

- 다양한 버전의 JAVA, 여러개의 데이터베이스를 쉽게 사용할 수 있다.

- 서버의 상태를 이미지로 저장할 수 있어, 동일한 서버 상태를 찍어 낼 수 있다.

Mutable vs Immutable Infrastructure   
- Mutable:  서버에 설치된 애플리케이션을 새로운 버전으로 업데이트
- Immutable:  새로운 버전이 설치된 서버의 상태를 이미지로 만들고 교체

https://www.bridge-global.com/blog/mutable-vs-immutable-infrastructure/

- 새로운 서버를 만들고 기존 서버의 내용을 복사할 수 있다.

- 가상 머신은 하드웨어를 격리시켜, 많은 애플리케이션이 동작할 수 있도록 한다.

 

4) 클라우드 등장

클라우드는 네트워크 전체에서 확장 가능한 리소스를 추상화, 풀링 및 공유하는 IT 환경이다.

- ex) AWS, Google Cloud, Azure

 

이는 다음과 같은 장점이 존재한다.

- 하드웨어 파편화 문제 해결한다.

- 가상화된 환경만으로 아키텍처 구성이 가능해진다.

- 이미지를 기반으로 한 다수의 서버 상태 관리가 가능하다.

 

하지만 단점도 존재하다.

- 다수의 서버 상태를 관리하기 어렵다.

- 누군가는 서버 운영을 담당해야 한다.

 

5) PaaS 등장

PasS는 하드웨어 및 소프트웨어 플랫폼을 제공하는 클라우드 컴퓨팅을 의미한다.

- 인프라, 운영 체제, 네트워크 관리 등 복잡한 작업을 대신 수행해 주어 개발자들이 애플리케이션 개발에만 집중할 수 있도록 도와준다.

- ex) Heroku, Netlify, AWS Elastic Beanstalk

 

이는 다음과 같은 장점이 존재한다.

- 소스 코드만으로 배포가 가능하다.

- 일반화된 프로비저닝 방법을 제공한다.

- 빠르게 시장에 투입하는 것이 중요한 스타트업에게는 필수적일 수 있다.

 

하지만 단점도 존재하다.

- 사용자가 서버의 상태를 변경하면 문제가 발생한다.

- 애플리케이션을 PaaS 방식에 맞게 작성해야 한다.

- 서버에 대한 원격 접속 시스템을 제공하지 않는다.

- 서버에 파일 시스템을 사용할 수 없다.

- Site 패키지를 설치할 수 없다.

- 로그 수집을 제한적인 방식으로 허용한다.

- 애플리케이션 배포에 대한 새로운 패러다임이 존재한다.

- PaaS에서만 제공하는 기능만 사용할 수 있다.

 

즉, PaaS에 따라 제한이 너무나도 많다..

 

6) 도커 등장

Docker는 2013년 DotCloud에서 첫 공개하였으며, 모든 영역에 있는 개발자, 인프라 모두에게 영향을 준 컨테이너 기술이다.

- 컨테이너 : 격리된 환경에서 작동하는 프로세스 (프로세스를 격리시켜 주는 기술)

- 리눅스 커널의 여러 기술을 활용한다. (성능이 뛰어나다.)

- 하드웨어 가상화 기술보다 가볍다.

- 이미지 단위로 프로세스 실행 환경을 구성한다.

 

VM vs Docker
VM(가상머신)과 Docker는 둘 다 격리된 환경에서 애플리케이션을 실행할 수 있는 가상화 기술이다. 하지만 둘은 격리하는 대상이 다르다.

VM은 Host OS 위에 Hypervisor를 설치하여 여러 개의 가상머신을 생성하고, 각각의 가상머신 안에 Guest OS를 설치합니다. 이렇게 생성된 각각의 가상머신은 독립적인 운영체제와 가상 하드웨어를 가지고 있으므로, 애플리케이션을 실행하는 데 있어서 완전한 격리성을 제공합니다.

반면에 Docker는 호스트 운영체제 위에 Container Engine을 설치하고, 각각의 컨테이너에 애플리케이션과 라이브러리 등 필요한 소프트웨어 패키지를 설치합니다. 컨테이너는 호스트 운영체제와 커널을 공유하기 때문에, 가상머신에 비해 더 가볍고 빠른 속도로 애플리케이션을 실행할 수 있습니다. 또한 컨테이너는 격리된 파일 시스템과 네트워크를 가지므로, 애플리케이션을 실행하는 데 필요한 환경을 완전하게 격리시킬 수 있습니다.

 

도커의 특징

1. 확장성

• 도커가 설치되어 있다면 어디서든 컨테이너를 실행할 수 있다.
• 특정 회사나 서비스에 종속적이지 않다.
• 쉽게 개발 서버를 만들 수 있고 테스트서버 생성도 간편하다.

 

2. 표준성

• 도커를 사용하지 않는 경우 ruby, nodejs, go, php로 만든 서비스들의 배포 방식은 제각각 다르다.
• 컨테이너라는 표준으로 서버를 배포하므로 모든 서비스들의 배포과정이 동일해졌다.
• 배포 파이프라인이 표준화된다.

 

3. 이미지

• 이미지에서 컨테이너를 생성하기 때문에 반드시 이미지를 만드는 과정이 필요하다.
• Dockerfile을 이용하여 이미지를 만들고 처음부터 재현 가능하다.
• 빌드 서버에서 이미지를 만들면 해당 이미지 저장소에 저장하고 운영서버에서 이미지를 불러올 수 있다. (dockerhub)

 

4. 설정

• 설정은 보통 환경 변수로 제어한다. 애플리케이션 내에의 설정 파일을 이용하지 않고 도커에서 관리한다.

 

5. 자원

• 컨테이너는 삭제 후 새로 만들면 모든 데이터가 초기화된다.
• 업로드 파일을 외부 스토리지와 링크하여 사용하거나 S3 같은 별도의 저장소가 필요하다.
• 세션이나 캐시를 파일로 사용하고 있다면, memcached나 redis와 같은 외부로 분리하다.

 

도커의 등장으로, PaaS와 같은 제한이 없어지고, 클라우드 이미지 보다 관리하기 쉬워졌다.

도커의 장점으로, 컨테이너 하나하나가 하나의 서버처럼 다루게 되어 여러 대의 서버와 여러대의 서비스를 관리하는데 비용과 어려움이 생겼다.

- 관리 비용이 많이 든다.

- 여러 대의 서버와 여러 개의 서비스를 편리하게 관리해 주는 작업 (K8S)

 

7) 쿠버네티스 등장

k8s는 컨테이너를 쉽고 빠르게 배포/확장하고 편리하게 관리해 준다. = 컨테이너 오케스트레이션

k8s는 컨테이너 레이어를 잘 관리하지만, 애플리케이션 레이어는 관리하지 못하는 단점이 존재한다. 따라서 컨테이너 레벨에만 로깅과 모니터링이 가능하지, 자바의 힙 메모리 등 애플리케이션 레이어에 대해서는 잘 알지 못한다.

따라서 컨테이너는 잘 동작하지만 애플리케이션에서 장애가 생겼을 경우 문제가 생길 수 있다.

 

8) 서비스 메시 등장

서비스 메시는 애플리케이션 레벨을 탄력적 있도록 관리할 수 있도록 도와준다.

- ex) Istio Framework

서비스 메시는 다음과 같은 기능이 있다.

• 서비스 발견
• 부하 분산, 경로 관리, 트래픽 관리 - 부하 분산 처리
• 운영 탄력성
• 오류 주입
• 로깅/모니터링
• 분산 추적
• 보안
• 인증, 인가

 

마무리,,

각 기술들의 깊이 있는 내용은 아니었지만, 각 기술들의 단점이 무엇이고 해당 단점을 극복하기 위해 어떤 기술이 등장했는지에 대한 흐름을 알 수 있었다. 덕분에 클라우드를 이해하는데 많은 도움이 된 것 같다. 

 

최신 기술이라고 무조건 좋은 것도 아니고, 기술을 많이 적용하는 것도 정답은 아닌 것 같다. 내 환경에서 내가 해결하고자 하는 문제에 대해서 고민하고 설계하는 과정에 집중해 기술을 선택하고 잘 적용해야겠다.