테크 블로그 TechBlog

GS리테일에 합류한지 한달정도 된것 같습니다. 저는 플랫폼 구조개선TFT에서 플랫폼 구조개선 업무를 담당하고 있는 주길재입니다.

 

어떤 방식으로 플랫폼을 구조개선할지 정하기 전에 마이크로서비스, 미니서비스 및 매크로(Monolithic)서비스를 구별해 보겠습니다.

 

마이크로 서비스

아래의 경우에만 마이크로 서비스라고 정의할 수 있습니다.

• 주변 서비스에 대한 인식 없이 독립적으로 개발, 배포 및 관리됩니다.
• Publish-Subscribe pattern 혹은 HTTP기반 RESTful 방식으로 서로 통신합니다.
• 단일 책임이 있습니다.
• 느슨하게 결합되어 있습니다.

Microservices Architecture

위의 원칙을 따르지 않는다면 마이크로서비스가 아닙니다. 아래의 경우에도 마이크로서비스가 아닙니다.

• 데이터베이스(물리적 또는 논리적)를 공유합니다.
• 인프라를 공유합니다.

 

미니 서비스

미니 서비스는 비즈니스 요구사항을 해결하기 위해 약간 큼직하게 마이크로서비스화 한 것과 같습니다. 서비스로서의 단일 기능을 제공합니다. 아래의 경우 미니서비스라고 정의할 수 있습니다.

• 여러 애플리케이션이 동일한 데이터베이스를 공유하는 경우
• 각 서비스는 RESTful API를 통해 서로 통신하며 비동기 통신을 위한 Event기반 아키텍처를 수용하지 않습니다.
• 배포를 위한 인프라를 공유합니다.

 

Miniservices Architecture

 

서비스 도메인은 단일 데이터베이스와 애플리케이션 서버를 공유하고 각 서비스를 REST API로 호출하게 됩니다.

 

매크로(Monolithic) 서비스

모든 비즈니스 서비스가 애플리케이션 서버에 단일 패키지로 배포되고 동일한 데이터베이스(물리적, 논리적)룰 공유하는 방식입니다. 이 방식은 덜 복잡하고 서비스 간 긴밀한 결합을 허용합니다.

Monolithic Architecture

 

플랫폼 구조 개선시에는 어떤 아키텍처를 사용할 것인가?

현재 모습

Monolithic Architecture

 

현재 모습은 전통적인 Monolithic 아키텍처이고, 통합 데이터베이스를 사용하고 있습니다. 일부 비즈니스 로직은 프로시저로 구현되어 있습니다. 그리고 DB동기화를 위한 EAI등이 사용되고 있습니다.

 

위 구조가 나쁜것은 아닙니다. 최초 사업을 시작하는 시점엔 가장 최적화된 아키텍처였을 것입니다.

시간이 흐르고, 비즈니스 요구사항이 변화됨에 따라 시장의 Needs에 유연하게 대처할 수 있는 아키텍처가 필요합니다.

 

고려 사항

기존 시스템을 분석중에 있고, 몇 가지 비즈니스적 고려 사항을 도출했습니다.

1. 하나의 업데이트가 다른 요소에 영향을 미칠 때 시장이 필요로 하는 속도로 움직일 수 있을까?
2. “적은 위험과 더 많은 보상" 차원에서 작게 시작하여 효과적인 것을 구축하는 것을 생각해보자.
3. 지금의 모습으로 오프라인 마켓이 계속 유지될 것인가?
4. 새로운 기능을 반영할 때, 기존 코드에 삽입해야 하는가?
5. 현재 플랫폼은 비즈니스와 함께 성장했을 가능성이 높으며, 프로세스와 비즈니스 로직이 tightly하게 매핑되어 있다.
6. 스토리 매핑이 필요하다.

 

플랫폼을 개선한다는 것은 ,

디지털 변혁의 시대에 복잡하고 다면적인 이해관계자의 역할을 반영하여 비즈니스에 유연성과 빠른 속도를 제공하는 것

 

이라고 생각합니다. 비즈니스에 유연성과 빠른 속도를 어떻게 제공 할 수 있을지에 대한 고민이 필요합니다. 그리고 기본 베이스를 튼튼하게 다져야 합니다.

 

개선 사항

현재 시점에서 마이크로서비스 아키텍처를 언급하는 것은 의미가 없어보입니다. 우선 기반을 다지는 작업을 선행 해야 합니다.

1. In-house 개발의 비중을 늘려갈 것이기에, 업무 프로세스 정립 및 수행 체계를 효율화할 필요성이 있습니다. 비즈니스 파트너분들과 프로젝트를 진행했을 경우에는 Waterfall이 훌륭한 방법이긴 하지만, 일부 내재화를 진행하기에 Agile과 Waterfall을 적절히 섞어서 수행할 필요성이 있습니다.
2. 개발 표준을 정의할 생각입니다. 서비스 타입별로 개발 환경을 수립하고 REST API Specification, Naming convention, Logging, ORM 가이드등을 먼저 정의할 생각입니다.
3. 프로시저를 애플리케이션 영역으로 옮기는 작업도 서서히 진행할 계획입니다. ANSI SQL을 사용하고 데이터베이스의 Dependency를 최소화하는 것이 목적입니다. (데이터베이스는 가장 비싼 리소스니까요.)
4. API-led connectivity를 적용하여 비즈니스 확장에 대응할 생각입니다.
5. Actor별로 서비스를 분리할 계획입니다. 지금은 여러 Actor가 같은 시스템을 사용하기에 Side-effect 및 영향도가 증가하는 구조입니다.
6. Front-end, Back-end를 분리하여 API가 Pure한 데이터/기능으로써 역할을 하도록 할 생각입니다.
7. 일반적으로 UX는 시대 상황에 따라 변화되기에, UX 변화에 따른 Back-end의 영향을 최소화하고자 BFF(Backend For Frontend)를 도입할 생각입니다.

현재, 생각나는 부분은 이정도입니다. 계속 분석하다보면 중장기적 관점에서 최선의 방안이 수립될 것으로 판단됩니다.

 

마치며

현 시점 혹은 미래에 발생할 수 있는 비즈니스 요구사항에 따라 다르겠지만, 일반적으로 여러 코드 Repository에 관리되는 서비스의 경우에는 이미 애플리케이션 레벨에서 분리 되었기에 마이크로서비스로 만드는 것이 유리하다고 생각합니다. 반면, 단일 코드 Repository에 여러 기능이 있거나 하나의 서비스에 여러 기능이 존재하는 경우 미니 서비스가 해결책일 것으로 판단됩니다.

 

미니 서비스는 비용 효율적이지만 비즈니스 목표를 달성하기 위해 실시간으로 여러 기능을 배포해야 하는 상황에서는 효율성이 감소됩니다.

 

하지만,

기존 시스템의 일부를 포용해야 하는 현 상황에서는 미니서비스로 구조 개선을 하는 것이 효과적으로 보입니다.

 

플랫폼 구조개선 TFT는 현재 Team building중에 있습니다. 함께 성장해가면서 최적화된 플랫폼을 만드실 분은 지원하세요 :)

저도 이렇게 함께 일하고 싶습니다. 그날이 오겠죠?