MSA-1.4-MSA의 단점

jaegeunsong97·2023년 9월 3일
0

MSA

목록 보기
4/6

IPC(Inter-Process Communication)

  • 모놀리식에서의 모듈, 서비스 간 통신(개발, 운영 측면)
    • 모놀리식에서는 개발자는 SpringBoot로 로직만 짜면 끝
    • 트러블 슈팅 발생 시, AA/TA/DA 호출
    • 실패 시, 할 수 있는 것이 없음

  • 모놀리식에서의 모듈, 서비스 간 통신(빌드, 배포 측면)
    • Jenkins Job으로 배포 : 깃허브로 부터 배포용 코드 받아오고 빌드
    • 하지만 만약 빌드 도중에 ERROR 뜨면?
      • 간단 : 갓 구글링으로 해결가능
      • 복잡 : 해당 회사 DevOps 엔지니어 호출 ㅠㅠ

  • MSA에서의 모듈, 서비스 간 통신(개발, 운영 측면)
    • 다른 서비스를 호출 : 무조건 통신 필요(HTTP, gRPC)
    • HTTP, gRPC 이해 필요
      • Keepalive : 설정을 하지 않으면 대용량 처리시 비효율적
      • Connection Pool
      • Connetcion Logic Timeout : 방화벽문제, Connection을 얻어오는 과정에서 문제(외부)
      • Business Logic Timeout : 호출하는 서비스 내부에서 문제(내부)
    • 따라서 이런 판단을 할 줄 알아야 하기 때문에 단점
      • 알아야하는 양이 모놀리식에서는 개발만 하면 됬는데
      • 지금은 어디서 문제가 발생했는지 알아야 DevOps 엔지니어와 소통이 가능

  • MSA에서의 모듈, 서비스 간 통신(빌드, 배포 측면)

Transactions

  • 모놀리식 트랜젝션
    • 필요한 것
      • SpringBoot
      • @Transaction
      • DB Resource
    • on-premise방식이기 때문에 1개의 DB 1개의 서버여서 트랜젝션은 1개의 서버에서 작동을 한다
      • 따라서 WRITE 3개중 1개라도 ERROR가 되면 전체가 ROLL BACK 된다.

  • MSA 트랜젝션
    • 기본적으로 각 서비스를 호출할 때통신을 통해서 호출한다.
    • 모놀리식의 경우 1개의 프로세스에서 실패시 전체 WRITE 되는 서비스가 ROLL BACK이지만
    • MSA의 경우는 통신이기 때문에 1개의 서비스가 실패시, 통신을 통해 이전 통과된 서비스에게도 실패했다고 알려주고 전부 ROLL BACK을 한다.
      • 이것을 보상 트랜젝션이라고 한다.
    • 필요한 것
      • 2PC : 2 page commit
        • 2번의 commit을 통해 진짜를 표현
        • 따라서 2번이나 commit을 표현하는 것 자체가 어렵고 복잡
      • 보상 트랜젝션
      • Saga : 내부적으로 보상 트랜젝션으로 구성
    • MSA 트랜젝션은 복잡하고 어렵다.

  • 어렵고 복잡한 Data Query
    • 모놀리식의 경우 : 1개의 DB만을 사용하기 떄문에 실패와 성공의 데이터를 가지고 오려면 JOIN을 2~3번 사용하면 해결 가능
    • MSA의 경우 : 원하는 데이터가 서로 다른 곳에 존재하기 떄문에 통신을 통해서 먼저 다른 DB에서 원하는 데이터를 가져오고 그것을 바탕으로 정보를 추출
      • 듣기만 해도 복잡
      • 이런 것을 Data Query
        • API 조합 패턴 : 말 그대로 API의 결과를 바탕으로 조합해서 Query 만듬
        • CQRS 패턴

Monitoring

  • 모놀리스 모니터링
    • 모니터링 대상
      • 인프라
        • 서버, DB
        • 상태 :CPU, Memory
      • 네트워크 Status : 속도와 시간
        • Inbound Proxy Latency
        • Outbound Proxy Latency
      • 어플리케이션 상태
        • JVM Status
        • App Warning
        • Error
    • Node가 1개 : 송금서비스, 고객 계좌 확인 서비스, 계정/고객 서비스를 포함하는 1개의 Process
      • 1개의 Node가 외부와의 통신 + SQL과의 통신
    • Node Exporter, Prometheus, Metric Push Gateway

  • MSA/Cloud 모니터링
    • 모니터링 대상
      • 모놀리스 모니터링 대상 포함
      • 서비스 간 응답, 네트워크 상태 : Latency, Error rate
      • 어떤 트랜젝션이 어느 구간에서 왜 문제가 발생
    • 전체적인 흐름을 다 알아야 모니터링이 가능
      • 어디서 문제가 생겼는지 알 수 있기 때문에
    • Node가 n개 : 각 서비스에 대해서 Node가 존재
    • Matric : 노드와 서비스의 상태를 의미
      • Matric 수집방식
        • PUSH(에플리케이션 기준) : 프로메테우스가 주기적으로 가지고 옴, but corn 2, 3초 이떄 PUSH
          • 언제 어느 시점에 정확하게 올라오는지 측정 힘듬
          • 짧은 시간올라왔다, 내려갈 수도 있어서
        • PULL(프로메테우스 기준) : DEFAULT
        • 에플리케이션이 Port만 열어두면 프로메테우스가 알아서 PULL을 해서 가져감
          • 따라서 에플리케이션 부하방지

  • 결론
    • MSA 난이도 높다
    • 통신, 트랜젝션, 모니터링 -> 어려운 문제들
      • 그러나 AWS, Cloud 기반 기술(Docker, K8S) 으로 많이 해결
      • MSA환경에서 모니터링을 위한 다양한 기술 스택이나 이론 많이 나옴
    • 전체적인 동작 방식과 구조 이해해야 -> Business Capabilites 챙길 수 있다.
    • 결론은 Business Capabilites 존나 중요, 돈이잖아 ㅎㅅㅎ.....
profile
현재 블로그 : https://jasonsong97.tistory.com/

0개의 댓글

관련 채용 정보