아카이빙
1.배포했는데 반영이 안 된다? — 5주간 조용히 롤백된 Flyway 삽질기
시리즈 예고: 지금 운영 중인 서비스의 백엔드 인프라(AWS ECS Fargate + Terraform)를 직접 구축했다.구축 과정은 따로 연재로 풀 예정이고, 오늘은 정식 오픈 전 준비 기간에 겪은 사건 하나를 먼저 꺼낸다.실사용자가 없던 시기라 피해는 없었지만, 개
2.인프라 구축 일지 (1) — VPC를 3개의 방으로 나눈 이유
백엔드 개발자가 AWS 인프라를 처음부터 직접 구축한 기록이다.지난 글(Flyway 삽질기)에서 예고했던 구축 일지, 그 첫 번째. 네트워크부터 시작한다.인프라를 구축하면서 가장 먼저 한 일은 서버를 띄우는 게 아니었다. 네트워크 도면 그리기였다.AWS에서 네트워크의
3.인프라 구축 일지 (2) — EC2 대신 Fargate를 고른 이유, 그리고 "백신 안 깔았어요?"
1편에서 네트워크를 3층으로 나눴다. 이번엔 그 2층(앱 층)에 뭘 올릴지 정하는 이야기다.Spring Boot 앱을 AWS에서 돌리는 방법은 여러 가지다. 후보를 두 개로 좁혔다.EC2: 가상 서버를 직접 빌려서 그 위에 도커/앱을 올린다ECS Fargate: 컨테이
4.인프라 구축 일지 (3) — AWS 키를 평문으로 두지 않기로 했다
1편은 네트워크, 2편은 컴퓨팅이었다. 이번엔 눈에 안 보이는 것 — 비밀값 이야기다.DB 비밀번호, JWT 키, OAuth 시크릿, 그리고 AWS 액세스 키 자체까지.인프라를 구축하다 보면 비밀값이 계속 늘어난다.DB 비밀번호, JWT 서명 키, 소셜 로그인 클라이언
5.인프라 구축 일지 (5) — 오토스케일링, 설정만 하면 끝일까?
3·4편에서 비밀값과 배포 인증을 정리했다. 이번엔 트래픽이 몰리면 알아서 늘어나는 구조,그리고 그게 진짜 동작하는지 부하를 걸어 실측한 이야기다.ECS 오토스케일링은 Target Tracking 방식으로 걸었다. terraform으로 몇 줄이면 된다.CPU가 70%를
6.인프라 구축 일지 (6) — 오픈하니까 진짜로 공격이 왔다: WAF 실전 기록
5편까지는 "만든" 이야기였다. 이번엔 서비스를 오픈하고 나서실제로 들어온 공격과, 그걸 막은 기록이다.서비스를 인터넷에 열면 사람보다 봇이 먼저 온다는 말이 있는데, 진짜였다.오픈 직후부터 ALB 액세스 로그에 이런 요청들이 찍히기 시작했다.우리는 Spring Boo
7.인프라 구축 일지 (6) — 오픈하니까 진짜로 공격이 왔다: WAF 실전 기록
5편까지는 "만든" 이야기였다. 이번엔 서비스를 오픈하고 나서실제로 들어온 공격과, 그걸 막은 기록이다.서비스를 인터넷에 열면 사람보다 봇이 먼저 온다는 말이 있는데, 진짜였다.오픈 직후부터 ALB 액세스 로그에 이런 요청들이 찍히기 시작했다.우리는 Spring Boo
8.인프라 구축 일지 (7) — 매일 아침 5분, 서버 점검 루틴 만들기
구축이 끝나면 운영이 시작된다. 오픈 이후 매일 아침 반복하는4종 점검 루틴과, 로그를 "읽는 기준"을 정한 이야기다.오픈 직후엔 불안해서 CloudWatch 콘솔을 하루에도 몇 번씩 열었다.그런데 콘솔을 돌아다니는 건 시간도 걸리고, 볼 때마다 보는 범위가 달랐다.어
9.인프라 구축 일지 (8·완) — 오픈 전 마지막 일주일에 한 일들
구축 일지 마지막 편이다. 인프라는 다 만들어져 있었다.문제는 "이대로 열어도 되나?"에 답하는 일이었다.기능 개발이 끝나고 오픈 일정이 잡히면, 이상하게 그때부터 불안해진다.개발 환경에선 편했던 것들이 운영에선 구멍이 되기 때문이다.오픈 전 마지막 주에 한 것들을 영
10.백엔드 개발 일지 (1) — 캐시 서버가 죽으면 서비스도 죽어야 할까?
인프라 구축 일지는 끝났고, 이번엔 그 위에서 돌아가는 애플리케이션 이야기다.첫 주제는 캐시. Redis를 붙이는 건 쉬운데, "Redis가 아플 때"를 설계하는 게 진짜 일이었다.메인 화면은 조회가 압도적으로 많고, 내용은 자주 안 바뀐다.리스트 첫 페이지, 추천 목
11.백엔드 개발 일지 (2) — LIKE '%검색어%'는 인덱스를 못 탄다던데
1편은 캐시였고, 이번엔 검색이다. 인프라 일지 5편의 부하 테스트에서"가장 무거운 API = 검색"이었던 이유와, 그걸 어떻게 인덱스로 풀었는지.검색 기능의 핵심 조건은 이거다. 대소문자 무시 + 부분 일치.동작은 잘 한다. 문제는 실행 계획이다. sequential
12.백엔드 개발 일지 (3) — offset 페이징을 버린 이유
2편에서 검색 인덱스를 정리했다. 이번엔 그 검색 결과를 "어떻게 나눠 주느냐" —페이징 이야기다. 교과서의 OFFSET 방식을 버리고 커서로 간 기록.페이징의 기본형은 다들 이렇게 배운다.이 쿼리의 함정은 OFFSET의 동작 방식에 있다.DB는 10,020행을 읽어서
13.백엔드 개발 일지 (4) — 조회수 하나 올리는 데 이렇게까지
이번 편은 "조회수 +1"이라는, 요구사항 한 줄짜리 기능이다.그런데 이 한 줄이 트랜잭션·비동기·백프레셔를 전부 소환했다. 그 과정을 남긴다.첫 구현은 누구나 떠올리는 그대로였다. 상세 조회 트랜잭션 안에서 UPDATE.동작한다. 그런데 곱씹을수록 이상했다.첫째, 조
14.급한 실서버 반영은 왔는데, develop엔 아직 못 나갈 코드가 있다면
브랜치 전략 얘기다. 팀에서 실제로 부딪힌 딜레마 하나를 어떻게 풀었는지,Feature Flag를 왜 안 골랐는지, 대신 뭘 골랐는지의 기록.결론부터 말하면 hotfix 브랜치를 stage 서버에 임시로 스왑하는 방식으로 갔다.기획쪽에서 카톡이 왔다."실서버 화면 하나
15.백엔드 개발 일지 (5·완) — application.yml의 숫자엔 전부 이유가 있다
백엔드 일지 마지막 편이다. 화려한 기능 대신 설정 파일을 꺼냈다.application.yml에 박힌 숫자들은 대부분 "기본값을 왜 바꿨는가"의 기록이기 때문이다.프레임워크의 기본값은 "대부분의 상황에서 무난한" 값이지,"우리 상황에서 최적인" 값이 아니다. 운영하면서