Apach & Tomcat trouble shooting (1)

미들웨어/트러블 슈팅

Apach & Tomcat trouble shooting (1)

saay-hi 2024. 10. 21. 10:20

ch01
1.apache · tomcat 유연한 아키텍처

유연한 아키텍처 : AP구성에 따라 (+ 필요한 instance에 따라 was 양을 조절하며) flexible 구성 및 설치/지원

2. 연계 구성

3tier ( client - 웹/애플리케이션 - db ): browser ↔ apache ↔ tomcat ↔ database

3.시스템 지연 발생 주요 모니터링(1) - 세부모니터링

세부 모니터링 측면에서 봐야할 요소 : 1) access.log

2) error.log
3) 네트워크 확인
4) mod_jk ** (web → was)

db, middleware, 네트워크에 따라 session 의미 상이

4. Apache · Tomcat 별 모니터링 ( 차이점 )

차후 고민해 볼 항목

서버 to 서버 : new connection추가할 때 왜 cost가장 큰 지
sw to sw간의 연계 할 때 고려해야할 대상
왜 외부 서버로 connection할 때 poolling이 가장 좋은지 → was - db connection
왜 중간에 오는 traffic관련 리소스가 많이 잡아 먹는지

개인 의견 : 외부 서버 연결 시, connection 양을 단순히 늘리는 것보다 pooling을 하는 것이 더 좋을 것 같습니다.
(connection pool : WAS가 실행되면서 DB와 미리 connection을 해놓은 객체들을 pool에 저장해 두었다가 클라이언트 요청이 오면 connection을 빌려주고, 처리가 끝나면 다시 connection을 반납받아 pool에 저장하는 방식)

connection 요청
이전 사용했던 connection 정보 존재 여부 확인
이전 사용했던 connection 목록 중 사용 가능한 connection 존재 여부 확인
전체 connection 목록 중 사용 가능한 connection 존재 여부 확인
(2,3,4 순서대로 유휴 connection이 존재하면 다음 과정을 생략하고 반환) connection 반환

pooling은 쓰고 다시 반납하여 재사용할 수 있는 개념이며
비용적인 측면에서 connection 을 추가하는 비용 > connection pool을 사용하는 비용 이기에 pooling하는 것이 좋은 것 같습니다

네트워크 측면 )
DBMS와 통신은 TCP/IP로 이루어짐. (TCP : 연결형 프로토콜 - 가상 경로를 생성하고 통신하는데, 이는 서버측이 미리 준비하고 있어야 가능)
서버 프로세스(DB)는 OS에게 포토 번호로 통신 요청이 오면 자신에게 전달해 달라하며 기다림 → "LISTEN"

(연결을 위해) 3-way handshake 과정

1. 클라이언트가 통신 상대인 서버측 os에게 가상 경로 오픈을 의뢰하며 SYN 패킷 전송
2. 서버 측 소켓은 LISTENING 상태이기에 ACK + SYN 패킷 응답
3. 클라이언트도 다시 ACK 패킷으로 응답하며 서버의 새로운 소켓이 생성되며 연결 → "ESTABLISHED"
위 과정을 매번 반복하지 않아도 됨 (반복한다면 비효율적인 일)

OS 측면)
매번 close wait 를 반복하게 될 경우 네트워크 io 자체가 늘어나게 됨
connection pool 을 이용하여 network resource io가 줄게 되어 connection pooling하는 것이 좋음

(connection pool 이용 시 ) 결론 :

handshake 비용 감소
프로세스나 스레드 생성/삭제 비용 감소

1.apache · tomcat

WEB : web server
WAS : web application server

참고) WAS 별 startup time 비교
1) tomcat 1초 (무너질 때 바로 뜨고 빠른 대응) → 현재 흐름 : 경량화 (Thread많이 안 갖고있음)
2) weblogic 8초
3) wildfly 모듈화(모듈 의존도)
→ 각 vendor 가능 방향과 흐름 이해

참고) WAS 종류
tomcat : java EE full stack 중에 jsp/servlet기술만 제공(라이브러리 충돌 x, ap에서 라이브러리 별도 관리하고 추가해줘야함) was 기능제공
weblogic : was server 제품
websphere : IBM에서 진행 IBM이 redhat인수( Jboss, web sphere보유)

참고) Nginx 특징 (WEB)
만개의 request 동시 처리 목적 , 많은 것을 어떻게 가볍게 처리할 지 중점
*분산, traiffic관리, (ap logic 띄울 수 있는, 데몬을 띄울 수 있는)경량화

1.2 Apache 기능

- 도메인 관리, 정적 파일, HTTP, 통신 기록, 인증, 정적 콘텐츠 관리 , HTTPS 지원, 콘텐츠 압축, 가상 호스팅, 대용량 파일 지원, 대역폭으로 폴링

( * 폴링 : 하나의 장치 (또는 프로그램) 가 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치 (또는 프로그램)의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처릴 하는 방식 )

1.3 Tomcat 기능

- JSP 가 서블릿을 만들고, 서블릿이 결과적으로 웹 페이지를 만듦

( * 서블릿 컨테이너 : 클라이언트의 요청을 받아 요청을 처리하고, 다시 클라이언트에게 응답해주는 역할 )

- 웹 서버에서 넘어온 동적인 페이지를 읽어 들여 프로그램 실행. 그 결과를 다시 html 재구성하여 Apache에게 response를 되돌려줌

( * Apache가 없이 Tomcat 독립적으로 사용될 수는 있지만, Apache와 같은 다른 web server와도 함께 사용될 수는 있음 )

*Apache, Tomcat 기본 구성
(기본 web, was 구성 및 기본 기능)
<Aphche> <tomcat > <DBMS>
client > L4(분산) → http → instance1 → DBMS
→ instance2
→ http → instance3
→ instance4

1.4 apache 와 WAS SW(tomcat, jboss⋅⋅⋅ 등)을 연동하는 이유

- tomcat의 web server 기능은 Apache web server보다 느린 기능을 보였고, 웹의 모든 정적/동적 데이터를 모두WAS 서버인 tomcat이 처리한다면, 결과적으로 사용자 요청의 응답 속도 감소

- 그러므로 정적 데이터는 web server인 Apache에서, 동적 데이터는 WAS인 Tomcat에서 처리함으로써 서버의 전체적인 부하를 분산하고 속도를 빠르게 하기 위해서 연동함

*WAS 처리 인스턴스 확장 시 고려사항

개발 application의 특성에 따라 증설 및 구성 확장 고려
단건 처리에 대한 메모리 사용량 부족의 경우?
서버 cpu 과 사용에 따른 리소스 부족으로 인한 서비스 지연인 경우?
과다 로그 생성 혹은 네트워크 IO발생에 따른 리소스 부족의 경우?

instance 안의 메모리, instance의 DISK I/O resource부족 (내부 이슈)으로 인해서인 경우 → instance 개수 증가

그러나, 네트워크 I/O측면의 문제 (외부 이슈)인 경우 → 서버를 늘리는 것을 권장

(memory heap size 고려)

참고)
자바에선 메모리 증량할 경우, 관리 능력 떨어짐 (service holding시간 길어짐)
file writing하는 io instance증가

2. 연계구성

2.1 3-tier 구성 및 구성 이유

1) 인프라 고가용성 측면에서 WEB/WAS/DB를 분리하여, 한 서비스가 종료되어도 나머지 서비스에는 영향을 미치지 않도록 하는 3중 이원화(WEB-WAS-DB) 를 위함

참고)
네트워크를 쏘는 방향 흐름은 →→ 이 방향으로 흐르지만
apache와 tomcat경우, ↔ 이 방향으로 response를 받음
( JSP가 서블릿을 만들고 서블릿이 결과적으로 웹 페이지를 만듦
웹 서버에서 넘어온 동적인 페이지를 읽어들여 프로그램 실행 → 그 결과를 다시 html로 재구성하여 Apache에게 response를 되돌려줌)

2) web/ was 분리 이유

ⅰ. web sever(Apache) / web container(tomcat) → 성능 측면에서 나눔 (성능 3배 좋아짐)

→ web sever 정적인 처리 (ex. 이미지) tomcat 동적인 처리만

ex) 23개 request경우 web server가 정적인 처리 다하고 web application server는 하나만 (동적인) 처리

ⅱ. web & was 서비스가 한 서버에 있는 경우, 서비스 부하시 성능 저하를 일으킬 수 있음 → Apache(web)와 Tomcat(was)를 분리하여 단일 서비스를 하는 서버로 구성

* 분리 시, 시스템 흐름 및 활용 , 서비스 유입량 고려

ex. max가 1000이라 하면, 나머지 서버로 버틸 수 있는 apache를 하나 더 추가해야함 → 늘릴 만큼의 여유 분을 생각해야함

*Apache · tomcat 각각의 서비스만을 수행하는 단일 서버 권장

(이유 : 네트워크 ip에 대한 traffic의 resource때문 등)

apache에서는 네트워크 io 성능 저하 시 내부에서 해결 못하므로, apache와 tomcat을 분리하여 각각의 서비스만 수행하는 서버1개를 둘 것을 권장

참고)
기업들이 나눈이유 : 보안 때문에
dmz존(외부망) - 내부망

2.2 연동원리

- Apache 와 Tomcat이 연동하기 위해선 AJP를 통해 서로 통신을 하여야 한다

( * AJP(Apche Jserve Protocal) : Apache 가 웹 서버와 외부 서비스(Tomcat 등) 과 연동하기 위해 정한 프로토콜 )

→ apache는 이를 사용하여 80 port로 들어오는 요청은 자신이 받고, 이 요청중 서블릿을 필요로 하는 요청은 tomcat에게 전달하여 처리한다.(httpd.conf의 JkMount 설정)

해당 프로토콜은(ajp)는 다양한 was에서 지원한다. (ex. 아파치, 톰캣, 제우스, 웹로직, 웹스피어 등 ...)

Apache · tomcat 연동 동작 flow

1) apche 웹 서버의 httpd.conf에 tomcat연동을 위한 설정을 추가하고 톰캣에서 처리할 요청을 지정한다.

2) 사용자의 브라우저는 apache 웹서버에 접속하여 요청한다. (통상 80 port)

3) apache 웹 서버는 사용자의 요청이 들어왔을 때, 이 요청이 톰캣에서 처리되도록 지정된 요청인지 확인한다.

4) tomcat에서 처리해야하는 경우, 아파치 웹서버는 tomcat의 AJP포트 (통상 8009 port)에 접속해 요청을 톰캣에게 전달한다.

5) tomcat은 apache 웹서버로부터 요청을 받아 처리한 후, 처리 결과를 다시 apache 웹 서버에게 돌려준다.

6) apache 웹 서버는 tomcat으로 전달받은 처리 결과를 사용자에게 전송한다.

2.3 Apache · Tomcat 연동 순서

1) Apache · Tomcat 각각 설치

2) JK connector 설치

- Apache가 설치된 경로의 modules 디렉터리에 mod_jk파일을 위치시킨다. httpd.conf의 mod_jk.so위치와 일치해야함

mod_jk모듈 : AJP 프로토콜을 사용하여 tocmat과 연동하기 위해 만들어진 모듈. mod_jk는 tomcat에서 배포되고 apache 웹서버에 설치해주어야 한다.

3) apache 설정

ⅰ. /etc/httpd → 이 위치에, /etc/httpd/conf/httpd.conf 파일이 생성됨

ⅱ. mod_jk 설치

ⅲ . module 사용 config 파일 생성

- workers.properties : 실제로 was와의 연동 설정을 명시하는 설정파일 → workers.properties에 연동할 tomcat의 정보 기입(host, port, lbfactor(작업할당량) 등

( worker == (was 안의)instance )

구글링

worker.list=webmail, sysman, mobile // 이름은 임의로 설정
worker.webmail.type=ajp13
worker.webmail.host=localhost
worker.webmail.port=8009 //포트번호. 톰캣에서 설정한 포트와 일치해야함
worker.webmail.lbfactor=1 //서버밸런스 비율
worker.sysman.type=ajp13
worker.sysman.host=localhost
worker.sysman.port=8019 // 포트중첩 불가.
worker.mobile.type=ajp13
worker.mobile.host=localhost
worker.mobile.port=8019 // 포트중첩 불가.

→ 연동할 tomcat의 정보를 가진 properties파일은 생성 했으면, apache가 실행할 때 참조하는 httpd.conf 파일에 이를 명시해 주어야한다.

- httpd.conf

- mod_jk.so

LoadModule jk_module /etc/apache2/modules/mod_jk.so 
# mod_jk.so의 위치

JkWorkersFile /etc/apache2/conf/workers.properties
# workers 설정 파일 위치

JkLogFile /etc/apache2/logs/mod_jk.log
# 로그파일 위치

JkShmFile /etc/apache2/logs/mod_jk.shm
# Load balancing workers will not function properly 오류 대응, httpd의 권한


JkMount /*.jsp webmail
JkMount /*.do webmail
JkMount /sysman/* sysman
JkMount /mobile/* mobile
..
..

# URL에 따른 요청 처리 설정

* JkMount : 이부분에서 어떤 url 로 오는 경우, 어떤 worker(tomcat)가 처리할 지 결정할지 설정한다.

JkMount 뒤에 오는 /* 는 모든 url의 요청을 의미한다. 즉, "모든 url의 요청에서 서블릿 관련처리가 필요하다면 , worker.properties파일에 명시된 worker에게로 넘기겠다"는 의미

→ tomcat이 여러대인 경우, workers.list의 각 worker이름(webmail, sysman,mobile)에 따라서 설정한다.

*connection전에 ping으로 확인

→ 연결 이전 connection time out 확인/ 연결 이후 connection time out 확인

request가 상대 서버까지 들어간 것인지, 아닌지 확인

4) Tomcat 설정 - server.xml

ⅰ. 기존의 HTTP 커넥터(8080 port) 제거 (주석처리)

- Apache를 통해 :80 가상 포트로 접속하기 때문에 tomcat으로 직접 접속하는 :8080 port는 사용을 막는다.

구글링

ⅱ. AJP 커넥터 설정(주석해제)

구글링

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" address="localhost"/>

( 이 ajp 커넥터에 등록한 정보와 apache worker.properties의 정보가 일치해야 통신이 가능하다. )

5) Apache, tomcat 모두 설정 완료 후, 각각 재기동.

6) Apache 80 접속 확인

- 8080 포트 없이 접속되는지 확인한다.

- 연동 전에는 포트 번호를 붙여야 하지만, 이후에는 포트 번호 없이 접속이 가능하다.

2.4 Tomcat balancing 설정

instance11,21 balancing으로 묶인다면 instance11 찾아 간 후, target 지정 확인되면 아파치는 여기에 걸리는데 300초(기본) 넘어가면 아파치가 끊음.

그리고 retry / 안되면 21로 보냄

→ balancing 목적으로 묶인 instance11, 21이 있다는 조건 하에, 처리가 들어오면 target으로 지정된 instance11로 먼저 유입함. 다만 300초가 넘어가면 retry. (retry는 시스템 목적에 따라 상이)

지정한 retry 횟수를 초과할 시, 다른 instance21로 전송

참고)
recovery (retry)안 하는 경우( 재시도 안하는 경우) ( retry 안하고 다른 instance로 보내는 경우)
웹일 경우 recovery를 될 때까지 던지면 되지만, 결제 시스템인 경우 될 때까지 처리하면 안됨(두 번 결제 되는 경우도 있으므로)

10초 이상의 tomcat을 잡아 놓은 다음, 2번 걸리는지(retry하는지) 여부 확인 → "시스템의 성격을 파악하는 것이 중요"

3. 시스템 지연 발생 모니터링 - 세부 모니터링

** 사전 확인 필요

Apache/JBoss process owner 계정에 대한 ulimit 값

- 주요 사항 (모니터링 할 때 관련 서버에 해당 수치는 인지하고 있어야 함)
1) max user processes (-u) 8192 (해당 수치 이상의 processe를 생성 못함)
2) open files (-n) 8192 (해당 수치 이상의 file open을 하지 못함)
2. cpu, memory 상태 확인

WEB 유입 구간 확인

WEB access 로그 (status code, 처리 시간)
Error 로그 (Apahce의 경우 Apache 자체 error 로그 확인 필요)
네트워크 확인 (서비스 유입 수) : MaxClients 값 비교

netstat –na | grep WEB_server_IP:80 | wc –l

WEB->WAS 처리 구간

mod_jk 로그 확인

: Apache에서 WAS로 연동 상태 및 처리 시간

(참고)

1) mod_jk : Apache와 tomcat을 연동하기위한 모듈. AJP 프로토콜을 이용하여 Apache에 들어온 요청 중 tomcat이 처리할 요청을 AJP 포트(일반적으로 8009)을 통해 tomcat에 전달하고 그에 대한 응답을 받는 역할.

2) nginx엔 mod_jk 없음

WAS 유입 구간 확인

WAS access 로그 (status code, 처리 시간)
Error 로그 (nohup로그 혹은 server.log, App 자체 로그 확인도 필요)
네트워크 확인 (서비스 유입 수) : max-connections 값 비교

netstat –na | grep WEB_server_IP:80 | wc –l

DBMS 연계 구간 확인

네트워크 확인 (서비스 유입 수) : datasource 사용시 min max 값 비교

netstat –na | grep WEB_server_IP:1521 | wc –l

2. CLI를 이용하여 "ActiveCount“(실 사용 connection) 수 파악

타 시스템 연동 구간 확인 (사전 시스템 파악 필요)

네트워크 확인 (처리 연계 수) : 개발 소스 owner 협의

netstat –na | grep WEB_server_IP:1521 | wc –l

(유입 업무와 관련성이 있는지 확인)

4. apache · tomcat 별 모니터링

apache

Tomcat

httpd.conf 먼저 확인

- 영향을 주는 conf파일이 무엇이 있는지 파악 ( httpd.conf에서 줄기처럼 뻗어나가는 식 )
ex. grep jk httpd.conf
grep includ httpd.conf

tomcat 이랑 시간이 다름, 처리한 후 끝난 시간 보여 줌

- 시간 : 10,000단위
- 처리 종료 후 시간

도메인, 유입하는 ip, contents path 별로 분기가능

- 도메인은 같지만 분기하고싶다면 → wlb1, wlb2로 분기가능

apache 자체, request, access log 로 파악

- tomcat과 연동시 mod_jk 생성

access log : 시간별로 데이터 유입량 파악 가능 (time table 확인 가능)

- 병목이 생겨서 유입량이 는건지(tomcat이 느려서 쌓아서 많이 보이는건지)
- 유입량이 많이 늘어서 cpu가 튄건지
ex) 갑자기 0.00001 → 10초 처리 :지연으로 인한 처리유입량의 병목
처리는 동일한 경우 → 유입량때문에 처리 지연

각각의 요소별로 지정돼 있음 ( httpd.conf에서 줄기처럼 뻗어나가는 식이 아님)

apache랑 tomcat 시간이 다름, tomcat은 처리 종료난 후 걸린 시간을 보여줌

- 시간 : 10,000단위
- 처리 종료까지 걸린 시간

(database부문에선) connection Pool max가 2개인 경우 → connection 부족 현상 or 모니터링 포인트 부분 놓칠 수 있음.

- 타시스템에 대한 연결 부분도 중요포인트로 고려해야함

was 부문은 개발자 application 측면을 고려해야 함

apache 시간별로 데이터 유입량 파악 가능한 access log 없음 → web - was 각각의 access log 기능이 다르다

* 외향적인 현상가지고 내부 현상 파악 고려 필수

별첨)

*소유자와 소유그룹 설정 방법
소유자, 소유그룹 설정은 chown 명령어를 사용. change owner를 의미하는 명령어
$ chown test:test root_directory
$ chown -R test:test root_directory // 하위 디렉토리 모두 소유자 변경할 경우