▶️ 통신 방식 (TCP, SOAP, gRPC, GraphQL, Websocket)
TCP (Transmission Control Protocol)
- TCP는 인터넷에서 데이터를 안정적으로 전송하기 위한 프로토콜 중 하나이다.
- 연결 지향 프로토콜로, 데이터 패킷을 손실하지 않고 순서대로 전달한다.
- 주로 웹 브라우징, 이메일, 파일 전송 등의 네트워크 통신에서 사용됩니다.
SOAP (Simple Object Access Protocol)
- SOAP는 웹 서비스 간에 데이터를 교환하기 위한 프로토콜 및 메시지 형식이다.
- XML 기반으로 데이터를 패킹하고, HTTP, SMTP, TCP 등의 다양한 프로토콜을 통해 데이터를 전송한다.
- 주로 기업 간 데이터 통신 및 웹 서비스에서 사용된다.
- 동작 원리 - 서비스 요청자가 SOAP로 인코딩하여 웹 서비스 요청을 서비스 제공자에게 전달하며, 서비스 제공자는 이를 디코딩하여 적절한 서비스 로직을 수행시켜서 결과를 얻고, 그 결과를 다시 SOAP로 인코딩하여 반환한다.
- 참고글 https://tychejin.tistory.com/148
gRPC (gRPC Remote Procedure Call)
- gRPC는 Google에서 개발한 원격 프로시저 호출(RPC) 프레임워크이다.
- Protocol Buffers(Protobuf)를 사용하여 데이터 직렬화하며, HTTP/2 기반으로 효율적인 통신을 제공한다.
- 주로 마이크로서비스 아키텍처와 클라이언트-서버 간 통신에 사용된다.
GraphQL
- GraphQL은 데이터 쿼리 언어로, 클라이언트가 필요한 데이터를 정확하게 요청할 수 있도록 한다.
- REST API와 비교하여 더 유연하며, 클라이언트의 요구에 따라 데이터를 동적으로 가져올 수 있다.
- 주로 웹 및 모바일 애플리케이션에서 데이터 요청 및 전송에 사용됩니다.
WebSocket
- WebSocket은 양방향 통신을 지원하는 프로토콜로, 실시간 데이터 전송에 적합하다.
- HTTP 기반의 연결을 유지하며, 클라이언트와 서버 간에 데이터를 주고받을 수 있다.
- 실시간 채팅, 온라인 게임, 주식 시세 업데이트 등 실시간 애플리케이션에 사용된다.
▶️ 모놀리식 아키텍처 vs 서비스 지향 아키텍처 vs 마이크로서비스 아키텍처
모놀리식 아키텍처
- 소프트웨어의 모든 구성요소가 한 프로젝트에 통합 되어 있는 형태.
- 모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 한다.
- 장점
- 어떤 기능(서비스)든지 개발되어있는 환경이 같아서 복잡하지 않다.
- 쉽게 고가용성 서버 환경을 만들 수 있다. (같은 애플리케이션으로 하나 더 생성)
- End-to-End 테스트가 용이하다. (MSA의 경우 테스트에 필요한 서비스들을 모두 동작시켜야 한다.) - 단점
- 한 프로젝트의 덩치가 너무 커져서 애플리케이션 구동시간이 늘어나면 빌드, 배포 시간도 길어진다.
- 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야한다.
- 많은 양의 코드가 몰려있어 개발자가 모두를 이해할 수 없고 유지보수도 힘들다.
- 일부분의 오류가 전체에 영향을 미친다.
- 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기가 까다롭다.
서비스 지향 아키텍처(SOA)
- 서비스라는 소프트웨어 구성 요소를 사용해 비즈니스 애플리케이션을 생성하는 소프트웨어 개발 방식
- 각 서비스는 비즈니스 기능을 제공하며, 플랫폼과 언어를 넘나들며 서로 통신할 수 있다.
- 개발자는 SOA를 사용해 서로 다른 시스템 내의 서비스를 재사용하거나 독립적인 여러 서비스를 결합하여 복잡한 태스크를 수행한다.
SOA는 서비스를 개발하고, 이를 최대한 재가용한다. 재가용성이 늘어나면 서비스간 결합도가 늘어나기 때문에 아주 작은 서비스 단위를 독립적으로 나누어 구성함으로써 탄력적이고 유연한 구조를 가질 수 있다.
- 장점
- SOA는 서비스 단위로 기능을 분리하므로 이러한 서비스는 여러 프로젝트나 응용 프로그램에서 재사용할 수 있다. 이로써 개발 시간과 비용을 절감할 수 있다.
- 시스템의 서비스를 독립적으로 개발하고 업데이트할 수 있으므로 시스템의 일부를 변경하더라도 전체 시스템에 큰 영향을 미치지 않는다.
- SOA는 여러 시스템 간의 통합을 용이하게 만들어준다. 서비스 간의 표준화된 인터페이스를 사용하면 다양한 시스템을 쉽게 연결할 수 있다.
- 필요에 따라 서비스를 확장할 수 있으므로 시스템의 성능을 향상시키기 위해 추가 리소스를 할당하기 용이하다. - 단점
- 다양한 서비스 간의 관계와 의존성을 다루기 때문에 복잡성이 증가할 수 있다. 이로 인해 설계, 구현, 유지보수가 어려울 수 있다.
- 서비스 간의 통신이 추가 오버헤드를 초래할 수 있으며, 효율적인 메시지 전달이 중요하다. 부적절한 설계나 느린 서비스 호출은 성능 문제를 초래할 수 있다.
- 서비스 간의 통신은 보안 문제를 야기할 수 있으며, 적절한 보안 메커니즘을 구현하려면 노력이 필요하다.
마이크로서비스 아키텍처(MSA)
- 하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처
- 각 마이크로서비스는 상호 통신이 가능하며 이를 통해 전체 서비스를 구성한다. - 서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행한다. - 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다.
- 장점
- 기능별로 마이크로서비스를 개발하고, 작업 할당을 서비스 단위로 하면 개발자가 해당 부분을 온전히 이해할 수 있다.
- 새로 추가되거나 수정사항이 있는 마이크로서비스만 빠르게 빌드, 배포가 가능하다.
- 해당 기능에 맞는 기술, 언어 등을 선택하여 사용할 수 있다.
- 일부분의 오류가 있으면 해당 기능에만 오류가 발생하고 그 부분만 빠르게 고쳐서 정상화가 가능하다. - 단점
- 무엇보다 관리가 힘들다. 작은 여러 서비스들이 분산되어 있기 때문에 모니터링이 힘들다.
- 서로를 호출하여 전체 서비스가 이루어지기 때문에 무조건 다른 서비스를 호출하는 코드가 추가되는데 이부분이 모놀리식 아키텍쳐의 개발보다 까다롭다.
- 통신관련 오류가 잦을 수 있다. 마이크로 서비스들끼리 계속하여 통신을 하다보니 모놀리식 아키텍쳐에 비해 통신관련 오류가 잦다.
- 테스트가 불편하다. End-to-End 테스트를 위해 UI, Gateway 등등 여러개의 마이크로 서비스를 구동시켜야 한다.
▶️ TCP vs UDP
연결 지향 vs 비연결
- TCP는 연결 지향 프로토콜이다. 즉, 데이터 전송이 시작되기 전에 두 장치 간에 연결을 설정한다. 이 연결에는 오류 감지, 수정 및 흐름 제어를 위한 메커니즘이 포함되어 있으므로 데이터 신뢰성이 보장된다. TCP는 데이터가 올바른 순서로 도착하도록 보장합니다.
- UDP는 비연결 프로토콜이다. 즉, 데이터를 보내기 전에 연결을 설정하지 않는다. 순서에 대한 보장 없이 단순히 데이터 패킷을 대상으로 보낸다.
신뢰도
- TCP는 내장된 오류 감지 및 수정 메커니즘으로 인해 신뢰성이 높다. 손실되거나 손상된 패킷을 재전송하고 데이터가 올바르게 전달되도록 보장한다.
- UDP는 안정성을 보장하지 않는다. 손실된 패킷을 재전송하지 않으며 필요한 경우 오류 감지 및 수정을 처리하는 것은 애플리케이션 계층에 달려 있다.
속도와 효율성
- TCP는 연결 설정, 오류 처리 및 흐름 제어와 관련된 추가 오버헤드로 인해 일반적으로 UDP보다 느리다. 그러나 이러한 오버헤드는 데이터 무결성과 안정성을 보장한다.
- UDP는 연결 설정 및 오류 복구에 대한 오버헤드가 없기 때문에 TCP보다 빠르고 효율적이다. 비디오 스트리밍이나 온라인 게임과 같이 속도가 중요한 실시간 애플리케이션에 자주 사용된다.
사용 사례
- TCP는 웹 탐색, 이메일, 파일 전송(FTP) 및 원격 데스크톱 연결과 같이 안정적이고 순서화된 데이터 전달이 필요한 애플리케이션에 적합하다.
- UDP는 온라인 게임, 화상 회의, VoIP(Voice over IP), DNS(Domain Name System) 및 스트리밍 미디어와 같이 속도를 우선시하고 간헐적인 데이터 손실을 허용할 수 있는 애플리케이션에 선호된다.
▶️ TCP 동작 원리
▶️ 데이터 교환 방식
CQRS
- https://mslim8803.tistory.com/73
- 데이터 저장소로부터의 읽기와 업데이트 작업을 분리하는 패턴
- 어플리케이션의 퍼포먼스, 확장성, 보안성을 극대화
- CQRS 패턴을 통해 만들어진 시스템의 유연성을 바탕으로, 시간이 지나면서 지속적으로 시스템을 발전시켜나갈 수 있으며, 여러 요청으로부터 들어온 복수의 업데이트 명령들에 대한 충돌도 방지할 수 있다.
MQTT
AMQP
▶️ 최종 프로젝트에서 프레임워크를 사용하지 않은 이유
- 현재 최종 프로젝트에서 MSA를 적용하며 기존에 사용했던 프레임워크인 express를 사용하지 않고 있다.
- 일단 적용한 아키텍처도 새로운 도전이고, 이에 따른 여러 고려 사항(서비스 간 통신, 데이터 관리, 보안, 모니터링 등)도 있기 때문에, 프레임워크를 사용하는데 추가 공부를 하는 것보다 MSA에 대한 정확한 이해도를 갖는게 중요하다 생각하여 기존 node.js에 내장된 모듈을 최대한 이용하여 진행하기로 했다.
express는 TCP 기반의 프레임워크이다.
- express는 node.js를 기반으로 하며, 기본적으로 HTTP 프로토콜을 사용하여 웹 서버를 구축하고 관리한다. HTTP 프로토콜은 TCP/IP 프로토콜 스택 위에서 동작하므로 express를 사용하면 TCP 기반의 서버를 만들게 된다.
▶️ 최종 프로젝트에서 TCP를 사용하는 이유
효율적인 통신을 위해
- TCP는 신뢰성 있는 연결 기반 프로토콜로, 데이터 전송 중 손실이나 중복을 최소화할 수 있다. MSA에서 서비스 간 통신이 중요한데, 이러한 신뢰성은 중요하다.
보안을 위해
- TCP는 데이터를 암호화하고 보안을 강화하기 위한 다양한 기능을 지원한다. MSA에서는 서비스 간 데이터 보안이 중요하며, TCP를 통해 안전한 통신을 구축할 수 있다.
▶️ 최종 프로젝트에서 UDP를 사용하지 않는 이유
신뢰성 부족
- UDP는 데이터를 보낸 후 수신측에서 어떤 응답도 보내지 않으며, 패킷 손실이나 순서 변경이 발생할 수 있다. 이것은 MSA에서 서비스 간 통신에 문제가 될 수 있으며, 특히 데이터 무결성과 신뢰성이 중요한 경우에는 TCP보다 적합하지 않을 수 있다.
패킷 손실
- UDP는 패킷 손실을 처리하지 않으므로, 전송 중에 데이터가 손실될 수 있다. 이것은 MSA에서 중요한 데이터를 전송할 때 문제가 될 수 있으며, 손실을 감지하고 복구하기 위한 메커니즘을 직접 구현해야 할 수 있다.
순서 보장 문제
- UDP는 데이터 패킷의 순서를 보장하지 않으므로, 서비스 간 통신에서 데이터 패킷의 순서가 중요한 경우 문제가 발생할 수 있다. 이러한 순서 문제를 해결하기 위해서는 추가적인 로직과 관리가 필요하다.
보안 문제
- UDP는 데이터를 빠르게 전송하는 데 중점을 두고 있으며, 보안 기능이 제한적이다. MSA 환경에서 보안이 중요한 경우, 추가적인 보안 레이어를 구현하고 UDP 패킷을 안전하게 전송하는 방법을 고려해야 한다.
대역폭 관리
- UDP는 전송 중에 패킷 손실이 발생할 수 있으므로, 대역폭을 효과적으로 관리하기 어려울 수 있다. 이로 인해 네트워크 혼잡 및 성능 저하 문제가 발생할 수 있다.
꾸준히 하자