Spring Cloud Netflix를 Akka와 연동하는 변종체 프로젝트를 도커화를 시도하는 페이지입니다.




마이크로 서비스가 가야할길

마이크로서비스에서 영속성을 다루는 방식은 전통적인 CRUD를 사용할수도 있고 CQRS,EventSourcing등을 활용할수도 있습니다.

각각 다른 목표를 가진 마이크로서비스에서 CRUD에 이점이 있는것을 무리하게 CQRS로 통합하는것은 마이크로서비스의 본연의 목표는 아닙니다.  


우리는 다음과 같은 질문을 던질수 있습니다.

마이크로 서비스는 트랜잭션 무결성처리를 어렵게 만든다?

이것은 도메인이  복잡해짐에 따라 그것에 대응하는 유연한 설계가 안되었기때문이며,오랫동안 유지되고 변경된 서비스에서

트랜잭션 무결성을 준수하면서 조작할수 있는지에대한 기존코드를 통해 어떠한 통찰과 해석을 할수 없었기때문입니다.

즉 오랫동안 유지된 솔리드 서비스에서 기존 트랜잭션 무결성을 유지한채로, 기능을 개선하고 추가하는게

얼마나 어려웠는지 몇가지 경험과 이야기를 통해 알수 있습니다.

만약 이것이 쉽고 확장이 가능하였다면 마이크로서비스는 필요가 없었을것입니다.

마이크로서비스는 책임단위를 작게하여, 복잡성을 나누고 줄이는 것에 목적을 둡니다.  

분명한것은 복잡한 도메인의 트랜잭션 무결성을 처리하는 주제는 그냥 어려운 주제입니다.


이것은 마이크로 서비스 도입과정중 도메인주도설계 를 함게 이해하며 해결해야 하는 과제 입니다.



마이크로 서비스는 규모와 유연성에서 적합한가?

규모와 도메인에따라 다르게 전개될수 있는 내용이며 마이크로 서비스의 장단점은 오랫동안 논의가 되어왔으며

단점을 커버하고 장점을 살리는 성공사례가 이제 충분히 축적이 되었습니다.

그리고 이것은 작고 빠르게 움직이며 빠르게 대응하는 요즘 비지니스환경과도 일치하기 때문입니다.

이제 이러한 논쟁은 이미 종결된 상태이고, 우리가가진 도메인을 어떠한 방법을 통해

마이크로 서비스화 할것인가? 를 고민을 해야합니다.


여기서는 인프라적인 관점에서 마이크로서비스를 다룹니다.

  • 발견(Discovery) 서비스
  • 모니터링과 APM
  • 로드밸런스
  • 도커를 통한 테스트 배포통합
  • 설정의 중앙화
  • 로깅의 중앙화


솔리드 시스템 경계를 분리하여 마이크로 서비스화하는 아키텍은 분명 도메인의 특성을 이해하는것에 시작합니다.

올바른 작은 서비스로 나뉘어 졌다라고 가정하고. 거대 솔리드 시스템에서는 단 1~2개의 서비스를 유지했지만

5~10 개의  또는 그 이상의 서비스로 나뉘어야 한다라고가정해봅시다.  이것이 올바른 경계로 나뉜다고 해도

여러개의 서비스를 운영하고 관리하고 배포하는 비용이 개수에 비례해  증가한다고 하면 이것의 도입은 사실상 불가능합니다.

가상화 - 도커 - 클라우드 의 발전을 통해 이러한 수많은 작은 서비스를 관리하는 방법이 성숙했으며

그것을 모두 올바르게 사용하는것은 분명 어려운과제이지만, 그것을 사용할 방법이 오픈스택에 준비가 되었으며

성숙한 개발팀은 그것을 이용하는 방법을 알아야한다는것입니다.


도커를 위한 클라우드 환경은, 개인이 학습하기 적당하고 가격이 저렴한 vultr 사용할예정...


  • No labels