개발 일기

5주간 개인 프로젝트를 진행하였다. 혼자서 해보는 개인 프로젝트가 처음이라 시작하기 전 약간의 설렘이 있었지만 프로젝트 경험이 적어 혼자 해낼 수 있을까하는 두려움, 막막함이 더 컸다. 다행히 같은 주제로 프로젝트를 진행한 다른 분들의 도움을 많이 받기도 하고 내가 아는 선에서 도움을 줄 수 있는 부분도 있어서 개인 프로젝트지만 팀 프로젝트처럼 으쌰으쌰하면서 매일 늦은 시간까지 남아 프로젝트를 진행할 수 있었다. 이제 마무리하는 시점에서 프로젝트 진행 타임테이블, 내용, 기술적 의사결정과 이전에 비해 더 나아진 점, 아쉬운 점을 정리해보고자 한다. 일정 2024. 01. 24. ~ 2024. 02. 28.(5주) 기술적 의사결정 Java 17 운영체제나 플랫폼에 독립적인 프로그래밍 언어로 객체지향적 설계..

[성능 테스트][트러블 슈팅] Artillery를 이용한 부하 테스트 - 2 (성능 저하 요인 찾기) [성능 테스트] Artillery를 이용한 부하 테스트 -1 (테스트 설정, 결과 보기) 테스트 도구 선택 - Artillery Artillery는 Node.js 기반의 성능 및 부하 테스트를 위한 오픈 소스 도구로 HTTP, WebSocket 및 TCP 등 다 writtenbyrla.tistory.com 지난 글에서는 부하 테스트를 통해 문제를 인지하고 성능 저하에 영향을 미칠만한 요인을 추측해 보았고, 이번 글에서는 해결하는 과정과 결과를 담아보고자 한다. ++ 모든 부하 테스트는 외부적인 요인에 영향받지 않기 위해 다른 요인들은 건드리지 않고 일정한 환경에서 진행했다. 시도한 방법 1 - fetch..

[성능 테스트] Artillery를 이용한 부하 테스트 -1 (테스트 설정, 결과 보기) 테스트 도구 선택 - Artillery Artillery는 Node.js 기반의 성능 및 부하 테스트를 위한 오픈 소스 도구로 HTTP, WebSocket 및 TCP 등 다양한 프로토콜을 사용하여 테스트가 가능하며 YAML을 사용하여 시나리오 writtenbyrla.tistory.com Artillery를 이용하여 간단하게 테스트를 해 본 지난 글에 이어 프로젝트에 부하 테스트를 적용시켜 보는 이번 글 게시글 기능이 유저, 멀티미디어, 게시글 좋아요까지 여러 엔티티와 연관관계로 묶여 있는 데다가 피드 서비스의 핵심 기능이기 때문에 게시글 전체 목록을 받아오는 API를 선택해서 성능을 제대로 측정해 보기로 했다. 성능..

테스트 도구 선택 - Artillery Artillery는 Node.js 기반의 성능 및 부하 테스트를 위한 오픈 소스 도구로 HTTP, WebSocket 및 TCP 등 다양한 프로토콜을 사용하여 테스트가 가능하며 YAML을 사용하여 시나리오를 정의하므로 테스트 시나리오를 쉽게 작성할 수 있다는 장점이 있다. 또한 분산 테스트를 지원하여 여러 호스트에서 동시에 테스트를 실행하고 결과를 집계할 수 있으며 이를 통해 대규모 시스템의 성능을 테스트할 수 있다고 한다. Apach의 JMeter도 많이 사용하는 것 같았으나 Artillery가 좀 더 초심자가 사용하기에 쉬운 편이기도 하고 사용법에 대한 리소스도 많이 있어 Artillery를 이용하였다. 처음 해보는 부하 테스 트인 만큼 테스트 도구를 사용하는 데..

단위 테스트 이전 글 [단위 테스트/Mockito] 게시글 서비스 레이어 단위 테스트 - 1 (with ReflectionTestUtils) MockMvc를 이용하여 컨트롤러 통합테스트를 끝냈다. 테스트를 위한 별도 DB를 생성하여 모든 예외사항에 대해 전체 테스트를 끝냈는데, 아무리 생각해도 비즈니스 로직은 서비스단에 포함되어 있 writtenbyrla.tistory.com Mockito를 사용해서 서비스 레이어 단위 테스트를 열심히 하다가 또 한 번 위기를 겪었다. Mockito에서 Mock 객체를 사용하기 위해서 테스트 파일에 어노테이션을 달아주는데, 나는 계속해서 JUnit4 방식인 @RunWith(MockitoJUnitRunner.class) 어노테이션을 달고 있었고, JUnit5 방식은 @Ex..

MockMvc를 이용하여 컨트롤러 통합테스트를 끝냈다. [통합 테스트/MockMvc] 어쩌다 회원 가입만 290번 처음 해보는 통합테스트. 개발용 DB의 영향을 최소화하고자 테스트용 DB를 따로 만들어 연결하고 테스트를 진행하였다. 문제 상황 1. [ DB 연결 문제] 개발용 DB를 MySQL로 사용하고 있기 때문에 혹시 writtenbyrla.tistory.com 테스트를 위한 별도 DB를 생성하여 모든 예외사항에 대해 전체 테스트를 끝냈는데, 아무리 생각해도 비즈니스 로직은 서비스단에 포함되어 있으면서 테스트 하는동안 db에 영향을 많이 받는다는 생각이 들었다. 컨트롤러에서 통합 테스트를 하는 것이 필요없는 것은 아니지만 이미 개발을 진행하면서 postman으로 테스트해본 내용과 거의 일치하기 때문에..

처음 해보는 통합테스트. 개발용 DB의 영향을 최소화하고자 테스트용 DB를 따로 만들어 연결하고 테스트를 진행하였다. 문제 상황 1. [ DB 연결 문제] 개발용 DB를 MySQL로 사용하고 있기 때문에 혹시나 영향이 갈까 봐 H2를 이용하여 테스트용 DB를 분리하였다. 하지만 H2에서는 user를 예약어로 사용하고 있어 User 엔티티 생성에 있어 문제가 생겼고 MySQL로 변경하여 테스트용 스키마를 별도 생성해서 연결해 주었다. 2. [ Primary Key 자동생성 문제 ] @BeforeEach 어노테이션으로 테스트 실행시마다 유저를 생성하여 테스트를 진행하고자 했는데, 언젠가부터 처음에 통과하던 테스트 코드도 다시 실행해 보면 다 유저정보를 찾을 수 없다는 오류가 뜨고, 나중에는 결국 모두 실패하..

++ Spring Security와 Jwt를 곁들인... 기본적인 api 구현을 끝내고 회원가입, 로그인 화면단 연결을 목표로 타임리프를 이용하여 프론트 작업을 하였으나 로그인 후 페이지 이동시 403 Forbidden 오류로 이 작업을 이틀정도 핸들링했다. ajax나 fetch를 이용한 javascript 문법 미숙으로 인한 오류인 줄은 알고 있었으나 거기에 더해 토큰을 운용하는 과정에서 클라이언트단과 서버단에서 헤더, 쿠키방식을 혼용했기때문에 발생한 대참사였다. 사실 react와 같은 프레임워크를 이용하여 클라이언트단 서버를 분리하면 route를 이용해서 리다이렉션을 처리할 수 있을텐데, 템플릿 엔진 + rest api 방식을 이용하다보니 페이지 넘김에 있어서 꼬이고 꼬였고 프로젝트를 한번 엎고 다시..

💡 프로젝트 환경 spring boot 3.2.2 spring-cloud-starter-aws:2.2.6.RELEASE 1-1. AWS S3 버킷 만들기 1) aws 콘솔에서 회원가입 후 S3 검색해 버킷을 만듦 https://aws.amazon.com/ko/console/ AWS Management Console AWS Support 플랜은 AWS로 성공하는 데 도움이 되는 다양한 도구, 프로그램 및 전문 지식에 대한 액세스의 조합을 제공합니다. aws.amazon.com 실무에서는 보통 액세스 차단을 한다고 함, 테스트를 위해서 퍼블릭 상태로 둠 2) 버킷 정책 생성 권한 - 버킷 정책 편집 - 정책 생성기 클릭 Actions에는 GetObject 선택해주면 됨 현재 이미 정책을 생성해놓아서 유효하지..

패기롭게 주어진 자료를 참고해서 JWT, Security를 써보면서 유저기능(회원가입, 로그인, 로그아웃) 구현을 끝냈었다. 하지만 내가 참고하던 자료는 필터를 너무나도 많이 커스텀해서 쓰고 있었고 유저기능 구현을 다 하고 나서 다른 기능을 구현하려니 자꾸 막혔다. 문제는 커스텀한 필터에 대한 이해도가 없어서 내 프로젝트에 맞게 어떤식으로 적용해야 할지를 모르겠다는 거였다. 거기다가 뷰까지 만들어서 연결을 하려고 하니 도저히 진도가 나가지 않아서 과감한 선택이 필요했다. 그래서 7일차에 결심하고 기존 프로젝트를 엎어서 8일차부터 다시 시작했다. 타임라인을 정리해보자면 1/31 ~ 2/1 💡 스프링부트 입문 강의 완강 스프링 부트 프로젝트 설정, 구조에 대한 이해 mvc 패턴 이용한 컨트롤러 작성 rest..