요즘에는 점점 더 많은 앱이 클라우드에서 실행되고 있으며, 멤캐시를 함께 사용하기 시작했습니다. 예를 들어, 이번 주 초에 발표한 바와 같이, 약 300개의 애플리케이션에서 NorthScale의 서비스형 멤캐시드를 사용하고 있습니다. 헤로쿠의 Ruby 기반 PaaS 클라우드 플랫폼.
과거에는 멤캐시를 사용하는 대부분의 환경이 통제된 단일 LAN에서 실행되었으며, 보통 DMZ와 데이터베이스 사이에 일반적인 방화벽이나 라우터도 없이 프론트엔드 웹 서버가 DMZ에 위치해 있었습니다. 이러한 환경에서는 서버 장애가 한 번의 패킷 손실보다 훨씬 더 많이 발생할 수 있으며, 재전송을 기다리는 시간이 데이터베이스에 타격을 주는 것보다 더 오래 걸릴 수 있으므로 멤캐시드 작업에 대해 100-250ms 이하의 매우 공격적인 타임아웃을 설정하는 것이 합리적입니다.
반면 클라우드 네트워킹 환경은 다른 고객과 공유되고 특정 서비스의 위치가 반드시 사용자의 통제 하에 있는 것은 아니기 때문에 훨씬 덜 통제되는 경향이 있습니다. 이러한 환경에서는 같은 데이터센터 내에서도 노드 간에 3개 이상의 홉이 있는 경우가 흔합니다. 또한 동일한 스위치 또는 동일한 물리적 노드에 다른 고객이 있는 경우 때때로 패킷 손실이 급증하거나 지연 시간이 길어질 수 있습니다.
이러한 환경에서는 약간 공격적인 시간 초과가 발생하더라도 패킷이 한 번만 삭제되어도 쿼리가 실패할 수 있습니다. TCP의 초기 재전송 타이머는 3초입니다. 이보다 빨리 다시 시도하는 유일한 방법은 바로 포기하고 재시도하는 것입니다. 데이터베이스가 이보다 느리거나 특별히 비용이 많이 드는 경우가 아니라면 클라이언트의 타임아웃을 (아마도 비교적 공격적인) 기본값으로 설정하는 것이 합리적일 수 있습니다. 그러나 이제 시간 초과가 서버 장애보다 네트워크 문제로 인해 발생할 가능성이 더 높으므로 클라이언트가 반복적인 실패 후 서버를 죽은 것으로 표시하는 경우 이 설정을 약간 느슨하게 하는 것이 중요합니다. 2(Fauna의 기본값)는 너무 빡빡할 수 있으며, 3~5회 정도의 실패 횟수가 서버가 죽었다고 표시하는 데 더 적합할 수 있습니다.
클라우드에서 태어나지 않은 많은 애플리케이션은 멤캐시의 시간 초과를 잘 처리하지 못합니다. 이러한 애플리케이션의 경우, 최소한 하나의 삭제된 패킷을 처리할 수 있도록 타임아웃을 조정하는 것이 좋습니다. Fauna에 대한 튜너블(SASL을 지원하기 때문에 NorthScale이 권장하는 루비 클라이언트)은 클라이언트 생성자에 해시 매개변수로 전달할 수 있습니다. 단일 드롭된 패킷 처리를 위한 권장 사항을 포함했습니다:
:connect_timeout - 4.0 - 초기 연결, 패킷이 끊어지면 TCP는 3초가 걸립니다.
:rcv_timeout - 설정되지 않음 - libmemcached에 해당하는 값은 MEMCACHED_BEHAVIOR_RCV_TIMEOUT - 서버로부터 응답을 받기 위한 시간
:poll_timeout - 설정되지 않음 - libmemcached에 해당하는 것은 MEMCACHED_BEHAVIOR_POLL_TIMEOUT - 폴링 호출이 반환될 때까지 기다리는 시간입니다.
timeout - 4.0 - 별도로 지정하지 않은 경우 :rcv_timeout 및 :poll_timeout의 기본값으로, 일반적으로 사용되는 값입니다.
재시도_시간 초과 - 30 - 서버가 :서버_실패_제한에 도달했을 때 서버를 죽은 것으로 표시하는 기간
:서버_실패 제한 - 3-5 - 서버가 죽었다고 표시되기 전에 실패할 수 있는 횟수
이 모든 과정은 몇 초 만에 이루어지며, Fauna는 내부적으로 libmemcached에 적합한 값으로 변환합니다.
