solyrion

들어가며최근 AI 기반 회식 장소 추천 서비스를 개발하면서, 배포 과정에서 서비스를 멈추지 않고 업데이트하는 방법이 필요해졌습니다설계 단계에서 서비스 특성상 단순히 배포 시간을 줄이는 게 아니라, 장애 영향 범위를 최소화하고 문제가 생겼을 때 빠르게 복구할 수 있는 배포 전략의 필요성을 느끼게 되어 무중단 배포를 단계적으로 도입하기로 했습니다.초기에는 블루/그린으로 운영 안정성과 빠른 롤백을 확보하고, 이후에는 롤링 혹은 카나리로 전환해 일부 트래픽에서 먼저 검증하며 리스크를 더 작게 통제하고자 합니다.이 글에서는 블루/그린, 롤링, 카나리를 각각을 설명하고 왜 우리 서비스는 블루/그린 → 롤링 or 카나리로 진화하려는지 정리합니다무중단 배포란?무중단 배포는 서비스를 멈추지 않고 새 버전을 배포하는 방식..

부하테스트 대회에서 배운 “트래픽 분산”의 관점 (로깅/모니터링 포함)최근 부트캠프에서 2일간 부하테스트 대회를 진행했습니다.이전까지는 프로젝트를 할 때 구현에 집중하거나, 부하를 고려한다고 해도 실제로 많은 트래픽을 받는 상황을 만들어보기는 쉽지 않았습니다.그런데 이번에는 제한된 시간 안에 실제로 트래픽을 밀어 넣고, 병목을 찾고, 개선하고, 다시 측정하는 경험을 할 수 있었습니다.이번 글에서는 그 과정에서 정리한 트래픽을 분산하는 방법들을 공유해보려고 합니다.트래픽이 많으면 서버만 늘리면 되지 않나?가 부족했던 이유보통 트래픽 분산이라고 하면 “서버를 여러 대로 늘린다”를 먼저 떠올립니다.저도 실제로 면접에서 “트래픽이 많으면 어떻게 대응할 건가요?”라는 질문을 받으면 분산 서버(Scale-out) ..

개요최근 Express, Spring 서버에 CI/CD를 적용하고 있었습니다.Express 서버랑 다르게 Spring 서버의 경우 빌드를 진행하면 .jar 이라는 일종의 산출물이 나오게 되고이것을 실행하는 방식으로 서버를 실행합니다.그렇기 때문에 Dockerfile로 Spring 서버를 실행한다면 Multi Stage(빌드 스테이지 → 실행 스테이지)로 실행됩니다.빌드 시점이러한 방식이다보니 Spring 서버의 빌드 시점, 위치에 대한 고민이 있었습니다.Docker를 쓰는 상황에서 CI 작업을 Github Actions에서 진행한다면 빌드 위치는 여러 곳일 수 있습니다.DockerGithub Actions두 군데에서 모두 빌드할 필요는 없다고 생각했고 둘 중 1군데에서 진행하면 되는데어디서 진행해야 할지..