https://blog.cruru.kr/series/java-spring-%EA%B0%9C%EB%B0%9C-%EC%8B%9C%EB%A6%AC%EC%A6%88/ Recent content in Java Spring 개발 시리즈 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/restdocs-%EB%8F%84%EC%9E%85%ED%95%98%EA%B8%B0-fff1e50d803f8139a486c56e6c397adb/ Thu, 26 Sep 2024 09:02:00 +0000 https://blog.cruru.kr/docs/backend/restdocs-%EB%8F%84%EC%9E%85%ED%95%98%EA%B8%B0-fff1e50d803f8139a486c56e6c397adb/ 이 포스팅은 우아한테크코스 6기 팀 ‘크루루’의 백엔드 크루 명오가 작성하였습니다. 도입 배경 link저희는 자동으로 API 문서를 만들기 위해 Swagger와 RESTDocs 사이에서 고민했습니다. 저희가 느낀 각각의 장단점은 아래와 같습니다. Swagger 장점: 프론트 입장에서 보기 편하고, API 테스트하기 편합니다. 단점: 프로덕션 코드에 기능과 관련 없는 어노테이션이 들어갑니다. RESTDocs 장점: API에 대한 테스트를 무조건 작성해야 하므로, 엣지 케이스에 대한 테스트를 까먹는 경우를 방지할 수 있습니다. 단점: Swagger보다 시간이 더 많이 소요됩니다. 저희 팀은 Postman을 사용하여 API를 테스트하기 때문에, Swagger의 장점이 살아나지 않는다고 생각하여 RESTDocs를 채택하게 되었습니다.