모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까?

모놀리식과 마이크로서비스 아키텍처중 어떤 아키텍처를 선택해야 하는지에 대해서 요즘IT에 기고했다. 아래는 기고한 글 일부이다.

---

애플리케이션의 아키텍처 스타일(모놀리식 vs 마이크로서비스)에 대한 선택은 트렌드나 경쟁사의 특징을 따르기보다, 애플리케이션의 목표와 비즈니스 요구 사항에 따라 달라진다. (생략) 모놀리식 애플리케이션은 소프트웨어 개발을 위한 기본 접근 방식이다. 그렇다면 마이크로서비스가 대세가 된 현재 모놀리식 접근 방식을 버려야 할까? 만약 모놀리식 애플리케이션에서 마이크로서비스로 전환하면 어떤 이점이 있을까? 마이크로서비스로 애플리케이션을 만들면 비즈니스의 이점은 무엇일까? 이번 글에서는 모놀리식과 마이크로서비스 아키텍처를 비교하여 장단점을 살펴보고, 비즈니스에 적합한 소프트웨어 아키텍처를 선택하는 방법에 대해서 알아보자.

(생략)

개발자라면 누구나 내가 설계하고 작성한 코드가 비즈니스에 큰 가치를 줄 때 성취감을 느낄 것이다. 이것은 우리가 기술을 다루지만, 항상 비지니스를 염두해 두고 고민해야 함을 뜻한다. 이번 글을 참고하여, 현 비즈니스 상황에 최적화된 아키텍처를 선택할 수 있길 바란다.

아래 링크를 통해 원본 글을 볼 수 있다.

기고글 보러 가기

Read More

Monolith 분할 하기

 

모놀리스 분석

대부분 현재 시스템을 잘 설명해주는 문서는 존재하지 않는다. 존재한다고 해도 현행화가 되어 있지 않기에, 오해의 여지가 발생하기도 한다. 상황이 어떻든 최소한 아래의 정보는 수집해야 한다.

• 애플리케이션의 기능 모듈 및 상호간의 관계
• API 및 서비스 인터페이스
• 모듈에 대한 설명이 있는 논리 다이어그램
• 시스템 구성을 알 수 있는 물리 다이어그램

데이터

어떤 데이터를 다루는지 알 필요가 있다. 각 모듈별 어떤 데이터를 다루는지 추출을 해야 향후 마이크로서비스로 전환시 경계를 설정할 수 있다.

현황 파악

기능이 이미 외부에 존재하는 경우도 있다. 이 경우 외부 서비스를 재사용하도록 고려해야 한다.

사용자 파악

애플리케이션을 어떤 사용자가 사용하는지 파악해야 한다. 이 작업을 수행하면 사용하지 않는 기능을 추출할 수 있고 분할 방법, 분할하는 이유 및 효과등을 알 수 있다.

분할해야 하는 이유

모놀리스를 마이크로서비스로 분할해야 하는 이유에 대한 답을 찾기가 어려울 수 있다. 가능하면 두가지를 얻으려고 노력한다. 비즈니스/기술 지향 관점에서 이점을 가져가려고 노력해야 한다.

비즈니스 관점

비즈니스 지향 관점에서 분할하는 이유를 고려해야 한다.

• 애플리케이션 출시 기간 단축
• TCO 절감 → 트래픽 증가시 필요 부분만 확장
• 손실 감소
• 더 나은 사용자 경험 → 이 경우 UX를 반영한 UI가 개선되어야 한다.

현재 프로젝트는 위 4가지 개선 사항이 모두 포함되어 있다.

기술 관점

기술 지향 관점은 비즈니스 Guy들은 이해하기가 어렵지만, 중장기적 관점에서 원할한 MA를 위해서 필요한 작업들이다.

• 더 이상 사용되지 않는 기술을 제거하고 현재 사용중인 기술로 마이그레이션 → Stored Procedure, EAI등
• 복잡성 감소
• 테스트 커버리지 증대 → 장애 감소

오랫동안 사용되었던 시스템을 구조개선해야하는 업무를 수행중이다.

모놀리스 시스템을 분할하기 위해서는 몇 가지 목표를 설정해야 한다. 분할 비용과 분할 되었을 때의 이점을 고려해야 하고, 이 보다 애플리케이션 및 데이터베이스 Scale-up이 더 유리한지 판단해야 한다.

애플리케이션의 특성으로 인해 모놀리스는 매우 지저분해 보일 수 있다. 대규모 시스템이며 상호간 튼튼하게 결합되어 있다.

• 재사용성 고려
• Side effect 최소화

마이크로 서비스로 전환?

마이크로 서비스의 이점

무작정 마이크로 서비스로 전환하려는 것은 아니다. 오래전 Gartner가 소개한 MSA에 대한 관점을 보면, 통합 DB를 사용하는 경우 Miniservices라는 표현을 했고, 현재 구조개선을 해야 할 시스템은 마이크로서비스보단 미니서비스가 적합해 보인다. 모든 것을 한걸음으로 해결하면 좋겠지만 현실은 녹녹치 않다.

이점	요구사항
서비스 유연성: 모놀리스에 비해 상대적으로 작은 서비스는 유연하기에 기능을 수정하기 쉽다.	출시 시간 단축, 개발 비용 절약, 복잡성 해소, 테스트 커버리즈 증대
서비스 재사용성: 서비스는 비즈니스 기능을 중심으로 구성되기에 재사용하기 쉬워야 한다.	개발 비용 절약
표준화된 서비스 개발 및 기술에 구애받지 않는 구현: 다양한 기술이 포함된 Stack을 활용	개발 비용 절약, 더 나은 리소스 계획, 재사용
서비스 확장: 추가, 제거, 업데이트 및 이벤트 대응등 확장하기 쉬워야 한다.	TCO 절감, 더 나은 사용자 경험
복원력: 오케스트레이션을 통한 단일 서비스의 장애 격리	더 나은 사용자 경험, 손실 감소

분할 준비

사전 준비하기

모놀리스를 분할하는 단계이다. 비즈니스 요구 사항, 애플리케이션 상태, CI/CD 프로세스를 고려하여 단계를 조정할 수 있다.

기준이 설정되면 모듈/서비스 목록은 비즈니스 기능을 중심으로 구성해야 한다.

리팩토링

분할해야 하는 애플리케이션이 좋은 형태를 가지고 있을 가능성은 거의 없다. 그 애플리케이션 개발되는 시점에는 최선의 선택이었겠지만, 시간이 흐르면 바라보는 관점이 달라지기 때문이다. 따라서 모놀리스에서 리팩토링이 수행될 수 있다.

우리는 각 유형별 Boiler plate를 만들었고, 개발 되는 모든 작업들은 Boiler plate 표준 기반으로 동작되도록 가이드했다. 기존 시스템도 Boiler plate기반으로 리팩토링을 진행했다. 리팩토링을 진행하면서 Controller, Service, DAO등과 같은 애플리케이션의 주요 계층을 이해하고 관찰했다.

서비스/기능 경계 및 API

비즈니스 모델을 모델링하는 대신 기존 애플리케이션에서 비즈니스 기능을 추출해야 한다. 비즈니스 기능을 기존 애플리케이션 서비스 및 도메인 모델에 매핑하여 경계를 식별하기만 하면 된다.

일반적인 모놀리스 시스템에서 컨트롤러는 API를 추출하는데 도움이 된다. 기존 시스템은 DTO 없이 모두 HashMap으로 Request/Response를 처리하고 있었고, DTO 작업을 통해 Request/Response에 대해 미리 파악할 수 있었다.

서비스 외관 작업

서비스 경계가 정의되면 비즈니스 기능을 한 애플리케이션이 처리하는 대신 상호 작용 방식으로 변경해야 한다. 모놀리스 애플리케이션에서 Facade를 만들고 Facade를 통해 작업해야 한다.

서비스를 추출하기 전에 느슨하게 결합된 모놀리스로 리팩토링 되어야 한다.

데이터

데이터베이스로 하나의 서비스를 추출하면 다른 서비스에 영향을 줄 수 있다. 서비스 데이터에 대한 접근은 데이터베이스가 아닌 API를 통해서만 이루어지도록 해야 한다. (통합DB를 사용하더라도, 가능하면 계정을 분리하고 각 서비스에서 제공하는 API를 통해 접근해야 한다.)

이 작업은 상당한 노력이 필요하다. 우리팀의 경우 예기치 않은 Join이 발생했을 경우를 제외하고는 이 정책을 유지하려고 노력중이다.

모놀리스 시스템의 새로운 기능 추가 중단

미니서비스로 분할하는 작업을 진행할 경우, 기존 운영중인 모놀리스 시스템과 병렬로 작업이 수행된다. 이 경우 모놀리스 시스템에 추가되는 기능은 법적인 문제, 버그등으로 제한할 필요가 있고, 신규 기능들은 새롭게 구현되는 미니서비스에서 충족시켜줄 필요가 있다.

사전 준비 마무리

위에서 언급한 단계는 모두 분할전에 수행되어야 한다. 애플리케이션은 세분화된 서비스, API 및 경계, 각 서비스간 데이터 격리의 정책을 기반으로 느슨하게 결합된 모놀리스로 제공되어야 한다.

분할 수행

분할할 서비스 우선 순위 지정

비즈니스 기능/도메인별로 기존 애플리케이션을 재구성/리팩토링/그룹화하려는 시도가 필요하다.

• 가장 자주 변경되는 서비스: 배포에 대한 영향을 최소화
• 외부 서비스로 대체될 수 있는 서비스: 굳이 개발할 필요가 없기에
• 확장해야 할 서비스: 성능을 최적화
• 서비스 복잡성: 자동화된 프로세스 구축

마이크로 서비스간 통신 방식 선택

대부분의 경우 REST 또는 gRPC를 선호한다. 이유는 상대적으로 단순하고, 팀내에 경험자가 많고, 다양한 도구의 지원이 가능하기 때문이다.

서비스 구현

통신 방식을 선택 후, 미니서비스를 구현한다. 기존에 리팩토링된 모놀리스의 코드를 참조한다.

미니서비스 사용으로 전환

구현이 완료되면 통합 테스트 후, 기존 모놀리스에서 미니서비스로 프로덕션 레벨에서 전환한다.

Read More

모놀리스 애플리케이션을 MSA(마이크로서비스)로 마이그레이션 하는 방법

이쪽 업종에서 일하는 분들이라면 Monolith으로 구현되어 있는 레거시 시스템을 마이크로서비스로 마이그레이션 하고자 하는 Needs가 있을 것이다.

비즈니스를 분석해서 새롭게 만드는 것이 가장 좋은 방법이겠지만, 레거시와 병행해서 개선을 해야 할 상황도 존재하기에 새롭게 만드는 것이 여의치 않은 경우도 많을 것이다.

나도 레거시 시스템을 분석하면서 어떻게 구조 개선을 할 것인지에 대한 고민이 있고, 새롭게 코드를 짜던 기존 코드를 마이그레이션을 하던 가장 유리한 방식을 채택할 계획이다.

위 관점에서 Dzone에 도움이 되는 글이 있길래, 번역을 하였다.

모놀리스 아키텍처

모놀리스 애플리케이션은 복잡도가 큰 단일 애플리케이션이다. 또한 유지 관리가 어렵고 잦은 배포를 하기가 쉽지 않다. 한 곳에 장애가 발생하면 전체 시스템이 다운 될 수 있는 확률도 높다.

모놀리스 아키텍처의 특징은 아래와 같다.

• 모든 유형의 브라우저, 모바일 앱등을 제공하는 큰 단일 애플리케이션이다.
• 매우 복잡하고 거대한 구조와 파일을 지니고 있다.
• 모놀리스 애플리케이션은 유지 보수가 어렵다. (코딩 표준, 버그 수정등의 측면)
• 대규모 애플리케이션을 자주 배포할 수 없기 때문에 지속적인 개발이 어려울 수 있다.
• 애플리케이션 확장이 어려울 수 있다.
• Scale-out이 매우 어렵다.
• 개발팀은 모놀리스 애플리케이션을 확장하는 것이 어렵다고 생각한다. 애플리케이션이 일정 크기를 넘어서면 단일팀으로는 유지 관리가 어렵기에 모듈 및 서비스를 현명하게 분할해야 하고 각 모듈간 간섭으로 인해 개발자가 폭넓게 이해를 해야 하기에 시간과 비용이 많이 소요된다. 이런 부분들이 생산성에도 영향을 미친다.
• 기술의 병목 현상이 존재한다. 애플리케이션이 특정 기술에서 개발을 시작하면 구식이 되어도 최초 사용한 기술을 고수해야 한다.
• 애플리케이션을 빌드하거나 배포하는데 많은 시간이 소요된다. 이에 개발자는 많은 시간을 할애해야 한다.
• 애플리케이션을 시작시 많은 시간이 걸리기에 배포에 영향을 미치고, 이는 생산성에 영향을 준다.

위의 이미지는 단일 애플리케이션에 모든 기능이 포함된 일반적인 아키텍처를 의미한다.

마이크로 서비스란?

서비스에 집중하고 각 서비스가 독립적으로 되는 방식이다. 전체 시스템을 조각으로 나누어 서비스를 개발하는 방법이다. 간단히 말해서 유지 관리가 어려운 하나의 거대한 시스템을 독립적이고 유지 관리가 가능한 더 작은 서비스로 나누는 것이다.

마이크로 서비스의 주요 특징은 다음과 같다.

• 각 서비스는 느슨하게 결합되어야 한다.
• 각 서비스는 유지 보수가 용이하고 확장 가능해야 한다.
• 각 서비스는 독립적으로 배포할 수 있어야 한다.
• 각 서비스는 비즈니스 기능에 따라 경계를 명확히 해야 한다.
• 각 서비스는 소규모 팀이 소유해야 한다.

아래 이미지를 보면 자체 데이터베이스가 있는 다양한 유형의 서비스가 있음을 식별 할 수 있다.

위 그림에서 각 서비스는 서로 간섭하지 않고 작동하는 여러 마이크로서비스로 나뉜다. 이것은 각 서비스가 다른 마이크로서비스와의 간섭을 최소화하면서 작동할 수 있는 하나의 작은 모듈이고 각 서비스가 책임을 가지며 개별적으로 배포할 수 있고 소규모 팀이 소유할 수 있는 마이크로 서비스 아키텍처의 모습이다.

레거시 애플리케이션을 마이크로서비스로 마이그레이션

모놀리스 애플리케이션을 마이크로서비스로 마이그레이션 하는 방법에는 두 가지가 존재한다.

• 별도의 마이크로서비스에서 새로운 기능을 구현
• 기존 모놀리스 코드 기반에서 새 마이크로서비스를 추출

단일 모놀리스 애플리케이션이 있는 경우 별도의 데이터베이스와 기능을 포함하는 마이크로서비스에서 새로운 기능을 개발해야 한다. 이 프로세스에서 모놀리스 애플리케이션의 데이터를 원하는 경우 모놀리스 애플리케이션 내부에 상대 API를 빌드하거나 제공할 수 있는 독립형 애플리케이션을 만들어야 한다.

이것을 모놀리스와 마이크로서비스 사이의 중재자가 될 Glue라고 한다. 이 후 개발자는 시간이 있을 때 모놀리스에서 새로운 마이크로서비스로 모듈을 이동할 수 있다. 일정 시간이 지나면 모놀리스 애플리케이션 없이 마이크로서비스만 가질 수 있게된다.

하나의 식품 주문 및 배달 관리 모놀리스 애플리케이션이 있다고 가정하자. 일부 기능을 마이크로서비스로 추출하여 해당 애플리케이션을 마이크로서비스로 만들려고 한다. 아래 그림은 모놀리스 애플리케이션에서 일부 기능을 마이크로서비스로 변환한 것이다.

1.먼저 모놀리스 애플리케이션 내에서 코드를 분할한다. 즉, 코드를 느슨하게 결합된 코드와 동일한 모놀리스 애플리케이션내에 위치한 주문 코드 및 배송 코드를 별도로 분할한다.

2.데이터베이스를 분할하고 추출된 서비스의 데이터베이스를 분리한다. 이때 접착제를 추가해야 한다. 즉, 개발자는 두 베이스베이스간에 동기화할 계획을 가지고 만들어야 한다. Trigger 또는 코드로 관리할 수 있다.

3.분리할 기능에 대한 별도 서비스를 정의한다. 해당 모듈에 대해 별도의 서비스를 만든다. (아래의 예저는 배송관리이다.)

4.Extracted Service를 독립적으로 사용한다. API 게이트웨이를 이용해 독립적으로 만들 수 있다.

5.기존 모놀리스 애플리케이션에서 전달 관리 코드를 제거한다.

끝으로

위 단계를 따르면 일반적인 모놀리스 애플리케이션을 마이크로서비스 기반 아키텍처로 마이그레이션 할 수 있다.

Read More

MSA(Microservices Architecture)의 장점과 단점

 

마이크로 서비스는 대규모 소프트웨어 프로젝트를 마이크로 단위의 모듈로 분리하여 loosely-coupled한 구조로 만들고 API를 통해 서로 통신합니다.

지난 몇 년동안 마이크로 서비스에 대해서 많은 이야기가 있었습니다. 모듈형 아키텍처 스타일은 클라우드 기반 환경에 적합하며 인기가 높아지고 있습니다.

마이크로 서비스는 대형 소프트웨어 프로젝트의 기능들을 작고 독립적이며 느슨하게 결합 된 모듈로 분해하여 서비스를 제공하는 아키텍처 입니다.

각 개별 모듈은 개별적인 작업을 담당하며 간단하고 보편적으로 엑세스 할 수 있는 API를 통해 다른 모듈과 통신 합니다.

마이크로 서비스는 웹 기반의 복잡한 응용 프로그램을 설계하기 위한 또 다른 아키텍처입니다. 일반적으로 SOA(Service Oriented Architecture)와 비슷하게 바라보는 시각도 존재합니다만 엄연히 다른 아키텍처입니다.

그렇다면 SOA와 같은 기존 아키텍처의 문제점은 무엇일까요?

Java를 사용하여 기존 웹 프로그램을 만든다고 가정합시다. 가장 먼저 해야 할 일은 presentation layer (사용자 인터페이스)를 디자인을 하고 Business logic을 처리하는 Application layer와 구성 요소 간의 느슨한 결합을 가능하게 하는 Integration layer 그리고 마지막으로 데이터에 접근이가능하도록 Persistence layer를 디자인 하고 구현해야 합니다.

어플리케이션을 구동하기 위해 war or ear 패키지를 생성하고 이를 Tomcat or JBoss와 같은 Application server에 배포합니다. 모든 모듈이 war or ear로 패키징 되었기에 우리는 이것을 Monolithic이라고 부릅니다. 다시 말해서 별도의 구현 가능한 구성 요소가 존재해도 모두 하나의 지붕 아래에 패키징되어 있습니다. 아래의 그림을 참조하세요.

Monolithic 아키텍처: challenges

• 어플리케이션이 커질 수록 코드도 방대해지고 로드시에 IDE에 과부하가 걸릴 수 있습니다. 이런 부분은 개발자의 생산성을 저하시키는 요인이 됩니다.
• 하나의 war or ear에 모든 것을 포함하였기에 어플리케이션의 기술 스택을 변경하는 것을 주저하게 됩니다. 예를 들어서 일부 컴포넌트는 JVM내에서 동작하는 Groovy나 Scala와 같은 다른 언어를 사용하여 처리하려고 할 경우 이런 종류의 아키텍처를 사용하면 어떤 side-effect가 발생 할지 예측이 어려우므로 리펙토링을 해야 하지만 코드가 너무 방대해서 리펙토링을 하기가 어렵습니다.
• 어플리케이션내의 특정 기능이 실패하면 전체 어플리케이션에 영향을 미칩니다. 그리고 퍼포먼스가 나쁜 특정 함수/메소드의 영향이 전체 어플리케이션에 고통을 주게 됩니다.
• 이런 아키텍처에서의 scaling은 서버마다 동일한 war or ear을 배포하여 수행해야 합니다. 각각 서버는 동일한 리소스를 사용하게 되므로 이 것은 효율적인 방법이 아닙니다.
• 어플리케이션이 커질수록 개발자는 작은 단위로 작업을 축소할 수 있어야 합니다. Monolithic은 모든 것이 하나로 묶여 있기 때문에 개발자가 독립적으로 모듈을 개발하고 배포 할 수 없습니다. 그리고 개발은 협업으로 진행되므로 다른 개발자에 의존성때문에 개발 시간이 길어지게 됩니다.

위의 언급한 내용을 염두하고 마이크로 서비스에 대해서 알아보겠습니다.

마이크로 서비스

아키텍처의 중요한 포인트는 바로 확장성입니다. 많은 사람들이 확장성을 얘기 할 때는 The Art of Scalability라는 책을 인용합니다. 이 책에서는 Scaling을 세 가지로 정의합니다.

X 축은 horizontal(수평) application scaling (Monolithic 아키텍처에서도 가능)을 나타내며, Z축은 비슷한 것들을 분할하여 어플리케이션을 스케일링함을 의미합니다. (Z축은 데이터를 분할하여 사용자의 요청에 따라 해당 샤드에 redirect하는 샤딩 개념으로 이해하면 됩니다.)

Y축이 가장 중요하고 우리가 눈여겨 봐야할 대상입니다. 이 축은 기능적인 분해(해체)를 의미합니다. Monolithic에 포함되어 있는 다양한 기능을 독립적인 서비스로 바라보는 전략을 취합니다. 따라서 모든 기능을 전체 어플리케이션에 배포하지 않고 각각 서비스를 독립적으로 배포 할 수 있습니다.

이렇게 하면 개발자의 생산성이 향상되고 기능 변경시 side-effect 걱정 없이 변경하고 배포 할 수 있는 유연성을 제공합니다.

예전 Monolithic 방식과 비교해보세요.

마이크로 서비스의 장점

벤더사 중심의 SOA에 비해서 마이크로서비스는 Amazon, Netflix, eBay와 같은 글로벌 서비스 플레이어가 사용할 만큼 강력합니다.

Improves fault isolation : 단일 모듈의 장애에 대해 전체 어플리케이션은 크게 영향을 받지 않습니다.

Eliminates long-term commitment to a single technology stack : 각 개별 서비스에서 새로운 기술 스택을 시험하고자 한다면 바로 시작할 수 있습니다. 의존 관계가 기존 Monolithic 아키텍처보다 적고 유연합니다.

기능 단위로 서비스가 되기에 새로 조인한 개발자가 기능을 더 쉽게 이해 할 수 있습니다.

마이크로 서비스의 배포 및 가상화

마이크로 서비스기반의 어플리케이션을 배포하는 가장 좋은 방법은 컨테이너 가상화를 이용하는 것입니다. (Docker)

AWS와 같은 IaaS업체의 VM을 이용하여 마이크로 서비스를 배포할 수 있지만 작은 단위의 마이크로 서비스는 VM의 리소스를 전부 활용 하지 못해 비용 효율성을 저하 시킬 수 있습니다. 따라서 컨테이너 기반으로 배포를 하는 것이 유리합니다.

OSGI(Open Service Gateway Initiative) 번들을 사용하여 코드를 배포 할 수도 있지만, 이 경우에는 management and isolation tradeoff와 관련된 단점이 존재합니다.

마이크로 서비스의 약점

아래는 마이크로 서비스 설계와 관련된 잠재적인 약점에 대한 부분입니다.

• 분산 시스템 개발은 일반 개발보다 복잡합니다. 모든 것이 독립적인 서비스이기 때문에 각 모듈간의 인터페이스를 신중하게 처리 해야 합니다. 서비스중 하나가 응답하지 않게 될 경우에 대한 방어코드도 작성해야 합니다. 호출 대기 시간이 발생하게 되면 복잡한 상황이 발생할 수 있습니다.
• Multiple Databases 및 트랜젝션 관리가 어려울 수 있습니다.
• 마이크로 서비스 기반의 어플리케이션을 테스트하는 것은 번거로울 수 있습니다. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 합니다.
• 마이크로 서비스의 배포는 복잡 할 수 있습니다. 각 서비스 간의 조정이 필요 할 수 있습니다.

하지만, 이런 부분들은 자동화 도구를 사용하면 해결 할 수 있습니다.

끝으로, 마이크로 서비스는 벤더사 중심이 아닌 서비스사 중심의 아키텍처이고 이미 글로벌 플레이어에 의해 검증이 되어 있습니다.

하지만, 좋은 아키텍처도 상황과 사람에 의해 달라지게 됩니다.

마이크로 서비스 아키텍처를 경험했거나 경험할 계획이 있으신가요?

참조

• http://cloudacademy.com/blog/microservices-architecture-challenge-advantage-drawback/

Read More