글로벌 서비스를 준비 중입니다. 지역에 상관없이 동일한 아키텍처로 빠르게 구성하려고…

글로벌 서비스를 준비 중입니다. 지역에 상관없이 동일한 아키텍처로 빠르게 구성하려고 생각 해보니, AWS를 활용할 것을 생각하고 있습니다. 나름 AWS 관련 경험도 있구요.

문제는 korea region이 없어서, tokyo region에서 서비스를 해야 한다는 겁니다. 기본적으로는 HTTP 기반으로 REST API를 서비스하는 형태고요. 메시징 시스템이라고 보시면 됩니다.

Tokyo와 korean 간 네트워크 지연이 좀 있다고 해서, 테스트를 진행했습니다. 비교 대상은 ucloud 이고요. 순수하게 HTTP 요청 지연만을 테스트 했습니다.
했더니..

aws connection time : 46ms
ucloud connection time : 4ms 가 나오더군요.
쌍방향으로 메시지를 주고 받으니까, 대략 95ms vs 9ms 정도가 나옵니다.

95ms의 네트워크 지연이라 이걸 어떻게 판단해야 할지 감이 잡히지 않더군요. 괜찮은 수준이라고 봐야하는 건지.. 여러분의 조언을 듣고 싶습니다.

참고로 대량의 메시지를 교환하면서, 네트워크 대역폭을 소비하는 그런 서비스는 아닙니다. 대량의 메시지를 다루지는 않습니다. 그래서 관심이 네트워크 지연인 입니다.

6 thoughts on “글로벌 서비스를 준비 중입니다. 지역에 상관없이 동일한 아키텍처로 빠르게 구성하려고…

  1. API가 Sync 하게 동작되고 어플리케이션이 다수의 API 콜이 있다면, 아시는 바와같이 계속 중첩이 될것입니다.

    46ms는 글로벌 서빙에서 그리 큰 값은 아닌것 같네요. 전용선으로 해도 한국-대만, 한국-싱가폴 정도만 해도 65ms 정도 나오거든요. Public Line 이라 저값이 널뛰기를 한다면 문제가 되겠지만요.

  2. Jinoos Lee 요청과 요청에 대한 응답이 분리된 Async 방식입니다. 요청을 받는 API server는 Message queue에 요청을 올린 후 곧바로 200을 리턴합니다. Message 대한 처리는 백엔드에서 작업을 한 후 응답을 보내는 방식입니다.

    이런 구성의 경우 네트워크 대역폭을 채우지 않는다면 레이턴시는 일정하게 유지될 거라고 가정할 수 있겠죠 ? API server는 ELB로 요청을 분산할 거고요.

  3. Yun Sang Bae message queue 에서 처리 후 보내지는 응답을 client 는 어떻게 받는지 궁금하네요. 지속적으로 연결된 웹소켓이 있는건지, 아니면 주기적으로 client 에서 polling 하는 방식인지요

  4. 클라이언트 앞단에 서버가 하나 놓임니다. Message 플랫폼에서는 이 서버에 REST로 메시지를 보내고요. 이 후 클라이언트가 소켓으로 가져가든 long polling로 가져가든 알아서 가져가는 방식입니다.

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.