[프로젝트 개발] spring-security 리팩토링

커스텀 필터를 스프링빈으로 등록하기 : 스프링빈 컨테이너 - circular dependency 발생과 해결

• 커스텀 필터에서 스프링빈을 사용해야하므로 필터를 스프링빈으로 등록해야할 필요성이 생김 : 빈으로 등록하고 Config에서 @Autowired를 받으려고 했으나 필터 생성과정에서 AuthenticationManager를 등록해줘야하는데, Config에서 Manager 빈을 가지고 있으므로 Config가 빈으로 생성되지 못하면 Manager 빈을 가져오지 못하는 문제가 발생함
  • 커스텀 필터는 매니져가 필요하고 매니져는 Config가 생성되어야 가져올 수 있다보니 결국 어느 한 쪽도 온전히 생성되어 빈으로 등록되지 못한 상황이라 로그에는 circular dependency라며 찍히고 스프링 종료됨
• 해결하기 : 무조건 @Component - @Autowired 하다보면 아직 생성되지않은 빈들끼리 서로 @Autowired를 하려고 할 것이고, 에러가 발생할 것 : circular dependency라는 로그가 찍히면서 서로 아직 생성되지않았는데 서로 필요로 하니 어떻게 해야할지 모르겠다면서 스프링 실행이 중단됨
  • 해결방법은 한 쪽에서 @Bean으로 수동생성해서 빈으로 등록하도록 하는 것 : 해당 클래스는 @Configuration으로 설정되어있어야 스캔 대상이 됨

@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Bean
    JWTAuthenticationFilter jwtAuthenticationFilter() throws Exception {
        JWTAuthenticationFilter filter = new JWTAuthenticationFilter();
        filter.setAuthenticationManager(super.authenticationManagerBean());
        return filter;
    }

서버 아키텍쳐 구성(1)

Scalability

• 트래픽에 따라 서버를 확장하거나 축소할 수 있는 것을 말함
  • 확장 뿐만 아니라 트래픽이 몰리지 않는 시간대에는 줄일 수 있어야함 : 탄력적 운영을 통해 비용 절약

Scale-Up vs Scale-Out

• Scalability를 말할 때 두가지 유형이 있음
  • Scale-Up : 장비 수는 그대로 두되 장비의 성능을 업그레이드 하는 것, 가장 쉬운 방법이지만 어느 순간부터는 개선이 되지 않음(절대적인 숫자가 부족하기때문에 아무리 빠르더라도 데이터를 주고 받을 때 대역폭이 낮은 것과 마찬가지), 비용 대비 저효율
  • Scale-Out : 비슷한 성능 수준을 사용하되 장비 수를 늘리는 것, 장비 수를 무작정 늘리는 것이 아니라 늘어난 수에 따라 상태를 동기화 하는 아키텍쳐를 구성하던지, 상태를 관리하지않는 무상태 서버를 구성하던지 해야함, 늘어난 장비 수를 활용하기위한 로드밸런서가 앞 단에 위치해야함 로드 밸런싱에 대한 경험이 없는 경우 진입 장벽이 높음

SPOF

• single point of failure : 단일 장애점
  • 시스템 구성 요소 중 장애가 발생했을 때 전체 시스템이 마비되는 요소, 장애 발생에 따른 대안이 없도록 설계한 것이 문제(완벽하게는 없앨 수 없으나 안전성 또는 가용성을 높이기위한 방법을 도입해야함)
  • 예를 들어 컴퓨터 1대(장비)가 static, dynamic, db server 역할을 모두 한다면 해당 장비에 문제가 발생했을 때 모든 시스템이 마비가 됨 : 나눠야할 필요성이 생김, 나누고도 안전성이 그리 크게 증가하지않음, 장애 발생 시 가동될 시스템을 마련해야할 필요(이중성)

SPOF 해결하기 - 이중성

• 이중성의 필요성 : 예비 자원(장비) 없이 운영할 경우 역할 분리로 처리해야 할 일을 분산 했다고 하더라도 해당 지점에 에러가 발생할 경우 전체 시스템이 마비되는 것은 마찬가지

• 서버에서는 로드밸런싱 - 서버 간 역할 분배, N대 서버

• 데이터베이스에서는 리플리케이션 : mysql 기준
  • 물리적으로 다른 지역에 같은 내용을 가진 데이터베이스를 만듦 : 마스터 장비의 로그에 기록하고, 변화를 감지 한 뒤 슬레이브 장비에 기록
  • 마스터(멀티쓰레드) - 슬레이브(싱글쓰레드) 역할 : 마스터에서만 변경을 하고, 슬레이브 장비에서는 읽기만 가능 / 마스터 장비에 장애 발생 시 데이터 변경을 할 수 없는 문제가 있음, 데이터 동기화할 것이 많아지면 마스터와 슬레이브 사이에 동기화되는 시점 차이가 많이 나게됨