블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'EIP'에 해당되는 글 4

  1. 2013.08.18 Amazon VPC (Virtual Private Cloud) 소개 (3)
  2. 2013.02.20 Apache Camel Error Handling
  3. 2013.02.17 Apache Camel Overview
  4. 2013.02.12 Apache Camel note
 

Amazon VPC (Virtual Private Cloud)

조대협 (http://bcho.tistory.com)


VPC Virtual Private Cloud의 약자로 아마존 클라우드 내에서 private ip를 사용하는 일종의 가상 private network 망을 만들어줄 수 있게 해주는 서비스이다.

이 서비스 전에는 EIP 이외에는 정적 서비스를 사용할 수 없었으며, 또한 10.0.x.x와 같은 private ip를 사용할 수 없었다. VPC 서비스와 함께, 내부 ip 대역을 사용할 수 있게 되었으며 조금 더 유연한 네트워크 관리가 가능하게 되었다.


VPC

VPC Amazon 콘솔에서 생성하면 되는데, VPC의 범위는 , 하나의 VPC는 하나의 Region내에서만 생성이 가능하다. VPC를 두개 이상의 region에 걸쳐서 사용이 불가능하다.단 하나의 VPC는 여러개의 Amazon Availibility Zone (이하 AZ) 에 걸쳐서 생성될 수 있다. 또한 하나의 VPC가 가질 수 있는 IP 주소의 Range 2^16 = 65535로 제한된다.

CIDR 표현으로 10.0.0.0/16 (10.0.0.0~10.0.255.255) 범위가 된다. CIDR에 대한 개념과 계산법은 http://www.subnet-calculator.com/cidr.php 계산기를 참고하기 바란다.


Subnet

VPC를 생성했으면, 각각의 Subnet을 생성해야 한다. Subnet의 범위를 다시 한번 보자.

VPC는 앞서 설명한것 처럼, 하나으 region내에서 여러개의 AZ에 걸쳐서 생성이 가능하다. VPC안에서는 여러개의 subnet을 생성할 수 있는데, 하나의 subnet VPC안에서 하나의 AZ에만 생성이 가능하다.



 

Route Table

subnet에는 default subnet과 밖을 연결해주는 router가 생성되고, router route table을 가지고 있다. 대상 ip address routing 경로를 정의하는 것으로 subnet에서 밖으로 나가는 outbound traffic에 대한 routing 경로를 정의한다. route table AWS 콘솔에서 설정이 가능하고, routing 경로는 target의 타입에 따라서, 크게 세가지로 분리할 수 있다.



Ÿ   *  Local : VPC 내의 다른 subnet으로 traffic routing 한다.

Ÿ   Internet gateway : internet gateway를 통해서, 외부 인터넷으로 trafficrouting 한다.

Ÿ   * Virtual private gateway : 관리자가 임의로 정의한 destination으로 trafficrouting한다. VPN 연결을 위한 VPN gateway 등이 그 예가 된다.


아래와 같이 설정을 해놓으면, 10.0.0.0~10.0.255.255 VPC 내부로 routing이 되고, 172.16.0.0~172.31.255.255 vgw-9628c9ff 라고 정의한 routerrouting이 된다.



또 다른 예를 보자.



이 경우에는 172.31.0.0~172.31.255.255는 내부 VPC 내로 routing이 되고, 이 외의 모든 traffic igw-0eab8665 (internet gateway로 정의했음) 을 통해서 외부 인터넷으로 routing이 되게 된다.

모든 subnet1개의 routing table을 가져야 하며, 하나의 routing table은 여러개의 subnet에 중복되서 적용될 수 있다.


Public subnet & Internet gateway

VPC 내에 생성되는 EC2 Instance 10.0.x.x와 같은 private IP이외에 Elastic IP(이하 EIP)를 통해서 일반 인터넷 주소인 pubic IP까지 총 2개의 IP를 가질 수 있다.

Subnet 내의 EC2 instance들이 직접 인터넷에 EIP를 통해서 in/out bound connection이 연결 가능한 subnet public subnet이라고 정의 하는데, in/outbound traffic internet gateway (이하 igw)를 통해서 이루어지며 콘솔에서 설정에 의해서 만들 수 있으며, 생성을 한후에, VPC attach한후, 사용하고자 하는 subnet routing table에 설정을 해주면 된다.



위의 그림과 같이 subnet에서 인터넷으로 traffic EC2 EIP를 통해서 router를 타고, router에 의해 정의된 routing 경로를 따라 internet gateway를 거쳐서 internet에 연결된다.


Private subnet & NAT

Public subnet이 있으면 당연히 private subnet도 있다. Private subnet EIP를 가지지 않고 private IP만 가지고 있으며, Internet으로의 in/outbound 연결이 불가능하며 단지 다른 subnet으로만 연결이 가능하다.



보통 일반적인 회사에서 private network을 구성할때 많이 사용하는 방법인데, private ip를 쓴다 하더라도, 외부 시스템으로의 접속이 필요한 경우가 있다. 예를 들어서 다른 서버와 connection을 하거나 patch를 읽어오는 것과 같은 outbound connection은 사용되는 경우가 많다. 일반 private network의 경우에는 outbound connection에 대해서 public ip binding 하여 연결을 제공하는 방식으로 NAT (Network Address Translator) 라는 장비를 사용하는데, Amazon에서도 마찬가지로 이러한 NAT를 이용해서, Private subnet 내의 instnaceinternet으로 나가는 outbound traffic이 지원될 수 있도록 한다.



NAT를 이용한다고 해서, 특별한 기능을 Amazon이 제공하는 것이 아니고, Software 기반의 NAT public subnet에 설치한후에, private subnet에서 인터넷으로 나가는 outbound traffic에 대한 routing 경로를 이 NAT를 통하게 하는 것이다.

조금 사용을 편리하게 하기 위해서, Amazon에서는 AMI 이미지 형태로 미리 NAT EC2 이미지를 제공하고 있기 때문에, 별도의 선호 제품이 없을 경우에는 이 이미지를 사용하면 된다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html

보통 이 NAT를 사용할 경우, 전체 VPC에 대해서 한두개의 NAT만 사용하는 경우가 있는데, 애플리케이션이 private subnet에서 밖으로 나가는 outbound protocol이 많을 경우에 이 NAT 자체가 병목 구간이 될 수 있기 때문에, NAT에 대한 traffic을 수시로 확인하고 알맞은 용량으로 운영을 해야 한다.

또한 Amazon 내부 서비스라 하더라도, private ip가 아니라 public ip를 쓰는 경우가 많고 이 경우 private subnet에 있는 EC2 인스턴스들은 NAT를 거치기 때문에, Amazon 서비스에 대한 호출도 NAT를 사용함을 인지하고 NAT 용량을 체크해야 한다. (. S3 public ip만 제공한다. 그래서 private subnet에서 S3로의 traffic은 모두 NAT를 거치게 된다.)


VPN

먼저 VPN에 대해서 알아보자. VPN (Virtual Private Network) 서비스의 약자로, public(인터넷) 망을 통해서 회사의 private network 망에 연결하게 해주는 서비스 이다.

예를 들어 회사가 10.0.1.XX 대역의 네트웍을 쓰고 있고, 내가 집에서 노트북으로 회사의 네트웍에 접속하고자 한다고 하자. IP public internet ip 198.12.x.x 를 사용한다고 하자. 회사 네트워크는 private 망이기 때문에 접속이 불가능하다. 그래서 VPN gateway를 회사 네트웍과 내 PC에 설치해놓으면 가상으로 내 PC를 회사 네트웍과 연결하여 같은 네트워크 대역으로 사용할 수 있도록 해준다. 개인PC à 회사 private 네트웍 뿐만 아니라, 물리적으로 분리되어 있는 지역간의 사무실이나 네트웍까지 이 VPN 네트웍을 사용하면 하나의 private network으로 묶을 수 있다.



Amazon에서도 역시 VPN을 사용할 수 있는데, VPN을 사용하기 위해서는 VPN Gateway를 설치해야 한다. 직접 소프트웨어 기반의 VPN을 설치할 수 도 있지만, Amazon에서 제공하는 VPN을 사용할 수 도 있다. VPN은 그 보안 및 암호화 방법에 따라서 IPESC, IKE등 여러가지 방법을 제공하는데, Amazon에서 제공하는 VPN의 경우에도 상당히 다양한 방법의 VPN 프로토콜을 지원 한다. (IPSEC,IKE, SHA-1 방식의 Hashing, BGP peering ).

자세한 내용은 아래 Link 참고
http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Introduction.html

VPN 을 통해서 VPC에서 할 수 있는 것은 region간의 서로 다른 VPC를 같은 subnet으로 묶거나, 또는 회사 데이타 센타의 subnet VPN을 통해서 VPC와 같은 네트워크 대역으로 묶을 수 있다.



VPN을 구성할때 고려해야 할 점은, VPC를 구성할때, VPN을 통해서 다른 region이나 데이타센터(회사)와 연결할 가능성이 있다면, subnet ip 주소를 이에 맞게 구성해야 한다는 것이다. 만약에 VPC를 구성할때 처음부터 10.0.0.0/16으로 Full range를 다 사용해버리면 나중에 다른 데이타 센터와 VPC로 연결할때 IP가 겹칠 수 있고, 나중에 이를 바꿔야 하는 대 작업이 생길 수 있기 때문에, VPC 디자인시 먼저 subnet ip 대역을 적절하게 분할하여 설계할 필요가 있다.


Security Group

Security GroupVPC 안에서 일종의 방화벽 처럼 사용된다. VPC 가 아니더라도 Security GroupAWS에서 필수적으로 사용되는데, Security 그룹은 inboud 또는 outbound traffic에 대해서 port 별로 접근을 제어할 수 있는 기능을 제공한다. 마치 방화벽과 같은 기능을 하는 서비스라고 생가하면 된다.

 VPC 안에서의 Security Group의 차이점은 VPC를 사용하지 않는 경우 Security Group에서는 inbound traffic에 대해서만 접근 제어가 가능한데, VPC내의 Security Group의 경우에는 in/outbound traffic 모두에 대해서 접근 제어가 가능하다.

그 외에도, 생성할 수 있는 Security Group수나 지원 하는 Protocol의 종류가 차이가 있는데, 자세한 내용은
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#VPC_Security_Group_Differences
를 참고하기 바란다.

Security Group 을 이용하면, Hosting 환경에서 사용하는 DMZ와 같은 개념을 구현할 수 있다. 아래 그림을 보자, 아래 아키텍쳐는 Web à REST API à DBMS 세 가지 계층으로 이루어진 시스템이다.



Web Layer public subnet으로 구성하고, 인터넷으로 부터 들어오는 모든 TCP 80 (HTTP) traffic을 받도록 Security Group을 구성한다. REST API 를 제공하는 subnet Web Server들이 위치한 Subnet으로 부터 들어오는 TCP 8080 traffic만 받도록 하고, DB들이 위치한 subnet API Server subnet에서 들어오는 DB 연결용 3306 포트만 받도록 한다.

이런식으로 네트워크를 구성하면 조금 더 높은 수준의 보안을 제공할 수 있다.


Bastion

VPC를 사용하게 되면, private subnet의 경우에는 외부에서 telnet이나 ssh로 접근할 수 있는 방법이 없다. (public ip가 없기 때문에) 또한 public subnet에 있는 EC2 instance의 경우에도 모든 인스턴스에 SSH 연결을 열어 놓게 되면 보안상으로 문제가 발생할 수 있는 가능성이 있다.

그래서 Bastion 이라는 개념을 사용하는데, 일종의 Telnet 접속 Console이라고 생각하면 된다.



VPC 내의 모든 Instance들은 이 Bastion으로 부터의 telnet 또는 SSH 접속 만을 허용하도록 Security Group이 설정하고, Bastion역시 SSH 접속을 운영자의 PC나 운영센터 (회사) IP 대역을 통해서 SSH 접속만을 할 수 있도록 Security Group을 설정해놓으면 VPC로의 접근을 안전하게 통제할 수 있으며, 단일 접속 지점만을 제공하기 때문에, 모든 사용자의 접근 내용을 한군데로 logging해서 감시할 수 있는 장점이 있다.

Bastion은 단일 접속 지점인 만큼 하나의 instance로 운영하는 것보다는 HA를 사용하거나 또는 일반적인 접속을 위한 Bastion, super user만을 위한 (나중에 일반 접속용 Bastion이 장애가 나서 접속이 불가할 때 사용할 용도) 별도의 Bastion 을 포함하여 2개 이상을 운영하는 것이 좋다.


VPC Scenarios

지금까지 간략하게 나마 VPC의 기능에 대해서 알아보았다. VPC를 제대로 사용하면 상당히 다양한 구조의 network 구성을 할 수 있다. 반대로 이야기 하면, 모르면 구성이나 사용이 매우 어렵다는 이야기가 된다.

Amazon에서는 VPC에 대한 주요 사용 패턴에 따라 약 4가지 시나리오를 이미 준비해놓고, VPC Wizard에서 지원하고 있다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenarios.html 를 보면 Amazon에서 제공하는 주요 4가지 시나리오에 대한 설명과 설정 방법을 참고할 수 있다.

 

Apache Camel Error Handling

아키텍쳐 /EAI | 2013.02.20 00:54 | Posted by 조대협


Camel의 에러처리

먼저 Camel의 에러 타입에 대해서 살펴보자. 이 에러 타입은 Camel 이 아니더라도, 일반적인 integration 시나리오에서는 공통적으로 존재하는 에러 타입으로, 복구 가능한 에러와 복구 불가능한 에러가 있다.

에러의 종류

복구 가능한 에러 (Recoverable error)

복구 가능한 에러는 다시 시도 했을 경우 정상 처리 할 수 있는 에러이다. 예를 들어 순간적으로 네트워크 Connection이 끊어졌을때는 대부분, 다시 시도 하면 재처리가 가능하다.

복구 불가능한 에러 (Irrecoverable error)

복구 불가능한 에러는 내부 로직 문제나 잘못된 데이타 입력으로 인하여 다시 시도했을때에도 에러가 예상되는 에러를 복구 불가능 에러로 분리한다.

Camel에서 수신 컴포넌트에서부터 전달되는 메세지는 org.apache.camel.Exchange라는 클래스를 이용해서 전달이 되는데, 에러가 발생하면, 이 클래스에 에러를 Binding 시킬 수 있다. 에러 처리는 Camel Route 흐름에 따라서 Channel이라는 단계에서 처리된다. (Channel의 개념은 뒤에서 설명)

Recoverable 에러의 경우에는 Throwable이나 Exception 으로 정의하고, Exchange.setException() 메서드를 통해서 바인딩 한다.

Irrecoverable 에러의 경우에는

Message msg = Exchange.getOut();

msg.setFault(true)

로 설정해주면, 이 에러는 irrecoverable 에러로 정의된다이렇게 발생된 에러는 어떻게 처리 될까? 에러 처리 정책을 결정하는 ErrorHandler에 정의된 정책에 따라서 처리 된다.

ErrorHandler

어떻게 Error 가 처리 되는지를 설명하기 위해서 앞서 설명했던 Camel Route 흐름을 조금 더 자세하게 살펴보자




Camel은 앞서도 설명하였지만, 메세지를 수신 받는 Component, 이를 처리하는 Processor 그리고, 수신 시스템으로 송신하는 Component로 구성이 된다. 이 세 요소 사이에 메세지가 흘러가는데, 이 각각의 구간을 Channel이라고 정의한다. Channel은 단순히 논리적인 구간만이 아니라, 메세지가 흘러가는 길목으로 이 부분을 통해서 에러 처리나 모니터링 등의 (injection과 같은) 작업을 수행할 수 있다. 즉 에러 처리가 여기서 발생한다

에러가 발생하면, 에러는 전단계의 Channel로 넘어가게 되고, 정의된 ErrorHandler의 정책에 따라서 에러가 처리 된다. 즉 위의 그림에서 Processor에서 에러가 발생하면, Exception[1] Channel 부분으로 넘어가게 되고, 정의된 ErrorHandler에 의해서 처리된다. 마찬가지로 (Outbound) Component에서 에러가 발생하면 [2] Channel로 넘어가서 여기서 에러가 처리된다.

그러면 실제로 에러를 처리 하는 ErrorHandler를 살펴보자. Camel은 크게 5개의 Error Handler를 가지고 있다.


(1) DefaultErrorHandler

가장 일반적으로 사용되는 ErrorHandler이다. DefaultErrorHandler의 경우 에러가 발생하면, 앞단계로 Error Propagation한다.

, Processor에서 에러가 발생하면 앞단계의 Inbound Component Error propagte하고 Route process를 끝낸다. Inbound Component의 경우 내부적으로 자체 Error 처리 로직을 가지고 있는 경우가 있다. (File,FTP,DB Component의 경우) 이 컴포넌트들은 에러를 받으면 에러 처리를 한 후에 Route를 종료 시킨다.

만약 특정 에러가 발생하였을 때, Route를 정지 시키지 않고 진행을 하고 싶다면, Error 처리를 한 후에 뒤로 진행하도록 할 수 있다.

다음 코드를 보자

from(“src:start)
 .process(new MyProcessor())
 .to(“des:end”);

 

onException(StepBackException.class).log(“error sent back to caller”);

onException(HandledErrorException.class).handled(true).setBody(constant(“error handled”)).to(“des:errorhandle)

onException(IgnoreErrorException.class).continue(true);

 

이 코드는 별도의 ErrorHandler를 지정하지 않았기 때문에, Default Handler로 작동하고,

StepBackException 이 발생하면 앞단계로 Error propagate하고 Route를 종료한다.

HandledErrorException이 발생하면 handled(true)를 세팅하였기 때문에, setBody~ 부터의 흐름을 진행하여, des:errorhandle로 메세지를 전달한다.

IgnoreErrorException 이 발생하면, continue(true)에 의해서 에러를 무시하고 to(des:end)를 그대로 진행한다.

 

(2) DeadLetterChannel

Error가 발생되었을때, DeadLetterChannel로 메세지를 전송한다. 일반적으로 Message Queue 메카니즘을 사용할때 쓰는 일종의 ErrorQueue로 생각하면 된다.

RouterBuilder Class에서

public void configure(){

 errorHandler(deadLetterChannel("jms:queue:error_queue"));

 from(…)…

 to(…)..

}

와 같이 정의 해놓으면, 에러가 발생하였을때, 메세지를 JMS error_queue로 전송한다.

 

(3) LogErrorHandler

에러가 발생하였을 때, 설정된 Log4J등의 Logger를 통해서 에러를 출력한다.

그 외에 TransactionErrorHandler NoErrorHandler 등이 있다.

ErrorHandler들은 CamelContext에 적용하여 Context binding된 전체 Route들에 적용할 수도 있고, 또는 개개별 Route에만 적용할 수 도 있다.

에러의 재처리

DefaultErrorHandler의 경우, 에러가 발생하였을때, 재처리를 하도록 설정할 수 있다.

errorHandler(defaultErrorHandler().maximumRedeliveries(5))

로 지정하면 5 Retry를 하게 된다. 물론, retry 간격등이나, retry logging 등 다양한 옵션을 지정할 수 있다.

http://camel.apache.org/redeliverypolicy.html


참고 : Apache Camel 소개 -http://bcho.tistory.com/715


'아키텍쳐  > EAI' 카테고리의 다른 글

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (2) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21

Apache Camel Overview

아키텍쳐 /EAI | 2013.02.17 00:43 | Posted by 조대협

조대협 (http://bcho.tistory.com)

서문

예전 BEA나 오라클 시절에, EAI, ESB 등을 가지고 시스템간의 연계 업무를 많이 해왔던 나로써는 오픈 소스 기반의 EAI 프레임웍인 Apache Camel의 경우 상당히 흥미로운 주제였다. 과연 상용 제품 대비 얼마나 현실성있는 integration 기능을 제공할 것인가? 가 가장 큰 궁금증이었다.

BEA WebLogic EAI, Oracle Service Bus, AIA 등 여러 제품을 이용해서 직접 시스템간의 연계 시나리오도 구현해보고, BMT에서 타의 솔루션을 테스트도 해봤지만, 먼저 상용 솔루션의 약점은, 솔루션에서 제공하는 시스템간의 연계에 있어서 성능적인 제약이 매우 많이 따른 다는 것이다. 대부분 Message Queue 구조의 비동기 구조를 통해서, 양단간에 데이타 연계를 하는 시나리오가 많은데, 이 경우 비주얼하게 각 단계에 대해서 모니터링은 가능 하지만, 대규모 처리에 있어서 비동기의 약점 때문에 성능적인 제약이 따르고 특히 대규모 메세지 처리에 있어서 그리 매끄럽지 못했던 경험이 있다. BPEL과 같은 제품의 경우 양단간의 연동 시나리오중, 개개별 메세지를 콘솔을 통해서 트레이스할 수 있는데, 하루에 수백,수천건을 연계하는 거래의 경우에는 GUI 콘솔을 통해서 메세지를 전달 내용이나 에러 내용을 추적한다는 것은 애초 부터 불가능한 일이다.

 그래서 실제 프로젝트 때에는 송수신 시스템을 연동하는 양쪽의 아답터 (JMS, 메인프레임, TP 모니터, ERP, CRM 등 다양한 시스템과 연동이 필요하기 때문에, 상용 제품에서 지원되는 아답터는 매우 중요하다)와 기본적인 메세지 플로우 이외의 부분은 대부분 직접 구현하였다. 그래서, EAI와 같은 제품에서 필요한 구조와 이런 것을 요구 사항에 맞게 빠르게 만들었으면 하는 프레임웍이 있었으면 했는데, Apache Camel을 보니, EAI와 같은 연계 업무성 프레임웍으로 적합해 보인다.

Apache Camel의 특징을 보면

Message Integration Framework

Camel은 기본적으로 Message Integration Framework이다. Framework임을 강조하는 것은, ESB EAI 제품과 같은 솔루션이라기 보다는 이를 개발하기 위한 Framework으로 보는 것이 적절하다고 판단된다.

이유는 ESB EAI는 메세지 연동 기능을 수행하기 위한 컨테이너가 있다. (즉 서버가 있다) 아무런 연동 인터페이스가 없더라도, 연동 인터페이스를 수용할 수 있는 컨테이너가 있고, 이 컨테이너들은 모니터링, 로깅등의 관리 기능을 제공한다. 그러나 CamelLibrary이다. 자체적으로 Container를 가지고 있지 않다. 다만, OSGI 컨테이너나 WAS, Spring등에 탑재 되서 돌아갈 수 있다. 쉽게 이야기 하면, EAI ESB와 같은 솔루션 제품은 서버를 설치해야 하고, 서버 관리를 위한 관리 콘솔 UI를 제공한다. Camel Jar로 된 라이브러리 이다.

상용 제품 연계에는 적절하지 않다.

Camel을 보면, 타 솔루션을 연동하기 위한 아답터, (Camel에서는 Component라고 부른다)가 있다. 50여개의 아답터가 있기는 하지만, 기업에서 많이 사용되는 솔루션의 아답터는 턱없이 부족하다. 예를 들어 SAP ERP, Sieble CRM, Tuxedo, AS/400 과 같은 애플리케이션에 대한 아답터 지원이 없다. 상용 제품의 경우 이런 아답터 지원이 강력하다.

반면, DB,FTP,HTTP,JMS와 같이 일반적인 애플리케이션 개발에 사용되는 기술에 대한 아답터는 많이 제공된다.

Apache Camel의 컨셉

Apache Camel의 컨셉을 대략적으로 도식화 해보면 다음과 같다.


Route

먼저 Route 라는 개념을 이해해야 하는데, Route하나의 시스템간의 연동 인터페이스를 정의한다. 예를 들어 시스템 A에서 B로 웹서비스를 이용해서 연동을 했다면 이것이 하나의 Route가 된다. Route 1:1 관계뿐만 아니라 1:N의 관계도 지원 하는데, A 시스템에서 B 시스템으로 JMS로 메세지를 보내고, 그후에 C 시스템으로 FTP 파일 전송하는 인터페이스가 있다면, 이 역시 하나의 Route로 정의할 수 있다.

Component

Route는 크게 Component Processor로 정의 된다. 연계 하고자 하는 송신 시스템과 수신 시스템이 있을때, 각 송신,수신 시스템의 주소(IP) end point라고 정의하며, Component는 일종의 아답터의 개념으로, 송수신 시스템의 프로토콜에 맞는 컴포넌트를 선택해야 한다. 예를 들어 송신 시스템을 FTP로 연동하고 싶다면, FTP 컴포넌트를 , JDBC로 연동하고 싶다면, JDBC 컴포넌트를 사용해야 한다. 컴포넌트는 송신 시스템으로 부터 메세지를 읽어드리고, 수신 시스템으로 메세지를 전송하는 역할을 한다.

Processor

메세지를 읽고 그냥 보내기만 한다면 별 문제가 없겠지만, 시스템간의 연동에는 메세지를 받은 후에 수신 시스템으로 보내기전에 하다못해 로깅을 남기더라도 무엇인가 항상 처리를 한다. 이렇게 송신 시스템으로 부터 받은 메세지를 수신 시스템에 보내기전에 무엇인가 처리를 하는 부분을 Processor라고 하는데, Processor는 그 특징에 따라서 몇가지로 나뉘어 질 수 있다.

1. Message Transformation

Message Format Transformation

메세지의 포맷을 변경하는 작업을 수행한다. 예를 들어 JSON으로 들어온 데이타를 XML로 변경하는 것들이 이에 해당한다.

Message Type Transformation

메세지의 데이타 타입을 변경한다. String으로 들어온 메세지를 jms:TextMessageType으로 변경하는 등의 작업을 수행한다.

이러한 메세지 변환은 Java Class를 정의해서할 수 있으며, 이외에도 Camel에서 미리 제공되는 Converter, XSLT를 이용한 변환 Apache Velocity의 같은 Template 엔진등 다양한 방법을 이용해서 변환이 가능하다.

2. Routing

메세지 라우팅은 들어온 메세지를 다수의 수신 시스템에 조건에 따라서 라우팅할 수 있는 기능이다.


Processor 단계는 쉽게 생각하면, 메세지를 받은 후, 보내기전에 무엇인가.. 를 하는 곳이다. 앞서 설명한것처럼, 메세지를 변환하거나, 라우팅할 수 도 있고, 로깅을 할 수도 있다. 들어온 메세지에 대해서 유효성 검증을 할 수 도 있다. 이러한 Processor는 자주 사용되는 메세지 변환등의 패턴은 Camel에 의해서 제공되지만, Java 클래스를 구현하면, 무엇이든지 가능하기 때문에 메세지에 대한 거의 모든 처리를 구현할 수 있는 단계이다.

 

이렇게, “송신 Component à Processor à 수신 Component”로 하나의 Route가 정의되는데, 이렇게 Route를 정의하여 객체화 시키는 것이 RouteBuilder이다. 이렇게 RouteBuilder에 의해서 생성된 Route CamelContext에 바인딩이 된다. CamelContext SpringContext와 유사한 개념으로 생각하면 된다. Route에 대한 집합이며, Route에 대한 라이플 사이클 (Start up,Stop)등을 관리한다.

간단한 개발 예제

이쯤에서 간단한 예제를 하나 보자. 다음은 FTP로 원격지 디렉토리의 파일을 읽어서 Local Directory에 쓰는 Camel Application이다.

먼저 Maven을 이용해서 다음과 같이 Camel Project를 만든 후에,

mvn archetype:create -DarchetypeGroupId=org.apache.camel.archetypes -DarchetypeArtifactId=camel-archetype-java -DarchetypeVersion=2.5.0 -DgroupId=camelinaction -DartifactId=order-router

다음과 같은 코드를 구현한다.

public class MyRouteBuilder extends RouteBuilder {

    public static void main(String... args) throws Exception {

        Main.main(args);

    }



    public void configure() {

        from("ftp://userid@168.1.2.3/camel/src/?password=password&stepwise=false")

         .to("file:c:/temp/");

 

    }

}

위의 코드는 RouteBuilder를 구현한 코드로 configure 메서드에서 FTP로 파일을 읽어와서 Local에 저장하는 route를 정의한 예이다.

DSL

눈치가 빠른 사람이라면, 위의 코드가 몬가 이상하다는 것을 느꼈을지도 모르겠다. configure 메서드안에 from(“….”).to(“….”).??

함수().함수() 호출? Java에서 이런 문법이 있었던가?

정확히 이야기 하면 이건 일반적인 Java Coding이 아니라 DSL (Domain Specific Language)이다. DSL은 특수목적으로 정의된 언어를 이야기 하는데, 여기서 사용된 Java DSL Route를 효율적으로 정의하기 위해서 Camel에 정의된 내장 스크립트 언어이다.

JavaDSL을 이용하면 상당히 쉽게 Route를 구성할 수 있는데, Camel은 이 Java DSL 뿐만 아니라, 다음과 같이 상당히 다양한 DSL을 제공한다.

Ÿ   Spring XML : XML 기반으로 정의된 DSL , Spring xml configuration 파일에 정의

Ÿ   Groovy,Scala DSL : Groovy 언어, Scala 언어 기반의 DSL

Ÿ   Annotation DSL : Java Annotation 기반의 DSL

Ÿ   기타 (Kotlin DSL, Bluprint XML etc)

(참고: http://camel.apache.org/dsl.html)

DSL Route Processor 부분을 정의하는데 주로 사용되는데, 송수신, Component만 정의되면, 사실상 시스템 연계에서 구현해야 되는 부분은 거의 Processor이며, Processor의 로직 대부분은 메세지 처리, 변환,라우팅에 해당하는 내용이기 때문에 특수목적의 DSL을 사용할 수 있으며, 또한 DSL 사용을 통해서 개발 생산성이나 코드양을 획기적으로 줄일 수 있다.

예를 메세지를 스트링으로 받아서 reverse하여, 화면에 출력하는 경우 Java DSL을 이용하면

from("direct:test")

      .transform(new Expression() {

         @Override

         public Object evaluate(Exchange e) {

            return new StringBuffer(e.getIn().getBody().toString()).reverse().toString();

         }

      })

      .process(new Processor() {

         @Override

         public void process(Exchange e) {

           System.out.println(e.getIn().getBody());

         }

      });

인데 반해서, Groovy DSL을 사용하면

from('direct:test')

      .transform { it.in.body.reverse() }

      .process { println it.in.body }

같이 단지 3줄이면 간단하게 끝난다.

Camel EIP

시스템 연동에는 사실 많은 패턴들이 있다. 메세지 변환, 라우팅, 로그 추적을 위한 글로벌 트렌젝션 ID, 장애시 재처리등등 여러가지 방법이 있는데, 이를 패턴화 시켜놓은 것이 Enterprise Integration Pattern (EIP)이다. EIP


책에 잘 정의 되어 있으니 참고하기 바란다.

사실 Camel에서 반영 및 설계되어 있는 EIP도 이 책에 있는 내용을 대부분 바탕으로 하여 구현되어 있다. (Camel을 쓸려면 이책은 꼭 한번 읽어봐야 하지 않을까 싶다.)

 

참고 : http://camel.apache.org/enterprise-integration-patterns.html 에 간단하게 대표적인 EIP 들이 정리되어 있다.

상용 지원

오픈소스가 무료이라서 저 비용의 장점을 가지고 있지만, 반대로, 오픈소스는 기술지원이나 교육 부분에서 매우 취약하다. 그래서 RedHat과 같이 오픈소스 제품에 대해서 subscription base로 기술 지원이나 교육 및 컨설팅을 제공하는 회사들이 존재하는데, Apache Camel 역시 http://fusesource.com/ 는 곳에서 상용 기술 지원을 받을 수 있다. (얼마전에 Redhat에 인수되었다.) Fuse Source의 경우, Camel을 이용하여 제품을 만들어서 판매하고 있으며, Camel 프로젝트에 참여하고 있는 Commiter 들을 많이 보유하고 있다고 한다.

http://fusesource.com/products/enterprise-camel/ 들어가면 Fuse Source에서 개발 및 판매하는 상용 Camel을 다운로드 받을 수 있으며, 개발 관련 및 트레이닝 자료들을 살펴볼 수 있다.

결론

짧은 시간내에 살펴본 제품이라서 아직 완벽한 특성은 파악하지는 못했다. 그러나 EAI, ESB와 같이 메세지 기반의 연동 처리를 하기 위한 시스템을 개발한다면, 개발 프레임웍으로 충분히 활용할만 하다. 특히 엔터프라이즈의 특정 애플리케이션 (ERP,CRM)등이 아니라 일반적인 프로토콜 (HTTP,JMS,TCP)등을 사용하여 그리 복잡하지 않으면서 고속의 연동 처리를 필요로 한다면 아주 유용하게 사용할 수 있을 것이라 판단된다.

시간 관계상 에러처리, 모니터링, 배포 및 확장성등 운영 관점에 대한 부분은 깊게 살펴보지 못했지만, 그냥 개발 프레임웍으로 본다면, 어짜피 운영 관련 부분은 직접 구현해야 하니까는 괜찮지 않을까 싶다.

다만 단순히 프레임웍이기 때문에, 클러스터링 기반의 HA나 부하 분산등의 기능을 제공하지 않는 것이 아쉬운 점이다.

시스템간의 연동의 중요성과 편이성을 경험한 나한테는, Apache Camel물건은 물건이다.” 라는 결론이 적절하다고나 할까?

 

ErrorHandling - http://bcho.tistory.com/716


참고:ErrorHandling에 대한 관련글 -

http://www.consulting-notes.com/2010/08/camel-exception-handling-overview.html 

정리가 잘되어 있네...

 

'아키텍쳐  > EAI' 카테고리의 다른 글

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (2) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21

Apache Camel note

엔터프라이즈 솔루션 | 2013.02.12 19:10 | Posted by 조대협

1. 프로젝트 생성하기

mvn archetype:create -DarchetypeGroupId=org.apache.camel.archetypes -DarchetypeArtifactId=camel-archetype-java -DarchetypeVersion=2.5.0 -DgroupId=camelinaction -DartifactId=order-router


으로  Camel Project 생성

2. 코드 
아래는 Spring을 이용하여, FTP로 파일을 읽어서 Local의 C:\temp에 복사하는 코드

public class MyRouteBuilder extends RouteBuilder {

    /**
     * A main() so we can easily run these routing rules in our IDE
     */
    public static void main(String... args) throws Exception {
        Main.main(args);
    }

    /**
     * Lets configure the Camel routing rules using Java code...
     */
    public void configure() {
        from("ftp://userid@168.1.2.3/camel/src/?password=password&stepwise=false")
        .to("file:c:/temp/");

    }
}


'엔터프라이즈 솔루션' 카테고리의 다른 글

Apache Camel note  (0) 2013.02.12
아키텍쳐에 있어서 레퍼런스의 중요성  (2) 2009.10.20
2009년 기술 전망  (2) 2009.01.06