weblogic.Deployer 를 이용한 배포.

WebLogic 은 weblogic.Deployer 라는 Command Line 명령어를 이용해서 배포를 할 수 있습니다. 이를 통해서 GUI 화면인 WebLogic Admin Console 없이도 터미널을 이용해서 쉽고 빠르게 배포를 할 수 있는 것입니다.

setWLSEnv.sh 실행

터미널의 Command Line 에서 weblogic.Deployer 를 사용하기 위해서는 반드시 환경실행 파일을 먼저 실행해야 합니다. setWLSEnv.sh 라 불리우는 이 파일은 weblogic.Deployer 를 실행하기 위한 각종 라이브러리 클래스와 명령어 PATH를 세팅해 줍니다.

반드시 weblogic.Deployer 를 실행하기 전에 실행해줘야 합니다.

weblogic.Deployer 사용법

이를 사용하기 위해서는 반드시 Admin 서버를 주소와 포트를 알아야 합니다. WebLogic 의 모든 제어는 Admin 을 통해서만 가능하기 때문이며 weblogic.Deployer 실행하는 서버와 Admin 서버간의 통신도 가능해야 합니다.

배포된 애플리케이션 리스트

먼저 배포된 애플리케이션 리스트를 가져와 보겠습니다.

Admin 서버 주소와 포트를 -adminurl 인자로 주고 Admin Web Console 로그인 정보로 인증을 해줍니다. 마지막으로 배포된 애플리케이션 리스트를 출력하도록 -listapps 를 인자로 줍니다.

배포하기

배포를 하기 위해서는 먼저 Admin 서버에 업로드 디렉토리에 배포할 애플리케이션 파일이 존재해야 합니다. (뒤에 업로드도 하면서 배포하는 방법이 있습니다.)

그리고 다음과 같이 해줍니다.

배포가 완료 되었다. 하지만 여기에는 한가지 문제가 있습니다.

애플리케이션은 유지보수가 됩니다. 그래서 많은 변화가 일어나고 변화된 내용을 WebLogic 서버에 배포해야 합니다. 그런데, 배포할 파일 이름이 healthCheck.war 로 모두 동일하다면 WebLogic 서버에 배포하기 위해서는 기존의 배포된 파일을 제거하고 새로운 파일을 배포해야 합니다. 이는 사람이 수동을 다 해줘야 합니다.

버전 배포하기

만일, 배포시에 애플리케이션을 구분하기 위해서 버전정보를 준다면 WebLogic 서버는 자동으로 기존의 배포된 애플리케이션은 회수되고 새로운 버전의 애플리케이션이 활성화해주어 서비스를 지속할 수 있도록 해줍니다.

-appversion 1.0.1 은 배포되는 애플리케이션 버전이 1.0.1 임을 지정해 줍니다.

재배포 하기

재배포는 기존의 버전보다 업데이트된 버전으로 교체하는 것을 말합니다. 지금까지 배포할때 사용했던 -deploy 대신에 -redeploy 를 사용하고 버전은 기존의 것보다 높은 버전을 지정해주면 됩니다.

기존의 1.0.1 버전보다 높아진 1.0.2 를 사용했고 재배포하기 위해서 -redeploy 를 사용했습니다.

지금까지 배포 방법에는 한가지 문제가 있습니다. 전부다 Admin 서버를 대상으로 배포를 진행했다는 것입니다. weblogic.Deployer 는 배포할 서버를 지정해줄 수가 있습니다. 서버뿐만 아니라 Cluster 를 지정함으로써 Cluster 내에 포함된 모든 서버에 배포를 적용할 수도 있습니다.

타켓(Target) 지정 배포하기

배포 대상 서버, Cluster 을 타켓이라고 합니다. -targets 옵션을 주어서 지정할 수 있습니다.

타켓을 지정하면 결과 출력에도 타켓 서버가 함께 출력됩니다.

파일 업로드 배포하기

만일 원격에서 파일을 배포하려고 하는데, 배포 파일을 서버로 옮길 방법이 없을 경우에 파일 업로드와 함께 배포를 실행할 수 있습니다. 이를 사용하기 위해서는 먼저 업로드 디렉토리가 설정되어 있어야 합니다.

-upload 옵션과함께 -remote 옵션을 함께 사용합니다.

UnDeploy 하기

배포를 삭제하기 위해서는 undeploy 를 하면 됩니다. undeploy 할때에는 -source 옵션은 필요 없고 -version 과 -target 그리고 애플리케이션 이름 옵션인 -name 만 있으면 됩니다.

 

Systemd for WebLogic 11g

Ubuntu 16.04, CentOS 7, RHEL 7 부터는 Systemd 로 Kernel 의 메인프로세스가 바뀌었습니다. 과거에는 Init 이였는데 이 배포판들은 systemd 로 바뀌었습니다.

리눅스가 부팅하면서 SystemV 인 Run Level 에 따라서 자동으로 시작시키기위한 Init Script 가 존재했었는데, Systemd 도 리눅스가 부팅하면서 시작되도록 하는 Systemd Script 가 존재합니다.

Systemd for WebLogic Administrator

WebLogic 을 Systemd 로 동작하는 배포판에 설치했다면 시작/중지 스크립트를 다음과 같이 작성할 수 있습니다.

WebLogic 의 Admin 서버가 구동될때에 각종 옵션들을 주고 싶다면 “USER_MEM_ARGS” 쉘 환경변수로 지정하고 ‘startWebLogic.sh’ 를 실행하면 그것이 적용된다. Systemd 에서 이러한 환경변수들은 ‘/u01/app/weblogic/config/domains/mCloud/servers/AdminServer/etc/default/adminserver’ 파일에 다음과 같이 정의해 줍니다.

 

Systemd for WebLogic Managed Server

Managed Server 를 시작하기 위해서는 ‘startManagedWebLogic.sh’ 스크립트를 사용하는데, 인자로 서버명을 주어야 합니다. 이것도 Admin 서버와 비슷하게 환경파일을 지정하고 그곳에 정의해주면 됩니다.

‘/u01/app/weblogic/config/domains/mCloud/servers/Server-0/etc/default/server-0’ 는 다음과 같습니다.

물론 USER_MEM_ARGS 환경변수를 지정할 수도 있습니다.

Systemd 등록.

Systemd 에 스크립트를 등록하기 위해서는 ‘/etc/systemd/system’ 디렉토리로 파일을 복사하고 다음과 같은 명령어를 입력해줍니다.

심볼릭 링크가 생성되면서 Systemd 스크립트가 등록이 됩니다. 등록이되면 이제부터 시스템이 꺼질때는 자동으로 WebLogic 도 꺼지고 시스템이 부팅되면 자동으로 시작이 됩니다.

 

WebLogic 11g Silent 설치

WebLogic 11g Silent 설치 에대한 글입니다. Oracle 제품군들을 설치하기 위해서는 GUI 환경이라야 한다고 생각하겠지만 GUI 환경이 아니더라도 설치가 가능한데, 이러한 방법을 Slient 설치하록 합니다. WebLogic 11g 도 Silent 설치를 지원 합니다.

Silent 설치에 핵심은 설치를 위한 각종 자료를 XML 파일로 작성하는 것입니다. ‘각종 자료’라고 함은 설치할 디렉토리, 설치할 컨포넌트등을 정의하는 것입니다.

설치 환경

설치 환경은 다음과 같습니다.

  • OS: Ubuntu16.04 64bit
  • Hostname: weblogic1.localdomain

 

설치 준비

호스트네임 변경

호스트네임을 변경해줍니다. 과거에는 파일을 조작해야 했지만 다음과 같이 hostnamectl 명령어를 이용합니다.

로그인을 다시하면 변경된 호스트네임이 반영됩니다.

계정생성

계정은 Oracle 제품군 설치를 위해서 oinstall 그룹과 weblogic 계정을 다음과 같이 생성합니다.

디렉토리 생성

Oracle 은 자사의 제품군에 대한 설치를 위해 디렉토리 구조를 정의놨는데 이것을 OFA(Optimal Flexible Architecture) 라고 부릅니다. OFA 는 단순하게 디렉토리만을 정의한것이 아니라 파일시스템, 스토리지 확장등을 모두 고려해 연구해 Oracle 에서 발표한 것입니다.

 

Weblogic 11g 설치를 위해 다음과 같이 디렉토리를 생성 합니다.

쉘 환경 변수 설정

weblogic 계정에 쉘 환경변수를 다음과 같이 만들어 줍니다.

Silent.xml 생성

이제 설치 명세서인 Silent.xml 를 다음과 같이 작성해 줍니다.

대략 위와같이 작성합니다. 각각의 내용은 Oracle 홈페이지 Silent.xml 에 나와 있습니다.

설치 

다음과 같이 설치를 진행 합니다.

설치는 의외로 금방 끝난다.

이제 설치가 정상적으로 되었는지 다음과 같이 테스트를 합니다.

 

도메인 생성

GUI 가 없기 때문에 도메인 생성도 역시 Console 상태에서 해야하는데, WebLogic 은 이것을 지원 합니다.

새로운 도메인 생성을 위해서 1번을 선택합니다.

도메인 생성을 위한 기존의 템플릿이나 필요한 컴포넌트 선택하는 것으로 여기서는 1번을 선택합니다.

필요한 기능을 갖춘 도메인을 선택한다. 기본 WebLogic 서버 기능만 힜으면 됨으로 나머지 선택을 하지 않고 그냥 엔터

사용할 도메인 이름을 입력하고 엔터.

여기가 중요하다. 앞전에 설치를 위한 디렉토리 생성시에 도메인을 위한 디렉토리를 다음과 같이 만들어준적이 있다.

  • /u01/app/weblogic/config/domains

따라서 도메인 디렉토리를 위 디렉토리로 변경해준다.

WebLogic 의 관리자 계정을 생성한다. 2번과 3번을 선택해 패스워드를 지정해준다.

운영모드 선택이다. 자신에게 맞는 환경을 선택한다.

설치된 자바를 선택해주면 된다.

여기서 반드시 Administration Server 는 해주도록 하자. 관리자 서버를 실행해야 웹콘솔 접속이 가능하지고 모든 작업이 웹콘솔을 통해서 가능하게 된다.

Administration 서버 설정으로 필요한 부분, port 나 Listen address 등을 바꿔주면 된다.

이로서 도메인 생성이 완료되었다.

WebLogic 을 비록한 Oracle 제품군을 설치할때에 GUI 모드를 고집하는 경향이 있다. 하지만 GUI 모드 설치를 위해서는 GUI 를 위한 각종 프로그램들을 설치해야하고 느린 네트워크 환경에서는 설치가 수월하게 되지 않는다.

Silent 모드 설치와 Console 모드에서 도메인 생성은 간편하면서도 의존성이 없는 텍스트만으로 이루어짐으로 어떤 환경에서든지 활용이 가능하며 쉽다.

Managed Server 인증 기동

WebLogic Admin 을 세팅하고 웹 콘솔로 접속한 후에 서버를 하나 생성하면 Managed Server 가 생성되는 것입니다. 이를 기동하기 위해서 터미널에서 다음과 같이 해줍니다.

그런데, 위와같이 인증을 위한 프롬프트가 나옵니다. 이는 Admin 서버와 통신을 위한 것으로 Admin 웹 콘솔 로그인을 위한 계정을 입력해주면 됩니다.

하지만 매번 이렇게 할려면 매우 힘든 일이고 기동 스크립트는 자동화가 필요한 부분이라 이부분을 자동인증으로 하기 위한 방법을 설명합니다. 이 방법은 다음 링크에도 잘 기술되어 있습니다.

Managed Server 마다 boot.properties 파일을 생성해 다음과 같이 로그인 정보를 적어 줍니다.

텍스트 파일로 작성해서 저장하는데, Managed Server 를 기동하면 이게 암호화가 되기 때문에 보안에 아무런 문제가 없습니다.

Java 동작모드 바꾸기

아무런 설정 없이 WebLogic 서버들을 시작하면, 다음과 같은 JVM_OPTION 들이 보입니다.

-client 모드로 기동이 되는데 이를 -server 로 바꾸어야 합니다. Java 의 동작 모드는 지속적인 서비스를 위해서는 -server 가 적합 합니다. WebLogic 에서 이를 바꾸기 위해서는 다음과 같이 고쳐줍니다.

WebLogic 구동 시 /dev/random 블로킹 이슈 해결

이것을 해주지 않으면 구동시간이 아주 길어 집니다. 방법은 여러가지가 있지만 여기서는 전역환경변수에서 이것을 수정함으로써 해결 합니다.

위와같이 JAVA_OPTIONS 환경변수에 지정해줍니다.

 

Apache 2.4 에서 RemoteIPInternalProxy 의미

Apache 2.4 에서 RemoteIPInternalProxy 는 다음과 같이 사용합니다.

이 문법을 X-Forwared-For 와 함께 사용하면 다음과 같다.

X-Forwarded-For 는 원격지 주소를 192.0.2.1 이 된다. 그런데 RemoteIPInternalProxy 의 영향으로 인해서 192.0.2.1 은 내부 Proxy 로 지정되었기 때문에 X-Forwarded-For 의 원격지 주소는 198.51.100.2 가 된다.

ps, X-Forwarded-For 는 여러개의 IP를 기록할 수 있다. 만일 여러개를 기록할 경우에 맨 오른쪽에 IP가 최종 원격지 IP 주소가 된다.

UBUNTU 14.04 KVM 게스트에 콘솔 접속하기

KVM 가상화를 사용하고 있고 게스트로 Ubuntu14.04 를 사용하고 있다면 콘솔 접속을 위해서는 다음과 같이 해주어야 한다.

ttyS0 터미널 설정

KVM 게스트인 Ubuntu14.04 에 콘솔로 접속하기 위해서는 게스트 Ubuntu14.04 에 ttyS0 터미널로 접속을 해야 한다. 그런데 Ubuntu 14.04 에는 ttyS0 터미널 설정이 되어 있지 않아 이를 설정을 해야 한다.

/etc/init/ttyS0.conf 파일을 다음과 같이 생성한다.

 

그리고 다음과 같이 /etc/securetty 파일에 ttyS0 를 추가 해준다.

 

/etc/default/grub 편집

이제 grub 에서 ttyS0 이 콘솔 접속이 되도록 다음과 같이 편접해 준다.

위와같이 편접을 한 후에 grub 을 다시 시작해 줍니다.

 

위와같이 설정을 하고 재부팅을 한 후에 KVM 콘솔 접속을 하면 아주 잘 됩니다.

 

Apache Proxy Load Balancer 구성

Apache 웹 서버는 세계적으로 많이 사용되는 웹 서버이다. 많은 기능을 내장하고 있는데, 그 중에서 Proxy Load Balancer 구성에 대해서 설치부터 설정까지 기술 한다.

기술 환경은 다음과 같다.

  • 배포판: Ubuntu14.04 64bit
  • Apache: 2.4.25
  • 컴파일 설치.

운영환경도 아주 중요하다. 이 문서에서 기술한 운영 환경은 AWS 환경이며 External ELB 바로 뒤에 Apache 웹 서버가 있다. 이 Apache 웹 서버는 뒤에 WAS 서버가 존재하는 환경이다.

Apache Proxy Load Balancer 운영 환경

의존성 패키지 설치

컴파일 설치를 하기전에 의존성 패키지를 다음과 같이 설치해 줍니다.

 

설치

설치는 소스를 받아 직접 컴파일을 했다. 소스는 현재 최신버전인 2.4.25 버전으로 다운받아 압축 해제한다.

Apache 웹 서버의 확장 모듈을 설치하거나 별도의 유틸리티를 사용하기 위해서 apr, apr-utils 도 함께 설치해주어야 한다. 이 기능을 사용하기 위해서는 컴파일 시에 ‘–with-included-apr’ 옵션을 주어야 한다.

이제 다음과 같이 Configure 해줍니다.

아무런 오류 없이 끝나면 다음과 같이 컴파일, 설치 해줍니다.

설치 디렉토리로 이동해서 다음과 같이 심볼릭 링크를 생성해 줍니다.

 

httpd.conf 설정

Apache 웹 서버의 주요 설정은 httpd.conf 파일에서 이루어 집니다. 웹 서버이름, 실행할 데몬 소유자, 로깅, 사용할 모듈, 사용할 기능파일등에 대해서 설정할 수 있습니다.

사용할 모듈 설정

컴파일 설치를 했어도 사용할 모듈들을 최소화할 수 있습니다. 다음과 같이 해줍니다.

어떤 기능을 사용할 것인지에 따라서 위 설정은 달라지지만, 적어도 Proxy Load Balancer 를 운영하기 위해 필요한 것과 불필요한 것만 위에서 기술 했다.

현재 활성화된 모듈이 무엇인지는 다음의 명령어로 확인 가능하다.

 

데몬 사용자/그룹 지정

Apache 웹 서버는 실행 프로세스와 HTTP 를 처리하는 데몬의 사용자/그룹를 다르게 지정할 수 있다. mod_unixd 에서 제공하는 것으로 다음과 같이 지정할 수 있다.

RemoteIp 사용 설정

Apache 웹 서버 앞에 AWS ELB 가 있다. AWS 의 ELB 는 Client IP 를 ‘X-Forwarded-IP’ 헤더에 담아 뒤로 넘겨준다. 하지만 Apache 웹 서버는 이것이 Client IP 인지를 인식하지 못하는데, ‘X-Forwarded-IP’ 헤더 필드 값이 실제 IP 로 사용하도록 지정할 수 있는데 mod_remoteip 가 이를 담당 한다. 다음과 같이 설정해 준다.

이렇게 설정을 해주면 이제부터 Apache 내부에서 사용하던 Client IP 관련 환경변수들이 ‘X-Forwarded-For’ 값으로 대체(override)된다. 바꿔말해서 Client IP 관련 환경 변수들을 하나하나 찾아서 ‘X-Forwarded-For’ 값으로 대체하지 않아도 된다.

log 설정

mod_remoteip 를 사용할 경우에 Apache 웹 서버의 로그에 Client IP 가 기록되도록 다음과 같이 추가해 준다.

기준의 combined 로그 포맷을 이용해 ‘%h’ -> ‘%a’, ‘%b’->’%O’ 로 교체해주고 ‘proxy_combined’ 이름의 로그 포맷을 정의했다.

추가 설정

Apache 웹 서버는 기능별로 설정들을 따로 모아서 conf/extra 디렉토리에 모아 뒀다. 필요한 기능과 설정을 하고 싶다면 이 파일들을 수정하고 httpd.conf 파일에서 Include 명령어로 포함시켜주면 동작한다.

주요하게 포함되어지는 파일들은 다음과 같다.

 

httpd-mpm.conf

Apache 웹 서버의 프로세스 모델을 설정하는 파일이다. Apache 2.4 에서는 주요하게 세가지를 제공 한다.

  • event (2.4 기본)
  • profork
  • worker

event 프로세스 모델은 ‘mpm_event_module’ 을 이용해서 설정 가능하며 httpd-mpm.conf 파일 중간쯤에 있다.

모델별로 동작 방법은 다르지만 설정하는 내용은 비슷하다. 대부분이 초기 프로세스 개수, 최소, 최대 쓰레드(Thread) 개수, 한 쓰레드당 최대 worker 등을 지정하는 식이다.

이 값은 얼마만큼 Apache 웹 서버가 일하는지에 따라서 달리 설정되어 진다. 이 값은 서비스 오픈전 부하 테스트를 거쳐서 확정된다.

httpd-default.conf

이 설정은 매우 중요하다. 특히나 AWS ELB 뒤에 Apache 웹 서버를 운영중이라면 아주 중요하다.

여기에서 reqtimeout_module 부분을 수정하지 않으면 아마도 로그에  ‘ELB-HealthChecker/1.0’ 요청에 대해서 408 을 리턴하는 것을 볼 수 있다.

이는 httpd-default.conf 파일에서 다음을 수정해줘야 한다.

이렇게 해야 하는 이유는 AWS ELB 의 Health Checker 가 Apache 웹 서버의 Alive 를 알아내기 위해서 패킷을 보내는데, AWS ELB 의 기본 Idle 값(60)보다 크게 잡아야 하기 때문이다.

위와같이 설정하면 408 오류는 보이지 않게 된다.

httpd-vhosts.conf 

Proxy Load Balancer 설정

Proxy Load Balancer 설정을 위해서는 Proxy 설정을 먼저 알아야 한다. Apache 웹 서버의 Proxy 설정은 다음과 같다.

Proxy 는 ReverseProxy 로 동작하게 하면서 Load Balancer 를 지정하고 있다. URL 이 /adm 으로 들어올 경우에 위 설정을 따르게 되고 Load Balancer 로 연결이 된다.

Load Balancer 설정에서는 Balancer 를 위한 서버의 Member 를 등록한다. route 는 Sticky Session 부분과 관련이 있으며 Tomcat의 jvmRoute 파라메터에서 사용되어지기도 해서 WAS 서버 설정과 관련이 있다.

그러나 WAS 서버에서 Session Cluster 설정을 했다면 route 는 그냥 WAS 서버의 호출 주소를 적어줘도 된다.

CustomLog 설정

CustomLog 설정에서 rotatelogs 시에 파일명을 날짜별로 되도록 다음과 같이 수정한다.

 

지금까지 Apache 2.4 에서 기초적인 Reverse Proxy 설정을 기술했다. 기본적인 설정일뿐이며 이를 기반으로 다양한 기능들을 추가하면 된다. 추가적인 기능으로는 CustomLog 에서 파일형태(그림파일), URI 별로 쪼개서 로깅하기 혹은 IP 를 기반으로 차단하기, 이미지 파일 캐싱하기 등등이 있다.

KVM에 Bridge Network 설정

CentOS 6 에는 가상화로 KVM만 지원합니다. Xen은 빼버렸습니다. 가상화로 KVM을 하게되면 사용할 수 있게됩니다. 그런데, KVM을 활성화하게 되면 virbr0 라는 가상의 이더넷이 생성이되는데 이것이 NAT로 동작하게 됩니다. 그러니까 KVM의 게스트들은 virbr0 의 NAT를 이용해서 인터넷을 하게 되는 것입니다.

그런데 제가 집에서 사용하는 인터넷 사용환경은 공유기를 이용해서 각 피시에서 private ip 주소를 할당해서 사용합니다. 그래서 KVM의 게스트들도 직접 공유기로 부터 private ip 주소를 할당 받기를 원했습니다. 그렇게 하기위해서는 virbr0 를 NAT를 정지시키고 br0 을 만들어서 eth0와 br0를 Bridged 시키면 됩니다.

이 문서는 이것을 설명한 것입니다.

처음 KVM을 설치해서 보면 다음과 같이 나옵니다. NAT로 동작하고 있다는 증거입니다.

Bridged 로 바꿔보겠습니다. 절차는 다음과 같습니다.

  1. virbr0 를 지웁니다.
  2. eth0 에 dhcp 기능을 지우고 br0 로 Bridged 한다.
  3. br0 만드는데, dhcp 로 아이피를 새로 받도록 한다. TYPE 를 Bridged 로 해준다.

Virbr0 를 지운다. 

버추얼쉘(virsh) 명령어를 이용해 네트워크 리스트를 봅니다.

버추얼 네트워크 이름이 ‘default’로 나오네요. 이것을 지우겠습니다.

eth0 의 dhcp 를 지우고 br0 로 Bridged 한다.

다음과 같이 합니다.

br0 를 만든다.

다음과 같이 합니다.

위과정을 거치면 설정은 끝납니다. 한가지 더 있는데, 리눅스의 NetworkManager 데몬을 꺼주고 network 서비스를 다시 올려줍니다.

이제 virt-manager 로 KVM 게스트를 설치할 다음과 같이 이더넷을 설정해 주면 됩니다.

Virt-Manager 에서 Br0 설정

 

Apache 2.4 환경변수를 이용한 로그 남기기 – mod_setenvif

Apache 2.4 에서 로그를 남기는 다양한 방법이 있는데, mod_setenvif 모듈을 이용하면 다양한 조건에 부합한 것만 로그를 남길 수 있다.

위 예제는 access.2017-04-13.log 파일에 로깅을 하는데 combinedio 로 정의된 로그 포맷대로 기록하며 86400(1day) 하루에 한번 로그 로테이션을 하도록 설정한 것이다.

그런데, 만일 기록되어지는 로그중에 특정 형식의 URI 로 시작하는 경우에 별도의 로그 파일에 기록하고 싶다면 어떻게 해야할까?

위 처럼 /wp-admin 으로 시작하는 URI 를 별도 파일로 기록하고 싶다면 다음과 같이 하면 된다.

위와같이 mod_setenvif 모듈이 제공하는 SetEnvIfNoCase 문을 이용해 URI 에 형태를 정규표현식을 이용해 매칭시키고 이것을 변수로 등록한다. 그리고 CustomLog 를 하나 더 추가해 ‘combinedio env=object_is_admin’ 처럼 환경변수를 인식 시켜준다.

위와같이 하면 access_wp_admin.%Y-%m-%d.log 파일에는 /wp-admin 으로 시작하는 URI 에 대해서만 기록하게 된다.

한가지 주의할 것은 기존의 access.%Y-%m-%d.log 파일에도 여전히 /wp-admin 으로 시작하는 URI 도 함께 기록된다는 것이다. 이를 피하기 위해서 다음과 같이 지정해줄 수 있다.

access.%Y-%m-%d.log 에는 ‘combinedio env=!object_is_admin’ 을 적용함으로써 /wp-admin 으로 시작하는 URI 는 기록하지 못하도록 했다.

그런데, 만일 두가지 환경변수를 함꺼번에 적용하고 싶다면 어떻게 해야 할까?

두가지의 환경 변수를 정의했을 경우에 이 두가지를 한꺼번에 정의하기 위해서는 env 를 쓸수가 없다. env 는 OR 연산자를 제공하지 않았다. 다음의 경우

위와 같이 할 경우에 configtest 는 통과하고 재시작도 아주 잘되지만 적용되지 않는다.

이럴때는 변수 선언을 key=value 형식으로 바꾸고 CustomLog 에는 expr 를 사용해야 한다.

위와같이 expr 를 사용해 AND, OR 연산을 이용할 수 있다.

참고: How to impose two conditions at once for Apache CustomLog?

Nginx 이용한 로드 밸런싱(Load Balancing) 구현하기

Nginx 는 전세계적으로 인기있는 웹 서버 입니다. 기존 웹 서버들과 달리 고속이며 대량의 접속을 적은 자원으로 처리해줍니다. 또, Nginx 는 Reverse Proxy 기능도 아주 훌륭하게 수행하며 이에 더해서 로드밸런싱 기능도 제공하는듯 다양한 기능을 다른 웹서버들보다 훌륭하게 수행합니다.

아키텍쳐(Architecture)

먼저 다음과 같은 아키텍쳐를 생각해 봅시다.

Nginx 로드 밸런싱 아키텍쳐

AWS 에 흔히 볼수 있는 기본적인 아키텍쳐입니다. 외부 접속은 External ELB가 담당하고 이것을 뒤에 Nginx 서버가 ELB의 접속을 받아서 Nginx 뒤에 있는 Jboss EAP 서버에 분배 접속을 하도록 하는 것입니다.

Nginx 로드 밸런싱(Load Balancing)

Nginx 는 자체적으로 로드 밸런싱 기능을 제공합니다. 이는 Nginx 의 Upstream 모듈을 통해서 제공 합니다. 기본적인 설정 방법은 다음과 같습니다.

ELB 에서 Nginx 로 80 포트(port)로 접속을하면 proxy_pass 에 정의된 upstream 인 myapp1 으로 연결을 시켜주며 myapp1 upstream 에 정의된 서버 3대 중에 하나에 연결을 시켜줍니다.

upstream 에서 다양한 옵션을 제공 합니다. 대표적인 것이 Nginx 뒤에 서버의 연결 상태를 어떻게 체크할 것인가 하는 것입니다. 예를들면,

srv1.example.com 서버는 30초 동안 최대 3번 접속이 실패하면 30초 동안 접속이 불가한 것으로 판단 합니다. 30초가 지나면 또 최대 3번의 접속 실패가 발생하고 나서야 30초동안 접속을 하지 않습니다.

지속적인 서비스를 제공해야하는 상황에서 접속이 잘되는지 안되는지 실제로 접속을 해봐야만 한다면 고객들에게 불편을 제공할 것입니다.

AWS ELB 방식

AWS ELB 방식은 위 Nginx 의 max_fails 방법과는 다릅니다. ELB 는 뒤에 연결되는 인스턴스(Instance)가 살았는지 죽었는지를 판단하는 Health Check 기능을 제공합니다. 이것은 5초에 한번 Health Check 를 하고 10번이상 성공했다면 인스턴스가 살았다라고 판단해(InService 상태) 연결을 활성화 해줍니다. 만일 5초에 한번 Health Check 를 하는데 2번 실패를 했다면 인스턴스가 죽었다고 판단해(OutOfService 상태) 더 이상 연결을 시도하지 않습니다.

즉, 일정한 기준을 만족해야만 연결을 활성화 해준다는 겁니다. Nginx 에서도 이렇게 동작하면 얼마나 좋을까?

nginx_http_upstream_check_module

nginx_http_upstream_check_module 모듈은 Nginx.org 에서 배포하지 않고 개인 개발자가 개발한 Third Party 모듈 입니다. 이 모듈은 앞에서 언급했던 ELB 의 Health Check 기능을 제공해 줍니다. 특정한 기준을 통과하면 연결을 활성화 시켜주는 것입니다.

이를 활용하기 위해서는 Nginx 설치시에 같이 컴파일 설치를 해줘야 합니다.

Nginx 설치

이번 Nginx 설치는 Upstream Health Check Module 를 함께 설치하는 과정을 포함 합니다.

설치 환경은 다음과 같습니다.

  • Ubuntu 14.04 64bit
  • 컴파일을 위해서 설치한 패키지들: build-essential, automake, unzip, patch, libpcre++-dev, zlib1g-dev, geoip-bin, libgeoip-dev

Nginx 다운로드를 해줍니다.

nginx_http_upstream_check_module 는 git를 이용해서 다운(?) 받습니다.

이제 Nginx 에 nginx_http_upstream_check_module 다음과 패치를 해줍니다.

그리고 다음과 같이 서버 Signiture 를 바꿔 줍니다.

이렇게하면 서버가 PowerServer/1.0 이라고 나와서 Nginx 를 쓴다는것을 숨길 수가 있습니다.

마지막으로 openssl 최신 소스를 다운받아 nginx 디렉토리에 놓습니다.

 

Nginx 설정하기

설치가 끝났다면 이제 설정을 해야 합니다. 설정에 앞서서 현재 Nginx 의 아키텍쳐를 상기시켜봅시다.

  • Nginx 앞에는 AWS ELB 에 있다. AWS ELB 는 실제 접속자인 Client IP 를 ‘X-Forewarded-For’ 헤더값에 저장해 넘겨준다.
  • Nginx 뒤에는 두대의 WAS 서버가 존재한다.
  • Nginx 는 뒤에 두대의 WAS 에 대해서 Health Check 하고 특정값 기준으로 Alive/Down 을 결정하도록 한다.

위 내용을 설정에 반영하면 다음과 같습니다.

먼저 7번째 줄에 Nginx 에서 실제 IP를 ‘X-Forewarded-For’ 헤더 값이라고 알려 주도록 설정한 것입니다. 8번째 줄은 AWS ELB 의 주소 범위를 말합니다. Nginx 는 AWS ELB 로부터 접속을 받기 때문에 그것을 지정해줄 필요가 있는데 그것이 바로 8줄 설정입니다. 12줄 ~ 14줄은 뒤에 WAS 서버에 넘겨줄 헤더값을 지정해주고 있습니다. WAS 서버도 실제 Client IP가 필요하기 때문에 이것을 ‘X-Forewarded-For’ 에 지정해 줍니다. 그외에 ‘X-Forewarded-Server’, ‘X-Forewarded-Host’ 도 지정해 줍니다.

18번째 줄부터는 이제 upstream 설정하는 부분인데, 24줄이 Health Checker 를 해주는 부분으로 nginx_http_upstream_check_module 기능 입니다. 3초에 한번 체크를 하는데 그 방법은 TCP를 이용하고 5번 연속으로 실패할 경우에 뒤에 서버는 다운된것으로 하고 2번 연속 성공하면 뒤에 서버가 살아있는것으로 해서 연결을 시켜줍니다. 마치 AWS ELB 처럼 동작하는 것입니다.

/status URL 을 호출하면 다음과 같이 나옵니다.

Nginx Upstream Health Status
Rise Counts, Fall counts 는 3초마다 체크해서 그 수를 센 것입니다. 현재 뒤에 WAS 서버들이 하나는 살아 있고, 하나는 죽은것으로 되어 있고 Down 된 서버는 빨강색으로 표시됩니다.

체크하난 프로토콜을 변경할 수 있는데, http 를 이용할 경우에 보내는 url 과 기대되는 리턴되는 http 의 상태값(status)를 지정해주면 됩니다.

WebLogic 11g 기동시 JAVA OPTION 넣기

WebLogic 11g 기동시 JAVA OPTION 넣기위해서 setDomainEnv.sh 나 commonEnv.sh 를 수정하는 경우가 있다. 하지만 이렇게 하면 WebLogic 11g 를 구성하는 Admin, NodeManager, ManagedServer 에 각각 따로따로 적용해주기위해서 앞에서 언급한 쉘 스크립트에 조건식을 줘야 한다.

setDomainEnv.sh 나 commonEnv.sh 는 WebLogic 서버에서 전역적으로 사용하는 것이기 때문에 특정한 부분을 위해서 수정하는 경우는 지양해야 한다.

최신의 WebLogic 11g 에서는 이러한 특정부분만을 위해 적용할 수 있는 JAVA OPTION 변수를 제공하는데 그것이 바로 USER_MEM_ARGS 이다. 쉘 환경변수로서 이것을 활용하면 Admin, NodeManager, ManagedServer 기동시에 JAVA OPTION을 줄 수 있다.

예를들어 Admin 서버를 기동할때에 사용하는 스크립트인 ${DOMAIN_HOME}/startWebLogic.sh 를 보자.

위와 같이 USER_MEM_ARGS 환경변수에 JAVA OPTION 값을 지정하면 WebLogic 이 구동시에 이것을 반영하게 된다.

ManagedServer 기동시에도 마찬가지다. 보통 ManagedServer 기동은 다음과 같이 한다.

하지만 이렇게하면 JAVA OPTION을 제공할 수가 없다. Server-0 로 불리우는 ManagedServer 기동을 위해서 일종의 랩퍼 스크립트를 다음과 같이 작성해보자.

위와같이 USER_MEM_ARGS 쉘 환경변수에 JAVA OPTION 값을 지정하면 이것을 반영하하여 Server-0 는 기동하게 된다.