durumis.wiki와 wiki.onul.works 운영 경험 기반 인프라 구성에 따른 응답 시간 비교 분석
현재 두 개의 위키 서비스, durumis.wiki와 wiki.onul.works를 운영하고 있다. 이 중 wiki.onul.works는 durumis.wiki의 안정적인 서비스 환경 구축을 위한 파일럿 프로젝트 성격을 가진다. 두 서비스는 서로 다른 네트워크 인프라 구성을 사용하고 있으며, 이에 따른 응답 시간(latency) 차이를 관찰하여 그 결과를 공유하고자 한다.
인프라 구성
- durumis.wiki: 사용자 요청은 클라우드플레어(Cloudflare)를 경유하여 최종 서버로 전달된다.
- wiki.onul.works: 구글 클라우드 플랫폼(GCP)의 글로벌 로드 밸런서(GCLB)를 통해 직접 서비스된다.
응답 시간 데이터 비교
[클라우드 플레어 경유]
[직접 연결]
첨부된 모니터링 그래프는 각 서비스의 평균 응답 시간을 밀리초(ms) 단위로 보여준다.
- durumis.wiki (Cloudflare 경유): 그래프 상 장기간 평균 응답 시간은 91ms로 표시된다. 하지만 이 수치는 서비스 비활성 기간 또는 초기 데이터가 포함되어 전체 평균을 낮춘 것으로 해석된다. 최근 서비스 활성 상태에서의 응답 시간은 급증하는 경향을 보이며, 약 700ms 수준까지 기록되었다.
- wiki.onul.works (GCLB 직접 사용): 평균 응답 시간은 약 402ms 수준을 유지하고 있다. durumis.wiki의 최근 데이터와 비교했을 때, 상대적으로 변동폭이 적고 안정적인 응답 시간을 보인다.
인프라 선택 배경 및 분석
durumis.wiki에 클라우드플레어를 도입한 주된 이유는 최근 구글 쿠버네티스 엔진(GKE)의 Gateway API를 적용했기 때문이다. 현시점에서 GKE Gateway API는 특정 기능들(예: 특정 로드밸런싱 옵션, 상세 보안 정책 등)을 네이티브하게 지원하지 않아, 이러한 제약을 우회하고 필요한 기능을 구현하기 위해 클라우드플레어 사용이 불가피했다.
하지만 모니터링 결과, GCLB를 직접 사용하는 wiki.onul.works가 현재 구성 환경에서는 클라우드플레어를 경유하는 durumis.wiki보다 오히려 더 낮고 안정적인 응답 시간을 보여주는 것으로 나타났다. 물론 이는 네트워크 경로, 캐싱 전략, 각 서비스의 구체적인 부하 패턴 등 다양한 요인에 의해 영향을 받을 수 있는 결과이다. 그럼에도 불구하고, 직접적인 GCLB 사용이 특정 상황에서는 성능상 이점을 가질 수 있음을 시사한다.
향후 계획
이러한 응답 시간 측정 결과는 GKE Gateway API의 기능적 한계 외에도, 성능적인 측면에서 durumis.wiki의 인프라를 다시 GCLB 기반으로 전환하는 것을 고려하게 만드는 추가적인 요인이 되었다. 장기적으로는 GKE Gateway API의 발전 추이를 지켜보면서, 서비스 안정성 및 성능 최적화를 위해 GCLB로의 회귀를 포함한 인프라 재조정을 검토할 계획이다.
