이 포스트는 2019년 6월 29일 토요일, SK플래닛 T아카데미에서 진행됐던 세미나에 가서 청강하고 작성했습니다.
현재 세미나 강의와 자료는 추후 이 곳에서 확인하실 수 있습니다.
노트 필기식으로 작성한 내용이기에, 존댓말을 사용하지 않은 점 참고하시기 바랍니다.
* 발표자 : 김충섭 (퍼플웍스) 님
도커가 등장하기 전 서버 운영
자체 운영 → 설정 관리 도구 → 가상 머신 → 클라우드 → PaaS → 도커 → 쿠버네티스 → 서비스메시
- 서버의 상태를 관리하기 위한 노력이 이렇게 많다.
자체 서버 운영
- 서버를 설정하기 위한 많은 노력과 시간이 필요하다.
- 성능이 좋은 걸 미리 구매하고 효율적인 사용을 위해 여러 애플리케이션을 설치하게 되었다.
과거, 어려운 서버 상태 관리
소프트웨어 버전 업그레이드를 수행했다?
그 이후 어떻게 동작될지, 어떤 결과를 초래할지에 대해 정확히 알고 있어야한다.
(와르르 무너지거나, 운이 상당히 좋으면 아무렇지 않게 동작이 잘 되거나!)
서버가 잘 돈 것처럼 보이지만, 카드로 탑 쌓듯이 언제 어떻게 무너질 지 모르는 상태로 진행되는 것이다.
서버 이슈가 어떤 것이든, 어떠한 문제이든, 무조건 서버 관리자가 있어야하며,
서버 관리자의 피로는 물론이거니와 심각한 상태이기에 메이저 버전을 업그레이드 해야함에도 불구하고,
그에 따른 후속 조치와 결과에 벌벌 떨어야 하기 때문에 혁신 자체가 어려운 상태가 됐다.
이로 인해…
설정 관리 도구의 등장
- 명령어를 통해 서버 관리를 지양하지 않음
선언적 서버 상태 정의
- 불완전하지만, 서버의 상태가 재현 가능하다.
- 소스 관리나 코드 리뷰를 통해 서버 운영의 협업이 가능하다.
- 영상에서 확인 할 수 있듯이 이처럼 다양한 환경 변수가 존재.
- 좀 쉬워졌지만 결국엔 원하는 도구에 대한 개념과 설정 값들을 정확하게 이해해야한다.
가상머신 등장
- 한 서버에 여러 가상 서버 설치 가능
- 다양한 Java, 데이터 베이스 쉽게 사용
- 서버 상태 자체를 이미지로 저장 가능
- 새 서버를 만들고, 기존 서버 내용 복사 가능
Mutable(변할 수 있는) vs. Immutable (변하지 않는)
mutable
새 애플리케이션을 업데이트
immutable
새 버전이 설치된 서버 상태를 이미지로 만들고 교체. 대부분 완벽한 상태로의 전환이 가능하다.
- 시스템의 mutable한 부분을 immutable하게 바꾸기 위해선, 복제 등에 대해 상당한 시간과 노력이 필요하다. 그리고, 이에 따라 시스템 자원에 대해 상당히 의존적이다.
클라우드 등장
- AWS, GCP, Azure 등
- 하드웨어 파편화 문제 해결, 가상 환경으로 아키텍처 구성 가능
- 이미지 기반의 다수 서버 관리 가능
그러나
모든 개발자가 하나의 애플리케이션 시스템을
- 어떻게 만들었는지 정확히 모른다
- 처음부터 다시 만들기 어렵다
- 편의성 측면에서 관리가 어렵다
PaaS 등장
- Heroku, Netlify, AWS Elastic Beanstalk, GCP App Engine 등
- 서버 운영하는 것은 복잡하고 어려우므로, 개발자 소스 코드만으로 배포 가능함.
- 일반화된 프로비저닝 방법 제공 (정확한 방식을 잘 따르면 쉽게 배포가 가능)
- Github 프로젝트를 참고하여 Basic build settings 작성하고, 웹 상으로 시스템을 배포하기
- 기존 클라우드보다 손쉽고 빠른 서비스 런칭이 가능하다.
그러나…
- PaaS 방식에 맞게 애플리케이션 작성 (버전 의존성이 상당히 높음)
- 서버 원격 접속 시스템을 제공하지 않음
- 파일 시스템을 직접 사용할 수 없음
- 패키지 설치 관리자에 대해 제한적
- 로그 수집 자체를 제한적인 방식을 이용해야 한다
- 배포에 대한 새로운 패러다임 자체를 이해해야 한다.
- 크론잡, 데이터 분석, 로그 분석, 앱 성능 모니터링, A/B 배포, Canary 배포, 네트워크 및 스토리지 설정에 제한적
즉, 조금 더 심층적으로 다룰 수 있는 환경을 제공하지 않아 다양한 이슈들을 세밀하게 대응하기가 상당히 제한적이다.
Docker 등장
‘19차 T아카데미 세미나 : 컨테이너 기반 가상화 플랫폼 도커(Docker)의 이해’ 블로그 포스트 참고
- 리눅스 커널의 여러 기술 활용
- Host OS 위에 Docker Engine이 직접, 각각의 앱들을 격리시킴
- 특정 회사나 서비스에 종속되지 않음
- 개발 서버를 쉽게 만들 수 있으며 테스트 서버 생성도 간편함
- 서비스들의 배포 방식이 제각각 다른데, 이를 표준화된 명령어를 제공함으로 해결
- Dockerfile 이용하여 이미지 만들고 재현 가능
- 이미지 저장소로 저장하고 운영서버에서 이미지를 불러오기 간편함
- 환경변수 제어 가능, 외부 스토리지와 링킹 가능
- 가상머신 처럼 사용하지만 성능저하가 거의 없음
- 이미지 빌드 기록이 남음
- 코드와 설정으로 관리 가능
- 오픈소스
Blue - Green 배포
- 앱 업데이트를 위해 서비스를 종료했어야했지만, 현재는 이를 컨테이너를 교체하는 방식으로 사용 가능
Service Discovery
- 복잡한 기술을 사용자가 일일히 했지만, 이는 개선했음.
- Key/Value Store에 해당 서버 주소가 기록이 되어 있기 때문에, 서버 주소를 추가하고 기입하면 자동으로 반영된다.
docker-gen
- Docker Container가 생성되면 이에 대한 이벤트가 발생되고, 원하는 작업을 자동으로 수행해주는 도구
컨테이너 오케스트레이션
- 여러 대의 서버와 여러 개의 서비스를 편리하게 관리해주는 작업
스케줄링
- 컨테이너를 적당한 서버에 배포해주는 작업
- 자동으로 스케일링 업/다운이 가능
클러스터링
- 여러개 서버를 마치 하나의 서버처럼 작동
- 여러 클러스터를 묶어준다
그 이외
- Service Discovery, Logging Monitoring 등이 있다.
현재 Kubernetes가 표준화 되어 있다.
서비스 매시 등장
- 김충섭님 : “현재 가장 트렌드한 기술이라고 생각합니다.”
- 서비스마다 Proxy가 대신 서비스를 재시작 등을 할 수 있음
- Fault Injection, Distributed Tracing, Security, Authentication 등이 기존 방법에서 추가된 기능
- Library가 아니라 Proxy를 사용한다
- 서비스A <-> 서비스 B 요청은 각각 서비스에 존재되어 있는 Proxy를 통해 교신한다.
결론
위 과정들은 모두 서버 상태를 관리하기 위한 노력!
- 쉽고 편리하게 서버 관리를 하기 위한 필요성에 등장
- Immutable 하게 앱, 스토리지 또는 로그를 분리하여 관리
- 확장 가능한 설계