MSA에서 말하는 '느슨한 결합'이란?

 

📜서론

MSA를 공부하는 과정에서 느슨한 결합(Loose Coupling)이라는 개념을 여러 번 접하게 되었습니다.

"서비스 간 결합도를 낮춘다."
"서비스 간 의존성을 낮춘다."
"서비스 간 에러가 전파되지 않는다."

 

이처럼 다양한 표현이 등장하다 보니 다소 혼란이 왔습니다.

그래서 이번 글에서는 MSA에서 말하는 서비스 간 느슨한 결합의 정확한 의미와 MSA가 이를 어떻게 실현하는지에 대해 살펴보려고 합니다.

 

 

"서비스 간에는 최소한의 종속성을 가진다"

MSA에서는 각 서비스가 독립적으로 동작해야 하므로, 서비스 간의 종속성을 최소화하는 것이 핵심입니다.
즉, 하나의 서비스가 변경되더라도 다른 서비스에 영향을 주지 않는 구조를 가져야 합니다.

 

최소한의 종속성이란 무엇인가?

"최소한의 종속성"이란, 서비스 간 직접적인 의존성을 줄이고 독립성을 유지하는 것을 의미합니다.
즉, 한 서비스가 다른 서비스의 상태나 내부 구현을 알 필요 없이 동작할 수 있어야 합니다.

 

사실 이렇게만 들었을때는 대략적으로 느낌은 오지만 그래서 실제로 어떻게 낮춘다는 것인지 확실하게 이해하지 못하였습니다. 이제는 실제로 어떻게 서비스간에 최소한의 종속성을 갖게하는지에 대해 살펴보겠습니다.

 

살펴보기전에 이번글에서 반복적으로 나오는 '결합'이란 단어를 생각해보겠습니다.

 

강한결합🆚약한 결합

 

공장에서 더블 비얀코 아이스크림을 제조합니다.

그러기 위해서는 " 아이스크림 받침 + 아이스크림 + 뚜껑 " 이 모든게 있어야 더블 비얀코가 완성되어 팔수있습니다. 
공장에서 제조할 수 있는 방식은 두가지가 있을 수 있습니다.

 

첫번쨰 방법은, 아이스크림 받침을 만들고, 아이스크림을 만든뒤에, 뚜껑을 제작하여 만들 수 있습니다. 

이때 레일이 고장나면 어떻게 될까요? 모든 제작이 멈추게 됩니다. 

 

 

 

두번째 방법은 각각의 레일 위에 두고 재작하는 방법입니다. 이렇게 됐을 때 뚜껑 레일이 고장나면 어떻게 될까요? 뚜껑 제작만 멈추고 다른 레일은 정상적으로 계속해서 제작을 합니다. 이렇게 되면 나중에 뚜껑 레일만 늘려서 더 만들 수 도있고, 다른 레일들은 쉬고 있을 수 있습니다.
실제로 아이스크림 제작시간이 뚜껑 제작보다 오래 걸릴테니깐 미리 만들어 놓을 수 도있겠죠? 

두가지 차이를 아시겠나요? 위에는 강한결합을 의미하고, 밑에는 약한 결합을 의미합니다.

하나의레일로만 동작한다면 모든 재료들에 영향이 가지만, 각각의 레일로 동작한다면 특정 고장난 레일의 재료에만 영향이 가죠.

 

MSA는 바로 약한 결합을 하기위해 고안된 방식입니다. 그렇다면 MSA는 어떻게 약한 결합을 할까요?

 

 

 

1. 서비스 간 직접적인 HTTP 호출을 최소화  
 

❗[나쁜 예시: 강한 결합]

  Order-service → Payment-service (직접 HTTP 호출)

 

🚨문제점

• Payment-service가 다운되면 Order-service도 정상적으로 동작할 수 없음
• Payment-service의 API가 변경되면, Order-service도 함께 수정해야 함
• 하나의 서비스에 장애가 발생하면, 다른 서비스로도 장애가 전파됨

이처럼 한 서비스가 다른 서비스의 상태와 구현 방식에 직접적으로 의존하면, 결국 모든 서비스가 서로 얽혀버려 변경이 어려워지고 그렇게 모든 서비스가 다운됩니다.

 

' 그런데 그건 비동기도 똑같은거 아닌가? ' 라는 생각이 드실수도 있습니다. 아래는 비동기 통신 방식에 대한 설명입니다.

 

Order-service → 메시지 큐(RabbitMQ, Kafka) → Payment-service (비동기 메시징)

Order-service가 결제 요청을 메시지 큐에 넣고 바로 다음 작업을 수행함
Payment-service는 메시지 큐에서 요청을 가져와 결제를 처리함

 

장점

• Payment-service가 다운되더라도 Order-service는 정상적으로 주문을 처리할 수 있음
• Payment-service가 다시 살아나면, 메시지 큐에 쌓인 요청을 순차적으로 처리할 수 있음(이때, 결제처리하면됨)
• Payment-service의 내부 구현이 바뀌더라도 Order-service에는 영향을 주지 않음

 

차이를 아시겠나요? 비동기 방식에서는 Payment-service가 다운되더라도 일단 Order-service를 정상적으로 처리하고 후에 다시 Payment-service가 살아나면 그때 처리하는게 가능합니다. 즉, Payment-service의 장애가 Order-service에게까지 전파되지 않습니다.

💡물론 동기방식의 통신에서 장애 전파 위험등은 서킷브레이커등을 활용해 해결할 수 있습니다. 하지만 서킷 브레이커는 단순히 장애를 감지만 할 뿐 실패한 요청을 보존할 방법이 없습니다.

 

---

2. 서비스 간 DB를 분리

MSA에서는 각 서비스가 독립적으로 동작해야 합니다.

이를 위해 각 서비스는 자신만의 데이터베이스(DB)를 가져야 합니다. 

즉, 서비스 간 DB를 공유하지 않는 것이 핵심 원칙입니다.

 

왜 서비스 간 DB를 분리해야 할까?

 

[나쁜 예시: 단일 DB를 공유하는 경우]

Order-service, Payment-service → 하나의 DB 사용

🚨문제점

• 결합도가 높아짐 → Payment-service가 DB를 변경하면 Order-service도 영향을 받음
• 확장성이 낮음 → 특정 서비스에 부하가 걸리면, 다른 서비스에도 성능 문제가 발생할 수 있음
• 장애 전파 가능성 → 하나의 서비스가 DB 성능을 과도하게 사용하면, 전체 시스템이 느려질 수 있음

[좋은 예시: 서비스별 독립적인 DB 사용]

Order-service → Order-DB
Payment-service → Payment-DB

😊 장점

• 서비스 간 완전한 독립성 보장 → 한 서비스의 변경이 다른 서비스에 영향을 주지 않음
• 확장성 향상 → 각 서비스가 자신의 DB를 최적화할 수 있음
• 장애 격리 가능 → 특정 서비스가 장애를 일으켜도 다른 서비스의 DB에는 영향 없음

계속해서 결합도, 장애전파 같은 단어가 반복된다는 것을 느끼셨나요? 

정리하자면 하나의 서비스에서 DB에 오류를 발생시키면, 다른 모든서비스에 영향이 갑니다. 또는 DB를 수정할경우에도 모든 서비스에 영향을 미치게 됩니다.

 

깊게 생각하지 않아도 사실 다른 서비스에게 영향을 끼치지 않기 위해서 힘들게 서비스를 분리시켜놨는데  DB를 공유하면 의미가 없어집니다. 특정 서비스가 DB 망가뜨리면 다른 서비스도 와르르 

 

---

3. API 게이트웨이를 활용하여 서비스 간 결합도를 낮춘다

MSA에서는 각 서비스가 독립적으로 동작해야 하지만,
클라이언트(웹, 모바일 앱 등) 입장에서는 여러 개의 서비스를 직접 호출하는 것이 비효율적입니다.

또한, 각 서비스의 상태를 클라이언트가 직접 확인해야 한다면, 서비스 간 결합도가 높아지는 문제가 발생합니다.

이를 해결하기 위해 API 게이트웨이를 활용합니다

 

 API게이트웨이는 클라이언트 편하기 위해 사용하는거 아니야?
-> 클라이언트도 서비스다. 즉, 클라이언트 서비스와 MSA서비스간 결합도를 낮춘다.

 

API 게이트웨이가 서비스 간 결합도를 낮추는 이유

클라이언트 → API 게이트웨이 → 개별 서비스 호출

장점
1. 클라이언트가 개별 서비스의 상태를 몰라도 됨

• API 게이트웨이가 개별 서비스의 상태를 모니터링하고, 일부 서비스가 다운되어도 일관된 응답을 제공할 수 있음.
• 예를 들어, Order-service는 정상인데 Payment-service가 장애가 발생했다면?
  → API 게이트웨이가 Payment-service의 응답을 캐싱된 데이터로 대체하거나,
  "현재 결제 처리가 지연되고 있습니다."와 같은 우회 응답을 줄 수 있음.

2. 서비스 장애 시 중앙에서 예외 처리 가능

• 클라이언트가 개별 서비스의 장애 여부를 확인할 필요 없이,
  API 게이트웨이가 이를 감지하고 적절한 응답을 줄 수 있음.
• 예를 들어, 일부 서비스가 다운되었을 경우 게이트웨이가
  "일부 서비스가 현재 이용 불가능합니다."라는 공통 메시지를 반환하도록 설정할 수 있음.

3. Fallback(대체 응답) 처리 가능

• 게이트웨이를 통해 일부 기능이 동작하지 않아도 전체 서비스가 정상 작동하도록 설계 가능
• 예를 들어, 주문서비스가 장애가 발생해도,
  API 게이트웨이가 "현재 주문 서비스를 이용할 수 없습니다."라는 기본 메시지를 반환하도록 할 수 있음.

즉, API 게이트웨이를 활용하면 클라이언트와 MSA 서비스들 간의 결합도도 낮춰주는 중요한 역할을 합니다.

 

🤠결론: MSA에서 느슨한 결합을 유지하는 핵심 원칙

1. 직접적인 HTTP 호출을 최소화하고, 메시지 큐 기반 비동기 통신을 활용한다.
2. 서비스별 독립적인 DB를 운영하여, 데이터 종속성을 줄인다.
3. API 게이트웨이를 도입하여, 서비스 간 결합도를 낮추고 장애 전파를 방지한다.

 

이 세 가지 방법을 적용하면, 서비스 간 독립성이 보장되어 유지보수성이 향상되고, 장애 발생 시 서비스 전체에 영향을 주지 않으며, 확장성과 유연성이 뛰어난 MSA 구조를 구축할 수 있습니다.