https://blog.cruru.kr/keywords/java/ Recent content in Java on 팀 크루루의 개발 이야기 Hugo -- gohugo.io ko-kr Mon, 07 Oct 2024 12:00:00 +0000 https://blog.cruru.kr/docs/backend/read/write-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%B6%84%EB%A6%AC%ED%95%98%EA%B8%B0-0ac3937ba8fd4522988a08574585a8f8/ Mon, 07 Oct 2024 12:00:00 +0000 https://blog.cruru.kr/docs/backend/read/write-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%B6%84%EB%A6%AC%ED%95%98%EA%B8%B0-0ac3937ba8fd4522988a08574585a8f8/ 이 글은 우아한테크코스 백엔드 6기 러쉬에 의해 작성되었습니다. 기존 운영환경에 배포되어 있던 크루루 서비스는 단 하나의 데이터베이스 인스턴스를 사용하고 있었습니다. 하나의 데이터베이스 인스턴스만 사용했을 경우 SPOF라는 치명적인 단점이 존재합니다. 이를 해결하기 위해 기존 데이터베이스를 스케일-아웃 했습니다. 기존 데이터베이스 구조 link 운영환경 데이터베이스가 하나만 존재했습니다. 따라서 read/write 작업이 하나의 데이터베이스에서 이루어지고 있었습니다. 운영 DB를 하나로 운영하면 다음 문제들이 있다고 느꼈습니다. 가용성 확보 불가 기존 운영 환경에서 단 하나의 데이터베이스 인스턴스만 사용했을 때는 데이터베이스가 SPOF가 되는 치명적인 단점이 존재합니다. https://blog.cruru.kr/docs/backend/%EC%8A%A4%ED%94%84%EB%A7%81-osiv%EC%99%80-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%86%8C%EC%8A%A4-%EB%9D%BC%EC%9A%B0%ED%8C%85-%EC%98%A4%EB%A5%98-%ED%95%B4%EA%B2%B0%ED%95%98%EA%B8%B0-7f8129285f564a0a8051cd41d8d72853/ Mon, 07 Oct 2024 11:49:00 +0000 https://blog.cruru.kr/docs/backend/%EC%8A%A4%ED%94%84%EB%A7%81-osiv%EC%99%80-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%86%8C%EC%8A%A4-%EB%9D%BC%EC%9A%B0%ED%8C%85-%EC%98%A4%EB%A5%98-%ED%95%B4%EA%B2%B0%ED%95%98%EA%B8%B0-7f8129285f564a0a8051cd41d8d72853/ 이 글은 우아한테크코스 백엔드 6기 러쉬에 의해 작성되었습니다. 스프링 OSIV와 데이터 소스 라우팅 오류 해결하기 link안녕하세요. 우아한테크코스 6기 백엔드 러쉬입니다. 현재 크루루는 동아리 리크루팅 서비스를 개발하고 있습니다. 기존에 운영 중이던 크루루 서비스는 단일 데이터베이스 인스턴스에 의존하고 있었습니다. 단일 인스턴스 사용에는 SPOF의 위험이 있어, 이 문제를 해결하기 위해 데이터베이스를 스케일아웃 했습니다. 그러나 데이터베이스 스케일 아웃 과정에서 OSIV(Open Session in View)와 관련된 문제가 발생했습니다. 이번 글에서는 OSIV의 개념을 설명하고, 크루루 서비스에서 OSIV 문제를 해결하기 위한 트러블슈팅 과정을 공유하겠습니다. https://blog.cruru.kr/docs/backend/%EC%9D%B4%EB%A9%94%EC%9D%BC-%EB%B0%9C%EC%86%A1-%EB%B9%84%EB%8F%99%EA%B8%B0-%EC%A0%81%EC%9A%A9%EA%B8%B0-fff1e50d803f813bae2eea918fcf0302/ Thu, 26 Sep 2024 09:02:00 +0000 https://blog.cruru.kr/docs/backend/%EC%9D%B4%EB%A9%94%EC%9D%BC-%EB%B0%9C%EC%86%A1-%EB%B9%84%EB%8F%99%EA%B8%B0-%EC%A0%81%EC%9A%A9%EA%B8%B0-fff1e50d803f813bae2eea918fcf0302/ 이 글은 우아한테크코스 백엔드 6기 냥인, 명오에 의해 작성되었습니다. 초기 코드의 문제점 link 💡 2줄 요약 기존의 코드는 API 요청 → 이메일 저장 → 이메일 전송 → API 응답의 흐름으로 이루어졌다. 이메일 저장과 전송이 한 트랜잭션에서 이루어져, DB 커넥션을 길게 점유하는 문제가 존재했다. 우리가 원하는 기능은 이메일 발송에 성공했을 때만 발송 내역이 저장되는 것이었다. 아래와 같이 EmailFacade에 두 로직을 한 메서드로 묶고, @Transactional을 적용하였다. 이렇게 하면 이메일 발송 실패 시 이메일 발송 내역 저장 로직이 롤백된다. https://blog.cruru.kr/docs/backend/github-action%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-jacoco-%EB%8F%84%EC%9E%85%EA%B8%B0-1d9e9c03b70a4c1f895700153c8c81fb/ Fri, 02 Aug 2024 07:08:00 +0000 https://blog.cruru.kr/docs/backend/github-action%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-jacoco-%EB%8F%84%EC%9E%85%EA%B8%B0-1d9e9c03b70a4c1f895700153c8c81fb/ 이 글은 우아한테크코스 6기 팀 ‘크루루’의 백엔드 크루 초코칩, 도비가 작성하였습니다. 도입 배경 link저희는 프로젝트의 비즈니스 로직 개발에 집중하면서 안정적인 기능 작동 여부를 확인하기 위해 테스트 케이스를 검증하고 있습니다. 하지만 개별적으로 테스트가 완료되었는지 테스트 코드를 통해 확인하는 것은 많은 노력이 필요합니다. 또한 매 리뷰마다 작업 브랜치를 로컬로 가져와 테스트 커버리지를 실행하는 것은 번거롭다고 느꼈습니다. 따라서 테스트 코드 커버리지를 정량적으로 측정하고 문서화할 수 있는 도구를 CI 과정에서 자동으로 실행하도록 도입하기로 결정했습니다.