0403 ~ 0423

# 0403 ~ 0423

# 0404 - Dispatcher-Servlet(디스패처 서블릿)

# Dispatcher-Servlet 개념

# 개념

디스패처 서블릿의 dispatch는 "보내다"라는 뜻을 가지고 있다. 그리고 이러한 단어를 포함하는 디스패처 서블릿은 HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러(Front Controller)라고 정의할 수 있다.
이것을 보다 자세히 설명하자면, 클라이언트로부터 어떠한 요청이 오면 Tomcat(톰캣)과 같은 서블릿 컨테이너가 요청을 받게 된다. 그리고 이 모든 요청을 프론트 컨트롤러인 디스패처 서블릿이 가장 먼저 받게 된다. 그러면 디스패처 서블릿은 공통적인 작업을 먼저 처리한 후에 해당 요청을 처리해야 하는 컨트롤러를 찾아서 작업을 위임한다.
여기서 Front Controller(프론트 컨트롤러)라는 용어가 사용되는데, Front Controller는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 처리해주는 컨트롤러로써, MVC 구조에서 함께 사용되는 디자인 패턴이다.

# 장점

spring MVC는 DispatcherServlet이 등장함에 따라 web.xml의 역할을 상당히 축소시켜 주었다. 과거에는 모든 서블릿을 URL 매핑을 위해 web.xml에 모두 등록해주어야 했지만, dispatcher-servlet이 해당 어플리케이션으로 들어오는 모든 요청을 핸들링해주고 공통작업을 처리하면서 상당히 편리하게 이용할 수 있게 되었다. 우리는 컨트롤러를 구현해두기만 하면 디스패처 서블릿이 알아서 적합한 컨트롤러로 위임해주는 구조가 되었다.

# Dispatcher-Servelt 동작 과정

# 동작방식

클라이언트의 요청을 디스패처 서블릿이 받음
요청 정보를 통해 요청을 위임할 컨트롤러를 찾음
요청을 컨트롤러로 위임할 핸들러 어댑터를 찾아서 전달
핸들러 어댑터가 컨트롤러로 요청을 위임함
비지니스 로직을 처리함
컨트롤러가 반환값을 반환함
핸들러 어댑터가 반환값을 처리함
서버의 응답을 클라이언트로 반환함

# 0406 - SpringBoot 실행 후에 초기화 코드를 넣는 3가지 방법과 이벤트 리스너

# 커맨드라인 파라미터를 위한 CommandLineRunner

# CommandLineRunner를 구현하는 클래스 생성

CommandLineRunner는 스프링 부트 1.0에 추가된 함수형 인터페이스로써 스프링 애플리케이션이 구동된 후에 실행되어야 하는 빈을 정의하기 위해 사용된다. CommandLineRunner는 파라미터로 String 타입의 가변 인자를 받고 있으며 인터페이스 이름 그대로 컨맨드 라인으로 받은 스트링 타입의 인자를 파라미터로 받아서 사용하기 위해 만들어졌따. CommandLineRunner는 이를 구현하는 클래스를 정의하고 빈이 등록하면 어플리케이션이 구동된 후에 자동으로 run 메소드가 실행된다.

@Component
class TestCommandLineRunner implements CommandLineRunner {

    @Override
    public void run(String... args) {
        System.out.println("Test");
    }
    
}

1
2
3
4
5
6
7
8
9

# CommandLineRunner를 람다식으로 구현

우리가 필요로 하는 작업은 애플리케이션 실행 후에 1회 초기화 작업인데, 위와 같이 클래스로 만드는 것은 무거우며 번거롭다. CommandLineRunner는 함수형 인터페이스이므로 다음과 같이 main 클래스에 @Bean과 함께 람다식으로 구현하여 간소화할 수 있다.

@SpringBootApplication
public class TestingApplication {

    public static void main(String[] args) {
        SpringApplication.run(TestingApplication.class, args);
    }

    @Bean
    public CommandLineRunner commandLineRunner() {
        return args -> System.out.println("Test");
    }
}

1
2
3
4
5
6
7
8
9
10
11
12

@Bean은 @Configuration이 있는 클래스 안에서만 동작하는데, @SpringBootApplication이 갖고 있는 @SpringBootConfiguration 안에 @Configuration이 존재하므로 메인 클래스 역시 빈으로 등록이 되어 가능한 것이다.

# 다양한 파라미터를 위한 ApplicationRunner

ApplicationRunner 역시 마찬가지로 함수형 인터페이스로써 스프링 애플리케이션이 구동된 후에 실행되어야 하는 빈을 정의하기 위한 인터페이스이다. 목적 자체는 동일하지만 ApplicationRunner는 다양한 종류의 파라미터를 받아서 실행하는 경우에 사용할 수 있다. ApplicationRunner는 스프링 부터 2.0에 추가되었다.

@SpringBootApplication
public class TestingApplication {

    public static void main(String[] args) {
        SpringApplication.run(TestingApplication.class, args);
    }

    @Bean
    public ApplicationRunner applicationRunner() {
        return args -> System.out.println("Test");
    }
}

1
2
3
4
5
6
7
8
9
10
11
12

# 이벤트 수신을 위한 EventListener

# 이벤트 리스너 등록 및 이벤트 발행

스프링은 초기부터 애플리케이션 컨텍스트 내부에서 특정 타입의 이벤트를 던지고, 이를 리슨하는 리스너에게 전달해주는 메커니즘을 사용하고 있었다. 그리고 우리가 이를 애플리케이션 레벨에서 이용할 수도 있는데, 특정 타입의 이벤트를 수신하기 위해서는 해당 리스너를 구현해 빈으로 등록해두면 된다. 이벤트 리스너를 등록하고 이벤트를 발행하는 코드는 다음과 같다.

@SpringBootApplication
public class TestingApplication {

    public static void main(String[] args) {
        ConfigurableApplicationContext context = SpringApplication.run(TestingApplication.class, args);

        context.addApplicationListener(new ApplicationListener<ApplicationEvent>() {
            @Override
            public void onApplicationEvent(ApplicationEvent event) {
                System.out.println("Test");
            }
        });

        context.publishEvent(new ApplicationEvent(context) {

        });
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

ApplicationEvent의 생성자는 Object 타입을 받고 있는데, 이벤트를 발행하는 객체를 넣는 용도로 존재한다. 위의 코드에서 ApplicationContext 객체를 넣어주었다. ApplicationListener는 역시 함수형 인터페이스이므로 람다식으로 간소화할 수 있다.

@SpringBootApplication
public class TestingApplication {

    public static void main(String[] args) {
        ConfigurableApplicationContext context = SpringApplication.run(TestingApplication.class, args);

        context.addApplicationListener(event -> System.out.println("Test"));

        context.publishEvent(new ApplicationEvent(context) {

        });
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13

# @EventListner를 사용한 이벤트 리스너 등록

하지만 위와 같이 이벤트 리스너를 직접 구현하는 방식은 상당히 번거롭다. 그래서 스프링 4.2부터는 @VentListener 어노테이션이 추가되었는데, @EventListener를 스프링 빈 안에 구현해두면 리스너가 동작하게 된다. 스프링은 애플리케이션이 준비되었을 때 ApplicationReadyEvent 타입의 이벤트를 발행하므로, 애플리케이션이 준비되었을 때 어떤 코드를 실행하기 위해서는 다음과 같이 이용할 수 있다.

@SpringBootApplication
public class TestingApplication {

    public static void main(String[] args) {
        SpringApplication.run(TestingApplication.class, args);
    }

    @EventListener(ApplicationReadyEvent.class)
    public void init() {
        System.out.println("Test");
    }
    
    @EventListener
    public void init(ApplicationReadyEvent event) {
        System.out.println("Test");
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@EventListener는 여러 타입의 메세지를 받을 수 있는데, 특정 타입의 메세지를 받기 위해서는 @EventListener 어노테이션에 이벤트 타입을 넣어주면 되며, 만약 해당 타입이 파라미터로 필요하다면 어노테이션에 적어줄 필요없이 파라미터로만 명시해주어도 된다. 스프링은 ApplicationReadyEvent 타입의 이벤트를 1회만 발행하는데, 위의 코드에서는 수신하는 리스너가 2개가 존재한다. 이벤트 리스너는 기본적으로 멀티 캐스팅 관계이므로 동일한 타입의 여러 리스너가 등록되었다면 모든 리스너가 이벤트를 받게 된다.

# 커스텀 이벤트와 커스텀 이벤트 리스너의 구현

ApplicationListener의 제네릭 타입으로 ApplicationEvent 하위의 이벤트 클래스를 주면 해당 타입의 이벤트만을 받도록 구현할 수 있다. 또한 직접 리스너 어노테이션을 구현할수도 있는데, 이를 코드로 작성하면 다음과 같다.

@SpringBootApplication
public class TestingApplication {

    public static void main(String[] args) {
        ConfigurableApplicationContext context = SpringApplication.run(TestingApplication.class, args);
        context.publishEvent(new TestEvent(context, "TestEvent"));
    }

    static class TestEvent extends ApplicationEvent {

        private final String message;

        public TestEvent(Object source, String message) {
            super(source);
            this.message = message;
        }
    }

    @Target(ElementType.METHOD)
    @Retention(RetentionPolicy.RUNTIME)
    @EventListener
    @interface TestListener {

    }

    @TestListener
    public void testEvent(TestEvent testEvent) {
        System.out.println(testEvent.message);
    }

}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

이러한 이벤트를 발행하고 리스너를 통해 수신하는 개발 방식은 빈들 사이의 관계를 끊어 느슨하게 함으로써 결합도를 낮출 수 있다. 또한 이를 중심으로 개발하는 설계 등을 이벤트 주도 설계(Event Driven Architecture) 등이라고도 한다.
스프링 부트에서는 애플리케이션의 시점에 따라 이벤트를 발행하기 위해 ApplicationEvent를 상속받는 SpringApplicationEvnet 추상클래스를 구현해두었고, 다음과 같은 구현체들 역시 만들어두었다.

ApplicationStartingEvent
- 애플리케이션이 실행되고나서 가능한 빠른 시점에 발행됨
- Environment와 ApplicationContext는 준비되지 않았지만 리스너들은 등록이 되었음
- 이벤트 발행 source로 SpringApplication이 넘어오는데, 이후 내부 상태가 바뀌므로 내부 상태의 변경은 최소화해야 함
ApplicationContextInitializedEvent
- 애플리케이션이 시작되고 애플리케이션 컨텍스트가 준비되었으며 initializer가 호출되었음
- 하지만 빈 정보들은 불러와지기 전에 발행됨
ApplicationEnvironmentPreparedEvent
- 애플리케이션이 실행되고 Environment가 준비되었을 때 발행됨
ApplicationPreparedEvent
- 애플리케이션이 시작되고 애플리케이션 컨텍스트가 완전히 준비되었지만 refresh 되기 전에 발행됨
- 빈 정보들은 불러와졌으며 Environment 역시 준비가 된 상태임
ApplicationStartedEvent
- 애플리케이션 컨텍스트가 refresh 되고나서 발행됨
- ApplicationRunner와 CommandLineRunner가 실행되기 전의 시점임
ApplicationReadyEvent
- 애플리케이션이 요청을 받아서 처리할 준비가 되었을 때 발행됨
- 이벤트 발행 source로 SpringApplication이 넘어오는데, 이후에 초기화 스텝이 진행되므로 내부 변경은 최소화해야 함
ApplicationFailedEvent
- 애플리케이션이 실행에 실패했을 때 발행됨

위의 3가지 중에서 편한 방법을 이용하면 애플리케이션 실행 시에 warm-up을 시킴으로써 첫 요청이 느린 문제를 해결할 수 있다. 물론 이벤트 리스너는 비지니스 로직에서 불필요하게 연관관계가 복잡해지는 문제들을 해결하기 위해서도 사용할 수 있다. 이러한 경우에 만약 트랜잭션과 연관된 작업이라면 @RansactionalEventListener를 사용해주면 된다.

# 0409 - CDN(Contents Delivery Network)

CDN(Contents Delivery Network)이란 데이터 사용량이 많은 애플리케이션의 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크이다.

사용자는 웹 사이트를 방문할 떄 해당 웹 사이트 서버의 데이터가 인터넷을 통해 사용자의 컴퓨터에 도달하게 된다. 이때 사용자가 해당 서버에서 멀리 떨어져 있는 경우 동영상이나 이미지와 같은 대용량 파일을 도르할 때 많은 시간이 걸리게 된다.

반면 사용자와 가까운 거리에 있는 CDN 서버에 웹 사이트 콘텐츠를 저장해 놓으면 사용자는 훨씬 빠른 속도로 콘텐츠를 로드할 수 있다.
즉, CDN은 콘텐츠 전송 시간을 줄여주는 네트워크이다.

# CDN의 동작 방식

CDN의 목적은 지연 시간을 줄이는 것이다. 지연 시간이란 웹 페이지 혹은 비디오 스트리밍 콘텐츠 등이 디바이스에 완전히 로딩되기 전에 발생하는 지연 시간을 말한다. 콘텐츠가 사용자에게 도달하기 위해 이동해야 하는 물리적 거리를 줄여 지연 시간을 줄이는 CDN도 있다. 따라서 CDN이 광범위하고 넓게 분산되어 있을수록 웹 콘텐츠를 보다 빠르고 안정적으로 전송할 수 있다.

이러한 CDN은 여러 지리적 위치에 접속 지점(POP) 또는 CDN 엣지 서버 그룹을 설정하는 방식으로 동작한다. 지리적으로 분산된 이 네트워크는 캐싱, 동적 가속 및 엣지 로직 계산의 원리를 기반으로 동작한다.

# 캐싱

캐싱은 더 빠른 데이터 접근을 위해 동일한 데이터의 여러 복사본을 저장하는 프로세스이다. CDN 기술에서 캐싱은 네트워크 여러 서버에 정적 웹 사이트 콘텐츠를 저장하는 프로세스를 의미한다. CDN에서 캐싱은 다음과 같이 동작한다.

지리적으로 멀리 떨어진 웹 사이트 방문자가 사이트에 정적 웹 콘텐츠를 요청한다.
요청이 웹 애플리케이션 서버 또는 Origin 서버에 도달한다. Origin 서버는 원격 방문자에게 응답을 보낸다. 또한 해당 방문자와 지리적으로 가장 가까운 CDN POP에 응답 복사본을 보낸다.
CDN POP 서버는 복사본을 캐싱된 파일로 저장한다.
다음에 해당 방문자 또는 해당 위치에 있는 다른 방문자가 동일한 요청을 하면, Origin 서버가 아닌 캐싱 서버가 응답을 보낸다.

# 동적 가속

동적 가속은 웹 애플리케이션과 클라이언트 사이의 중개 CDN 서버로 인해 발생하는 동적 웹 콘텐츠 요청에 대한 서버응답 시간을 단축하는 것이다. 사용자의 요청이 있을 때마다 콘텐츠가 변경될 수 있기 때문에 동적 웹 콘텐츠에서는 캐싱이 제대로 동작하지 않는다. CDN 서버는 모든 동적 요청에 대해 Origin 서버와 다시 연결해야 하지만 자신과 Origin서버 간의 연결을 최적화하여 프로세스를 가속화한다.

클라이언트가 인터넷을 통해 웹 서버로 직접 동적 요청을 보내는 경우 네트워크 대기 시간으로 인해 요청이 손실되거나 지연될 수 있다. 보안 검증을 위해 연결을 열고 닫는 데에도 시간이 걸릴 수 있다. 반면, 근처의 CDN 서버가 요청을 Origin 서버로 전달할 경우, 신뢰할 수 있는 지속적인 연결이 이미 설정되어 있을 것이다. 예를 들어 다음과 같은 기능을 통해 이들 간의 연결을 더욱 최적화할 수 있다.

지능형 라우팅 알고리즘
Origin 서버에 대한 지리적 근접성
클라이언트 요청을 처리할 수 있으므로 클라이언트 요청을 줄일 수 있다.

# 엣지 로직 계산

클라이언트와 서버 간의 통신을 단순화하는 논리적 계산을 수행하도록 CDN 엣지 서버를 프로그래밍할 수 있다. 예를 들어 이 서버는 다음을 수행할 수 있다.

사용자 요청을 검사하고 캐싱 동작을 수정한다.
잘못된 사용자 요청을 확인하고 처리한다.
응답하기 전에 콘텐츠를 수정하거나 최적화한다.

웹 서버와 네트워크 엣지 간에 애플리케이션 로직을 배포하면 개발자가 Origin 서버의 컴퓨팅 요구 사항을 오프로드하고 웹 사이트 성능을 높이는 데 도움이 된다.

# CDN의 장점

CDN을 사용하면 아래와 같은 장점을 얻을 수 있다.

페이지 로드 시간 단축
가까운 CDN 서버에서 콘텐츠를 전송해주기 떄문에 페이지 로드 시간을 단축 할 수 있다.
대역폭 비용 절감
-> CDN은 캐싱 및 기타 최적화를 통해 Origin 서버가 제공해야하는 데이터의 양을 줄여 웹 사이트 소유자의 호스팅 비용을 절감할 수 있다.
콘텐츠 가용성 제공
-> CDN 서비스는 대용량 트래픽을 처리하고 웹 서버의 부하를 줄일 수 있다.
웹 사이트 보안 강화
-> DDoS 공격과 같은 가짜 트래픽을 여러 중간 서버 간에 분산하여 Origin 서버에 미치는 영향을 줄일 수 있다.

# 0413 - 논리 연산과 불 대수

# 논리 연산

: 산술 연산(수치를 이용한 가감승제)을 제외한 문자나 숫자에 대한 여러 가지 연산. 데이터를 숫자로 취급하지 않으며 비트 또는 바이트 단위로 취급.

# 논리 연산의 종류

논리합, 논리곱, 논리부정, 분기, 비교 시프트, 변환 등

분기 : 명령의 순서를 변경하는 것. 무조건 분기와 조건 분기 존재.
비교 : 조건에 따라 두 개의 데이터를 비교하여 그 대소를 판단하는 것.
시프트 : 각종 연산을 위해서 기억된 데이터 비트들을 왼쪽이나 오른쪽으로 차례대로 이동하는 연산.
변환 : 2진수와 10진수의 상호 변환이나 코드를 바꾸는 것.

# 불 대수

# 대수

: 대수학 (개개의 숫자 대신에 숫자를 대표하는 일반적인 문자를 사용하여 수의 관계, 성질, 계산 법칙 따위를 학문하는 학문).

# 불 대수

: 조지 불에 의해 창시된 논리 수학. 명제의 참과 거짓을 판단하는 론리 연산을 다루는 대수.
논리 회로 설계에 이용되어 컴퓨터 동작의 기초가 됨.
논리의 참 또는 거짓 값을 갖는 논리 변수들의 상관관계를 논리곱, 논리합, 논리부정 등의 논리 연산을 이용하여 논리식으로 표현.

논리식을 간단하게 할 수 있는 법칙과 정리들을 제공하므로 이들을 이용하여 정확하고 간결하게 논리 회로 설계 가능.

# 불 대수의 기본 연산

논리곱 : 주어진 복수 명제 모두가 참이어야 결과가 참이 되는 연산
논리합 : 주어진 복수 명제에 적어도 1개 이상의 참이 있으면 결과가 참이 되는 연산
논리부정 : 주어진 명제의 참과 거짓을 부정하는 연산

# 불 대수의 법치과 정리

산술 연산에서 +와 *연산의 우선순의는 다르지만, 논리 연산에서 +와 *연산의 우선순의는 같으므로 분배법칙이 성립한다.

# 논리 게이트

: 하나 이상의 논리 값을 입력받아 논리 연산을 수행하여 하나의 결과를 출력하는 전자 회로

AND 게이트 : 두 개 이상의 입력이 모두 1일 때 출력이 1인 게이트. 논리곱 회로
OR 게이트 : 두 개 이상의 입력 중 하나 이상 입력이 1일 때 출력이 1인 게이트. 논리합 회로
XOR 게이트 : 입력이 서로 다를 때 출력이 1인 게이트. 배타적 논리합 회로
NOT 게이트 : 입력이 0이면 출력이 1, 입력이 1이면 출력이 0인 게이트. 논리부정 회로
NAND 게이트 : NOT + AND 게이트로 AND 게이트의 반대가 출력.
NOR 게이트 : NOT + OR 게이트로 OR 게이트의 반대가 출력.
NXOR 게이트 : NOT + XOR 게이트로 XOR 게이트의 반대가 출력.

# 0423 - GitHub 기본 Label 의미

Label	설명
bug	예상치 못한 문제 또는 의도하지 않은 동작
documentation	문서에 대한 개선 또는 추가가 필요함
duplicate	유사한 issue, pull requests 또는 토론
enhancement	새로운 기능 요청
good first issue	처음 기여자에게 좋은 issue
help wanted	관리자가 issue 또는 pull request에 대한 도움을 원함을 나타낸다
invalid	issue, pull request 또는 토론이 더 이상 관련이 없음
question	issue, pull request 또는 토론에 추가 정보가 필요함
wontfix	issue, pull request 또는 토론에 대한 작업이 계속되지 않음

0320 ~ 0402 0612

0403 ~ 0423

# 0403 ~ 0423

# 0404 - Dispatcher-Servlet(디스패처 서블릿)

# Dispatcher-Servlet 개념

# 개념

# 장점

# Dispatcher-Servelt 동작 과정

# 동작방식

# 0406 - SpringBoot 실행 후에 초기화 코드를 넣는 3가지 방법과 이벤트 리스너

# 커맨드라인 파라미터를 위한 CommandLineRunner

# CommandLineRunner를 구현하는 클래스 생성

# CommandLineRunner를 람다식으로 구현

# 다양한 파라미터를 위한 ApplicationRunner

# 이벤트 수신을 위한 EventListener

# 이벤트 리스너 등록 및 이벤트 발행

# @EventListner를 사용한 이벤트 리스너 등록

# 커스텀 이벤트와 커스텀 이벤트 리스너의 구현

# 0409 - CDN(Contents Delivery Network)

# CDN의 동작 방식

# 캐싱

# 동적 가속

# 엣지 로직 계산

# CDN의 장점

# 0413 - 논리 연산과 불 대수

# 논리 연산

# 논리 연산의 종류

# 불 대수

# 대수

# 불 대수

# 불 대수의 기본 연산

# 불 대수의 법치과 정리

# 논리 게이트

# 0423 - GitHub 기본 Label 의미

Description