안녕하세요. 엔지엠소프트웨어입니다. 개발자가 아닌 분들은 아마도 마이크로 서비스라는 용어를 처음 들어볼겁니다. 개발자라고 해도 서버 프로그래머가 아니면 들어는 봤지만, 개념은 생소할수도 있어요. 마이크로 서비스 아키텍처(Microservice Architecture)는 애플리케이션을 작고 독립적인 여러 개의 서비스로 분리하는 아키텍처 패턴입니다. 각각의 서비스는 독립적으로 배포, 확장, 관리될 수 있으며, 서로 다른 기술 스택을 사용할 수 있습니다. 마이크로 서비스 아키텍처는 모놀리식(monolithic) 아키텍처와 대조됩니다. 모놀리식 아키텍처는 모든 기능이 한 애플리케이션 내부에 구현되어 있으며, 한 부분의 변경이 전체 시스템에 영향을 미치는 단점이 있습니다. 반면, 마이크로 서비스 아키텍처는 각각의 서비스가 독립적으로 개발, 배포, 운영될 수 있기 때문에 전체 시스템의 유연성과 확장성이 높습니다.

 

 

마이크로 서비스 아키텍처는 일반적으로 RESTful API, 메시지 큐, 이벤트 기반 아키텍처 등을 사용하여 각각의 서비스가 상호작용하도록 구현됩니다. 이러한 아키텍처를 사용하면 개발자는 각각의 서비스를 작은 조각으로 나누어 개발하고, 독립적으로 테스트하고, 배포하고, 확장할 수 있습니다. 마이크로 서비스 아키텍처는 일반적으로 대규모 분산 시스템, 클라우드 환경, 빠른 개발 및 배포를 필요로 하는 기업에서 사용됩니다. 그러나 구현 및 운영이 더 복잡하며, 서비스 간 통신 오버헤드와 레이턴시 문제가 발생할 수 있습니다.

 

그렇다면 왜 마이크로 서비스 아키텍처를 도입할까요? 이유는 간단합니다. 서비스가 비대해져서 발생되는 다양한 문제들을 해결할 수 있기 때문입니다. 마이크로 서비스 아키텍처의 주요 장점은 다음과 같습니다.

1. 유연성과 확장성: 마이크로 서비스 아키텍처는 각각의 서비스가 독립적으로 개발, 배포, 운영될 수 있기 때문에 전체 시스템의 유연성과 확장성이 높습니다. 필요에 따라 필요한 서비스만 확장할 수 있습니다.
2. 기술 스택 다양성: 각각의 서비스는 독립적으로 개발될 수 있기 때문에 서로 다른 기술 스택을 사용할 수 있습니다. 이는 개발자가 최적의 도구와 기술을 선택할 수 있도록 합니다.
3. 높은 가용성: 각각의 서비스가 독립적으로 개발, 배포, 운영될 수 있기 때문에 전체 시스템의 가용성이 높아집니다. 하나의 서비스가 문제가 생겨도 다른 서비스는 계속 정상적으로 작동할 수 있습니다.
4. 빠른 배포와 개발: 마이크로 서비스 아키텍처는 각각의 서비스를 작은 단위로 나누어 개발하고, 독립적으로 테스트하고, 배포할 수 있습니다. 이는 개발 및 배포의 빠른 속도를 가능하게 합니다.
5. 팀의 독립성: 각각의 서비스를 독립적으로 개발하고 운영할 수 있기 때문에, 각각의 팀이 독립적으로 일할 수 있습니다. 이는 개발과 운영에 대한 책임을 분산시키고, 개발자의 역할을 명확하게 정의할 수 있도록 합니다.
6. 분산 환경 대응: 마이크로 서비스 아키텍처는 분산 시스템에 적합합니다. 서비스 간의 통신은 RESTful API, 메시지 큐, 이벤트 기반 아키텍처 등을 사용하여 구현할 수 있습니다.
7. 기존 시스템 통합: 기존 모놀리식 시스템을 마이크로 서비스 아키텍처로 전환하는 것은 쉬운 작업은 아니지만, 기존 시스템의 일부를 마이크로 서비스로 분리하여 기존 시스템과 통합하는 것은 가능합니다.

 

이러한 장점들은 개발자와 기업에게 유용한 결과를 제공할 수 있습니다. 모놀리식 아키텍처의 주요 단점은 다음과 같습니다.

1. 유연성 제한: 모놀리식 아키텍처는 전체 시스템이 단일 어플리케이션으로 구성되기 때문에, 한 부분의 변경이 전체 시스템에 영향을 미칩니다. 이는 개발자가 시스템을 확장하거나 업데이트할 때 제한을 가할 수 있습니다.
2. 확장성 제한: 모놀리식 아키텍처에서는 전체 시스템을 함께 확장해야 하기 때문에, 필요한 경우 전체 시스템을 확장해야 합니다. 이는 리소스를 낭비하게 될 수 있습니다.
3. 높은 결합도: 모놀리식 아키텍처는 모든 코드가 한 곳에 모여 있기 때문에, 각각의 코드 모듈이 밀접하게 결합됩니다. 이는 코드 수정 및 업데이트가 어려울 수 있으며, 오류 및 결함이 전체 시스템에 영향을 미칠 수 있습니다.
4. 장애 복구 어려움: 전체 시스템이 한 곳에 모여 있기 때문에, 시스템의 장애가 발생하면 전체 시스템이 중단됩니다. 이는 장애 복구가 어려울 수 있습니다.
5. 기술 스택 한정성: 모놀리식 아키텍처에서는 전체 시스템에 대해 단일 기술 스택을 사용해야 하기 때문에, 다양한 기술 스택을 사용하기 어려울 수 있습니다.
6. 높은 복잡성: 모놀리식 아키텍처에서는 전체 시스템을 한 곳에서 관리해야 하기 때문에, 시스템이 복잡해질 가능성이 높습니다.
7. 개발자 역할 분담의 어려움: 모놀리식 아키텍처에서는 개발자 역할이 분담되기 어려울 수 있습니다. 이는 개발자의 역할을 명확하게 정의하기 어렵게 만들 수 있습니다.

 

이러한 단점들은 모놀리식 아키텍처의 한계를 보여줍니다. 마이크로 서비스 아키텍처는 이러한 문제를 해결할 수 있는 대안이 될 수 있습니다. 위의 내용들은 개념적인 내용이라서 잘 이해가 안갈수도 있습니다. 쇼핑몰을 예로 들어볼까요? 쇼핑몰을 구축하기 위해서는 다양한 서비스들이 필요합니다. 결제 기능, 고객 관리, 제고 관리, 상품 관리등이 있습니다. 하나의 서비스를 작게 나눠서 하나의 솔루션안에 프로젝트로 관리하는게 아닌 하나의 솔루션으로 관리하는겁니다. 물론, 결제 기능에도 여러개의 프로젝트가 포함될 수 있지만, 이 부분도 카드사 연동, 결제 지연, 장애 처리 및 복구와 같이 서비스를 분리할 수 있습니다. 하나의 서비스가 다른 서비스에 영향을 주지 않으므로 개별적으로 개발, 테스트, 배포가 가능합니다. 별도의 서비스는 기존에 사용하던 외부 라이브러리 또는 패키지를 버전 업하거나 다른 패키지로 변경이 쉽게 가능합니다. 서비스들이 서로 영향을 주는 모놀리식 아키텍처는 외부 라이브러리나 패키지를 변경하는게 거의 불가능합니다.

 

 

이외에도 다양한 문제들이 존재합니다. 아마 개발자분들이라면 충분히 공감하고 있을겁니다. 마이크로 서비스를 운영할 때 자주 사용하는 툴이나 기술들이 있습니다. 한번쯤은 들어보셨을겁니다. 워낙 이슈가 되었기도 하고, 국내에서도 많은 솔루션 회사들이 도입하고 있으니까요. 도커 컨테이너(Docker)와 같은 독립적인 프로세스에 담아서 배포하기도 합니다. 컨테이너가 많아지면 이걸 관리하기 위해 쿠버네티스(Kubernetes)를 사용하기도 합니다. 그리고, 가장 중요한 서비스간 메세지 통신은 Kafka를 사용합니다. 전통적으로 Tibrv와 ActiveMQ를 사용했었지만, 요즘은 카프카로 통일되었으니 여러분들도 이걸 그냥 쓰시면 됩니다. 엔지엠 매크로 에디터에도 카프카가 포함되어 있습니다.

 

 

서비스 통신에 대해 좀 더 설명하자면 이렇습니다. 위에서도 언급했듯이 쇼핑몰에서 각각의 서비스를 분리해두었다고 합시다. 고객이 상품을 구매하면 상품 관리 서비스에서 제고가 있는지 먼저 파악해야 한다고 생각해보세요. 그러면, 장바구니 서비스가 처리하기 전 상품 관리 서비스에 재고가 있는지 먼저 물어봐야 합니다. 재고가 있다면 장바구니에 담거나 결제가 이루어져야 합니다. 만약, 재고가 없다면 고객에게 재고가 없다고 알려줘야합니다. 이걸 HTTP로 처리하는건 비효율적이라서 각각의 서비스간 통신은 카프카를 사용하는겁니다. 카프카는 여러가지 장점들이 있지만, 그건 나중에 알아보도록 하고 넘어갈께요. 어딘가에 정리해둔 글이 있었던거 같은데... 못찾겠네요.

 

 

여러분들도 여기까지 내용을 이해하셨으면 분산되어 있는 서비스들을 어떻게 관리하고 모니터링할까를 고민할겁니다. 이건 시스템 관리자가 항상하는 고민이기도 합니다. 수많은 서비스가 정상적으로 잘 동작하고 있는지 문제는 없는지 알고 싶으니까요. 특정 서비스에서 장애가 발생하면 해당 서비스를 빨리 수정해야겠죠? 이렇게 서비스들을 모니터링할 때는 프로메테우스(Prometheus)를 사용합니다. 이외에도 아틀라시안의 지라 DevOps를 사용해서 형상관리와 CI/CD를 자동화할 수 있고, 마이크로소프트의 에저 DevOps를 사용할수도 있습니다. 제 홈페이지에도 정리되어 있긴한데... 요즘은 사용하지 않는 젠킨스라는 것도 있습니다.

 

여기까지 내용만 보면, 마이크로 서비스 아키텍처를 도입하면 현재 솔루션 회사들이 가지고 있는 모든 문제점들이 해결될거 같아 보입니다. 그런데, 마이크로 서비스를 도입했다가 망했다는 글들도 많이 보입니다. 모든 시스템에는 장점이 있으면 단점도 존재하기 마련입니다. 하나의 팀에서 개발자들이 모두 정확하게 이해하고 서비스를 개발하면 괜찮습니다. 서로 인터페이스도 정형화가 잘 되어있고, 소통이 잘되면 문제가 없을테지만 모든 조직이 이렇지는 않습니다. 그리고, 모놀리식 아키텍처와 비교해보면 복잡도가 매우 높다는걸 알 수 있습니다.

 

 

위 차트에서 말하는건 개발복잡도를 말하는게 아닙니다. 개발자는 더 쉽게 서비스를 개발할 수 있고, 유지보수, 배포, 관리가 용이해집니다. 하지만, 앞서 말했던 장점들이 대부분 운영과 관련되어 있습니다. DevOps가 하나의 팀이라면 개발자보다 운영자가 너무나 힘든 시스템입니다. 예를 들어서 마이크로 서비스가 10개 이상이면 위에 말한 서비스(Docker, Kafka, Kubernetes, Prometheus, CI, CD, Network, ETC...)들이 무조건 필수로 사용해야 합니다. 운영을 책임져줄 인력이 부족한 중소규모 솔루션 회사라면 이런 툴들을 관리하는데 드는 시간과 비용 때문에 개발할 시간이 부족하게 됩니다. 그리고, 각각의 서비스를 담당하는 개발자가 다르면 장애가 발생했을 때 어디에서 문제가 발생했는지 파악하는데 더 많은 시간이 들어갑니다. A 서비스에서 요청(Request)했는데 B 서비스에서 안줄수도 있고 줬는데(Respone) 요청자가 못 받았을수도 있습니다. 다양한 이슈들이 발생할 수 있기 때문에 서비스간 담당자들이 같이 시간을 들여야합니다.

 

서비스가 10개가 아닌 100개 1,000개라면 내가 이용하고자 하는 서비스가 어디에 있는지 찾아야하고, 서비스를 이용하기 위한 문서를 보고 개발해야 합니다. 문서관리가 안되는 상태라면 서비스 담당자에게 직접 전화하거나 메일을 보낸 후 기다려야 합니다. 하지만 어느회사나 그렇듯이 부하가 걸리는 부서가 있기 마련이고 이런 상태에서 장애가 발생하면 처리하는게 많은 시간이 소요될수도 있습니다. 서비스가 문제라면 그나마 다행이지만, 기능에 문제가 발생되면 처리가 어려울수도 있습니다. 기능에는 여러가지 서비스가 포함되어 하나의 기능이 완성되는데요. 이 때 어떤 서비스가 범인인지 찾아내기가 쉽지 않습니다. 물론, 모든 경우가 다 그렇지는 않습니다. 기능의 흐름을 보면 누가 범인인지 대충 감이 오는것들도 많거든요.

 

 

각각의 서비스 담당자들이 많다보니 다양한 문제점들이 발생합니다. 대기업에서 발생하는 문제들이 마이크로 서비스를 도입한 중소기업에서 발생한다고 생각 해보세요. 회사가 과연 잘 돌아갈까요? 서비스별로 담당자를 지정해야 해서 쓸데없는 인력이 많아지고, 서비스를 나누다보니 불필요한 부서들도 마구 생기게 됩니다. 그리고, 부서간 업무 분쟁도 빈번하게 발생합니다. 누구의 업무인지 불분명한 기능인 경우 더 그렇죠. 이렇다보니 커뮤니케이션에서 오는 피곤함이 가중되고, 관리인력이 필요하게되어 하는일에 비해 팀이 비대해지게 됩니다. 조직이 비대해지면 어떤 문제가 발생할까요? 그렇죠! 의사결정이 늦어지고 협의해야할 사항이 많아져서 회의도 길어집니다. 개발할 시간은 부족한데 이런 관리 영역에서 모든 시간과 노력, 열정을 다 써버리면 정작 회사는 안돌아가게 됩니다.

 

결론은, 충분한 학습과 테스트를 거친 후 현재 회사에 맞는지를 잘 판단하셔야 할거 같습니다. 저희 회사도 여러번 마이크로 서비스를 도입하려다가 반려되기를 수차례 반복했었습니다. 아무래도 중소기업이다보니 빠른 의사결정이 중요하고, POC와 같은 소규모 프로젝트도 빈번하게 발생하다보니 지금 도입하는건 맞지 않다라고 판단했었구요. 제 경우에는 회사와 개인 사업 및 추가적으로 진행하는 여러가지 사업과 서비스들로 인해 다양하게 조합해서 운영하고 있긴합니다. 결국은 CTO 또는 솔루션 개발 리더와 팀장이 잘 판단해야 할 문제라고 생각되어지고, 미래에 서비스가 많아지고 관리가 어려울거 같으니 지금 당장 도입해야 한다는 아니라고 생각합니다. 제가 항상 시스템, 설계, 개발 방법론등등을 글로 작성할 때 자주 언급하는 내용이 있습니다. 수익이 발생하는 서비스를 빠르게 만들고 시장의 평가를 받아보는 것입니다. 가능성을 보고, 서비스를 빠르게 제공하면서 수익을 만들어야 합니다. 생활이 안정되면 회사도 업무도 안정되기 때문입니다. 생활이 안정되지 않으면 자꾸 코인이나 주식 또는 한방 테크트리를 찾게 되는데요. 이건 직장인으로써 경계해야 하는것들입니다.

 

Kubernetes 오케스트레이션 툴

Kubernetes는 컨테이너 오케스트레이션 툴이며, 클라우드 네이티브 애플리케이션을 배포, 확장 및 관리하는 데 사용됩니다. Kubernetes는 Google에서 개발된 오픈 소스 툴이며, 다양한 클라우드 환경에서 실행됩니다. 이 툴은 컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있도록 도와주며, 이를 위해 컨테이너 클러스터를 자동으로 관리합니다. Kubernetes는 여러 개의 컨테이너를 하나의 클러스터로 묶어서 통합 관리를 가능하게 합니다. 또한, 컨테이너의 상태를 감시하고 필요한 경우 자동으로 복제하여 애플리케이션을 확장할 수 있습니다. 또한, Kubernetes는 서비스 디스커버리, 로드 밸런싱, 롤링 업데이트 등 다양한 기능을 제공하여 애플리케이션의 안정성과 확장성을 보장합니다. Kubernetes는 DevOps와 개발자 커뮤니티에서 매우 인기가 있으며, 현재는 대부분의 클라우드 제공 업체에서 지원되고 있습니다.

 

Kafka 메세지버스 툴

Kafka는 분산 스트리밍 플랫폼으로, 대용량의 실시간 데이터를 처리하고 저장하는 데 사용됩니다. Apache Kafka는 2010년 LinkedIn에서 개발되었으며, 오픈 소스로 공개되어 있습니다. Kafka는 Producer, Consumer 및 Broker로 구성됩니다. Producer는 데이터를 생성하고 Kafka에게 전송합니다. Broker는 데이터를 저장하고 분산 처리를 담당합니다.  Consumer는 저장된 데이터를 가져와 처리합니다. 이러한 구조로 Kafka는 대량의 데이터를 처리하고 스트림 처리를 효과적으로 수행할 수 있습니다. Kafka는 대량의 데이터를 안정적으로 처리할 수 있으며, 확장성과 내결함성이 뛰어납니다. 또한, 데이터를 저장하고 처리하는 데 필요한 시간이 짧아 실시간 처리에 적합합니다. Kafka는 데이터 분석, 로그 처리, 이벤트 스트리밍 등에 널리 사용됩니다.

 

Docker 컨테이너 툴

도커(Docker)는 리눅스 컨테이너를 기반으로 하는 컨테이너 기술을 이용한 오픈소스 플랫폼입니다. 컨테이너는 애플리케이션의 실행 환경을 포함하는 기술로, 이를 이용해 애플리케이션을 실행할 때 필요한 모든 것들(코드, 라이브러리, 환경 변수, 설정 등)을 하나의 패키지로 묶어서 전달할 수 있습니다. 도커는 이러한 컨테이너 기술을 이용하여, 애플리케이션의 배포, 실행, 관리를 간단하고 효율적으로 할 수 있도록 해줍니다. 도커는 컨테이너를 생성하고 관리하는 데 필요한 모든 기능을 제공하며, 컨테이너 간의 네트워크, 저장소, 보안 등을 관리할 수 있습니다. 또한, 도커는 개발자들이 각자의 개발 환경에서 애플리케이션을 개발하고, 테스트하며, 운영 환경으로 배포하는 것을 쉽게 할 수 있도록 해줍니다. 도커 이미지를 이용하여 개발 환경, 테스트 환경, 운영 환경 등의 동일한 실행 환경을 구축할 수 있고, 이를 통해 애플리케이션 배포의 일관성과 안정성을 높일 수 있습니다. 도커는 대규모 서비스의 배포 및 운영에서 널리 사용되며, 클라우드 컴퓨팅, 마이크로서비스 아키텍처, DevOps 등의 기술과 함께 사용되는 경우가 많습니다.

 

개발자에게 후원하기

 

추천, 구독, 홍보 꼭~ 부탁드립니다.

여러분의 후원이 빠른 귀농을 가능하게 해줍니다~ 답답한 도시를 벗어나 귀농하고 싶은 개발자~

감사합니다~

추천0 비추천0