글루와 테크 미니 컨퍼런스 후기

글루와 테크 미니 컨퍼런스 후기

2018년 10월 17일 수요일 기다리고 기다리던 글루와 테크 미니 컨퍼런스에 다녀왔습니다!! 사실 글루와란 회사는 잘 알지 못하였는데 유튜버로도 유명하신 "김포프"님을 보러 가는게 큰 목적이었지요 ㅋㅋㅋㅋㅋㅋ IT 컨퍼런스 자체가 처음 경험해봐서 생소했지만, 약간 부드러운 강연 분위기랄까 그런게 느껴지더라고요. 일단 그때 주워 들은 얘기를 공유해볼까 합니다.

"모노-마이크로 서비스 아키텍처"

강연의 주제는 위 사진에서 보시다시피 모노-마이크로 서비스 아키텍처입니다. 개발자시라면 "아니 모놀리틱이면 모놀리틱이고 마이크로면 마이크로지 모노-마이크로는 뭐야?"라고 하실 수 있겠는데 간단히 말해서 모놀리틱과 마이크로 서비스의 중간 지점 혹은 장점만 모아서 만든 아키텍처라고 볼 수 있습니다. 

모놀리틱 서비스 아키텍처

모놀리틱 서비스 아키텍처는 위의 사진처럼 하나의 시스템 안에 모든 서비스 및 DB가 존재하는 형태를 말합니다. 기존의 서비스들이 이러한 형태를 띄지요. 장점으로는 아키텍처 자체가 단순한 형태라는 것입니다. 이에 따른 장점은 다음과 같지요. 

1. 개발의 단순함
2. 배포의 단순함
3. 확장의 단순함

단적인 예로 자바로 구축된 서비스라면 하나의 IDE에서 개발하고 하나의 WAR파일로 배포가 가능하며 로드 발란서 뒤의 DB만 추가하면 되기 때문에 확장이 단순하다는 것입니다. 하지만 서비스가 점점 커질 수록 많은 문제점들이 발생하는데 문제점들은 다음과 같습니다.

1. IDE 과부화
2. 웹 컨테이너 과부화
3. 지속적인 배포의 어려움

먼저 서비스가 몇천을 넘어 몇만 아니 몇백만 라인 정도의 코드라고 생각해보지요. 아무리 좋은 IDE라도 이러한 코드를 불러오는데는 오랜 시간이 걸리겠지요. 그리고 컨테이너 역시 애플리케이션을 구동하는데 필요한 작업들이 많기 때문에 오랜 시간이 걸립니다. 이러한 것들은 개발의 생상성에 큰 문제기 되지요. 또한 한 컴포넌트만 바뀌었을 뿐임에도 전체 배포 파일을 갱신해야 하기 때문에 지속적인 배포에도 문제가 생긴답니다. 즉, 앞서 말했던 장점들이 시스템이 커질수록 단점으로 바뀌는 상황이 발생하는 것이지요. 이러한 점들을 개선하기 위해 많은 아키텍처들이 발전했는데, 현재 가장 인기 있는 아키텍처가 바로 마이크로 서비스 아키텍처입니다.

마이크로 서비스 아키텍처

바로 오른쪽의 그림이 마이크로 서비스 아키텍처의 구조 이른바 "MSA 구조"입니다. MSA 구조는 데이터부터 비지니스 로직까지 즉 하나의 컴포넌트를 서비스로 분리한 형태를 말합니다. 즉 하나의 거대한 서비스를 작은 단위로 쪼개서 여러 개의 서비스로 나누어서 개발하는 방식입니다. 이러한 서비스들은 Restful API 방식으로 통신하며, 클라이언트와 아키텍처의 리소스들을 연결할 때는 중간에서 API Gateway라는 녀석이 하게 됩니다. MSA 구조의 장점은 다음과 같습니다.

1. 책임의 확실한 분리
2. API 스펙의 이른 확립 촉진
3. 확장성

일단 MSA 구조를 체택하면 쪼개진 서비스 당 하나의 팀이 개발부터 배포까지 담당하는 것이 일반적이라고 합니다. 즉 어떤 리소스가 에러가 나면 그 서비스를 개발한 팀의 문제가 되는 것이죠. 이러한 것이 개발할 때 책임을 보다 명확하게 해줍니다. 두번 째 장점은 명확하게 이해가 되지 않아서 넘어가도록 하겠습니다.ㅠㅠ 세번째는 확장성인데 쉽게 말해 짧은 배포 시간, 쉬운 지속적 통합, 자동화된 테스트 등 배포가 보다 쉽다는 얘기입니다. 그러나 글루와 팀이 분석한 MSA 구조의 단점은 다음과 같습니다.

1. 성능의 저하
2. 예외 안정성 보장의 어려움
3. 의존성 기억 또는 제어가 어려움
4. 다수의 인력 필요

일단 잦은 HTTP 통신 방식, 서버와 서버 사이를 넘나들며 통신해야 하기 때문에 모놀리틱 서비스보다 일반적으로 속도가 떨어질 수 밖에 없습니다. 또한 서버별로 각기 다른 데이터를 보관하기 때문에 통신 중간에 에러가 났을 때 동기화된 트랜잭션과 롤백이 어렵습니다. 의존성 기억과 제어에 있어서는 잘 기억이... 그리고 서비스 별로 팀을 나누기기 때문에 실제로 MSA 구조를 체택하면 보다 많은 인력이 필요하다고 합니다. 글루와 팀은 MSA 구조를 체택할 때 팀의 서비스가 다음 조건을 만족하는지 살펴보라고 말하고 있습니다.

1. 현재 트래픽이 엄청 많은가?
2. DB가 느려지는 것이 확실한가?(대부분 쿼리문이 잘 짜여졌다고 가정하면 서버에서 제일 나중에 죽는 것이 DB라고 합니다.)
3. 트래픽이 기하 급수적으로 증가하는 것을 확신할 수 있는가?
4. 개발자를 더 뽑을 수 있는가?

모노-마이크로 서비스 아키텍처

**이 부분은 쓸까 말까 고민을 많이 했습니다. 왜냐하면 노트에 적긴 적었는데 1주일도 안돼서 많은 내용들이 제 머리속에서 지워졌더군요... 혹여라도 여러분들에게 잘못된 정보를 전달하는 것이 아닐까? 글루와 팀의 노력을 잘못 전달하는 것이 아닐까 이런 생각이 들면서 잘 적혀지지 않더군요. 하지만 강연 주제인 만큼 꼭 필요하단 생각이 들어서 적게 되었습니다. 이 부분은 글루와 팀이 MMSA구조를 취했는데 필자는 저렇게 이해했구나 정도로 넘어가셨으면 좋겠습니다.**

사실 글루와 서비스 역시 옛날에는 MSA구조로 개발되었는데, 포프님과 크리스님이 합류한 뒤에 모노-마이크로 서비스 아키텍처 이른바 MMSA 구조로 변경되었다고 합니다. 글루와 개발 팀은 "우리 서비스를 개발하느데 있어 MSA구조가 정말 맞는 구조인가?"에 대한 강한 의문심이 들었고 결과적으로 모놀리틱 구조에서 마이크로 구조의 장점을 더해서 만든 MMSA 구조를 만들게 되었다고 합니다. MMSA 구조는 다음과 같습니다.

MMSA 구조의 특징은 다음과 같습니다.

1. 모놀리틱 아키텍처처럼 하나의 DB를 공유한다. 

2. 서비스 클라이언트를 모듈 형태로 만든다. 

3. 하나의 엔드포인트에서 리소스를 제공한다.

일단, MSA 구조의 가장 큰 문제점이었던 통신 중에 에러가 났을 때 생기는 DB 동기화 문제를 MMSA에서는 기존 모노리틱 아키텍처처럼 하나의 DB를 사용함으로써 해결하였다고 합니다. 글루와 팀은 DB가 제공하는 트랜잭션-롤백을 버리는 것은 옳지 않다고 판단하였고 이런 구조를 통해서 안정성을 확보했다고 합니다. 

그리고 제가 선정한 "MMSA 구조의 꽃" 바로 모듈 형식의 서비스 형태입니다. MMSA 구조에서는 MSA 구조보다 코드량이 3배 가량 많다고 합니다. 이유인 즉슨, 먼저 data access layer 클라이언트와 후에 떨어져나갈 http client api를 둘 다 만들어두기 때문입니다. 그리고 애플리케이션 구동 시에 startup.cs에서 DI 패턴으로 데이터에 접근하는 서비스일지, API 엔드 포인트에 의한 서비스일지 결정하게 됩니다. 이 때 특이한 것이 컴포넌트들은 dll(혹은 jar)파일로 빌드시키는데. 음,,, 닷넷 코어 형태로 봤을 때 MMSA 구조 역시 한 솔루션에 여러 프로젝트가 존재한다고 생각하시면 됩니다..

https://github.com/gluwa/ShoppingMallDemo

다음 URL에서 코드를 살펴보시면 감이 잡힐 것입니다. 결국 이렇게 했을 때 가장 좋은 점은 MSA 구조로 변경하기 쉽다는 것입니다. 그냥 모듈 자체를 서비스로 만들어서 별도로 배포하면 끝이기 때문이죠. 결국 MMSA에서 보는 서비스의 단위는 다음과 같습니다.

서비스 = 비지니스 로직 + API 엔드 포인트 + Dacta Access Layer

하지만 MMSA도 단점이 존재합니다. 글루와 팀은 다음을 단점으로 뽑았습니다.

1. 프로젝트 구조를 잡을 때 코드량이 많다.

2. 유효성 검사 떄문에 중복되는 코드가 많다.

그래서 다음과 같은 개선 작업을 진행 하고 있다고 합니다.

1. 캐싱 최적화

2. 크로스 도메인 유효성 검사

3. 크로스 도메인 오류 처리

느낀점

사실 처음 들어보는 컨퍼런스라 굉장히 기대를 많이 하고 갔습니다. 살짝 조용한 분위기라.... 찍는게 조심스러워 딱 한 장만 찍었는데 하필 포프님이 눈 감으신...... ㅠㅠ 아무튼 컨퍼런스 자체는 만족했습니다. 단 돈, 1000원이라고는 믿기지 않을 정도로 알찬 내용들이었어요. 아무래도 현재 제가 개발하고 있는 프로젝트가 MSA 구조로 만들고 있어서 더 귀기울이게 된 것 같습니다. 앞으로 더 많은 컨퍼런스에 참여해서 나중에는 저도 포프님처럼, 크리스님처럼 한 번 컨퍼런스 발표를 해보고 싶네요. 감사했습니다!

참고자료

그림 이미지 http://bcho.tistory.com/948