MSA 아키텍처로 서버를 구성하다보면 하나의 서비스가 여러 서비스의 api를 호출하는 일이 빈번하게 일어난다. 이런 경우 각 서비스의 endpoint에 호출을 하는 것 보다 API gateway를 만드는 것이 유리하다.
API gateway가 없는 경우
한 서비스가 자신이 호출하려는 각기 다른 서비스들의 endpoint를 알고있어야 한다. 이는 서비스간의 의존관계를 만드는 것으로 관리의 요소를 증가시킨다.
API gateway가 있는 경우
Gateway의 endpoint만을 알고 있어도 된다. 위에서 지적한 관리요소를 한 곳으로 집약시켰다. Point of Failure가 한곳에 있다는 단점이 있지만 그보다는 이로 인한 장점이 월등하게 높다.
또한, 서버 구성의 추상화가 가능해진다.
서버 구성의 추상화
추상화가 이루어지지 않은 경우
A라는 서버에서 제공해주는 api를 사용하여 어플리케이션이 동작하고 있었다. 서비스가 발전해나가면서 A서버를 A'와 A'' 서버로 나누기로 하는 경우를 생각해보자. 이 경우 application code에서 A 서버로의 api를 보내는 부분을 전부 A'와 A''로 바꾸어 보내주어야 한다. 이 과정에서 A 서버의 api를 사용하는 모든 application code를 수정해주고 이것에 대한 테스트를 진행하고 나서야 작업이 마무리 된다. 누락된 부분이 없는지, 바꾼 이후에 아무런 문제가 발생하지 않는지 확인을 하는 시간과 인내심이 필요하다. 경험상.. 이 과정에서 아무런 문제가 없이 넘어간적이 없었다. 그정도로 human error는 강력하다. Application code에서 변경을 누락한 문제, 구현된 서버에서 발생하는 문제, 주고받는 api 문서 속 오류로 인한 문제..
추상화가 이루어진 경우
A 서버만 사용하는 경우
/a/feature1 -> A
/a/feature2 -> A A 서버를 A'와 A''로 분할한 경우
/a/feature1 -> A'
/a/feature2 -> A''API gateway에 의해서 서버가 추상화 되는 경우에는, 이러한 진통을 겪지 않아도 된다. 서버의 분할로 인해 달라진 endpoint가 API gateway에 등록되어 application 개발자에게 전달되기 때문이다. API gateway의 endpoint로 서버의 api를 호출하는 application의 입장에서는 이러한 큰 변화가 생겼더라도 추상화가 잘 된 덕에 이런 일이 일어났다는 사실 조차 알아채지 못할것이다.
