카카오페이 테크블로그의 MSA 환경에서 네트워크 예외를 잘 다루는 방법를 읽고 쓰는 글입니다.
들어가기 앞서
지금 진행하는 프로젝트에서 MSA를 사용해보고 있는데 이와 관련된 인사이트를 얻기 좋은 주제라는 생각에 글을 정리해봤습니다. 참고로 제 프로젝트는 MSA가 전혀 필요하지 않는 작은 규모로 단순히 MSA 기술이 어떤건지 공부하고 한번 써보고 싶다는 목적을 위해 진행하는 프로젝트입니다. (MSA를 공부하고 있을 뿐 MSA를 잘 이해하고 있거나 능숙히 다룬다는 게 아님을 얘기하고 싶었습니다.)
MSA환경
아래 그림에서 잘 보여주듯 MSA환경에서는 각 서비스마다 DB가 따로 존재합니다. 그리고 이 DB의 일관성을 잘 보장하는 것이 이번 글의 핵심입니다.
MSA환경이 기존의 모놀리식 아키텍처와 다른 점은 데이터를 주고받기 위해 네트워크 통신을 한다는 점입니다. 즉, 네트워크 상황에서의 예외를 잘 이해하고 처리하는 게 곧 MSA환경에서 DB의 일관성과 관련된 문제를 잘 해결하는 것이라고 할 수 있습니다.
예외 처리
블로그에서는 기본적으로 아래와 같은 네트워크 통신 예외상황이 존재할 수 있음을 소개했습니다.
그리고 이와 관련해서 알 수 없는 에러 처리라는 내용을 얘기합니다. 지금까지 제가 프로젝트에서 처리한 예외는 '페이지가 존재하지 않으면 404에러를 발생시켜라', '데이터가 null이면 해당 값을 채워라는 alert를 띄워라'처럼 단순하고 명확했습니다. 이 글을 읽으면서 성공과 실패를 판단하기 어려운 알 수 없는 에러가 더 까다롭고 중요하다는 사실을 간접적으로 경험할 수 있었습니다.
글을 읽으면 이분법적인 성공과 실패가 아니라 제3의 상황이 필요함이 당연해 보입니다. 하지만 이걸 보기 전까지는 부끄럽지만 아무런 고민 없이 성공/실패 두 가지 상황만으로 요청에 대한 응답을 처리하고 있었습니다.
알 수 없는 에러는 일반적으로 후처리를 통해 보정한다고 합니다.
하지만 이러한 후처리 역시 알 수 없는 에러가 발생할 수 있고, 이를 보정해주지 않으면 무한 루프에 빠질 수 있습니다. 결국 알 수 없는 에러를 마주했을 때 어떤 재시도를 할 건지, 어떤 장치들로 보정해 줄 건지 등을 개발자가 잘 설정해야 합니다.
멱등성 API
동일한 요청을 여러 번 보내도 같은 응답을 반환할 때 멱등성이 보장된다고 표현합니다. 오류가 발생했을 때 새로운 요청을 보내는 게 아니라 기존에 실패했던 요청을 다시 한번 보냄으로써 동일한 작업을 안전하게 재시도 합니다.
사실 아래 내용은 제대로 이해하지 못했습니다. 제 나름의 추측은 API가 알 수 없는 예외상황을 마주했을 때 -> 해당 API는 이전에 같은 요청을 성공으로 처리했었다면 -> 재요청을 통해 성공 응답을 받을 가능성이 크다는 내용이 아닐까라고 조심스럽게 추측해 봤습니다.
동일한 요청
멱등성의 동일한 요청을 판단하기 위해 요청 데이터에 유니크한 키를 포함해서 보냅니다. 해당 키값이 동일하다면 이를 동일한 요청으로 판단합니다.
예외 처리
예외는 기본적으로 try-catch를 통해 처리되는데 앞선 얘기의 성공, 실패, 알 수 없는 예외 세 가지 예외는 다음과 같이 처리할 수 있습니다.
이 때 try-catch가 깊어짐에 따라 문제가 발생할 수 있는데, 이러한 부분은 함수형 패러다임으로 조금 더 안전하게 처리할 수 있다고 합니다. 자바에서는 Optional<T>을 통해 데이터가 존재하지 않는 경우(null)를 안전하게 처리할 수 있습니다.
