공부노트

버전이 올라가며 이전, 이후 버전의 DB 스키마가 크게 바뀌었다. 주요 테이블의 네이밍이 수정되었고 서비스 로직이 변경되며 컬럼의 위치도 일부 수정되었다. 개인 별로 저장되던 스터디 참여자들의 진행 정보가 기획이 수정되며 함께 관리되도록 바뀌었다. 문제: 스키마는 바꼈지만 이전 버전의 데이터도 신버전에서 실시간으로 보고 싶다 스키마의 변경 자체는 크진 않지만 신규 배포를 무중단으로 진행해야 한다는 점이 가장 큰 문제였다. 서비스에는 다음의 세 주요 기능이 존재한다. 1. 스터디 함께 진행하기 2. 혼자 공부하기(다인 스터디를 혼자 진행하는 형태) 3. 자신의 스터디 기록 조회하기 이번 배포에서는 기능이 빈약한 '1. 스터디 함께 진행하기'에 실시간 동기화 기능을 추가하는 것이 가장 큰 변경이었고, 기능이..

하루스터디 서비스에서 다음 핵심 기능인 '스터디 실시간 함께 진행하기'를 테스트 서버에서 시험 중이다. 기존의 기능에선 같이 하기 과정에서 진행도를 공유할 수 없어 여럿이 함께 한다는 느낌을 받기 어렵다는 평이 많았다. 통계를 보았을 때 현재는 개인 사용자 수가 그룹 사용자에 비해 압도적으로 높은 상황이다. 새로운 기능을 통해 개인 사용자 외에 그룹 사용자 또한 스터디를 함께 진행하기를 기대한다. 이번 기능으로 인해 기존의 로직이 변경되는 부분이 굉장히 많았다. 프론트의 정적 파일과 웹 서버의 로직은 당연하며 기존의 DB 스키마까지 변경되는 부분이 있었다. 실사용자들이 주요 쓰는 혼자 하기 기능까지 변경의 영향을 받아 중단 배포를 해야 할까 고민하였으나 복잡하지만 무중단 배포가 가능하여 고려한 부분들을..

벨로그에 우리 서비스를 홍보했던 글을 보고 많은 분들이 기대 이상으로 사용해 주시고 응원해 주셨다 여러 플랫폼에 서비스를 소개했지만 운 좋게도 벨로그에서 추천을 굉장히 많이 받아 글이 주간 트랜딩 3위까지 올라갔고 현재는 월간 트렌드로 넘어간 상태다. 덕분에 무난하게 초기 사용자 목표를 달성할 수 있었다. 사실 이보다 더 기대했던 것은 실 사용 데이터였고, 의미 있는 수준의 데이터가 쌓여 이를 바탕으로 우리의 서버가 얼마나 안정적으로 사용자를 수용할 수 있을지 테스트가 가능해졌다. 마침 새로 추가되는 기능으로 인해 API 호출 수준이 많이 늘어날 것으로 예상되었고, 테스트 결과를 바탕으로 목표한 수준의 로드에서도 병목이 발생한다면 어느 부분이 문제인지 인지하고 튜닝을 진행할 것을 기대했다. 테스트 목표:..

JPA를 통한 테스트 구현 과정에서 entityManager의 merge()를 사용해 준영속인 엔티티를 다시 영속화하고 변경 감지를 아래처럼 사용하려 했으나 제대로 적용되지 않았다. entityManager.merge(entity); entity.proceed(); // 상태 변경 메서드 entityManager.flush(); 준영속 상태인 엔티티를 다시 영속화하고 상태를 변경하였는데 변경 감지가 동작하지 않았다. merge() 시에 select 쿼리가 나가기는 하나 proceed() 시에 update 쿼리가 나가지는 않았다. proceed() 이후 entityManager.contains(entity)로 영속화 여부를 확인해도 false가 출력되었다. 아래와 같이 순서를 바꾸니 변경 내용을 정상적으로..

이 글에서는 Java Enum의 valueOf()보다 switch ~ case의 사용이 빠른 예시와, Enum의 switch ~ case가 바이트코드 레벨에서 어떻게 최적화되는지를 기술하였다. Spring MVC의 코드를 살펴보던 도중 RequestMethod라는 Enum에서 HTTP 요청 메서드 문자열을 Enum으로 변환할 때 java.lan.Enum.valueOf()를 사용하지 않고 resolve()라는 메서드를 별도로 만들어 사용하는 것을 보았다. // Spring 6.0.6+ public enum RequestMethod { GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE; @Nullable public static RequestMethod resolv..

DB 마이그레이션을 진행하며 동시에 데이터의 일부를 개발 서버의 인메모리로 데이터를 관리할 일이 생겼다. DB와 웹 서버의 변경이 동시에 일어나야 하는 상황에서 다운타임이 없는 무중단 배포를 하는 것은 많이 까다롭다. 변경된 데이터를 다루는 API들에 대해서 정교하게 요청을 구분하고 프록시 서버로 라우팅을 해줘야 한다. 다행히(?) 변경하려는 서버는 운영 서버가 아닌 개발 서버이고, 웹서버도 한 대만 올라간 상태여서 비교적 간단한 중단 배포를 하기로 결정했다. 이 예시는 Jenkins, MySQL과 SpringBoot 서버 환경에서 진행되었으며 예약 명령어들을 사용해 밤 시간에 DB 및 웹 서버를 안전하게 예약하여 재배포하는 방법을 다룬다. DB 스키마 변경 예약하기 DB의 스키마 변경은 MySQL의 이..