본문 바로가기

전체 글

 (80)
[배포를 진행해보자] Jenkins를 통한 CI/CD 구축 Xshell을 통해 EC2 접속 이제 EC2에 접속하여 실제 배포 환경을 만들어보자. 나는 윈도우 환경에서 EC2에 접속하기위해 Xshell을 활용하였다. Xshell에서 접속하기 위해 다음과 같이 설정을 진행한다. 호스트에는 자신의 퍼블릭 IP을 입력해주고 해당 세션에 대한 이름을 지정해준다.(이름은 임의로 지정해주면 된다.) ​ 그리고 우리는 EC2를 생성할 때 SSH로 접근하기 위한 키 페어를 생성했다. 이를 적용시켜주기 위해 사용자 인증 탭에서 Public Key를 체크해주고 설정 버튼을 누른다. ​ 그리고 가져오기를 통해 해당 키 페어를 가져오고 비밀번호를 입력한다. 비밀번호를 지정하지 않았을 경우 빈 상태로 진행하고 다시 해당 페이지로 돌아와 아래 사진에서 보이는 등록 정보를 클릭해 비밀번호를..
[배포를 진행해보자] EC2와 RDS를 생성하기 EC2 생성하기 어느 정도의 프로젝트 베이스가 마련되어 실질적인 배포를 진행해보려고 한다. 이를 위해 이전에 AWS에 대해 학습한 바 있고 이를 실제 프로젝트로 적용하려고 한다. 먼저, 배포를 위한 EC2를 생성해보자. (AWS에 가입되어 있다고 가정한다.) AWS에서는 프리 티어로 EC2를 무료로 사용할 수 있다. 나는 프리 티어로 이번에 진행을 해볼 것이다. 먼저, EC2에 들어왔다면 인스턴스 시작을 눌러 실제 EC2를 생성해보자. AWS 서비스에서 EC2를 들어가 인스턴스 탭에서 인스턴스 시작을 누르자. ​ 그렇다면 다음과 같이 AMI을 선택하는 화면이 나오게 된다. 여기서 우리는 프리 티어를 사용하여 EC2 환경을 구축할 것이기 때문에 다음과 같이 선택해준다. ​ 프리 티어 용으로 선택하고 넘어가..
JPA에서의 일급 컬렉션 적용 엔티티를 다시 값 타입 컬렉션으로 전환 바로 이전 포스트에서 값 타입 컬렉션을 엔티티로 승격시킨바 있다. 그 이유는 이전 포스트에도 설명했지만 추후 수정이나 추적의 여지가 있기에 해당 부분에 대한 변경을 진행해보았다. 물론, 태그라는 특성 자체가 수정이나 추적의 여지가 큰 건 아니지만 한 번 진행해본 부분이였다. 해당 부분을 수정한 뒤, 협업하는 팀원과 함께 논의를 거쳐 요구사항을 더 명확히 하기로 하였다. 그 결과, 태그 자체를 수정하는 로직은 존재하지 않으며 수정을 거치기 위해서는 단순 삭제 후 새로운 것을 추가하는 방향이며 태그를 추후 업데이트하고 싶다면 업데이트된 태그들을 담은 리스트로 기존 리스트를 대체하는 것이였다. 이 요구사항을 정리해보자. 수정은 불필요하다. 태그 요소들의 변경은 리스트 자..
값 타입 컬렉션 ➡ 엔티티 값 타입 컬렉션을 엔티티로 그전에 이를 적용하게 된 계기부터 살펴보자. 이전 포스트에서 태그에 대한 부분에 대해 @ElementCollection 어노테이션을 통해 태그들을 값 타입 컬렉션으로 관리해주었다. 나는 태그에 관한 부분에 대해 값 타입 컬렉션에서 엔티티로 승격하기로 한 두 가지 이유가 존재했다. ​ 첫 번째는 태그에 대한 요구사항의 변화에 유연하게 대처하고 싶었다. 태그 자체를 값 타입인 String 타입으로 저장하다보니 실제로 변경되거나 삭제되면 더이상 추적할 수 없고 그대로 다른 String으로 변하거나 삭제되어버린다. 추후 태그 자체의 수정을 가능하게하고 추적이 가능하게 할 수 있기 때문에 이에 대한 부분이 생긴다면 더 이상 값 타입으로 유지할 수 없고 엔티티로 승격해야하기에 미리 이 부..
@ElementCollections 사용기 값 타입 컬렉션 사용기 (feat. @ElementColletion) 이번에 값 타입 컬렉션을 사용하게 되었다. 값 타입 컬렉션이란 컬렉션에 값 타입을 담는 것을 의미하는데 값 타입이라는 것이 정확히 무슨 뜻인지에 대해서 알아보자. 값 타입은 흔히 엔티티와 많이 비교된다. 먼저, 우리에게 익숙한 엔티티에 대해서 먼저 알아보자. 엔티티는 우리가 흔히 @Entity로 정의하는 객체이며 @Id라는 어노테이션으로 정의한 PK(식별자)를 통해 계속적으로 추적이 가능하다. 하지만, 값 타입은 식별자라는 개념이 존재하지 않아 추적이 어렵다. 값 타입은 흔히 우리가 사용하는 Integer, String과 같은 자바의 원시 타입과 같은 존재로 우리가 흔히 사용하는 객체와 달리 공유에 안전하고 사이드 이펙트가 발생하지 않..
@Embeddable 활용기 @Embeddable 이번 프로젝트에서 엔티티를 구성하는데 있어 @Embeddable을 활용하였다. 이번에 이를 활용하면서 임베디드 타입을 언제 활용하면 좋은지, 어떤 장점이 존재하는지 좀 더 자세하게 알게 되었다. 이를 이번 포스트에서 정리해보려고 한다. 먼저, 사용한 배경에 대해 먼저 설명하려고 한다. 스터디 커뮤니티에서 스터디라는 엔티티를 구성하기 위한 다양한 요소가 존재했다. 스터디 작성자 스터디 제목 스터디 태그 스터디 썸네일 스터디 관련 학과 스터디 시작 일자 스터디 종료 일자 스터디 모집 일정 스터디 진행 여부 스터디 진행 방식 적어도 위와 같은 요소들을 포함해야했다. 수 많은 요소들이 존재하는데 복잡한 현실 세계 속에서 이를 조금 더 추상화해보기로 했다. 그래서 공통 요소로 추출할 수 있다..
Page, Slice에 대해 Page, Slice 오늘 다룰 포스트는 Page와 Slice이다. 우리는 흔히 어떤 웹을 돌아다녀도 페이징을 처리한 부분을 자주 찾아볼 수 있다. 우리가 개발을 하면서 구글링을 진행할 때 하단 부분을 바라보면 역시 페이징 처리되어 검색 페이지들이 나열되어 있는 모습을 확인할 수 있다. 이렇게 페이징을 처리하는 이유에 대해서 먼저 알아보자. 우리가 수 많은 데이터가 존재한다고 했을 때, 페이징을 처리하지 않고 모든 데이터들을 한 번에 뿌려준다면 어떻게 될까? 해당 데이터를 DB로부터 가져오는데 엄청난 시간이 소요될 것이다. 그 뿐 아니라, 해당 데이터 자체를 들고 있어야 하기에 엄청난 메모리의 소비가 존재할 것이다. 또한, 사용자들이 해당 게시물들을 모두 보게 하게끔 만들기에 용이하지 못하다. 그래서 우..
Cascade vs @Delete Cascade vs @OnDelete 이번 포스트는 이전에 다루었던 Cascade의 연장선이다. 이전에 언급했던 것처럼 생명주기를 공유하는, 어느 한 엔티티의 생명주기에 의존하는 엔티티들이 존재할 경우 Cascade를 사용하면 좋다고 언급했다. 그 이유는 프로젝트 - Cascade의 오해 (tistory.com)에 설명해놓았지만 간단히 다시 살펴보겠다. 어떠한 게시판이 존재한다고 가정하자. 우리가 흔히 잘 알고있듯이 게시판에는 여러개의 게시글, 그 안에 여러개의 댓글이 존재한다. (추천 또한 존재할 수 있다.) 만약, 게시판이 존재한다면 어떻게 될까? 일반적인 경우에는 게시판이 제거됨과 동시에 그 안에 존재하는 게시글, 댓글 (혹은 추천)이 모두 제거될 것이다. 왜냐하면 그들은 게시판의 생명주기에 의존하..

티스토리툴바