Category: Programming

HTTP 응답 헤더 보안

의외로 웹 프로그래밍을 하는 사람들 조차도 HTTP 응답 헤더에 대해서 생각을 하지 않는다. HTTP 응답 헤더에 대한 생각을 하지 않는다는 것은 웹 프로그래밍을 깊게 공부한 사람이 아니라고 말할 수도 있다.

Cache Control

대부분의 사람들은 이 부분에 대해서는 잘 안다. Cache Control 헤더는 Client 에 컨텐츠를 어떻게 캐시할 것인지에 대한 제어를 할 수 있다.

하지만 고려해야할 사항이 존재한다. 만약 AWS Cloud 를 사용한다면 더 더욱 고려해야할 사항이 존재한다. AWS 의 CloudFront 는 CDN 서비스로서 컨텐츠 캐시를 기반으로 한다.

만일 특정 컨텐츠에 대해서 캐시를 하고 싶지 않다면 어떻게 해야할까? AWS 에서는 다음과 문서에 기술해 놨다.

사용자 지정 오리진 웹 서버 애플리케이션에서, Cache-Control no-cache, no-store 또는 private 명령을 CloudFront에서 캐시하지 않으려는 객체에 추가합니다. 또는 Expires 명령을 CloudFront에서 캐시하지 않으려는 객체에 추가합니다.

CloudFront에서 특정 파일 캐시를 방지하려면 어떻게 해야 합니까?

오리진(origin) 의 웹 서버나 애플리케이션에서 Cache-Control 헤더를 조작하도록 권고 하고 있다.

Cache 제어 헤더
1
2
3
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expire: 0

위는 응답 캐싱 정책을 정의하는 사용하는 헤더 지시문이다. Cache-Control 은 HTTP/1.1 사양의 일부로 정의 되었다. Expire 는 Cache-Control 이전에 사용했던 지시문이다. 현대의 대부분 브라우저는 HTTP/1.1 를 지원하지만 구형을 쓰는 곳이 있을 수 있음으로 Expire 지시문을 함께 사용한다.

no-cache 는 말그대로 캐시를 하지 말라는 것을 지시한다. 이 지시자를 쓸 경우에 매번 요청할 때마다 문서의 유효성을 검사한다. 그래서 컨텐츠가 변경된 경우에 최신 버전을 가지고 오게 된다. 컨텐츠의 변화를 감지하는 매커니즘을 가진다는 것이 매우 중요하다. 또 모든 것을 캐시를 하지 않는다. 예를들어, 비공계 개인 데이터와같은 것은 이 지시자로 캐시를 제어를 할 수 없다.

no-store 는 비공개 개인 데이터를 포함해 모든 캐시를 하지 않다록 해준다.

public, private 이라는 것도 있다. 이는 중간 캐시를 이용할 경우에 유용하다. 중간 캐시는 CDN 을 의미한다. 만일 CDN 과 같은 중간 캐시 서버가 캐시 데이터를 가지고 있기를 원하지 않는다면 private 를 써야 한다.

그리고 위 코드에 보이는과 같이 모든 것을 다 포함하도록 지시문을 사용해서는 안된다. Pragma, Expire 는 HTTP/1.0 스펙에서 유효하다. 거기다 Cache-Control 지시문에서 no-cache, no-store, max-age 를 한꺼번에 쓰는건 잘못된 것이다.

그래서 cache 전략이 필요하게된다. 이는 HTML 구조를 봐야 한다.

index.html 예제
XHTML
1
2
3
4
5
6
7
8
<html>
<head><title>캐시 전략</title>
<link rel="stylesheet" type="text/css" href="common.css">
<script type="text/javascript" src="a.js"></script>
<body>
Hello World!
</body>
</html>

index.html 파일 안에 구조가 저렇게 되어 있다고 가정하면, 대략 다음과 같은 형태의 캐시 전략을 쓸 수 있다.

ContentsCache-Control
index.htmlCache-Control: no-cache
common.cssCache-Control: max-age=86400
a.jsCache-Control: private, max-age=86400

CSS 파일은 최대 1일까지만 캐시하도록 지시했고, Javascript 파일은 CDN 에서 캐시를 하지 못하도록 하고 브라우져에서 최대 1일까지만 캐시하도록 했다. index.html 은 no-cache 를 주어서 캐시를 하지 못하게 했지만 매번 요청할 때마다 변경이 되었는지 체크하고 변경되었다면 최신판을 새로 받도록 했다.

must-revalidate 가 있는데, 강제 사항을 적용할 때 사용 한다. 이는 다음과 같이 사용한다.

cache control 헤더
1
Cache-Control: max-age=86400, must-revalidate

이 경우에 1일동안 캐시를 하고 그 이후에는 서버에 반드시 유효성검사를 하도록 강제한다. 만일 네트워크 상황으로 유효성 검사를 못할 경우에는 절대로 캐시 데이터를 사용하지 못하도록 한다.

이론을 기반으로 현실에서 사용 전략을 다음과 같이 세울 수 있다.

경우의 수Cache-Control
금융Cache-Control: no-store
장바구니, 결재 페이지Cache-Control: no-store
개인정보 수정 페이지Cache-Control: no-store
동적 웹 페이지Cache-Control: no-cache
정적 파일Cache-Control: max-age=86400

금융 관련된 웹 애플리케이션을 사용할 때에는 캐시를 되도록이면 하게 하면 안된다.

Nginx 와 같은 경우에 다음과 같이 HTTP Header 에 Cache-Control 을 붙일 수 있다.

Nginx 서버에 Cache Control 헤더 추가 예제
Apache
1
2
3
4
location /static {
   expires 1M;
   add_header Cache-Control "public, must-revalidate";
}

Nginx 에서 max-age 설정은 expires 해도 된다. 이렇게 하면 구형의 Expire 지시자도 함께 지정된다.

Spring에서는 Spring-Security 에서 다음과 같이 지원한다.

spring security 를 이용한 cache control 설정 예제
XHTML
1
2
3
4
5
<http>
   <headers>
       <cache-control />
   </headers>
</http>

위 설정은 다음과 같은 상태로 만든다.

spring security 설정으로 생성된 cache control 헤더
1
2
3
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0

만일 직접 캐시를 조작하고 싶다면 다음과 같이 해주면 된다.

spring security 을 통한 cache control 세밀한 설정
XHTML
1
2
3
      <headers>
          <header name="Cache-Control" value="public, max-age=86400, must-revalidate"/>
      <headers>

Content Type Options

브라우저는 content sniffing 같은 기술을 사용해 다운받을려는 컨텐츠 타입을 추정하고 특정하게 된다. 하지만 이러한 것은 XSS 와 같은 공격을 제공하는 빌미가 된다. 그래서 이것을 방지하기 위해서 다음과 같이 헤더응답을 넣는다.

X-Content-Type-Options 헤더
1
X-Content-Type-Options: nosniff

Spring Security 에서는 간단하게 설정할 수 있다.

spring security 를 이용한 X-Content-Type-Options 설정 헤더
XHTML
1
2
3
<headers>
   <content-type-options />
</headers>

HTTP Strict Transport Security(HSTS)

보통 사이트에 접속하는데에 프로토콜을(HTTPS, HTTP) 붙이지 않는다. 이럴 경우 브라우저는 HTTP 로 먼저 접속해보고 서버의 설정에 따라서 HTTPS 로 리다이렉트를 하게 된다.

만일 중간에 해커가 Proxy Server 를 두게되면 클라이언트는 HTTP 로만, Proxy Server 가 이를 받아서 HTTPS 로 뒷단 서버에 연결을 하게된다. 이렇게 되면 모든 정보를 볼 수 있게 된다. 이러한 해킹 기법을 “SSL Stripping” 공격 혹은 SSL/TLS Hijacking 이라고 부른다.

HSTS 는 애초에 접속을 HTTPS 로만 하라고 강제한다. 이는 브라우저와 서버 모두 HSTS 를 모두 지원해야 한다는 제한이 있지만 2010에 HSTS 에 대한 논의로 인해서 현재에는 모든 서버와 브라우저가 지원하고 있다.

HSTS 를 지원하는 브라우저는 도메인 목록을 유지한다. HTTPS 로만 접속 해야만 하는 도메인을 가지고 있게된다. 만일 HSTS 목록에 있는 도메인 주소를 억지로 HTTP 로 접속하게 되면 서버가 리다이렉트를 하는게 아니라 HTTPS 로 다시 접속하라고 브라우저에 요청하게 된다. HSTS 는 목록에 도메인을 유지하는 시간을 지정할 수 있다.

무조건 HTTPS 로만 접속하도록 강제하기 때문에 SSL 도메인 인증서가 있는 사이트에서만 사용 가능하다.

Spring Security 에서는 다음과 같이 간단히 적용할 수 있다.

spring security 를 이용한 hsts 헤더 설정
XHTML
1
2
3
4
5
<headers>
   <hsts />
    혹은
   <hsts  include-subdomains="true" max-age-seconds="31536000" />
</headers>

X-Frame-Options

HTML 내에 또 다른 frame 을 넣는 기술은 자주 사용 되었었다. 최근에는 사용이 줄었지만 그래도 여전히 사용되어지는 기술이다. 하지만 이러한 frame 을 이용할 경우에 그것이 변조에 취약하다는 문제가 있다.

그래서 이 frame 을 실행하지 못하도록 브라우저에게 요청할 수 있는데, 이것이 X-Frame-Options 다. 기본 값은 DENY 이지만 같은 도메인의 frame 일 경우에는 허용할 수도 있다.

Spring Security 에서는 다음과 같이 설정할 수 있다.

spring security 를 이용한 frame-options 헤더 설정
XHTML
1
2
3
4
5
<headers>
  <frame-options />
    혹은
  <frame-options policy="SAMEORIGIN" />
</headers>

SAMEORIGIN 일 경우에는 같은 도메인의 frame 일 경우에는 허용하게 한다.

X-XSS-Protection

XSS 를 브라우저에서 실행하도록 한다. 주의해야할 것은 서버의 웹 애플리케이션에서 하는게 아니라 브라우저의 XSS 필터에서 하는 것이다. 그러니까 서버에 요청을 넣기전에 브라우저가 사전에 XSS를 한번 차단하게 하는 것이다.

Spring Security 에서는 다음과 같이 설정할 수 있다.

spring security 를 이용한 xss-protection 헤더 설정
XHTML
1
2
3
4
5
<headers>
   <xss-protection />
      혹은
   <xss-protection block="false" />
</headers>

CONTENT-SECURITY-POLICY

웹에 자원은 동일한 도메인에서만 작동되도록 설계되었다. 하지만 자신만의 스크립트를 삽입하는 XSS 공격을 고안해 냈다. 이를 방어하기 위해서 고안된 것이 CSP(Content Security Policy) 이다. 이것을 HTTP 헤더에 정의하면 브라우저에는 이곳에서 받은 리소스만 실행허거나 렌더링하도록 강제 한다.

Spring Seuciryt 에서는 다음과 같이 설정할 수 있다.

spring security 를 이용한 content-security-policy 헤더 설정
XHTML
1
2
3
4
5
<headers>
   <content-security-policy />
     혹은
   <content-security-policy policy-directives="script-src 'self' https://linux.systemv.pe.kr; object-src https://linux.systemv.pe.kr; report-uri /csp-report-endpoint/" />
</headers>

Spring 에서 기본

많은 웹 애플리케이션이 Spring 을 이용해서 만들어진다. 그리고 인증을 위해서 Spring Security 를 사용한다. 하지만 대부분의 소스를 보면 위에서 언급한 기본적인 보안조차 되어 있지 안되어 있는 곳이 대부분이다. 대기업의 프로젝트에서조차도 이런것을 고려하지도 않는다.

위에서 언급한 모든 내용은 다음과 같이 Spring Security 에서 간단하게 설정할 수 있다.

spring security 를 이용한 기본 헤더 설정
XHTML
1
2
3
4
5
6
7
<headers>
   <cache-control />
   <content-type-options />
   <hsts />
   <frame-options />
   <xss-protection />
</headers>

아주 간단하다. 그냥 가져다 붙여넣기만 해도 된다. 하지만 이것조차도 사용하지 않는 대기업 프로젝트가 부지기수다. 뭐가 기술력이 좋다는 건지… IT 선진국이라는 것이 좋은 인프라에 작동하기만 하면 되는 앱만으로 얻을 수 있는 거였다니..

Reactive Stream 간단 사용

Reactive Stream 을 사용하기 위해서는 다음과 같은 것을 구현해줘야 한다.

  • Publisher
  • Subscriber
  • Subscription

한가지 문제가 있다. 이것을 구현하기가 쉽지가 않다. 특히 Publisher 의 경우에는 Reactive Stream 의 기본 아이디어만 가지고 간단하게 구현할 수가 없다. 어떤 것을 Publisher 할지도 영향을 주는것도 문제지만 Reactive 의 Spec 을 마춰짜야 하는데 이게 쉽지가 안다.

Publisher 를 간단하게 구현 방법이 없을까? SubmissionPublisher 를 이용하면 간단하게 사용해 볼 수 있다.

이 문서는 SubmissionPublisher 를 이용해 어떻게 Reactive Stream 을 구현하는지를 설명한다.

SubmissionPublisher Class

이 클래스를 간단히 살펴보자.

SubmissionPublisher 객체
Java
1
public class SubmissionPublisher<T> implements Publisher<T>,  AutoCloseable {

이 클래스는 Publisher 인터페이스를 구현한 구현체 클래스 이다. 하지만 아주 간단하지만은 않다.

SubmissionPublisher 클래스가 가지는 메소드가 꽤 있다. 자세히 보면 get 혹은 is 로 시작하는 메소드가 많음을 알 수 있다. 이 클래스들은 Publisher 의 상태 정보를 체크하기 위한 것들이다. 반대로 set 으로 시작하는, 그러니까 뭔가를 지정하는 메소드는 많지가 않다.

이 클래스에 설명은 다음과 같이 시작한다.

A Flow.Publisher that asynchronously issues submitted (non-null) items to current subscribers until it is closed. Each current subscriber receives newly submitted items in the same order unless drops or exceptions are encountered. Using a SubmissionPublisher allows item generators to act as compliant reactive-streams Publishers relying on drop handling and/or blocking for flow control.

Flow.Publisher 는 Null 이 아닌 제출된 아이템들을(item) 현재 구독자에게 닫힐때까지 비동기적으로 발행한다. 각각의 현재 구독자들은 삭제 또는 예외가 발생하지 않는한 새롭게 제출된 아이템들을 같은 순서로 받는다. SubmissionPublisher 를 사용하는 것은 아이템 생성기를 흐름제어를 위해 삭제 핸들링과 블럭킹을 필요로하는 reactive-streams Publisher 와 호환되는 것처럼 행동하게 해준다.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/SubmissionPublisher.html

어찌되었든 간에 이것을 이용하면 Reactive Streams Publisher 처럼 만들어 준다 것에 주목해야 한다.

SubmissionPublisher 사용하기

사용방법은 아주 간단하다.

SubmissionPublisher 객체 생성
Java
1
SubmissionPublisher<Integer> publisher = new SubmissionPublisher<>();

SubmissionPublisher 의 객체를 하나 생성한다. 그리고 Reactive Stream 이 Publisher 에 요구하는 subscribe 메소드를 호출해 준다.

subscribe 메소드 사용
Java
1
publisher.subscribe()

하지만 subscribe() 메소드는 인자값으로 Subscriber 클래스를 요구한다. Subscriber 클래스는 Interface 클래스여서 구현체 클래서를 넣어야 한다. 다양한 방법이 있지만 여기서는 다음과 같이 작성해 본다.

subscribe 메소드 작성
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
publisher.subscribe(new Subscriber<Integer>() {
@Override
public void onSubscribe(Subscription subscription) {
// TODO Auto-generated method stub
}
@Override
public void onNext(Integer item) {
// TODO Auto-generated method stub
}
@Override
public void onError(Throwable throwable) {
// TODO Auto-generated method stub
}
@Override
public void onComplete() {
// TODO Auto-generated method stub
}

Reactive Stream 이 요구하는 Subscriber 에 요구 메소드들이(onNext, onError, onComplete) 모두 나온다. 다음과 같이 모두 구현해 준다.

subscribe 메소드 구현
Java
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
publisher.subscribe(new Subscriber<Integer>() {
private Subscription subscription;
@Override
public void onSubscribe(Subscription subscription) {
// TODO Auto-generated method stub
this.subscription = subscription;
subscription.request(1);
}
@Override
public void onNext(Integer item) {
// TODO Auto-generated method stub
System.out.println("Received item:" + item);
subscription.request(1);
}
@Override
public void onError(Throwable throwable) {
// TODO Auto-generated method stub
System.out.println("Error occurred: " + throwable.getMessage());
}
@Override
public void onComplete() {
// TODO Auto-generated method stub
System.out.println("Subscriber is complete");
}
});

위와같이 구현을 해주면 된다. 여기서 중요한 것이 존재하는데, Subscription 객체 변수를 반드시 써야 한다는 것이다. onSubscribe, onNext 메소드에서 공통으로 보이는 subscription.request(1) 이 바로 그것인데 onNext 메소드에 이를 사용하기 위해서 Subscriber 구현체에서 멤버변수를 만들어두고 onSubscribe 시에 주입된 객체변수를 할당해 준다.

이제 다음과 같이 publisher 의 submit 메소드를 사용해 아이템을 넣어준다.

submit 메소드를 사용해 아이템 넣기
Java
1
2
3
4
5
for (int i = 0; i &lt; 10; i++) {
publisher.submit(i);
                }
Thread.sleep(100);
publisher.close();

submit 메소드는 아이템을 제출해 비동기적으로 Subscriber 에게 생성해준다. SubmissionPublisher 의 비동기는 Thread 를 이용한다. 그래서 모든 Thread 가 완료되기를 Main Thread 를 몇초간 중지줘야해서 Thread.sleep(100) 코드가 필요하다.

모든 비동기 제출이 완료되면 제출자를 닫아준다. publisher.close() 다.

이렇게 완료된 전체 코드는 다음과 같다.

전체 코드
Java
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
32
33
34
35
SubmissionPublisher&lt;Integer> publisher = new SubmissionPublisher&lt;>();
publisher.subscribe(new Subscriber&lt;Integer>() {
private Subscription subscription;
@Override
public void onSubscribe(Subscription subscription) {
// TODO Auto-generated method stub
this.subscription = subscription;
subscription.request(1);
}
@Override
public void onNext(Integer item) {
// TODO Auto-generated method stub
System.out.println("Received item:" + item);
subscription.request(1);
}
@Override
public void onError(Throwable throwable) {
// TODO Auto-generated method stub
System.out.println("Error occurred: " + throwable.getMessage());
}
@Override
public void onComplete() {
// TODO Auto-generated method stub
System.out.println("Subscriber is complete");
}
});
for (int i = 0; i &lt; 10; i++) {
publisher.submit(i);
        }
Thread.sleep(100);
publisher.close();

Reactive Stream 을 어떻게하면 간단하게 사용해볼까. Reactive Stream 이 요구하는 최소사항을 어떻게하면 직접 사용해볼 수 있을까? 그렇다면 SubmissionPublisher 클래스를 활용하라.

자바 Reactive Stream 구현체

자바(Java) 에서 Reactive Stream 구현체를 살펴본다.

이전 글에서 Reative Stream 의 기본 아이디어를 설명했었다.

  • Flow control
  • Publisher – Subscriber pattern

또한 이 아이디어를 위한 포맷은 Publisher – Subscriber 이다. Reactive Stream 에서 이 모델은 1) Subscriber 가 Publisher 에게 가입을 요청하면 2) Publisher 는 Subscriber 와 통신을 위한 채널인 Subscription 을 생성하고 이를 통보한다. 이는 다음 그림과 같이 묘사할 수 있다.

출처:https://dzone.com/articles/reactive-streams-in-java-9

여기서 주목해야할 것이 Subscriber 는 Subcription 을 통해서 데이터를 요청하고 받게 된다는데 있다.

java.util.concurrent.Flow

자바에서 구현은 위 클래스에 구현 되어 있다. 그리고 이 클래스 첫줄에 다음과 같이 설명이 시작된다.

Interrelated interfaces and static methods for establishing flow-controlled components in which Publishers produce items consumed by one or more Subscribers, each managed by a Subscription

흐름 제어 컴포넌트를 설정하기 위한 (밀접하게) 상호연관된 인터페이스(Interface) 와 스태틱 메소드(Static method)

java.util.concurrent.Flow

주석에 내용에 등장하는 컴포넌트 Publisher, Subscriber, Subscription 이다. Flow.class 는 다음과 같이 구성되어 있다.

Publisher

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
    @FunctionalInterface
    public static interface Publisher<T> {
        /**
         * Adds the given Subscriber if possible.  If already
         * subscribed, or the attempt to subscribe fails due to policy
         * violations or errors, the Subscriber's {@code onError}
         * method is invoked with an {@link IllegalStateException}.
         * Otherwise, the Subscriber's {@code onSubscribe} method is
         * invoked with a new {@link Subscription}.  Subscribers may
         * enable receiving items by invoking the {@code request}
         * method of this Subscription, and may unsubscribe by
         * invoking its {@code cancel} method.
         *
         * @param subscriber the subscriber
         * @throws NullPointerException if subscriber is null
         */
        public void subscribe(Subscriber<? super T> subscriber);
    }

FunctionalInterface 인게 눈에 뛴다. 이것은 오직 한개의 메소드만을 가진다는 것과 Lambda 식을 지원하게 된다. subscribe 메소드는 인자로 Subscriber 를 받는다.

중간에 주석에 주목할만한 내용이 나온다.

Subscribers may enable receiving items by invoking the request method of this Subscription, and may unsubscribe by invoking its cancel method.

Subscriber 는 이 Subcription 의 request 메소드를 호출함으로써 아이템들을 수신할 수 있으며 cancel 메소드를 호출함으로써 가입이 해제된다.

Subcriber 는 Subscription 의 request 메소드를 호출함으로써 데이터(아이템)을 수신한다는 것이다.

Subscriber

1
2
3
4
5
6
7
8
9
10
    public static interface Subscriber<T> {
 
        public void onSubscribe(Subscription subscription);
 
        public void onNext(T item);
 
        public void onError(Throwable throwable);
 
         public void onComplete();
    }

4개의 메소드를 가지고 있다. 이 메소드들이 다루는 것이 무엇인지를 아는것이 제일 중요하다. 각 메소드의 주석에는 Subscription 이 항상 나온다.

Method invoked with a Subscription’s next item. If this method throws an exception, resulting behavior is not guaranteed, but may cause the Subscription to be cancelled

Subscription’s 의 다음 아이템을 호출하는 메소드. 만약 이 메소드가 예외를 발생시키면, 최종 결과를 보장하지 않지만, Subcription 은 취소될 수 있다.

onNext

Subscriber 가 다음 아이템을 호출하는데 Publisher 를 대상으로 하지 않고 Subscription 을 대상으로 한다는 것을 꼭 기억해야 한다.

Subscription

1
2
3
4
5
6
    public static interface Subscription {
  
        public void request(long n);
 
      public void cancel();
    }

Publisher 와 Subscriber 를 연결하는 메시지 제어를 하는게 목적이다 .request 메소드는 Subcription 에 대해 현재 처리되지 않은 요청을 위한 아이템의 개수를 추가하게 된다. 몇개의 아이템을 요청할 것인지를 요청하는 것이다.

SubmissionPublisher

SubmissionPublisher 는 non-null 아이템을 생성해주는 Publisher 이다. 생성을 해준다고 해서 자동으로 생성해주는 것이 아니라 아이템을 제출해야 한다. 이 제출된 아이템은 순차적으로 Publish 해준다.

submit

1
2
3
public int submit(T item) {
        return doOffer(item, Long.MAX_VALUE, null);
    }

이 메소드는 비동기적으로 Subscriber의 onNext 메소드를 호출함으로써 인수로 받은 아이템을 Subscriber 에 아이템을 발행한다.

Reactive Stream Family

Reactive Stream 에는 다양한 프레임워크, 라이브러리들이 존재한다. 이것들은 각자의 고유한 이름과 특징을 가지고 있다. 어떤 것들이 있는지 간단하게 정리해 본다.

Reactive Streams

저수준의 규약으로 주로 자바 인터페이스(Interface) 로 구현 되어 있다. 명시적인 back-pressure 으로 Publisher 와 Subscriber 의 기본 빌딩 블록을 표현한다. Java 9 에서 java.util.concurrent.Flow 로 구현되어 있다.

RxJava

이것은 Reactive Extension 이다. Neflix 에서 개발해 오픈소스로 전화하면서 세상에 알려졌다. ReactiveX 라고도 불린다. 브릿지 Reactive Stream 이라고 말하기도 하는데, Reactive Stream 을 위한 타입 전환을 지원한다.

Reactor

자바 프레임워크 이다. Spring 배포로 유명한 피보탈(Pivotal) 에서 제작해 오픈소스로 배포하고 있다.

Spring Framework

HTTP 서버/클라이언트을 툴을 비롯해 리액트 기능을 가지고 있다. Spring 의 특징은 어노테이션을 이용한 기능 주입등을 사용할 수 있다. 비동기 HTTP 서버에서 구동가능하다. (Netty, Undertow, Tomcat 8 이상)

Akka Stream

Actor Model 을 기반으로 애플리케이션 개발을 위한 Java, Scala 를 위한 툴킷이다.

이것을 정리하는 이유가 있다. Reactive Stream 은 스펙이기 때문이다. 이 스펙을 만족하면 Reactive Stream 이라고 할 수 있다. 물론 자바의 저수준 인터페이스 이름도 Reactive Stream 이라 헷깔릴 수 있지만 Reactive Stream 스펙을 만족하는 다양하고 라이브러리, 프레임워크, 툴킷들이 있다.

Reactive Stream 기본 아이디어

자바 9에서 소개된 Reactive Stream 은 비동기(Asynchronously), 논 블럭킹(Non-Blocking)이 특징이다.

그렇다면 왜 이것이 특징이되어야만 했나. 이 특징에 반대되는 개념은 블럭킹(Blocking) 이며 블럭킹을 발생시키는 요인은 동시식 요청인 것이다. 결과적으로 이 둘을 해결해야만 하는 과제를 안고 있었는데 Reactive Stream 이 이 문제를 해결했다고 볼수 있다.

이 글에서 Reactive Stream 에서 핵심 특징의 아이디어를 아주 가볍게 고찰해 본다.

일반적인 데이터 처리 흐름.

데이터를 처리를 어떻게 할까? 좀 더 정확하게 표현을 한다면 데이터 처리를 어떠한 형태를 가지고 할까?

대부분 위와 같은 형태를 가진다. 첫째로 데이터 처리를 요청하는 무언가가 있다. 이를 ‘데이터 처리 요청자’라고 하자. 둘째로 데이터를 처리하는 무언가가 있다. 이를 ‘데이터 처리자’라고 하자. 데이터 처리 요청자는 데이터 처리를 담당하는 데이터 처리자에게 데이터를 던진다. 그러면 데이터 처리자는 요청이 들어온 순서대로 데이터를 처리하게 된다.

그런데, 데이터 처리 요청자가 갑자기 한꺼번에 많은 데이터를 던지면 어떻게 될까? 아니면 데이터 처리 요청자 여러개가 하나의 데이터 처리자에게 데이터를 던지면 어떻게 될까?

데이터 처리자는 일을 처리하는데 필요한 자원이 한정되어 있다. 순차적으로 일을 처리하는 데이터 처리자는 한꺼번에 밀려드는 데이터를 쌓아두게 된다. 또, 데이터 처리 요청자는 요청한 데이터가 모두 처리되어 돌아올때까지 기달려야 한다.

이렇게 되면 전체적으로 시스템의 성능이 느려지게 된다. 모든 데이터처리가 동기화되어서 작동되는 방식이며 데이터 처리자가 모든 것을 처리할때까지 요청자는 다른 요청을 모두 차단(Block) 하게 된다.

Reactive Stream 은 이러한 문제를 해결하고자 하는게 핵심 포인트라고 보면 된다.

기본 아이디어 – 데이터 흐름을 뒤집다.

데이터 처리자의 자원은 한정되어 있다. 자원이 할당되어져야 데이터 처리자는 데이터를 처리하게 된다.

그렇다면 데이터 처리자가 자원이 할당 되었을때에 데이터 처리자가 데이터 요청자에 데이터를 가지고 가면 될 것이 아닌가? 이렇게 하기 위해서는 데이터 처리자가 데이터 요청자를 알고 있어야 한다.

이러한 아이디어는 Reactive Stream 에서는 다음과 같은 것이 핵심적인 키 포인트로 정리가 된다.

  • Flow Control
  • Publish-Subscribe pattern

기존의 데이터 흐름 제어를 완전히 뒤집은 새로운 아이디어다.

Reactive Stream 작동 방법

Reactive Stream 에서 구현은 기본 아이디어를 바탕으로 하지만 약간 다르다.

Reactive Stream 에서는 Subcriber 가 Publisher 에게 직접적으로 데이터를 요청하는 것이 아니라 어느정도 데이터 처리가 가능한지에 대한 정보를 알려준다. 그렇게되면 Publisher 는 처리가 가능한 정도만 데이터를 보내게 된다.

Publisher 와 Subscriber 사이에 정보를 교환하기 위한 일종의 채널이 필요하게 된다. 이러한 채널을 Subscription 이라고 한다. 이러한 Subscription 은 Subscriber 가 Publisher 에 가입하는 순간 생성된다.

Subscription 은 Publisher 와 Subcriber 간의 통신 채널이다. Subcriber 는 Subscription 을 통해 몇개나 받을 수 있는지에 대한 정보를 통지한다. 그러면 Publisher 는 다음과 같은 정보를 Subcriber 에게 전송한다.

  • Subscribed with subscription
  • error
  • complete
  • cancel

Publisher 가 complete 나 cancel 을 통지하면 채널은 해제되고 Publisher 와 Subscriber 관계는 끝이 난다.

Back-Pressure

역압이라고 번역하던데, 의미를 파악하기 어려운 용어들이다. 이 용어에 대한 정의는 다음에서 찾을 수 있다 .

This back-pressure is an important feedback mechanism that allows systems to gracefully respond to load rather than collapse under it

Back-Pressure 는 중요한 피드백 매커니즘인데, 대량으로 데이터를 수신한 Subscriber 가 과부하에 응답을 못하거나 시스템이 다운되지 않고 정상적으로 응답하게 해준다.

https://www.reactivemanifesto.org/glossary#Back-Pressure

Back-Pressure 는 매커니즘인데, 앞에서 설명한 어쩔땐 pull-based 혹은 push-based 로 작동되게하는 것이 바로 Back-Pressure 다.

여기서 한가지 중요한 포인트가 있다. Back-Pressure 는 성능을 보장하지 않는다는 것이다. 시스템을 보호해 어떻게든 응답을 보장하는게 목적인 것이지 Subscriber 가 응답을 빠르게 해야한다는 것은 아니다.

Gradle 설치

이 문서는 Gradle 설치에 관한 것이다. 설치할 시스템은 Linux 이다.

설치(Installation)

Gradle 공식 페이지에서 다운로드가 가능하다.

1
]$ wget https://services.gradle.org/distributions/gradle-6.0.1-bin.zip

다음과 같이 압축을 해제하면 기본적으로 설치는 끝난다.

1
2
]$ unzip gradle-6.0.1-bin.zip
]$ ln -s gradle-6.0.1 gradle

환경변수 설정

쉘 환경변수는 두가지로 다음과 같이 설정을 해줘야 한다. 쉘 환경변수는 계정에만 적용할 수도 있고 전체 시스템에 적용할 수도 있다.

GRADLE_HOME

GRADLE_HOME 은 Gradle 설치한 홈 디렉토리를 지정하면 된다.

GRADLE_USER_HOME

이 디렉토리는 다운로드한 리소스, 컴파일된 빌드 스크립트들을 캐쉬하는데 사용된다. 의존성 라이브러리를 다운로드 하는 디렉토리이기도 하다. 다음과 같이 디렉토리를 생성해 준다.

1
]$ mkdir gradle/repository

이제 이것들을 모두 쉘 환경변수로 등록해 준다.

1
2
3
4
]$ cat .bashrc
export GRADLE_USER_HOME=$HOME/gradle/repository
export GRADLE_HOME=$HOME/gradle
PATH=$GRADLE_HOME:$PATH

스트림(Stream)

자바(Java) 세계에서 언제부터인지 스트림(Stream) 이라는 단어를 목격하게 되었다. 내 기억으로는 Java 8 에서부터 시작된 것 같은데 난데없는 이 단어가 왜 그렇게 핵심이 되었는지가 의문이였다. 도대체 왜 스트림(Stream) 이냐 하는 질문에 대한 대답을 듣기도 어려웠던 시절이기도 하다. 그져 사용하는 방법을 익히는데에 몰두하는 모습만 목격됐을 뿐이다.

java.util.stream

스트림(Stream) 에 대한 정의는 다양하다.

데이터 소스(Array, List) 로부터 흐름을 가지는 데이터의 집합체이며 통합연산을(bulk processing) 통해 데이터를 변형시키고 최종적으로 소비자가 그 데이터를 소비하도록 한다.

스트림을 다루게 되면 항상 다음과 같은 데이터 소스들을 만나게 된다. 모두 데이터의 집합체들이다.

  • Array
  • List

하필 왜 데이터 집합체들일까

컴퓨터 알고리즘 필요성과 유사한 스트림(Stream)

난데 없이 컴퓨터 알고리즘을 꺼내온 이유가 있다. 컴퓨터 알고리즘을 공부할때에 가장 먼저 만나는 것이 정렬(sort)문제이다. 그런데, 이런 질문을 하게된다.

왜 하필 정렬부터 인가?

이에 대한 대답은 간단다.

Compute 연산과 Memory 공간을 절약하기 위해서..

컴퓨터가 중복된 데이터를 어떻게 찾아낼까? 정렬을하면 쉽게 해결된다. 정렬된 데이터가 아니라면 모든 데이터를 비교해야 하지만 정렬할 경우에 같은 위상을 같은 데이터 값이 나오게 되는데 이를 하나만 남기고 지우면 간단해 진다.

이렇게 함으로써 Memory 공간도 절약하게 되고 이렇게 중복되지 않은 데이터를 가지고 Compute 연산을 할 경우에 당연히 그에 들어가는 비용도 줄게 된다.

자바에서 스트림도 이와 유사하다.

자바에서 데이터를 다루는 방법은 다양한다. 이는 데이터 소스를 통해서 다루어지는데, 이 데이터 소스를 간단하게 타입(Type) 이라고 생각해보자. 정수형, 문자열 등은 가장 단순한 타입이다.

Primative
1
2
int a = 10;
String b = "systemv";

이런 타입들은 단 하나의 데이터만 저장하고 있을 뿐 “데이터들” 을 가지고 있지 않다. Compute 연산 알고리즘에서는 여러 데이터들의 집합을 다룬다. 컴퓨터가 가지고 있는 데이터들이란 집합을 이야기 한다. 따라서 데이터 소스라고하면 “데이터들” 을 지칭하며 자바에서 이런형태의 데이터 타입은 Array, List 가 대표적이다.

Array
1
2
3
4
5
private static Employee[] arrayOfEmps = {
    new Employee(1, "Amazon", 10.0),
    new Employee(2, "MSFT", 20.5),
    new Employee(3, "Samsung", 30.0)
};

그럼 이런 생각을 하게된다. 데이터 집합체들을 어떻게 하면 빠르게 중복을 제거하고 연산을 하게 만들 것인가? 과거에 For loop 문과 같은 것을 이용해서 조건식을 붙이면서 사용을 할 수도 있다.

람다(Lambda)

연속된 데이터들을 다루기만 할 거라면 단순하게 For loop 문을 이용하면 된다. 만일 이런 생각을 하게 된다.

연속된 데이터를 처리할때에 병렬을 이용해서 처리보자.

For loop 문에서 병렬처리는 쉬운게 아니다. Thread 를 이용할 수도 있지만 이건 동시성 프로그래밍이지 병렬은 아니다.

이를 위해서 자바 8 에서는 람다(Lambda) 를 도입했다. 이것에 대한 정의를 보면 함수형 프로그래밍(Funtional Programming) 이라는 말을 자주 접하게 되는데 병렬연산을 가능하게 하는 부분이다.

자바 8 스트림은 이 람다를 기반으로 한다. 결국에 스트림은 벌크 프로세싱(Bulk Processing) 을 람다를 사용해 구현하여 빠른 고속 데이터 처리가 가능하다.

스트림 – 흐른다.

스트림의 중요한 특징은 흐름이다. 프로그래밍에서 데이터를 다룰때 흐름 없이 다루는 경우도 많다. 앞에서 컴퓨터가 다루는 데이터는 “데이터들” 이라고 했는데, 이것들을 흐름을 가지고 연산을 수행하는게 스트림이다.

“흐른다” 라는 말을 수도관을 떠올리게 한다. 왼쪽에 물을 흘려보내면 오른쪽으로 물이 나온다. 데이터를 왼쪽에서 흘려보내면 오른쪽으로 물이 나온다. 만일 이 물이 설탕물로 만들고 싶다면 중간에 설탕을 뿌리면된다. 이물질을 제거하고 싶다면 이물질 제거기를 설치하면 된다.

이렇게 보면 누군가 데이터를 흘려보내는 놈이 필요하고 데이터를 받아 마시는 놈이 필요하게 된다. 이것을 Producer 와 Comsumer 관계라고 부른다.

리액티브 와 무슨 관계?

자바 스트림과 Reactive 관계보다 차이가 존재한다.

스트림(Stream) 은 데이터를 생산하면 즉각 소비가 발생한다. 하지만 리액티브 는 그렇지 않다. 리액티브 은 시간이 지남에 따라서 생산과 소비가 발생한다. 생산과 소비가 즉각적이지 않다.

이말을 잘 생각해 볼 필요가 있다. 스트림은 데이터를 다루는 영역에서 매우 유용할 수 있다. 프로그래밍 연산을 할 경우에 적합하게 사용되어질 수 있다. 하지만 Reactive 는 프로그래밍 연산보다 네트워크를 통한 데이터 요청과 리턴에 접합한 모델이라고 할 수 있다.

차이는 또 있다. 리액티브 에서 생산자는 반드시 흐름 데이터만 만들지 않는다. 대표적으로 웹에서 클릭(Click) 조차도 리액티브 에서 생산자가 될 수 있다. 그래서 연속된 데이터 흐름이 없다보니 뭔가 생산하는 개념이 아닌것이여서 생산자(Producer) 라는 말을 쓰지 않는다.

“즉각적으로 소비가 발생하지 않는다” 라는 말도 중요하다. 비동기적으로 데이터 리턴이 발생한다는 것을 의미 한다. 하지만 리턴 값을 받기 위한 준비는 항상하고 있다는것도 중요하다.

리액티브 는 네트워크를 통한 데이터 요청, 리턴 모델에 적합하다. 리액티브 요청한 것에 대한 데이터들을 다룰때에는 스트림을 이용할 수도 있다.

Error – The server time zone value ‘KST’ is unrecognized

Java 와 MySQL 을 연동하는 상황에서 다음과 같은 오류를 만나기도 한다.

server time zone value 'KST' is unrecognized
Shell
1
2
3
4
5
6
7
HTTP Status 500 – Internal Server Error
 
Type Exception Report
 
Message Request processing failed; nested exception is org.springframework.transaction.CannotCreateTransactionException: Could not open JDBC Connection for transaction; nested exception is java.sql.SQLException: Cannot create PoolableConnectionFactory (The server time zone value 'KST' is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.)
 
Description The server encountered an unexpected condition that prevented it from fulfilling the request.

자세히 보면 java.sql.SQLException 이 보인다. 이 경우는 결국에는 데이터베이스쪽에 문제가 있다는 것이며, MySQL을 사용할 경우에 보이게 된다. 이는 MySQL의 시간을 나타내는 타임존 설정이 맞지 않아 생기는 오류다.

MySQL 5.7, MariaDB 10

MySQL 5.7 과 MariaDB 10 을 사용한다면 my.cnf 에서 다음과 같이 설정함으로써 문제 해결이 가능하다.

MySQL 5.7
INI
1
2
# time zone 설정
default-time-zone=Asia/Seoul

설정할 수 있는 타임존 리스트는 MySQL 메뉴얼을 참조하기 바란다. 이렇게 했는데도 다음과 같은 오류를 만날 가능성도 있다.

illegal or unknown default time zone
ZSH
1
[ERROR] Fatal error: Illegal or unknown default time zone 'Asia/Seoul'

이럴때는 다음과 같이 해준다.

ZSH
1
/opt/mysql/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p

Spring5 requirements

Spring5 를위한 필요사항들을 정리.

  1. java 8. 원래 Spring5 는 Java 9를 기반으로 하려고 했지만 변경됐다. 이로 인해서 Reactive Programming을 하기 위해서는 의존성 라이브러리를 필요로 한다. 현재Java 9 은 지원이 중단된 상태다. Java 10 을 사용해도 된다.
  2. Java EE 8 호환. Servlet 4.0, Bean Validation 2.0 등을 지원한다.
  3. HTTP/2 지원한다.
  4. Jackson 2.9, Protobuf 3.0 지원.

 

MyBatis Error – The content of elements must consist of well-formed character data or markup.

MyBatis 의 Mapper XML 파일에서 다음과 같은 오류가 발생 했다.

MyBatis Mapper XML Error
“The content of elements must consist of well-formed character data or markup.”

이는 SQL 연산자인 <, =, > 와 같은 엔터티가 MyBatis 문법과 혼동되서 나오는 문제다. 이럴때는 CDATA 를 적용해주면 된다.

MySQL
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
<select id="getCheckInDay" resultType="CheckInDayVO">
<![CDATA[
SELECT
dayofweek,
DATE(start_date) AS day,
start_date,
end_date,
TIMEDIFF(end_date, start_date) AS worktime,
CASE
WHEN end_date is null
OR TIMESTAMPDIFF(MINUTE,start_date,end_date) < 160 THEN
TIMESTAMPDIFF(MINUTE,start_date,now())
ELSE
TIMESTAMPDIFF(MINUTE,start_date,end_date)
END workminute,
CASE
WHEN end_date is null
OR TIMESTAMPDIFF(MINUTE,start_date,end_date) < 160 THEN
(TIMESTAMPDIFF(MINUTE,start_date,now())/480)*100
ELSE
(TIMESTAMPDIFF(MINUTE,start_date,end_date)/480)*100
END workpercentage
FROM
checkin
WHERE
username = #{username}
AND
DATE(start_date) = #{today}
]]>
</select>

이렇게하면 에러를 없앨 수 있다.