'proxy'에 해당되는 글 5건
- 2020.08.22 :: Web Server - Nginx 설치 및 사용방법(nginx cache, reverse proxy, 프록시, 캐시)
- 2020.04.21 :: Docker - DOOD로 띄웠을 경우 proxy(프록시) 설정
- 2020.04.12 :: Network - Proxy(프록시)와 Gateway(게이트웨이)란? 이 둘의 차이점은?
- 2019.02.25 :: Spring Cloud - Zuul API gateway & Proxy !(Netflix Zuul)
- 2019.02.04 :: JPA - 즉시로딩과 지연로딩(FetchType.EAGER,FetchType.LAZY) 그리고 프록시
오늘 포스팅해볼 내용은 Web server 중 하나인 Nginx의 설치 및 사용방법에 대해 다루어본다. 우선 Nginx는 무엇인가 알아보자.
예제 설정은 아래 깃헙사이트에 있다.
yoonyeoseong/kubernetes-sample
Kubernetes(쿠버네티스) sample. Contribute to yoonyeoseong/kubernetes-sample development by creating an account on GitHub.
github.com
Wiki(https://ko.wikipedia.org/wiki/Nginx)
Nginx(엔진 x라 읽는다)는 웹 서버 소프트웨어로, 가벼움과 높은 성능을 목표로 한다. 웹 서버, 리버스 프록시 및 메일 프록시 기능을 가진다.
2017년 10월 기준으로 실질적으로 작동하는 웹 사이트(active site)들에서 쓰이는 웹 서버 소프트웨어 순위는 아파치(44.89%), 엔진엑스(20.65%), 구글 웹 서버(7.86%), 마이크로소프트 IIS(7.32%)순이다.[1] 이 조사에서 생성은 되어있으나 정상적으로 작동하지 않는 웹 사이트들은 배제되었으며[2] 특히 MS의 인터넷 정보 서비스(IIS)를 설치한 웹 사이트들의 상당수가 비활성 사이트였다. 그런 사이트들도 포함하면 MS IIS가 1위이다. 2017년 6월 현재 Nginx는 한국 전체 등록 도메인 중 24.73%가 사용하고 있다.[3]
Nginx는 요청에 응답하기 위해 비동기 이벤트 기반 구조를 가진다. 이것은 아파치 HTTP 서버의 스레드/프로세스 기반 구조를 가지는 것과는 대조적이다. 이러한 구조는 서버에 많은 부하가 생길 경우의 성능을 예측하기 쉽게 해준다.
또한 nginx는 하나의 마스터 프로세스와 여러 워커 프로세스가 있고, 마스터 프로세스는 주로 설정 파일을 읽고 적용하며 워커 프로세스들을 관리하는 역할을 하게 된다. 워커 프로세스는 실제 요청에 대한 처리를 하게 된다. nginx는 event driven 모델을 메커니즘으로 사용하여 실제 워커 프로세스간 요청을 효율적으로 분산한다.
실습은 Mac os 기준으로 실습을 진행해 볼것이다. 우선 nginx를 설치해보자.
Nginx install
> brew install nginx
brew로 설치를 아래와 같은 디렉터리들이 생성된다. 우선 아래 디렉토리를 실습을 진행하면서 전부 알아볼 것이다.
Docroot is: /usr/local/var/www
The default port has been set in /usr/local/etc/nginx/nginx.conf to 8080 so that
nginx can run without sudo.
nginx will load all files in /usr/local/etc/nginx/servers/.
To have launchd start nginx now and restart at login:
brew services start nginx
Or, if you don't want/need a background service you can just run:
nginx
==> Summary
🍺 /usr/local/Cellar/nginx/1.19.2: 25 files, 2.1MB
==> Caveats
==> nginx
Docroot is: /usr/local/var/www
The default port has been set in /usr/local/etc/nginx/nginx.conf to 8080 so that
nginx can run without sudo.
nginx will load all files in /usr/local/etc/nginx/servers/.
To have launchd start nginx now and restart at login:
brew services start nginx
Or, if you don't want/need a background service you can just run:
nginx
Nginx 구동 명령어(nginx -s <signal>
- nginx : 서버시작
- nginx -s stop : 서버종료(워커들이 요청을 처리중이더라도 그냥 종료한다.)
- nginx -s quit : 워커 프로세스가 현재 요청 처리를 완료할 때까지 대기하고 모두 처리완료된 후에 서버 종료.
- nginx -s reload : nginx config를 새로 로드한다. 마스터 프로세스가 설정을 다시 로드하라는 요청을 받으면 설정 유효성 검사후 새로운 워커 프로세스를 시작하고, 이전 워커 프로세스에게 종료 메시지를 보내게 되고 이전 워커 프로세스는 요청을 완료하게 되면 종료된다.
위 명령어로 nginx를 시작 해보자 !
> nginx
> lsof -i:8080
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 88891 yun-yeoseong 6u IPv4 0x7370b7ed168f296f 0t0 TCP *:http-alt (LISTEN)
nginx 88892 yun-yeoseong 6u IPv4 0x7370b7ed168f296f 0t0 TCP *:http-alt (LISTEN)
#실행중인 모든 nginx 프로세스 목록을 가져온다.
> ps -ax | grep nginx
88891 ?? 0:00.00 nginx: master process nginx
88892 ?? 0:00.01 nginx: worker process
89201 ttys000 0:00.03 vi nginx.conf
89695 ttys001 0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn nginx
디폴트 포트인 8080으로 nginx 프로세스가 잘 떠있다. 이제 웹브라우저에서 localhost:8080으로 접속해보자.
> curl localhost:8080
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
브라우저에 welcome to nginx가 보인다면 설치 및 실행이 잘된 것이다 ! 어 그렇다면, 여기서 조금 의아한 것이 있을 것이다. 과연 저 html은 어디서 응답을 준것일까?
Docroot
답은 도큐먼트 루트에 있다. 설치를 하면 아래와 같은 로그가 출력되어있을 것인데, 해당 디렉토리 내에 html 파일이 존재한다.
Docroot is: /usr/local/var/www
기본적으로 웹서버는 다른 서버로 프록시 하지 않는 이상 uri로 명시한 path로 도큐먼트 루트 디렉토리를 찾아서 응답을 주게 된다. 사실 localhost:8080은 localhost:8080/index.html과 같다고 보면된다. 그렇다면 index.html의 위치를 바꾸면 어떻게 될까?
> cd /usr/local/var/www
> mkdir backup
> mv index.html ./backup
이제 아래 요청을 보내보자.
> curl localhost:8080/index.html
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.19.2</center>
</body>
</html>
우리는 index.html을 다른 디렉토리로 옮겼기 때문에 404 not found가 뜨게 된다. 그렇다면 옮긴 디렉토리 path를 명시해서 요청을 보내보자.
> curl http://localhost:8080/backup/index.html
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
응답이 잘 도착하였다. 보통 도큐멘트 루트는 어떻게 사용이 될까? 보통은 정적인 리소스 파일(css, html)을 위치시키게 된다. 그렇다면 정적인 리로스 파일을 위치시키는 이유는 무엇일까? 만약 WAS에 해당 정적인 리소스 파일을 위치시키게 되면, 사실상 서버 동작과 관련이 적은 정적 리소스를 가져오기 위한 요청도 모두 WAS로 들어가기 때문에 앱에 부하가 많이 가게 될수 있다. 그렇기 때문에 보통 정적인 리소스는 nginx(웹서버)에서 처리하고 WAS는 백엔드 데이터만 제공하게 하여 WAS의 부담을 줄여줄 수 있다.
이제는 본격적으로 Nginx의 설정을 커스터마이징해보자.
Configuration file's structure
nginx의 설정 파일은 simple directives(단순 지시문)과 block directives(블록 지시문)으로 나뉜다. 단순 지시문을 공백으로 구분 된 이름과 매개변수로 구성되며 세미콜론(;)으로 끝난다. 블록 지시문은 단순 지시문과 구조가 동일하지만 세미콜론 대신 중괄호({})로 명령 블록을 지정한다. 또한 블록지시문을 블록지시문의 중첩구조로도 이루어 질 수 있다. 이러한 지시문으로 nginx에 플러그인 된 여러 모듈을 제어하게 된다.
Nginx Configuration
nginx.conf 파일에는 nginx의 설정 내용이 들어간다. 해당 파일의 전체적인 구조(모듈)는 아래와 같이 이루어져있다.
user nginx;
worker_processes 1;
error_log logs/error.log;
events {
worker_connections 1024;
}
http {
include mime.types;
#응답의 기본 default mime type을 지정
default_type application/octet-stream;
charset utf-8;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
#지정된 에러 코드에 대해 응답나갈 document root의 html 파일을 지정
#docroot의 html말고 다른 URL로 리다이렉션 가능하다.
error_page 500 502 503 504 /50x.html;
#error_page 500 502 503 504 http://example.com/error.html
sendfile on;
tcp_nopush on;
keepalive_timeout 65;
#keepalive로 유지되는 커넥션으로 최대 처리할 요청수를 지정
#keepalive_requests 100;
#nginx의 버전을 숨길 것인가에 대한 옵션이다. 보안상 활성화하는 것을 권장한다.
server_tokens on;
#응답 컨텐츠를 압축하는 옵션, 해당 옵션말고 gzip관련 다양한 옵션 존재(압축 사이즈 등등)
gzip on;
#context : http, server, location
#클라이언트 요청 본문을 읽기 위한 버퍼 크기를 설정 64bit platform default 16k
client_body_buffer_size 16k;
#클라이언트 요청 본문을 읽기 위한 타임아웃 시간 설정
client_body_timeout 60s;
#클라이언트 요청 헤더를 읽기위한 버퍼 크기 설정
client_header_buffer_size 1k;
client_header_timeout 60s;
#클라이언트가 보낸 요청 본문의 최대 사이즈
client_max_body_size 1m;
server {
listen 80;
location / {
root html;
index index.html index.htm;
}
}
}
- Core 모듈 설정 : 위 예제의 worker_processes와 같은 지시자 설정 파일 최상단에 위치하면서 nginx의 기본적인 동작 방식을 정의한다.
- http 모듈 블록 : 밑에서 설명할 server, location의 루트 블록이라고 할 수 있고, 여기서 설정된 값을 하위 블록들은 상속한다. http 블록은 여러개를 사용할 수 있지만 관리상의 이슈로 한번만 정의하는 것을 권장한다. http, server, location 블록은 계층구조를 가지고 있고 많은 지시어가 각각의 블록에서 동시에 사용될 수 있는데, http의 내용은 server의 기본값이 되고, server의 지시어는 location의 기본값이 된다. 그리고 하위의 블록에서 선언된 지시어는 상위의 선언을 무시하고 적용된다.
- server 블록 : server 블록은 하나의 웹사이트를 선언하는데 사용된다. 가상 호스팅(vhost)의 개념이다.
- location 블록 : location 블록은 server 블록 안에 정의하며 특정 URL을 처리하는 방법을 정의한다. 예를 들어 uri path마다 다르게 요청을 처리하고 싶을 때 해당 블록 내에 정의한다.
- events 블록 : nginx는 event driven을 메커니즘으로 동작하는데, 이 event driven 동작 방식에 대한 설정을 다룬다.
nginx.conf
"user"
user의 값이 root로 되어 있다면 일반 계정으로 변경하는 것이 좋다. nginx는 마스터 프로세스와 워커 프로세스로 동작하고, 워커 프로세스가 실질적인 웹서버의 역할을 수행하는데 user 지시어는 워커프로세스의 권한을 지정한다. 만약 user의 값이 root로 되어 있다면 워커 프로세스를 root의 권한으로 동작하게 되고, 워커 프로세스를 악의적으로 사용자가 제어하게 된다면 해당 머신을 루트 사용자의 권한으로 원격제어하게 되는 셈이기 때문에 보안상 위험하다.
user 설정의 값으로는 대표성있는 이름(nginx)로 사용하고, 이 계정은 일반 유저의 권한으로 쉘에 접속할 수 없어야 안전하다.
> useradd --shell /sbin/nologin www-data
"worker_process"
worker_process는 워커 프로세스를 몇개 생성할 것인지를 지정하는 지시어이다. 이 값이 1이라면 모든 요청을 하나의 프로세스로 실행하겠다는 뜻인데, 여러개의 CPU 코어가 있는 시스템이라면 CPU 코어수만큼 지정하길 권장한다.
"events.worker_connections"
이 값은 몇개의 접속을 동시에 처리할 것인가를 지정하는 값이다. 이 값과 worker_process의 값을 조합해 동시에 최대로 처리할 수 있는 커넥션의 양을 산출할 수 있다.(worker_process*worker_connections)
"http.incloud"
가상 호스트 설정이나, 반복되는 설정들을 파일로 저장해놓고, incloude를 통해 불러올 수 있다.
"http.log_format"
access 로그에 남길 로그 포맷을 지정한다. 보통 어떠한 장애가 났을 때, 가장 먼저보는 것이 로그 파일이기 때문에 디버깅하기 위해 유용한 값들을 로그에 남겨두는 것이 중요하다. 특히나, 여러 프록시 서버를 지나오는 서버 구성인 경우에는 x-forwarded-ip 등을 지정하면 지나온 프록시들의 아이피들을 할 수 있다.
"http.access_log"
access로그를 어느 디렉토리에 남길지 설정한다.
"http.keepalive_timeout"
소켓을 끊지 않고 얼마나 유지할지에 대한 설정이다. 자세한 내용은 keepalive 개념을 확인하자.
"http.server_tokens"
nginx의 버전을 숨길 것인가에 대한 옵션이다. 보안상 활성화하는 것을 권장한다.
기타 설정들은 위 예제 파일에 주석으로 달아놓았다.
다음은 실제 프록시 설정이 들어가는 server 블록 설정을 다루어 보자.
server {
listen 80;
server_name levi.local.com;
access_log logs/access.log;
error_log logs/error.log;
error_page 500 502 503 504 /50x.html;
charset utf-8;
location / {
proxy_pass http://app;
}
}
upstream app {
server localhost:8080;
}
위 설정은 http 블록 하위로 들어가게 된다. 크게 어려운 설정은 없고, "levi.local.com:80/"으로 요청이 들어오면 upstream(요청받는 서버)으로 요청을 리버스 프록시 한다라는 뜻이다. 실제로 앱하나를 띄워보고 프록시 되는지 확인해보자.
> curl levi.local.com/api
new api ! - 7
위처럼 응답이 잘오는 것을 볼 수 있다. 그런데 사실 server 블록이 하나일때는 server_name에 적혀있는 도메인으로 오지않아도 응답을 준다. server_name이 진짜 도메인네임을 구분하기 위한 server_name으로 사용되기 위해서는 listen 포트가 같은 server 블록이 두개 이상 존재할때 이다. 아래 예제를 보자.
server {
listen 80;
server_name levi.local.com;
#access_log logs/access.log;
#error_log logs/error.log;
error_page 500 502 503 504 /50x.html;
charset utf-8;
location / {
proxy_pass http://app;
}
}
upstream app {
server localhost:8080;
}
server {
listen 80;
server_name local.yoon.com;
#access_log logs/access.log;
#error_log logs/error.log;
error_page 500 502 503 504 /50x.html;
charset utf-8;
location / {
proxy_pass http://app2;
}
}
upstream app2 {
server localhost:7070;
}
위와 같이 설정하고, 각 도메인을 분리해서 요청을 보내보자. server_name으로 분리되어 요청이 프록시 될것이다.
Nginx cache
마지막으로 location 블록에 대한 설정중 nginx cache에 설정에 대해 주로 다루어보자.
- /path/to/cache ==> 캐시 내용이 local disk 에 저장될 위치
- levels=1:2 ==> directory depth 와 사용할 name 길이.
- ex ) /data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c
- keys_zone ==> 캐시 키로 사용될 이름과 크기. 1MB 는 약 8천개의 이름 저장. 10MB면 8만개.
- max_size ==> 캐시 파일 크기의 maximum. size 가 over 되면 가장 오래전에 사용한 데이터 부터 삭제한다.
- inactive ==> access 되지 않았을 경우 얼마 뒤에 삭제 할 것인가.
- use_temp_path ==> 설정된 path 외에 임시 저장 폴더를 따로 사용할 것인가? 따로 설정하지 않는 것이 좋다.
- proxy_cache <namev> ==> 캐시로 사용할 메모리 zone 이름.
- proxy_cache_methods ==> request method를 정의한다. default : GET, HEAD
- proxy_cache_key ==> 캐시 할 때 사용할 이름.
- proxy_cache_bypass ==> 예를 들어 "http://www.example.com/?nocache=true" 이러한 요청이 왔을 때 캐싱되지 않은 response 를 보낸다. 이 설정이 없다면 nocache 아규먼트는 동작하지 않는다. http_pragma==> 헤더 Pragma:no-cache
- proxy_cache_lock ==> 활성화 시키면 한 번에 단 하나의 요청만 proxy server로 전달되어 proxy_cache_key 에 따라 캐싱된 데이터로 사용합니다. 다른 request 들은 캐싱된 데이터를 사용하거나 proxy_cache_lock_timeout의 설정에 따라 proxy server로 전달 될 수 있습니다.
- proxy_cache_valid ==> 기본적으로 캐싱할 response code 와 시간을 정의한다.
예제 설정으로는 아래와 같다.
proxy_cache_path /usr/local/etc/nginx/cache levels=1:2 keys_zone=myapp:10m max_size=10g inactive=60s use_temp_path=off;
server {
listen 80;
server_name levi.local.com;
access_log logs/access.log;
error_log logs/error.log;
error_page 500 502 503 504 /50x.html;
charset utf-8;
location / {
proxy_cache myapp;
proxy_cache_methods GET;
proxy_cache_key "$uri$is_args$args";
proxy_cache_bypass $cookie_nocache $arg_nocache $http_pragma;
proxy_ignore_headers Expires Cache-Control Set-Cookie;
#proxy_cache_lock on;
#200ok인 응답을 1분동안 캐싱
proxy_cache_valid 200 1m;
proxy_pass http://app;
}
}
upstream app {
server localhost:8080;
}
실제로 캐싱이 잘되는지 요청을 보내보고 실제 캐싱이 저장되는 디렉토리로 들어가보자.
> cd /usr/local/etc/nginx/cache
> ls
8
> cd 8
> ls
68
> cd 68
> ls
5d198634e5fa00f3cf3a478fcdf57688
> vi 5d198634e5fa00f3cf3a478fcdf57688
^E^@^@^@^@^@^@^@û½@_^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ÿÿÿÿÿÿÿÿ¿½@_^@^@^@^@#Y|^V^@^@d^Aè^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
KEY: /api?arg=args
HTTP/1.1 200 ^M
Content-Type: text/html;charset=UTF-8^M
Content-Length: 13^M
Date: Sat, 22 Aug 2020 06:39:59 GMT^M
Connection: close^M
^M
new api ! - 5
응답이 잘 캐싱된것을 볼수 있다. 그리고 대략 1분후에는 해당 캐싱 파일 지워져있다.
여기까지 간단하게 Nginx 설치 및 사용방법에 대해 다루어보았다. 맘 같아선 캐싱에 대해 더 자세히 다루고 싶었다. 대규모 웹사이트 같은 경우는 정말 장비를 늘리는 것으로는 트래픽을 받는데 한계가 있기 때문에 사실상 캐싱 싸움이 될것이기 때문이다. 이번 포스팅에서는 Nginx에 대해 맛보기 정도만 하였지만, 다음 시간에는 조금더 딥한 내용까지 다루어 볼 계획이다.
참조
nginx cache
1. cache dir 설정 proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=cache:2m 2. cache 사용 설정 server { listen 80; server_name cached.test.co.kr; access_log /var/log/nginx/cache-access.log c..
semode.tistory.com
'인프라 > Web Server & WAS' 카테고리의 다른 글
| Web - Http Header의 뜻 (0) | 2019.04.03 |
|---|---|
| 웹 취약성 검사 대비하기 ! (2) | 2018.10.26 |
| tomcat WAS에 spring(spring boot) 여러개의 war파일 배포(여러개 context) (0) | 2018.09.12 |
이번 포스팅에서 다루어볼 내용은 DOOD로 도커를 띄웠을 때, proxy 설정하는 방법이다. 그전에 간단하게 Docker in Docker(dind)와 Docker Out Of Dcoker(DooD)에 대해 알아보자.
Docker in Docker(dind)
도커 내부에 격리된 Docker 데몬을 실행하는 방법이다. CI(Jenkins docker agent) 측면에서 접근하면 Agent가 Docker client와 Docker Daemon 역할 두가지를 동시에 하게 된다. 하지만 이 방법은 단점이 존재한다. 내부의 도커 컨테이너가 privileged mode로 실행되어야 한다.
> docker run --privileged --name dind -d docker:1.8-dind
privileged 옵션을 사용하면 모든 장치에 접근할 수 있을뿐만 아니라 호스트 컴퓨터 커널의 대부분의 기능을 사용할 수 있기 때문에 보안에 좋지않은 방법이다. 하지만 실제로 실무에서 많이 쓰는 방법이긴하다.
Docker out of Docker(dood)
Docker out of Docker는 호스트 머신에서 동작하고 있는 Docker의 Docker socket과 내부에서 실행되는 Docker socket을 공유하는 방법이다. 간단하게 볼륨을 마운트하여 두 Docker socket을 공유한다.
> docker run -v /var/run/docker.sock:/var/run/docker.sock ...
이 방식을 그나마 Dind보다는 권장하고 있는 방법이긴하다. 하지만 이 방식도 단점은 존재한다. 내부 도커에서 외부 호스트 도커에서 실행되고 있는 도커 컨테이너를 조회할 수 있고 조작할 수 있기 때문에 보안상 아주 좋다고 이야기할 수는 없다.
DooD proxy 설정
dood로 도커를 띄운 경우, 호스트 머신에 동작하고 있는 도커에 proxy 설정이 되어있어야 내부 도커에도 동일한 proxy 설정을 가져간다.
방법1. /etc/sysconfig/docker에 프록시 설정
> sudo vi /etc/sysconfig/docker
HTTP_PROXY="http://proxy-domain:port"
HTTPS_PROXY="http://proxy-domain:port"
#docker restart
> service docker restart
방법2. 환경변수 설정
> mkdir /etc/systemd/system/docker.service.d
> cd /etc/systemd/system/docker.service.d
> vi http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://proxy-domain:port"
Environment="HTTPS_PROXY=http://proxy-domain:port"
Environment="NO_PROXY=hostname.example.com, 172.10.10.10"
> systemctl daemon-reload
> systemctl restart docker
> systemctl show docker --property Environment
Environment=GOTRACEBACK=crash HTTP_PROXY=http://proxy-domain:port HTTPS_PROXY=http://proxy-domain:port NO_PROXY= hostname.example.com,172.10.10.10
여기까지 dood로 도커 엔진을 띄웠을 때, proxy 설정하는 방법이다.
참고
How to configure docker to use proxy – The Geek Diary
www.thegeekdiary.com
'인프라 > Docker&Kubernetes' 카테고리의 다른 글
| Docker - 도커 이미지 만들기 ! (Dockerfile) (0) | 2020.07.18 |
|---|---|
| Docker - 도커를 이용해 Single node Kafka 띄우기 (0) | 2020.06.04 |
| Docker - Docker 다른 레포지토리에 push하기 (0) | 2020.04.20 |
| Docker - Docker image 빌드시 Dockerfile이 아닌 커스텀한 dockerfile명을 이용할때 (0) | 2020.04.09 |
| Kubernetes - Kubernetes 로깅 운영(logging), Fluentd (1) | 2020.02.24 |
필자는 그동안 프록시서버와 게이트웨이를 혼동해서 용어를 많이 사용했었던 것 같다. 사실 글을 쓰는 지금까지도 이 두개의 차이점을 100% 명확히 구분짓기 힘들지만, 범용적으로 사용되는 프록시서버와 게이트웨이를 뜻을 알아본다.
Proxy Server(프록시 서버)
위키에는 프록시 서버에 대한 설명이 아래와 같이 나와있다.
프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부른다.
프록시 서버 중 일부는 프록시 서버에 요청된 내용들을 캐시를 이용하여 저장해 둔다. 이렇게 캐시를 해 두고 난 후에, 캐시 안에 있는 정보를 요구하는 요청에 대해서는 원격 서버에 접속하여 데이터를 가져올 필요가 없게 됨으로써 전송 시간을 절약할 수 있게 됨과 동시에 불필요하게 외부와의 연결을 하지 않아도 된다는 장점을 갖게 된다. 또한 외부와의 트래픽을 줄이게 됨으로써 네트워크 병목 현상을 방지하는 효과도 얻을 수 있게 된다.
HTTP Protocol 관점에서 조금 더 설명을 더하자면, 프록시 서버는 클라이언트와 서버 사이에 위치하여, 클라이언트의 모든 HTTP 요청을 받아 서버에 전달한다.(대개 요청을 수정한 후에) 이 애플리케이션(프록시서버)은 사용자를 위한 프록시로 동작하며 사용자를 대신해서 서버에 접근한다. 프록시는 주로 보안을 위해 사용된다. 즉, 모든 웹 트래픽 흐름 속에서 신뢰할 만한 중개자 역할을 한다. 또한 프록시는 요청과 응답을 필터링한다. 예를 들어 회사 내부망에서 외부로 요청(메이븐, 그래들 라이브러리 다운로드 등)을 신뢰할만한 요청인지 확인해서 회사 내부정책에서 인정한 인가한 서버만 접속가능하도록 하는 등의 기능이다.
밑은 용도에 따른 Proxy server 종류이다.
- Caching Proxy Server : 이전 클라이언트의 요청 내용과 응답 컨텐츠를 저장해 두었다가 동일한 요청이 들어오면 저장된 컨텐츠를 전송한다. 이 방법을 이용하면 높은 트래픽에 대한 대응이 가능하다. 비용 절감 효과도 있을 수 있기 때문에 Caching Proxy를 자주 사용한다.
- Web Proxy : 웹 트래픽에 초점이 맞춰진 Proxy 서버이다. 가장 일반적인 형태를 Web Cache이다. 어떤 프록시 서버는 이기종간의 컨텐츠를 변환하는 일을 하기도 한다.
- Forward Proxy : 일반적으로 사용하는 프록시 방식이다. 프록시 서버는 클라이언트와 애플리케이션 서버사이에 위치하여 클라이언트가 타겟인 서버에 애플리케이션 서비스를 요청할 때, 프록시 서버로 요청을 보내게 된다. 프록시서버는 그 사이에서 중계자 역할을 하게된다.(애플리케이션 서버에게 클라이언트가 누구인지 감춰진다.)
- Reverse Proxy : 기본적인 구성은 Forward Proxy와 동일하지만, 클라이언트는 Proxy Server 뒤에 있는 타겟서버의 URL이 아닌 Proxy Server의 URL로 요쳥한다. 이를 통해 애플리케이션 서버는 외부로부터 감춰지는 효과를 보게된다.(클라이언트에게 애플리케이션 서버가 무엇인지 감춰진다.)
우리가 많이 사용하는 Nginx 같은 녀석도 프록시서버라고 볼수도 있겠다. Nginx는 위에서 설명한 대부분의 기능을 모두다 제공한다.(캐시, 포워드 프록시, 리버스 프록시)
Gateway(게이트웨이)
위키에는 게이트웨이 서버를 아래와 같이 설명한다.
게이트웨이는 컴퓨터 네트워크에서 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 가능하게 하는 컴퓨터나 소프트웨어를 두루 일컫는 용어, 즉 다른 네트워크로 들어가는 입구 역할을 하는 네트워크 포인트이다. 넓은 의미로는 종류가 다른 네트워크 간의 통로의 역할을 하는 장치이다. 또한 게이트웨이를 지날 때마다 트래픽(traffic)도 증가하기 때문에 속도가 느려질 수 있다. 쉽게 예를 들자면 해외여행을 들 수 있는데 해외로 나가기 위해서 꼭 통과해야하는 공항이 게이트웨이와 같은 개념이다.
즉, 게이트웨이는 서로 다른 네트워크 상의 통신 프로토콜(protocol,통신규약)을 적절히 변환해주는 역할을 한다.
게이트웨이는 프록시 서버와 비슷하게 클라이언트(혹은 서버)와 서버끼리 통신 사이에 중개자로 동작하는 서비스이다. 하지만 용도가 조금 다르다. 게이트웨이는 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용한다. 마치 게이트웨이는 언제나 스스로가 리소스를 갖고 있는 진짜 서버인 것처럼 요청을 다룬다. 클라이언트는 자신이 게이트웨이와 통신하고 있음을 알아채지 못할 것이다.
두 컴퓨터가 네트워크 상에서 서로 연결되려면 동일한 통신 프로토콜을 사용해야 하는데, 만약 요청은 HTTP 요청이고 백엔드에서 데이터를 가져오려면 FTP 통신이 필요하다면 중간에 게이트웨이가 두 프로토콜을 호환가능하도록 HTTP->FTP, FTP->HTTP를 대신 해주는 대행자가 되는 것이다.
Gateway(게이트웨이)
각각의 의미가 무엇이며 용도에 대해 알아보니 둘의 차이점을 조금이나마 알수 있었다. 둘다 중개자 역할임은 동일하지만 각각의 용도가 다르다는 것을 차이점으로 볼 수 있을 것 같다.
프록시 서버는 컨텐트 캐시, 보안, 필터링 등의 역할을 하는 중개자라면 게이트웨이는 서로 다른 네트워크 통신에서 서로 다른 프로토콜을 호환가능하게 하는 특별한 서버라고 볼 수 있을 것 같다.
여기까지 간단하게 프록시서버와 게이트웨이 서버가 무엇인지 둘의 차이점을 다루어보았다.
'인프라 > 네트워크(기초)' 카테고리의 다른 글
| [HTTP, HTTPS] x-forwarded-for(XFF) header (0) | 2023.04.07 |
|---|---|
| 네트워크(DNS) - A record와 CNAME의 차이점!(DNS Record Type) (0) | 2020.04.22 |
| 네트워크 - GSLB(Global Server Load Balancing)란? (2) | 2020.04.07 |
| OS - ssh 비밀번호 없이 접속하기 (0) | 2019.08.04 |
| 네트워크 - HTTP/HTTPS 차이점, HTTPS란? (0) | 2019.08.01 |
Spring Cloud - Zuul API gateway & Proxy !(Netflix Zuul)
Netflix Zuul 이란 무엇인가?
마이크로서비스 아키텍쳐(MSA)에서 Netflix Zuul은 간단히 API gateway 또는 API Service,Edge Service로 정의된다.
그래서 하는 일이 무엇이냐? 마이크로서비스 아키텍쳐에서 여러 클라이언트 요청을 적절한 서비스로 프록시하거나 라우팅하기 위한 서비스이다.
위의 이미지에서 보이듯, 모든 마이크로서비스의 종단점은 숨기고 모든 요청을 최앞단에서 Zuul이 받아
적절한 서비스로 분기를 시키게된다. 모든 마이크로서비스의 종단점을 숨겨야하는 이유가 무엇인가?
1) 클라이언트는 일부 마이크로서비스만 필요로한다.
2) 클라이언트별로 적용돼야 할 정책이 있다면 그 정책을 여러 곳에서 분산해 두는 것보단 한곳에 두고 적용하는 것이
더욱안전하다.(크로스오리진 접근정책이 바로 이런 방식의 대표적인 예임) 또한 서비스 단에서 사용자별 분기처리 로직은
구현하기 까다롭다.
3)대역폭이 제한돼 있는 환경에서 데이터 집계가 필요하다면 다수의 클라이언트의 요청이 집중되지 않게 중간에 게이트웨이를
두는것이 좋다.
Netflix Zuul 설계목적?
만약 이전 포스팅에서 Eureka에 대해 읽어 보았다면, 위의 그림만 보아도 Zuul이 어떤식으로
동작하는지 이해가 될것이다.
▶︎▶︎▶︎Spring Cloud - Eureka를 이용한 마이크로서비스 동적등록&탐색&부하분산처리
그렇다면 Zuul은 어떠한 요구사항일때 쓸모가 있을까?
많은 요구사항이 있지만, 아래와 같은 요구사항일때 특히 더 쓸모가 있다.
1) 인증이나 보안을 모든 마이크로서비스 종단점에 각각 적용하는 대신 게이트웨이 한곳에 적용한다. 게이트웨이는
요청을 적절한 서비스에 전달하기 전에 보안 정책 적용, 토큰 처리 등을 수행할 수 있다. 또한 특정 블랙리스트(IP차단) 사용자를
거부할 수 있는 비즈니스 정책 적용이 가능하다.
2) 모니터링, 데이터 집계 등을 마이크로서비스 단에서 처리하는 것이아니라, Zuul에서 처리해 외부로 데이터를
내보낼때 사용할 수 있다.
3)부하 슈레딩(shredding),부하 스로틀링(throttling)이 필요한 상황에서도 유용하다.
4)세밀한 제어를 필요로 하는 부하 분산 처리에 유용하다(Zuul+Eureka+Ribbon)
예제 프로젝트의 구성은 Spring Cloud Config, Eureka, Zuul로 구성되어 있습니다.
▶︎▶︎▶︎Spring Cloud Config
▶︎▶︎▶︎Spring Cloud Eureka
예제프로젝트는 위의 이미지의 구성입니다. 하지만 편의상 Zuul은 하나의 인스턴스만 그리고 2개의 마이크로서비스 인스턴스만
띄울 예정입니다. 그리고 마이크로서비스 인스턴스들은 또한 편의상 Spring Cloud Config를 이용하지 않았습니다.
만약 모든 구성을 스프링클라우드 컨피그로 가신다면 다른 유레카나 주울과 같은 컨피그 구성으로 가시면 됩니다.
그리고 이전 포스팅에서 유레카 서버를 독립설치형이 아닌 클러스터링된 구성으로 진행 할 것입니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | #유레카 서버 - 1 spring.application.name=eureka-server1 eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/,http://localhost:8899/eureka/ #eureka.instance.hostname=localhost eureka.client.registerWithEureka=true eureka.client.fetchRegistry=true #유레카 서버 - 2 spring.application.name=eureka-server2 eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/,http://localhost:8899/eureka/ eureka.client.registerWithEureka=true eureka.client.fetchRegistry=true #주울 server.port=8060 zuul.routes.search-apigateway.serviceId=eurekaclient zuul.routes.search-apigateway.path=/api/** eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/,http://localhost:8899/eureka/ | cs |
위는 깃저장소에 있는 spring cloud config 설정파일입니다.(편의상 하나의 파일로 작성함. 실제로는 따로 파일을 나눠야함)
조금 설명할 점이 있다면, 유레카 독립모드와 클러스터 모드의 차이점입니다. 독립모드는 자신을 유레카서버에 등록하지 않고,
캐시한 서비스 목록을 패치하지 않습니다. 하지만 클러스터모드에서는 유레카서버들이 서로 통신해야하기 때문에 자신을 서비스로
등록하고, 자신들의 서버목록들을 빠르게 통신하기 위해 캐시합니다. 그리고 defaultZone에 모든 유레카서버의 경로를 ","구분으로
나열합니다.(사실 서로 크로스해서 상대방의 주소만 써도됨. 하지만 나중에 유레카 서버가 많고 서로 하나씩 크로스됬다는 구성에서
만약 하나의 유레카서버가 죽어서 유레카서버끼리의 통신이 단절될 가능성도 있음. 그래서 모든 유레카서버 목록을 나열해서
통신하도록 하는 것이 좋음.)
그리고 주울도 하나의 유레카클라이언트이며 주울 프록시이다. 그래서 defaultZone에 유레카서버들을 나열한다. 그리고 프록시 설정이
한가지 방법만 있는 것은 아닌데 이 설정파일에는 /api/**로 들어오는 요청을 모두 eurekaclient로 보내라는 설정이다.
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 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 | #서비스 - 1, application.properties server.port=8090 spring.application.name=eurekaclient eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/,http://localhost:8899/eureka/ eureka.client.healthcheck.enabled=true #서비스 - 2, application.properties server.port=8080 spring.application.name=eurekaclient eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/,http://localhost:8899/eureka/ eureka.client.healthcheck.enabled=true #서비스 1,2 호출하는 클라이언트, application.properties server.port=8070 eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/,http://localhost:8899/eureka/ spring.application.name=eureka-call-client #config server, bootstrap.properties server.port=8888 spring.cloud.config.server.git.uri=https://github.com/yeoseong/spring-cloud-configserver.git management.security.enabled=false management.endpoint.env.enabled=true #eureka server - 1, bootstrap.properties spring.application.name=eureka spring.profiles.active=server1 server.port=8889 spring.cloud.config.uri=http://localhost:8888 management.security.enabled=false #eureka server - 2, bootstrap.properties spring.application.name=eureka spring.profiles.active=server2 server.port=8899 spring.cloud.config.uri=http://localhost:8888 management.security.enabled=false #zuul , bootstrap.properties spring.application.name=zuulapi spring.cloud.config.uri=http://localhost:8888 spring.profiles.active=dev management.security.enabled=false zuul.routes.eurekaclient=/api3/** 애플리케이션들의 application.properties,bootstrap.properties 입니다.(스프링클라우드컨피그 사용여부에 따라 다름) | cs |
나머지 설정들은 이전 포스팅에서 보고 왔다면 모두 이해할수 있다. 마지막 하나만 설명하자면, zuul의 설정이다. 이미 깃에 있는 설정파일에서 하나의
프록시 룰을 정해줬다. 하지만 그 방법말고도 다른방법이 있다.
zuul.routes.serviceId(eureka)=/path/**로도 라우팅 규칙을 정해줄 수 있다.
이제는 소스 설명이다. 유레카 및 컨피그, 마이크로서비스 클라이언트 소스는 이전과 동일하기 때문에 따로 작성하지 않는다.
▶︎▶︎▶︎Spring Cloud Config
▶︎▶︎▶︎Spring Cloud Eureka
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 | @EnableZuulProxy @EnableDiscoveryClient @SpringBootApplication public class ZuulApiApplication { public static void main(String[] args) { SpringApplication.run(ZuulApiApplication.class, args); } @Bean @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); } @Bean public ZuulFilter zuulFilter() { return new ZuulCustomFilter(); } @RestController class ZuulController{ @Autowired RestTemplate restTemplate; @GetMapping("/api2") public String zuulProxy() { System.out.println("ZuulController.zuulProxy() :::: /api2"); return restTemplate.getForObject("http://eurekaclient/eureka/client", String.class); } } } | cs |
위의 소스를 설명하면, @EnableZuulProxy로 이 애플리케이션이 주울 프록시임을 명시한다. 그리고 주울도 하나의 유레카 클라이언트임으로
@EnableDiscoveryClient로 명시해준다. 그리고 주울의 특징중 하나는 스프링 기반으로 만들어진 API임으로 개발자가 자신이 커스터마이징해서
사용할 수 있다는 점이다. @RestController로 직접 주울의 엔드포인트를 정의해서 원하는 서비스로 보낼수 있다. 더 세밀한 무엇인가가
필요하다면 이렇게 컨트롤러를 만들어서 커스터마이징해도 좋을 듯싶다. 그리고 주울도 위에서 말했듯이 하나의 유레카 클라이언트고
내부적으로 리본을 사용해 로드벨런싱 한다고 했으니, 컨트롤러에서 라우팅할때 @LoadBalanced된 RestTemplate을 이용해야
로드밸런싱이 된다.(지금까지 총 3가지 라우팅 룰을 다뤘다.)
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 36 37 38 39 40 41 42 43 44 | public class ZuulCustomFilter extends ZuulFilter{ private static Logger logger = LoggerFactory.getLogger(ZuulCustomFilter.class); /** * Criteria - 필터 실행 여부를 결정 */ @Override public boolean shouldFilter() { // TODO Auto-generated method stub return true; } /** * Action - Criteria 만족 시에 실행할 비즈니스 로직 */ @Override public Object run() throws ZuulException { // TODO Auto-generated method stub logger.info("ZuulCustomFilter :::: {}","pre filter"); return null; } /** * Type - pre,route,post */ @Override public String filterType() { // TODO Auto-generated method stub return "pre"; } /** * Order - 필터 실행 순서를 결정, 숫자가 낮을 수록 우선순위가 높아짐. */ @Override public int filterOrder() { // TODO Auto-generated method stub return 0; } } | cs |
Pre Filter
주로 backend에 보내줄 정보를 RequestContext에 담는 역할
Payco의 AccessToken으로 email을 넘겨주는 경우
public class QueryParamPreFilter extends ZuulFilter { |
email은 소중한 개인 정보입니다. 다루실 때 주의하시기 바랍니다.
Route Filter
pre filter 이후에 실행되며, 다른 서비스로 보낼 요청을 작성한다
이 필터는 주로 request, response를 client가 요구하는 모델로 변환하는 작업을 수행한다
아래의 예제는 Servlet Request를 OkHttp3 Request로 변환하고, 요청을 실행하고,
OkHttp3 Response를 Servlet Response로 변환하는 작업을 수행한다
public class OkHttpRoutingFilter extends ZuulFilter { |
Post Filter
Response를 생성하는 작업을 처리한다
아래 예제는 X-Sample 헤더에 임의의 UUID를 넣는 소스이다
public class AddResponseHeaderFilter extends ZuulFilter { |
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 36 37 38 39 40 41 42 43 44 45 46 47 48 49 | @EnableDiscoveryClient @SpringBootApplication public class Eurekaclient3Application { public static void main(String[] args) { SpringApplication.run(Eurekaclient3Application.class, args); } @Bean @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); } @RestController class EurekaClientController{ @Autowired RestTemplate restTemplate; @GetMapping("/eureka/client") public String eurekaClient() { // String result = restTemplate.getForObject("http://eurekaclient/eureka/client", String.class); System.out.println("EurekaClientController :::: /eureka/client"); String result = restTemplate.getForObject("http://zuulapi/api/eureka/client", String.class); return result; } @GetMapping("/eureka/client2") public String eurekaClient2() { System.out.println("EurekaClientController :::: /eureka/client2"); String result = restTemplate.getForObject("http://zuulapi/api2", String.class); return result; } @GetMapping("/eureka/client3") public String eurekaClient3() { System.out.println("EurekaClientController :::: /eureka/client3"); String result = restTemplate.getForObject("http://zuulapi/api3/eureka/client", String.class); return result; } } } | cs |
이제 마이크로서비스를 호출하는 클라이언트 소스입니다..(주울호출) 모두 /apin/~으로 주울에게 요청이 갑니다.
그리고 주울에서는 각각의 마이크로서비스로 /apin/을 제외한 나머지 Uri를 해당 마이크로서비스들에게 요청보냅니다.
(물론 설정으로 앞의 프리픽스까지 붙여서 요청보내게 할 수 있음)
postman 이나 curl로 호출이 잘되는지 확인 해보시면 될듯합니다..
<유레카 및 주울 설정 메모>
구글링을 막하다가 유레카 및 주울 설정들을 막 메모한 것들입니다.
정리하기 힘들어서.... 그냥 메모 그대로 올립니다....
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 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 | ================================================================================Zuul========================================================================================================= #Netflix Zuul 1.x은 외부 API 호출시 클라이언트 사이드 로드 밸런서로 Netflix Ribbon를 사용한다. #또한, Netflix Ribbon는 외부 API 서비스의 물리적인 노드 정보를 발견하는 역할로 Netflix Eureka에 의존한다. #만약 Netflix Eureka(별도 독립 서비스 구축 필요)를 사용하지 않는다면 ribbon.eureka.enabled 옵션을 false로 설정하면 된다. #zuul.sensitive-headers에 특정 헤더 이름을 설정하면 라우팅 전에 해당 헤더를 제거할 수 있다. 보안 문제로 라우팅되지 말아야할 헤더가 있을 경우 활용할 수 있다. #zuul.host.connect-timeout-millis으로 API 요청 후 연결까지의 타임아웃을 설정할 수 있다. 설정된 타임아웃이 초과했을 경우 ZuulException(내부적으로는 java.net.ConnectException) 예외가 발생한다. #zuul.host.socket-timeout-millis으로 API 요청 후 응답까지의 타임아웃을 설정할 수 있다. 설정된 타임아웃이 초과했을 경우 ZuulException(내부적으로는 java.net.SocketTimeoutException) 예외가 발생한다. #zuul.routes.url을 직접적으로 명시하면 Netflix Ribbon을 사용하지 않는다. #zuul.routes.stripPrefix를 false로 설정하면 라우팅시 url에 path가 그대로 보존되어 결합된다. 인지적으로 가장 자연스러운 설정이다. true(기본값)로 설정시에는 url에서 path 부분은 제거되고 나머지 부분이 추가되어 라우팅된다. #구성 등록 정보 zuul.max.host.connections는 #두 개의 새 등록 정보 zuul.host.maxTotalConnections 및 zuul.host.maxPerRouteConnections로 대체되었습니다. #기본값은 각각 200 및 20입니다. #모든 경로의 기본 Hystrix 격리 패턴 (ExecutionIsolationStrategy)은 SEMAPHORE입니다. #zuul.ribbonIsolationStrategy는 격리 패턴이 선호되는 경우 THREAD로 변경할 수 있습니다. #THREAD일때, WAS의 스레드로 API요청을 받는 것이 아니라, Hystrix의 별도의 스레드를 이용하여 #WAS의 스레드와 격리한다. #프록시는 리본을 사용하여 검색을 통해 전달할 인스턴스를 찾습니다. #모든 요청은 hystrix 명령으로 실행되므로 실패는 Hystrix 메트릭에 나타납니다. #회선이 열리면 프록시는 서비스에 접속하려고 시도하지 않습니다. #서비스가 자동으로 추가되는 것을 건너 뛰려면 zuul.ignored-services를 서비스 ID 패턴 목록으로 설정하십시오. #zuul.ignored-services='*' #zuul.routes.eurekaclient=/api3/** #서비스아이디가 아니라 직접 URL을 등록할 수 있지만, 이것은 클라우드의 로드벨런싱 효과를 얻을 수 없다. #zuul.strip-prefix=true 으로 설정된 prefix를 붙여서 요청을 보낸다. #zuul: # routes: # users: # path: /myusers/** # serviceId: users # #ribbon: # eureka: # enabled: false # #users: # ribbon: # listOfServers: example.com,google.com #위와 같이 직접 리본으로 라우팅할 리스트를 작성할 수있다. 이것을 사용하려면 eureka 사용을 비활성화해야한다. #만약 X-Forwarded-Host 헤더같은 것이 요청에 들어갔을 경우, #헤더값을 추가못하게 설정할수 있다. #zuul.add-proxy-headers=false #기본 경로 (/)를 설정하면 @EnableZuulProxy가있는 응용 프로그램이 독립 실행 형 서버로 작동 할 수 있습니다. #예를 들어, zuul.route.home : /는 모든 트래픽 ( "/ **")을 "home"서비스로 라우팅합니다. #zuul: # routes: # users: # path: /myusers/** # sensitiveHeaders: Cookie,Set-Cookie,Authorization # url: https://downstream # 위처럼 bypass시킬 헤더값 목록을 지정 # zuul: # routes: # users: # path: /myusers/** # sensitiveHeaders: # url: https://downstream # 모든 헤더값을 bypass #zuul.ignored-headers=Cookie,Set-Cookie #Cookie,Set-Cookie 헤더는 버린다. #spring security를 쓰고 시큐리티헤더를 통과시키려면 #zuul.ignore-security-headers=false #zuul: # forceOriginalQueryStringEncoding: true # 원래 인코딩값으로 강제로 바꾼다. #Zuul이 서비스 검색을 사용하는 경우 ribbon.ReadTimeout 및 ribbon.SocketTimeout 리본 등록 정보로 이러한 시간 초과를 구성해야합니다. #URL을 지정하여 Zuul 경로를 구성한 경우 zuul.host.connect-timeout-millis 및 zuul.host.socket-timeout-millis를 사용해야합니다. #기본적으로 Zuul은 모든 Cross Origin Request (CORS)를 서비스로 라우팅합니다. #대신 Zuul이 이러한 요청을 처리하기 원하는 경우 사용자 지정 WebMvcConfigurer bean을 제공하여 수행 할 수 있습니다. #@Bean #public WebMvcConfigurer corsConfigurer() { # return new WebMvcConfigurer() { # public void addCorsMappings(CorsRegistry registry) { # registry.addMapping("/path-1/**") # .allowedOrigins("http://allowed-origin.com") # .allowedMethods("GET", "POST"); # } # }; #} ================================================================================Zuul========================================================================================================= ================================================================================Eureka========================================================================================================= #<Eureka 등장 용어 정리> # <Eureka 행동 관련> # Service Registration: 서비스가 자기 자신의 정보를 Eureka에 등록하는 행동 # Service Registry: 서비스가 스스로 등록한 정보들의 목록, 가용한 서비스들의 위치 정보로 갱신됨 # Service Discovery: 서비스 클라이언트가 요청을 보내고자 하는 대상의 정보를 Service Registry를 통해 발견하는 과정 # <Eureka 구성 요소 관련> # Eureka Client: 서비스들의 위치 정보를 알아내기 위해 Eureka에 질의하는 서비스를 가리킴 (like Service consumer) # Eureka Service: Eureka Client에 의해 발견의 대상이 되도록 Eureka에 등록을 요청한 서비스를 가리킴 (like Service provider) # Eureka Server: Eureka Service가 자기 자신을 등록(Service Registration)하는 서버이자 Eureka Client가 가용한 서비스 목록(Service Registry)을 요청하는 서버 # Eureka Instance: Eureka에 등록되어 목록에서 조회 가능한 Eureka Service를 의미 # #<Eureka Client 동작과 Server간 Communication> # <Self-Identification & Registration> # Eureka Client는 어떻게 Eureka Server로부터 서비스 목록을 받아올까? # REST endpoint /eureka/apps를 통해 등록된 인스턴스 정보를 확인할 수 있다. # # Traffic을 받을 준비가 되면 Eureka Instance의 status가 STARTING → UP으로 바뀐다 # status:STARTING은 Eureka Instance가 초기화 작업을 진행 중인 상태로 Traffic을 받을 준비가 안되었다는 의미이다 # eureka.instance.instance-enabled-onit 설정값을 통해 Startup 후 Traffic 받을 준비가 되었을 때 status:UP이 되도록 할 수 있다 (default: false) # # 등록 이후 heartbeat은 eureka.instance.lease-renewal-interval-in-seconds에 설정된 주기마다 스케쥴러가 실행된다 (default: 30) # # Eureka Server는 interval에 따라 Eureka Service의 status(UP/DOWN/..)를 판단하고 # 가장 최근 heartbeat 시점 + interval 이후에 heartbeat을 받지 못하면 # eureka.instance.lease-expiration-duration-in-seconds에 설정된 시간만큼 기다렸다가 # 해당 Eureka Instance를 Registry에서 제거한다 (default: 90, 단, Eureka Instance가 정상적으로 종료된 경우 Registry에서 바로 제거된다) # 위의 값은 lease-renewal-interval-in-seconds보다는 커야한다. # # 등록 이후 Instance 정보가 변경 되었을 때 Registry 정보를 갱신하기 위한 REST를 # eureka.client.instance-info-replication-interval-seconds에 설정된 주기마다 호출한다 (default: 30) # eureka.client.initial-instance-info-replication-interval-seconds (default: 40) # # Eureka Server 추가, 변경, 삭제가 일어날 때 Eureka Client가 얼마나 자주 service urls를 갱신할 것인지 # eureka.client.eureka-service-url-poll-interval-seconds 값으로 조정할 수 있다 # #default: 0, 단 DNS를 통해 service urls를 가져오는 경우) # # <Service Discovery> # -Instance Startup 시점 # Eureka로부터 Registry 정보를 fetch한다 # Instance Startup 이후 Fetch Registry # 등록 이후 Eureka Client는 eureka.client.registry-fetch-interval-seconds에 설정된 주기마다 Local Cache Registry 정보를 갱신한다 (default: 30) #<Eureka Server 동작과 Peer Server간 Communication> # <Self-Identification & Registration> # -Instance Startup 시점 # Peer nodes를 찾아서 Registry 정보 등 Sync 맞추는 작업을 한다 # eureka.server.registry-sync-retrires 값을 통해 Peer nodes로부터 Registry 정보를 얻기 위한 재시도 횟수를 조정할 수 있다 (default: 5) # Eureka Server가 시작되고 Peer nodes로부터 Instance들을 가져올 수 없을 때 얼마나 # 기다릴 것인지 eureka.server.wait-time-in-ms-when-sync-empty 시간(milliseconds)을 조정할 수 있다 (default: 3000) # # 나머지 과정은 Server도 Eureka Client이기 때문에 'Eureka Client > Self-Identification & Registration > Instance Startup 시점'에 설명한 바와 같이 동일하게 동작한다 # Standalone으로 구성하는 경우 Peer nodes가 없기 때문에 eureka.client.register-with-eureka: false 설정을 통해 등록 과정을 생략할 수 있다 #<Eureka Server Response Cache 설정> # Eureka server에서 eureka client에게 자신의 registry 정보를 제공 시 사용하는 cache. # client에게 더 빠른 registry 정보 제공을 위해 실제 registry 값이 아닌 cache의 값을 제공 함. # eureka.server.response-cache-update-interval-ms: 3000 # 기본 30초 #<Eureka Client Cache 설정> # Eureka client에 존재하는 cache로 eureka server에 서비스 정보 요청 시 이 cache의 값을 이용 한다. # eureka.client.fetchRegistry 값이 false이면 client cache는 적용되지 않는다. # eureka.client.registryFetchIntervalSeconds: 3 # 기본 30초 #어떤 경우에는 유레카가 호스트 이름보다는 서비스의 IP 주소를 광고하는 것이 바람직합니다. #eureka.instance.preferIpAddress를 true로 설정하고 응용 프로그램이 eureka에 등록하면 호스트 이름 대신 IP 주소를 사용합니다. #spring-boot-starter-security를 통해 서버의 classpath에 Spring Security를 추가하기 만하면 유레카 서버를 보호 할 수 있습니다. #기본적으로 Spring Security가 classpath에있을 때, 모든 요청에 대해 유효한 CSRF 토큰을 앱에 보내야합니다. #유레카 고객은 일반적으로 유효한 CSRF (cross site request forgery) 토큰을 보유하지 않으므로 / eureka / ** 엔드 포인트에 대해이 요구 사항을 비활성화해야합니다. #@EnableWebSecurity #class WebSecurityConfig extends WebSecurityConfigurerAdapter { # # @Override # protected void configure(HttpSecurity http) throws Exception { # http.csrf().ignoringAntMatchers("/eureka/**"); # super.configure(http); # } #} #Eureka Discovery Client를 사용하지 않으려면 eureka.client.enabled를 false로 설정할 수 있습니다. #Eureka Discovery Client는 spring.cloud.discovery.enabled가 false로 설정된 경우에도 비활성화됩니다. #eureka.client.serviceUrl.defaultZone URL 중 하나에 자격 증명이 포함되어 있으면 HTTP 기본 인증이 자동으로 유레카 클라이언트에 추가됩니다 #(컬 스타일, http : // user : password @ localhost : 8761 / eureka). #보다 복잡한 요구를 위해, DiscoveryClientOptionalArgs 타입의 @Bean을 생성하고 ClientFilter 인스턴스를 클라이언트에 삽입 할 수 있습니다. #이 인스턴스는 모두 클라이언트에서 서버로의 호출에 적용됩니다. #Eureka 인스턴스의 상태 페이지 및 상태 표시기는 각각 Spring Boot Actuator 응용 프로그램의 유용한 끝점의 기본 위치 인 / info 및 / health로 기본 설정됩니다. #eureka: # instance: # statusPageUrlPath: ${server.servletPath}/info # healthCheckUrlPath: ${server.servletPath}/health #HTTPS를 통해 앱과 연락하려는 경우 EurekaInstanceConfig에서 다음과 같은 두 가지 플래그를 설정할 수 있습니다. #eureka.instance.[nonSecurePortEnabled]=[false] #eureka.instance.[securePortEnabled]=[true] #eureka.hostname == eureka.instance.hostname #기본적으로 Eureka는 클라이언트 하트 비트를 사용하여 클라이언트가 작동 중인지 확인합니다. #별도로 지정하지 않는 한, Discovery Client는 Spring Boot Actuator에 따라 응용 프로그램의 현재 상태 검사 상태를 전파하지 않습니다. #따라서 성공적으로 등록한 후 Eureka는 응용 프로그램이 항상 UP 상태임을 발표합니다. #이 동작은 Eureka 상태 점검을 활성화하여 응용 프로그램 상태를 Eureka에 전파함으로써 변경 될 수 있습니다. #결과적으로 다른 모든 응용 프로그램은 'UP'이외의 상태로 응용 프로그램에 트래픽을 보내지 않습니다. #반드시 actuator 의존이 필요 #상태 검사를 더 많이 제어해야하는 경우에는 com.netflix.appinfo.HealthCheckHandler를 직접 구현하는 것이 좋습니다. #라우터를 사용하는 경우 (권장 또는 필수, 플랫폼 설정 방식에 따라 다름) 라우터를 사용하도록 명시 적으로 호스트 이름과 포트 번호 (보안 또는 비보안)를 설정해야합니다. #eureka: # client: # healthcheck: # enabled: true #만약 bootstrap.properties에 등록하면 UNKNOWN등의 비정상적인 상태값이 나올수 있다.(반드시 application.xxx에 설정하자) #Cloud Foundry에는 글로벌 라우터가있어 동일한 앱의 모든 인스턴스가 동일한 호스트 이름을 갖는다면, #이것은 반드시 유레카 사용의 문제가 있지는 않다. #그러나 라우터를 사용하는 경우 (권장 또는 필수, 플랫폼 설정 방식에 따라 다름) 라우터를 사용하도록 명시 적으로 호스트 이름과 포트 번호 (보안 또는 비보안)를 설정해야합니다. #eureka: # instance: # hostname: ${vcap.application.uris[0]} # nonSecurePort: 80 ######################################################################################################################################### #Register # eureka.instance, eureka.client 설정값을 바탕으로 Eureka에 등록하기 위한 Eureka Instance 정보를 만듦 # Client가 eureka 서버로 첫 hearbeat 전송 시 Eureka Instance 정보를 등록 # 등록된 instance 정보는 eureka dashboard나 http://eurekaserver/eureka/apps를 통해 확인할 수 있음 #Renew # Client는 eureka에 등록 이후 설정된 주기마다 heatbeat를 전송하여 자신의 존재를 알림 # eureka.instance.lease-renewal-interval-in-seconds (default: 30) # 설정된 시간동안 heartbeat를 받지 못하면 해당 Eureka Instance를 Registry에서 제거 # eureka.instance.lease-expiration-duration-in-seconds (default: 90) # renew 관련 interval은 변경하지 않는것을 권장 함(서버 내부적으로 client를 관리하는 로직 때문) #Fetch Registry # Client는 Server로부터 Registry(서버에 등록된 인스턴스 목록) 정보를 가져와서 로컬에 캐시 # 캐시 된 정보는 설정된 주기마다 업데이트 됨 # eureka.client.registryFetchIntervalSeconds (default: 30) #Cancel # Client가 shutdown될 때 cancel 요청을 eureka 서버로 보내서 registry에서 제거 하게 됨 #Time Lag # Eureka server와 client의 registry 관련 캐시 사용으로 인해 client가 호출 하려는 다른 instance 정보가 최신으로 갱신되는데 약간의 시간 차가 있음 #Peering # 여러대의 eureka server를 사용하여 서로 peering 구성이 가능하다. # Eureka server는 설정에 정의된 peer nodes를 찾아서 Registry 정보 등 Sync 맞추는 작업을 한다 . # # 관련 설정 # Standalone으로 구성하려면 아래 처럼 설정 # eureka.client.register-with-eureka: false # Peer nodes 로부터 registry를 갱신할 수 없을 때 재시도 횟수 # eureka.server.registry-sync-retrires (default: 5) # Peer nodes 로부터 registry를 갱신할 수 없을때 재시도를 기다리는 시간 # eureka.server.wait-time-in-ms-when-sync-empty (default: 3000) milliseconds #Self-Preservation Mode(자가보존모드) # Eureka 서버는 등록된 instance로부터 heartbeat를 주기적으로 받는다. # 하지만 네트워크 단절 등의 상황으로 hearbeat를 받을 수 없는 경우 보통 registry에서 해당 instance를 제거 한다. # Eureka로의 네트워크는 단절되었지만, 해당 서비스 API를 호출하는데 문제가 없는 경우가 있을수 있어서, # self-preservation 을 사용하여 registry에서 문제된 instance를 정해진 기간 동안 제거하지 않을 수 있다. # EvictionTask가 매분 마다 Expected heartbeats 수와 Actual heartbeats 수를 비교하여 Self-Preservation 모드 여부를 결정한다. # eureka.server.eviction-interval-timer-in-ms (default: 60 * 1000) #Expected heartbeats updating scheduler # 기본 매 15분(renewal-threshold-update-interval-ms) 마다 수행되며 preservation mode로 가기 위한 임계값을 계산한다. # 예를 들어 인스턴스 개수가 N개이고, renewal-percent-threshold값이 0.85이면 계산식은 아래와 같다. # 최소 1분이내 받아야 할 heartbeat 총 수 = 2 N 0.85 # 위 값은 아래 설정으로 변경 가능 # eureka.instance.lease-renewal-interval-in-seconds (default: 30) # eureka.server.renewal-percent-threshold (default: 0.85) # scheduler 수행 주기 설정 eureka.server.renewal-threshold-update-interval-ms (default: 15 60 1000) #Actual heartbeats calculation scheduler # 기본 매 1분 마다 수행되며 실제 받은 heartbeats 횟수를 계산하다. #eureka # instance: # preferIpAddress: true # 서비스간 통신 시 hostname 보다 ip 를 우선 사용 함 #server: # port: 8761 # #eureak: # server: # enable-self-preservation: true # client: # registerWithEureka: true # fetchRegistry: true # #--- # #spring: # profiles: eureka1 #eureka: # instance: # hostname: eureka1 # client: # serviceUrl: # defaultZone: http://eureka2:8761/eureka/ # #--- #spring: # profiles: eureka2 #eureka: # instance: # hostname: eureka2 # client: # serviceUrl: # defaultZone: http://eureka1:8761/eureka/ #동일서버에서 실행하는 경우 instance hostname은 unique하게 설정되어야 한다. #registerWithEureka true로 설정 # true설정시 서버 자신도 유레카 클라이언트로 등록한다. #fetchRegistry true로 설정 # defaultZone의 유레카 서버에서 클라이언트 정보를 가져온다(registerWithEureka가 true로 설정되어야 동작함) #profile 추가하여 서로 참조하도록 serviceUrl.defaultZone 설정 #self preservation #spring: # application: # name: customer-service # #eureka: # client: # serviceUrl: # defaultZone: http://eureka1:8761/eureka/,http://eureka2:8761/eureka/ # enabled: true #eureka.client.serviceUrl.defaultZone에 clustering한 유레카 서버 모두 입력 # heart-beat는 defaultZone의 very first 항목인 eureka1에 만 전송 #여러개의 Eureka에 등록할 경우 defaultZone에 ,(comma)로 구분하여 입력한다. #유레카 (Eureka)는 CAP 정리의 관점에서 AP 시스템입니다. 그러면 레지스트리의 정보가 네트워크 파티션 동안 서버간에 일치하지 않게됩니다. 자체 보존 기능은 이러한 불일치를 최소화하기위한 노력입니다. # #자기 보존 정의 # 자체 보존은 Eureka 서버가 특정 임계 값 이상으로 하트 비트 (피어 및 클라이언트 마이크로 서비스에서)를 수신하지 않을 때 레지스트리에서 만료 인스턴스를 중지하는 기능 입니다. ================================================================================Eureka========================================================================================================= | cs |
'Web > Spring Cloud' 카테고리의 다른 글
| Spring Cloud - Eureka Client 안전한 종료 방법(Discovery Client Shutdown, Spring boot graceful shutdown) (0) | 2019.08.25 |
|---|---|
| Spring Cloud - Spring Cloud Bus (0) | 2019.02.24 |
| Spring Cloud - Eureka를 이용한 마이크로서비스 동적등록&탐색&부하분산처리 (0) | 2019.02.24 |
| Spring Cloud - Spring Cloud Config(스프링 클라우드 컨피그) (0) | 2019.02.23 |
JPA - 즉시로딩과 지연로딩(FetchType.EAGER,FetchType.LAZY) 그리고 프록시
만약 회원이라는 엔티티 객체와 팀이라는 엔티티 객체가 있고 회원:팀 = N:1 연관관계를 맺고 있다고 가정하자. 만약 회원이라는 엔티티를 데이터베이스에서 조회했을 경우 팀이라는 엔티티 객체를 같이 로딩해서 사용할 수 도 있겠지만 진짜 회원만 사용할 목적으로 엔티티객체를 조회 할 수도 있다. 그렇다면 만약 필요하지 않은 연관관계 객체의 로딩을 뒤로 미룬다면 어떻게 할까? 이것은 불필요한 데이터베이스 조회 성능을 최적화 할 수 있는 기회가 될 수 있을 것이다. 예를 들어 연관관계가 List 필드로 되어있고 연관된 객체가 수만개라면? 그리고 해당 List연관관계의 엔티티는 필요하지 않은 상황이라면? 이럴경우에는 지연로딩이라는 패치전략을 사용할 수 있다. 그리고 필요한 시점에 그 객체를 데이터베이스에서 불러올 수 있다.
지연로딩, FetchType.LAZY 그리고 프록시 객체
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 | @Entity @Table(name = "MEMBER_TB") @Getter @Setter public class MemberFetchTypeLazy { @Id private String id; private String name; @ManyToOne(fetch = FetchType.LAZY) private TeamFetchType team; } @Entity @Table(name = "TEAM_TB") @Getter @Setter public class TeamFetchType { @Id private String id; private String name; @OneToMany(mappedBy="team") private List<MemberFetchTypeLazy> members = new ArrayList<MemberFetchTypeLazy>(); } | cs |
지연로딩 전략은 위와 같이 연관관계를 명시해주는 어노테이션에 fetch = FetchType.Lazy 처럼 명시 해줄 수 있다. 위의 소스 설명은 회원엔티티를 조회할때 팀엔티티를 즉시로딩하지 않고 지연로딩할 것이라는 소스이다. 이 말은 회원엔티티를 조회할때 팀회원을 같이 데이터베이스에서 가져오지 않고, MemberFetchTypeLazy.getTeam() 으로 실제로 팀엔티티가 사용될 때 데이터베이스에서 해당 엔티티를 조회해오는 것이다.
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 36 37 38 39 40 41 42 43 44 45 46 | public class FetchTypeTest { public static void main(String[] args) { // TODO Auto-generated method stub //엔티티매니저 팩토리 생성 EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook"); //엔티티매니저 생성 EntityManager em = emf.createEntityManager(); //트랜잭션 획득 EntityTransaction tx = em.getTransaction(); try { tx.begin(); TeamFetchType team = new TeamFetchType(); team.setId("team_1"); team.setName("team_1"); em.persist(team); MemberFetchTypeLazy member = new MemberFetchTypeLazy(); member.setId("member_1"); member.setName("윤여성"); member.setTeam(team); em.persist(member); tx.commit(); }catch (Exception e1) { // TODO: handle exception tx.rollback(); }finally { em.close(); } /*emf.close();*/ //엔티티매니저를 새로 생성한 이유는 영속성컨텍스트가 비어있는 상태에서 조회하기 위함(em.clear()도 가능) EntityManager em2 = emf.createEntityManager(); MemberFetchTypeLazy findMember = em2.find(MemberFetchTypeLazy.class, "member_1"); System.out.println(findMember.getTeam().getName()); System.out.println(); } } | cs |
(디버깅화면 잘보세요 !)
첫번째 결과 사진을 보면 회원엔티티를 조회하면 team필드에는 id=null,name=null이 들어가있는 것이 보일 것이다. 즉, 데이터베이스에서 조회해오지 않는다. 그리고 Console에도 보면 회원엔티티만을 조회하고 있다.
두번째 결과 getTeam().getName() 이후 Console에는 팀을 조회하는 SQL이 생겨나있는 것을 볼 수 있다. 이말은 회원엔티티를 조회할때는 팀엔티티를 가져오지 않고 진짜 팀엔티티가 사용될 시점에 데이터베이스에서 팀 엔티티를 조회해오는 것이다.
여기서 디버깅화면을 보면 team필드에 이상한 인스턴스이름이 들어가 있는 것을 볼 수 있다.
바로 지연로딩의 핵심이되는 프록시라는 객체가 team필드가 레퍼런스하고 있는 것이다. 맞다. JPA는 지연로딩에 프록시전략을 이용한다. 프록시는 간략히 얘기하면 대행자이다. 팀회원을 조회할때 team에는 실제 팀엔티티가 들어가는 것이 아니고 프록시 객체가 들어가는 것이고, 실제 팀엔티티를 사용할때 이 프록시객체가 대행자역할을 하여 팀엔티티를 바라보고 대신 팀엔티티관련 데이터를 리턴해주는 것이다.(하지만 만약 Team 엔티티가 이미 영속성컨텍스트에 들어가있다면 지연로딩설정을 해도 즉시로딩과 동일하게 영속성 컨텍스트에서 Team엔티티를 가져온다. 그래서 위의 예제는 영속성컨텍스트를 초기화? 할 목적으로 엔티티매니저 인스턴스를 새로 생성하였다.)
프록시 객체를 실제 엔티티를 상속하고 있기 때문에 겉모양을 그대로이다. 그리고 프록시를 내부적으로 실제 엔티티에 대한 레퍼런스를 갖고 직접 실제객체의 데이터를 리턴해준다.
그리고 한가지더 얘기할 것은 위와 같이 Member.getTeam을 조회할때는 프록시 객체가 엔티티를 초기화요청을 한다. 하지만 엔티티의 필드중 컬렉션으로 되어있는 필드를 초기화하려면 Team.getMembers.get(i)처럼 직접 실제 인덱스로 데이터를 조회할 경우 엔티티초기화요청을 프록시 객체가 보내게 된다.
<엔티티 필드 중에 컬렉션은 진짜 컬렉션으로 저장될까?>
JPA는 필드중 컬렉션으로 된 타입이 있다면 컬렉션을 추적하고 관리할 목적으로 원본 컬렉션을 하이버네이트가 제공하는 내장 컬렉션으로 변경한다. 이것을 컬렉션 래퍼라고 한다. 디버깅을 해보면 컬렉션으로 된 타입의 필드가 있다면 PersistentBag라는 컬렉션래퍼로 반환되는 것을 볼 수 있다.
FetchType.EAGER,즉시로딩
즉시로딩은 어노테이션만 EAGER로 바꾸어주면 된다. 즉시로딩은 말그대로 즉시 연관된 엔티티도 다 조회를 해오는 것이다. 어려운 설정은 없다. 하지만 하나 주의해야될 것이 있다. 즉시로딩은 연관된 엔티티를 따로따로 조회하는 것이 아니라, 조인을 이용해 하나의 쿼리로 데이터를 가져오기 때문에 만약 외래키에게 널을 허용한다면? 외부조인을, 외래키가 널을 허용하지 않는다면 내부조인을 이용해서 가져온다. (선택적 비식별관계, 필수적 비식별관계)
이것이 주의해야될 상황인것이 만약 특정상황에서 필요한 데이터를 가져오지 못하는 상황이 발생 할 수 있다.(내부조인,외부조인)
- 외부조인이라면 null값이 저장된 데이터는 가져오지 않는다. 즉, 필요할 수 있는 데이터를 외래키null을 허용함으로써 가져오지 못한다.
<주의사항>
-컬렉션을 하나 이상 즉시 로딩하는 것은 권장하지 않는다.
:A 테이블을 N,M 두 테이블과 일대다 조인한다면 SQL 실행 결과가 N곱하기 M이 되면서 너무 많은 데이터를 반환할 수 있고 결과적으로 애플리케이션 성능이 저하될 수 있다.
JPA 기본 패치전략
- @ManyToOne, @OneToOne : 즉시로딩(FetchType.EAGER)
- @OneToMany,@ManyToMany : 지연로딩(FetchType.LAZY)
하지만 대게 정말 필요한 상황을 제외하고는 LAZY, 지연로딩하는 것을 권고한다고 한다.
<optional 속성>
- @ManyToOne, @OneToOne (optional = false, true)
false : 내부 조인
true : 외부조인
- @OneToMany,@ManyToMany (optional = false, true)
false : 외부 조인
true : 외부조인
여기서 특징이라면 엔티티의 컬렉션을 조회할때는 optional 속성과 무관하게 무조건 외부조인을 이용한다는 점이다.
'Web > JPA' 카테고리의 다른 글
| JPA - @Embedded,@Embeddable 임베디드타입 (0) | 2019.02.04 |
|---|---|
| JPA - 영속성 전이(Cascade)와 고아 객체(Orphan) (0) | 2019.02.04 |
| JPA - 하나의 엔티티에 다수 테이블 매핑(@SecondaryTable,@SecondaryTables) (0) | 2019.02.03 |
| JPA - @MappedSuperClass (매핑정보 상속) (0) | 2019.02.02 |
| JPA - 상속 관계 매핑, @Inheritance, @DiscriminatorColumn (0) | 2019.02.02 |