이번에 할 것은 Docker, k8s, terraform 으로 구현하는 마이크로 서비스 라는 책을 보면서 정리한 내용을 기재할 것이다.
마이크로 서비스란 무엇인가?
정의
- 마이크로 서비스는 개별적으로 배포 일정을 갖고 업데이트 운영이 가능한 작고 독립적인 소프트웨어 프로세스
- 이는 반드시 다른 마이크로 서비스와 별개로 업데이트가 가능해야한다는 말이다.
마이크로서비스는 어떤 개발자나 개발팀이 소유하고 관리가 가능하다.
각각의 마이크로서비스는 고객과의 상호작용을 위해 외부에서 접근 가능하도록 노출할 수 있고, 순수하게 내부적으로만 사용하는 서비스로 외부 접근을 허용하지 않을 수도 있다. 특히 접근을 막는 경우는 DB, 파일 저장소, 상태 저장 메소드 등이다.
마이크로서비스는 하나의 기능만을 갖고 있지 않다.잘 설계된 시스템이라면 단순한 서비스들로 구분이 가능하다. 또한 이 서비스들 끼리 서로 연결되어 커다란 앱(마이크로서비스 앱)과 같은 기능을 제공한다.
마이크로서비스 앱이란?
기존에 알고 있던 분산 애플리케이션 이며, 격리된 프로세스와 네트워크 통신을 하는 작은 구성 요소로 이루어진 시스템을 말함. 가상으로 구분된 컴퓨터에 위치하지만 가끔은 물리적인 컴퓨터로 구분돼 있는 경우도 있다.
마이크로서비스 앱은 클러스터 안에서 동작하는 여러 개의 작고 독립적인 서비스로 구성된다.
왜 마이크로 서비스를 선호할까? 여기서는 마이크로 서비스와 반대되는 개념인 모놀리스를 확인해볼 필요가 있다.
모놀리스란?
위 이미지에서 왼쪽 이미지와 같이 한곳에 모든 기능이 다 들어가 있는 아주 멋진 녀석이다...
모놀리스의 문제점
- 모놀리스는 전체적인 앱이 단일 프로세스로 동작하는 경우를 말한다.
말 그대로 모놀리스란 모든 기능이 합쳐저 있는 하나의 앱을 의미한다. 분산되어 있지 않고 하나의 코드가 수정되어도 전체 앱을 배포해야하기 때문에 위험도가 높다.
마이크로서비스 보다 모놀리스 앱이 더 만들기 쉽다. 전체 앱을 한 프로젝트 내에서 만들고 배포하면 끝이기 때문에 더 적은 기술과 설계 방법이 필요하기 때문이다.
새로운 앱을 만들때의 좋은 시작점이기도 하다.
하나의 모놀리스 앱을 만든 후 천천히 마이크로 서비스로 분리하는 방법도 좋다
모놀리스는 나중에 버릴 수 잇는 실험적 모델을 만들어보기에 적합하다. 작은 범위에서 또는 나중에 추가적인 기능 확장이 필요 없이 빠르게 잘 동작하게 만들려는 앱들이 그 예다.
그리고 무조건 적으로 마이크로 서비스로 만들기보다 앱이 항상 작은 규모에 서비스 확장을 할 필요가 없으면 모놀리스가 적합하다.
대부분의 제품들은 성장하고 개선되며, 모놀리스 앱도 마찬가지로 더 많은 유용한 기능을 갖추면서 커지고, 새로운 실험적 기능을 추가하고 없애기가 더욱 어려워진다.
모놀리스는 잠재적 문제들을 동반한다. 처음에는 작게 시작하면서 코드를 깔끔하고 잘 정리해서 운영할 것이라는 목표에 항상 최선을 다하지만... 한 회사에 몇십년을 근무하는 사람은 드물다.
기존에 관리자 들이 바뀌어 가고 새로운 관리자가 들어오면서 처음의 의도와는 다르게 설정해 놨던 목표와 다르게 흘러가기도하고,
모든 코드가 같은 프로세스에서 동작하므로 방대한 스파게티 코드가 되는 것을 막을 방법이 없고, 일부만 따로 떼어놓고 작업하는 것도 불가능하다.
새로운 개발자는 자신의 생각에 맞게 앱의 모델을 개발하고 초기의 관리자가 설정한 목표는 유별나다고 여기기 쉽다.
이런 일이 반복되면....
음쓰 코드의 탄생
시간이 더 흐르면 여러 손을 거치며 코드가 변경되고, 위의 나쁜 영향이 확산되어 코드는 스파게티를 뛰어넘어 위와 같은 음식물 쓰레기로 변하게 된다. 이는 앱의 설계 구조를 알아볼 수 없을 정도로 망가진 상황을 말한다.
모놀리스 앱의 코드를 변경하는 것은 위험한 작업이다. 모놀리스 앱의 동작을 손상시킬 코드를 푸시하고 나면 앱의 전체 동작을 멈추게 만들고, 동작이 멈추면 멈춘 동안의 시간은 회사 또는 개인의 손해로 올 수 있다.
코드 한줄만 바꾸고 싶지만 여전히 전체 앱을 배포해야되고 장애 발생 위험을 감수해야한다. 이 위험은 개발을 기피하고 , 전체 개발 속도를 느리게 만든다.
또한 모놀리스 앱의 구조가 악화되면서 예상하기 힘든 장애가 발생할 수 있는 가능성이 증가하고, 테스트는 점점 어려워지고.. 배포는 점점 머리가 아파온다...
완성된 모놀리스 앱에 적합한 시스템 용량 때문에 테스트에 어려움이 따르고, 매우 낮은 수준의 독립적 구성 요소를 갖기 때문에 확장성이 떨어진다. 결과적으로 모놀리스 앱을 실행하는 물리적 컴퓨터 자원의 제약에 의해 확장성이 정해진다.
오래 묵은 모놀리스 앱이 점점 더 많은 물리적 자원을 소비한다면 더 많은 운영 비용이 발생한다.
위에서 이렇게 까내리긴 했지만 사실 많은 앱은 규모가 작다. 자신의 역할을 충분히 이행하는 모놀리스 앱이 있으며 확장이나 개선이 필요없다.
추가할 것들이 없어서 성장에 따른 문제도 만나지 않는다. 자신의 앱이 작고 간단하게 남을 수 있고, 특별한 기능 향상도 필요없다면 모놀리스로 제작하는 것이 답이다.
왜 마이크로서비스를 많이 사용할까?
요즘에는 클라우드의 가상화, 가상 인프라 관리 자동화 도구의 힘을 얻어 분산 시스템의 구축 비용이 줄었다. 분산 애플리케이션 기반의 모놀리스 앱을 대체하기 위한 비용이 줄면서, 앱의 구조를 향상하기 위한 방법을 당연히 고민하게 됐다. 따라서 분산 시스템의 구성 요서들을 가능한 한 작게 많들었고, 이것을 마이크로서비스라고 부르고 있다.
위와 같은 점이 마이크로서비스 사용량이 늘어난 이유이다. 오늘날의 복잡한 앱을 제작하기 위한 일방적인 장점 뿐만 아니라, 비용을 줄이는 효과도 있기 때문이다.
내 생각에는 사이즈가 커지면 커질 수록 서버의 자원을 높이는 스케일업의 방식이 달라지는데 수평적으로 스케일 업을 하는 것이 아닌 수직적인 스케일 업을 한다고 생각한다. 그리고 수직적인 스케일 업을 한 것을 다시 수평적으로 스케일 아웃을 하려고 하다보니 스펙 높은 서버를 여러대를 사용해서 비용적 면이 증가한다고 본다.
그래서 마이크로서비스 같이 한 기능마다 서버를 두고 한다면 낮은 스펙으로 스케일 아웃을하면 높은 스펙으로 스케일 아웃한 것 보다 비용적인 면으로 좋다고 생각한다.
마이크로서비스의 장점
분산 애플리케이션은 여러 장점을 가진다. 단위 서비스는 잠재적으로 자신만의 프로세서, 메모리와 같은 자원을 가질 수 있다.
전형적인 예로 많은 서비스들이 물리적인 인프라를 공유해 마이크로서비스의 가성비를 좋게 만든다. 반대로 필요한 서비스를 격리해 무거운 서비스를 위한 자원을 따로 확보해 사용하도록 구성할 수 있다.
각각의 작은 서비스는 독립적으로 확장 가능하며, 이러한 확장성이 앱의 성능을 최적화 하기 위한 세밀한 조정을 가능하게 한다.
세밀한 제어가 가능 : 마이크로서비스는 확장성을 바탕으로 섬세하게 조정할 수 있는 앱을 만들 수 있다.
배포 위험의 최소화 : 마이크로서비스는 일련의 개발과정 속도가 빠르므로 배포 위험을 줄이는 데 도움이 된다.
자신이 이미 보유한 기술 선택 : 마이크로서비슨느 수행할 작업을 위한 올바른 개발도구를 선택할 수 있게 만드므로, 특정 기술이나 도구에 의해 생기는 제약이 없다.
마이크로서비스의 단점
어렵다.
가파른 학습곡선을 의미한다. 마이크로서비스를 만드는 방법을 배우는 과정은 여러 기술들을 복잡하게 구성해내는 방법은 물론이고, 분산 애플리케이션을 만드는 원칙과 기술을 배워야한다.
하지만 MSA 를 배워 놓는 다면 단점을 커버치는 장점을 맛볼 수 있다...
'아키텍처 패턴 > 마이크로 서비스' 카테고리의 다른 글
| 3. Azure Storage 설정 (0) | 2023.08.15 |
|---|---|
| 2. 마이크로 서비스 준비 (0) | 2023.08.15 |
Comment