요즘 프로젝트를 하고 있는데, 역시나 자바 시스템이 있다. Spring Boot3 을 사용하고 있고 자바 17을 쓰는등 나름대로 괜찮은 환경에서 개발이 이루어지고 있다. 그런데, 이것을 서버에서 배포를 하고 Spring Boot 를 실행해야 하는데, 어떻게 하나 봤더니 초보자 수준도 못 벗어나는 설정을 하고 있으니… 안타까운 마음에 어떻게 하는 것이 좋은 것인지 한번 적어봤다.
Spring boot, jar 실행 파일
Spring Boot3 를 컴파일 하면 jar 파일 나온다. 그리고 별다른 서버 없이도 바로 실행하고 접속이 가능해 진다. 한가지 재미있는 사실은 많은 사람들이 Spring boot3 에 실행 파일 jar 이 내장된 WAS 서버가 구동되면서 실행된다는 걸 모른다는 거다. 심지여 그것이 Tomcat 이라는 것도. 물론 어떤 프로그래밍 모델인지에 따라서 Tomcat 이 되기도 하고 Netty 되기도 하지만, 과연 Reactive Programming Model 로 짜는 사람이 몇이나 있나 싶다. 대부분 Spring MVC 이고 Servlet 이면 기본적으로 Tomcat 이 구동된다. 내장형 Tomcat
현대의 소프트웨어 아키텍쳐로 인기가 있는, 아니 어쩌면 전부일 수도 있는 REST 에 대한 역사는 2000년으로 거슬러 올라간다. 시기적으로 그 당시에 한국에서는 IT 버블이라는 현상도 있었던 만큼 IT 관련 기업들이 많이 생겨나고 했던 때다.
2000년 당시를 회상해보면 웹 메일(Web Mail) 서비스를 기반으로 하는 포털들이 많이 있었다. 해외에서는 야후(Yahoo) 가 대표적이였고 마이크로소프트(Microsoft) 의 경우에도 Hotmail 과 함께 MSN 포털을 운영했었다. 국내에서는 다음(Daum) 이 한메일(Hanmail) 서비스를, 네이버(Naver)가 네이버 메일을 기반으로 포털로서 성장하던 때다. 아,,, 네이트도 있었는데, 당시 네이트는 네이트온(NateOn) 메신저가 인기가 있었던 것으로 기억한다.
그 당시에 해외에서도 그렇지만, 소프트웨어 아키텍쳐, 좀 더 정확하게는 이기종간에 데이터 전송을 위한 아키텍쳐로 SOAP(Simple Object Access Protocol) 를 기반으로 구축되었다. 물론 XMLRpc 도 존재했지만 엔터프라이즈 서비스에서는 SOAP 이 거의 표준처럼 사용되던 때였다.
REST 는 HTTP 를 기반으로 하기 때문에 서버의 기종과는 아무런 상관없이 데이터 전송이 가능했다. 더 군다나 그 구조자체가 SOAP 비해서는 매우 단순했기 때문에 데이터 전송에 대한 오버헤더도 줄었다.
이후에 REST 를 기반으로 구축한 업체들이 나타나게 되는데, eBay 가 그중 하나였다. eBay 는 그들의 파트너들에게 필요한 정부를 REST API 형태로 제공했던 것이다. 그때가 2000년 11월즘이였다고 한다. 이후에 Amazon, Flicker 등이 REST 기반 서비스를 제공하게 된다.
G1 GC 의 기본적인 목표는 짧은 STW 시간을 가지고 가는 것이다. 어짜피 STW 를 피하지 못할 바에야 이 시간을 짧게 가지고 가는게 유리하다.
여기서 구분해야할는게 있는데 STW 는 Young GC 일때도 발생한다. 하지만 그 시간이 매우 짧아서 못 느낄 정도일 뿐이다. Old GC 의 경우에는 Young GC 대비 STW 시간이 매우 길다. 그 이유는 Heap 메모리 전체를 청소해야하기 때문이며 청소해야할 공간이 클 수록 Garbage Collector 작동을 위한 자원 소모가 많아진다.
다음과 같은 목표를 갖는다.
짧은 STW 시간을 갖도록 한다.
Full GC 가 발생되지 않도록 한다.
여기서 주목해야하는 것이 Full GC 발생하지 않도록 이다.
Full GC 발생 않도록…
MaxTenuringThreshold
이 말은 결국에는 Young GC 만 만들어야 한다는 것을 의미한다. 문제는 live Object 는 결국 최종적으로는 Old Generation 영역으로 이동할 수밖에 없다는데 있다. 그래서 G1 에서는 최대한 Old Generation 영역으로 이동하는 것을 늦출려고 한다. 이에 대한 파라메터가 -XX:MaxTenuringThreshold 다.
-XX:MaxTenuringThreshold: Sets the maximum amount of iterations to keep live objects in the new generation. This defaults to 15.
live 객체를 new generation 에 머물게하기 위한 최대 반복횟수로 번역된다. new generation 에서 Young GC 가 발생하면 오래 살아남을 live 객체를 선별되게 된다. 오래 살아남을 live 객체는 당연히 Old generation 영역으로 이동해야 하는데, 이것을 한번에 판단하지 않겠다는 뜻이다.
적어도 여러번.. 기본값으로 15번 정도는 같은 live 객체가 new generation 에서 생존해 있어야 한다. 그래야 ‘아~ 이놈은 오래 살아남을 놈이구나.. Old Generation 으로 옮기자’ 가 된다.
이러한 메커니즘은 Full GC 를 피하기 위한 것이다. Old Generation 에 live 객체가 많아지면 많아질 수록 Full GC 발생가능성은 커진다. 그래서 왠만하면 Young Generation 에 객체를 머물게하고 Garbage 가 되길 기다린다.
MaxGCPauseMillis – Do not set the new generation size unless required.
이 값을 꼭 지정하도록 하고 있다. G1 은 a pause time-target 을 갖는다. 이값은 MaxGCPauseMillis 로 지정하게 되는데 문제는 이 값을 어떻게든 충족되도록 동작하기 뒤해서 G1은 Young Generation 크기를 자동으로 조정하게 된다.
따라서 반드시 Young Generation 크기를 지정해서는 안된다. 오로지 MaxGCPauseMillis 값을 지정해주고 이를 통해서 자동으로 조정되도록 해야 한다. 200 ~ 500 사이에 값을 지정하면 되는데 될수있으면 그냥 기본값으로 둔다.
G1 에서 추천하는 JVM Options
다음은 G1 에서 추천하는 JVM Options 이다.
JVM Option
Details
-XX:+DisableExplicitGC
기본 추천 옵션으로 명시적 GC 를 사용하지 못하게 한다.
-XX:+UseStringDeduplication
기본값이 disabled 인데, 켜준다. String deduplication 에 대한 메모리 사용을 줄여준다.
-XX:MaxMetaspaceSize
최대 사용가능한 클래스 메타데이터 크기. 네이티브 메모리를 사용한다. 256MB 를 권장하지만 값은 유동적이다.
-XX:MaxTenuringThreshold
기본값: 15. new generation 에 live 객체를 유지하기 위한 최대 반복 횟수. 오랫동안 살아남아야할 live 객체가 많다면 값을 낮추고 그렇지않다면 기본값 사용 권장.
문제는 Eclipse 나 IDE 툴에서는 SpringBoot 애플리케이션이 잘만 실행되지만 정작 컴파일을 할려고 하면 위와같은 오류가 나오는다는 것이다. 아무리 봐도 소스코드상에서는 아무런 문제가 없는데도 이런다면 다음과 같이 gradle 에서 annotationProcessor 를 추가해주면 된다.
The Jakarta EE 8 has the same set of specifications from Java EE 8 with no changes in its features. The only change is the new process to evolve these specifications. With this, Jakarta EE 8 is a milestone in Java enterprise history, as it inserts these specifications in a new process to boost the specifications to a cloud-native application approach.
이 글은 Spring5 에 Spring-Security 에 대한 기초 템플릿이다. Session 유지를 위해서 Redis 를 필요로 한다. 또, ElasticSearch 의 RestHighLevelClient 로 ElasticSearch를 연결 한다. 데이터베이스는 JNDI 설정으로 연결 된다.
다음과 같은 내용을 담았다.
JDK 11
Tomcat 서버 9 를 이용.
spring-session.xml 을 작성해 Redis 를 세션으로 사용하도록 했다.
JNDI 를 이용해 MySQL 에 연결된다.
Redis 설정한 이유는 Spring Security 에 인증을 InMemory 를 요구 한다. 이는 다음과 같은 설정 때문이다.
spring-security.xml 에 bcrypt 패스워드 설정
XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<authentication-manager>
<authentication-provider>
<user-service>
<!-- This is required a InMemory DB. So I setup Redis and config to a spring-session.xml for connecting the redis
if you set spring-session.xml, you should config also web.xml for springSessionRepositoryFilter
이 문서는 Spring5 Security 기초 템플릿에 대한 것이다. Spring5 에 Spring-Security 를 이용해 기초적인 로그인을 구현 했다. Session 은 InMemory 가 아닌 WAS 서버에 세션을 저장한다. 로그인 정보는 spring-security.xml 에 정의된 것을 그대로 사용했다. 그야말로 기초적인 내용만 담았다.
이 템플릿이 동작하기 위한 조건은 다음과 같다.
Java 1.8 기반.
데이터베이스가 연결되어 있어야 한다. 데이터베이스는 MySQL 이다.
WAS 서버에 JNDI 를 연결된다.
users 테이블이 필요한데, user.sql 파일에 내용이 있다.
spring security 의 Role 기반 권한 접근 제어.
context root 는 malluser 이다.
작동방식
Login 화면
권한을 체크하기 때문에 로그인 화면이 먼저 나온다. 권한 체크는 다음과 같이 Controller 에서 이루어진다.
SpringFramework 을 이용하다보면 데이터베이스 액세스를 위해서 MyBatis 를 사용하곤 한다. SQL 매퍼라고 불리기도 하는 것인데, 이를 이용하면 손쉽게 자바 코드와 SQL 문을 분리해줄 수 있을뿐만 아니라 MyBatis 에서 제공하는 여러가지 추가적인 기능을 이용해 데이터베이스를 좀 더 유연하게 사용할 수 있다.
DAO
보통 MyBatis 를 이용할대는 DAO 를 구조를 사용하곤 했다. Data Access Object 라고 불리는 것으로 말 그대로 데이터 접근을 위한 객체로서 sqlSession 객체를 이용해 데이터베이스 조회만 전담하는 객체다.
이 구조는 인터페이스와 그것을 구현한 구현체 클래스가 있어야 한다. 이를 위해서 Spring의 컨텍스트 설정을 해줘야 하는데 대략 다음과 같다.
이렇게 함으로써 Mapper 를 이용하면서도 DAO 구조를 그대로 유지할 수 있다. 문제는 DAO 에서 Mapper 인터페이스 객체를 매번 생성해 줘야 한다는 것이다. sqlSession.getMapper 를 이용해서 매번 가지고 오게 되는데, 이렇게 하는 것보다는 Spring Context 에서 빈으로 등록해 와이어로 가지고 오게 되면 DAO 가 아닌 Service 계층에서 호출이 가능하다.
UserService 에 Mybatis 의 Mapper 인터페이스를 Auto wiring 예제
Java
1
2
3
4
5
@Service
publicclassUserServiceImplimplementsUserService{
@Autowired
publicUserTableMapper userTableMapper;
하지만 이렇게 할 경우에 Mapper 인터페이스 객체 하나하나 전부 Spring Context 에서 빈으로 만들어 줘야 한다. 그래서 이렇게 하지말고 Mapper 인터페이스를 스캔하도록 할 수 있는데 이를 위해서 mybatis-spring 라이브러리 패키지와 xsd 설정을 해줘야 한다. xsd 과 설정은 Spring Context 파일에 다음과 같이 해준다.
의외로 웹 프로그래밍을 하는 사람들 조차도 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-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 를 한꺼번에 쓰는건 잘못된 것이다.
index.html 파일 안에 구조가 저렇게 되어 있다고 가정하면, 대략 다음과 같은 형태의 캐시 전략을 쓸 수 있다.
Contents
Cache-Control
index.html
Cache-Control: no-cache
common.css
Cache-Control: max-age=86400
a.js
Cache-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{
expires1M;
add_headerCache-Control"public, must-revalidate";
}
Nginx 에서 max-age 설정은 expires 해도 된다. 이렇게 하면 구형의 Expire 지시자도 함께 지정된다.
브라우저는 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 도메인 인증서가 있는 사이트에서만 사용 가능하다.
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 헤더 설정
많은 웹 애플리케이션이 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 선진국이라는 것이 좋은 인프라에 작동하기만 하면 되는 앱만으로 얻을 수 있는 거였다니..
