E4NET

가자! 마이크로서비스 아키텍처로 본문

E4.Tech/IT Technology

가자! 마이크로서비스 아키텍처로

E4. 2020. 10. 22. 09:40

 

 

현재 진행 중인 프로젝트 작업을 소개하고자 합니다 . 개발자가 아니시면 공감이 덜 가는 주제입니다 .

지난해 MVP( Minimum Viable Product, 최소 기능 제품 ) 로 개발된 블록체인 연계 기부서비스 프로젝트를 MSA(Microservice Architecture) 로 전환하는 작업에 대한 개발 아키텍처 관련 내용입니다 .

2019 년도 올해 KISA 과제에 선정되었다는 것과 서비스에 대한 내용은 그동안 사장님이 말씀이나 기사를 통해   잘 아실 겁니다 .  
차후 이윤수 팀장님이 좀더 자세한 내용을   말씀드리게 되는 기회가 있지 않을까 합니다 .

사실 마이크로서비스 아키텍처 ( 이하 MSA) 작업을 하는 과정에는 많은 기술적인 배경 내용의 숙지가 필요합니다 .
간단히 기술하자면 ...

MSA 는 단일 응용 웹서비스 프로그램을 나누어 작은 서비스의 조합으로 구축하는 방법입니다 .

MSA 로 가는 목적은 데브옵스 (DevOps) 모델로 구축하기 위함 입니다 .

많은 수의 마이크로서비스를 무중단 배포를 편리하게 하기 위해 지속적인 통합 (Continuous Integration. CI) 과 지속적인 배포 (Continuous Deployment. CD) 툴이 필요합니다 .

MSA 인프라 구축에 중요한 개념이 가상화 (Virtualization) 와 API(Application Programming Interface) 입니다 .

가상화는 컨테이너 기반의 가상화를 사용하게 되는데 대표적인 것이 도커 (Docker) 입니다 .

서비스 간의 API 방식은 일반적으로 REST 방식을 사용하기 때문에 RESTful 한 설계가 필요합니다 .

프로젝트는 자바 프레임워크 (Java Framework) 이면서 MSA 에 최적화된 스프링부트 (Spring Boot) 기반으로 구축하고 , MSA 로 가면서 생기는 리스크를 최소화 하고 효율적 운영을 위해 스프링클라우드 (Spring Cloud) 라이브러리를 사용하게 됩니다 .

또한 실재 운영 서비스가 될 AWS(Amazon Web Services) 와 도커 기반 배포와 관리를 위한 쿠버네티스 (Kubernetes) 도 있습니다 .

스프링 클라우드에는 다음과 같은 기능이 필요합니다 .

Spring Cloud Config 이용한 환경설정 정보 관리

Spring Cloud Eureka 이용한 서비스 탐색 (Service Discovery)

Spring Cloud Ribbon 이용한 클라이언트용 로드 밸런싱

Spring Cloud Zuul 이용한 API Gateway 구축

Spring Cloud Stream 이용한 이벤트 기반의 구조 구축

Spring Cloud Security 이용한 인증 , 인가 보안 . OAuth2 및 JWT 사용

Spring Cloud Sleuth 이용한 분산 로그 추적 및 모니터링

그 밖에 Im-Merory, Hystrix 처리 등이 있습니다 .
( 스프링 클라우드 기술에 대해 관심있는 개발자의 이해를 돕기 위한 참조 링크입니다 .    https://coe.gitbook.io/guide/ )

 

본론으로 들어가서 오늘 주제는 기존 프로젝트 개발에 적용된 구조인 모노리틱 아키텍처 (Monolithic Architecture) 방식을 마이크로서비스 아키텍처 ( Microservice Architecture, MSA) 로 전환하는 작업에 대한 아키텍처 적인 전략적인 설명입니다 .


기존 AS-IS 스프링 @MVC(Spring Annotation MVC) 형태의 프로젝트를 TO-BE Frontend Service 와   Backend Service 프로젝트로 나누는 방법은 다음 < 그림 1> 과 같이 수행되게 잡았습니다 .

TO-BE   Frontend Service 는 일명 웹 서비스입니다 . 기존 View 와 @Controller 를 가집니다 . Backend Service 는 일명 REST 서비스 입니다 . 기존 @Service 와 @Mapper(= @Repository) 그리고 MyBatis 쿼리 파일을 가집니다 .
둘로 나누어진 서비스 프로젝트의 연계는 Backend Service 에는 REST 서버 역할을 하는 @RestController 가 추가되고 Frontend Service 에는 REST 클라이언트가 되는 RestTemplate 을 사용한 @Service 를 추가하여 서로 연동하게 됩니다 . 사실 작업하다 보면 단순히 기계적으로 나누어지는 것은 아닙니다 .
추가 되는 REST 연계부분 이외에 기존 소스 부분도 대부분 이에 맞추어 손질을 거치게 됩니다 .

 

< 그림 1>

 

기존 AS-IS 프로젝트는 사용자웹 (CaasWeb) 과 관리자용웹 (CaasAdmin) 2 개의 완전 분리된 구조의 모노리틱 아키텍처 프로젝트로 작업 되어 있었습니다 .
이를  다음과 같은 MSA 구조의 프로젝트로 재 구성합니다 .
Frontend 웹서비스로는 모바일 사용자용 웹서비스 (caas-web-mobile) 와 관리자용 웹서비스 (caas-mng-org) 로 , Backend REST 서비스로는 기부처리 관련 서비스 (caas-svc-donate) 와 결제정산 관련 서비스 (caas-svc-payment) 그리고 공통과 인프라 관련 서비스 (caas-svc-infra) 로 나누어 집니다 .

AS-IS CaasWeb 의 front 단이 caas-web-mobile 에 CaasAdmin 의 front 단이 caas-mng-org 에 위치합니다 .
AS-IS CaasWeb 와 CaasAdmin 의 양쪽 bakc 단은 기능별로 나누어 지고 다시 모여지게 위치합니다 .
( 아래 < 그림 2>   참조 )
사실 언급된 5 개 TO-BE 서비스 프로젝트 이외에 몇개의 프로젝트가 더 작업 되고 있습니다 .

 

 

 

< 그림 2>

 

MSA 로 프로젝트가 나누어지지만 다른 한편으로는 동일한 기능의 모듈이나 리소스의 공유는 필요합니다 .
이를 위해 스프링부트 (Spring Boot) + Maven 기반의 “ 멀티모듈 프로젝트 (Multi Module Project)" 로 구성 하였습니다 .
멀티모듈 프로젝트는 하나의 부모모듈 프로젝트 (Parent Module Project) 와 다수의 자식모듈 프로젝트 (Child Module Project) 들로 구성됩니다 .
모듈 프로젝트 간에 의존 (Dependency) 관계 설정으로 모듈이나 리소스를 마치 상속받아 사용하는 효과가 됩니다 .

이를 통해 공통으로 사용하는 기능이나 리소스를 하나로 관리할 수 있게 되어 전체 프로젝트 소스 관리 통제가 가능하게 됩니다 .

공통 모듈과 리소스 공유를 위해 앞서 언급한 서비스 프로젝트 외에 다음과 같은 모듈 프로젝트를 가지고 갑니다 .

공통 모듈 프로젝트는 2 단계로로 나누어 관리 합니다 .
본 과제 체리에 공통 관련된 부분과 일반 프로젝트에 공통인 부분을 나누어 관리하도록 합니다 .

일반 공통은 차후 다른 응용 서비스 프로젝트 구축 시 재사용성을 높입니다 .

체리 공통은 체리 관련 서비스 개발에 재사용성을 높입니다 .

참조 < 그림 3> 에 현재 진행 중이거나 진행 예정인 모듈 프로젝트를 나타냅니다 .
화살표 ( 빨강 , 파랑 ) 는 모듈 프로젝트 간의 Dependency 관계를 나타냅니다 .   

 

 

< 그림 3>

 

(1) 일반 공통

caas-bfc-cnm - 일반 서비스 공통 모듈 프로젝트 .

모든 서비스 프로젝트에 공통으로 포함됩니다 .  

caas-bfc-web - 일반 웹 서비스 공통 .

View 단 일반 공통 모듈이나 리소스가 포함됩니다 .

(2) 채리 공통

caas-cmm-svc - 채리 서비스 공통 모듈 프로젝트

모든 채리 서비스 프로젝트에 공통으로 포함됩니다 .

caas-cmm-mob - 채리 사용자 모바일용 웹서비스 공통 모듈 프로젝트

caas-cmm-web – 채리 사용자 브라우저용 웹서비스 공통 모듈 프로젝트 ( 예정 )

caas-cmm-mng – 채리 관리자 브라우저용 웹서비스 공통 모듈 프로젝트

공통 모듈 프로젝트는 독자적으로 서버로 빌드되어 사용되지 않습니다 . 라이브러리용으로만 사용됩니다 .

웹 화면용 리소스 모듈 프로젝트인 caas-cmm-mob, caas-cmm-web, caas-cmm-mng 은 각각 화면 UI/UX 디자인 퍼블리싱 리소스가 위치합니다 .
차후 채리 화면 UI/UX 를 사용하는 웹서비스 개발시 기존 리소스를 재사용하게 되어 생상성 있는 개발이 가능한 구조로 구축하였습니다 .

앞서 언급한 5 게 프로젝트 외에 다음 프로젝트 진행 되거나 예정 입니다 .

caas-svc-blockchain - 블록체인 연계 backend 서비스 ( 진행 중 )

루비버스 (Luniverse) 블록체인 플랫폼과의 연계용 서비스입니다 .

추가적으로 하이퍼레저 패브릭 ( Hyperledger Fabric) 연계 예정입니다 . ( 차후 )

caas-web-browser - 사용자 브라우저웹 frontend 서비스   프로젝트 ( 예정 )

caas-mng-platform - 플랫폼 운영자 브라우저웹 frontend 서비스 프로젝트 ( 예정 )

caas-svc-micro - 마이크로 기부 관련 backend 서비스 프로젝트 ( 예정 )

caas-svc-commerce - 기부커머스 관련 backend 서비스 프로젝트 ( 예정 )   

사실 모듈 프로젝트로 나누고 Dependency 로 연계하는 과정에 패키지 패스나 폴더 구성에 대한 고민이 동반 됩니다 .
여기 내용에는   기술하지는 않았지만 합리적으로 설계 구축하였습니다 .

 

앞서 언급된 서비스 프로젝트외에 < 그림 4> 에 다양한 서비스나 서버가 추가 구축됩니다 .

·  모바일 App - 안드로이드용과 IOS 용 2 가지 버전이 개발됩니다 . ( 서버 아님 )

·  웹 서비스 - 앞서 언급된 Fontend 웹 서비스

·  외부연계 서비스 - 외부로 API 오픈이 필요한 경우 . ( 차후 검토 중 )

·  Cloud 서버 - 클라우드 관련 서비스 프로젝트나 서버 .

   쿠버네티스 도입에 따라 기능이 중복되는 서버는 제외 예정

·  Cloud Infra 서버 - 운영관리용 인프라 서버 . ( 검토 또는 예정 중 )

   쿠버네티스 도입에 따라 중복 기능 제외 예정 . 나머지도 예정 검토 .

·  서비스 서버 - 앞서 언급된 Backend REST 서비스

·  배치 서비스 - 배치 처리 서비스 ( 검토 또는 예정 중 )

·  파일 시스템 서버 - 기존 IPFS 서버를 같이 사용 예정

·  인증 서비스 서버

< 그림 4> 는 예상 가능한 모든 Application 에 대한 구도를 예상해 잡은 것으로 향후 상황에 따라 일부 누락 또는 대체 , 추가 됩니다 .  

 

 

< 그림 4>

 

DB 테이블은 자신이 관리되는 Backend 서비스 단위로 나누어 관리되는 것이 원칙입니다 .

나누어 관리하는 방법에는 DB 서버를 개별로 사용하는 방법과 DB 서버는 같이 사용하데 DB 계정을 나누어 사용하는 방법이 있습니다 . 이 프로젝트에서는 후자로 진행할 예정입니다 .

< 그림 5> 는 AS-IS DB 와 차후 TO-BE 시 추가 예상인 DB 가 표시하고 있습니다 .
아직 기획이 안된 DB 는 차후 추가 설계되면 추가 예정입니다 .

앞서 언급한 4 개의 서비스 단위로 다음과 같이 나누어 관리 됩니다 .

  (1) 기부처리 관련 서비스 (caas-svc-donate) - 연한 초록 배경 색

  (2) 결제정산 관련 서비스 (caas-svc-payment) - 연한 붉은 배경 색

  (3) 공통과 인프라 관련 서비스 (caas-svc-infra) - 연한 파란 배경 색

  (4) 블록체인 연계 서비스 (caas-svc-blockchain) - 연한 주황 배경 색

 

 

< 그림 5>

 

마이크로서비스 아키텍처로 DevOps 환경을 구축해 가는 것에는 많은 기술적인 지식과 노하우가 필요합니다 .
또한 마이크로서비스 아키텍처로 프로젝트를 진행하는 것에는 많은 개발과 운영 노력이 필요합니다 .
어떤 아키텍처로 가져가는 것이 좋은지 고민도 많이 하고 관련 기술적인 내용에 대해서도 파악하고자 하였습니다 .
지금도 앞으로도 프로젝트가 마무리 될때까지 고민과 노력을 해야 할 겁니다 . 이번 프로젝트는 AS-IS 2 개의 프로젝트가 20 개 전후의 모듈 프로젝트로 나누어 개발 예상됩니다 .
이번 채리 기부 프로젝트 개발 및 구축을 통해 쌓인 기술과 노하우가 향후 진행되는 이포넷 프로젝트에 밑걸음이 되었으면 하는 바램입니다 . 개발관련 궁금한 사항은 언제든 문의가능합니다 .

이 프로젝트 개발을 통해 다음 질문에 대해 자신있게 답할 수 있길 바라며 재미없고 지루한 이야기를 마칩니다 . ^^

    (1) MSA 프로젝트 구축

    (2) MSA 클라우드 구축

    (3) MSA 통합배포 구축

'E4.Tech > IT Technology' 카테고리의 다른 글

TypeScript란?  (0) 2020.10.22
리액트 네이티브 프레임워크  (0) 2020.10.22
가자! 마이크로서비스 아키텍처로  (0) 2020.10.22
5G 시대가 다가 옵니다..  (0) 2020.10.22
현재 AI는?  (0) 2020.10.21
일상속의 블록체인  (0) 2020.10.21
0 Comments