[MicroService Architecture] SpringCloud를 이용한 상품 MSA적용을 시도한 경험을 공유합니다.

저는 커머스플랫폼을 개발하는 조직에 소속되어 있습니다. 여기서 말은 못하지만 다들 잘 아시는 커머스 서비스의 백단 플랫폼을 만드는 조직 이었는데요. 이때 기존 커머스 플랫폼은 구축한지 오래된 Monolithic Architecture구조로 되어있었습니다.

이것을 MicroService Architecture로 전환 하기위한 시도의 일환으로 제가 사내에서 발표한 내용을 당시 개발셀장님에게 보안적으로 이슈가 있는 부분을 가리고 블로그에 블로깅해도 된다는 허락을 받아 블로깅을 하게 되었습니다.

  • 왜? Micro Service Architecture (이하 MSA) 를 생각하게 되었나?  
    • 커머스 플랫폼 프로젝트는 Groovy, Grails를 이용하여 Monolithic architecture 로 build된 프로젝트 입니다. 모든 도메인의 로직이 한 프로젝트안에 들어있죠… 뭐… 작은 규모의 프로젝트라면 큰 문제는 없습니다.
    • screen-shot-2016-12-05-at-10-48-48-pm
    • 하지만 이런 커머스 플랫폼 정도의 규모라면 Monolithic architecture의 구조문제및 복합적인 문제가 발생하기 시작합니다.
    • screen-shot-2016-12-03-at-11-07-02-am
      • 개발자가 Local 에서 프로젝트 빌드시에 덩치가 크기 때문에 빌드 시간이 엄청나게 오래걸림 (Grails 라서 오래걸리는 건지… 덩치가 커서 그런건지… 맥북프로 레티나 최고급형인데도… 가끔 분단위로도….)
      • 한프로젝트에서 작은 서브 프로젝트들이 코어 소스를 공유하고 있고 각 프로젝트별로 소스참조가 있기 때문에 작은 실수로 전체 프로젝트 빌드 실패나 한곳에서 낸 장애가 서비스 전체로 번지기도 함
      • 도메인 혹은 로직들의 Coupling이 강하기 때문에 성능문제나 장애시 원인 파악 혹은 수정하기가 힘들다… (옵션에서 수정하면 기본 상품 정보에서 장애가 터지기도 하고…)
      • 도메인의 CRUD 혹은 비즈니스로직이 이곳저곳 분산되어 있기 때문에 새로운 팀원이 와서 파악을 하거나 기존에 있던 팀원도 장애 포인트를 찾는데 시간이 걸리기도 합니다. (힘들어요..)
      • 로직 관련 이야기를 더 하면 view 영역에 GSP 혹은 Javascript로직에도 중요한 로직이 있으며 Javascript 또한 같은 도메인의 로직임에도 분산되어 있어서 따라가기가 힘들다.
      • 간단한 기능 혹은 bugfix 에도 불구하고 전체 배포를 해야한다. (배포 시간도 오래 걸리기도 하고… GSP 같은거 수정해도 다시 다 배포…)
      • Groovy 나 Grails 문제… 일단 문제 생겨서 구글링 해도 바로 해결점을 찾기란 좀 힘들고 시간걸리고 스트레스 받음 그리고 개발자 커리어 관리에 안좋음… (자네 카카오에서 뭐했나? 저는 Grails를 이용하여 어쩌구저쩌구….??? Grails가 뭔가요??)
  • 그럼 개선방법은?
    • screen-shot-2016-12-05-at-10-51-31-pm
    • 제가 속한 상품개발유닛장이자 제가 존경하는 개발자이며 Java 17년차 외길인생 이신 일명 “개발의신” 이셨으나 최근 Groovy를 만나곤 Java를 버렸다는 최모 개발자의 의견을 일단 들어보았습니다.
      • 최모 개발자 “Grails 와 Groovy를 유지한 상태로 일단은 기존 로직 정리 및 리펙토링 하자” 라고 하셨는데… (정확히는 리펙토링 하고 정리후 새로운 language 나 framework 을 적용하도록 하자)
      • 그래서 고민해 보니 일단 Grails는 하기가 싫었습니다. (정확하게 하기가 싫다기 보다는 이걸 파서 익숙해질 시간에 Spring 이나 더 실무에서 했음 했죠…)
      • 기존 로직 정리 및 리펙토링 하려고 보니… 아.. 헬이네요.. 할일이 태산… 그냥 정리와 리펙토링을 새 그릇에서 했음 좋겠다.. 라고 생각 했죠.
      • 그리고 화제가 되는 MSA로 다시 상품 도메인을 구성을 해보자 라고 생각 했죠. (MSA가 왜 상품쪽에 적합한지는 아래에서 설명 하도록 하겠습니다.…)
  • 그래서 일단은 기술스택을 정했습니다.
    • 기본 language와 framework은 대중적이며 개발자 커리어 관리에도 좋도록 : Java 1.8, Spring boot 1.4, MariaDB
    • 여기에 요즘 인기있는 (김영한님이 쓴책 다들 한권씩 가지고 계시죠?? 자바 ORM 표준 JPA 프로그래밍)  screen-shot-2016-12-03-at-11-26-50-am
    • 그리고 캐시나 빠른 Response가 필요할때는 Redis (국내에서 Redis를 가장 잘 다루기로 소문난 강대명님이 사내에 계시기 때문에 Redis 관련 문의는 바로바로 할수 있다는 장점)screen-shot-2016-12-03-at-11-29-26-am
    • 여기서 해당 기술스택을 이용해 MSA를 적용하기 위해서 Spring Cloud 를 이용하기로 했습니다.
      • Spring Cloud란 Spring 의 프로젝트 이름 입니다. (http://projects.spring.io/spring-cloud/)screen-shot-2016-12-03-at-11-31-11-am
      • 쉽게 생각하면 Spring boot 에 좋은 library 를 더해서 개발자들이 MSA 서비스를 쉽게 만들수 있도록 도와주겠다 라는건데요. 여기서 좋은 library는 대부분 Netflix 개발자들이 만들어서 Open Source 한것이 대부분이라고 합니다. Netflix에서 지금 쓰고 있구요.
  • 본격적으로 들어가기 전에 Spring Cloud에 관해서 더 이야기하기 전에 정리를 하고 넘어갈것이 있습니다. 
    • Monolithic architecture 는 다 아시죠?? 그냥 정통적인 web service 개발 architecture 라고 생각하면 됩니다. 한 모듈안에 모든 기능이 다 들어있죠.screen-shot-2016-12-03-at-11-32-49-am
    • 장점은 빠른 개발속도와 Test가 쉽고 ScaleUp구조에 유리합니다.
    • MSA 도 다 아시겠지만. 한번더 학습하고 넘어간다 생각하며 귀차니즘의 압박이 오더라도 한번더 보고 넘어 가도록 하죠. 장점을 정리해 볼께요..screen-shot-2016-12-03-at-11-37-22-am
      • 각 중요한 도메인의 기능을 작게 나누에 독립적으로 실행이 가능하도록 하자. (자율적이며 Transaction 단위로 분리하는게 좋음)
      • 따라서 한가지 일을 자~알 하는데 초점을 맞추자.
      • 기능추가나 bugfix 배포,복구 등이 자유로우며 한 모듈의 장애가 다른 모듈로 전파되지 않는다.
      • 코드의 양이 줄어들어 누구나 쉽게 파악이 가능해서 바로 현업 투입이 가능 하도록 하자.
      • 모듈 하나하나가 규모가 작기 때문에 신기술 적용이나 요즘 좋은 배포 시스템 연동이 매우 쉽다.screen-shot-2016-12-03-at-11-40-13-am
      • Rest API와 Json을 이용한 모듈간의 자유로은 communication이 가능함
      • Rest API(Json)는 Platform 이나 language 에 독립적이다.
        • 학습 하기가 매우 쉽다. (사람이 보기 쉽다. 개발적인 지식이 없는 기획자나 디자이너 들도 분석이 쉽게 가능하다.)
        • 요청의 결과가 Json으로 나오기 때문에 캐시를 적용하기가 매우 쉽다.
      • 각 모듈별로 개발자가 틀릴경우에 장점이 나오는데
        • A와 B모듈을 개발하는 개발자가 다른경우에도 서로간의 통신 Format 만 정해 놓으면 (Json 의 key 데이타 등) 서로간에 모듈이 완성이 될때까지 기다릴 필요가 없다. Mock 으로 Json 을 만들어 놓으면 되니깐. (그러니 눈치보며 서로 쪼는 행동을 할 필요도 없으니 좋다.)screen-shot-2016-12-03-at-11-41-48-am
    • 그럼 MSA는 구세주 인가요?screen-shot-2016-12-03-at-11-42-40-am
      • 당연히 그럴리가 없죠 … 아무튼 … 단점도 존재 합니다.
      • 너무 작은 서비스에서 MSA를 적용하면 오히려 낭비 (인력자원, 귀차니즘, 돈 등등….)
      • 또 이게 기능을 너무 많이 쪼개면 오히려 복잡도 증가 (상품 정보 하나 조회 하는데 Rest 호출 20번에 만약 리스트 조회 라면 x 100번 …)
      • 그리고 보통은 MSA 쪼갤때 각각의 모듈은 독립적인 DB 를 사용하도록 되어있습니다. screen-shot-2016-12-03-at-11-45-36-am이런식으로 말이죠… 하지만 이 때문에 Transaction 으로 묶기가 좀 힘들어요… (그래서 일단은 상품쪽은 같은 물리적인 DB 에 Database 를 논리적으로 나누어 갈까해요.)
      • 그리고 각 모듈마다 설정이나 기동방식이 다르다면 좀 귀찮죠…
      • 하나하나 git clone / pull 하는것도 일이고..
      • 그리고 초기 개발시에는 MSA 로 원활히 개발을 위한 인프라준비 등으로 개발 시간이 오래 걸리는것도 단점 입니다.
  • 그러면 다시 도메인 이야기로 돌아와서.. 왜 상품도메인이 MSA 적용하기가 좋은건데? 
    • 상품 도메인은 우리의 상품의 등록 승인등의 프로세스로 인하여 각 서브 도메인별로 의존도가 낮습니다.screen-shot-2016-12-03-at-11-50-34-am
    • 간단하게 설명을 하자면 이 커머스 플랫폼의 경우 오픈마켓이 아니기 때문에 상품등록시 승인 구조를 가지고 있습니다. screen-shot-2016-12-05-at-10-53-50-pm
    • 엠디가 상품 승인과 노출의 모든 권한을 가지고 있습니다. 따라서
    • 만약 모듈중에 하나가 문제가 생겨서 상품등록시에 배송비 정보를 빼고 등록이 되었다면.. 승인 거부를 하면 됩니다. screen-shot-2016-12-05-at-10-58-19-pm-copy
    • 이렇게 옵션 뿐만 아니라 이미지, 고시정보, 배송정보 등 각각 분리가 쉬운 구조로 되어있습니다. (일부 서브도메인의경우 UX가 완전 독립이 되어있죠)
    • 그래서 상품의 SpringCloud를 이용한 MSA 적용 Architecture 는 다음과 같습니다. (V. 0.5)screen-shot-2016-12-05-at-11-03-31-pm-copy
    • 보시다 보면 다른것은 다 하실텐데 Eureka는 뭐여?? 라고 생각하실껍니다. 이제 그 이야기를 하죠.
  • 이제 Spring Cloud에 관해서 더 이야기를 해보도록 하죠.
    • 위에서 잠깐 언급 했지만 Spring Cloud는 Spring boot + library(잡다한) 입니다.
    • 이야기를 하기전에 Twelve factors 방법론을 살펴보고 넘어가는 것이 좋습니다. (요약하면)
      • 설정 자동화를 통하여 최근 등장한 클라우드 플랫폼에 배포를 쉽게 한다.
      • 개발환경과 운영환경의 차이를 최소화하며 지속적인 (수시로) 배포가 가능하도록 한다.
      • 개발 환경이나 방식을 크게 바꾸지 않고도 ScaleUp, Out을 가능하게 한다.
    • 이중에 우리가 가장 많이 사용해야 할것 요약하면..
      • 버전이 관리되는 하나의 코드베이스를 사용하여 분리된 환경설정으로 배포가 가능하게 한다. (더이상 소스를 알파 베타 리얼 이딴거 없도록 하자)screen-shot-2016-12-03-at-12-02-22-pm
    • 어플리케이션을 stateless 하도록 프로세스를 실행 하게 만들도록 하자
      • MSA에서 사용하는 Http프로토콜은 자체적으로 상태를 저장하거나 유지할수 없다. application 딴에서 상태 정보를 유지관리해야 한다. 그래서 Http 그 자체는 stateless하다고 할수 있다.
      • 그러니깐 sticky session 이나 로그인 세션등 이런거 쓰지말자는 거다.
      • 각각의 요청은 독립적인것이라고 생각하며 이전에 했던 요청에 의존적이지 않다는 것이다. 따라서 각각의 요청은 모든 서버가 처리가 가능하도록 모든 정보를 제공해야 한다.
      • 단… 클라이언트가 요청을 할때 상태 정보를 전달해야하니 네트워크 리소스를 그만큼 소모해야 하고 서버는 해당 요청을 받아 처리를 더 해야하는 리소스는 필요하다.screen-shot-2016-12-03-at-12-03-21-pm
      • 당장 와닿는것만 정리해 보았고 나머지 Twelve factors 방법론은 알아서 찾아보세요.screen-shot-2016-12-03-at-12-04-27-pm
    • Spring Cloud 에서 가장 중요한 모듈은 Eureka 라고 할수 있습니다. Eureka는 MSA를 구성함에 있어서 각 모듈의 Lookup, Scale상태, 모듈의 Health 상태등을 관리하는 모듈 입니다.screen-shot-2016-12-03-at-12-06-43-pm
      • Client 에서 account서비스에 요청이 들어오면 Eureka는 account 서비스가 어디에 있는지 요청이 가능한 상태인지 체크를 해서 해당 서버의 ip와 포트의 정보를 돌려주게되고 클라이언트를 해당 정보를 요청하게 됩니다.
      • 코드를 간단하게 보면 screen-shot-2016-12-03-at-12-07-48-pm소스코드로 보면 이렇게 됩니다. app_name 에 같은 모듈이 서로 다른 포트로 100개 달려있건 1개가 달려있건 상관없죠. (Client side Loadbalancing 라고 부릅니다)
      • Eureka는 DashBoard를 지원하는데요. 여기에서 각 모듈의 상태를 확인할수 있죠.screen-shot-2016-12-03-at-12-09-04-pm
    • 그리도 또 중요한것이 설정의 분리 입니다.
      • 설정이라하면 Db 접속정보 URL 정보 기타등등 많은 설정 정보가 있죠? 이것들은 보통 프로젝트에 들어있습니다. (YML이나 Properties파일로 따로 저장하는 설정 파일들) screen-shot-2016-12-03-at-12-12-28-pm
      • 이런 설정 파일들을 더이상 프로젝트 내부가 아닌 외부 GIT에 올려 놓습니다.screen-shot-2016-12-03-at-12-13-11-pm
      • 위의 이미지를 보시면 YML 파일을 app의아이디-환경명.yml 파일로 만들어 두고 GIT Repository에 올리곤 spring config 서버에 연결만 해 두면…screen-shot-2016-12-03-at-12-15-00-pm
      • GIT Repository에 YML 파일로 올려둔 설정을 가져다 쓰는 법은 간단하게 가져다 쓸수 있습니다.screen-shot-2016-12-03-at-12-15-30-pm
      • 그리고 가장 좋은것은 클래스 상단에 이렇게.. @RefreshScope 만 붙여주면 restart 없이 다이나믹하게 설정값을 변경할수 있어요. screen-shot-2016-12-03-at-12-17-07-pm
    • Rest API 호출을 하는것은 불편하고 번거롭다? (네 좀 귀찮을때가 있죠)
      • Spring Cloud 에서는 Rest API 호출한다는 개념이 좀 달라요 즉 일반적으로는 Http Rest 통신의 경우 외부에 있는 자원을 Http 통신을 이용해서 내가 가져다 쓴다. 이제는 Rest 자원도 local 자원처럼 쓸수 있어요.
      • 즉 Eureka로 묶여있는 서비스 내에서는 로칼 레포지토리 호출하듯 interface 를 만들어서 쓰면 됩니다. screen-shot-2016-12-03-at-12-19-23-pm
      • API 주소는 설정파일에 올려놓고 Spring config를 이용해서 쉽게 사용할수 있어요. (언제든 바꿀수 있고 서버 리빌드가 필요 없어요.)screen-shot-2016-12-03-at-12-20-04-pm
      • screen-shot-2016-12-03-at-12-20-36-pm
    • 마지막으로 Hystrix Circuit Breakers 도 쉽게 사용할수 있어요.screen-shot-2016-12-03-at-12-21-24-pm
      • 쉽게 소스 코드로 설명하면 특정 메서드의 실행 조건을 정해서 그 조건에 걸리면 다른 메서드를 실행 하도록 할수있죠. (응답 속도가 느리다거나.. exception 이 난다거나..)screen-shot-2016-12-03-at-12-22-11-pm

이상으로 상품 도메인의 MSA 프로젝트를 위해 제가 사내에서 발표 했던 자료중에 보안에 문제가 있는 부분을 뺴고 정리를 해보았습니다.

결과적으로 프로젝트는 그럼 어떻게 되었냐 하면 제가 퇴사를 하는 바람에 진행을 하지는 못했어요 ㅜㅜ

하지만 프로젝트를 하기 위해 공부를 하고 Architecture를 그리고 데모를 위해 프로젝트를 만들고 상품 도메인의 여러 서브 도메인중 몇가지는 MSA로 직접 개발해 보기도 했으니 개인적으로 성과는 충분 하다고 생각 했습니다.

나중에 기회가 되면 더큰 MSA프로젝트를 해보고 싶네요. ^^

이미지 출처

screen-shot-2016-12-03-at-12-22-47-pm

[MicroService Architecture] SpringCloud를 이용한 상품 MSA적용을 시도한 경험을 공유합니다.”에 대한 2개의 생각

  1. 정용태

    좋은 글 감사히 잘 읽고 갑니다 ^_^

    모노리틱과 마이크로서비스 아키텍쳐 형태로 모두 개발을 해 봤는데도

    이 글을 포스트를 읽으니 이제야 아~ 내가 이런 아키텍쳐의 일을 했었던 거구나 라고 알게 되었습니다.

    고맙습니다.

    응답
  2. Haanee

    안녕하세요, MSA를 막 파악하고 있는 UX디자이너입니다.
    저희도 처음 적용해보는거라 막막한데요, UX디자이너(UI, GUI모두 포함)와 일하는 방식에 있어서
    MSA를 적용함으로 인해서 달라진 점이 있었나요?
    디자이너 입장에서 어떤 것을 고려해야 도움을 줄수 있는지 궁금합니다.

    응답

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다