분류 전체보기

[Logging] Slack 알림 메세지 Logger 구현하기

들어가면서 기존에 하루스터디 팀 프로젝트를 진행하면서 스프링 콘솔에서 출력되던 스프링 자체 로깅 메세지와 HTTP 웹 요청 / 응답 메세지 값들을 로깅하고자 했습니다. 이를 수행하기 위해 LogBack에서 기본으로 제공하는 Appender 중 RollingFileAppender를 채택해서 사용했습니다. 기본적으로 서버에 파일로 로깅 데이터를 남긴 후 그라파나로 시각화하여 로그를 조회할 수 있는 시스템을 구축하는 것이 최종적인 목표였기 때문입니다. 그러던 중 서버에서 에러 로그가 발생하면 자동으로 백엔드 팀 슬랙에 알림이 오도록 기능을 추가하고 싶어졌습니다. 현재는 서버에서 에러가 발생했는지 여부를 확인하기 위해 팀원들이 직접 그라파나에 접속해서 확인해야 했는데 이를 매번 주기적으로 확인하기란 쉽지 않습니..

[우아한테크코스] LV3 - 3차 스프린트 회고

들어가면서 3차 스프린트는 서비스 배포와 내부 설계 변경에 집중했던 기간이었다. 처음엔 프론트엔드와 백엔드 모두 기능적으로는 구현이 완료된 상태였기에 배포 과정에서 큰 문제는 없을 것이라 판단했었다. 그러나 예상과는 다르게 기본적인 비즈니스 플로우의 시작점에서부터 에러들이 발생하기 시작했다. 이러한 에러들을 해결하며 기능 연동을 위해 노력하는 한편 백엔드 팀에서는 내부 구조에 대한 논의와 변경이 많이 이뤄졌었는데 이를 정리하고자 한다. 3차 스프린트 CloudFlare 캐시 삭제 문제 하루스터디 팀에서는 프론트엔드와 백엔드 별 기능 구현이 1차적으로 완료되고 나서 정식 배포를 위해 기능 연동을 진행했다. 실제로 연동이 잘 되었는지 확인하기 위해 개발 서버에 배포를 완료한 후 배포된 서비스에 접근해서 직접..

[우아한테크코스] LV3 - 2차 스프린트 회고

들어가면서 4차 스프린트가 진행중인 현재 2차 스프린트 회고를 진행해보고자 한다. 노션에 개인적으로 2차 스프린트에 대한 회고를 메모형식으로 정리해두기는 했었으나 프로젝트 일정이 더 급하다는 이유로 포스팅을 미뤄뒀었다. 시간이 더 흘러서 적어뒀던 메모를 보고도 기억이 나지 않기 전에 스스로를 위해 포스팅한다. 2차 스프린트는 뒤쳐지지 않기 위해 무던히 애를 썼던 기간이었다. 첫 주부터 예비군 훈련으로 내리 4일을 빠지게 되었기에 그 동안 팀에서 진행한 업무들을 동기화하는데 더 노력을 기울일 수 밖에 없었다. 다행인지 불행인지는 모르겠지만 4일 동안 1차 스프린트 데모데이 피드백을 중심으로 서비스의 방향성을 뒤집는 기획 회의만 이뤄졌었다. 개발적인 부분이 먼저 시작되었으면 더 쫓아가기 힘들었을텐데 딱 캠퍼..

[우아한테크코스] LV2 - 웹 장바구니 협업 미션 회고

들어가면서 (임시저장만 해두고 발행을 누르지 않은 것을 반성합니다) 우아한테크코스 레벨2의 마지막 미션은 웹 장바구니 협업 미션이었다. 이번 페어는 키아라와 주드였다. 프론트, 안드로이드 크루들과도 함께 팀을 이루어 미션을 진행하는 방식이었는데 랜덤 배정 결과 프론트 크루들과 함께 미션을 진행하게 되었다. step 0, 1 에서는 서버를 AWS 상에 배포하고 CORS 문제를 해결하는 과정이 핵심이었다. 그리고 step2에서는 장바구니에 담은 물품들을 실제로 주문을 할 수 있도록 기능을 추가 구현하는 것이었다. 이와 더불어 할인 정책과 관련된 기능을 선택해서 추가하는 것 또한 요구사항이었는데 우리는 포인트 적립 및 사용 정책을 구현하는 것을 결정했다. 같이 협업을 하게된 프론트 크루들은 솔로스타와 네이브였..

[Logging] Logback을 이용한 기본적인 로깅하기

들어가면서 현재 진행중인 팀 프로젝트 하루스터디 서비스는 배포가 완료된 상태입니다. 배포 완료의 기쁨을 느꼈던 것도 잠시, 저희는 실제 배포 환경에서 서비스를 운영하면서 마주치는 버그와 이슈 상황들을 바로 마주하게 되었습니다. 로컬 환경에서라면 인텔리제이의 debug 기능을 활용하거나 정말 단순하게는 System.out을 통해 원하는 값을 직접 출력 해볼 수도 있을 것입니다. 하지만 현재 하루스터디 서비스는 배포 서버에 이미 배포가 되어 있는 상태라서 기존 방식으로는 버그와 이슈 상황들에 대한 원인 파악이 쉽지 않았습니다. 따라서 이를 해결하기 위해 로깅 기능을 구현해서 도입하기로 결정했습니다. 본 포스팅은 팀 로깅 작업을 진행하기 전 개인적으로 진행한 학습 내용을 정리하기 위한 것임을 밝힙니다. SLF..

[Spring Data JPA] Save() 메서드 persist VS merge

Spring Data Jpa에서 엔티티를 영속화 하기 위해서 repository 인터페이스를 만들고 save 메서드를 정의해 사용하는 것이 일반적이다. 그런데 학습과정에서 JpaRepository 인터페이스의 save 메서드 구현 코드를 접하게 되었다. 아래에 나온 코드는 org.springframework.data.repository.CrudRepository 의 기본 구현체로 제공되는 SimpleJpaRepository 클래스에 구현되어 있는 save() 메서드다. @Transactional @Override public S save(S entity) { Assert.notNull(entity, "Entity must not be null"); if (entityInformation.isNew(ent..

엔티티 간 상속관계를 DB 모델로 구현하기 위해 Join 전략을 선택하는 이유에 대한 고찰

들어가면서 위 이미지는 현재 하루스터디의 DDL을 도식화한 ERD입니다. 간략하게 각 테이블을 엔티티 단위로 묶어서 설명해보면 다음과 같습니다. study : 하루스터디 서비스에서 개설되는 스터디에 대한 정보를 관리 member_progress : 개설된 스터디에서 참여자들의 진행 정보를 관리 member_record : 참여자들이 스터디의 각 사이클마다 진행한 사전 계획과 회고를 관리 member : 참여자들의 개인 정보를 관리 participant_code : 스터디 방 개설 후 입장 시 필요한 참여코드를 관리 여기에서 주목할 것은 study, member_progress, member_record 테이블입니다. 현재 ERD에서는 한 눈에 알아보기 힘들긴 하지만 이 테이블들은 전부 Join전략을 통해..

브랜치 전략에서 squash and merge 방식 사용에 대한 고찰

들어가면서 우아한테크코스 레벨3에서 현재 팀 프로젝트(이하 하루스터디)를 진행하고 있다. 하루스터디 서비스 개발을 시작하기 전에 서비스 기획과 더불어서 팀 컨벤션을 정하는 회의를 많이 진행했다. 그 중 Git 브랜치 전략도 팀 컨벤션으로 정하였는데 이 기간에 예비군 훈련과 겹쳐서 직접적으로 팀원들과 브랜치 전략을 연습하고 정하는 시간에 함께하지 못했다. 이후 팀원들이 정리해둔 문서를 보며 혼자 브랜치 전략을 연습하던 와중 마주한 문제가 있었는데 이를 정리하고자 한다. squash and merge 사용 시 직면한 문제상황 위 이미지에 나온 것 처럼, main 브랜치에서 프로덕션 코드를 관리하고 develop 브랜치에서 기능 구현 작업들이 완료되면 main 브랜치에 PR을 날리는 방식으로 운영한다고 가정했..