도커의 필요성, 마이크로서비스를 통한 큰 그림 그리기

2022년 7월 5일

#Docker

서버는 24시간 구동이 필요하며, 특정 목적으로 사용되는 프로그램 많다. (웹서버)
다양한 리눅스 패키지와 업데이트로 프로그램 설정이 수시로 바뀐다.
서버 이전시 이전할 서버에 맞도록 재설정 필요하다.
- 서버 관리자 들이 싫어하는 사례 😢

-> 위 번거로운 작업을 해결하는 DOCKER 이다!

DOCKER?

일종의 서버 환경을 감싸서, 도커 레벨로 서버를 다룰 수 있다. (= 도커로 감쌌다! 말았다! 라고 표현)
위에 나온 서버 이전, 패키지 버전 변경 등 서버 설정 불필요하다.
단순히 도커를 만들어 서버에서 실행하면 된다!

웹서비스 개발과 마이크로 서비스

모놀리틱 구조
- 하나에 서버에 모든 기능을 넣는 구조이다.
  - 1세대 : READ Static HTML
  - 2세대 : Create request based HTML from CFI + DB
  - 3세대 : MVC 패턴 기반 프레임워크 활용
- 문제점 : 서비스가 방대해지면서, 하나의 서버에 기능을 모아 놓으면, 특정 기능의 문제로 전체 시스템에 장애 발생한다…
마이크로 서비스
- 여러 서버에 각 기능을 분산해놓고, REST API 등 통신을 통해 전체 서비스 운영하는 방식이다.

개발팀과 운영팀

마이크로 서비스 조직은 각 조직이 각각의 세부 서비스를 담당하고 수시로 릴리즈한다.
기능 릴리즈 → 개발팀이 운영팀에 어떻게 운영할지 안내 → 많은 기능이라면 알려주기 어렵고, 운영이 잘 안될 경우 운영팀에서 알려주지 않음 → 서비스 다운 혹은 비정상 동작으로 고객 경험 저하
수많은 마이크로 기능과 수많은 사용자가 존재한다면…
- 엄청한 트래픽을 견딜 시스템과 운영팀 필요하다.

-> DevOps 분야는 이를 위한 해결책으로 등장하였다.

DevOps

운영 + 운영시스템 효율화/자동화 프로젝트가 목표이다.
- release system 자동화
- 코드리뷰, 테스트 자동화
- 서비스 모니터링 시스템
- 이슈 발생시 커뮤니케이션 시스템 ⇒ 자동 배포

정리

각 마이크로 서비스 ⇒ 도커 를 통해 개발
초대용량 서비스 유지 보수 위한 서버 핸들링 ⇒ 쿠버네티스 (네트워크 트래픽에 따른 서버 관리)
수시 릴리즈를 지원하기 위한 배포 시스템 ⇒ git 신규 코드 릴리즈 ⇒ Jenkins/Travis CI 등으로 서버 자동 재가동 ⇒ 배포 자동화
서비스 중단은 되지 않도록 ⇒ 무중단 배포