2018 Open Cloud Engine 행사 회고

2018 Open Cloud Engine 행사

uEngine측에서 주관하는 Open Cloud Engine 행사에 참여하였습니다. 컬리큠럼을 보면 MSA를 실무에서 적용하면서 겪에되는 경험들을 공유하는 내용인거 같습니다. Spring Cloud를 이용한 MSA 구축에 관심을 갖고는 있지만 사내에서 폴리글랏 환경이기 때문에 아직까지 Spring Cloud를 사용할 예정은 없으므로, MSA과 함께 다루는 DDD(Domain Driven Design)과 CI/CD에 관심을 가지고 들을 예정입니다.

MSA 아키텍처 구현 개론

기존에 많은 애플리케이션은 모놀리식으로 구현되어있습니다. 하나의 서비스를 거대한 애플리케이션으로 동작하는 것을 말합니다. 예전의 서비스들은 규모가 작았기 때문에 모놀리식 방식으로 구현하더라도 고객의 요구사항을 충족할 수 있었으나, 현재는 모바일 기기등과 같은 수많은 디바이스를 통해 접근성이 높아졌기 때문에 고객의 요구사항을 발빠르게 만족하기 위해서는 하나의 거대한 애플리케이션으로는 불가능하게 되었습니다. 하나의 거대한 애플리케이션은 각 모듈간의 강한 결합을 가지기 때문에 하나의 모듈을 수정할 경우 다른 모듈이 오작동 할 수 있는 사이드 이펙트가 생길 수 있기 때문입니다. MSA는 이러한 패러다임 변화를 수용하기 위해서 최근에 많이 사용하고 있는 아키텍처 입니다. 거대한 애플리케이션을 작은 단위의 애플리케이션으로 나누고, 각 애플리케이션 간에 메시지 통신을 통해 느슨한 결합을 가질 수 있습니다. MSA를 통해 개발팀은 서비스의 안정성, 유연성, 짧은 배포 주기를 가질 수 있습니다.

MSA를 제대로 구축하기 위해서는 작은 애플리케이션 벌로 DB를 분리하는 것이 좋습니다. 그렇다면 기존에 RDB에서 하던 조인은 어떻게 하는 걸까요? MSA에서는 데이터를 합칠때 API Gateway 나 FrontEnd에서 하게 됩니다. 그렇기 때문에 MSA를 구축하게 되면, 자연스럽게 FrontEnd에서 처리를 많이 해주어야 하기 때문에 영향을 끼치게 됩니다.

[분석/설계] 도메인 주도 설계, 이벤트 스토밍과 BPMN를 통한 MSA 아키텍처 설계

폴리글랏 환경에서는 각 애플리케이션의 주소(IP, Port)를 DNS를 통해서 관리하는 것이 좋지만 Spring Cloud는 DNS를 사용하지 않고 넷플릭스에서 공개한 라이브러리인 유레카를 사용하여 각각의 작은 애플리케이션의 주소를 관리 합니다.

DDD(Doamin Driven Design)

금일 저희 팀장님과 카페에서 오늘 행사에 대해서 얘기를 하면서 DDD에 대해서 이야기를 했었습니다. 저는 DDD를 공부하면서 애플리케이션 단위의 작은 규모로 인식하고 있었는데 팀장님께서 DDD는 코드 레벨 뿐만 아니라 아키텍처 레벨 관점에서도 볼 수 있다고 알려주셨습니다. 이를 통해 저는 MSA와 DDD는 굉장히 유사한 개념이라는 걸 알게되었습니다. 해당 컨퍼런스에서도 DDD에 대해 얘기를 해주셨는데요. 작은 규모의 애플리케이션을 구현하는 것을 지향하는 MSA 또한 도메인 단위로 애플리케이션을 디자인하는 DDD와 매우 유사하다는 것을 알 수 있습니다.

DDD를 하다보면 어려운 부분이 있는데요. 도메인간의 경계가 애매한 부분을 어떻게 분리할지가 가장 어려운 부분이라고 생각합니다. 내공이 부족하기도 하고… 제 스스로가 명확한 기준 혹은 최소한의 기준을 갖고 개발을 하기 보다는 그 상황에 따라 결정을 하기 때문에 특히 어려운거 같습니다. 이 내용은 제가 좀 더 공부한 후 기회가 되면 공유해보도록 하겠습니다.

도메인 분석 -> 서비스 식별과 API 디자인 -> 서비스 구현 -> 서비스 통합 -> 서비스 운영 자동화 -> 비지니스 서포트

• 서비스 구현: 어떻게 하면 적은 비용으로 서비스를 구현할 수 있을까?

DDD & MSA

• 어떤 단위가 마이크로 서비스가 될 수 있을까?
  • Bounded Context -> 마이크로 서비스 크기 식별
• 서비스를 결합 할 때는 어떻게 결합할 것인가?
  • Aggregate -> Rest 데이터의 Aggreation
• 도메인 이벤트의 식별
  • Event-driven Architecutre 도출
• 잦은 변화에 유연한 설계
• 레거시 시스템의 단계적 폐기
• 리팩토링 전략
  • 지속적인 딜리버리와 개선

[구현] Spring Cloud를 사용한 마이크로 서비스 구현

MSA를 가장 관심있게 바라보고 있는 도메인이라고 하면 커머스를 대표적으로 들수 있습니다. 커머스 예제를 통해서 MSA 구축을 간단하게 진행해 보는 시간을 가졌습니다.

구현에 앞서 간단하게 설계 단계부터 시작하였습니다.

Event Storming

DDD를 간단하기 하기위해 할 수 있는 방법입니다.

Event 도출

• Event들을 먼저 도출하여 시작합니다.
• 우리 서비스에느 ㄴ어떤 비즈니스 이벤트들이 발생하는가?
• 현업이 사용하는 용어를 그대로 사용한다.

Command 도출

• 이벤트를 발생시키는 명령을 도출합니다.

Entity 도출

• 가능한 정규화하지 않고 간단하게 Document 형식으로 작성합니다.

Sub-domain과 Bounded Context

• 도메인 별로 분리하도록 합니다.
• 분리하기 애매한 부분을 잘 분리합니다.(Bounded Context)
• 분리된 도메인 영역은 마이크로 프로세스 영역으로 나눌 수 잇습니다.

Core/Supportive/General Sub-domain

• 위에 작성된 도메인 이외에 공통적으로 필요한 도메인을 추가합니다.

분산 트랜잭션

분산 트랜잭션을 하게 되면 각 애플리케이션 간에 메시징이 모두 완료 되지 않았을 경우 데이터 동기화가 완료되지 않을 경우가 발생한다. 그렇게 대한 대안으로

동기화가 완료되었다는 이벤트(All-done) 을 발생하고, All-done이 발생하기 전까지 알림을 한다. 이러한 부분적으로 동기화가 되지 않은 문제 때문에 금융권에서는 쓰기 힘들것이라고 판단된다??

[운영] Devops 운영자동화와 Private PaaS 플랫폼의 구축

###