https://blog.cruru.kr/author/%EA%B6%8C%EA%B8%B0%ED%98%B8/ Recent content in 권기호 on 팀 크루루의 개발 이야기 Hugo -- gohugo.io ko-kr Thu, 26 Sep 2024 11:18:00 +0000 https://blog.cruru.kr/docs/infra/%EC%9A%B4%EC%98%81-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95%EA%B8%B0-2-flyway-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0-10d1e50d803f8023930eeaee02a1b908/ Thu, 26 Sep 2024 11:18:00 +0000 https://blog.cruru.kr/docs/infra/%EC%9A%B4%EC%98%81-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95%EA%B8%B0-2-flyway-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0-10d1e50d803f8023930eeaee02a1b908/ 이 글은 우아한테크코스 백엔드 6기 초코칩에 의해 작성되었습니다. 데이터베이스 마이그레이션 툴의 필요성 link왜 데이터베이스 마이그레이션 툴이 필요할까요? link필요성을 알아보기 전에, 팀 크루루의 현재 배포 환경을 알아봅시다. 팀 크루루의 프로젝트는 로컬 환경, 개발 환경, 운영 환경으로 총 3가지의 구동 환경을 가지고 있습니다. 개발자의 로컬 환경에서 구현되어 테스트가 마친 소스 코드는 형상관리 툴인 Git을 통해 변경 이력을 관리하고 있습니다. 개발이 완료된 코드가 be/dev 브랜치로 push되면 CI/CD를 통해 개발 서버로 배포됩니다. 개발 서버에서 QA test를 통과한 코드는 be/main 브랜치에 되고, CD를 통해 운영 서버로 배포됩니다. https://blog.cruru.kr/docs/infra/%EC%9A%B4%EC%98%81-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95%EA%B8%B0-1-%EC%84%9C%EB%B2%84-%EA%B5%AC%EC%B6%95-fff1e50d803f81debffff1a2353dde2a/ Thu, 26 Sep 2024 09:03:00 +0000 https://blog.cruru.kr/docs/infra/%EC%9A%B4%EC%98%81-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95%EA%B8%B0-1-%EC%84%9C%EB%B2%84-%EA%B5%AC%EC%B6%95-fff1e50d803f81debffff1a2353dde2a/ 이 글은 우아한테크코스 백엔드 6기 초코칩, 명오, 냥인에 의해 작성되었습니다. 운영 환경 아키텍처 link현재 크루루 서비스의 개발 환경 아키텍처입니다. Public subnet에 위치한 EC2 인스턴스에 Nginx 서버, Spring 서버, DB 서버가 띄워져 있습니다. 위 아키텍처를 운영 환경에 적용하기에는 몇 가지 문제가 있습니다. DB 서버가 Public subnet에 있어 보안에 취약함. Nginx와 Spring 서버가 하나의 인스턴스에 존재하여, 확장성에 제약이 있음. 여러 서버가 하나의 인스턴스에 존재하여, SPOF(Single Point of Failure) 발생 가능성이 있음. 이러한 점을 개선하여 운영 환경은 아래와 같이 설계하였습니다. https://blog.cruru.kr/docs/backend/%EC%BB%A4%EB%B2%84%EB%A7%81-%EC%9D%B8%EB%8D%B1%EC%8A%A4%EB%A1%9C-100%EB%A7%8C-%EA%B1%B4-%EB%8D%B0%EC%9D%B4%ED%84%B0-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-api-%EC%9D%91%EB%8B%B5-%EC%86%8D%EB%8F%84-90-%EA%B0%9C%EC%84%A0%ED%95%98%EA%B8%B0-fff1e50d803f814f93b7f9ab2a83a1b3/ Thu, 26 Sep 2024 09:02:00 +0000 https://blog.cruru.kr/docs/backend/%EC%BB%A4%EB%B2%84%EB%A7%81-%EC%9D%B8%EB%8D%B1%EC%8A%A4%EB%A1%9C-100%EB%A7%8C-%EA%B1%B4-%EB%8D%B0%EC%9D%B4%ED%84%B0-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-api-%EC%9D%91%EB%8B%B5-%EC%86%8D%EB%8F%84-90-%EA%B0%9C%EC%84%A0%ED%95%98%EA%B8%B0-fff1e50d803f814f93b7f9ab2a83a1b3/ 이 글은 우아한테크코스 백엔드 6기 초코칩에 의해 작성되었습니다. 안녕하세요, 우아한테크코스 6기에서 크루루 서비스의 개발을 맡고 있는 권기호입니다. 크루루 서비스는 동아리나 소규모 집단을 위한 리크루팅 서비스로, 서비스의 성장을 대비하여 데이터베이스에 대량 데이터를 삽입하고 성능을 개선하는 작업을 진행하고 있습니다. 이번 글에서는 대량의 데이터 환경에서 API 응답 속도를 빠르게 처리하기 위한 방법과, 이를 해결하기 위해 커버링 인덱스를 적용하여 성능을 개선한 경험을 공유하려고 합니다. 예상 독자 link API의 성능 병목 현상을 어떻게 접근하고 해결할지 고민하는 분들 조인(Join)이 포함된 쿼리에서 성능 최적화를 고민하는 분들 N+1 문제와 지연 로딩(Lazy Loading)으로 인해 발생하는 비효율을 해결하려는 분들 MySQL에서 인덱스를 적용해 쿼리 성능을 개선하고자 하는 분들 100만 건 이상의 데이터 처리 시 쿼리 개수 및 처리 시간을 줄이기 위한 최적화 방법을 찾고 계신 분들 커버링 인덱스와 복합 인덱스가 실제 성능에 미치는 영향을 알고 싶은 분들 배경 link팀 크루루는 서비스 확장을 염두에 두고, 대량의 데이터를 데이터베이스에 삽입하며 성능 개선 작업을 진행하고 있습니다. https://blog.cruru.kr/docs/backend/%ED%8C%80-%ED%81%AC%EB%A3%A8%EB%A3%A8%EC%9D%98-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C%EC%99%80-%EB%B0%B1%EC%97%94%EB%93%9C-%ED%98%91%EC%97%85-4cc19d6ea1e54036845d86dfbd24dad2/ Thu, 08 Aug 2024 04:17:00 +0000 https://blog.cruru.kr/docs/backend/%ED%8C%80-%ED%81%AC%EB%A3%A8%EB%A3%A8%EC%9D%98-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C%EC%99%80-%EB%B0%B1%EC%97%94%EB%93%9C-%ED%98%91%EC%97%85-4cc19d6ea1e54036845d86dfbd24dad2/ 이 글은 우아한테크코스 백엔드 6기 초코칩, 러쉬에 의해 작성되었습니다. 협업 배경 link이번 3차 스프린트의 공통 요구사항에 다음과 같은 내용이 있었습니다. FE에서 BE까지 관통하는 업무 중 최소 하나를 FE / BE 개발자가 짝으로 진행 팀 크루루는 요구사항 충족과 서로 간의 업무를 이해하기 위해 여러 협업을 시도했습니다. Figma 와이어프레임 디자인 및 컴포넌트 작업 link 첫 번째로 시도한 협업은 와이어프레임 디자인과 컴포넌트 작업입니다. 기존에도 와이어프레임 디자인에 대해 함께 토의했지만, 이번에는 Figma를 이용해 직접 참여했습니다. 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 과정에서 자동으로 실행하도록 도입하기로 결정했습니다.