Apache on

아파치 로드밸런싱으로 여러 WAS 운영하기

Sun, 04 Aug 2019 19:50:43 +0000

웹서버 하나만 사용하거나 WAS 하나만을 사용하며 웹서비스를 운영하는 경우는 극히 드물다. 웹서버의 장점과 WAS의 장점 그 두마리의 토끼를 다 잡기 위해 보통 앞단에 웹서버를 두고 그 뒤에 WAS를 두며 서비스를 운영하곤 한다. 헌데 운영하는 서비스가 인기가 많아져(?) 사용량이 많아지다면 그만큼 응답이 느려 (TPS 등) 서버를 늘려야 하는 상황이 생긴다고 가정해보자. (물론 서버를 늘리는 것보다 캐시를 적용하거나 로직을 바꿔보는 노력이 선행되야 하겠지만…) 당연히 서버부터 구매하며 “Scale Out"을 하려고 할것이다. 만약 원래 운영하던 서버가 너무 좋아서 CPU나 메모리 사용률이 거의 바닥이여도 서버를 구매해야 할까? 서버를 구매하게되면 결국 두개 이상의 서버가 운영될텐데 그 서버들을 앞에서 묶어주며 트래픽을 분산시켜주는 무언가가 필요하다. 그러한 기술을 바로 로드밸런싱 이라고 한다. 통상 L4 스위치를 활용하여 요청을 여러 서버들로 분산시키며 산술적으로는 서버 대수만큼 성능이 좋아지는 효과를 볼 수 있다. 하지만 앞서 말했듯 서버의 자원 사용률이 바닥일 정도로 거의 사용을 안할경우 서버를 구매하는건 너무나 비효율적이다. 이번 포스팅에서는 서버를 늘리지 않으면서 웹서버 중 아파치를 활용하여 여러 WAS를 운영하는 방법에 대해 알아보고자 한다. 서버 늘려야 하는 상황에서 사용해 볼 수 있는 나만의 좋은 무기(?)가 생긴게 아닐까 생각이 든다.

아파치는 EOL이 되었기 때문에 2.4버전으로 설치하고, WAS는 편의상 톰켓 최신버전으로 설치해서 동일한 서버에 아파치 한대와 톰켓 3대를 연동하는것을 목적으로 한다. 로드밸런싱이 어떤식으로 이루어 지고 하위에 연결된 톰켓을 컨트롤 하는 방법 또한 알아볼 예정이다.

서버 환경 및 설치하게 될 각 버전은 다음과 같다. 서버 : CentOS 7.4 64Bit apache : httpd-2.4.39 tomcat : apache-tomcat-8.5.43 tomcat-connectors(mod_jk) : 1.2.46

Apache 와 Tomcat 설치

필자의 포스팅에서 종종 나오는 부분이기도 하고, 구글링 해보면 바로 설치 방법을 쉽게 찾을 수 있겠지만 그렇다고 언급을 안하고 넘어가기엔 너무 불친절하니… 치트키처럼(?) 빠르게 정리해보자.

Apache

$ wget http://apache.tt.co.kr//httpd/httpd-2.4.39.tar.gz
$ tar -zxvf httpd-2.4.39.tar.gz
$ ./configure --prefix=/home/~~~/apache
$ make && make install
$ cd /home/~~~/apache/bin
$ sudo chown root:계정명 httpd
$ sudo chmod +s httpd
$ vi /home/~~~/apache/conf/httpd.conf
User 계정명
Grop 계정명
$ /home/~~~/apache/bin/apachectl start ← 실행

이렇게 설치를 한뒤 실행을 시키고 서버의 ip를 접속해보면 아래와 같은 화면을 볼 수 있다.

Tomcat

$ wget http://mirror.apache-kr.org/tomcat/tomcat-8/v8.5.43/bin/apache-tomcat-8.5.43.tar.gz
$ tar -zxvf apache-tomcat-8.5.43.tar.gz
$ /home/apache-tomcat-8.5.43/bin/start.sh ← 실행

톰켓의 기본 http 포트인 8080으로 접속을 해보면 귀여운 고양이가 있는 톰켓 기본화면을 볼 수 있다.

아파치와 톰켓 연동하기

아파치와 톰켓의 연동은 mod_jk 와 mod_proxy 등 다양한 모듈로 연동을 할 수 있는데 이번 포스팅에서는 mod_jk 를 활용하는 방법에 대해 알아보고자 한다. 우선 mod_jk 를 설치하자.

간단히 mod_jk 는 컴파일, 설정 등 복잡하지만 톰켓 전용 바이너리 프로토콜인 AJP를 사용하기 때문에 높은 성능을 기대할수가 있다. mod_proxy 는 반면 기본으로 아파치에 탑재되어있는 모듈이기 때문에 별도의 모듈 설치가 필요 없고 설정도 간단하다는 장점이 있다. 각 연동방식의 장단점이 있기 때문에 본인이 운영하는 서버 상황에 맞추어 적용 할 필요가 있다.

mod_jk 설치

$ wget http://apache.tt.co.kr/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.46-src.tar.gz
$ tar -zxvf tomcat-connectors-1.2.46-src.tar.gz
$ cd tomcat-connectors-1.2.46-src/native
$ ./configure --with-apxs=/home/~~~/apache/bin/apxs
$ make && make install
$ /home/~~~/apache/modules 하위에 mod_jk.so가 생김

mod_jk 를 활용하면 AJP라는 통신으로 아파치와 톰켓이 연동되는데 톰켓의 기본 AJP 포트는 8009번임을 알고 다음처럼 설정을 해주자.

apache/conf/workers.properties

worker.list=tomcat1
worker.tomcat1.port=8009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13
worker.tomcat1.lbfactor=1

apache/conf/httpd.conf

LoadModule jk_module modules/mod_jk.so
<IfModule jk_module>
 JkWorkersFile conf/workers.properties
 JkLogFile logs/mod_jk.log
 JkLogLevel info
 JkMount /* 	tomcat1
</IfModule>

이렇게 하고서 아파치와 톰켓을 재시작 후에 서버의 ip로 접속해보면 (별도의 port 없이) 톰켓 설정페이지로 랜딩이 되는것을 확인할 수 있다.

로드밸런싱을 위한 작업

여기까지는 본 포스팅을 작성하기 위한 밑거름이라고 말할 수 있다. 이제 실제로 로드밸런싱을 해볼 차례. 앞서 톰켓 하나만 설치했는데 편의상 톰켓 3개를 설치해두자. (하나를 설치하고 cp -r 명령어를 활용하는게 빠르다.) 그 다음 각 톰켓의 모든 포트를 셋다 다르게 설정해야 하는데 겹치지 않도록 설정해 두고 (필자는 앞자리를 1,2,3 이런식으로 다르게 설정하였다.) 워커(workers.properties)를 아래처럼 설정해주자.

초간단 API서버 만들기 - 2부 (Python + Flask + Nginx)

Sun, 01 Jul 2018 02:00:00 +0000

지난포스팅에 이어 이번엔 Flask와 Nginx를 연동하는 방법을 정리해보고자 한다. Apache로 연동했는데 왜 또 Nginx로 연동하는걸 정리하지(?)하며 의문이 들수 있는데 다른 포스팅을 봐도 Apache + Flask 조합보다 Nginx + Flask 조합이 더 많고 지난 포스팅에서도 알수있었듯이 (Apache VS Nginx) 둘중 어느것이 좋다고 할수도 없고 각 상황에서 연동하는 방법을 알고 있다면 이 또한 나만의 무기가 될것같아 Nginx를 연동하는 방법을 정리해보려 한다.

1부에서 왜 Flask인가, Flask의 장점에 대해 정리를 했으니 이번 포스팅에서는 별도로 작성하진 않는다.

Nginx 설치 ( https://nginx.org/en/ )

역시 소스설치를 한다.

- 다운을 받고
$ https://nginx.org/download/nginx-1.14.0.tar.gz
- 압축을 푼 다음
$ tar -zxvf nginx-1.14.0.tar.gz
- 폴더로 이동해서 
$ cd nginx-1.14.0
- 설치할 디렉토리를 설정하고
$ ./configure --prefix=/~~~/apps/nginx
- make 파일을 만들고
$ make
- 설치를 진행한다.
$ make install

이렇게 하면 일단 Nginx는 설치가 되었다.

uWSGI 설치 ( https://uwsgi-docs.readthedocs.io/ )

앞서 Apache와 연동할때는 별도의 모듈을 Apache에게 등록하는 형태였다면 Nginx는 WSGI프로토콜을 활용하는 WSGI 어플리케이션을 실행하는 어플리케이션 서버를 활용해야 한다.

- 다운을 받고
$ wget https://projects.unbit.it/downloads/uwsgi-latest.tar.gz
- 압축을 풀고
$ tar zxvf uwsgi-latest.tar.gz
- 폴더로 이동하여
$ cd uwsgi-2.0.17
- make 명령어를 호출하면 'uwsgi'이라는 실행파일이 생성된다.
$ make

Nginx 설정

Apache와 비슷하게 uWSGI 관련 설정을 해준다.

server {
 listen 80;
 server_name localhost;

 location / { # ( / ) 경로로 들어올 경우
 include uwsgi_params; # GET/POST 등 기본적으로 필요한 환경변수를 include 해준다.
 uwsgi_pass 127.0.0.1:3031; # 요청을 IP:PORT로 전달한다.
 }
}

별도의 모듈을 사용하지 않기때문에 전달해주는 (proxy느낌) 설정을 해준다.

uWSGI 실행 및 Nginx 재시작

앞서 설치한 uwsgi를 아래처럼 IP:port 를 명시적으로 적어주고 (위에서 전달받은 IP:PORT와 동일하게) Apache 연동시 활용했던 wsgi파일을 이번에도 동일하게 사용하도록 해서 실행한다.

$ ./uwsgi -s 127.0.0.1:3031 --wsgi-file /~~~/python_app/hello_world.wsgi

이렇게 하면 background로 실행되는게 아닌 foreground로 실행되기 때문에 &을 사용한다던지 해서 background로 실행되도록 해준다. 그후 Nginx를 재시작 해주면 원하는 그토록 원했던 Hello World!를 만날수가 있게 된다.

Apache연동과 조금 다른점은 모듈을 사용하지않고 별도의 전달 어플리케이션(?)이 필요하다는점이다. 간단히 Apache처럼 모듈만 넣으면 되는게 아니라서 불편할수도 있을것 같지만 한편으로는 관리할수있는 포인트가 더 늘어난 셈이라 어떤 측면에서는 활용할수 있는 방법이 하나 늘어난것으로 볼수도 있다.

마치며

막상 정리하고 나면 아무것도 아닌데 알기 위해서 몸부림을 쳐가며 책이며 구글링을 하는 과정을 통해 점점 성장을 하는것 같다. (성장통이라고나 할까) 이렇게 단순히 Flask를 할수있다 가 아닌 웹서버를 연동할수있다. 그것도 Apache와 Nginx 두개나. 이것도 언젠간 나만의 무기가 되지 않을까?

초간단 API서버 만들기 - 1부 (Python + Flask + Apache)

Fri, 29 Jun 2018 23:00:00 +0000

Static한 HTML이 아닌 로직이 필요한 API서버를 구성한다고 가정해보자. (이제까지 지식으로)처음 머릿속에 떠오르는건 Java를 사용하고 스프링으로 어플리케이션을 만들고 apache에 tomcat을 연동한 다음 … 이러한 방법으로 API서버를 구성할수 있겠지만 프로토타이핑 또는 테스트 목적으로 만들기 위해서는 설정하는 시간이 은근 많이 소요된다. (물론 Java Config, Spring Boot 등 간소해졌지만…) 얼마전부터 Python에 대한 매력을 뼈저리게 느끼고 있다보니 Python으로 API서버를 구성할순 없을까 알아봤고 (모바일 게임 듀랑고 서버가 python이라고 하기도 하고…) Flask와 Django가 있어서 둘다 써본 결과 필자는 Flask가 맞겠다고 생각해서 정리를 해볼까 한다.

‘장고’라고도 불리는 Django에는 모든것들이 다 들어가 있어서 사용하기 너무 편리하다. (DB, 어드민 등 ) 하지만 Flask는 내가 사용할 것들만 import해서 사용하는 방식이라 어떤 측면에서는 아무것도 없다 할수 있겠으나 커스터마이징에 용이하다고 볼수 있었기에 Flask를 선택하게 되었다. (Django가 Flask보다 안좋다는 말은 아니니 오해는 하지 마시길…)

글쓰기에 앞서 본 포스팅은 2개의 포스팅에 걸쳐 시리즈(?)형식으로 작성할 예정이다. 1부에서는 Flask가 무엇이고 이를 어떻게 사용하며 Apache와 연동하는 방법을 소개하고, 2부에서는 Nginx와 연동하는 방법을 소개한다. 환경은 다음과 같다.

CentOS 7.4
Python 3.6 (기본은 2.7이였으나 추가로 설치)

Flask ( http://flask.pocoo.org/ )

공식 홈페이지에서도 보면 알수 있듯이 너~무 간단하다. 단지 아래 코드 몇줄만 작성하면 우리가 모든 프로그램 초기 작성시 항상 만나는 “Hello World"를 볼수 있다.

#hello_world.py

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
 return "Hello World!"

위와같이 작성하고 python hello.py로 실행해두고 브라우저에서 http://127.0.0.1:5000 을 요청하면 반가운 Hello World를 만날수 있다. (너무 간단;;) 자세한 문법은 도큐먼트를 참조하면 될듯하고 이 Flask를 잘만 활용한다면 보다 빠르고 간단하게 API서버를 구성할수 있을거라 생각한다.

Hello World를 찍었으면 된거 아닌가 라고 질문할수도 있겠으나 실제 서비스에서 사용하기 위해서는 앞단에 웹서버를 두는게 여러 측면에서 효율적이다. 주로 사용하는 웹서버는 Apache 와 Nginx가 있는데 여기서는 Apache와 연동하는 방법을 정리 해보고자 한다.

Apache 설치 ( http://archive.apache.org/ )

우선 필자는 yum 이나 apt-get처럼 패키지 관리자로 설치하는것을 그렇게 좋아하지 않는다. 이유는 커스터마이징을 할 경우 시스템 어느곳에 설치되어있는지를 한눈에 파악하기 어렵고 윈도우경우 Program Files처럼 내가 추가로 설치하고 관리하는 프로그램들을 한곳에서 관리하고 싶기에 왠만하면 소스를 직접 컴파일하여 설치하곤 한다. 이번 역시 아파치도 소스로 설치하려고 한다. 현재 아파치는 2.4버전이 Stable버전으로 되어있지만 보다 레퍼런스가 많은 2.2버전으로 설치하기 위해 어렵게 아카이빙된 경로를 통해 다운을 받고 설치를 한다.

- 다운을 받고
$ wget http://archive.apache.org/dist/httpd/httpd-2.2.29.tar.gz 
- 압축을 푼 다음
$ tar xvzf httpd-2.2.29.tar.gz
- 해당 폴더로 들어가
$ cd httpd-2.2.29
- 컴파일 후 설치 경로를 정해주고
$ ./configure --prefix=/~~~/apps/apache
- make 파일을 만든다음
$ make
- 설치를 해준다.
$ make install

이렇게 되면 /~~~/apps/apache/ 하위에 필요한 파일들이 설치가 되는데 root계정이 아닌 일반계정으로 실행하기 위해서는 /bin하위에 있는 httpd에 대한 실행/소유권한을 변경해줘야 한다. (아니면 그냥 root권한으로 시작/종료. 왜? Apache는 80port를 사용하는데 일반적으로 리눅스에서는 1024 아래 port를 컨트롤 하기 위해서는 root권한이 있어야 사용이 가능, 그게 아니라면 이처럼 별도의 설정이 필요하다.)

$ sudo chown root:계정명 httpd
$ sudo chmod +s httpd

mod_wsgi 설치 ( https://code.google.com/archive/p/modwsgi/ )

웹 서버 게이트웨이 인터페이스(WSGI, Web Server Gateway Interface)는 웹서버와 웹 애플리케이션의 인터페이스를 위한 파이선 프레임워크다. 라고 정의되어있다. 즉, 웹서버(Apache)와 위에서 만든 Flask 어플리케이션을 연동해주기 위한 프레임워크이다. 이또한 소스로 설치해보자. (위와 같은 이유로~)

- 다운을 받고
$ wget https://github.com/GrahamDumpleton/mod_wsgi/archive/3.5.tar.gz
- 압축을 푼 다음
$ tar -zxvf 3.5.tar.gz
- 폴더에 들어가서
$ cd mod_wsgi-3.5
- 아파치의 빌드툴인 apxs의 경로를 설정해주고
- 필자와 같이 기본 python 버전을 사용하지 않을꺼라면 꼭 python경로를 설정해줘야 한다! (중요)
$ ./configure --with-apxs=/~~~/apps/apache/bin/apxs --with-python=/usr/bin/python3.6
- make 파일을 만들고
$ make
- 설치~
$ make install

이렇게 설치를 하면 자동으로 아파치 하위 /modules 폴더안에 mod_wsgi.so 파일이 생긴다. (필자는 이것도 모르고 mod_wsgi.so파일을 다운 받으려고 구글링을 몇일째 했던 기억이 ㅠ)

Apache냐 Nginx냐, 그것이 알고싶다.

Wed, 27 Jun 2018 17:17:33 +0000

웹서버는 HTTP 프로토콜을 통해 읽힐수 있는 문서를 처리를 하며 일반적으로 웹 어플리케이션의 앞단에 배치되곤 한다. 동적인 리소스는 WAS에게 처리하도록 하고 정적인 리소스를 보다 효율적으로 처리하기 위한 방법일수도 있다. 크게 Apache와 Nginx가 사용되곤 하는데 이 둘의 차이는 무엇일까? 사실 필자는 사내에서 주로 Apache만 사용하다보니 Nginx는 그저 Apache와는 다른 방식의 웹서버다 또는 보다 경량화 되었다 정도로만 알고있었는데 이번기회를 통해 제대로 알고 비교를 해보면서 결국 어떤게 좋은지 알아보고자 한다.

구글링을 조금만 해보면 Apache와 Nginx를 비교하는 포스팅이 많이 나온다. 이번 포스팅의 목적 이러한 정보들을 단순히 요약/종합 하려는게 아니고, 최대한 실무 서비스를 운영하는 시각으로 정리하고자 함을 밝힌다.

Apache ( https://httpd.apache.org/ )

우리나라에서 웹어플리케이션을 개발하는 사람들은 한번쯤은 들어봤을 Apache. 국내 일반적인 기업에서 웹서버의 표준으로 자리잡았다고 해도 과언이 아닐것 같다. Client에서 요청을 받으면 MPM (Multi Processing Module : 다중처리모듈) 이라는 방식으로 처리를 하는데 대표적으로는 Prefork와 Worker방식이 있다. 간단하게 어떤식으로 처리하는지 알고 넘어가자.

Prefork MPM

Prefork MPM, http://old.zope.org/Members/ike/Apache2/osx/configure_html

실행중인 프로세스를 복제되어 처리가 된다. 각 프로세스는 한번에 한 연결만 처리하고 요청량이 많아질수록 프로세스는 증가하지만 복제시 메모리영역까지 복제되어 동작하므로 프로세스간 메모리 공유가 없어 안정적이라 볼수 있다.

Worker MPM

Worker MPM, http://old.zope.org/Members/ike/Apache2/osx/configure_html

Prefork 동작방식이 1개의 프로세스가 1개의 스레드로 처리가 되었다면 Worker 동작방식은 1개의 프로세스가 각각 여러 쓰레드를 사용하게 된다. 쓰레드간의 메모리를 공유하며 PreFork방식보다 메모리를 덜 사용하는 장점이 있다.

참고로 WAS로 tomcat을 연동하는 경우라면 mod_jk, mod_proxy, mod_proxy_ajp 방식을 Apache 자체적으로 지원해주기 때문에 다양하고 효율적으로 tomcat을 연동할수 있다. 참고링크

Nginx ( https://nginx.org/en/ )

Nginx에 대해 살펴보기 전에 구글 트랜드를 활용하여 Nginx에 대한 관심이 어느정도인지를 보고 넘어가자.

최근 5년간 구글트랜드, 파란색이 Apache이고 빨간색이 Nginx

전세계는 Nginx보다는 Apache에 대한 관심이 많은것으로 보이는데 국내는 아주 조금씩 Nginx에 대한 관심이 오르는것을 볼수있었다. (그래도 아직은 Apache가 월등히 우세한 편이다.) 그럼 Nginx는 어떤식으로 돌아가는 것일까? 가장 유명한(?) 특징이라면 Event Driven 방식을 꼽을수 있을것 같다. Event Driven 방식에 대해 잠깐 언급을 하고 넘어가면 요청이 들어오면 어떤 동작을 해야하는지만 알려주고 다른요청을 처리하는 방식이다. (Producer Consumer Pattern과 유사하다.) 그러다보니 프로세스를 fork하거나 쓰레드를 사용하는 아파치와는 달리 CPU와 관계없이 모든 IO들을 전부 Event Listener로 미루기 때문에 흐름이 끊기지 않고 응답이 빠르게 진행이 되어 1개의 프로세스로 더 빠른 작업이 가능하게 될수 있다. 이때문에 메모리적인 측면에서 Nginx가 System Resource를 적게 처리한다는 장점이 있다고 한다.

Nginx Process Model (https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale)

그래서 뭐가 좋은가?

이 포스팅을 적으면서 마지막엔 Apache가 더좋다 또는 Nginx가 더좋다로 마무리를 짓고 싶었는데 어느 시사/교양 프로그램처럼 어쩔수 없는 열린결말로 마무리를 지을수밖에 없을것 같다. (어찌보면 이게 정답일수도?)

기술의 선택에 있어서 정답은 없는것 같다.(물론 Spring 을 사용하느냐 서블릿을 직접 구현하는냐 와는 좀 다른 성격의 이야기;;) 운영하고 있는 서비스의 상황을 잘 알고 튜닝을 해가면서 가장 효율적인것을 선택하는게 정답이라고 말할수 밖에… 커뮤니티 파워를 무시 못하기 때문에 Apache를 선택할수도 있을테고, 점점 관심도가 올라간다는건 그만큼의 장점이 있고 또한 메모리 측면에서 동접자 처리시 효율적인 Nginx를 사용할수 있을것 같다.

아파치 엑세스 로그에 408코드가?

Sun, 29 Apr 2018 17:39:36 +0000

예전에 아파치 로그를 엘라스틱 스택을 활용하여 내 서버에 누가 들어오는지를 확인할수 있도록 구성을 해두고 몇일간 지켜보니 다음과 같은 엑세스 로그가 발생하고 있었다.

1.2.3.4 - - [26/Apr/2018:01:27:33 +0900] "GET /aaa/ HTTP/1.1" 200 6001 30788 "http://www.naver.com" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:28:08 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:28:08 +0900] "-" 408 - 28 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:28:08 +0900] "-" 408 - 12 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:28:08 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:28:50 +0900] "GET /aaa/ HTTP/1.1" 200 5999 13521 "http://www.naver.com/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:29:14 +0900] "GET /aaa/ HTTP/1.1" 200 5996 19437 "http://www.naver.com" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:29:15 +0900] "GET /aaa/ HTTP/1.1" 200 5997 17553 "http://www.naver.com" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:29:15 +0900] "GET /aaa/ HTTP/1.1" 200 5998 17429 "http://www.naver.com/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:29:53 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:29:53 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:29:53 +0900] "-" 408 - 32 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:29:53 +0900] "-" 408 - 38 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:29:53 +0900] "-" 408 - 29 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:30:54 +0900] "GET /aaa/ HTTP/1.1" 200 6000 17881 "http://www.naver.com" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"
1.2.3.4 - - [26/Apr/2018:01:31:34 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:31:34 +0900] "-" 408 - 30 "-" "-"
1.2.3.4 - - [26/Apr/2018:01:31:34 +0900] "-" 408 - 25 "-" "-"

한시간에 만건이상 응답코드는 408, referrer도 없고, useragent도 없는, ip들도 매우 다양한 이상한 녀석들이 요청되고 있었다.

이렇게 엑세스 로그를 분석할수 있는 구성을 해두고 나니 보였지 안그랬음 그냥 지나갔을 터..

이러한 데이터를 키바나에서 보면 아래처럼 볼수있는데 한눈에 봐도 과연 의미있는 요청들일까? 하는 의구심이 들정도이다. (1시간 아파치 엑세스 로그)

주황색이 408응답

그럼 이런 호출들은 도대체 뭘까? 천천히 생각좀 해보자.

정상적이지 않는 호출로 우리 서버의 취약점을 파악하려 하는것들일까?
응답코드 408은 요청시간초과 응답코드인데… 오히려 클라이언트 입장에서 문제가 있는건 아닐까?
어플리케이션 로직이 잘못되어 무한루프에 빠졌나;

위키백과에서는 아파치 응답코드 중 408에 대한 응답을 다음과 같이 알려주고 있다.

The server timed out waiting for the request. According to HTTP specifications: “The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time

즉, 아파치 단에서 타임아웃을 내버리는 상황. 여러 다양한 키워드들로 구글링을 해봐도 이렇다할 검색결과를 찾지 못하고 네트워크 관련상황인지 싶어 크롬 개발자도구를 열어 네트워크 지연 테스트를 해보았으나 별 효과가 없었다. 그렇게 범인찾는 형사의 심정으로 이것저것 알아보다 우연히 집에서 원격으로 회사 VPN 붙어서 테스트 하던도중 관련 증상을 재현 할수 있게 되었다.

# 재현상황

우선 아파치버전은 2.2이고 KeepAlive Off가 되어있는 상황. 아래그림처럼 집PC - 공유기 - VPN - Apache - tomcat jenkins 상황이였는데 젠킨스에 한번 접속후에는 항상 408 응답이 주루룩(?) 발생하는것을 알수 있었다. (사실 맨위에 엑세스 로그가 재현한 엑세스 로그이다.)

Apache keepAlive

Mon, 28 Aug 2017 19:56:40 +0000

서버를 운영하다보면 간혹 문제가 발생하곤 한다. 이를테면 메모리가 다른이유없이 올라간다거나, 사용자 입장에서 응답속도가 간헐적으로 느린다거나. 그럴때마다 선배개발자분들께서 가장먼저 입에 오르내리는 단어. keepAlive.