brunch

매거진 스타트업과 개발자를 위한 짧은글들

라이킷 8 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 신현묵 Jan 04. 2017

데이터 중심의 소프트웨어 개발, #5

쉽게 알아보는 서비스 구조#1-Monolitic

본격적으로 데이터 중심의 소프트웨어 개발에 대해서 이야기하기 위해서 마이크로 서비스 아키텍처(MSA)에 대해서 1차적인 정리를 먼저 해야 한다. 현재, 대부분의 웹서비스들은 MSA의 구조를 따르고 있다고 해도 과언이 아니다.

이 방식으로 개발된 각각의 서비스들은 최소한의 독립적인 서비스들로 구성되며, 정말 자동화된 배포 방식을 지향하고 있다. 각각 개발자와 개발팀들이 서로 상호 간에 큰 의사소통 없이도 빠른 시간 안에 서비스의 배포가 이루어진다.

중앙통제체제는 정말 최소한의 규정이나 규범 정도만 가지게 되며, 대부분의 마이크로 서비스들은 빈번하고 빠르게 교체된다. 전체적인 서비스의 관점에서 본다면, 매우 빠른 속도로 서비스가 업데이트되는 것을 고객들은 느끼게 된다.

작인 빌딩 블록이나 엄청나게 높은 비결 합성은 MSA의 큰 장점이다.

마이크로 서비스 이전에 존재하던 SOA는 미들웨어 중심으로 구현되는 형태의 서비스를 의미했다. 하지만, 사실상 SOA는 아주 큰 서비스를 지향하고 있기 때문에 현재 이 구조로 동작되는 서비스들은 거대 클라우드 서비스 이외에는 크게 어울리지 않는다.

대표적인 SOA의 서비스 형태는 SAP나 Salesforce.com 등이라고 설명할 수 있다.

보통 웹서비스 형태로 구성되는 서비스의 형태는 Monolitic형태, SOA형태, MSA형태의 크게 3가지 형태로 구성된다고 이야기할 수 있지만, 대부분의 엔터프라이즈 서비스들은 Monolitic형태들이고, 모바일이나 현재 대부분의 웹서비스들은 MSA형태라고 할 수 있다.

Monolitic형태는 UI와 애플리케이션의 웹 모듈이 하나의 형태를 띠는 경우가 많다. 이 구조를 다중으로 확장한 형태를 사용하기도 한다. 물론, 그렇게 동작도 가능하고. 이런 형태가 적합한 업무도 많다. 이 형태로 클라우드에서 동작하는 구조로 서비스를 하는 형태들도 많다.

대표적으로 일반적인 ERP나 그룹웨어 등의 서비스들을 클라우드에서 기존의 서비스들을 통째로 올리는 경우가 이러한 구조를 가진다.

이 경우 장점도 꽤 많은 편이다. 전체 모듈이 하나의 구성 형태이기 때문에, 확장 시에 CPU나 메모리 등의 구조가 단일화되고, 관리가 간편해진다. 이 서비스들 대부분은 특정 고객군들을 위해서 하나의 구성이 하나의 인스탄스 형태를 가지게 되기 때문에, 리소스의 구성이 매우 단조롭게 구성되며, 관리도 매우 효율적으로 움직인다.

이 아키텍처는 다음의 구조를 가지게 된다.

1. 하나의 패키지에 하나의 인스턴스, 패키지안에 들어있는 모든 컴포넌트

2. 배포가 동작하기 위해서는 테스트 과정을 심각하게 반복하며, 한번 배포하기까지 시간이 많이 걸린다.

3. 새로운 요구사항이 추가되고 변화가 실제 소스에 반영되고 다시 재배포를 하기 위한 과정의 비용과 시간이 막대하게 들어가므로, 요구사항을 빠르게 처리할 수 있는 프레임워크에 대해서 심각하게 고민하게 된다.

4. 변경이 어려우므로, 개발팀들이 새로운 요구사항을 추가하기에 부담을 가지며, 변화를 주저하게 된다.

5. 개발팀과 QA의 알력 다툼이거나 서로의 관계에 대해서 매끄럽지 않은 상황이 빈번하게 된다.

6. 오류가 발생활 때에 전체 시스템에 악영향을 주기 때문에 그 대안책을 많이 준비하게 된다.

7. 가능하면, 작은 요구사항의 변화들을 싫어하는 개발팀의 모습을 띄게 된다.

8. 확장을 결정한다고 하더라도, 전체 시스템에 대한 점검과 이펙트를 계산, 디자인, 설계, 의사소통 등의 시간적인 요소가 막대하게 들어가게 된다.

Monolitic의 형태는 그럼에도 불구하고 큰 가치가 있다.

1. 정해진 리소스, 반복적이고 정해진 상품구조라면 이보다 효율적인 방법은 없다.

2. 요구사항의 변화가 거의 없고, 정해진 사용자들, 비슷한 구조와 비슷한 업무의 형태라면 이 구조가 최고다.