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군데에서 진행하면 되는데어디서 진행해야 할지..

개요프로젝트를 진행하면서 인메모리 캐시를 도입해야 했던 시점이 있었습니다.처음에는 많은 개발자들이 사용하는 Redis를 선택하려고 했지만,Memcached라는 대안도 있다는 사실을 알고 두 엔진을 비교해보게 되었습니다. 특징Memcached멀티 스레드 아키텍처로 높은 병렬 처리에 강함Key-Value 기반 순수 메모리 캐시오직 문자열 기반 캐시매우 가벼움단일 목적: 빠른 읽기/쓰기RedisKey-Value 기반의 데이터 구조 서버(data structure server)문자열, Hash, List, Set, Sorted Set 등 다양한 자료구조 지원Persistence(RDB, AOF) 지원Pub/Sub, Lua Script 등 부가 기능 풍부트랜잭션 제공비교성능 (읽기/쓰기 속도) Redis ..

상황최근 토이 프로젝트를 진행하면서 FE, BE, 그리고 배포 환경 전반을 함께 공부하고 있습니다.배포를 위해 인스턴스 종류를 고민하던 중, 프로젝트 규모가 작고 트래픽이 거의 없다는 점을 고려해 t3.micro 인스턴스를 선택했습니다.처음에는 서버에서 직접 git clone으로 FE와 BE를 빌드했는데,이 중 Spring 프로젝트 빌드가 계속 실패하는 문제가 발생했습니다.로컬 환경에서는 정상적으로 빌드되었기 때문에, 원인을 서버의 성능 부족으로 판단했습니다.그래서 로컬에서 빌드 후 .jar 파일만 서버로 전송하는 방식으로 배포 방법을 변경했고,이로써 빌드 문제는 해결되었습니다. 하지만 바로 이어서 또 다른 문제가 발생했습니다.바로 FE와 BE 서버를 동시에 백그라운드로 실행할 수 없는 문제였습니다.메모..

Redis 클러스터Redis는 빠르고 간단해서 단일 서버로 시작하기 좋은 캐싱 시스템 중 하나입니다.하지만 서비스 트래픽이 커지고, 데이터가 많아질수록 하나의 Redis로는 부족할 수 있습니다.이번 글에서는 이를 해결하기 위한 Redis 클러스터(Cluster) 구조를 정리해보려 합니다.1. 단일 Redis의 한계와 클러스터의 필요성Redis는 기본적으로 싱글 스레드 구조이기 때문에,아무리 서버 성능을 올려도 결국엔 Scale-up의 한계가 옵니다.예를 들어,트래픽이 커질수록 I/O 병목이 발생하고,Redis 서버가 죽으면 모든 캐시가 날아가며,데이터가 많아지면 한 서버 메모리에 다 들어가지 않습니다.그래서 등장한 개념이 바로 Redis Cluster입니다.👉 여러 Redis 노드가 하나의 거대한 Re..

개요실제 Redis를 Spring 서버에 어떻게 적용할 수 있는지 알아보겠습니다.Redis 서버AWS에서 제공하는 ElasticCache를 사용할 수 있습니다.로컬에서 사용한다면 간단하게 Docker를 활용해서 Redis 서버를 열 수 있습니다.(저는 개발: Docker, 배포: ElasticCache 방식으로 사용했습니다.)Spring 연동 (의존성 + application.yml)build.gradle// build.gradleimplementation 'org.springframework.boot:spring-boot-starter-data-redis'implementation 'org.springframework.boot:spring-boot-starter-cache'// 추가적으로 필요한 의존성..

개요Redis는 DB의 데이터를 메모리에 일시적으로 저장하는 공간입니다.그렇기 때문에 저장 공간이 한정적입니다. 따라서 데이터를 무한히 저장할 수는 없고,실제 DB의 데이터와 현재 캐싱되어 있는 데이터가 불일치할 수도 있기 때문에기존 데이터들이 적절히 삭제될 필요가 있습니다.이때 사용될 수 있는 방법이 TTL 값 설정입니다.TTLRedis는 데이터베이스 내의 특정 키에 대한 만료 시간을 설정할 수 있으며,이는 데이터의 유효 기간 또는 만료시간을 정의하는 데 사용됩니다.특징단위: 보통 초(second) 단위로 설정되며, 밀리초(ms) 단위도 가능 (PTTL, PEXPIRE).자동 삭제: 설정된 시간이 지나면 자동으로 데이터가 삭제되어 메모리 공간을 효율적으로 관리.데이터 수명 관리: 캐시 데이터 유지 및 ..