MSA 서비스 시리즈 1탄 : 서버간 오류 어떻게 해야할까 🤔

 

 

 

 

 

 

MSA 알고 이 글을 읽는거겠죠..?

아주 간단하게 설명하면 여러개의 컴퓨터를 사용하는거다.

예를 들어 네이버를 뇌피셜로 설명해보자.

우리가 자주 사용하는 검색창은 A 컴퓨터에서, 페이는 B 컴퓨터에서, 메일은 C 컴퓨터에서 실행된다.

컴퓨터의 수는 무수히 많을 수 있다. 

(사스가 네이버라면 어쩌면 세자리를 수일수도 😙)

 

컴퓨터는 무슨 기준으로 나누나요?! 라고 물어볼 수도 있다.

현재 1년 6개월 차 밖에 되지 않은 햇병아리 백엔드 개발가인 내가 감히 생각해보면...

그건 회사마다 이끄는 사람마다 다르다.

실은 MSA를 하냐 아니면 Monolithic를 하냐부터 생각도 말도 많아진다.

 

그래도 진짜 그래도 나만의 서비스 선택 기준을 말하자면 아래와 같다.

1. 구상한 서비스가 작다 -> 3번으로 이동

2. 구상한 서비스가 크다 -> 4번으로 이동

3. 확장될 서비스가 아니다 -> Monolithic

4. 확장할 서비스다 -> 6번으로 이동

 

간단히 정리하면 구상한 서비스가 굉장히 크고 확장을 계속 할거면 MSA가 맞다.

구상한 서비스가 작다 크다는 혼자서 결정하기엔 아리송할 수 있다.

그럴때는 여러 사람들에게 서비스를 설명해보고 문서를 정리하며 파악해야한다.

 

 

 

 

서버끼리는 어떻게 통신해요?

회사 입사하기 전까지 MSA는 나한테 유니콘 같았다.

서버 여러개 오케오케 👌

대체로 개인 프로젝트나 팀별 프로젝트를 한다고 해도 소규모라서 MSA는 꿈도 못꿨다.

 

입사한 회사에서는 개발 초기 단계부터 MSA로 결정 그에 따라 서버 설계를 했다고 한다.

서비스에 대한 전반적인 이야기를 들어봐도 MSA 안하면 안될 규모이긴 했다.

적응 하고 실제로 코드를 작성할 수 있을 때 먼저 든 생각은 서버(=컴퓨터) 끼리 어떻게 통신할 수 있지? 였다.

 

서버끼리 왜 통신해 라고 물어볼 수도 있다.

예를 들어, A 컴퓨터엔 네이버 카페 서비스가 있고 B 컴퓨터엔 네이버 메일 서비스가 있다.

이때 각 컴퓨터엔 각 데이터만 존재한다.

즉, A 컴퓨터엔 카페 데이터만 있고 B 컴퓨터엔 메일 데이터만 있다.

 

근데 누군가 이런 요구사항을 가지고 온다.

"특정 카페에 가입한 사람들에게 전체 메일을 보내고 싶어요."

 

그럼 어떻게 해야할까? 

프론트에선 어딘가 버튼 하나 만들고 '전체 메일 보내기' 하나 만들어주면 된다.

그 버튼 B 컴퓨터의 b API 일거다.

b API는 호출 되는 순간 전체 메일을 보내기를 수행해야 한다.

근데 이 B 컴퓨터엔 특정 카페에 가입한 사람들의 데이터가 없다 🤯

 

이때 하는게 A 컴퓨터에 있는 카페 데이터를 조회하기 위해 B 컴퓨터에선 A 컴퓨터에 물어봐야(=통신) 한다.

"특정 카페에 가입한 사람들 정보 줘."

 

그럼 A 컴퓨터는 그래~ 하면서 필요한 정보를 건네준다.

말은 정말 쉽지만 실제로 백단에서는 이 작업을 하기 위해 수많은 코드와 처리를 진행한다.

그리고 이때 사용하는 것인 HTTP 라이브러리나 프레임워크다.

대표적으로 Axios가 있다.

 

 

본론으로 돌아가서 그렇다면 서버간 오류를 어떻게 처리해야할까?

자, 서버가 서로 통신하는 이유와 어떻게 하는지 알았다.

이 글의 제목은 '서버간 오류 어떻게 할까' 이다.

무슨 말일까 감이 잡하지 않는다면 더 설명하도록 하겠다.

 

B 컴퓨터에서 b API로 A 컴퓨터의 a API에 '특정 카페에 가입한 사람들 데이터 줘' 라고 요청했다.

근데 a API에서 '어? 네가 보내준 특정 카페 id가 조회가 안되는데? 오류야! 오류! 오류!'이렇게 답할 수 있다.

실제로 많은 개발자들이 id가 조회 되지 않으면 오류 처리를 한다.

 

당연히 아까 적은 것처럼 오류! 오류! 이렇게 보내지 않는다.

{
    "code": 3333,
    "msg": "id check plz"
}

간단히 이렇게 보낼 수 있다.

그럼 B 컴퓨터에서 b API는 err.response.data에 저런 데이터를 받게 된다.

친절한 오류 메시지 덕분에 id가 잘못 되었다는 것을 알았다.

 

그럼 인제 B 컴퓨터에서도 오류를 프론트에 보내야 한다.

이때!!!

어떻게 오류를 처리하냐는 재미있는 생각거리가 발생한다.

 

미리 말하지만 정답은 없다.

 

B 서버의 개발자는 선택이 두가지다.

첫번째는 A 서버의 개발자가 보내온 오류 데이터를 그대로 사용한다.

두번재는 A 서버의 개발자가 보내온 오류 데이터를 참고하여 따로 처리한다.

 

딱 봐도 둘의 장단점이 뚜렷하고 대비된다.

첫번째의 경우 그대로 A 서버 개발자의 오류 데이터를 태워주면 되니 편하다. 하지만 B 서버 개발자의 오류 형식과 달라 프론트에 혼란을 야기 할 수 있다.

두번째의 경우 어떤 경우든 B서버 개발자의 오류 형식이 같다. 하지만 한 번 더 매핑을 해주거나 처리를 해줘야 하기 때문에 귀찮을 수 있다.

(MSA이다 보니 서비스 혹은 개발자마다 오류 형식이 다를 수 있다.)

 

 

 

나의 선택은?

우선 백엔드 동료 두분께 물어봤다.

사수님은 부분적으로 사용하고 동기는 따로 처리를 해준다고 했다.

 

과연 나는...(두근두근)

따로 처리해주기로 했다!

 

왜냐하면 MSA가 지향하는 바를 생각해서다.

MSA의 최대 지향점은 각 서비스의 독립성이다.

근데 A 서비스의 오류 형식을 사용하면 어쩔 수 없이 A 서비스에 종속될 수 밖에 없다.

 

또한 B에서 쓰는 에러 코드와 A에서 오는 에러 코드가 같을 수도 있다.

{
    "code": 3333,
    "msg": "id check plz"
}

위에처럼 3333이라는 코드를 A 컴퓨터에서 줬는데 B 컴퓨터에서도 조회되는 메일 데이터가 없으면 프론트에 3333을 주라고 할 수 있다.

그럼 프론트 입장에서는 가입한 회원들의 정보를 못가져와서 오류인지(=A) 메일 데이터를 못 가져와서 오류인지(=B) 분기를 태워 작업할 수 없다.

 

그럼 B 서버 개발자한테 3333 쓰지 말라고 할까?

이런 생각이나 행동자체가 MSA에 맞지 않다.

 

하지만 그리 효율적이라는 생각은 안든다.

그렇기에 정답은 없다고 말한 것이다.

 

 

 

마무리

처음엔 Axios 오류를 어떻게 처리해줄까 하다가 해당 서비스의 개발자가 설정한 오류 메시지를 그대로 쓰면 되겠다! 라고 생각했다.

쉽게 개발 쌉가능~ 이라고 마음속으로 생각했지만 생각하면 할수록 따로 처리하는게 나을까? 아니야 활용하면 좋잖아로 팽팽하게 의견이 대립되어 동료들한테까지 물어보게 되었다.

이야기하면서 정답이 없다는 것을 느꼈고 내가 생각하는 기준(=가치관)에 맞춰 개발하면 된다는 것을 끝으로 글을 마무리한다.

(솔직히 이런 개발 가치관이 점점 쌓여 대처불가한 개발자가 된다고 생각한다 😎)

 

솔직히 이런 글을 타이핑하면서 써야하나 싶었는데 한 번쯤 개발자라면 생각해볼 이야기라 생각하여 작성했다.

이런 이야기거리로 개발자들과 이야기하면 은근 재미있다 👍

 

 

 

 

 

 

 

fin.