모놀리틱 아키텍처 이해

1. 로컬 톰캣, DB를 이용해서 클라우드 톰캣(+DB)에 배포
   • 무중단 배포가 불가능(즉, 서비스를 멈추고 다시 실행해야하기 때문에 접속수가 낮은 시간에 배포)
2. (ha: high availability 구성) 클라우드에 들어가는 톰캣을 하나 더 구입해서 로드밸런서를 배치 + nginx, haproxy
   • downtime이 없음(첫번째 톰캣에서 톰캣을 내리고 딜리버리 후 다시 시작하고 두번째 톰캣에서 톰캣을 내리고 딜리버리 후 다시 시작)
   • 아파치나 nginx 등을 이용해서 정적파일을 캐싱해서 속도가 빠름
   • 로드가 많아져도 부하가 많아져도 로드 밸런서가 잘 분배해 줌
   • 요즘에 했다면 load balancer 부분이 elb가 되었을 것
3. 동접 트래픽이 많이 나오니까 클라우드에 들어가는 서버를 추가 구입
   • 서버가 많아지니까 일일히 배포해야 하는 작업이 많아짐 → Jenkins, Ansible(CD: continuous delivery)
4. 동접 트래픽이 증가하면서 개발팀을 분리 + 단일 레퍼지토리(DB) 사용
   • 브랜치 머지 시 충돌
   • 각자 배포 일정이 다르고 배포 이슈
   • 푸시만 하거나 배포만 하거나 하는 인력이 생김
5. 개발팀마다 다른 도메인을 써서 트래픽을 분리
   • 개발팀마다 로드밸런서 톰캣이 적어도 하나씩
   • 데이터를 다른 개발팀에서 가져올 때 매우 불편 → 공통 코드들이 있는 share 레퍼지토리를 만듦
   • 대부분의 개발이 share 레퍼지토리에서 이루어짐(어디 팀에서 이걸 쓸거같은데...?, 여기다가 만들면 누가 쓸텐데... 이러면서 대부분 share 레퍼지토리에서 작업) → 여전히 정기배포가 필요(sync 문제), share 레퍼지토리를 쉽게 건드리지를 못함(다 가져다 쓰고 있는데 누가 언제 쓰는지 모르니까)
6. 이 단계까지 오면 두 가지 선택지가 있음
   • 새로운 언어, 깔끔한 코드로 전면 개편
   • MSA 플랫폼을 구축

 

모놀리틱	MSA
하나의 공통 코드가 있어서 그 공통 코드를 임포트해서 하나의 어플리케이션에 띄우고, 하나의 어플리케이션에서 다양한 서비스(주문, 상품 어쩌고 등등)들을 담당하는 팀들과 모두 의사소통해야 한다 → 높은 결합도	시스템을 여러개의 독립된 서비스로 나눠서, 이 서비스를 조합함으로서 기능을 제공하는 아키텍처 디자인 패턴

 

본 게시글은 T아카데미의 Spring Cloud를 활용한 MSA 기초 강의를 바탕으로 작성되었습니다.