Rails 애플리케이션 성능 최적화를 위한 '사이드웨이 스케일링': 두 번째 프로덕션 앱 운영 전략
Scaling Sideways: Why You Might Want To Run Two Production Apps
작성자
발행일
2025년 11월 14일
핵심 요약
- 1 단일 Rails 앱의 트래픽을 핵심(메인) 및 보조(세컨드) 서비스로 분리하는 '사이드웨이 스케일링'으로 성능을 최적화합니다.
- 2 SEO에 중요한 공개 웹사이트의 p95 응답 시간을 안정화하고 사용자 경험을 개선하며, 느린 요청으로 인한 스레드 점유 문제를 해결합니다.
- 3 마이크로서비스 전환 없이 런타임만 분리하고, 각 앱의 특성에 맞춰 스레드 및 오토스케일링 설정을 조정하여 효율성을 극대화합니다.
도입
이 글은 단일 Rails 애플리케이션 내에서 상이한 트래픽 특성을 가진 여러 '섹터'를 운영할 때 발생하는 성능 문제를 다룹니다. 특히 SEO가 중요한 공개 웹사이트의 빠른 응답 속도와 안정성이 필수적인 반면, 사용자 포털이나 관리 도구와 같은 다른 섹터는 상대적으로 느리고 예측 불가능한 경우가 많습니다. 이러한 상황에서 느린 엔드포인트가 전체 애플리케이션의 p95 응답 시간을 악화시키고 큐 시간을 증가시키는 문제를 해결하기 위해 '사이드웨이 스케일링(scaling sideways)'이라는 접근 방식을 제안합니다. 이는 기존 프로덕션 앱의 복제본인 '세컨드 앱'을 별도로 운영하여 트래픽을 분리하는 전략입니다.
문제점 및 ‘사이드웨이 스케일링’ 전략 단일 Rails 앱에서 느린 엔드포인트가 Puma 같은 다중 스레드 환경에서 스레드를 점유하면, 빠른 요청의 큐 시간 급증과 p95 응답 시간 불안정으로 SEO에 중요한 공개 웹사이트 성능 저하를 야기합니다. 이를 해결하기 위해 ‘사이드웨이 스케일링’은 기존 ‘메인 앱’의 복제본인 ‘세컨드 앱’을 별도 서브도메인에 배포하여 트래픽을 분리하는 전략입니다. 메인 앱은 빠르고 예측 가능한 트래픽을, 세컨드 앱은 느리거나 변동성이 큰 트래픽을 처리하도록 런타임 환경만 분리하여, 마이크로서비스 전환 없이 핵심 성능을 최적화합니다. ### 사이드웨이 스케일링 적합성 및 구현 방법 이 전략은 트래픽 형태가 명확히 구분되고, 경로별 SLA가 다르며, 프론트엔드 호출 제어를 통해 트래픽을 유도할 수 있고, SEO가 비즈니스에 중요할 때 효과적입니다. 구현은 메인 앱과 동일한 코드베이스, 배포 파이프라인, 환경 변수(세션 공유를 위한
결론
사이드웨이 스케일링은 'SEO를 위한 공개 웹사이트 최적화'와 같이 특정 성능 목표를 달성해야 하지만, 전체 애플리케이션을 리팩토링하기 어려운 상황에 매우 효과적인 전략입니다. 이는 하나의 코드베이스를 유지하면서 두 개의 런타임 환경을 분리하여, 메인 앱은 빠르고 예측 가능한 경로를 처리하고 세컨드 앱은 복잡하고 변동성이 큰 작업을 흡수하도록 합니다. 점진적인 트래픽 이동과 신중한 모니터링을 통해 적은 추가 비용과 도메인 복잡성 증가 없이 실제 성능 향상을 얻을 수 있으며, 이는 제품을 재작성하거나 비용을 두 배로 늘리지 않고도 약속된 성능 목표를 달성하는 실용적인 방법입니다.