시스템 디자인 + MSA

BACK-END 2023. 7. 28. 13:07

1. 요구사항 명확화 : 핵심기능 , 트래픽이나 유저수 등 확인.  (1초에 1000요청, 유저 100만명에 서버 기본2대+1씩,  1명당 하루 86.4건 요청)


(High Level Design)

2.1 API - High Level Design (Rest API)   

2.2 Component - High Level Design : 로드 밸런스 + VM 몇대(x 오토스케일링) + DB 단
      - 프론트를 SPA방식으로, 웹서버 없이 대신에
          글로벌서비스의 경우 CDN이나,   로컬서비스면 S3같은 object storage로 미디어 부하분리.
      (VM이냐 컨테이너 기반이냐는  조직이 크고 여러 팀으로 나누어 개발한다면 독립배포가 중요해져서 컨테이너 기반이 좋을 것 같고..
                                                      조직이 작으면 VM기반이 좋을 것 같음)                                                 

2.3 DB선택 : 복제냐 샤딩이냐,   A:카산드라/실리아.  B. dynamoDB. C. mongoDB/documentDB. 4. RDB
       => 옵션중에  트래픽이 많거나 많아질 확률이 있고  필드간의 관계도 좀 필요하다면 B/C 중에 선택!
            (전반적으로 B/C가  샤딩등 분산환경에 유리하다. RDB보다는 개발리소스도 좀 적게 들고..)
            B/C의 차이는 C가 좀 더 index등의 튜징여지가 있으므로  엔지니어 구성에 따라 선택가능)
       => 향후 MSA를 대비해 foreign키 없게 하고, Join을 최소화해서 분리가 용이하도록!

 

3. DB 테이블 설계

 

4.(여유가 되면) Fault tolerance 고려

 

DB - 용량에서  1. master/slave구조,  2. 샤딩/ Table파티셔닝  고민필요.      (index 는 application영역이라 보고 일단 제외)
                                                             =>샤드키는 Cardinality가 높은 값으로 선정. 
        ( RDB - postgreSQL만 슈평분할(샤딩과 유사)지원,  mySQL/oracle은 테이블파티셔닝만 지원
          NoSQL - mongoDB, cansandra 등이 샤딩 지원 : 샤딩시 DB가 빨라지지만 aggregation등에선 늦어질 수도 있음)

         master/slave구조:  오라클에선 replication이라고 부르며 transaction replication 방식이 일반적) 

 

 

////// MSA로 전환 전 고려사항//////

1. API Gateway 는 수직 방향    서비스 메시는 수평 방향으로  라우팅/로드밸런싱 등을 수행한다.

2. DB 트랜잭션을 
      A. 동기화 형태로 홀딩하면서 API호출 완료 후 트랜잭션 수행 : 초기에 일반적 방식. 
      B. 분산트랜잭션(즉 2단계 커밋, 표시나 lock을 하고  API호출 후  완료.)으로 할것인지,
      C. 이벤트 기반으로 LLT(long live Transaction)이용하는 사가패턴을 적용하고 실패시 보상트랜잭션을 개발할 건지 고민필요.   

          => 사가패턴도 2가지가 있는데 중앙관리형과  서비스별 자체 관리형이 있다.

 

 

 

//////////// MSA 장단점

MSA의 핵심은  1. 데이터 분리와  2. API Gateway 라고 생각한다.
  (단, 1. 데이터 분리가 난이도가 높기 때문에,
         운영중인 모노리스를 MSA로 변환해야하는 실상황에서는 서비스만 먼저 분리하고 나중에 데이터를 분리하는 방법이 현실적이다) 

 

 

모노리스 장단점:

  • (장점) 배포 및 테스트도 하나의 애플리케이션만 수행하면 되기 때문에
     개발 및 환경설정이 간단, 운영 관리가 용이, 
  • (단점들 : 시스템이 커지기 시작하면 등장)
    - 빌드/테스트 시간이 길어진다.
    작은 수정에도 시스템 전체를 빌드해야 하며, 테스트 시간도 길어진다. 요즘처럼 CI/CD가 강조되는 시점에서는 큰 문제가 될 수 있다.
    - 하나의 서비스가 모든 서비스에 영향을 준다.  이벤트 서비스에 트래픽이 몰려 해당 서버가 죽게 된다면 다른 모든 서비스 역시 마비 되는 상황이 오게 됩니다
    선택적 확장이 불가능
    이벤트로 인해 서비스 접속 량이 폭증할 경우 프로젝트 전체를 확장해야만 한다.

MSA 장단점:  

  • (장점) 1. 서비스별 독립된 배포,  2. 해당 서비스별 확정.   
  • (단점들)
      모노리틱 아키텍처는 서비스간의 호출이 하나의 프로세스 내에서 이루어지기 때문에 속도가 빠르지만, MSA의 경우 서비스간 호출을 API통신을 이용하기 때문에 속도가 느리다.
  • 통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생 

 

Posted by yongary
,