[Spring Cloud 를 활용한 MSA 기초] 1. 모놀리틱 아키텍처 이해

1. 모놀리틱 아키텍처 이해

---

youtu.be/D6drzNZWs-Y

• 10년 전으로 거슬러 올라가 보겠습니다
  • Amazon Web Services 가 없던 시절
• E-commerce 스타트업 시작
  • 이름 : 12번가
  • 업종 : 오픈마켓
  • 개발자 3명

개발자가 개발한 코드는 Tomcat(WAS) 에 의해 실행되고
프로그램의 상태(State) 는 데이터베이스에 저장

개발자가 여러명이 되면 코드를
SCM(Source Code Management) 으로 관리
 DB 는 공유해서 사용

---

최초 상용 배포

톰캣 1대, DB 1대 구입
SCP 를 통해 Clean 배포(stop -> delivery -> start)
DNS(12st.com) -> Tomcat

---

서버 1대 추가 구입

HA(High Avaliability) 구성 - 지속적으로 구동되는(uptime) 시스템
Load Balancer - L4 switch(hardware), L7(Nginx, HAProxy)

---

서버 3대 추가 구입

LB 설정 변경, 배포 방식 변경(Jenkins, Ansible, Chef, etc..)

---

조직개편. 상품팀, 주문팀으로 분리

단일 Repository

• Issue
  1. Branch Merge 시 Conflict Issue
  2. QA 를 어디까지? - 정기배포일
  3. 각자 다른 일정, 배포 이슈
  4. etc,.....

---

팀 별 Repository 분리, 각 코드 commit 시 팀별 배포 가능

공통적인 부분들을 Share Repository 에 넣음
각 프로젝트에서 compile “kr.co.12st:share:1.0.0-SNAPSHOT'

---

회사는 더더 성장하는데...

• 개발자 150명+
• 회원팀, 상품팀, 주문팀, 정산팀, 셀러팀, 등등.. 그리고 지원 조직(DB팀,..,.)
• 하나의 DB. (share.jar 에서 접근해야 하고.. 그게 쉬우니까)
• 수백만 라인의 공통 코드(소스 코드만 100MB 이상)
• copy & paste 에서 오는 중복과 복잡도

---

콘웨이의 법칙(Conway's Law)

• (광범위하게 정의하면) 모든 조직은 조직의 의사소통 구조(communication structure)와 똑같은 구조 를 갖는 시스템을 설계한다
  • Melvin Edward Conway, 컴퓨터 과학자
• 콘웨이 법칙은 조직도에 초점을 두지 않고, 실질적인 소통 관계에 관심을 둔다
  너무 많은 통신 관계를 갖는 것은 프로젝트에 대한 진정한 위험이 된다

---

모놀리틱 아키텍쳐 정리

• 대부분 IT 회사의 시작은 모놀리틱(Amazon, Netflix, 11번가, etc...)
• 장점
  • 개발이 단순하다(repository 하나 체크아 웃 받아서 띄우면 되니까..)
  • 배포가 단순하다(war 하나만 배포하면 되 니까..)
  • Scale-out 이 단순하다(서버 하나 복사하 면 되니까..)
    • 하지만, DB 성능으로 인한 한계가 있다
• 단점
  • 무겁다 - IDE 가 못 받쳐줌
  • 어플리케이션 시작이 오래 걸린다
  • 기술 스택 바꾸기가 어렵다
  • 높은 결합도
  • 코드베이스의 책임 한계와 소유권이 불투명

---

이쯤에서 회사는 결정을 하게 됩니다

• 새로운 언어, 깔끔한 코드로 전면 재개편 하거나
  • 차세대 프로젝트, 빅뱅
  • Netscape
• MSA 플랫폼을 구축하며 기존 Legacy 를 고사(strangle)시킵니다
  • Amazon, Netflix, 11번가, etc...