SKplanet Tacademy 의 임성묵님의 발표자료를 옮겨 둔 내용입니다. 임성묵님과, 자료를 준비 해 주신, SKplanet Tacademy 에 감사드립니다.

자료출처: https://www.youtube.com/watch?v=D6drzNZWs-Y

콘웨이의 법칙

#[모놀리틱 애플리케이션]

  • 모든조직은 조직의 의사소통 구조(communication structure)와 똑같은 구조를 갖는 시스템을 설계한다.
  • 콘웨이의 법칙은 조직도에 초점을 두지않고, “실질적인 소통관계” 에 관심을 둔다. 너무 많은 통신관계를 갖는 것은 프로젝트에 대한 진정한 위험이 된다.

예를들어, 주문팀이 뭔가 해결하려면 정산팀에다도 물어봐야 하고, UI 팀에도 물어봐야 한다. 너무 많은 소통이 필요함.

장점

  • 개발이 단순하다.
  • 배포가 단순하다
  • 스케일-아웃이 단순하다 ( 서버 하나만 복사하면 된다. ) (DB 성능 한계가 있다.)

단점

  • 무겁다. [IDE 가 못받쳐줌]
  • 어플리케이션 시작이 오래걸린다.
  • 기술스택 바꾸기가 어렵다.
  • 다른 서비스와의 높은 결합도
  • 코드베이스의 책임 한계와 소유권이 불투명
  • 레거시를 계속 하고있으면 개발자의 만족도가 굉장히 떨어짐

이쯤.. 회사가 결정하게 된다.

  • 새로운 언어, 깔끔한 코드로 전면 재개편함. ( 차세대 프로젝트, 빅뱅 ) [
  • MSA 플랫폼을 구축하여, 기존 레거시를 고사(strangle) 시킴

#[MSA]

  • 시스템을 여러개의 독립된 서비스로 나눠서, 서비스를 조합함으로써 기능을 제공하는 아키텍쳐 디자인 패턴

사례1. 제프베조스 의 메일 2002년

제프베조스 - 컴퓨터 공학과 출신 개발자 , 아마존 CEO

  1. 모든 팀들은 데이터와 기능들을 서비스 인터페이스로 연결시켜라.
  2. 팀들은 이 인터페이스를 통해서만 연락해야한다.
  3. 다른 어떤 커뮤니케이션 방법도 허용되지 않는다. 직접 링크를 보내거나 다른팀의 스토리지에 직접 억세스 해서도 안되며, 공유 메모리나, 백도어 같은것도 안된다. 모든 커뮤니케이션은 네트워크를 통한 서비스 인터페이스로 이루어져야한다.
  4. 어떤 기술을 쓰든 상관없다. HTTP, Cobra, Pubsub, 독자프로토콜.. 그건상관없다. 베조스는 그런데 관심없다.
  5. 모든 서비스 인터페이스는 예외없이 외부에서 이용가능하게 만들어져야한다. 그말은 팀들은 외부 개발자들이 인터페이스를 이용할 수 있게 해야 한다는것이다. 예외는 없다.
  6. 이를 실천하지 않는 사람은 누구든 해고될 것이다.
  • 2006년 아마존 웹 서비스 (aws) 릴리즈

사례2 [넷플릭스의 선택]

  • 2008년 데이터베이스에 심각한 문제가 발생해, 고객에게 DVD 를 보낼 수 없는 사태발생 (Single Points of failure)
    • Scale-up 확장만 가능한 인프라 스트럭쳐와 단일 장애지점(SPOF) 이라는 한계에서 벗어나길 선언
    • 시작은 아파치 카산드라.
  • 2009년 AWS 로 이관시작
    • 세가지 목표에 집중. 확장성(Scalability), 성능(Performance), 가용성(Availability)
  • ‘자체 보유 인프라와 솔루션으로는 이렇게 급증한 트래픽을 감당할수 있는 확장성을 확보 할 수 없었을것’ - 유리 이즈라일레프스키(Yuri lzrailevsky), 넷플릭스 클라우드 및 플랫폼 엔지니어링 부문 부사장
  • 온프레미스 환경 -> 클라우드 환경

#[그래서 MSA 란?]

  • 공식적인 정의는 없음. 단지 공감대가 있을뿐 ( 위키피디아 )
  • 각 서비스간 네트워크를 통해 ( 보통 HTTP )
  • 독립된 배포 단위
  • 각서비스는 쉽게 교체 가능
  • 각 서비스는 ‘기능중심’ 으로 구성됨 eg, 프론트엔드, 추천, 정산, 상품 등
  • 각서비스에 적합한 프로그래밍 언어, 데이터베이스, 환경 으로 만들어진다.
  • 서비스는 크기가 작고, 상황에 따라 ‘경계’ 를 정하고, ‘자율적으로 개발’ 되고, ‘독립적으로 배포’ 되고, ‘분산’ 되고, ‘자동화된 프로세스’ 로 구축되고 배포된다.
  • 마이크로 서비스는 한 팀에 의해 개발할 수 있는 크기가 상한선이다. 절대로 3~9명의 사람들이 스스로 더 많은 개발을 할 수 없을 정도로 커지면 안된다.
  • ‘마이크로 서비스는 아직까지 아이디어 수준에서 크게 벗어나 있지 않다. 다양한 산업 분야에서 폭넓게 적용되고 있지만. 그것이 좋은지 나쁜지는 시간이 더 지나봐야 알 수 있다.’ - 조쉬 롱, 케니 바스타니, 피보탈