견고한 MSA

MSA의 비싼 아키텍처가 유행하게 되면서 서비스의 회복성(resilence)의 중요성은 점점 대두되고있다.Spring Cloud에서는 개발자들이 회복성있는 마이크로 서비스를 구현할 수 있는 몇몇 기능을 제공한다. 몇몇 기능 중 대표적으로 Retry와 Fallback을 소개할 예정이다. 이 둘은 견고한 시스템에서 우아하게 실패들을 처리할 수 있는 중요한 구성 요소이다.

 

들어가기에 앞서....

 

서론

 - 마이크로 서비스의 필요성?

분산 시스템에서는 마이크로 서비스들이 agility, scalability, maintainability를 중요 요소로 여겨진다. 이러한 장점들 덕에 마이크로서비스가 인기를 얻었다고해도 과언이 아니다. 하지만 이 요소들은 시스템을 위태롭게하는 요소중에 하나이기도 하다. 때문에 마이크로 서비스들에게 resilence를 보장하도록하는 것은 당연하고 이것이 견고한 시스템을 만들기 위한 기반이다.

 

- 분산 환경

분산이 마이크로서비스의 핵심 원리이다. 모든 서비스가 독립적으로 maintain, scale, deploy될 수 있다. 그리고 이것들은 네트워크 통신에 강력하게 의존하여 응집력을 유지한다.

하지만 네트워크는 예측불가능한 영역이다. 지연시간이 급증할 수도, 패킷 손실, 완전 중단은 드문 발생한다. 때문에 견고한 마이크로 서비스에서는 네트워키 이상을 가정한 상태로 개발되어야한다. 더 나아가 monolithic 아키텍쳐에서는 모듈들이 in-memory로 소통한다. 하지만 마이크로 서비스에서는 네트워크 전반에서 잠재적인 실패의 경우를 포함한다. Http requests, message queue 그리고 event-driven은 모두 분산 시스템의 문제를 가지고 있다.

 

- 연속적인 실패

내부적으로 연결된 환경에서는 한 가지 서비스에서 장애가 발생하면 연쇄적으로 장애가 발생하게 됩니다.

때문에 A 서비스가 B서비스에 의존하고 C 서비스까지 의존을 한다면, 만약 C가 실패시에는 올바르게 에러가 핸들링되지 않고 A,B서비스 모두 영향을 받게된다. 그리고 시스템이 무너지게된다. 이러한 Domino Effect를 방지하기 위해서는 circuit breaking과 같은 기술이 필요하다. (지금 우리 시스템은 domino effect가 만연하다... 때문에 이 전사적으로 해결할 필요가 있을 듯하다.)

 

- 외부 의존

가끔 마이크로 서비스가 독립적이지 않을 때가 있다. 바로 외부 시스템(서드 파티/ 데이터베이스)에 의존하는 경우가 있다. 

만약 마이크로 서비스가 외부 서드 파티 서비스에 의존하고 있다면, 해당 서비스가 down되었을 경우 우리 서비스도 함께 다운되게 된다. 견고한 아키텍쳐를 디자인한다는 것은 이러한 이벤트들에 대한 잠재적인 준비를 하는 것이다. 예를 들에 caching이 하나의 방법이 될 수 있다. 또는 fallback도 하나의 방법이 될 수 있다.  그래도 DB는 신뢰할 수 있는 요소 중 하나지만 오류가 없는 것은 아니다. Connection Pool exhaustion, slow queries, full-scale database outages(데이터 베이스 대규모 중단)는 마이크로 서비스가  중단될 수 있다. 이런 경우에는 db failover mecahnisms, read replicas, query optimization 등의 해결 방법이 필요하다.

 

- Scalability and Load

마이크로 서비스의 핵심 이점 중 하나는 바로 scale individual services based on demand이다.  하지만 이 역시 몇몇 고려사항들이 있다. 그 중 하나가 갑작스러운 트래픽 스파이크다. 이것이 올바르게 핸들링되지 않으면 서비스가 죽게된다. Load balancer / auto--scaling policies / rate limiting이 우아하게 트래픽이 몰리는 것을 조절할 수 있는 툴이다. 또한 서비스가 확장됨에 따라 메모리 leak이나 비효율적인 리소스 사용이 여러 인스턴스로 확대되어 시스템 전체에 문제가 발생할 수 있으니 조심할 필요가 있다. (이 역시 우리 시스템에서 조심해야 할 부분 중 하나인 것 같다.. 지속적인 모니터링과 서비스 분산시에는 충분한 근거가 필요한 것 같다..)

 

이렇게 마이크로 서비스가 가진 타고난 문제들로 인하여 개발자들에게 기능 뿐만이 아니라 역경 속에서도 회복성 있고 안정적인 시스템을 설계하는 것이 점차 중요해지고 있다. (이것들이 오늘날 백엔드 개발자들의 핵심 역량이 될 듯 하다!)

 

 

 

 

MSA의 특징을 정리하다보니 모두 알고 있었지만, 우리 서비스에서 부족한 부분들이 몇몇 보이고 있다. 그것을 중점으로 해결해 나아가는 것도 좋을 것 같다. 

 

정리 

1. domino effect 없애기 - fallback / retry를 통하여 

2. 새로운 분산 환경 만들때에는 충분한 근거가 있을 때에만 만들기