백엔드 개발자를 목표하다보면, 한번씩 듣게되는 무서운 이야기가 있다.바로 데이터베이스를 날려버린 개발자의 괴담....!!!물론 실무에서는 미숙한 개발자가 쉽게 DB를 날려버리지는 않게끔 권한을 짜뒀겠지만, 아무튼 무서운 이야기이다. 그리고 이외에도 DB엔 다양한 변수가 있을수있다. 대표적으로 최근 이슈였던 예스24의 랜섬웨어 감염으로 인한 장애가 있었다.고객정보 등 핵심데이터를 암호화해 못쓰게 만들었다고...😮 아무튼 이런 문제의 예방도 중요하지만, 발생했을때 복구 방안 또한 중요할것이다.그래서 나는 우선적으로 정기적인 DB백업 자동화를 도입하기로 했다안전한 외부 서버에 데이터를 저장해 백업용도로 사용할 예정이다. 백업을 위한 다양한 방법db백업을 외부에 저장하는 방식은 다음과같이 떠올릴 수 있었..

Nginx 리버스 프록시 구현의 필요성을 느낀 계기가 있었다. 빼곡 서비스의 프로덕션과 스테이징 환경을 분리하면서 발생했던 문제였다. 우선 홈서버를 사용하고 있는 기존 아키텍처를 그림으로 표현하자면 다음과 같다. 한 서버에 각 docker-compose로 서버가 구성되어있고, 서로 다른 포트로 포트포워딩함으로써 접속하도록 만든것이다.당연히 DNS도 따로 발급받아두긴 했었다. 스테이징 URL에는 staging이 포함되는 url경로를 사용했다. 그러나 이 구조에서 헛점을 발견했는데, 도메인과 별개로 포트번호만 바뀌어도 각자 환경에 접근 할 수 있다는 것이였다. 즉, https://{product-uri}:50443으로 접근하면 product 환경이 아닌 staging환경으로 접속되는것이다.사실 이건 당연한 ..

빼곡이 서비스를 시작한지 어느덧 5개월이 되어간다.그리고 이렇게 프로덕션 서버를 운영하면서, 무중단 배포의 중요성을 느끼게 되었다. 사실 개발단계에서는 배포하느라 서비스가 중단되더라도, 그걸 FE개발자가 그걸 사용중인게 아닌이상 문제될게 전혀없었다.그런데 프로덕션에서는 다르다. 자잘한 에러나 보완을 하느라 코드를 커밋하는일이 발생하는데, 그때마다 서비스가 멈추면 사용자들은 큰 불편을 겪을것이다. 불안정한 서비스라고 느끼고 탈퇴할수도 있고 ㅜㅜ 그래서 무중단 배포 도입의 필요성을 크게 느꼈고, 여러 기법들을 공부하며 실제로 도입까지 완료했다.이번 포스팅은 그 여정을 담아보았다. 무중단 배포?말 그대로 서비스의 중단 없이 새 버전을 배포하는 개념이다.무중단배포를 도입하지 않은 일반적인 CI/CD의 경우, 기..

AWS Summit Seoul 2025 프로젝트할때 많이 사용했던 클라우드 컴퓨팅 기업인 AWS!!지난 5월, 코엑스에서 IT컨퍼런스를 개최했다.올해는 단순 IT를 넘어, 생성형 AI의 최신 트렌드부터 실전 활용법까지에 중점을 두었다고 한다.100개가 넘는 세션, 60여개의 파트너부스, 70여개의 고객사례 발표 등... IT 최신 트렌드를 공부할수 있는 자리였다ㅎㅎ리테일, 금융, 제조, 미디어, 산업 등등 다양한 산업을 아우르는 세션들이 있었다. 참여계기나는 취준생이기도 하고...^^ 가지 못할줄 알았는데, 같이 취준중인 지인이 알바를 통해 가보면 어떻겠냐 제안해서 참여하게 되었다!그렇다... 참가가 아니라 알바였다...AWS Summit에 오신분들.. 읽고계신가요? 홀에 포진해있던 주황색 NPC중 하..

서비스 운영에 있어 BI의 필요성을 크게 느꼈다. 일단 팀원들은 DB접근권한이 없다보니 실제 가입자수가 몇명인지, 회독 등 기능 이용이 잘 되고있는지 파악하고 싶어했는데 매번 내가 DB를 열어서 확인해주는건 너무 불편하다고 느꼈다ㅎㅎ 그래서 애널리틱스 시각화를 뭘로 만들까 고민을 많이 했다.1. DataDog - APM분석과 함께있으면 편하지 않을까? 하고 조사해보니, 비즈니스 분석은 메트릭수집을 통해 만들게 되는데 아무래도 메트릭 누락 등의 이유로 비즈니스 분석에는 정합성에서 큰 문제가 있을것같았다.2. Grafana - 대시보드를 만드는덴 특화되어 있으나, 시계열 모니터링과 알림이 주 목적이라 내 목적과는 차이가 있었다.3. Tableau - 기업에서 많이 사용하는것 같긴 한데, 아무래도 유료구독이 ..

저번 글에 이어서, 많은 요청이 발생했을때 데이터베이스를 어떻게 설계해야 하는지 알아보도록 하자. 데이터베이스 다중화대부분의 데이터베이스는 다중화 기능을 제공한다. 예를들어 AWS에서는 Read Replica를 통해 Master-Slave 관계를 만들 수 있다. 즉, 같은 데이터베이스를 하나의 Master DB와 여러개의 SlaveDB로 두는 방식으로, 원본이 Master서버에 사본이 Slave서버에 저장된다. 이경우 Master DB에서는 Write(쓰기연산)가 가능하고, Slave DB에서는 Read(읽기연산)만 가능하다. 웹이나 앱등을 구현하다보면, 쓰기/수정/삭제연산과 같이 Write연산보다는 읽기연산인 Read가 훨씬 많이 사용하게 되는것을 알게된다. 사실 당연하다. 뭔가를 수정,삭제하기 위해..

요즘 개발 포스트나 공고등을 보다보면 항상 눈에 보이는 단어가 있다.바로 "대규모 시스템 개발 경험"!비슷한 말로 대규모 트래픽 처리 경험, 대용량 데이터 처리 경험, 확장성있는 구조 등등이 있다. 대체 대규모 시스템이란 얼마나 다른 구조를 갖고 있기에 실무에서 강조 또 강조하는것일까?현재 나는 "빼곡"이라는 서비스를 운영하고 있긴 하지만, 아직 많은 이용자와 트래픽이 있는것은 아니기에 막상 경험해보긴 힘들었다. 따라서 책과 포스팅을 통해 개인적으로 학습해보고, 이를 토대로 아키텍처를 설계해보며 기업들이 강조하는 대해 알아보고, 성장하고자 한다. cf. 주 참고자료는 한 면접을 준비하며 알게된 상 면접 사례로 배우는 대규모 시스템 설계 기초>라는 책이다. 초기 서비스단일서버(클라이언트, 서버, DB)요..

스프링에서 백엔드 Repository를 구현하다보면 사용하는 어노테이션이 있다.바로 @Transactional! AOP를 활용해서 커밋, 롤백 등 트랜잭션을 관리하는 기능이다.만약 해당 repository에서 읽기작업만 수행할 경우, readOnly=true 속성을 사용하기도 한다.@Transactional(readOnly = true) 위 설정을 통해 성능상의 이점을 가져올 수 있다고 하는데, 좀더 구체적으로 어떤 이점이 있는지 공부해보려고 한다. Transcational과 Dirty ChekingTransactional은 begin()부터 commit()작업 전까지 영속성 컨텍스트를 유지한다.또한, 영속성 컨텍스트로 불러온 Entity의 변경사항을 DB에 바로 적용하지 않고, Dirty Chekin..

두번째 리팩토링의 주제는 @Reposiotry 생략했는데 왜 정상작동? 이다. 과거 MyBatis를 활용해서 프로젝트를 진행했던적이 있다. Controller, Service, Repository 등 클래스들은 어노테이션을 통해 꼭 빈으로 등록했었다(당시에 몇번 빼먹었다가 오류가 나서 수정했던 기억이ㅎ) 그런데 프로젝트의 경우, @Repository 어노테이션을 생략해도 정상적으로 동작하는것을 발견했다. 초반에 작성했던 클래스를 제외하고는 대부분 명시하지 않았다. 구현에 급급하다보니 살피지 못했던 부분이다. 다른점이라면 기술스택으로 인한 차이가 있다. JPA를 채택하고있기 때문에 Repository는 모두 JpaRepository를 extends하는 인터페이스 기반의 레포지토리이다. 그렇다면 지금 발..

기존 CookieUtil의 문제점 찾기코드리뷰 과정에서 대답에 가장 난항을 겪었던 클래스의 리팩토링 과정을 설명하려고 한다. 우선, 기존 코드는 다음과 같았다.@Slf4j@Componentpublic class CookieUtil { private static String domain; private CookieUtil() {}; @Value("${bbaegok.root-domain}") public void setDomain(String domain) { CookieUtil.domain = domain; } public static Optional getCookie(HttpServletRequest request, String name) { Co..