상당히 높은 트래픽(일일 페이지뷰 15만 회 이상)이 발생하는 사이트를 운영 중입니다. 메시지 버스에서 주로 429 에러가 발생하고 있습니다. 이전에 set_real_ip_from 설정 오류로 인해 문제가 있었지만, 해당 문제는 해결되었습니다. 또한 레이트 리미팅 템플릿도 (아마도 임시로) 제거했습니다.
현재도 초당 약 0.5건의 429 에러가 계속 발생하고 있습니다.
CPU 2코어/4스레드 환경에서 유니콘(unicorn) 워커 5개를 사용하고 있으며, RAM은 16GB입니다. Postgres는 별도의 호스트에 설치되어 있습니다. CPU 사용률은 여전히 50% 이상 유휴 상태입니다.
레이트 리미팅 템플릿을 제거하고 유니콘 워커를 5개로 늘린 시점은 약 8시 20분경입니다.
완전히 정상적인 현상입니다. 유니콘(Worker) 프로세스에 부하가 많이 걸리고 큐에 요청이 조금씩 쌓이게 되면 메시지 버스가 429 상태 코드를 반환하며 백오프(backoff)를 수행합니다.
노드가 데이터베이스를 실행하지 않는다면 4코어에 RAM 16GB라는 비율은 정말 이상합니다. 예를 들어 8코어/8스레드가 더 적절할 것입니다.
좋아요! 감사합니다. CPU가 이미지 처리로 여전히 과부하 상태인데, 아마 하루 이틀 안에 끝나지 않을까 싶습니다.
맞는 말씀입니다. 하지만 베어 메탈 서버는 2코어/4스레드입니다. 코어를 추가하는 것보다 RAM을 추가하는 것이 훨씬 쉽거든요(집에 32GB RAM이 있는 서버가 하나 더 있습니다). CPU를 더 확보하기 위해 데이터베이스와 웹을 두 대의 머신으로 나누어 실행하고 있습니다. 같은 데이터베이스 서버에는 트래픽이 적은 다른 사이트들의 데이터베이스가 여섯 개 정도 더 돌고 있습니다(웹은 다른 호스트에서). 데이터베이스와 웹을 같은 머신에서 실행하는 것이 더 좋을까요? CPU 성능은 조금 떨어지겠지만, 지연 시간은 줄어들 것 같습니다.
여기에 로드 밸런서 기능이 있다면, 고부하 사이트를 위해 웹 워커를 두 대의 머신 모두에 배치해 볼 수 있습니다. 데이터베이스가 있는 머신에는 워커 수를 줄이고, 예를 들어 5+2처럼 구성하는 것도 방법입니다.
문제를 돈으로 해결할 수 있는 옵션이라면, CPU:RAM 비율이 더 좋은 다른 호스트를 하나 더 확보하는 것이 좋습니다.
음, 내가 무료로 받은 이 머신들이 조금 노후화되고 있어서, 그걸 받아들이기 시작하는 중입니다. 그래도 단일 CPU 성능은 여전히 DigitalOcean 드롭렛보다 나은 것 같아요. 단기적으로 돈을 써서 문제를 해결할 수 있었다면, 아마 기업급 성능을 기업급 가격에 원하시는 이 특정 클라이언트를 맡지 않았을 거예요. 
하지만 체인의 다른 곳에 유니콘(워커) 수를 하드코딩해 둔 걸 발견해서, 여전히 3개만 실행 중입니다.
아쉬운 점은 현재 설정이 하나의 호스트에서 docker와만 통신한다는 거예요. 다른 머신에도 유니콘을 몇 개 더 붙여볼 수 있는지 시간을 좀 더 들여 확인해 봐야 할 것 같아요. HAproxy를 다시 살펴볼 때도 된 것 같은데, 우선 출시하고 싶은 다른 프로젝트가 하나 있어서요.
좋은 조언 감사드립니다.
수정: 마침내 유니콘을 3개에서 5개로 늘렸는데, 성능 그래프는 거의 비슷해 보입니다(조금 더 느려진 것 같기도 하고요). 하지만 429 에러는 크게 줄었습니다. 이미지 처리가 완료된 후에는 이 시스템이 잘 작동할 것 같습니다. 
그리고 하루 뒤, 429 에러는 거의 0으로 줄어들었습니다. 라파엘의 "걱정하지 마세요"라는 조언은 정말 탁월했네요! 다시 한번 케인과 라파엘에게 감사드립니다. 도움을 얼마나 감사히 여기는지 아무리 강조해도 부족할 정도입니다.
