천객만래 [千客萬來] (It has an interminable succession of visitors)
반응형

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

Aug 04, 2019 in tech

 

웹서버 하나만 사용하거나 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번임을 알고 다음처럼 설정을 해주자.

 

#vi 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)를 아래처럼 설정해주자.

 

#vi apache/conf/workers.properties

worker.list=load_balancer

 

worker.load_balancer.type=lb

worker.load_balancer.balance_workers=tomcat1,tomcat2,tomcat3

 

worker.tomcat1.port=18009

worker.tomcat1.host=localhost

worker.tomcat1.type=ajp13

worker.tomcat1.lbfactor=1

 

worker.tomcat2.port=28009

worker.tomcat2.host=localhost

worker.tomcat2.type=ajp13

worker.tomcat2.lbfactor=1

 

worker.tomcat3.port=38009

worker.tomcat3.host=localhost

worker.tomcat3.type=ajp13

worker.tomcat3.lbfactor=1

 

이렇게 설정을 한 뒤 앞서 설정한 httpd.conf 에 JkMount 부분도 아래처럼 변경해주자.

 

apache/conf/httpd.conf

JkMount /* load_balancer

위 설정을 다시한번 살펴보자면, /*으로 들어오는 요청을 load_balancer라는 워커로 넘기는데 워커 설정에서는 로드밸런싱이 설정되어 있기 때문에 tomcat1, tomcat2, tomcat3 골고루 요청을 분산해준다는 의미이다.

tomcat 하위 logs 폴더에 보면 아래 기본 설정에 의해 엑세스 로그가 로깅이 되는데

 

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"

       prefix="localhost_access_log" suffix=".txt"

       pattern="%h %l %u %t &quot;%r&quot; %s %b" />

 

실제로 테스트를 해보면 다음처럼 9번의 요청을 3대의 톰켓에 골고루 요청된 것을 확인할 수 있다.

 

 

# 로드밸런싱을 컨트롤 하기 (jkmanager)

위에서 알아본 mod_jk 를 활용한 로드밸런싱을 별도의 서버 재시작 없이 컨트롤이 가능하다고 한다. 이게 어떤것을 의미하냐면 연동된 톰켓 3대중에 한대를 별도의 서버 셧다운을 하지 않아도 제외시킬수 있으며 반대로 다시 투입도 가능하다는 이야기이다. 이를 활용해보면 서비스 배포를 할 경우 위와 같은 설정이 되어있을때 제외 > 배포 > 투입하는 식으로 서비스가 무중단 상태에서 배포가 될수 있는 효과를 얻을 수 있다.

설치는 별도로 하지 않아도 되고 mod_jk 모듈 내에 있기 때문에 별도의 설정만 추가해주면 된다.

 

apache/conf/httpd.conf

 

<IfModule jk_module>

    JkWorkersFile    conf/workers.properties

    JkLogFile        logs/mod_jk.log

    JkLogLevel       info

    JkMount /* load_balancer

 

    <Location /jkmanager/>

        JkMount jkstatus

        Order deny,allow

        Deny from all

        Allow from 127.0.0.1

        Allow from {접근 가능한 IP}

    </Location>

</IfModule>

apache/conf/workers.properties

 

worker.list=jkstatus

worker.jkstatus.type=status

 

설정에서 볼 수 있듯이 해당 설정은 다른측면에서는 상당히 취약점이 많은 부분이다. 해당 설정이 외부에 노출이 되어있다면 그 컨트롤을 서버 관리자가 아닌 다른 누군가가 할수 있기 때문에 꼭 Allow 설정으로 접근 제한을 해둬야 한다. 이렇게 하고 서버 IP/jkmanager/ 을 접속해보면 “JK Status Manager” 이라는 문구와 함께 아파치에 연동된 톰켓의 상태를 한눈에 파악할 수 있다.

 

여기서 tomcat1 좌측에 있는 E(=edit)를 클릭하고 Activation 값을 “Disabled” 으로 바꿔본 뒤 앞서 테스트한 방법을 다시 해보면 tomcat1 에는 엑세스가 들어오지 않고 9번 엑세스가 골고루 tomca2 와 tomcat3 으로 로드밸런싱이 된것을 확인할 수 있다.

 

 

# 마치며

각 설정값들은 아무리 필자가 설명을 잘 해도 도큐먼트를 따라갈 수 없듯이 실제 각 도큐먼트를 보면서 설정값 하나하나를 조절해보며 운영하고 있는 서비스의 특징과 상황에 맞도록 맞춰가는것이 핵심일것 같다. (본 포스팅은 아주 가볍게 연동만 해보는 형태이고, 각 설정이나 워커들간의 우선순위 로드밸런싱 같은 경우는 직접 설정을 해가면서 확인이 필요하다. )

사실 이부분은 머릿속으로는 어떻게 하는구나라고 알고만 있었는데 실제로 해보니 각 설정들이 어떤 의미이고 어떻게 조절하면 보다 더 좋은 성능이나 다양한 이득을 취할수 있을것 같다는 생각을 해본다.

 

참고 링크

https://tomcat.apache.org/connectors-doc/reference/workers.html

https://tomcat.apache.org/connectors-doc/common_howto/loadbalancers.html

 

출처 : https://taetaetae.github.io/2019/08/04/apache-load-balancing/

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

반응형
Posted by 사용자 SB패밀리

댓글을 달아 주세요

반응형

Forward Proxy & Reverse Proxy

포워드 프록시와 리버스 프록시 개념

 

Forward Proxy

클라이언트가 example.com 에 연결하려고 하면 사용자 PC 가 직접 연결하는게 아니라 포워드 프록시 서버가 요청을 받아서 example.com 에 연결하여 그 결과를 클라이언트에 전달(forward) 해 준다.

포워드 프록시는 대개 캐시 기능이 있으므로 자주 사용되는 컨텐츠라면 월등한 성능 향상을 가져올 수 있으며 정해진 사이트만 연결하게 설정하는 등 웹 사용 환경을 제한할수 있으므로 기업 환경등에서 많이 사용한다.


Reverse Proxy

클라이언트가 example.com 웹 서비스에 데이타를 요청하면 Reverse Proxy는 이 요청을 받아서 내부 서버에서 데이타를 받은 후에 이 데이타를 클라이언트에 전달하게 된다.

내부 서버가 직접 서비스를 제공해도 되지만 이렇게 구성하는 이유 중 하나는 보안 때문이다.

보통 기업의 네트워크 환경은 DMZ 라고 하는 내부 네트워크와 외부 네트워크 사이에 위치하는 구간이 존재하며 이 구간에는 메일 서버, 웹 서버, FTP 서버등 외부 서비스를 제공하는 서버가 위치하게 된다. example.com 사는 서비스를 자바로 구현해서 WAS 를 DMZ 에 놓고 서비스해도 되지만 WAS 는 보통 DB 서버와 연결되므로 WAS 가 최전방에 있으면 WAS 가 털릴 경우 DB 서버까지 같이 털리는 심각한 문제가 발생할 수 있다.

이 때문에 리버스 프락시 서버를 두고 실제 서비스 서버는 내부망에 위치시키고 프락시 서버만 내부에 있는 서비스 서버와 통신해서 결과를 클라이언트에게 제공하는 방식으로 서비스를 하게 된다.

특히 리눅스 환경이라면 리버스 프락시로 아파치 웹 서버를 사용한다면 SELinux 를 켜 놓으면 SELinux 의 기본 정책이 웹 서버는 톰캣의 8080, 8009 포트만 접근 할 수 있으므로 아파치 웹 서버가 해킹당해도 웹 서버 권한으로는 내부망으로 연결이 불가하다. 또한 리버시 프락시를 cluster로 구성해 놓으면 가용성을 높일 수 있고 사용자가 증가하는 상황에 맞게 Web Server 나 WAS 를 유연하게 늘릴 수 있는 장점이 있다.

 

**

Reverse Proxy 로 서비스 제공시 WAS 에서 REMOTE_ADDR 을 가져오면 Reverse Proxy 서버의 IP 를 얻게 되므로 원하는 결과가 나오지 않는다.

Proxy(프락시) 환경에서 client IP 를 얻기 위한 X-Forwarded-For(XFF) http header 를 참고해서 XFF 헤더를 사용하자.


출처 : www.lesstif.com/system-admin/forward-proxy-reverse-proxy-21430345.html

 

프록시와 리버스 프록시의 가장 쉬운 접근 방법은 

망 내에서 외부로의 서비스 이용은 (포워드) 프록시
망 밖에서 내부로의 서비스 이용은 리버스 프록시

가 되겠다.

포워드 프록시는 망 내의 이용자(또는 시스템)가 외부 서비스 위치 등을 모르고 이용하고

리버스 프록시는 망 밖의 이용자(또는 시스템)가 내부 서비스 위치 등을 모르고 이용하게 된다.

 

 

반응형
Posted by 사용자 SB패밀리

댓글을 달아 주세요

반응형

Domain Object
도메인 객체란 내가 개발하고자 하는 영역을 분석하고, 그 분석의 결과로 도출된 객체들을 말한다.

예를 들어, 쇼핑몰을 만든다고 했을 때 쇼핑몰의 주된 기능인 상품 구매에 사용되는 객체인 Member, Product, Purchase 등을 도메인 객체라고 할 수 있다.
 

 
DAO(Data Access Object)
DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 객체
실제 data resource를 액세스하는 어브젝트
DB에 대한 접근을 DAO를 통해서만 하도록 만들어 다수의 원격 호출을 통한 오버헤드와 호출 문제를 줄일 수 있다.

 

DTO(Domain Transfer Object)
계층간 데이터 교환을 위한 객체. 
도메인 모델의 튜플단위의 개체로 튜플의 속성을 getter, setter 하고 DAO로 연동하는 어브젝트
일반적인 DTO는 로직을 갖고 있지 않다. 순수한 데이터 객체이며 속성과 그 속성에 접근하기 위한 setter, getter 메서드만 가진 객체를 말한다. 여기에 추가적으로 toString(), equlas() 등의 Object 클래스 메서드를 작성할 수 있다.



VO(Value Object) : VO는 출력(Read only)

DTO의 읽기 버전



CRUD

CREATE(INSERT), READ(SELECT), UPDATE, DELETE

 

반응형
Posted by 사용자 SB패밀리

댓글을 달아 주세요

반응형

SOA 실현의 핵심, ESB

최근 서비스 지향 아키텍처(SOA) 가 엔터프라이즈 분야에서 핫 이슈로 떠오름에 따라 이를 실현하기 위한 핵심 미들웨엉인 ESB(Enterprise Service Bus)가 많은 개발자들에게 주목받고 있다. ESB란 미즈니스 내에서 서비스 ,애플리케이션, 자원을 연결하고 통합하는 미들웨어라고 할 수 있으며, 이를 통해 분산된 서비스 컴포넌트를 쉽게 통합 연동할 수 있어 신뢰성 있는 메시지 통신이 가능하다. IT 통합을 위한 인프라스트럭처로 새롭게 부상하고 있는 ESB가 오늘날 엔터프라이즈 환경의 문제를 어떻게 해결해 줄 수 있는지 그 주요 기술과 제품을 통해 살펴보자

 

특집 1부 기업 환경 통합을 위한 해법, EAI에서 ESB까지
특집 2부 자바 ESB 기술의 현주소
2-1 ESB 패턴 구현을 통해 본 IBM ESB
2-2 전사 IT 환경을 위한 BEA의 ESB, 미뉴
2-3 자바 ESB 표준의 삼총사 JBI,SCA,SDO
특집 3부 JBI 구현을 우한 오픈소스 ESB, ServiceMix
특집 4부 ESB의 비판적 대안, MS WCF와 비즈토크 서버

 

기업 환경 통합을 위한 해법 EAI에서 ESB까지

 


김민호|프로그래머

 

SOA와 그 토대가 되는 ESB는 분명 최근 IT의 화두이다. 그러나 IT의 화두들은 언제나 그렇듯 하위호환성의 근간을 두며 전혀 새로운 것이 아닌 EAI나 APS 등에서의 흐름과 통하는 것이라 할 수 있다. 특집 1부에서는 EAI의 도입 초기부터 시작하여 ESB의 개념이 나오게 된 동기와 개념에 대해 알아보고자 한다.

 

기업 환경의 변화는 분명 필수불가결한 결론에 다다르게 된다. 필요에 의해 하나둘씩 생긴 시스템들은 서로 인터페이스를 하게 되고, 또한 어쩔 수 없는 중복도 생기게 된다. 이런 혼잡한 기업 환경에서 ESB(Enterprise Service Bus)는 최적화된 기술 구조를 제공해주며, 유지보수의 편리성과 기업의 신속한 의사결정의 기반이 된다.

 

기업 환경의 확장

 

기업 환경만큼 IT의 흐름에 민감한 환경 또한 없을 것이다. 더군다나 우리나라의 기업 환경은 획일적일만치 IT 흐름의 정석을 따르고 있다. 그동안 한 기업 내에는 수많은 시스템들이 구축되었다. 그룹웨어 시스템을 비롯하여, CRM(Customer Relationship Manage ment)과 ERP(Enterprise Resource Planning)는 어느 정도 이상의 규모에서는 모두 구축되어 있다고 봐도 과언이 아닐 것이다.

 

이런 기업 환경은 구축된 시스템 간의 데이터에 대한 동기화와 비즈니스 요구사항을 빠르게 반영하기 위해 분명 변화해야 하는 필요성이 생기게 된다. 대부분이 SI(System Integration) 형태로 진행된 단위 프로젝트이고 보면, 다른 시스템과의 연계성이나 전체 기업 환경의 구조까지를 생각하고 진행하게 되는 경우는 그리 많지 않았다.

 

또한 IT 기술적인 변화는 결코 현재 운영 중인 시스템에는 영향을 주지 않은 상태여야 하고, 이런 통합 작업은 <그림 1>과 같은 형태의 Point-to-Point 방식으로 진행되는 경우가 많았다. 이는 간단한 연동일 때 빠른 적용이 가능하고, 복잡하지 않은 환경에서는 적용이 가능한 형태라고 할 수 있다. 그러나 다음과 같은 단점들이 있다.

 

◆ Point-to-Point 방식의 연결로 인한 시스템 독립성이 보장 불가
◆ 시스템 변동시 과다한 수정사항 발생
◆ 프로세스의 변경 곤란(Ripple Effect)
◆ 비즈니스 로직의 재사용 불가
◆ 시스템 간 정보 흐름의 지체현상 발생

 

이런 단점들 때문에 어느 정도 이상 규모의 기업 환경에서는 더 큰 문제가 되기도 한다. 따라서 <그림 2>와 같은 좀 더 통합적인 관점에서 EAI(Enterprise Application Integration)의 도입이 진행되었던 것이다. 즉 EAI가 중심이 되어 인터페이스될 여러 시스템들이 EAI를 통하게 됨으로써 각 레거시 시스템은 EAI를 위한 단일의 인터페이스 형태만으로도 여러 종류의 레거시 시스템과 연동할 수 있게 된다. 뿐만 아니라 이런 중앙 집중 형태의 EAI는 미들웨어의 특징을 가지며, 데이터의 변환, 역할(Rule) 기반의 프로세싱, 트랜잭션의 무결성을 제공한다. 장점이 되는 특징들은 다음과 같은 것들이 있다.

 

◆ 단순 아키텍처 지향으로 재사용율을 높임
◆ 신규 애플리케이션 도입시 확장 용이
◆ 개발 편의성 증대
◆ 유지보수 편의성 증대
◆ 에러발견 및 로깅 , 복구의 편의성 증대

 

결국 <그림 1>의 전통적인 스파게티식의 인터페이스 방법은 <그림 2>의 방식으로 변경되었을 경우 개발과 운영 측면에서 2/3의 절감 효과를 기대할 수 있다.

 

<그림 1> Point-to-Point 방식의 통,인터페이스가 스파게티식으로 어지럽게 엮여져 있는 기업 환경

 

EAI의 대두

 

현재까지 이렇게 다양해지는 기업 환경을 통합하는 최선의 선택은 EAI이다. EAI는 e비즈니스를 구현할 때 기존 시스템과 단기간에 유기적으로 통합할 수 있는 비즈니스 통합 솔루션으로써의 역할을 수행할 수 있기 때문이다. 이렇게 EAI를 도입함으로써 시스템 통합에 대한 과다한 비용을 해소하고 여기저기 흩어져 있는 정보 자원을 효율적으로 사용할 수 있게 되며, 기업 내 시스템의 효과적인 통합을 통한 민첩하고 경쟁력 있는 기업으로의 성장이 원활하게 되는 것이다.

 

EAI 프로젝트는 기업 환경의 획기적인 변환 시점에 즈음하여 대개는 거론 또는 구축되는 경우를 많이 보는데 이는 그저 시스템 하나 둘 정도 늘어나는 정도의 변화 수준을 넘어 기업 내의 기반 플랫폼이 되는 새로운 시스템의 도입에 EAI가 병행되는 경우가 대부분이기 때문이다. 예를 들어 전사 기반의 ERP라든지 차세대 또는 신 시스템 등의 구축 등 상당히 중요한 시스템의 도입으로 인하여 대대적인 변화가 있는 경우에 대개는 진행되어 진다는 것이다. 과거 진행되었거나, 현재 진행되고 있는 국내의 EAI 프로젝트들은 크게 다음 두 가지로 분류하여 볼 수 있다.

 

◆ ERP 시스템이 도입되면서 전체 시스템에 영향을 미치는 EAI 프로젝트
◆ 차세대 또는 신 시스템 구축을 통하여 EAI가 도입되는 프로젝트

 

ERP가 도입되면서 진행되는 EAI 프로젝트

 

국내에서 ERP가 중심이 되어 EAI 프로젝트가 도입되는 사례를 살펴보면, 여러 산업 분야 중에서도 특히 제조, 통신 부분이 많이 차지하고 있다. 기업에서 새롭게 ERP를 채택하면서 진행되는 EAI 프로젝트는 당연 ERP를 기준으로 주변 시스템들을 재배치 또는 조정하는 모습이 보이는 것이 특징이며, ISP 단계에서 ERP 도입이 결정되면 기존 시스템들은 한편 생사의 기로(?)에 놓이게 되는 것이다.

 

ERP 중 국내에 많은 시장을 확보하고 있는 SAP를 기준으로 살펴보면, SAP ERP에서는 BAPI, RFC 또는 IDoc의 형태로 프로그래밍되며, 이것이 EAI 시스템과 ERP를 연결하는 프로그램 역할을 수행하여 준다. BAPI와 RFC는 동기 형태를 지원하며, IDoc은 비동기를 지원함으로 쓰임새가 좀 다르다고 할 수 있다. 특별히 해당 모듈이 IDoc 기반으로 되어 있지 않은 이상은 RFC를 이용한다고 보면 된다. IDoc은 동작된 것에 대한 모니터링이나 재처리, 주고받는 데이터에 대해 확인할 수 있는 등 많은 기능을 제공하지만, 비동기라는 방식 자체를 선호하지 않는 경우가 많아 ERP 자체적으로는 잘 사용되고 있으나, EAI에서는 그리 각광을 받지 못하는 것 같다는 느낌이다.

 

이런 ERP가 중심이 되는 EAI 프로젝트는 다른 어떠한 프로젝트보다 경험이 중요하다. 분명 EAI 프로젝트 자체가 다양한 레거시의 효율적인 연계를 위한 것이므로 시스템들 전반에 대한 지식을 필요로 하고 있고 따라서 보통은 웹 프로젝트에 비해 기반 기술을 비롯한 다양한 지식을 필요로 하는데 이것은 경험하지 않으면 쉽게 쌓이지 않는 부분이며 무엇보다도 경험을 통한 큰 그림을 가지는 능력이 반드시 필요하다.

 

오랜 시간 ERP를 하던 개발자들은 보통 자신이 속한 모듈의 지식만(?)을 가지고 있는 경우가 많고, 시스템의 관리를 맡는 BC 또한 ERP 외에 부분. 특히나 EAI와 같은 외부 연동 경험이 그리 풍부하지 않기 때문에 전체를 아우르는 EAI 입장에서 이러한 레거시는 물론 좀 더 상위 레벨의 전반 아키텍처를 그리지 않으면 안된다. ERP가 주가 되는 EAI 프로젝트의 장단점은 다음과 같다.

 

<그림 2> EAI, 중앙 집중 형태의 통합 기업 환경

 

<그림 3> 전통적인 인터페이스 방식과 EAI를 통한 인터페이스 방식의 도입효과, EAI의 도입효과 분석

 

<그림 4> EAI, EAI의 엔터프라이즈 미들웨어 프레임워크

 

<그림 5> EAI 프로젝트 종류 1, ERP 중심의 EAI 프로젝트

 

장점
◆ ERP가 주가 됨으로, 전체 아키텍처의 구성이 비교적 간단하다.
◆ ERP 도입으로 인한 컨설팅 진행으로 시스템들이 재정비되며, 프로세스가 효율적으로 간략화되는 경우가 많다.

 

단점
◆ ERP와 연계되는 시스템이 노후화된 경우가 많다.
◆ 연계 시스템의 노후화는 EAI 시스템의 부하를 증대시키고 전체 트랜잭션에 영향을 주게 된다.
◆ ERP 컨설턴트에 의해 기획되는 경우가 많고 기존 레거시의 기술적인 분석이 부족한 경우가 많음
◆ ERP 프로젝트 일정에 EAI가 속하게 됨으로 자체적인 프로젝트 일정이 의미가 없는 경우가 많다.
◆ ERP나 레거시 시스템의 개발자가 외부 연동의 경험이 없는 경우가 많아 EAI 측에서 이를 지원하거나 프로그램 샘플을 제공해야 하는 경우도 있다.

 

<그림 6> 차세대 프로젝트 등에서의 EAI 프로젝트, EAI 프로젝트 H/W 아키텍처 예시

 

ERP가 주가되는 EAI 프로젝트의 개발방법론

 

보통의 프로젝트에서 개발방법론은 ‘요구사항 분석->설계->개발->테스트’와 같은 폭포수 모델을 근간으로 하는 경우가 많다. 프로젝트 초창기 PM이나 컨설턴트에 의해 고객의 요구사항이 분석되며, 아키텍처나 고급 개발자가 설계하고 개발, 테스트하는 형태는 많은 개발자들이 받아들이기에 그리 무리가 없는 형태라 할 수 있다.

 

그러나 필자가 경험한 ERP가 주가 되는 EAI 프로젝트의 경우 이러한 단계별 진행이 거의 불가능하다. EAI 프로젝트의 경우 연계되는 시스템이 적게는 몇 십 개에서 많게는 몇 백 개의 시스템이 되며, 그 시스템들을 담당하고 있는 담당자들 또한 수십 명에 이르기 때문에 인터페이스의 설계가 프로젝트 초창기에 한꺼번에 진행되지 않고, ERP 프로젝트의 개발 일정에 EAI는 설계, 개발 , 테스트가 한꺼번에 이루어지게 된다. 물론 분석의 경우 인터페이스 할 레거시 시스템을 초기에 어느 정도 유추하는 것이 가능하기 때문에 100%는 아니더라도 거의 90% 이상 분석을 마친 상태로 프로젝트를 시작할 수 있다.

 

이런 조금은 다른 개발 방법은 개발자들에게 상당히 큰 스트레스가 된다. 분석/설계된 개발물량에 대한 특정 일자동안 개발하고 테스트했으나, 개발 중에 수시로 해야 하는 테스트와 EAI 단독적으로 진행할 수 있는 테스트가 거의 없기에 각 시스템 담당자와의 시간 약속, 그리고 수정 변경이 빈번이 일어나는 환경 등은 이제껏 경험할 수 없었던 독특하고 쉽지 않은 것이기 때문이다.

 

또한 테스트 부분도 단위 테스트, 통합 테스트, 병행가동 테스트 그리고 성능/부하 테스트 등 빈도가 많은 것은 기본이며 많은 시간을 할애해서 진행해야 하는 부분으로, 사전에 아주 치밀한 계획과 각 부서의 유기적인 협조가 이루어지지 않으면 거의 밤샘을 해야하는 상황까지 자주 연출될 수밖에 없는 것이다.

 

차세대 또는 신 시스템 구축을 통해 진행되는 EAI 프로젝트

 

주로 금융 또는 제2금융권에서 진행되는 경우가 많다. 이런 프로젝트의 특징은 트랜잭션 자체가 상당히 중요하나, 또한 이 트랜잭션을 잘게 나누는 것이 의미 있는 경우가 많으며, 대용량의 데이터를 실시간 또는 배치 형태로 전달하는 것이 중요한 부분을 차지하게 된다. 또한 신뢰성이 상당히 중요해서 EAI 시스템 자체에 대한 장애 복구 방안은 기본이며, 다른 레거시 시스템들에 장애가 발생했을 경우에 대처할 수 있는 방안 또한 중요하게 취급되어 진다.

 

EAI와 ESB 그리고 SOA

 

가트너 그룹의 보고서에 따르면 EAI를 “엔터프라이즈 미들웨어를 인프라로 하여 다양한 이질적 기업적 환경(애플리케이션, 데이터, 플랫폼 및 네트워크 등)을 통합하여 하나의 시스템으로 관리 운영할 수 있는 유기적인 시스템”이라고 정의하고 있으며, 다른 기관에서의 정의 또한 대동소이한 편이다. 하지만 ESB의 경우 다음과 같이 기관마다 차이가 나는 다른 정의를 내리고 있는 것을 볼 수 있다.

 

◆ 느슨하게 결합되었거나 결합되지 않은 구성 요소들 간에 중재적인 관계와 직접 통신을 지원하는 웹 서비스가 가능한 인프라 - Gartner Group

◆ ESB란 표시는 그 제품이 MOM과 웹 서비스 프로토콜 모두를 지원하는 일종의 통합 미들웨어 제품 - Burton Group

◆ 표준 기반 통합 백본, 통합 메시징, 웹 서비스, 변환, 그리고 인텔리전트 라우팅 - Sonic Software

◆ 통신과 연결, 변환, 보안을 위한 표준화된 인터페이스를 구현하는 엔터프라이즈 플랫폼 - Fiorano Software

◆ 쉽게 말해 웹스피어 MQ와 그 밖의 다른 웹스피어 브로커 그리고 통합 서버를 가지고 있다면 당신은 ESB를 가지고 있는 것 - Bob Sutor, IBM

◆ ESB는 인프라 서비스들의 규칙적인 서비스 통합 아키텍처로 정의된 환경 내의 여러 비즈니스 서비스들에 일관된 지원을 제공한다. ESB는 웹 서비스 인터페이스를 사용해 서비스 중심 아키텍처로 구현된다. - CBDI

 

이와 같이 여러 가지 다양한 정의가 나온 것에 대해서 데이비드 채펠(채펠앤어소시에이트 사장)은 다음과 같은 말을 했다.

 

“개인적으로 ESB는 마케팅 개념에 불과하다고 본다. ESB 회사의 최고기술책임자(CTO)로 있는 친구들과 얘기를 해봤는데 사람들마다 의견이 달렸다. 현재 ESB는 자사의 독자 기술을 판매하기 위한 일종의 마케팅 전술이라고 할 수 있다. 그렇기 때문에 ESB에 대한 정의가 제각각인 셈이다.”

 

필자는 EAI라는 개념이 나왔을 당시만 해도 ESB와 EAI는 크게 다르지 않은 거의 같은 개념으로 이해하고 있었다. 다만 SOA (Servic Oriented Architecture)라는 아키텍처가 거의 모든 벤더들에게 마케팅의 중심이 되자, EAI라는 말은 거의 사라졌으며 ESB로 옮겨가고 있었다. 현재 시점에서 EAI와 ESB에 대한 구분은 EAI는 주로 허브&스포크 형태의 중앙 집중 방식이라면 ESB는 동적인 업무 프로세스를 통합하기 위한 버스 형태를 취하고 있다는 점이다. 즉 EAI는 시스템들 사이에 위치하며 각 시스템의 연계를 중심으로 한다면, ESB는 서비스를 중심으로 하나의 업무 프로세스를 진행하기 위해 하나 이상의 시스템을 거치는 운반자적인 역할이 더 중요하다는 것이다.

 

EAI가 대두되면서 기업의 통합에만 중심이 되서 EAI가 독립적으로 각광을 받았다고는 볼 수 없다. EAI가 회자될때쯤 EP(Enter prise Portal)와 함께 APS(Application Platform Suites)도 꽤 비중 있게 다루어졌다. 필자는 예전에 세미나를 통해 EAI를 발표할 기회가 있었는데 분명 EAI 자체적인 것도 중요하게 다뤘지만 이 EAI를 통하여 발전하게 될 기업 환경을 위해 APS에 대해 상당히 무게를 두었다.

 

기업 환경을 통합하는 EAI만으로는 무언가 부족함을 느끼게 된다. 분명 EAI를 통해 기업은 체계화된 데이터와 재사용 가능한 컴포넌트들을 가지게 되었지만, 이것이 적기시장진입(Time-to-Market)을 실현할 수 있는 열쇠는 될 수 없기 때문이다. 실제로 이러한 기본 환경들이 활용되기 위해서는 EP를 통한 UI 환경에서의 통합 또한 중요하기 때문이다.

 

ESB의 특징

 

ESB는 기업 IT 환경에서 중추적인 역할을 수행하는 것으로 각 레거시 시스템과의 연동을 위한 다양한 표준 프로토콜의 지원을 기본으로 재사용 가능한 컴포넌트들을 조립함으로써 서비스 지향적인 기업 환경을 만들 수 있는 기반이 되어야 한다. ESB의 특징으로는 다음과 같은 것들이 있다.

 

◆ 다양한 시스템과 연동하기 위한 멀티 프로토콜 지원
◆ 느슨한 결합(loosely coupled)
◆ 소프트웨어 컴포넌트를 조합하여 서비스를 조립하는 BPM 지원
◆ 이벤트 지향적
◆ 표준 지향적

 

ESB의 구성요소

 

어댑터 형태의 레거시 연동 컴포넌트
ESB는 기본적으로 다양한 표준 프로토콜을 어댑터(Adapter) 형태로 지원해야 한다. 어댑터 형태의 지원이란 소스 형태의 라이브러리가 아닌 통합 개발 환경에서 플러거블(Pluggable)할 수 있는 간단히 연동할 수 있는 형태여야 한다.

 

메시지의 변환, 가공
연동되는 시스템끼리는 서로 다른 형태의 데이터일 경우가 대부분이다. 따라서 데이터 포맷과 형태 등을 통합 개발 환경 등을 통해 자유롭게 변화하고 가공할 수 있어야 한다.

 

BPM
기업에서 필요로 하는 하나의 단위 서비스들은 보통 하나의 시스템과의 연동으로 이루어지는 경우는 그리 많지 않다. 다양한 시스템의 데이터와 애플리케이션과의 연동을 통해 하나의 서비스를 이용할 수 있어야 하고, 이를 위해서 반드시 BPM이 필요로 한다.

 

컨트롤과 모니터링
레거시 시스템과의 연동에서부터 데이터의 변환, 프로세스의 작성 등은 여러 단계를 거쳐 작업되고, 이러한 과정들은 통합적인 조작과 모니터링이 가능해야 한다. 어댑터 단에서의 연결 상태부터 진행되고 있는 프로세스의 상태 및 데이터 값 등이 모니터링의 대상이 될 수 있다.

 

통합개발환경
ESB에서 통합개발환경을 구성요소로 포함시키는 경우는 거의 없다. 하지만 여러 툴을 통하여 개발되거나 툴 자체가 제공되지 않을 경우 개발 효율성은 급격히 떨어질 수밖에 없다. 따라서 통합개발환경은 ESB에서 필요한 요소 중 하나가 되기에 충분하다.

 

<그림 7> ESB, ESB를 도식화한 그림(출처 : IBM Redbooks)

 

SOA에서의 ESB

 

현대 기업에서 가장 필요한 IT적 특성은 민첩성이라고 할 수 있다. 이런 민첩성을 해결할 아키텍처가 SOA이며, SOA를 이루는 핵심 기술이 바로 ESB라고 할 수 있다. SOA가 각광받는 이유는 현재까지 다분히 소극적이었던 IT의 활용이 현재 구축된 기업 환경을 바탕으로 이제 좀 더 많은 이윤을 창출할 수 있는 바탕이 되는 것이기 때문이다. 예전처럼 기업의 서비스를 IT가 받쳐주는 것이 아닌 기 구축된 IT 환경에 의해 새로운 서비스가 탄생되어 이런 서비스로 하여감 기업이 이윤을 창출 할 수 있는 계기를 마련해주는 것이다.

 

예를 들어, 은행에서 하나의 예금상품을 만들 때 담당자가 해당 예금상품을 기획하고 그것을 창구를 통한 서비스가 아닌 인터넷 뱅킹 등의 서비스를 통해 다른 은행에 비해 더 빨리 제공할 수 있다면, 그 은행은 분명 다른 은행에 비해 더 많은 이윤을 창출할 수 있을 것이다.

 

진정한 서비스 지향으로의 ESB

 

진정한 SOA가 구축되기 위해서는 현업에서 서비스를 설계할 수 있도록 하는 구조가 되어야 한다. 보통 서비스를 설계하는 사람들이 실제 기술적인 측면을 이해하는 경우는 극히 드물다고 할 수 있다. 또한 기술적인 기반에서만 서비스를 구축할 수 있다면 그것은 진정한 서비스라고 할 수 없다. 서비스란 철저히 기술과 분리된 개념으로 이루어져서 이제껏 전통적인 방법으로 새로운 상품을 개발하는 것과 동일한 형태로 서비스를 이용할 수 있어야 하는 것이다.

 

많은 기업들이 SOA를 구축하려 시도했고 또한 시도하고 있지만 기술적인 관심사에 압도되어 적정 수준보다 적은 범위의 목표에 집중하기 때문에 현업에서 사용되어야 하는 서비스까지 도달하지 못하는 경우가 대부분이다. 분명 쉽지 않은 일이겠지만 서비스의 정의는 철저히 서비스만을 위한 정의가 되어야 하며, 이렇게 정의된 서비스를 기술에 원활히 접목시킬 수 있도록 기업 IT 환경이 ESB에 충실하게 구축되어야 할 것이다.

 

출처명 : 마이크로소프트웨어 [2006년 3월]

 

반응형
Posted by 사용자 SB패밀리
TAG CBD, EAI, ESB, MSA, SAP, si, SOA

댓글을 달아 주세요