현 포스팅은 마이크로서비스의 특징을 짚어보고, 왜 K8S 를 사용하는 것이 효율적인지 이유를 핵심으로 다루었습니다.
K8S 의 등장배경
몇년전까지만 해도 개발되던 거대한 모놀리스 레거시 애플리케이션은 릴리스 주기가 느리고 업데이트가 자주 되지 않는 편입니다. 이런 모놀리스 애플리케이션은 점차 마이크로서비스라는 독립적인 실행되는 더 작은 구성 요소로 세분화되었죠.
마이크로서비스는 서로 분리되어 있기 때문에 개별적으로 개발, 배포, 업데이트, 확장이 가능합니다. 하지만 배포 가능한 구성 요소 수가 많아지면서 시스템을 원활히 구성, 관리하는 일이 어려워졌습니다. 이런 구성 요소의 서버 배포를자동으로 스캐줄링하고 구성, 관리, 장애 처리를 자동화해주는 작업이 필요하게 되었으며, 이것이 바로 쿠버네티스가 등장한 이유입니다.
쿠버네티스틑 하드웨어에 장애가 발생시 해당 애플리케이션을 자동으로 모니터링하고 스캐줄링을 조정해서 운영 팀을 도와주는 강력한 기능을 지닙니다.
모놀리스 애플리케이션의 한계
버전 관리가 불편하다
모놀리스 애플리케이션은 전체 애플리케이션이 하나의 운영체제 프로세스로 실행되기 때문에 하나의 객체로 개발, 배포, 관리되어야 합니다. 애플리케이션의 한 부분을 변경하면 전체 애플리케이션을 재배포해야 합니다.
수직확장(Scale In), 수평확장(Scale Out) 하는 것도 한계가 있다
또 애플리케이션을 실행하기 위한 인프라를 구축시 서버 부하를 위해 수직확장, 수평확장을 진행해야할 상황이 발생할겁니다. 그러나 Proxy Server와 로드밸런싱, 수평확장(Scale Out)과 수직확장(Scale Up)에 대해 에서도 언급했듯이, 수직확장은 애플리케이션을 변경할 필요가 없지만 비용이 많이 들죠.
반면 수평확장은 저렴하지만 애플리케이션의 코드의 큰 변경이 생기게됩니다. 그러나 서버가 1000대 이상으로 수없이 늘어난 경우라면 이 작업도 매우 곤란해집니다.
마이크로서비스의 등장
독립적인 프로세스
앞서 살핀 기존의 복잡한 모놀리스 애플리케이션을 마이크로서비스라는 독립적으로 배포할 수 있는 작은 구성 요소(서비스)로 분할함으로서 단점을 보완할 수 있게 되었습니다.
각 마이크로서비스는 독립적인 프로세스로 실행되며, 단순하고 잘 정의된 API로 다른 마이크로서비스와 통신합니다. 일반적으로 RestAPI 를 제공하는 HTTP 프로토콜로 통신하죠.
각 마이크로서비스는 대체로 정적인 외부 API를 제공하는 독립형 프로세스이기 때문에, 개별적으로 개발 및 배포가 가능합니다. API 코드가 변경되지 않거나 이전 버전과 호환되는 방식으로 변경됐다면 이들 중 하나를 변경해도 다른 서비스를 변경하거나 재배포하지 않아도 됩니다.
마이크로서비스의 확장성과 배포
마이크로서비스의 강점
전체 시스템을 확장해야하는 모놀리스 시스템과 달리 마이크로서비스 확장은 각 시스템별로 수행되므로 리소스만 필요한 서비스만 별도로 확장 가능합니다.
또한 필요에 따라 특정 구성 요소(서비스)는 다른 서버에 배포된 여러 프로세스로 복제, 실행되며 다른 구성요소는 애플리케이션 프로세스 하나로 실행됩니다. 모놀리스 애플리케이션의 구성요소가 확장이 불가능한 경우, 애플리케이션을 마이크로서비스 형태로 분할해서 수평확장 또는 수직확장을 가능하게 합니다.
마이크로서비스의 한계
세부적인 서비스 기능을 각자 팀마다 개발시, 동일한 일관된 환경을 맞추면서 개발하기가 힘들다.
하지만 구성 요소가 많아지면서 배포 조합의 수뿐만 아니라 구성 요소간의 상호 종속성 수가 더 많아지므로 배포 관련 결정 및 설계가 어려워집니다.
마이크로서비스는 여러개가 서로 함께 작업을 수행하므로 서로를 찾아 통신해야합니다. 또 마이크로서비스는 여러 프로세스와 시스템에 분산되어 있기 때문에 버그가 발생할 경우 추적하기 어렵다는 한계가 있습니다.
또한 마이크로서비스 아키텍처의 구성요소는 한 애플리케이션의 각 구성요소간의 종속관계를 잘 고려해야한다는 까다로움이 존재합니다. 각 구성요소는 독립적으로 배포될 뿐만 아니라 독립적인 방식으로 개발된다고 했었죠? 각 구성요소를 개발하는 팀이 세부적으로 여럿 존재할텐데, 각 팀이 다른 라이브러리를 사용한다면 호환성 문제가 발생할 수 있습니다.
데브옵스로 애플리케이션에 일관된 환경을 제공해볼까?
이렇듯 개발시 애플리케이션을 실행하는 환경이 각 팀과 부서마다 다를 수 있다는 문제점이 존재합니다. 인프라 및 프로덕션 머신의 환경(ex. OS, 라이브러리, 네트워크 환경 등) 도 시간이 지남에 따라 버전이 변할 수 있어서, 모든 환경요소를 동일히 맞추기란 굉장히 힘든일입니다.
따라서 상충되는 다른 버전의 라이브러리와 환경을 필요로 각자 개발되었을지라도, 프로덕션 시스템은 운영하는 모든 애플리케이션에 호환되는 적절한 환경을 제공해줘야합니다.
또한 시간이 지나고도 해당 서버의 기존 애플리케이션에 영향을 주지않고 동일한 서버에 새로운 버전의 애플리케이션을 추가할 수 있는 기능을 제공해야 좋을것입니다.
데브옵스의 필요성
과거 개발팀의 업무는 애플리케이션을 만들고 배포하고 관리하며 운영(인프라)팀에 넘겨주는 방식이었죠. 그러나 이제는 개발팀이 애플리케이션을 배포하는 것에 더 많은 관여하는 방식을 바로 데브옵스라고 합니다.
개발자는 프로덕션 인프라 환경에서 애플리케이션을 실행하고 더 관여하는데 기여하면 운영팀이 직면하는 문제가 무엇인지 더 잘 알수있게됩니다. 개발자는 그에 따라 인프라 구조를 더욱 잘 파악하고 피드백이나 개선점을 빠르게 반영할 수 있습니다.
개발자가 만일 새로운 기능 개발에 집중하고 싶고, 운영팀은 인프라 관리에만 집중하고 싶다면 쿠버네티스(Kubernetes)를 사용하면 좋습니다.
쿠버네티스를 통해 하드웨어를 추상화하고 이를 애플리케이션 배포, 실행을 위한 플랫폼으로 제공함으로써 개발자는 시스템 관리자의 도움 없이도 애플리케이션을 구성, 배포할 수 있습니다. 또 시스템 관리잔는 실제 실행되는 애플리케이션을 잘 알 필요없이 인프라를 유지하고 운영하는데 집중할 수 있습니다.