Trouble Shooting

📎 프로젝트 진행 중 발생했던 이슈들에 대해 정리한 Wiki

• 정리를 하게 된 배경
• 개념 & 해결 방법(선택한 이유)
• 참고문서

💡 반복되는 코드에 대한 리팩토링 및 디자인 패턴 적용기 - 주현

💡 JPA N+1 - 주현

💡 Join vs Subquery - 지환

펼쳐보기

정리를 하게 된 배경

→ 비슷한 역할을 하는 것 같은 두 기능이 무슨 차이가 있는지?

→ 성능 상의 차이가 존재하는지에 대한 궁금증

차이점과 사용법(개념)

한줄로 요약해보면, 될 수 있으면 join을 사용하는 게 성능적으로 좋다.

subquery의 경우에는 내부 쿼리만으로는 실행이 불가능하기 때문에 외부 쿼리문에 의존해야한다!

SELECT
 name,
 cost
FROM product
WHERE id =
( SELECT product_id
   FROM sale
   WHERE price = 2000
        AND product_id = product.id );

price가 2000인 친구들을 검색하는 subquery는 외부의 product.id를 계속해서 참조해야한다. 따라서 한번에 두개를 모두 들고와서 연산하는 join보다는 성능적으로 안좋을 수밖에 없다.

하지만, subquery만이 가능한 것들이 존재한다.

그렇다면 join으로 변경할 수 있는 것들과 subquery로 사용할 수 있는 것들을 정리해보자!

join과 subquery문 둘다 사용이 가능한 것 → join을 사용하자!

스칼라 서브 쿼리

→ 그냥 join으로 변경이 가능하다.

IN 연산자 안에 있는 서브 쿼리

→ 그냥 join으로 변경이 가능하다.

NOT IN 연산자 안에 있는 서브 쿼리

→ NOT 대신 NULL을 사용함으로써 join으로 변경하자, JOIN하는 위치를 잘 지정해서 JOIN해주자

EXISTS, NOT EXISTS 연산자 안의 상관관계 서브 쿼리

→ NOT 대신 NULL을 사용함으로써 join으로 변경하자, JOIN하는 위치를 잘 지정해서 JOIN해주자

subquery만 사용이 가능한 쿼리

GROUP BY를 사용한 서브 쿼리가 FROM 절에 있을 때

집계된 값을 반환하는 서브쿼리가 WHERE 절에 있을 때

서브 쿼리가 ALL 연산자에 있을 때

• 왼쪽: join, 오른쪽: Subquery

참고자료

https://kimsyoung.tistory.com/entry/SUBQUERY-와-JOIN-의-차이-上

https://kimsyoung.tistory.com/entry/SUBQUERY-와-JOIN-의-차이-下

https://kimsyoung.tistory.com/entry/서브-쿼리의-종류에는-무엇이-있을까

💡 GitHub-Actions를 활용한 CI/CD 구축 - 주현

펼쳐보기

정리를 하게 된 배경

• GitHub-Actions로 CI/CD를 구축할 때 매우 많은 삽질을 하였기 때문에 정리를 통해 되돌아보고자 함

정리

• 블로그 포스팅을 작성하였기 때문에 이로 대체하겠습니다.
• https://zzang9ha.tistory.com/404

💡 Kotlin에서의 데이터 유효성 검증(@Valid, @field) - 주현

펼쳐보기

정리를 하게 된 배경

• 기존 Java & Spring에서 사용하는 Validation 방식이 코틀린에서는 적용되지 않아서 원인을 파악해보기 위해

정리

• Spring에서의 Validation은 필드와 게터(getter) 메소드 모두 검사하기 때문에 어디에 붙여도 예상하는 방식으로 동작을 한다.
  • Java에서 Lombok -> @Getter 등을 사용
• 코틀린은 코드들이 자동으로 생성되기 때문에(getter/setter 등) 어디에 어노테이션을 적용할지 명시적으로 지정해주어야 한다.
  • Validation은 필드의 속성을 검증하기 때문에 @field: NotEmpty() 와 같은 방식으로 사용해야 한다.
• 참고: https://unluckyjung.github.io//kotlin/spring/2022/06/06/kotlin-validation-annotation/

💡 Spring Security - WebSecurity vs HttpSecurity - 지환

펼쳐보기

정리를 하게 된 배경

→ 프론트와의 CORS 설정에서 httpSecurity는 설정이 안되고, WebSecurity는 설정이 되는 이유?

→ 비슷한 개념이지만, 가지고 있는 차이점이 무엇인지 궁금함.

개념 & 해결 방법(선택 이유)

WebSecurity가 HttpSecurity보다 상위 개념이다!

→ 따라서, WebSecurity에서 endpoint를 ignoring한 경우에는 HttpSecurity를 고려하지 않는다!

@Override
public void configure(WebSecurity web) throws Exception {
    web.ignoring().antMatchers("/health", "/health/**");
}
@Override
public void configure(HttpSecurity http) throws Exception {
     http.csrf().disable()
        .authorizeRequests()
        .antMatchers("/health", "/health/**").permitAll()
        .anyRequest().authenticated();
}

WebSecurity

• Endpoints를 ignoring한 경우에는 Spring Security를 아예 무시해버린다.
• Spring Security Filter Chain을 우회하고, 보안 컨텍스트가 설정되지 않는다!

HttpSecurity

• 해당 메소드에서 antMatchers를 통한 endpoints들은 authentication만을 무시한다.
• Request들은 Spring Security Filter Chain에서 허가를 받아서 access가 가능하다!

따라서, HttpSecurity를 사용하여 permitAll()을 진행한다면 Spring Security Filter Chain을 거치기 때문에 비용이 더 많이 든다.

만약, endpoint에 대해서 일반적인 취약점에 대하여 방어가 필요한 경우에는 HttpSecurity를 사용하면 된다.

만약, authentication 목적을 가진 특정한 Request에 대해서만 무시하고 싶을 경우에는 WebSecurity를 사용하면 된다!

→Security에는 인증말고도 다른 것에 대한 filter가 많기 때문에 Security를 통과할 필요가 없는 경우에는 WebSecurity를 사용하고, Security의 다른 filter들은 돌아야하지만, authentication에 관련해서 조정이 필요할 경우에는 HttpSecurity를 사용하면 된다고 이해하면 좋을듯!

동시에 WebSecurity와 HttpSecurity를 설정한 경우에는 WebSecurity가 상위 개념이기 때문에 HttpSecurity에 대한 사항들은 적용되지 않는다!

일반적으로는 login을 할 때나, public pages와 같은 Authentication/Authorization을 할 필요가 없는 endpoint의 경우에는 HttpSecurity를 사용한다!

참고문서

링크

💡 Swagger2 vs Swagger3 - 지환

💡 Spring Data JPA - CascadeType.REMOVE vs orphanRemoval true - 주현

펼쳐보기

정리를 하게 된 배경

• JPA에서 연관 관계에 대해 추가, 삭제 등의 작업을 할 때 사용할 수 있는 옵션인 CascadeType, orphanRemoval 등의 차이점을 파악해보고 정확하게 사용하기 위해

정리

CascadeType.REMOVE

• CascadeType.REMOVE는 부모 엔티티가 삭제되면 자식 엔티티도 같이 삭제
• 부모가 자식의 삭제 생명 주기를 관리
• 하지만 부모 엔티티가 자식 엔티티의 관계를 제거해도 자식 엔티티는 삭제되지 않고 그대로 유지됨

CascadeType 타입

package javax.persistence;

public enum CascadeType {
    ALL,
    PERSIST,
    MERGE,
    REMOVE,
    REFRESH,
    DETACH;

    private CascadeType() {
    }
}

orphanRemoval = true

• orphanRemoval = true 설정 또한 부모 엔티티가 삭제되면 자식 엔티티도 삭제됨
• 하지만 이 옵션은 부모 엔티티가 자식 엔티티의 관계를 제거하면 자식은 고아(orphan)로 취급되어 삭제됨

/* 
Team - Member이 1:N인 경우
 - 1) 부모 엔티티를 삭제하는 경우
 - 2) 부모 엔티티가 자식 엔티티의 관계를 제거하는 경우
*/

// 1)
tempRepository.delete(team);

// 2) CascadeType와는 다르게 orphanRemoval 설정의 경우 아래 쿼리에 대한 delete 쿼리문이 실행이 됨
team.getMembers().remove(1);

참고

• https://tecoble.techcourse.co.kr/post/2021-08-15-jpa-cascadetype-remove-vs-orphanremoval-true/

💡 RDBMS(PostgreSQL Self References Delete) - 주현

펼쳐보기

정리를 하게 된 배경

• RDBMS인 PostgreSQL에서 Self References 하고 있는 테이블에 대해 삭제를 하는 방법에 대해 정리
• 폴더(Folder) 테이블은 댓글/대댓글/대대댓글/... 등과 같이 무한 참조를 할 수 있는 구조로 본인의 테이블을 참조하는 구조
• 테이블 구조

정리

• 문제 상황

• 해결

1. 현재 FK 조회

// Look up the current FK definition 
SELECT pg_get_constraintdef(oid) AS constraint_def
FROM   pg_constraint
WHERE  conrelid = 'public.folder'::regclass  -- assuming public schema
AND    conname = 'fkn0cjh1seljcp0mc4tj1ufh99m';

-- result: "FOREIGN KEY (parent_id) REFERENCES folder(id)"

2. 테이블에서 DELETE CASCADE 속성 추가

ALTER TABLE folder
	DROP CONSTRAINT fkn0cjh1seljcp0mc4tj1ufh99m,
	ADD CONSTRAINT fkn0cjh1seljcp0mc4tj1ufh99m
	FOREIGN KEY (parent_id) REFERENCES folder (id) ON DELETE CASCADE;
	
commit;

3. DELETE CASCADE 속성 확인(pgAdmin4 기준)

• 테이블 > Constraints > FK 우클릭 > Properties ... 클릭
• Action > On delete : CASCADE 확인

4. M:N 중간 테이블인 account_folder 테이블도 위 과정 동일하게 설정

SELECT pg_get_constraintdef(oid) AS constraint_def
FROM   pg_constraint
WHERE  conrelid = 'public.account_folder'::regclass  -- assuming public schema
AND    conname = 'fkq12fenyrw4agbqxdkoe9j9t0';

-- "FOREIGN KEY (folder_id) REFERENCES folder(id)"

ALTER TABLE account_folder
	DROP CONSTRAINT fkq12fenyrw4agbqxdkoe9j9t0,
	ADD CONSTRAINT fkq12fenyrw4agbqxdkoe9j9t0
	FOREIGN KEY (folder_id) REFERENCES folder (id) ON DELETE CASCADE;

commit;

참고

• https://stackoverflow.com/questions/14182079/delete-rows-with-foreign-key-in-postgresql

💡 Hibernate - Database Initialization Strategy - 주현

펼쳐보기

spring.jpa.generate-ddl vs spring.jpa.hibernate.ddl-auto

정리를 하게 된 배경

• JPA에서 데이터베이스 초기화 전략에 대해 두 속성의 차이점에 대해 정확히 파악하고 올바르게 사용하고자 정리

정리

• spring.jpa.generate-ddl
  • true 로 설정 시 서버 시작 시 DDL을 생성하여 연동된 데이터베이스에 반영
  • default values는 false
  • (boolean) true나 false만 선택 할 수 있음
• spring.jpa.hibernate.ddl-auto
  • 데이터베이스 초기화 전략을 보다 세밀하게 제어하는 설정 기능
  • (enum) 타입으로 관리하며 default value는 create-drop
    • none: 아무런 전략을 취하지 않음
    • create-drop: SessionFactory가 시작될 때 드랍 및 생성을 하고, SessionFactory가 종료될 때 드랍을 수행
    • create: SessionFactory가 시작될 때 데이터베이스를 드랍하고, 생성된 DDL을 실행
    • update: 변경된 스키마 적용
    • validate: 변경된 스키마가 존재하면 출력하고 애플리케이션 종료

참고

• https://docs.spring.io/spring-boot/docs/1.1.0.M1/reference/html/howto-database-initialization.html

💡 One table vs Multiple tables - 주현

펼쳐보기

정리를 하게 된 배경

• NoSQL 데이터베이스 테이블을 설계도중 하나의 테이블에 필드 및 리스트를 선언하여 I/O Call을 줄일지, 혹은 테이블을 분리하여 복잡도를 줄일지에 대한 고민
• 결론: I/O Call을 줄여 대용량 상황에서의 부하를 고려하여 Embedding을 사용

정리

• Embedding(하나의 테이블에서 모든 것을 관리)

  • 장점
    • 단일 쿼리로 모든 관련 정보를 얻을 수 있음
    • 어플리케이션 코드에 join이나 $lookup과 같은 코드 구현을 피할 수 있음
    • 단일 원자성의 작업으로 관련 정보들을 업데이트 가능
  • 단점
    • 많은 필드가 연관성이 없다면 documents가 커질수록 많은 오버헤드가 발생
    • MongoDB는 16MB의 Document Size 제한이 존재 -> 단일 도큐먼트에 많은 데이터를 저장할경우 잠재적으로 이러한 제한에 도달할 수 있음

• Referencing(참조)

  • 장점
    • 데이터를 나누기에 보다 작은 도큐먼트 사이즈 유지가 가능
    • 위에서 언급한 16MB 도큐먼트 사이즈 제한에 도달할 가능성이 낮음
    • 자주 접근하지 않는 정보는 쿼리에 필요하지 않음
    • 데이터 중복 감소
  • 단점
    • 관련 도큐먼트를 얻기위해 최소 두 번의 쿼리 혹은 $lookup이 필요함 -> I/O Call 증가

참고

• https://www.mongodb.com/developer/products/mongodb/mongodb-schema-design-best-practices/
• https://zzang9ha.tistory.com/412
• https://dev.gmarket.com/32

💡 MongoDB Schema Design - 지환