[MSA] MSA가 어려운 이유

IPC (Inter-Process Communication)

출처 : https://nginxstore.com

 

MSA 환경에서 IPC는 여러 마이크로서비스 간에 효과적인 통신을 지원하는 중요한 측면입니다. MSA는 서로 독립적으로 배포되고 실행되는 여러 마이크로서비스로 구성되어 있으며, 이러한 서비스들은 특정 작업을 수행하기 위해 상호 작용해야 합니다.

 

IPC 고려사항

1. HTTP/RESTful API

HTTP 기반의 RESTful API는 가장 흔하게 사용되는 IPC 방법 중 하나입니다. 각 마이크로서비스는 HTTP 요청을 통해 다른 서비스에 요청을 보내고, RESTful 엔드포인트를 통해 데이터를 주고받습니다. 이러한 방식은 표준화되어 있고, 다양한 언어 및 플랫폼 간에 상호 운용성을 제공합니다.

 

2. Message Brokers

메시지 브로커는 이벤트 기반의 통신을 지원하는데, 대표적으로 RabbitMQ나 Apache Kafka가 있습니다. 마이크로서비스는 메시지 브로커를 통해 비동기적으로 통신하고, 이벤트에 대한 메시지를 주고받습니다. 이는 느슨한 결합과 확장성을 제공하여 서비스 간의 의존성을 최소화합니다.

 

3. gRPC

gRPC는 구글에서 개발한 RPC(Remote Procedure Call) 프레임워크로, MSA 환경에서 사용하기에 적합합니다. Protocol Buffers를 기반으로 하며, 다양한 언어에서 지원되는 강력한 기능을 제공합니다. 이를 통해 서비스 간 효율적이고 강력한 통신이 가능합니다.

 

4. Service Mesh

서비스 메시는 마이크로서비스 간의 통신을 추상화하고 관리하는 도구로, 예를 들어, Istio나 Linkerd가 있습니다. 이를 통해 보안, 모니터링, 로깅 등을 통합적으로 처리할 수 있습니다.

 

Transactions

MSA 환경에서 트랜잭션 관리는 전통적인 모놀리스 아키텍처와는 다르게 도전적인 과제로 인식됩니다. 여러 개의 독립적으로 배포되고 운영되는 마이크로서비스들 간에 데이터 일관성을 유지하려면, 트랜잭션 처리에 대한 접근을 신중하게 고려해야 합니다.

 

Transactions 고려사항

1. 분산 트랜잭션의 어려움

분산 환경에서 트랜잭션을 관리하는 것은 어려운 문제입니다. 모놀리스 시스템에서는 데이터베이스 트랜잭션으로 간단하게 해결할 수 있는 경우가 많았지만, MSA에서는 각각의 서비스가 자체 데이터베이스를 갖고 있고, 이들이 독립적으로 운영되기 때문에 분산 트랜잭션을 다뤄야 합니다.

 

2. 느슨한 결합

MSA는 각각의 마이크로서비스가 느슨하게 결합되어 있는 특성을 가지고 있습니다. 이는 하나의 트랜잭션으로 여러 서비스 간의 작업을 감싸는 것이 어려워진다는 것을 의미합니다. 서로 독립적으로 실행되는 서비스들 간에 트랜잭션을 유지하기 위해선 높은 수준의 조율이 필요합니다.

 

3. 보상 트랜잭션과 롤백

분산 시스템에서 트랜잭션 오류가 발생할 경우, 롤백이나 보상 트랜잭션을 통해 문제를 해결할 수 있습니다. 하지만 이러한 메커니즘을 설계하고 구현하는 것은 복잡하며, 모든 서비스에서 일관된 방식으로 이를 다루어야 합니다.

 

4. 이벤트 소싱 패턴

이벤트 소싱 패턴을 통해 이벤트를 통해 변경 사항을 전파하고, 이벤트 핸들러를 사용해 데이터 일관성을 유지하는 방법도 있습니다. 이러한 방식은 비동기적인 통신을 통해 데이터의 변경 사항을 전파함으로써 트랜잭션의 일관성을 유지할 수 있습니다.

 

5. Saga Pattern

Saga 패턴은 여러 트랜잭션 단계로 분리된 트랜잭션 관리 방법입니다. 각 마이크로서비스는 자체 트랜잭션을 관리하며, 실패 시 보상 트랜잭션을 통해 데이터 일관성을 보장합니다.

 

Monitoring

MSA 환경에서의 모니터링은 전통적인 모놀리스 아키텍처보다 더욱 중요하며 도전적인 과제입니다. MSA에서는 여러 마이크로서비스가 독립적으로 배포되고 운영되기 때문에, 각 서비스의 상태와 성능을 실시간으로 감시하는 것이 필수적입니다.

 

Monitoring 고려사항

1. 다양한 서비스의 모니터링

MSA에서는 여러 개의 서비스가 동시에 운영되므로, 각각의 서비스의 상태와 성능을 모니터링해야 합니다. 서비스 간의 의존성 및 통신을 모니터링하여 문제가 발생하는 경우에 신속하게 대응할 수 있도록 해야 합니다.

 

2. 분산된 로깅

서비스가 분산되어 있기 때문에 중앙 집중식 로깅이 필요합니다. 각 서비스에서 발생하는 로그를 통합적으로 수집하고 분석하여 이슈를 식별하고 해결할 수 있어야 합니다. 대표적인 로깅 시스템으로는 ELK(Elasticsearch, Logstash, Kibana) 스택이나 Fluentd와 같은 도구들이 있습니다.

 

3. 분산 추적

분산 시스템에서 각각의 트랜잭션과 이벤트를 추적하는 것이 중요합니다. 이를 통해 특정 이벤트의 전체적인 흐름을 이해하고, 병목 현상이나 지연이 발생하는 부분을 찾을 수 있습니다. Zipkin, Jaeger와 같은 분산 추적 도구를 활용할 수 있습니다.

 

4. Metric 수집과 대시보드

서비스의 성능 지표 및 상태 정보를 실시간으로 수집하고 대시보드를 통해 시각적으로 확인할 수 있어야 합니다. Prometheus와 Grafana 등의 도구를 사용하여 서비스의 Metric을 수집하고 시각적으로 나타낼 수 있습니다.

 

5. 이벤트 모니터링

이벤트 기반 아키텍처에서는 이벤트의 발생과 처리를 모니터링하는 것이 중요합니다. 이벤트 큐의 상태 및 이벤트 핸들러의 동작을 추적하여 시스템 전반적인 이벤트 흐름을 모니터링해야 합니다.

 

6. 자동화된 알람 및 대응

이상 상태를 감지하고 자동으로 알람을 발생시키는 모니터링 시스템을 구축해야 합니다. 또한, 이를 기반으로 자동화된 대응 메커니즘을 설정하여 장애 발생 시 신속하게 대응할 수 있도록 해야 합니다.