[MSA]분산 환경(Distributed Environment)에서의 내부 통신

목차

 

분산 환경(Distributed Environment)은 여러 대의 컴퓨터와 네트워크를 연결해 작업을 분산하고,

 

결과는 하나로 모아 마치 하나의 시스템인 것처럼 보이도록 구성된 환경을 말한다.

 

이를 위해 분산된 컴퓨터, 서버, 혹은 노드(및 데이터베이스) 간의 정보 공유를 위한 통신이 반드시 필요한데

 

이 글에선 주로 MSA 관점에서 그 대표적인 방법들의 장단점에 대해 정리한다.

 

참고로 나열 순서는 지난번에 리뷰했던 논문에서 실무자들이 가장 많이 사용한다고 응답한 순서를 따른다.

 

2023.03.31 - [Development/Paper Review] - [MSA]뜬금 논문 리뷰 - j.jss.2022.111521

[MSA]뜬금 논문 리뷰 - j.jss.2022.111521

 

HTTP RESTful API

 

HTTP RESTful API 방식은 서버와 클라이언트가 RESTful API를 통해 통신하며

 

서버 사이의 데이터 통신 역시 RESTful API를 통해 수행하는 것을 가리킨다.

 

기존의 HTTP 프로토콜을 사용하기 때문에 HTTP 통신이 가능한 모든 플랫폼에서 사용 가능하며,

 

이는 분산환경에서도 유용하게 사용되는 이유이기도 하다.

 

계속해서 장점과 단점에 대해 적어보자.

 

• 장점
  
  
  • 직관적이고 유연한 구조
    기존의 방식을 사용하기 때문에 구조가 직관적이고 유연하다. 위에 적었듯 다양한 환경에서 사용 가능하다.
  • 쉬운 구현과 확장성
    URI를 이용해 자원을 식별하기 때문에 분산환경에서도 쉽게 구현 가능하며,
    새로운 리소스의 추가 혹은 기존 리소스의 수정과 삭제가 간단해 확장성이 높다.
  • 무상태성(Stateless)
    상태를 유지하지 않는 특성 덕분에 서버에 부하가 적고,
    만약 서버에 문제가 생긴다 해도 클라이언트 측에 끼치는 영향이 적으며 쉽게 대처할 수 있다.
  • 캐싱
    캐시를 이용해 처리속도 향상과 같은 성능 개선과 서버 부하 감소를 노릴 수 있다.
  • 검색 엔진 최적화
    역시 URI를 이용해 자원을 식별하기 때문에 검색 엔진에서의 노출에 유리하다.
• 단점
  
  
  • 어려운 보안 기능 구현
    Stateless 하기 때문에 인증과 권한 부여 같은 기능을 구현하기 어려울 수 있다.
  • 복잡한 기능 구현의 한계
    간단한 CRUD 기능 구현에는 유리하지만 더 복잡한 기능은 구현이 어렵다.
  • 정해진 명세의 부재
    개발자들 간의 협업을 위해서 미리 API를 만들어야 해 협업에 시간이 소요된다.
  • 결합도 이슈
    서비스의 이름, 위치, 호출 방식 등을 포함한 연결이 필요하기 때문에 결합도를 낮추는데 한계가 있다.
  • 성능 이슈
    위와 같은 장점에도 불구하고 RESTful 방식은 대용량 데이터 처리에는 적합하지 않다.
    이는 HTTP가 TCP/IP를 기반으로 하기 때문인데, TCP/IP의 경우 데이터를 작은 패킷(일반적으론 1500바이트)으로 나눠 전송하기 때문에 대용량 데이터를 전송할 경우 패킷의 수가 급격하게 늘어나 오버헤드가 발생해 성능이 떨어질 가능성이 있다.
    이를 극복하기 위해서는 데이터를 압축하거나, 데이터 전송에는 별도의 프로토콜(FTP, SFTP)을 사용하는 대안 등이 존재한다.

 

Size of Data Packet

 

위에서 잠시 데이터 패킷의 기본 크기가 1500바이트라는 언급이 지나갔다.

 

왜 하필 1500바이트? 이진수로 표현할 때 딱 떨어지는 숫자도 아닌데?

 

궁금해서 잠깐 짚고 넘어간다.

 

이더넷(Ethernet)은 OSI 7 계층 모델에서 물리 계층과 데이트 링크 계층 사이에서 사용되는 프로토콜이다.

 

빠른 전송 속도와 낮은 지연시간, 쉬운 설치 및 유지보수와 그에 따른 저렴한 비용이 장점으로,

 

LAN에서 가장 많이 사용되는 기술이다.

 

갑자기 왜 이더넷이냐면, 이 이더넷에서 사용되는 프레임의 크기가 1518바이트이기 때문이다.

 

이중 이더넷의 MTU(Maximum Transmission Unit)는 1500바이트, 헤더와 푸터 등 오버헤드가 18바이트이며

 

이 최댓값을 맞추기 위해 데이터 패킷의 크기는 일반적으로 1500바이트 이하가 되는 것이다.

 

참고의 참고로, 데이터 패킷의 최소 크기는 오버헤드를 합쳐 64바이트인데,

 

이보다 작으면 충돌 방지 기능이 올바로 작동하지 않는다고 한다.

 

이더넷에서는 충돌을 방지하기 위해 CSMA/CD(Carrier Sense Multiple Access with Collision Detection)라는

 

방식을 사용하는데, 이는 데이터를 전송하기 전에 다른 데이터가 현재 이더넷 채널을 사용하고 있는지 확인하고,

 

만약 다른 컴퓨터가 데이터를 전송하고 있다면 데이터를 전송하지 않고 잠시 기다린 후에 다시 전송을 시도하는 방식이다.

 

이때 다수의 컴퓨터가 한 번에 요청을 보내면 충돌이 발생할 수 있는데, 충돌이 감지되면 해당 컴퓨터는 요청을 잠시 중단하고

 

다시 데이터를 전송하도록 한다.

 

여기서 일반적으로 데이터의 크기가 작을수록 충돌이 발생할 확률이 높아지기 때문에, 데이터 패킷이 64바이트보다 작다면

 

지나치게 잦은 충돌 발생으로 인해 성능 저하가 발생하며 방지 기능이 제 역할을 하지 못할 수도 있다는 뜻이다.

 

 

 

 

RPC(Remote Procedure Call)

 

RPC는 프로그램 간의 통신을 위한 표준화된 프로토콜이다. 클라이언트가 로컬에서 실행되는 메서드(프로시저)를

 

원격에서 호출하고, 서버는 그 결과를 돌려주는 식으로 동작한다.

 

장단점은 아래와 같다.

 

• 장점
  
  
  • 투명성 및 프로토콜 추상화
    개발자는 로컬 메서드를 호출할 때와 동일한 방식으로 원격 메서드를 호출할 수 있다.
    이때 개발자가 특정 프로토콜이나 통신에 대해 알 필요가 없도록 RPC 시스템이 프로토콜을 처리한다.
    즉 RPC는 다양한 프로토콜을 지원하며, 이 덕분에 개발자는 코드의 변경 없이 다른 프로그램의 메서드를 호출할 수 있다.
  • 표준화 및 이식성
    RESTful 방식과 다르게 RPC는 표준화된 프로토콜이다.
    때문에 다른 언어와 플랫폼에서 개발된 프로그램 사이에서도 무리 없이 통신이 가능하다.
• 단점
  
  
  • 보안 문제
    RPC는 인증이나 암호화등의 기능을 제공하지 않으며, 클라이언트-서버의 직접 통신을 요구하기 때문에
    방화벽을 넘지 못하는 문제가 발생한다. 이를 위해 TLS 등의 보안 기능을 직접 사용해야 한다.
  • 대용량 데이터 처리
    RESTful 방식과 마찬가지로 TCP/IP 방식을 사용하기 때문에 대용량 데이터 처리에서 불리하다.
  • 결합도 이슈
    서비스의 이름, 위치, 호출 방식 등을 포함한 연결이 필요하기 때문에 결합도를 낮추는데 한계가 있다.
  • 동기식 처리
    클라이언트는 메서드를 호출한 뒤 결과 반환을 기다린다. 때문에 지연시간 발생 시 프로그램의 실행시간 역시
    길어지게 되며, 이는 물리적 거리가 먼 서버로 요청을 보낼수록 증가할 확률이 크다.
    이와 같이 동기적 호출을 전제로 설계되었기 때문에 비동기 방식을 적용하는 것 역시 쉽지 않다.

 

Message Queue

 

Message Queue는 비동기 메시지 전송 방식을 사용해 서비스 간의 통신을 수행하는 방식이다.

 

이때 메시지를 생성하는 Producer와 소비하는 Consumer가 있으며,

 

당연하게도 각각 큐에 메시지를 넣고, 받아 처리하는 역할을 한다.

 

장단점은 아래와 같다.

 

• 장점
  
  
  • 비동기 처리
    Producer는 메시지를 넣고, Consumer는 즉시 처리가 아닌 가능한 타이밍에 가져와 처리한다.
    이는 Producer/Consumer의 부하 분산과 더불어 서비스 간의 결합도를 낮추는데 유리하게 작용하며,
    동시에 높은 처리량을 보장한다.
  • 간단한 통신
    모든 메시지가 큐에 모여있기 때문에 서비스 간의 통신을 쉽고 간결하게 처리할 수 있다.
  • 고가용성
    큐에 메시지를 넣으면 특정 시스템에서 처리하지 못하더라도 메시지는 유지된다.
    이는 장애가 발생한 시스템에서 처리하지 못한 메시지를 다시 처리할 수 있음, 즉 높은 가용성을 보장한다.
  • 탄력적이고 확장성 좋은 구조
    메시지 큐는 독립적인 기능이나 서비스 추가 및 확장이 쉽다(큐의 개수를 증가시키면 된다).
    또한 프로토콜과 데이터 형식에 제약이 매우 적기 때문에, 다양한 형태의 데이터를 다양한 방식으로 전송할 수 있다.
• 단점
  
  • 구현의 복잡성
    MQ의 구현과 운영은 RESTful과 RPC에 비해 복잡하고 어렵다.
  • 메시지 처리 순서 이슈
    비동기 처리의 특징으로 발행한 메시지의 처리순서를 보장하지 않는다.
  • 처리 실패
    메시지 수신에 성공한 Consumer가 메시지 처리에 실패하면 이를 복구하기 위한 메커니즘이 기본적으론 없다.
  • 데이터 크기
    위의 두 방법만큼은 아니지만 MQ에도 데이터 크기 제한이 존재한다.
    그리고 데이터 크기 제한을 올리더라도 그 크기가 너무 크면 시스템에 영향을 미치기 쉽다.
    커다란 데이터를 전송할 때는 다른 방식을 고려하는 것이 좋다.