개발서버에서 바로 서비스 트래픽을 받고싶어


요약

서버를 개발하고 계십니까? 서버를 개발하는데 테스트용 트래픽을 따로 만들어야 해서 번거로우시다구요? 그냥 실서비스 트래픽을 바로 받는건 어떻게 생각하십니까? 네? 용량 터진다구요? 그건 내가 알바 아니구…

아니 진짜로, 몇몇 개발 사례에서는 테스트 진짜 번거롭고, 아예 실제 트래픽을 직접 받는게 제일 편하다. 예를 들면, Google sheet에서 뭔가 변경사항을 받아서 처리하고 싶은데, 하다보니까 webhook 비슷하게 이벤트를 받아야 했고, 그걸 개발하려다 보니 그냥 진짜 이벤트 메시지를 직접 받는게 개발하는 데 있어서 편하겠다 싶었다 이거지.

요구사항

  • 실서비스 트래픽을 받는 Public IP를 갖는 서버
    • 트래픽은 https로 날아온다
  • 개발은 집 데스크탑에서
  • 개발중일 때만 트래픽 받고 로컬 서버 끄면 원래 트래픽으로 돌아갔으면 좋겠어

대략적인 구조

서버의 load balancer 기능을 이용하면 편하게 할 수 있을것 같더라구요. 로컬 서버가 있으면 그쪽으로 트래픽 보내고 없으면 fallback으로 배포된 서버로 트래픽 보내기

원래는 이런 설정같은거 너무 adhoc하고 한번 설정하면 남지를 않아서 좀 꺼리는 편이었는데, 기왕 Nix를 쓰기 시작하니까 쓸데없이 용기백배해서 막 들이대게 되었다.

발단-전개-절정?

{ pkgs, ...}: {
  services.caddy =
    let
      # ...
    in 
    {
      enable = true;
      virtualHosts."yourmom.example.com".extraConfig = ''
        reverse_proxy * {
          to :4999 :5000 # 포트 4999에 개발서버, 5000에 실서버 실행
          
          lb_policy first # 4999 먼저 시도, 안되면 5000으로
          lb_retries 1
          
          # active health checks
          # Seems passive check is not working when first upstream fails and second upstream tries to consume the payload
          # 맘에 안들지만 1초마다 upstream을 광광때려서 살아있는지 확인한다
          health_uri /
          health_interval 1s
          health_status 2xx

          ## Passive health checks
          ## 원래는 실제 이벤트 날아올 때에만 upstream을 확인하게 하고 싶었어...
          # fail_duration 100ms
          # max_fails 1
          # unhealthy_status 5xx
          # unhealthy_latency 5s
          # unhealthy_request_count 1
        }
      '';
    }
}

처음엔 passive check로 할 수 있을줄 알았는데, 보니까 caddy의 버그인지 설계인지, lb retry가 될때 post body를 잃어버리는 문제가 있는듯 하다. caddy를 디버깅하기엔 내 코가 석자라 그냥 active health check로 전환해서 대충 해결…

결말

막상 하고 나니까 거의 서버 개발 다 해버려서 막상 효과적으로 활용하진 못했다는게 함정…!

어쨌든 Google sheet에 주소를 입력하면 자동으로 다운받고 집 서버로 전송하는 구조를 완성했다. 하핫!

하고 나니까 내가 원하던 것은 fallback이 아니라 duplicate였으면 더 좋았겠다는 느낌이다. 실서버로 항상 트래픽 쏘고, 개발서버가 있으면 같은 요청을 한번더 보낸다던가 하는 식으로 말이지. 그치만 load balancer에서 그런걸 지원하겠어?

https://caddy.community/t/how-to-duplicate-traffic-using-http-proxy/6261