컴포넌트

객체지향의 상속

• 상속은 소스 레벨 재사용성
  • 한계 : 소스가 있어야만 가능하다.

• 컴포넌트
  • 컴파일된(바이너리) 레벨의 재활용 기술
  • 프로퍼티(Property)를 통한 호출 및 제어
    • 프로퍼티: 일종의 매뉴얼과 같은 파일
      • Reflection
        • 자바의 고급기능
        • byte코드(.class)의 인자와 리턴값을 볼 수 있는 기능
        • 자바에서는 Reflection을 통해 IDL 없이도 메소드와 필드의 기능을 알아낼 수 있다.
      • Interface Definition Language(IDL) - MS IDL(MIDL)
        • IDL을 이용하면 컴파일된 코드에서도 메소드 참조가 가능
  • 컴파일 두 번 필요
    • MIDL로 정의, 코드도 컴파일해서 같이 묶어서 배포해준다.

분산 컴포넌트 기술

• 컴포넌트 기술
  • 컴포넌트 스펙
    • CORBA(Common Object Request Broaker Architecture)
      • 원조 컴포넌트 스펙 (원조라는 것만 알아두라)
    • MS
      • COM계열의 컴포넌트 스펙
        • COM (Component Object Model / COM+ / DCOM(Distributed COM)
        • EX) ActiveX (COM 기술로 만든 대표적 기술)
    • 자바
      • bean 계열의 컴포넌트 스펙
        • 자바 빈(Java Beans)
        • Enterprise Java Beans(EJB)
        • Spring Bean -> 스프링 프레임워크

• 분산 컴포넌트 기술
  • 네트워크를 통해 원격으로 주고받을 수 있도록 확장한 컴포넌트 스펙
    • EJB vs DCOM
    • 현재는 Spring Bean이 주류
  • 함수 호출식으로 네트워크 프로그램을 짜는 것
  • 네트워크 개념 포함 - 원격의 컴포넌트를 검색해서 외부 컴포넌트를 호출해서 결과 받아오는 것이 가능하다.
  • RMI/RPC 기술을 이용해 컴포넌트를 분산아키텍처에서 사용하도록 만듦
    • RMI : 자바
    • RPC : C
  • 컴파일된 빈의 형태로 호출과 참조가 가능한 구조.

• SOA (Service-oriented Architecture)
  • 서비스(컴포넌트의 확장) 기반 구조
  • 모든 것을 웹서비스로 구현
  • WS- 로 되어있는 프로토콜의 집합
    • 주로 XML로 되어있고 SOAP
    • 무거운 서비스로 인해 JSON과 RESful로 대체되어 발전
  • ESB(Enterprise Service Bus)때문에 무거워짐
  • 결국 복잡하고 무거워서 실패!!

• MSA (Micro-service Architecture)

  • SOA를 가볍게 만든 구조

  • 컴포넌트는 서비스의 형태로 구현

  • API를 이용해 타 서비스와 연동

  • 낮은 결합도(Loosely coupled)

  • 기존의 모노리틱 구조를 개선

  • 어플리케이션 로직을 분리, 여러 개의 어플리케이션으로 마이크로 서비스를 만들고
    서비스 별로 로드밸런서를 연결하는 방식

    • 서버 증설
      • 모노리틱 구조
      • MSA
        • 로드밸런스 증설
          이미지 출처 : https://bcho.tistory.com/948
    • 데이터 저장 방식
      • 이미지 출처 : https://bcho.tistory.com/948
        • 데이터베이스를 각자 사용
    • 이렇게 완벽한 구조에 문제점이 있을 수 있다고?

  • 모노리틱 구조와 MSA는 은행과 카드사로 비유할 수 있다.
    이전에는 은행이라는 법인 회사 내부에 카드 담당 부서가 있었다. ---> (모노리틱 구조)
    은행에서 우수고객 정보를 요청하면
    카드 담당 부서는 복잡한 절차 없이 고객 정보를 공유했다.
    서비스의 규모가 커지면서 은행과 카드사가 분리될 필요성이 생기고
    이제 카드사는 독립적인 법인이 됐다. ----------------------------------> (MSA)
    여전히 은행과 카드사는 같은 건물에 위치해있다.
    회사는 달라졌지만 경비나 집행은 공동으로 진행한다.
    하지만 법인이 달라졌기 때문에 상황은 조금 달라진다.
    이제 다른 법인이 된 은행과 카드사에서
    고객정보를 공유하기 위해서는 공문이 필요하다. ----------------------> API Gateway

  • • API Gateway
      • SOA의 ESB(Micro-service Architecture)의 경량화 버전
      • 미들웨어
        이미지 출처 : https://bcho.tistory.com/948
      • 전체 토폴로지(연결방식)을 hub & spoke 방식으로 변환하여 서비스 간 호출을 단순화(연동의 효율화)

MSA 장단점

• MSA 장점
  • 배포
    • 필요한 부분만 부분 배포 가능
  • 확장성
    • 부하가 많은 서비스만 확장 가능
  • 컴포넌트 별로 팀을 독립적으로 운영가능
    • 컨웨이의 법칙
    • "소프트웨어의 구조는 그 소프트웨어를 만드는 조직의 구조와 일치한다."

• MSA 단점

  • 성능

    • 마샬링 오버해드
      • XML/JSON <-> Java Object
    • 네트워크 부하 -> 시간 지연

  • 메모리

    • 메모리 효율성이 떨어짐

  • 테스팅 어려움

  • 서비스간 트랜잭션 처리

    • 커밋과 롤백처리
      • XA() 분산 트랜잭션 필요

  • 분산형 거버넌스 (Governance)

    • 시스템을 개발하는 조직의 구조와 프로세스가 변화해야 한다.

  • API Gateway로 커버한다.

MSA 현재 상황

• 구현기술

  • JSON-RPC(text) -> gRPC(binary기반)

• 트랜잭션

  • Local -> Global(분산) Transaction
  • Commit/Rollback -> 2Phase Commit(2PC)

• API 게이트웨이

  • Kong -> Netflix OSS(zuul)
  • 배달의 민족, 쿠팡, …

• 스프링 클라우드 vs Kubernaetes

결론? 스프링 빈은 분산 컴포넌트 기술이다.
현재 과정은 Spring Bean을 배우고 있지만 결국 흐름에 따라 우리는 Spring MSA를 지향하게 될 것이다!
MSA는 따로 또 같이!
객체지향 -> 컴포넌트 -> 분산 컴포넌트 -> Spring Bean -> Spring MSA

더 공부하면 좋을 글

• 대용량 웹서비스를 위한 마이크로 서비스 아키텍쳐의 이해

TIP

• Enterprise가 붙으면 서버에서 돌아간다는 거임.
• Spring 이전에는 EJB를 만들어서 사용했다.
• MSA에서 가장 중요한 것은 API Gateway의 퍼포먼스
• API Gateway도 컴포넌트다!
• 스프링으로 Zuul을 연동해서 뭘 해보면...?