기존의 모놀리션 애플리케이션
몇년 전까지만 해도 대부분의 애플리케이션은 거대한 모놀리식 애플리케이션이였다.
때문에 모든 기능이 하나의 프로젝트로 개발, 배포되며 전체 애플리케이션을 한번에 빌드하고 배포하여야했다.
초기 개발 속도는 빨랐지만 코드가 복잡해짐 + 기능 수정이 다른 기능에도 영향을 미치는 경우가 많아져 유지보수도 어려워지고 확장성 또한 낮아졌다.
🔺위 사진은 모놀리션 애플리케이션의 아키택처 구조이다.
- User Interface : 입력 폼 같은 사용자가 직접 보는 화면.
- Business Layer : 애플리케이션의 핵심 기능을 처리하는 부분.
- Data Interface : DB 내용을 조회해서 정보를 가져오는 부분.
이라고 보면 된다.
단점을 개선하기위해 마이크로서비스 등장
이러한 모놀리식 애플리케이션은 점차 마이크로서비스라는 작고 독립적으로 실행 가능한 구성요소로 쪼개졌다.
마이크로서비스 아키텍처 구조 :
- Microservice UI : 사용자가 보는 화면
- Microservice : 각 기능이 분리된 독립적인 서비스
- Database : 각 마이크로서비스가 가지는 개별적인 DB
🔺그림을 보면 알 수 있듯이 마이크로서비스는 서비스 단위로 서로 분리되어있기 때문에 개별적으로 개발, 배치, 업데이트, 확장 할 수 있다. 따라서 급변하는 비즈니스 요구사항대로 자주, 신속하게 변경이 가능해졌다.
때문에 많은 대규모 서비스들이 모놀리식 구조에서 마이크로서비스 구조로 전환했지만 곧 마이크로서비스 운영에도 문제가 발생했다.
마이크로서비스의 문제 -> 도커로 개선
독립적인 서비스 개수가 늘어나면서 배포 및 관리가 어려워졌으며, 각 서비스가 독립적으로 실행되어야하기 때문에 컨테이너 실행환경이 필요해졌다.
--> 컨테이너 기반으로 마이크로서비스를 배포하고 관리하는 Docker가 등장하였다. 이로인해 개발자가 로컬에서 도커 컨테이너를 실행해보고, 동일한 환경을 서버에서도 실행할 수 있게 되었다.
하지만 서비스를 독립적으로 실행시키기 위해 등장한 컨테이너가 또 점점 많아지면서 문제가 생겼고, 특히 대규모 서비스에서 관리가 복잡해졌다.
도커의 문제 -> 쿠버네티스로 개선
기존 컨테이너 기반 운영의 문제:
- 컨테이너를 자동으로 배포하고 관리하는 기능이 필요했다.
- 크래픽이 많아지면 자동으로 컨테이너를 늘리고, 줄어들면 축소해야했다.
- 여러개의 컨테이너를 하나의 클라스터로 묶어 관리할 필요가 있었다.
--> 이러한 필요성 때문에 쿠버네티스(Kubernetes)가 등장하였다.
쿠버네티스는 컨테이너를 자동으로 배포, 확장, 로드밸런싱하는 기능을 제공하며, 장애가 난 컨테이너가 있으면 자동으로 재시작하고, 트래픽이 증가할때는 자동으로 컨테이너 개수를 조절하기도하며, 여러 서버에 걸쳐 컨테이너를 효율적으로 배포해준다.
이러한 이점 덕에 넷플릭스, 우버 등등 대규모 기업들이 수천개의 마이크로서비스를 쿠버네티스로 관리하기 시작했고,
최종적으로는 마이크로서비스 아키텍처 + 쿠버네티스 조합이 표준이 되었다.
