https://blog.cruru.kr/author/%EB%83%A5%EC%9D%B8%EC%B5%9C%EA%B0%80%ED%9D%AC/ Recent content in 냥인(최가희) on 팀 크루루의 개발 이야기 Hugo -- gohugo.io ko-kr Tue, 22 Oct 2024 04:38:00 +0000 https://blog.cruru.kr/docs/infra/%EB%B6%80%ED%95%98-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A1%9C-%EC%84%B1%EB%8A%A5-%EA%B0%9C%EC%84%A0%ED%95%98%EA%B8%B0-60bb8cbedc2743179befc3af6eb42037/ Tue, 22 Oct 2024 04:38:00 +0000 https://blog.cruru.kr/docs/infra/%EB%B6%80%ED%95%98-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A1%9C-%EC%84%B1%EB%8A%A5-%EA%B0%9C%EC%84%A0%ED%95%98%EA%B8%B0-60bb8cbedc2743179befc3af6eb42037/ 이 글은 우아한테크코스 백엔드 6기 냥인, 명오에 의해 작성되었습니다. 대규모 트래픽을 처리하기 위해서는 웹 애플리케이션의 성능을 최적화하는 것이 중요합니다. 서비스가 성장하는 상황을 연습하기 위해, 부하 테스트를 진행하며 톰캣과 HikariCP 설정을 조정한 경험을 공유합니다. 부하 테스트 도구 선정 link크루루는 부하 테스트 도구로 k6를 선택했습니다. 저희가 비교한 도구는 제일 대중적으로 사용되는 3가지이고, 아래는 비교한 내용입니다. 비교 Jmeter K6 Locust 스크립트 언어 XML JS Python 성능 순위 3 1 2 결과 확인 실시간 모니터링 제약 그라파나로 확인 가능 웹으로 실시간 확인 가능 현재 이미 그라파나가 구축되어 있고, 다른 언어에 비해 비교적 JS가 익숙했기 때문에 성능이 제일 좋은 K6를 사용했습니다. https://blog.cruru.kr/docs/infra/%EB%AA%A8%EB%8B%88%ED%84%B0%EB%A7%81-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%EC%B6%95%EA%B8%B0-1%ED%8E%B8-metric-fff1e50d803f81e5b0c2c484b3033ac9/ Thu, 26 Sep 2024 09:03:00 +0000 https://blog.cruru.kr/docs/infra/%EB%AA%A8%EB%8B%88%ED%84%B0%EB%A7%81-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%EC%B6%95%EA%B8%B0-1%ED%8E%B8-metric-fff1e50d803f81e5b0c2c484b3033ac9/ 이 글은 우아한테크코스 백엔드 6기 냥인, 러쉬, 명오에 의해 작성되었습니다. 구축 배경 link 3차: 서비스 운영 환경 구축 로깅 프레임워크 적용 API 문서 작성 (로그, 메트릭) 모니터링 대시보드 구성 백엔드 3차 요구사항으로 ‘모니터링 대시보드 구성하기’가 주어졌습니다. 팀 크루루는 아직 개발 환경만 구축되어 있기 때문에 개발 환경에 모니터링을 구축하였습니다. 모니터링 도구 선택 기준 link 💡 ▶︎ 요구사항에서 언급된 대로 빠르게 구축할 수 있어야 한다. ▶︎ 스프링 부트와 연동하기 쉬워야 한다. https://blog.cruru.kr/docs/infra/%EB%AA%A8%EB%8B%88%ED%84%B0%EB%A7%81-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%EC%B6%95%EA%B8%B0-2%ED%8E%B8-log-fff1e50d803f81188695f557c48abfde/ Thu, 26 Sep 2024 09:03:00 +0000 https://blog.cruru.kr/docs/infra/%EB%AA%A8%EB%8B%88%ED%84%B0%EB%A7%81-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%EC%B6%95%EA%B8%B0-2%ED%8E%B8-log-fff1e50d803f81188695f557c48abfde/ 이 글은 우아한테크코스 백엔드 6기 냥인, 러쉬, 명오에 의해 작성되었습니다. 로깅 모니터링 도구 선택 기준 link로그 모니터링의 경우에는 로그 프레임워크는 Logback, 모니터링 도구로는 Loki와 Promtail, Grafana를 사용했습니다. 메트릭 모니터링 시스템을 구축할 때와 마찬가지로 아래와 같은 기준을 적용하였습니다. ▶︎ 요구사항에서 언급된 대로 빠르게 구축할 수 있어야 한다. ▶︎ 스프링 부트와 연동하기 쉬워야 한다. Logback을 사용한 이유는 단순히 Spring boot에 기본으로 내장되어 있는 로깅 라이브러리를 사용하기 위함이었습니다. Loki의 경우는 이미 Grafana를 사용하여 메트릭 대시보드를 구축해놨기 때문에 자연스럽게 후보군에 올랐고, 위 기준에 부합하였기 때문에 도입하기로 결정하였습니다. 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/infra/%EC%9A%B4%EC%98%81-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95%EA%B8%B0-3-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0-%EB%B0%8F-https-%EC%A0%81%EC%9A%A9nginx-reverse-proxy-fff1e50d803f81a6a7c2c3ae36634ee3/ 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-3-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0-%EB%B0%8F-https-%EC%A0%81%EC%9A%A9nginx-reverse-proxy-fff1e50d803f81a6a7c2c3ae36634ee3/ 이 글은 우아한테크코스 백엔드 6기 냥인, 명오에 의해 작성되었습니다. 사전 준비 사항 linkNginx 서버 구축(EC2 인스턴스 생성) link먼저 Nginx 서버를 띄울 EC2 인스턴스를 생성합니다. 이 서버는 운영 서버와 마찬가지로 Public Subnet에 위치시킵니다. EC2 인스턴스에 Nginx 설치 sudo apt install nginx Nginx 설치 확인 Nginx의 버전 체크를 통해 설치가 잘 되었는지 확인합니다. sudo nginx -v Nginx 실행 sudo service nginx start Nginx를 실행한 후 웹 브라우저에서 EC2 인스턴스의 Public IP로 접근하면 아래와 같은 화면을 확인할 수 있습니다. 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을 적용하였다. 이렇게 하면 이메일 발송 실패 시 이메일 발송 내역 저장 로직이 롤백된다.