최근 면접 질문에서 DynamoDB의 응답 시간을 최소화 할 수 있는 방법에 대해 질문을 받았다. 나는 consistency 수준을 낮추는 것 외에 다른 방법에 대해서는 답변하지 못 했다. 다음번에 같은 상황이 오지 않도록 복기해보고자 한다.
방법을 찾아보던 중, AWS에서 작성한 문서가 내용이 좋아서 가져왔다. 문서에서는 Latency를 줄일 수 있는 여러가지 방법을 제시하고 있다.
1. Adjust request timeout and retry behavior
AWS SDK는 network resiliency, tcp packet timeout 등의 상황에 대비하기 위해 retry와 timeout이 적절한 균형을 이루도록 설정되어 있다.
다만, 최소 latency가 주 고려사항이라면 SDK의 timeout, retry 동작에 대한 조정이 필요하다.
조정은 클라이언트들이 일반적으로 겪는 latency를 기준으로 맞추면 된다. 평소보다 오래걸리는 request는 fail했을 확률이 높기 때문에, 실패로 처리하고 새로운 요청으로 fail fast 하는것이 결과적으로 latency를 줄일 수 있다.
2. Client와 DynamoDB간의 거리 최소화
network trip time 또한 latency에 포함된다. client와 dynamo의 endpoint간 물리적 거리가 길어질수록 network triptime 증가로 이어진다.
글로벌 트래픽이 발생하는 환경이라면, 물리적 거리로 인한 latency를 줄이기 위해 두 가지 전략을 사용할 수 있다.
| 방법 | 특징 |
| Global Table |
|
| gateway VPC Endpoint |
|
3. 캐시 사용
읽기 요청이 heavy하게 발생한다면 cache를 두는것도 좋다. DAX나 Redis등의 In-Memory cache를 적극 사용하자.
문서에서는 DAX를 사용할 경우, 최대 10배 이상의 성능 향상을 기대할 수 있다고 소개하고 있다.
4. 커넥션 재활용
DDB 요청은 기본적으로 HTTPS 통신에서 세션이 만들어진다. http connection 초기화 과정은 latency가 많이 발생한다. 그래서 일반적으로 첫번째 커넥션의 지연시간이 가장 크다.
따라서 새로운 커낵션을 매 번 만들기보다, 기존 커넥션을 잘 활용하는 것이 좋다. 커넥션이 항상 alive 하도록 유지하기 위해 30초마다 GetItem 등의 요청을 보낼 수 있다. 그러나 코드 복잡성을 야기할 수 있기 때문에 사용 전 고민해보는것이 좋다.
5. Use eventually consistent read
application이 strongly consistent reads를 요구하지 않는다면 eventually consistent 수준의 read를 사용하자.
eventually consistent read의 장점
1. 저렴한 비용
2. 일시적인 latency 증가를 경험할 가능성이 더 낮다.