공부노트

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

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

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

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

간단한 SpringBoot Rest Api 서버를 배포한 뒤 해당 서버가 설치된 AWS EC2에 대한 모니터링이 필요해졌다. 본 글은 설치 및 운영에 대한 가이드보다 어떠한 배경을 고려하여 도입하게 되었는지를 위주로 작성했다. 고려 사항과 목표 모니터링 시스템 구축 시 고려한 제약 사항은 아래와 같다. 배포한 Api 서버가 초기 단계여서 아직 부하가 거의 없는 상황 EC2에 대한 ssh 접속이 사내 네트워크에서만 접속이 가능하여 외부에서 대시보드로 상황을 확인할 수 있어야 함 보안을 위해 모든 IP에서 접속 가능한 EC2의 인바운드 규칙은 443, 3000, 8080 포트로 제한이 되어있으며 EC2 한 대는 443과 8080은 이미 HTTPS 접속과 Api 서버에 사용 중이어서 사실상 3000번만 사용이..

최근의 프로젝트에서 Spring Data JPA를 통해 상속관계를 사용했으나 적절하지 않음을 깨닫고 언제 슈퍼/서브타입을 사용해야 할지 정리하는 글입니다. 확장(Enhanced, Extended) ER과 슈퍼/서브타입 RDB의 엔티티 릴레이션(ER), 테이블은 정보를 저장하는 기본 단위이다.전통적인 릴레이션 모델링만으로는 현실의 다양한 데이터들을 효율적으로 나타내기 어려워 이를 조금 더 추상화한 확장 ER의 개념이 나오게 되었고 데이터의 상속 관계를 나타내기 위한 슈퍼/서브타입에 대한 개념이 여기에 포함된다.(명칭은 Super class & Subclass라 부르기도 하나 여기서는 슈퍼/서브타입 관계라 칭한다)  전통적인 모델링에서는 어떤 테이블의 하나의 열에 저장된 외래 키를 통해 다른 하나의 테이블만..