잡동사니 IT 저장소

개요

이번 글에서는 윈도우 서비스의 실행 파일 경로를 수정하는 방법에 대하여 설명한다.

여기서 실행 파일 경로란 서비스를 더블 클릭 했을 때 아래와 같이 나오는 부분이다.

서비스를 등록하고 나면 해당 화면에서는 경로를 수정할 수 없기 때문에 다른 방법으로 수정해야 한다.

sc 명령어를 통하여 수정할 수도 있지만 이 글에서는 간단하게 레지스트리 편집기를 사용하는 방법을 설명한다.

레지스트리 편집기

먼저 실행(Win + R)창에서 regedit 을 입력하여 레지스트리 편집기를 실행한다.

왼쪽 트리에서 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\서비스명 을 클릭하면 아래와 같이

값들이 나오는데, 여기서 ImagePath의 값을 수정하면 된다.

ImagePath의 값을 수정하고 서비스를 재시작하면 수정된 경로로 적용되어 시작되는 것을 확인할 수 있다.

개요

이번 글에서는 Apache HTTPD와 Tomcat 간의 세션 클러스터링 방법에 대해서 설명한다.

세션 클러스터링은 Web과 연동된 여러대의 Tomcat을 클러스터링하여 세션을 공유하는 기법이다. 

세션 클러스터링 시, Tomcat A의 사용자가 Tomcat B로 연결되어도 A에서 생성한 세션을 그대로 이어받을 수 있다.

L4 장비가 없는 로컬 환경에서 진행되므로 이번 글에서는 하나의 Apache에 2대의 톰캣을 연결한다.

연동 환경은 다음과 같다.

- OS : CentOS 6.7

- Apache Version : Apache 2.4.41

- Tomcat Version : Apache Tomcat 9.0.30

- Connector Version : JK 1.2.48

연동 전 준비사항

설정 방법은 이전 로드밸런싱 글에 나온 세팅을 그대로 사용한다.

https://itwarehouses.tistory.com/12?category=727632

Tomcat 설정 전 준비사항

1. Tomcat Session Clustering 간 Multicast를 위한 라우팅 설정이 필요하다.

위와 같이 라우팅 설정이 되어있지 않으면 해당 명령어로 주소를 추가하자.

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0(디바이스명)

2. Session Clustering에 사용되는 포트를 방화벽에서 허가해줘야 한다.

CentOS 6의 경우에는 vi /etc/sysconfig/iptables 로 아래의 내용을 추가하고 service iptables restart 실행

-A INPUT -m state --state NEW -m tcp -p tcp --dport 45564 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 45564 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 4000:4100 -j ACCEPT

CentOS 7의 경우에는 아래의 명령어를 실행한다.

firewall-cmd --permanent --zone=public --add-port=45564/tcp
firewall-cmd --permanent --zone=public --add-port=45564/udp
firewall-cmd --permanent --zone=public --add-port=4000-4100/tcp
firewall-cmd --reload

3. Apache workers.properties 파일에서 Sticky Session이 활성 되어있는지 확인한다.

기본값이 TRUE이기 때문에 아래와 같이 반드시 명시할 필요는 없다. 

false 또는 0 으로 되어있을 경우 true 또는 1로 변경한다.

Tomcat 관련 설정

Tomcat에서 설정해야할 부분은 총 3곳이다.

1. server.xml <Engine> 내 jvmRoute 요소 설정

위의 workers.properties 파일에서 로드밸런싱할 톰캣의 이름을 각각 worker1, worker2로 설정했었다.

각각의 Tomcat 서버에 jvmRoute 값을 worker1, worker2로 설정한다.

jvmRoute 값은 각 Tomcat 인스턴스의 라우팅 식별자로 사용되며, 설정 시 아래와 같이 세션 ID 값에 xxxxxx.${jvmRoute} 로 추가되어 표시된다.

2. server.xml <Host> 하위에 <Cluster> 설정

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                 channelSendOptions="8">

          <Manager className="org.apache.catalina.ha.session.DeltaManager"
                   expireSessionsOnShutdown="false"
                   notifyListenersOnReplication="true"/>

          <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Membership className="org.apache.catalina.tribes.membership.McastService"
                        address="228.0.0.4"
                        port="45564"
                        frequency="500"
                        dropTime="3000"/>
            <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                      address="auto"
                      port="4000"
                      autoBind="100"
                      selectorTimeout="5000"
                      maxThreads="6"/>

            <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
              <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
            </Sender>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
          </Channel>

          <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
                 filter=""/>
          <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

          <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
                    tempDir="/tmp/war-temp/"
                    deployDir="/tmp/war-deploy/"
                    watchDir="/tmp/war-listen/"
                    watchEnabled="false"/>

          <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
        </Cluster>

<Receiver> 내의 address 값에 ip 값을 입력하고, 같은 서버에서 여러대의 Tomcat이 동작할 경우 port의 값도 각각 다르게 설정해야 한다.

3. 어플리케이션 디렉터리 WEB-INF/web.xml에 <distributable /> 태그를 삽입한다.

Tomcat Documentation에 따르면 <distrubutable />이 하는 역할은 다음과 같다.

The <Manager> element defined inside the <Cluster> element is the template defined for all web applications that are marked <distributable/> in their web.xml file. However, you can still override the manager implementation on a per web application basis, by putting the <Manager> inside the <Context> element either in the context.xml file or the server.xml file.

web.xml에 <distrubutable />이 설정된 모든 어플리케이션이 server.xml에 설정한 <Manager> 설정대로 관리되는 듯 하다.

테스트

정상적으로 세션 클러스터링이 설정되었을 경우 테스트 방법은 아래와 같다.

1. Tomcat A, B 기동

2. Tomcat A 또는 B에서 처음으로 세션이 생성됨

3. 세션이 생성된 서버를 Shutdown

4. 나머지 서버의 세션 값이 처음 생성된 세션 값과 동일하면 설정 완료

1. Tomcat A, B 기동

2. Tomcat A 또는 B에서 세션 생성 확인 (Tomcat A에서 세션이 생성)

세션 값을 확인하는 방법은 여러가지가 있으나 여기서는 Chrome 브라우저의 개발자도구를 사용하였음.

3. 세션이 생성된 서버를 Shutdown(Tomcat A)

4. 나머지 서버(Tomcat B)의 세션 값이 처음 생성된 세션 값과 동일한지 확인

세션 값이 1EF398C1540F9380C4163C2F6062171F.worker1 으로 동일한 것을 확인할 수 있다.

만약 Session Clustering이 설정되지 않았다면 xxxxxxxx.worker2로 세션 값이 설정되었을 것이다.

개요

이번 글에서는 Apache HTTPD와 Tomcat 간의 로드밸런싱 방법에 대해서 설명한다.

로드밸런싱은 고가용성을 위해 Apache와 Tomcat을 1:N 또는 N:N 방식으로 연결하여 Request를 분산 처리하며,

하나의 톰캣이 서비스를 중단해도 다른 톰캣이 바로 연결을 이어받을 수 있다.

L4 장비가 없는 로컬 환경에서 진행되므로 이번 글에서는 하나의 Apache에 2대의 톰캣을 연결한다.

연동 환경은 다음과 같다.

- OS : CentOS 6.7

- Apache Version : Apache 2.4.41

- Tomcat Version : Apache Tomcat 9.0.30

- Connector Version : JK 1.2.48

연동 전 준비사항

설정 방법은 이전 글에 나온 세팅을 그대로 사용한다.

https://itwarehouses.tistory.com/11?category=727632

workers.properties 파일 수정

또다른 Tomcat의 정보를 추가해야 하므로 workers.properties 파일의 내용을 아래와 같이 수정한다.

httpd.conf 파일 수정

요청을 workers.properties에서 설정한 로드 밸런서의 별칭으로 전송하기 위해 httpd.conf 파일의 아래 내용을 수정한다.

테스트

테스트를 위해 Tomcat1의 화면에는 This is Tomcat 1,

                   Tomcat2의 화면에는 This is Tomcat 2 가 표시되도록 설정하였다.

브라우저 창에 서버 IP를 입력하고 계속 새로고침을 눌러보자.

위와 같이 Tomcat1, Tomcat2의 인덱스 화면이 바뀌면서 출력되는 것을 확인할 수 있다.

httpd.conf 파일의 mod_jk 설정 부분에 아래의 설정을 추가하면 로그로도 확인할 수 있다.

JkRequestLogFormat "%w %R %V %T %U %q"

Apache logs 디렉터리의 mod_jk.log 파일 내용에 request 처리 내역이 추가된다.

이로써 Apache HTTPD와 Tomcat을 연동하고 로드 밸런싱 하는 방법에 대해서 알아보았다.

다음 글에는 Apache HTTPD - Tomcat 간의 세션 클러스터링 방법에 대해서 작성하겠다.

개요

이번 글에서는 오픈소스 WEB/WAS의 대표 주자인 Apache HTTPD와 Apache Tomcat을 연동하는 방법을 설명한다.

Apache와 Tomcat이 설치되어있다는 전제 하에 진행되므로 미리 설치를 해놓자.

연동 환경은 다음과 같다.

- OS : CentOS 6.7

- Apache Version : Apache 2.4.41

- Tomcat Version : Apache Tomcat 9.0.30

- Connector Version : JK 1.2.48

연동 전 준비사항

Apache와 Tomcat을 연동하기 위해서는 전용 모듈인 mod_jk 모듈이 필요하다.

해당 모듈은 아래의 경로에서 받을 수 있다.

리눅스 기반에서 진행되므로 tar.gz로 압축된 파일을 받자.

https://tomcat.apache.org/download-connectors.cgi

mod_jk 컴파일

다운로드한 tomcat connector 1.2.48 파일의 압축을 해제하고 생성된 디렉터리안의 native 디렉터리로 이동한다.

해당 위치에서 아래의 명령을 실행한다.

./configure --with-apxs=아파치설치경로/bin/apxs

필자의 경우에는 ./configure --with-apxs=/apache24/bin/apxs 였다.

Configure 후 make && make install 명령을 통해 컴파일을 마무리한다.

컴파일 후 mod_jk.so 모듈이 생성되었는지 확인하려면 Apache 설치 경로의 modules 디렉터리를 확인한다.

workers.properties 파일 생성

httpd.conf를 설정하기 전에 먼저 workers.properties 파일을 생성해야 한다.

workers.properties는 Apache와 연동할 Tomcat의 정보 및 관련 파라미터 값을 설정하는 파일이다.

아파치설치경로/conf 디렉터리에 vi workers.properties 명령으로 파일을 생성하고 아래의 내용을 입력한다.

httpd.conf 설정 추가

httpd.conf 파일 하단에 아래의 내용을 추가한다.

LoadModule jk_module modules/mod_jk.so

-> mod_jk.so 모듈을 사용하기위해 적재

<IfModule jk_module>

</IfModule>

->  jk_module이 적재되어 있는 동안에만 해당 설정을 적용

JkWorkersFile conf/workers.properties

위에서 생성한 workers.properties 파일의 경로를 설정

JkLogFile logs/mod_jk.log

연동에 관련된 로그파일이 생성될 경로를 설정

JkLogLevel info

로그 파일의 레벨을 설정

JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"

로그 내용의 각 라인 앞에 찍히는 스탬프의 형식을 설정

JkMount /* worker1

Apache HTTPD로 들어오는 요청을 worker1로 전송

연동 테스트

현재 Apache HTTPD는 80, Tomcat은 8080 포트를 사용 중이다.

정상적으로 연동되었다면 80번 포트로 접속 시 Apache가 8009번 포트를 통해 Tomcat으로 Request를 전달한다.

웹브라우저에 서버 IP를 입력하여 접속해보자.

IP에 :8080을 붙이지 않고 80번 포트로 접속했을 때 Tomcat의 기본 인덱스 화면이 표시되는 것을 볼 수 있다.

이로써 Apache HTTPD와 Apache Tomcat을 연동하는 방법에 대해서 알아보았다.

IMDG Platforms

Hazelcast IMDG

Infinispan

EHCACHE

SCALEOUT STATESERVER

RED HAT JBOSS DATA GRID

GRIDGAIN ENTERPRISE EDITION

WEBSPHERE EXTREME SCALE

ORACLE COHERENCE

IBM WEBSPHERE APPLICATION SERVER

TERRACOTTA ENTERPRISE SUITE

출처

Top 15 In Memory Data Grid Platform : https://www.predictiveanalyticstoday.com/top-memory-data-grid-applications/

IMDG란?

In-Memory Data Grid(IMDG)는 RAM(Random Access Memory)에 상주하는 데이터 구조로, 여러 서버에 분산되어 존재한다. 최근의 64비트 및 멀티 코어 시스템의 발전으로 하드 디스크와 같은 전기 기계식 대용량 저장 매체의 필요 없이 수 테라바이트의 데이터를 RAM에 완전히 저장하는 것이 실용화되었다.

업계 분석 회사인 Gartner Inc.에 따르면 IMDG는 속도(velocity), 가변성(variability) 및 용량(volume)과 같은 빅 데이터의 “Big-Three V’s”를 처리하는데 적합하다고 한다. IMDG는 초당 수십만 건의 메모리 내 데이터 업데이트를 지원하며 대량의 데이터를 지원하는 방식으로 클러스터링하고 확장할 수 있다.

IMDG의 구조

어플리케이션 서버(AS)에는 IMDG가 제공하는 클라이언트 라이브러리가 있고, 이 라이브러리를 이용해 IMDG에 접근한다. IMDG에서 사용하는 데이터 모델은 Key-Value 모델이며 키를 이용해 데이터를 분산시켜 저장할 수 있다.

IMDG의 특징 및 장단점

• 데이터가 여러 서버에 분산되어 저장된다.
• 각 서버는 active 모드로 동작한다.
• 데이터 모델은 보통 객체 지향형(serialize)이고 non-relational이다.
• 필요에 따라 서버를 추가하거나 줄일 수 있는 경우가 많다.
• 테이블과 같은 전통적인 데이터베이스 특징이 아니다.
• Lock, Transaction, Sharding을 지원한다.

장점

• 하드 디스크로 데이터를 메모리에 쓰고 읽을 수 있기 때문에 성능이 향상된다.
• 데이터 그리드는 쉽게 확장 가능하고 업그레이드를 쉽게 구현할 수 있다.
• 관계 구조보다 Key-Value 데이터 구조가 어플리케이션 개발자들에게 유연성을 제공한다.
• 기술적 이점으로 더 빠른 의사결정과 더 높은 생산성, 향상된 고객 서비스를 제공한다.
• DBMS의 부하를 IMDG 서버로 분산함으로써 고질적인 병목구간을 해소한다.
• 자주 변경되거나 조회가 발생하는 정보를 메모리에 상주시켜 성능을 높이는 캐시 서버로 활용할 수 있다.

단점

• IMDG 클라이언트 사용으로 인한 메모리 샤용량 증가
• 데이터 변경으로 인한 무효화(invalid)가 발생이 잦을수록 성능 저하
• 데이터 일관성이 깨질 수 있음

IMDG Platform

IMDG Platform은 다음과 같은 기능들을 제공한다.

Management Center : 관리자 콘솔에서 메모리 내의 데이터 그리드 전체를 제어하고 모니터링할 수 있다.

이를 통해 네트워크에 있는 모든 IMDG 인스턴스를 관리할 수 있다.

Extended and standard query : 표준 보고 도구에서 메모리 내의 데이터 그리드에 접근할 수 있다.

JDBC와 호환되는 데이터베이스에 접근하는 것과 유사한 IMDG에 접근할 수 있다.

기본적으로 SQL을 기반으로 하며 표준 JDBC 커넥터를 사용하여 IMDG를 연결할 수 있다.

Mirror service : 기존의 back-office 보고 시스템과의 원활한 통합이 가능하다. 전체 IMDG에서 기존 데이터베이스 또는 기타 데이터 소스에 이르기까지 투명한 데이터 지속성을 지원한다.

SQL-based continuous query support : 적절한 데이터를 해당 어플리케이션 로컬 메모리 근처로 가져온다.

Real-time event notification : FIFO, 느린 클라이언트 지원, 컨텐츠 기반 라우팅, pub/sub, batching 등 메세징 시스템에서 제공하는 기능을 제공한다.

참조

predictiveanalyticstoday.com : https://www.predictiveanalyticstoday.com/top-memory-data-grid-applications/

개요

이번 글에서는 Apache Tomcat의 디렉토리 구조와 각 디렉토리 안의 파일들이 어떤 기능을 수행하는지 알아보고자 한다.

본 글은 Apache Tomcat 9 버전을 기준으로 작성되었다.

Tomcat 디렉토리 구조

bin 디렉토리 파일

bat 파일은 윈도우에서 실행하는 batch 파일, sh 파일은 유닉스 계열에서 실행하는 shell script 파일이다.

conf 디렉토리 파일

lib 디렉토리 파일

참조

Apache Tomcat 9 Docs : https://tomcat.apache.org/tomcat-9.0-doc/index.html

개요

Apache Tomcat은 자바 서블릿 및 JSP 기술의 오픈 소스 소프트웨어를 구현한 것이다.

Apache Tomcat은 현재 여러 버전이 사용되고 있으며 각 버전마다 요구하는 사양이 다르기 때문에 잘 살펴보고 버전을 선택해야 한다.

Apache Tomcat Version

현재 톰캣은 9버전까지 출시되었으며 2019-09-23 기준으로 최신 마이너 버전은 9.0.26이다.

Apache Tomcat 공식 홈페이지에서 7 이하의 버전에 대한 다운로드와 문서도 제공하고 있지만 최신의 버전일수록 성능이 좋고 커뮤니티의 지원이 활발하므로 최신 버전을 사용할 것을 권장한다.

Apache Tomcat 9

Apache Tomcat 9 버전은 현재 개발에 집중하고 있다.

Tomcat 8.0, 8.5를 기반으로 하며 Servlet 4.0, JSP 2.3, EL 3.0, WebSocket 1.1 및 JASPIC 1.1 사양 (JAVA EE 8 플랫폼에서 요구하는 버전)을 구현한다.

주요 개선사항은 다음과 같다.

• HTTP/2에 대한 지원 추가(Apache Tomcat 9.0.0 이후 Java 9에서 실행해야 함) 또는 설치 중인 Tomcat Native 라이브러리)
• JSSE 커넥터(NIO 및 NIO2)에서 TLS 지원을 위한 OpenSSL 사용 지원 추가
• TLS 가상 호스팅(SNI) 지원 추가

Apache Tomcat 8

Apache Tomcat 8.0은 Tomcat 7.0.x를 기반으로 하며 Servlet 3.1, JSP 2.3, EL 3.0 및 WebSocket 1.1 사양을 구현한다. 

주요 개선사항은 다음과 같다.

• 이전 버전에서 제공되는 여러 리소스 확장 기능을 대체하기 위한 단일 공통 리소스 구현

Apache Tomcat 8.5는 Apache Tomcat 8.0.x와 동일한 Servlet, JSP, EL 및 WebSocket 사양 버전을 지원한다.

그 외에도 JASPIC 1.1 규격을 구현한다.

현재 Tomcat 8.0은 8.5로 대체되어 사용되지않는다.

Tomcat 8.5의 주요 개선사항은 다음과 같다.

• HTTP/2에 대한 지원 추가(Tomcat Native 라이브러리 필요)
• JSSE 커넥터(NIO 및 NIO2)에서 TLS 지원을 위한 OpenSSL 사용 지원 추가
• TLS 가상 호스팅(SNI) 지원 추가

Apache Tomcat 8.5에서 다음 기술이 제거되었다.

• HTTP 및 AJP 커넥터의 BIO 구현
• Comet API 지원
  
  

Apache Tomcat 7

Apache Tomcat 7.x는 Tomcat 6.0.x의 개선 사항을 기반으로 하며 Servlet 3.0, JSP 2.2, EL 2.2 및 WebSocket 1.1 사양을 구현한다.

주요 개선사항은 다음과 같다.

• 웹 애플리케이션 메모리 누수 감지 및 방지
• Manager 및 Host Manager 애플리케이션의 보안 향상
• 일반 CSRF 보호
• 웹 응용 프로그램에 외부 콘텐츠 직접 포함 지원
• 리팩터링(커넥터, 라이프사이클) 및 많은 내부 코드 정리

참조

Apache Tomcat Which Version : https://tomcat.apache.org/whichversion.html