[DevOps] 마이크로서비스 아키텍쳐란

이 포스팅은 마이크로서비스 아키텍쳐를 공부하면서 도움이되었던 글로써 마이크로서비스 아키텍쳐를 공부하는데 도움이 되었으면하는 마음으로 번역을 해봤다

 

먼저 마이크로서비스 아키텍쳐를 알아보기이전 모놀리식 아키텍쳐부터 알아가보자

모놀리식 어플리케이션은 어플리케이션의 모든 소프트웨어 컴포넌트가 조립되어 촘촘히 패키지화된 큰 컨테이너이다.

레거시 애플리케이션의 경우 대부분의 레거시 애플리케이션이 주로 단일 아키텍처 로 구현된다고 말할 수 있다. 프로젝트의 모든 기능이  단일 코드베이스 에 존재하는 경우 해당 애플리케이션을 모놀리식 애플리케이션이라고 말한다.

모노리식 아키텍처에서는 사용자 인터페이스, 비즈니스 코드 및 데이터베이스 호출의 모든 것이 동일한 코드베이스에 포함된다.모든 애플리케이션 관련 사항은 단일 대규모 배포에 포함되어 있다. 단일 애플리케이션도 프레젠테이션, 비즈니스, 데이터 계층 등 서로 다른 계층에서 설계한 후 해당 코드베이스를 단일 jar/war 파일로 구현할 수 있다.

모놀리식 접근법에는 몇 가지 장점이 있는데 자세한 장점은 다음 문단에서 설명하겠다. 하지만 여기서 몇 가지 주요 장점과 단점을 말해보겠다.

 

단일 코드 베이스이기 때문에 프로젝트를 쉽게 시작할 수 있다. 프로젝트 구조가 하나의 프로젝트로 구성되어 서로 다른 모듈 간에 비즈니스 상호작용을 디버깅하기 쉽기 때문이다.

 

불행히도 모놀리식 아키텍처에는 많은 단점이 있다. 시간이 지남에 따라 코드 사이즈가 너무 커지기 때문에 관리가 매우 어렵다. 같은 코드 베이스로 병렬로 작업하는 것은 어렵다. 레거시 빅 모놀리식 애플리케이션에 새로운 기능을 구현하기가 어렵다. 변경 사항을 적용하려면 전체 애플리케이션의 새 버전을 배포해야 한다.

 

보시다시피 우리는 모놀리식 아키텍쳐를 이해하고있다.

 

모놀리식 아키텍처를 사용하는 경우

모노리식 아키텍처에도 많은 단점이 있지만 소규모 애플리케이션을 구축하는 경우에도 모노리식 아키텍처는 프로젝트에 적용할 수 있는 최고의 아키텍처 중 하나이다.

왜냐하면 여러 가지 면에서 획일적인 앱은 간단하기 때문이다.

• 빌드
• 시험
• 전개
• 트러블 슈팅
• 수직 확장(스케일업)

매우 쉽고 빠르다.

서비스를 식별하고 개발하기 위해 숙련된 개발자가 필요한 마이크로 서비스에 비해 개발하는 것은 간단하다. 단일 jar/war 파일만 배포되므로 배포가 더 쉽다.

 

모놀리식 아키텍처의 이점

앞에서 설명한 바와 같이 모놀리식 아키텍처는 애플리케이션을 구축하는 전통적인 방법으로 간주되는데 단일 애플리케이션은 단일 빅 코드 베이스로 구축된다. 즉, 하나의 큰 코드 베이스가 있다. 개발자가 업데이트 또는 변경을 원하는 경우 동일한 코드베이스에 액세스하게되면 전체 스택에서 한 번에 변경을 가한다.

그렇다면 모놀리식 아키텍처의 Strengths — Benefits — Advantages은 무엇일까?

 

1. 심플한 개발

모놀리식 접근 방식이 표준 애플리케이션 구축 방식인 한 엔지니어링 팀은 모놀리식 애플리케이션을 개발할 수 있는 적절한 지식과 능력을 갖추고 있습니다.즉, 마이크로 서비스 아키텍처에 비해 개발이 비교적 쉽고 간단하다는 것을 의미한다.

 

2. 디버깅과 테스트가 용이함

마이크로 서비스 아키텍처와 달리 모놀리식 애플리케이션은 디버깅과 테스트가 훨씬 쉽다.단일 애플리케이션은 하나의 큰 코드베이스이기 때문에 end-to-end testing을 훨씬 빠르게 실행할 수 있다.

 

3. 심플한 도입

일원화된 애플리케이션의 심플함과 관련된 또 다른 장점은 도입이 용이하다는 것이다. 일원화된 애플리케이션의 경우, 많은 도입을 처리할 필요가 없다. 단 하나의 파일 또는 디렉토리만 처리하면 된다. 단일 jar/war 파일만 배포되므로 배포가 용이하다. 네트워크 지연과 보안 문제는 마이크로 서비스 아키텍처에 비해 상대적으로 덜하다.

따라서 소규모 애플리케이션을 구축하는 경우에도 모놀리식 아키텍처는 프로젝트에 적용할 수 있는 최고의 아키텍처 중 하나이다.

 

모놀리식 아키텍처의 과제

여러 가지 면에서 모놀리식 앱은 간단하다. 그러나 모놀리식 아키텍처는 많은 문제를 일으킬 수 있는데 시간이 지남에 따라 통제력을 잃기 시작하는 지점에 도달할 수 있다.

 

1. 이해

시간이 지남에 따라 크기가 너무 커지기 때문에 관리가 어렵다. 획일적인 애플리케이션이 확장되면 너무 복잡해져서 이해할 수 없다. 즉, 모놀리식 어플리케이션은 너무 복잡해서 아무도 이해하지 못하게된다.

 

2. 새로운 변경

이렇게 크고 복잡한 애플리케이션에서는 결합이 매우 긴밀하여 새로운 변경을 구현하기가 어렵다. 코드가 변경되면 시스템 전체에 영향을 준다. 이것은 당신이 새로운 변화를 만들 때 두려움을 느끼게 한다. 그리고 이러한 변화는 비용이 많이 드는 부작용을 가져온다. 또한 전체 개발 과정이 훨씬 더 길어지며 구현에 시간이 많이 걸리고 개발하는데 비용이 많이들게된다.

 

3. 신기술 장벽

단일 애플리케이션에 새로운 기술을 적용하는 것은 매우 어렵다. 그러면 애플리케이션 전체를 다시 개발해야 하기 때문이다. 이 상태를 공포의 순환이라고 할 수 있는데 오랜 기간 동일한 단일 애플리케이션을 개발해야 하는 경우 최신 기술을 사용하여 전체 코드 기반을 변경해야 하는 부담이 크다. 새로운 솔루션이나 혁신적인 솔루션을 구축하는 대신 대부분의 시간을 레거시 애플리케이션을 유지 보수하는 데 소비한다.따라서 새로운 기술과 프레임워크를 추가하는 것은 선택사항이 아니게된다.

 

4. 확장성

구성요소들을 개별적으로 스케일링할 수 없다. 단, 어플리케이션 전체를 스케일링 할 수는 있다. 사용 중인 모듈 중 하나가 다른 모듈에 따라 더 많은 요청을 받을 수 있지만, 애플리케이션 내 모든 모듈에 맞게 확장해야 한다. 모듈을 분리하여 독립적으로 확장할 수 없다.

 

모노리식 아키텍처 도입

아키텍처를 설계하고 어떻게 이 아키텍처를 도입할 수 있을지에 대해 생각해보았다. 앞서 말했듯이, 이것은 단일 코드 베이스이기 때문에, 매우 긴밀한 결합으로 이렇게 크고 복잡한 애플리케이션에서 새로운 변화를 구현하기가 더 어렵다. 모든 코드 변경은 시스템 전체에 영향을 미칩니다. 사소한 변경에도 애플리케이션 전체의 완전한 도입이 필요하다. 하지만 그것은 비싸고 위험하다. 모듈 내의 1개의 버그로 인해 일원화된 어플리케이션 전체가 다운되는 것은 신뢰할 수 없다.

위의 이미지를 확인해보자 대규모 개발자 팀은 단일 소스 코드 저장소에 대한 변경 사항을 커밋한다. 코드 커밋에서 실가동까지의 과정은 길고 관리가 어려우며 수동 테스트가 필요하다. 따라서 애플리케이션 규모가 크고 복잡하며 안정성이 떨어지며 유지보수가 어렵다. 이러한 문제를 해결하기 위해서는 아키텍처를 마이크로 서비스 아키텍처로 발전시켜야 한다.

 

모놀리식 아키텍쳐를 알아봤으니 어플리케이션 설계의 마이크로 서비스 아키텍처에 대해 설명해보겠다.

마이크로 서비스를 사용하는 이유

마이크로 서비스는 초기에 시장에서 만연했던 단일 아키텍처의 문제를 극복하고 독립적인 서비스를 구현할 수 있도록 하기 위해 사용되었다.

마이크로서비스가 무엇인지 간단히 설명하기에 앞서 처음에 시장에서 우세했던 아키텍처, 즉 모놀리식 아키텍처에 대해 위에서 살펴봤다.

 

비전문적인 표현으로 말하면 어플리케이션의 모든 소프트웨어 구성요소가 함께 조립되어 촘촘하게 패키지된 큰 컨테이너와 비슷하다고 할 수 있는데 다시한번 정리해보자면

• 유연성이 없음 – 다른 테크놀로지를 사용하여 일원화된 애플리케이션을 구축할 수 없음
• 신뢰성이 낮다 – 시스템 기능 중 하나가 동작하지 않아도 시스템 전체가 동작하지 않는다
• 확장성 – 어플리케이션을 갱신해야 할 때마다 시스템 전체를 재구축해야 하므로 어플리케이션의 확장이 용이하지 않음
• 지속적인 개발 블록 – 어플리케이션의 많은 기능을 동시에 구축 및 도입할 수 없음
• 개발 속도가 느리다 – 모든 기능을 하나씩 구축해야 하므로 단일 애플리케이션 개발은 구축에 많은 시간이 걸림
• 복잡한 어플리케이션에는 적합하지 않음 – 복잡한 어플리케이션의 기능은 밀접하게 관련되어 있음

위의 과제가 마이크로 서비스의 진화를 이끈 주된 이유였다. 그럼 이제 마이크로 서비스가 무엇인지 간단히 설명해보겠다.

 

마이크로 서비스란?

마이크로 서비스는 서로 연동하여 독립적으로 도입할 수 있는 소규모 비즈니스 서비스이다. 이러한 서비스는 네트워크를 통해 대화함으로써 서로 통신하고 많은 이점을 가져온다.

마이크로 서비스는 애플리케이션을 비즈니스 도메인을 중심으로 모델링된 소규모 자율 서비스의 집합으로 구성하는 아키텍처 스타일이다.

주어진 아키텍처에서 각 서비스는 자체 관리되며 단일 비즈니스 기능을 구현한다.

 

가장 큰 장점 중 하나는 독립적으로 배치할 수 있다는 것이다. 그러나 다양한 기술로 작업하게되는 상황이 생기게된다.

 

Martin Fowlers Microservices 기사로부터

마이크로 서비스 아키텍처 스타일은 소규모 서비스 스위트로 단일 애플리케이션을 개발하여 각각 자체 프로세스로 실행되며 HTTP 또는 gRPC API와 같은 경량 메커니즘과 통신하는 방법이다.

이러한 서비스는 비즈니스 기능을 기반으로 구축되며, 완전히 자동화된 배포 프로세스를 통해 독립적으로 배포할 수 있는데 이러한 서비스는 최소한 중앙 집중식으로 관리할 수 있으며, 서로 다른 프로그래밍 언어로 작성되고 서로 다른 데이터 스토리지 기술을 사용할 수 있다.

 

따라서 마이크로서비스 아키텍처는 애플리케이션이 느슨하게 결합되고 독립적으로 구현 가능한 여러 작은 구성요소로 구성되는 클라우드 네이티브 아키텍처 접근 방식이라고 할 수 있다.

 

마이크로 서비스

• 데이터베이스 및 데이터 관리 모델을 포함한 자체 기술 스택을 보유한다.
• REST API, 이벤트 스트리밍 및 메시지 브로커의 조합을 통해 서로 통신한다.
• 비즈니스 기능별로 구성되며, 서비스를 구분하는 라인을 경계 컨텍스트라고 한다

 

마이크로 서비스의 특징

다시 말하지만 마이크로 서비스는 작고 독립적이며 느슨하게 결합되어 있다. 단일 소규모 개발 팀이 서비스를 작성하고 유지할 수 있다. 각 서비스는 개별 코드베이스이며 소규모 개발팀이 관리할 수 있다.

또한 서비스는 개별적으로 도입할 수 있다. 팀은 전체 애플리케이션을 재구축 및 재배치하지 않고도 기존 서비스를 업데이트할 수 있다. 서비스는 자신의 데이터 또는 외부 상태를 유지할 책임이 있는데 이는 별도의 데이터 계층이 데이터 지속성을 처리하는 기존 모델과 다르다.

서비스는 잘 정의된 API를 사용하여 서로 통신한다. 각 서비스의 내부 구현 세부 정보는 다른 서비스에서 숨겨지며 서비스는 동일한 기술 스택, 라이브러리 또는 프레임워크를 공유할 필요가 없다.

 

이러한 특성은 우리에게 몇 가지 중요한 이점을 가져다 준다.

• 코드를 보다 쉽게 갱신할 수 있다. 어플리케이션 전체를 조작하지 않고 새로운 기능을 추가할 수 있다.
• 팀은 컴포넌트별로 다른 기술 스택과 다른 프로그래밍 언어를 사용할 수 있다.
• 서비스는 독립적으로 확장할 수 있으며, 단일 기능으로 인해 과도한 부하가 발생할 수 있으므로 전체 애플리케이션에 대한 낭비와 비용을 줄일 수 있다.

즉, 각 서비스는 다음과 같다.

• 유지 보수성과 테스트성이 뛰어나 신속하고 빈번한 개발 및 도입 가능
• 다른 서비스와 느슨하게 결합 - 팀은 대부분의 시간을 다른 서비스로 변경하지 않고 다른 서비스에 영향을 주지 않고 독립적으로 작업할 수 있다.
• 독립적으로 도입 가능 - 다른 팀과 조정하지 않고 서비스를 도입할 수 있다.
• 소규모 팀이 개발할 수 있으며 대규모 팀의 높은 커뮤니케이션 회피하여 생산성을 높이는 데 필수적이다.

정리하자면 서비스는 HTTP/REST와 같은 동기 프로토콜 또는 AMQP와 같은 비동기 프로토콜을 사용하여 통신하며 서비스는 서로 독립적으로 개발 및 배포할 수 있다. 각 서비스에는 다른 서비스와 분리하기 위한 자체 데이터베이스가 있다.