[우리집 가족 커뮤니티 웹 서비스 프로젝트] 기술 정리 - 초기구성

우리 가족의 커뮤니티 웹 서비스를 만들기 위해 먼저 Server 작업을 하고 있는 것이에요.

코딩을 하면서 내용을 정리해서 나중에 주니 하랑도 확인하고, 여기 오신 여러분들과도 공유하고 싶은 것이에요!

그럼 시작해 보겠습니다!

 

해당 프로젝트에 대한 Source Code는 '주니하랑 Git Hub'에서 확인하실 수 있습니다.

 

 

---

 

 

 

🗂 목차(INDEX)
       1.  초기구성

       2. Spring Security 초기 구성

       3. Interceptor 설정

.      4. 초기 Domain 설정

 

 

 

 

 

---

 

🚀 Build.gradle

 

먼저 주니하랑은 이번 프로젝트를 위해 이러한 서비스를 이용하고 싶은 것이에요.

객체 지향적 DB 관리를 위해 Spring DATA JPA를 사용할 것이고, RESTFul하게 웹 서비스를 만들기 위해 hatoas를 적용시킬 것이에요. 그리고, 소셜 로그인 기능 구현을 위해 oauth2를 사용할 것이고, jwt 기술을 이용한 로그인 및 회원가입 구현을 위해 Spring Securiry 기술을 사용할 것이에요.

그리고, Mail 인증을 적용해 보기 위해 mail 의존성을 받고, Spring에 내장된 Tomcat 사용을 위해 Spring-boot-web의 의존성을 추가한 것이에요.

 

그리고, Model Mapper라는 것을 추가했답니다!

Model Mapper란 무엇일까요?

이것은 어떤 Object(객체)에 있는 필드값들을 자동으로 원하는 Object로 Mapping 시켜주는 것이에요.

우리가 코딩할 때, getter, setter를 이용하는데 있어 원하는 입력과 출력이 다를 때, 출력(Output) Object에 입력(Input) 필드 값들 중 원하는 필드들을 하나씩 넣어주는 과정을 다들 경험 해 보셨을 것이에요.

이런 것은 일일이 getter와 setter를 하나하나 작성해 주어야 하는데, 이런 것을 개발자는 좋아하지 않는 것이에요! 

바로 이 일을 줄이기 위해 사용하는 것이 Model Mapper랍니다!

 

그 다음 의존성은 Swagger를 사용하기 위한 의존성 입니다!

Swagger는 Back End 개발자가 개발한 내용을 문서화 하여 Front End 개발자 분들이 개발하실 때, 어떤식으로 개발하면 되는지 참고 하기 위해 사용하는 것이에요.

 

그 다음으로는 Request 유효성을 검사하기 위해 Spring Validation을 추가 해 주었답니다!

이것을 통해서 Request로 오는 객체(DTO)를 검증할 수 있는 것이에요.

Data 검증(Validation)은 여러 계층(Layer)에 걸쳐 발생하는 아주 흔한 작업인 것이며, 꼭 필요한 작업인 것이에요.

 

이것을 추가하게 되면 Bean Validation이라는 것을 사용할 수 있는데, 이것은 Class 필드에 특정 Annotaion을 적용하여 필드가 갖는 제약 조건을 정의하는 구조로 검사를 진행하는 것이에요.

Validator가 그 Class로 생성된 객체의 유효성 여부를 확인하게 되고, 어떤 비즈니스적 로직에 대한 검증이 아닌, 객체 자체의 필드에 대한 검증을 하는 것이에요.

 

그 다음은 주니하랑은 TEST 서버에서 사용하게 될 DB를 시놀로지 NAS에 도커를 구축하고, MariaDB를 올려 놓은 것이에요. 나중에 QA TEST 등을 진행할 때, 사용하기 위해 DEV DB와 별도로 사용하기 위해 MariaDB 의존성을 추가 하였습니다!

 

그리고, TEST를 할 때 사용할 JUnit4에 의존성을 받았고, jwt를 통해 토큰 기반에 안전한 로그인 기능을 구현하기 위해 해당 의존성을 추가한 것이에요.

 

그리고, Getter나, 생성자를 편하게 사용하기 위해 lombok 의존성을 추가했고, json기반에 API 통신을 위해 해당 의존성을 추가 했답니다!

 

 

 

JPA를 통해서 객체 지향적으로 DB에 Query를 날릴 수 있는 것이에요. RDBMS와 JAVA의 객체 지향이라는 것은 패러다임 불일치라는 Issue가 있어 이것을 해결 해 주는 아주 좋은 친구인데요!

하지만, JPA를 통해서 모든 CRUD를 구성하기는 어렵다는 한계가 있는 것이에요.

JOIN 등을 할 때는 네이티브 SQL을 쓰거나, Jooq, Querydsl 등을 사용하는데, 주니하랑은 Querydsl로 진행 해 보려는 것이에요.

 

 

🚀 application.properties or yml

jwt:
  secret: abc
spring:
  mail:
    host: smtp.gmail.com
    port: 587
    username: junyharang8592@gmail.com
    password: pwd
    properties:
      mail:
        smtp:
          auth: true
          starttls:
            enable: true
springdoc:
  paths-to-exclude=/swagger-resources/**:

위와 같이 application.yml에 jwt와 Mail 인증 등을 사용할 수 있는 설정을 해 준 것이에요.

spring.jpa.hibernate.ddl-auto=update
spring.jpa.properties.hibernate.format_sql=true
spring.jpa.show-sql=true

# DEV DataBase
spring.h2.console.enabled=true
spring.datasource.devdb.driver-class-name=org.h2.Driver
spring.datasource.devdb.jdbc-url=jdbc:h2:tcp://localhost/~/hongga
spring.datasource.devdb.username=sa
spring.datasource.devdb.password=
spring.jpa.devdb.database-platform=org.hibernate.dialect.H2Dialect

# Test DataBase
spring.datasource.testdb.driver-class-name=org.mariadb.jdbc.Driver
spring.datasource.testdb.jdbc-url=jdbc:mariadb://localhost:3389/hongga
spring.datasource.testdb.username=junyharang
spring.datasource.testdb.password=password
spring.jpa.testdb.database-platform=org.hibernate.dialect.MariaDBDialect

# File Upload Config
# File Saver Enable
spring.servlet.multipart.enabled=true
# Upload File Save Path
spring.servlet.multipart.location=/resources/imgUpload
com.hongga.upload.path =/resources/imgUpload
# One Thing Upload File Size
spring.servlet.multipart.max-request-size=50MB
# Upload File Max Size
spring.servlet.multipart.max-file-size=100MB

 

위의 application.properties에는 DB 관련 설정이 두 개가 있는 것이에요.
하나는 Mac Book으로 개발 중인 주니하랑의 '맥프기'에 H2 DBMS를 설치하고, 그 곳에 설정을 맞춰 개발용으로 쓰기 위함이고, 또 하나는 차 후 Test용으로 시놀로지 NAS에 도커로 올려 놓은 Maria DB를 설정 해 둔 것이에요.

운영 단계 까지 가면 DB는 하나 더 추가하여 운영 DB 또한 추가 해 줄 것 입니다.

그리고, 그 아래는 Image 등을 올릴 수 있게 File Upload 설정을 해 준 것이에요.

 

 

🚀 Config

 

Config 관련 Directory Tree 구조

 

 

    🔽  ModelMapperConfig

위에서도 이야기한 바와 같은 이유와 더불어 ModelMapper는 API가 제공하는 DTO를 그냥 사용하게 되면 문제가 발생하기 때문에 사용하는 이유가 큰 것이에요. API는 언제든지 변경될 수 있는데, API가 제공하는 DTO 그대로 사용해서 Application을 작성하게 되면 API가 변경 되었을 때, 모든 코드를 바꿔줘야 한다는 유지 보수에 치명적인 문제가 생겨 버리는 것이에요.

그렇기 때문에 API DTO를 이름만 바꿔(동일한 Data File를 갖는다.) WrapDTO로 변환해서 사용을 하는 것이에요. 그리고, Store 역할을 하는 객체가 API Call과 DTO < - > WrapDTO 간 변환을 담당해서 API Call 이라는 책임을 Store라는 곳에 집약 시킬 수 있는 것이에요. 이렇게 되면 API가 변경되어도 해당 책임을 담당하는 Store만 변경하면 되는 것이에요.

이 때, Store에서 DTO < - > WrapDTO를 해줘야 하는데, 필드가 한 두 개면 그냥 Setter로 넣어도 되지만, 위에 의존성에서 이야기 했듯이 수가 많다면 개발자가 싫어하는 단순 노가다가 시작되는 것이에요.

그렇기 때문에 간단한 Mapping의 경우 Model Mapper라는 Mapping을 도와주는 Class를 사용하는 것이랍니다!

Class A {
	int age;
} // class A 끝

Class B {
	int age;
} // class B 끝

ModelMapper mapper = new ModelMapper();

A a = new A();
a.age = 10;

B b = mapper.map(a, B.class);​

예시를 들면 위와 같은 Code가 있을 때, A 객체가 갖고 있는 필드를 그대로 B에 복사할 수 있는 것이에요.
필드 이름이 같다면 값이 그대로 Mapping 되기 때문인 것이에요.
b.setAge(a.getAge()); 와 같은 반복적인 Code는 필요가 없는 것이에요.

• Model Mapper Role
  기본적으로 필드 이름이 같다면 Mapping이 되나, 다양한 규칙이 아래와 같이 존재하는 것이에요.

  

  
  
  

  

  
  주니하랑은 ModelMapper를 사용하기 위해 위와 같이 Config Class를 만들어 주었답니다.
  
  
  
  
  

    🔽  QuerydslConfig

 

 

 

 

    🔽  SpringAsyncConfig

 

이 Config를 만든 이유는 바로 비동기 서비스를 만들기 위함이에요!

그럼 비동기와 그에 반대인 동기는 어떤 차이점이 있을까요?

동기 (Synchronous: 동시에 일어나는)
동기 방식은 말 그대로 동시에 어떤 일이 일어나는 것이에요. 요청과 그 결과가 동시에 일어난다는 것입니다.
이 방식은 요청을 했을 때, 시간이 얼마나 걸리던지 요청한 그 자리에서 최대한 빨리 결과가 주어져야 한답니다.
예를 들면 A Node와 B Node 사이 작업 처리 단위(Transaction)을 동시에 맞추겠다. 가 있겠네요!

비동기 (Asynchronous : 동시에 일어나지 않는)
비 동기는 동시에 일어나지 않는다는 것을 의미하는 것이에요.
요청과 결과가 동시에 일어나지 않을 것이라는 약속이랍니다. 즉, 요청한 그 자리에서 겨로가가 주어지지 않는 것이에요.
예를 들면 A Node와 B Node 사이 작업 처리 단위를 동시에 맞추지 않겠다. 가 있겠네요!

이 두 친구는 각각의 장, 단점을 갖고 있는 것이에요.

먼저, 동기 방식은 설계가 매우 간단하고, 직관적이지만, 결과가 주어질 때까지 아무것도 할 수 없고, 대기만 해야 한다는 치명적 단점이 있는 것이에요.

비동기 방식은 동기 방식보단 복잡하지만, 결과가 주어지는데, 시간이 걸리더라도 그 시간 동안 다른 작업을 할 수 있으므로, 자원을 효율적으로 사용할 수 있는 장점이 있는 것이에요.

그럼 다시 주제로 돌아가서 이 친구를 사용한 방법에 대해 알아 볼게요!

@Async를 사용해서 비동기 서비스를 만들 수 있는데, 제가 Config에 사용한 @EnableAsync를 사용하여 비동기 기능을 활성화 할 수 있는 것이에요. 
비동기 방식으로 동작을 원하는 Method(public Method)에 @Async를 붙혀주면 끝이랍니다!

위에 사용된 @primary는 같은 Type의 Bean이 여러 개 있을 때, @Quilfier를 지정해 주지 않은 경우를 대비하여 '이 Bean을 우선적으로 선택해서 주입해라! Spring!'을 뜻하는 것이에요.

이 친구는 @Configuration Class에서 많이 사용하는데, 맞아요! @Configuration은 어떤 설정을 위해 생성하는 Class에 붙혀주는 Annotation인 것이에요.


threadPoolTaskExecutor()를 통해 비동기로 호출하는 Threa에 대한 설정을 한 것이에요.

첫번째 : CorePoolSize - 기본적으로 실행을 대기하고 있는 Thread 개수 설정.
두번째 : MaxPoolSize - 동시 동작할 때, 최대 Thread 개수 설정.
세번째 : QueueCapacity - MaxPoolSize를 초과하는 Thread 생성 요청 발생 시 해당 내용을 Queue에 저장하고, 사용할 수 있는 Thread 여유 자리가 발생하게 되면 하나씩 꺼내 동작하는데, 몇 개를 담을 수 있게 할 것인지 설정.
다섯번째 : RejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
RejectedExecutionHandler는 ThreadPoolExecutor에서 작업(Task)를 더 이상 받을 수 없을 때, 호출 되는 것이에요.
이런 경우 Queue 허용치를 초과했더나, Executor가 종료 되어서 Thread 또는 Queue Slot을 사용할 수 없는 경우
발생하는 것이에요.

Reject Policy

Executor는 작업 Queue가 모두 찼을 때, 아래 4가지 전략 중에 하나를 선택할 수 있는 것이에요.

하나! ThreadPoolExecutor.AbortPolicy
이것은 기본(Default)로 설정 된 정책인 것이에요. Reject된 작업(Task)이 RejectedExecutionException을 던지는
것이에요.

둘! ThreadPoolExecutor.CallerRunPolicy
      이것은 호출한 Thread에서 Reject된 작업을 대신 실행하게 하는 것이에요. 주니하랑은 이 정책을 선택하였답니다!

셋! ThreadPoolExecutor.DiscardPolicy
      이것은 Reject된 작업을 버려 버리는 것이에요. 또한, 예외(Exception)도 터지지 않는답니다!

넷! ThreadPoolExecutor.DiscardOldestPolisy
      이것은 실행자를 종료하지 않는 한 가장 오래된 처리 되지 않은 요청을 삭제하고, execute()를 다시 시도하는 것이에요.


여섯번째 : WaitForTasksToCompleteOnShutdown(true);

        # shutdown
        ThreadPoolTaskExecutor Bean이 destroy(제거)될 때, shutdown 처리 되게 되는 것이에요.
        기본적으로는 작업을 더 이상 받지 않고, 실행 중인 작업이 있다면 냅다 중지(Interrupt) 시켜 버리는 것이에요.
        그런데, 작업이 끝나지도 않았는데, 중지라니요! 그래서 위의 설정을 해 주는 것이에요.
        저 필드 Setter에 true를 넣어주면 shutdown 시 작업이 끝날 때까지 대기하는 것이에요.
        기본값을 false이고, false면 당연히 작업이 있건 말건 퇴근하는 것이에요. 


일곱번째 : AwaitTerminationSeconds(60);

     이것은 위의 값이 true일 경우 얼마나 대기할 것인지 초 단위로 설정을 해 주는 부분인 것이에요.
     주니하랑은 60(1분)초를 설정 해 주었답니다!

위에 두 값은 비동기 설정 시 너무 작은 값을 설정 해 버리면 성능 문제가 터지고, 너무 큰 값을 설정하면 Resource 부족 현상이 발생할 수 있으니 적절하게 잘 사용해야 하는 것이에요. 

 

 

    🔽  SpringSecurityConfig

반응형

 

이 친구는 Spring이 제공하는 Security를 사용하여 로그인 관련 기능을 추가하기 위해 만든 것이에요.

먼저 WebSecurityConfigurerAdapter라는 친구를 상속을 받은 것이에요. 
이 친구는 로그인하기 전에 로그인 페이지로 이동(Redirect)하는 기능, 이용자에게 ID와 비밀번호 입력 받기, 입력 받은 값 DB 값과 비교하여 로그인 처리 등을 할 수 있게 해주는 친구인 것이에요.

@EnableWebSecurity는 기본적인 Web 보안 활성화를 해주는 친구인 것이에요.
@value("${jwt.secret}") private String secret; 이것은 지금 이 프로젝트 Code가 주니하랑의 Github에 올라가고 있는데, 이 때 은밀하게 사용되어야 할 jwt 값이 드러나지 않도록 하기 위해 jwt 값을 application.yml에서 가져오기 위해 넣어 준 것이에요.

PasswordEncoder는 이용자가 입력한 비밀번호를 암호화 하기 위해 만들어 두었습니다!

그리고, secret으로 만들어진 jwt 값을 JWTUtil이라는 객체에 보내 처리하도록 해 준 것이에요.

그런 다음 configure()를 Override하여 Cors Error 방어를 설정한 것이에요.

첫째 : addAllowedOring - CORS 요청을 허용할 Site 입력
둘째 : addAllowedMethod - CORS 요청을 허용햘 HTTP Method 설정 (주니하랑은 모든 Method 허용)
셋째 : addAllowedHeaders - 특정 Header를 가진 경우에 CORS를 요청할 때, 허용 여부 (주니하랑은 모두 허용)
넷째 :

UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
source.registerCorsConfiguration("/**", configuration);

                 UrlBasedCorsConfigurationSource()를 통해서 Pattern 방식으로 주니하랑이 개발하는 엡 서비스에 모든
                 URI에 Cors Error가 나지 않게 해 준 것이에요.

 

 

매개변수(파라미터)로 받은 HttpSecurity가 제공하는 기능들을 사용 해보려 하는 것이에요.

먼저, formLogin()과 logout()은 직관적으로 보면 알 수 있듯이 Login과 Logout 기능을 활성화 시키기 위함인데,

Login의 경우 위에 열거한 조건에 맞지 않으면 자동으로 Login창으로 이동을 시켜 Login 부터 하도록 만드려고 추가한 부분인 것이에요.

 

그 다음 csrf().disable()을 해 주었는데, (CSRF 공격은 이 곳을 누르시면 확일 할 수 있습니다.)

이것을 해제(disable)한 것이에요. 왜 그랬을까요?

이유는 바로 REST API에서 Spring Security Documentation에 Non-browser Clients만을 위한 Service라면 csrf 기능을 disable하여도 좋다고 하기 때문인 것이에요.

 

 

그 이유는 REST API를 이용한 서버라면, Session 기반 인증과 다르게 Stateless하기 때문에 Server에 인증 정보를 저장하지 않고, REST API에서 Client는 권한이 필요한 요청을 하기 위해 요청에 필요한 인증 정보(OAuth2, JWT 등)을 포함 시켜야 해요.

그런 이유로 Server에 인증정보를 저장하지 않기 때문에 굳이 불 필요한 Code가 될 csrf에 대한 기능을 넣을 필요가 없는 것이에요.

마지막으로 cors().configurationSource는 위에서 설정했던 CORS Error 방어 설정들을 한 데 모아 CORS Error 방어를 위해 사용한 부분인 것이에요.

 

 

    🔽  SwaggerConfig

 

Swagger는 Back End 개발자들이 Server 개발을 하면 Front End 개발자들이 어떤식으로 개발을 해야할지를 알려주는 문서 관리 Tool인 것이에요.

21번째 Code에 apis에 매개 변수로 RequestHandlerSelectors.basePackage("xx.xx")라고 하면 해당 패키지에 있는 내용만 가지고 추출하여 Swagger 문서를 만드는데, 주니하랑은 모두 추출을 원해서 any()라고 적어주었습니다.

그리고, 경로 패턴으로 URI에 대해 추출을 할 수 있는 부분에도 any를 주어 모든 부분을 추출하게 해 주었습니다.

api info에는 Swagger Main page 등에 표시되면서 Front End 개발자들이 직관적으로 확인할 수 있는 부분에 대해 명시한 것이에요.

 

 

 

    🔽  WebMvcConfing

 

 

먼저 Spring MVC에 관련된 내용은 이 곳을 클릭하시면 확인 하실 수 있습니다.

 

주니하랑은 @EnableWebMvc를 선언하여 WebMvcConfigurationSupport에서 구성한 Spring MVC 구성을 불러오도록 하고, @Configuration과 @EnableWebMvc를 함께 선언하여 WebMvcConfigurer Interface를 구현한 것이에요.

이렇게 하면 WebMvcConfigurationSupport에서 자동 구성한 Spring MVC 구성에 Formatter, MessageConverter등을 추가로 등록 할 수 있는 것이에요. 또한, ViewResolver 값이 자동으로 등록되는 효과를 얻을 수 있는 것이에요.

만약 어떤 등록된 Setting 값 A가 있다고 할 때, A 값에 추가적인 Setting을 더 하고 싶다면 A와 똑같은 Bean을 구현하고, 거기에 원하는 추가 Setting을 하여 customViewResolver()와 같은 Bean을 직접 만들어 줘야 하는 것이에요.

이것은 개발자가 싫어하는 단순 노가다이며, 매우 불편한 행위인 것이에요. 이것을 편리하게 하기 위해 WebMvcConfigurer를 사용한 것이에요.

이 친구를 사용하면 @EnableWebMvc가 자동적으로 Setiing 해주는 설정에 우리가 원하는 설정을 추가할 수 잇는 것이에요. 즉, @Override(재구성)이 가능한 것이지요.

 

주니하랑은 WebMvcConfigurer Interface에 있는 addInterceptors에 대해 구현한 것이에요.

그 전에 resouceHandle, preHandle, Interceptor, Servlet 등에 대해서는 이 곳을 클릭하시면 확인 하실 수 있습니다.

addInterceptors()는 등록할 인터셉터를 설정하는 곳이고, addPathPatterns 같은 것을 사용하여 적용할 URL Pattern을 설정하는 것이에요. 예를 들면 **/* ** 같이 할 경우 모든 URL에 대해 해당 인터셉터를 호출하게 할 수 있답니다.
그리고, excludePathPatterns를 사용하여 인터셉터를 제외할 URL Pattern을 등록하여 해당 URL로 접근 시 인터셉터를 적용하지 않게 할 수 있습니다.

일단 주니하랑은 선언만 해 논 상태인 것이에요.

 

그리고, GUestMemberAPIIntercptor, FamilyMemberAPIInterceptor, AdminAPIIntercpter를 호출하는데, 이번 프로젝트에서 주니하랑은 아래와 같이 회원 등급을 나눈 것이에요.

 

 

각 권한 별로 할 수 있는 부분들과 차단할 부분들에 대한 인가처리를 위해 위와 같이 호출하는 것이에요.

 

 

 

    🔽  다 중 Database 사용 관련 설정(DEVDBDataSourceConfig, TestDBDataSourceConfig)

---

• DEVDBDataSourceConfig
  
  

  

  

  
  
  
  
• TestDBDataSourceConfig
  
  

  

  

주니하랑은 개발 당시에 사용할 DEVDB(H2)와 QA 등과 같이 사용할 TEST Server에서 사용할 TestDB(Maria DB)를 나눠서 사용하기 위해 위와 같이 설정을 한 것이에요.

상단에 적었던 appilication.properties를 보시면 두 개의 DB가 있는 것을 확인할 수 있는 것이에요.

해당 설정은 application.properties에 prefix를 이용해서 두 가지 DB를 상황에 맞게 사용할 수 있게 해 주는 것이에요.

아직 설정 단계라 Repository 등이 없어서 빨간 줄이 나오는 부분이 있지만, 차 후 이 부분은 Repository를 해당 Package Path에 맞게 만들어 줄 것이에요.

위의 코드에서 처럼 Coustom datasource, entityManagerFactory 등을 설정을 하고, base Packages에 Repository Package Path를 적어주면 되는 것이에요. entityManagerFactory에서는 Entity의 Package를 지정해 주면 되는데, 주니하랑은 두 DB 별로 다르게 각각 설정을 해 준 것이에요.
참고로 @Primary는 꼭 붙혀줘야 하는 것이에요.

 

 

설정에 대한 내용은 여기서 마무리하고, 다음에는 Spring Security 관련 CORSFilterdhk JwtUtil에 대해 알아볼 것이에요.