마이크로 소프트 아키텍처(MSA) 2편 구성을 위한 선행조건

안녕하세요
앵과장입니다.

마이크로 서비스 아키텍처 1편에서는 모놀리식 구조와 MSA를 살짝비교 해봤는데 MSA장점보다는 이거 왜써야 하는지 그리고 개발자 연봉이 왜올라가는지 내용이 살짝 산으로 갔는데 마이크로 서비스 아키텍처에 장점과 선행조건을 알아보도록 하겠습니다.

마이크로 서비스에 대한 간단한 설명이 필요하다면 아래 링크를 참고하세요

마이크로서비스  MSA 코드 파편화 복잡도 최소화

마이크로 서비스 아키텍처 장단점
MSA

MSA를 사용하는 궁극적인 목적은 서비스에 트래픽과 리소스 증가 성장이 필요하기 때문입니다.

마이크로 서비스 장점

• 서비스 유연한 확장
• 분리된 도메인과 R&R 리소스
• 서비스 전면 장애에 대한 안정화
• 각 도메인별 분리된 업데이트
• Api 와 규격화된 Json context로 인한 개발언어와 프레임워크 자유도 확장
• 트래픽이 증가되었을때 유연한 server Auto scaling
• 다양한 Cloud 오픈라이브러리 사용으로 인한 서비스 안정화
• 개발자 리소스 다변화 (최근에는 어느정도 공통적인 구성으로 만드는경우가 많아지는 추세)

마이크로 서비스 단점

• 대규모 아키텍처구성으로 인한 리소스 비용증가
• 분리된 어플리케이션 트랜잭션 처리
• Cloud환경으로 필요한 러닝커브 증가
• devops에 대한 지속적인 변화필요
• Data Warehouse 구성을 위한 비용 증가
• 로그 트래킹 및 리소스 모니터링 비용 증가

이런 여러 장점 과 단점이 공존하지만 대규모 서비스 그리고 성장이 지속가능한 회사라면 필수로 고려 하고 구성해야 하는 중요한 빅피처 중에 하나 입니다.

  마이크로 서비스 아키텍처
선행조건
  

많은 회사들이 MSA를 가기위해서 많은 고민들을 현실적으로 하게 됩니다.

  Cloud 에 대한 고민  

Cloud 환경으로 구성되지않은 온프레미스 서비스도 존재하기 때문에 이부분부터 고민할수있습니다.

기존에 IDC환경에서 클라우드로 넘어가기 위해서는 정말 많은 부분들이 고려되어야 합니다

• 네트워크 흐름
• Ip생성
• public, private VPC
• 보안 WAP
• white list 정책 , ingress 정책
• 기존 IDC와 통신하기 위한 고민

서비스 에서 사용했던 OS도 언어별로 다를 경우 상당히 피곤해지는데 Window OS를 사용한 닷넷 계열을 Java진형으로 가기위해서 Linux로 구성해야 합니다.

이럴경우 Azure, Aws 둘다 존재하지만 마이크로 서비스 에 궁합으로 Azure를 사용하지만 언어 를 변경한다면 많은 서비스회사에서 Aws를 사용하게 됩니다.

물론 네이버 Cloud, 구글 Cloud도 사용하지만 많은 회사들이 서비스 사용성과 커뮤니티 활성으로 Aws를 많이 선택하는 추세 입니다.

MSA 아키텍처에 대한 고민

MSA를 구현하기 위해서 다양한 아키텍처와 디자인 패턴 라이브러리를 생각하게됩니다.

DDD 도메인 주도 개발을 가장먼저 고민하게됩니다.
OOP와 SOLID를 시작으로 객체 지향관점에서 객체가 모여있는 도메인으로 고민하게되면서 다양한 개념적인 언어 들이 존재하는게 그중 가장 고민하게되는 포인트만 저의 주관적인 개념으로 정리 해보도록 하겠습니다.

주로 사용하는 아키첵처

DDD 아키첵처
Clean 아키텍처
TDD 아키텍처
헥사고널 아키텍처
이벤트스토밍

• 모놀리식한 도메인(회원, 상품, 결제, 광고, 커뮤니티, 공통(배치, code, push)분리
• Api 컨트롤타워 주체가 되는 Gateway 구성에 대한고민
• BFF(Backand for Frontend)를 리소스와 IO 트랜잭션을 늘리면서 클라이언트에게 서포트 할지 고민
• Api에 대한 통신 구간을 Http, Queue 방식으로 어떻게 진행할지에 대한 고민
• CI/CD devops구성 Ec2, Ecs, K8s 배포
• 프로젝트명, 패키지, 클래스, 메소드 규칙과 개발 진행시 코드 복잡도와 파편화에 대한 고민

RDBMS에 대한 고민

Legacy 데이터가 존재 하지 않다면 이부분 여러고민중 큰 몇가지 고민을 하지 않아도 되지만 존재한다면 비슷한 고민을 해야합니다.

• 기존 DB를 다른 RDBMS로 바꿔야하나!!
• 특정 database만 옮겼다면 데이터 Sync하는 방법은?
• 특정데이터를 Nosql로 옮겨서 호출하는 방식?
• 어떤데이터를 In memory Cache 로 구성할지?
• 집계, 통계 등 Group으로 묶거나 join을 해야 하는상황은?
• 특정 테이블에 집중되는 Batch에서 사용되는 Query?

데이터를 Rdb에서 다른 Rdb로 옮긴다면

Mssql 에서는 CDC라는 기능이 존재하며 pub, sub 구조로 중간에 kafka를 이용해서 정제된 테이블 구조로 변경이 가능한 기능이 존재하며 무료, 유료 가 존재합니다.

또는 이벤트로 처리하는 방식입니다. 많은 서비스 기업들은 Msa같은 분산화된 HA환경에서는 Queue라는 자료구조를 사용합니다.

• Aws sqs sns
• RabbitMq
• Kafka
• Redis (in memory지만 제공되는 컬렉션중 스트림인가... ㅋㅋ 간단한 구성을 하기도 합니다)

각 Queue 는 특화된 용도가 있으니 서비스에 가장 적합한 기능으로 구현하시면 됩니다.
오픈소스는 도구로 사용해야지 오픈소스가 주가 되어서는 안되는점을 꼭 기억하세요!!

Nosql에 대한 고민

Log또는 Api에 흔적을 찾기 위해서 지속적으로 많은 데이터를 Nosql에 사용합니다.

ELK

AWS EC2 ELK Elasticsearch7.x + Logstash7.x + Kibana7.x + beats 최신버전 설치

실제 서비스 회사들은 ELK( Elasticsearch Logstash Kibana)스택을 이용해서 로그를 적제하거나 특정 Rdb를 CQRS패턴으로 데이터를 만들어서 Read와 Write를 분리 하기도 합니다. 물론 ELK는 검색에 특화된 루씬기반에 역색인 방식도 가능합니다. 러닝커브는 높은 편입니다.

Couchbase

Couchbase 를 이용해서 memory기반 Bucket이라는 표현을 하며 Rdb에서 사용하듯 Query호출처럼 사용이 가능합니다 항상 index를 잘구성해서 사용하시면되며 러닝커브가 가장 낮은 Nosql이라고 생각됩니다.

MongoDB

Baas라는 단어를 쓰던데 클라이언트는 서버 구성없이 사용할수 있는 형태라는 컨셉을 가지고 있는데 그만큼 다양한 기능을 제공합니다.
최근 4.x.x버전 이상부터는 검색, 대용량 데이터 적재, rdb처럼 사용가능한 테이블구조, 자유로운 DML,DDL, 집계 데이터 처리등을 할수 있으며 Cloud 환경에 엔터프라이즈급 관리자도 존재하지만 비용이 비싸다고 합니다.

하둡, SPARK

Kafka를 이용해 데이터를 하둡에 적제하고 스파크로 몰한다는데 사용해본적이 없어서..
데싸 라고 불리는 데이터 싸이언스, 데이터 분석가, 데이터 엔지니어가 사용한다고 합니다.
연봉이 높다고 하며 데싸는 학벌이 좋아야 한다고 합니다.

개발 언어에 대한 고민

java :
Spring Cloud 로 구성을 많이 하는편이며
한국에서는 다양한 커뮤니티가 형성되고 유튜브나 블로그 등에서 많은 입개발자들의 정보를 많이 만나보실수 있습니다.

Python : 스타트업에서 많이 사용되고 메이저급 기업들도 사용합니다.
개발 속도로는 따라올자가 없으며 러닝커브가 낮다고 하는게 정말 그럴까요?
장고, fast api, flask 등 라이트한 프레임워크부터 다양하게 많은 라이브러리들이 존재합니다.
저도 개발할때 이용하곤 합니다.

.Net : 마이크로 소프트라는 큰회사에서 사용하며 다양하고 비싼 라이브러리 하드웨어가 특징입니다.
그외는 전몰라요 ㅎㅎ

node :
스타트업에서 많이 선택하며 개발자를 클라이언트부터 서버로 굴리기 위해서 많이 사용한다고 합니다.
Javascript 이기 때문에 몸값도 올리기 좋은거같아요

Go
구글에서 만들어진 언어이며 분산처리나 빠르게 병렬처리에 특화되어 있다고 듣기만 했네요
(뱅크셀러드 CTO가 구글출신인데 이언어에 광적이라는 글을 블라인드에서본 기억이 있습니다)

기존 Legacy에 대한 고민

레거시가 존재하는 순간부터는 현실적으로 접근하셔야 합니다.
개발하면서 가장어려운건 다른사람의 소스를 인지하는겁니다.
근데 욕하며 봤던 소스가 내가짠 5개월전 소스라면 .....

개발자들 사이에서 개발할때 지금 내가 여차하면 이력서를 새로 써야 한다라는 단어를 표현하는 개발자가 많은곳은
아!!!!!
어!!!!!!
이런 표현이랍니다!!

그냥 힘들어영....레거시는 그냥 wiki에 문서 전부 읽고 기존에 아시던분들에게 잘해드리면서 파악하는게 가장 빠른길로 가는 진리입니다.

그럴수 있어!!! 이게 다 개바쁘고 거지같은 일정으로 이렇게 된거야 이사람이 잘못된게 아니다 라는 모든것을 그럴수 있다는 마음으로 접근하셔야 합니다!!!!!

devops에 대한고민

devops는 저도 깊이 있게 공부를 해본적이 없어서 뭐라고 표현하긴 그렇지만

gradle + deploy + network + 보안 이렇게 4가지 구성이 제일 어려운것 같습니다.

MSA만 보는것고 벅차다보니 이쪽은 점진적으로 공부 해보도록 하겠습니다.

Ec2, Docker, K8s 등으로 구성하는것같아요

인력 구성에 대한 고민

프로젝트를 진행하기 위해서는 여러 개발 방법이 필요합니다.

기술부채에 대한 확장과 성장을 위한 아키텍처, 라이브러리, 언어등도 중요 하지만 이모든 부분은 협업이 가장 중요한 포인트라고 할수 있습니다.

프로젝트 구성원들과 기술을 공유하고 공감대를 형성한뒤에 여러 좋은 방향을 함께 지속적으로 갈수 있는 고민이 필요 합니다.

그리고 무엇보다 중요한것은 기본적인 톤앤매너가 필요하며 사람과 사람에 관계에서는 겸손함이 필요하다는 생각입니다.

제가 좋아하는 말이 있는데

규칙은 바보에게는 복종이지만 현자에게는 지침이다
- 더글라스 베이더

항상 마음속에 생각해보면서 담아가는 중입니다.