Apache Camel을 이용한 대출 모집인 구현

이 글은 팁코 액티브엔터프라이즈(TIBCO ActiveEnterpise) 기반 통합 솔루션을 Apache Camel 기반 통합 솔루션으로 대체하는 방법을 설명합니다.

1. 들어가며

기업 통합 패턴(Enterprise Integration Patterns)의 "9장 사잇장: 복합 메시징"에서는 대출 모집인을 세가지 통합 도구를 각각 이용해 실질적인 통합 솔루션을 구현하는 예들을 설명한다. 첫째 예는 SOAP 프레임워크인 Apache Axis를 이용하고, 둘째 예는 마이크로소프트 MSMQ를 이용하고, 셋째 예는 상용 EAI 제품인 팁코 액티브엔터프라이즈(TIBCO ActiveEnterprise)를 이용한다. 이 책 9장에 등장하는 예들의 특징을 표로 보이면 다음과 같다.

구현	실행 방식	주소 지정	수집 전략	채널 형식	기술
1	동기	수신자 목록	채널	웹 서비스/SOAP	자바/아파치 액시스
2	비동기	수신자 목록	상관관계 식별자	메시지 큐	C#/마이크로소프트 MSMQ
3	동기,비동기	게시 구독 채널	상관관계 식별자	게시 구독	팁코 액티브엔터프라이즈

위 구현 예들은 중 "팁코 액티브엔터프라이즈를 이용한 구현"은 앞의 다른 예들과 달리 동기 요청과 비동기 메시징이 결합됐다는 점에서 차이가 있다. 즉 첫째 예는 SOAP을 이용한 동기 호출 기반의 솔루션이고, 둘째 예는 마이크로소프트 MSMQ를 이용한 비동기 메시징 솔루션인데, 셋째 예는 팁코 액티브엔터프라이즈를 이용해 요청은 동기로 수신하고 후속 처리는 비동기 메시징을 이용한다. 셋째 예의 메커니즘을 좀더 구체적으로 설명하면, "팁코 액티브엔터프라이즈를 이용한 구현" 예의 대출 모집인은 대출 클라이언트로부터 대출 견적을 동기로 요청 받아, 동기 호출로 신용 평가 기관에서 대출 클라이언트의 신용 점수를 얻고, 은행들에게 비동기 게시 구독 채널로 견적 요청을 브로드캐스트하고, 각 은행들로부터 대출 견적 응답을 비동기 메시지 큐(서브젝트)로 수집해, 최상 대출 견적을 대출 클라이언트에게 동기 응답으로 반환한다. 여기서 중요한 점은 상용 EAI 제품을 이용했다는 점이다.

그런데 기업 통합 패턴에서는 이런 메커니즘에 대한 해결책이 의도적이든 의도적이지 않든 부실하다. ("팁코 액티브엔터프라이즈를 이용한 구현"에서만 동기, 비동기의 결합에 대한 전체적인 예를 살펴볼 수 있다.) 기업 통합 패턴은, 비동기 메시징을 전제로 해결책들을 제시하는 책이므로, 비동기 인프라에서 동기 인프라에 접근하기 위한 패턴으로 서비스 액티베이터 패턴[EIP]을 설명하고, 애플리케이션이 비동기 인프라에 접근하기 위한 패턴으로는 메시징 게이트웨이 패턴[EIP]을 설명한다. 이와 같이 "팁코 액티브엔터프라이즈를 이용한 구현" 예를 벗어난 곳에서는 동기 인프라와 비동기 인프라가 결합된 종합적인 해결책을 비중 있게 다루지는 않는다. 상관관계 식별자 패턴[EIP]을 활용할 수도 있지만, 상관관계 식별자 패턴은 주로 비동기 요청의 응답을 상관시키기 위한 패턴이다.

이에 반해 팁코 액티브엔터프라이즈 같은 상용 EAI 제품들은 동기 호출과 비동기 응답을 상관시키는 종합적인 메커니즘을 내장한다. 이 기술은 간단한 것처럼 보이지만 실상은 그렇지 않다. 동기 호출은 응답을 반환할 때까지 동기 프로세스(스레드)가 (중간) 처리 결과와 처리 상태를 유지하는 반면, 비동기 메시징에서는 (중간) 처리 결과는 메시지와 필터 프로세스(스레드)들에 유지되고 처리 상태는 메시지가 위치한 채널로 관리한다. 즉 동기 호출과 비동기 메시징의 처리 결과와 상태 관리는 완전히 다른 방식이다.

그렇다면 동기 호출과 비동기 메시징을 결합하기 위해서는 상용 EAI 제품만 사용해야 하는 것일까? 그렇지 않다. 통합 프레임워크를 이용한다면 얼마든지 상용 EAI 제품처럼 동기 호출과 비동기 메시징을 결합할 수 있다. 그러므로 이 기능 때문에 상용 EAI 제품을 선택해야 한다는 기준은 전제하지 않아도 될 것이다.

2. 대출 모집인 솔루션 아키텍처 비교

기업 통합 패턴 9장의 "팁코 액티브엔터프라이즈를 이용한 구현" 예의 팁코 대출 모집인 솔루션 아키텍처는 다음과 같다.

위 아키텍처 그림에서 테스트 대출 클라이언트와 대출 모집인 사이와 대출 모집인과 신용 평가 기관 사이는 팁코의 동기 랑데부 전송을 사용하고, 대출 모집인과 은행들 사이는 비동기 랑데부 전송을 사용한다. 중간의 프로세스 관리자는 팁코의 시각적 도구와 스크립트와 메타 저장소 등을 이용하여 메시지 송수신 흐름과 처리 상태를 관리한다. 보다시피 동기 메커니즘과 비동기 메커니즘이 결합되어 있다. (이 솔루션 아키텍처는 기업 통합 패턴의 복합 메시징의 예를 보여주기 위해 모든 통신 인프라를 팁코 랑데부 통신으로 구성한 것이다. 실무적을 보면 대출 클라이언트는 원격지에서 인터넷으로 대출 모집인에 접속할 것이고, 신용 평가 기관이나 은행들도 원격지에 위치해 전용선이나 인터넷으로 대출 모집인을 연결할 것이다.)

위 솔루션 아키텍처에 대응되는 "Apache Camel을 이용한 대출 모집인 솔루션 아키텍처"는 다음과 같다.

"팁코 액티브엔터프라이즈를 이용한 구현"에서 달라진 점은 Apache Camel을 이용한 대출 모집인 솔루션은 팁코 동기 랑데부 전송을 좀더 범용적인 SOAP/HTTP 전송으로 대체하고, 팁코 비동기 랑데부 전송을 내부 메시징과 Apache ActiveMQ의 JMS Topic으로 대체하고, 프로세스 관리자를 프로세스 관리자(웹 서비스 빈) 라우팅과 응답 관리자 라우팅으로 대체한다는 점이다.

3. 대출 클라이언트 인터페이스

3.1. 대출 모집인

앞서도 간단히 언급했듯이 "Apache Camel를 이용한 구현"은 "팁코 액티브엔터프라이즈를 이용한 구현"의 팁코 동기 랑데부 전송을 SOAP/HTTP 동기 웹 서비스로 대체한다. 이를 위해 대출 모집인은 대출 견적 요청 서비스를 스프링 설정 파일에 SOAP 웹 서비스 인터페이스 빈으로 다음과 같이 노출한다.

brokerQouteServiceEndpoint 빈은 웹 서비스 인터페이스 객체고, brokerQouteServiceImp 빈은 웹 서비스 객체다. BrokerQouteServiceImp 빈 클래스가 웹 서비스를 실제 수행한다. 그러므로 BrokerQouteServiceImp 클래스가 실제 프로세스 관리자[EIP]다. 여기서는 서비스 우선 개발(service first development) 방법에 따라 웹 서비스 인터페이스를 먼저 정의했다. 이 설정으로 대출 클라이언트에 대한 대출 모집인의 SOAP 웹 서비스 노출을 완성된다. 서비스 우선 개발 방법의 자세한 설명은 "Apache Camel을 이용한 마이크로 웹 서비스 개발" 글을 참고하기 바란다.

BrokerQouteService 인터페이스는 다음과 같다.

BrokerQouteService 는 평범한 자바 인터페이스다. 이 인터페이스를 상속한 BrokerQouteServiceImp 빈 클래스는 프로세스 관리자 절에서 설명한다.

3.2. 대출 클라이언트

대출 클라이언트는 대출 모집인이 노출한 웹 서비스를 호출한다. 그런데 이 예는 대출 모집인과 대출 클라이언트가 하나의 스프링 설정 파일을 공유하므로, 대출 클라이언트는 위한 (호출 측) 웹 서비스 빈은 따로 설정하지 않는다. (대출 클라이언트는 (호출 측) 웹 서비스 빈으로 대출 모집인의 (서버 측) 웹 서비스 빈을 사용한다.)

웹 서비스를 호출하는 대출 클라이언트의 Camel 라우팅 설정은 다음과 같다.

대출 클라이언트 라우팅은 5초마다 bean:client 엔드포인트를 실행한다. 그러면 대출 클라이언트 빈은 대출 모집인의 웹 서비스를 호출한다.

LoanQouteClient 빈 클래스는 다음과 같다.

LoanQouteClient는 client 생산자 템플릿 객체를 이용해, 대출 모집인 웹 서비스로 동기 호출을 수행하고 반환된 결과를 화면에 출력한다.

4. 신용 평가 기관 인터페이스

4.1. 신용 평가 기관

신용 평가 기관도 동기 웹 서비스를 노출하므로, 신용 평가 기관은 신용 평가 서비스를 스프링 설정 파일에 SOAP 웹 서비스 인터페이스 빈으로 다음과 같이 노출한다.

creditScoreServiceEndpoint 빈은 웹 서비스 인터페이스 객체고, creditScoreServiceImp 빈은 웹 서비스 객체다. CreditScoreServiceImp 빈 클래스가 웹 서비스를 실제 수행한다. 여기서도 웹 서비스 개발에 서비스 우선 개발(service first development) 방법을 사용한다.

CreditScoreService 인터페이스는 다음과 같다.

CreditScoreService 는 평범한 자바 인터페이스다.

CreditScoreServiceImp 빈 클래스는 다음과 같다.

신용 평가 기관의 신용 점수 계산을 시뮬레이션 하기 위해 랜덤 메소드를 사용한다.

4.2. 대출 모집인

대출 모집인은 위에서 설명한 creditScoreServiceEndpoint 빈 설정을 그대로 사용해 신용 평가 기관에게 웹 서비스를 요청한다. 대출 모집인은 BrokerQouteServiceImp 빈에서 다음과 같이 creditBurea 생산자 템플릿을 이용해 신용 평가 기관에게 (동기) 웹 서비스를 호출한다. (BrokerQouteServiceImp의 전체 소스는 프로세스 관리자 절에 있다.)

5. 은행 인터페이스

5.1. 은행

이 예에서 각 은행들은 게시 구독 채널인 ActiveMQ의 JMS Topic에 가입한다. 그러므로 각 은행들은 스프링 설정 파일에 다음과 같은 JMS 수신자(가입자) Camel 라우팅 설정을 갖는다.

각 은행은 bank.loan.request 게시 구독 채널로부터 견적 요청을 수신해, bank? 빈 엔드포인트를 수행하고, 수행 결과 메시지를 bank.loan.relpy 채널로 응답한다.

BankQouteService 인터페이스는 다음과 같다.

BankQouteService 는 평범한 자바 인터페이스다.

BankQouteServiceImp 빈 클래스는 다음과 같다.

BankQouteServiceImp는 기업 통합 패턴 9장의 "MSMQ를 이용한 비동기 구현"을 참조했다. 요청마다 다른 견적을 응답하기 위해 랜덤 메소드를 사용한다.

5.2. 대출 모집인

대출 모집인은 BrokerQouteServiceImp 빈에서 다음과 같이 auction 생산자 템플릿을 이용해 bank.loan.request 게시 구독 채널로 견적 요청 메시지를 게시한다. (BrokerQouteServiceImp의 전체 소스는 프로세스 관리자 절에 있다.)

6. 대출 모집인 프로세스 개요

팁코 예의 대출 모집인 프로세스 정의는 다음과 같다.

Apache Camel 예는 위 프로세스 워크플로우를 프로세스 관리자 라우팅 설정인 borkerProcessManager와 응답 관리자 라우팅 설정인 brokerReplyManager로 대체한다. borkerProcessManager는 대출 클라이언트의 동기 요청을 처리하고, brokerReplyManager는 비동기로 은행들로부터 응답을 수신해 최상의 결과를 선택한다.

프로세스 관리자 borkerProcessManager의 라우팅 설정은 다음과 같다.

borkerProcessManager는 팁코 프로세스 워크플로우의 첫 번째부터 마지막까지 직선상에 위치한 액티비티들을 대체한다. borkerProcessManager는 은행들에게 대출 견적을 게시한 후 견적 결과가 완성될 때까지 실행 스레드를 중지한다. (자세한 설명은 뒤에 나온다.)

응답 관리자 brokerReplyManager의 라우팅 설정은 다음과 같다.

brokerReplyManager는 팁코 프로세스 워크플로우에서 오른쪽에 위치한 "Process Received Quote From Bank" 액티비티를 대체한다. JMS 큐로부터 은행들의 견적 응답을 수집해 최상 견적의 선택하고 borkerProcessManager를 재시작시킨다.

7. 대출 모집인 프로세스 상세

7.1. 프로세스 관리자

프로세스 관리자는 웹 서비스를 통해 대출 클라이언트로부터 대출 견적 요청을 수신하고, 신용 평가 기관 웹 서비스를 호출하고, 은행들에게 견적 요청을 게시하고, 최상의 대출 견적을 대출 클라이언트에게 반환한다.

다음은 프로세스 관리자를 위한 빈들과 borkerProcessManager 라우팅 설정이다.

BrokerQouteServiceImp 빈 클래스의 전체 소스는 다음과 같다.

BrokerQouteServiceImp은 프로세스 관리자로서 신용 평가 기관 인터페이스와 은행 견적 요청을 위한 게시 구독 채널을 멤버 변수로 갖고, 팁코 액티브엔터프라이즈의 대출 모집인 프로세스의 대부분의 액티비티들을 구현한다. BrokerQouteServiceImp은 게시 구독 채널로 은행 견적 요청을 브로드캐스트한 후 잡 저장소와 자바의 동기 메커니즘을 이용해 스레드를 중지하고 brokerReplyManager 라우팅이 job 객체를 깨울 때까지 대기한다.

7.2. 응답 관리자

응답 관리자는 은행들로부터 견적 응답을 수신하고, 견적 응답을 수집하고, 최상의 견적을 선택하고, 프로세스 관리자를 재시작시킨다.

다음은 응답 관리자를 위한 응답 수신 빈들과 brokerReplyManager 라우팅 설정이다.

수집기는 요청마다 10초동안 은행들로부터 견적들을 수집한다. bankReplyAggregator 빈은 은행들의 견적 응답을 bids 객체에 추가한다.

BankReplyAggregator 클래스는 다음과 같다.

이 수집기는 은행으로부터 수신한 메시지로부터 상관관계 식별자를 추출하여 상관 관계 식별자로 잡 저장소에서 잡을 꺼내와 bid 객체에 은행 응답을 추가하고, 다시 잡 저장소에 잡을 저장한다. AggregationStrategy을 상속해 Apache Camel의 수집 로직 전략 메커니즘을 이용했다.

ProcessReceivedQoute 클래스는 다음과 같다.

ProcessReceivedQoute 는 잡 저장소로부터 잡을 꺼내고, 은행 응답 객체를 생성하고, 완성된 bid 목록으로부터 최상의 견적을 찾아, 응답을 채운 후, 잡 객체의 자바 동기화 메커니즘을 이용해 BrokerQouteServiceImp 빈에서 중지된 스레드를 깨운다.

7.3. 잡 저장소

동기 프로세스와 비동기 메시징을 결합하려면 세션 객체 저장소가 필요하다. 이 저장소는 스프링 설정 파일에 빈과 Camel 라우팅을 이용해 설정한다.

잡 저장소의 스프링 빈과 Camel 라우팅 설정은 다음과 같다.

JobRepository 인터페이스는 다음과 같다.

JobRepository 인터페이스를 상속한 EhCacheRepository 클래스는 다음과 같다.

JobRepository 객체는 BrokerQouteServiceImp 클래스 등에서 멤버 변수로 참조된다.

8. 실행

대출 클라이언트는 5초마다 대출 모집인 웹 서비스에게 대출 견적을 요청하고, 대출 모집인은 대출 견적 요청을 은행들에게 게시하면, 5개 은행들은 각각 자신의 대출 견적을 응답하고, 대출 모집인은 5개의 대출 견적 응답 중 최상의 대출 견적을 선택해, 대출 클라이언트에게 반환한다. 아래는 이 솔루션을 실행한 결과다.

이 시뮬레이션 솔루션은 Camel 라우팅 설정으로 실행되며, 대출 클라이언트, 대출 모집인, 신용 평가 기관, 은행들을 모두 포함한다. Apache CXF 프레임워크가 포함되어 있으며, 테스트를 위해 Apache ActiveMQ가 함께 실행된다. 실행 결과의 아래를 보면 대출 클라이언트는 각 대출 견적 요청마다 다른 은행의 견적을 최상의 견적으로 반환 받을 것을 볼 수 있다.

9. 맺음말

필자는 이 글에서 Apache Camel로도 팁코 액티브엔터프라이즈로 구축한 통합 솔루션을 충분히 대체할 수 있음을 보였다. 게다가 팁코 액티브엔터프라이즈로 구축한 솔루션 예보다 Apache Camel로 구축한 솔루션 예가 설정이나 코딩을 더 적게 사용했다. 이렇게 작업량을 줄일 수 있었던 이유는 Apache Camel의 DSL(Domain Specific Language, 도메인 특화 언어)와 이미 완성된 컴포넌트들을 이용했기 때문이다. 웹 서비스를 위해 단지 몇 십 줄의 설정과 코딩이 필요했으며, JMS 서비스를 위해서도 몇 십 줄의 설정과 코딩을 추가했다. 이점이 Apache Camel이 갖는 강력한 생산성이다.

이와 같이 오픈 소스 통합 프레임워크인 Apache Camel을 이용하면 팁코와 같은 상용 EAI 제품으로 구축한 통합 솔루션을 대체하거나 통합 솔루션을 새롭게 구축할 수도 있으나, 여기에는 전제가 따른다. 기업 통합 패턴으로 아키텍처를 분석할 수 있어야 하며, 기존 솔루션의 아키텍처에 대한 이해도 충실해야 하고, Apache Camel과 Spring 프레임워크와 통합에 포함되는 다양한 기술에 대해서도 깊은 이해가 있어야 한다. 이런 준비가 없다면 기업 애플리케이션들을 제대로 통합할 수 없을 것이다. 물론 이런 전제는 상용 EAI 제품을 도입하더라도 동일하게 적용된다. 상용 EAI 제품도 어떤 기능을 제공한다고 해서 단순히 몇 줄의 설정이나 코딩으로 기능이 동작하는 것은 아니다. 상용 EAI 제품을 제대로 활용하려고 해도 통합을 위한 각종 어댑터들을 이해해야 한다. (실제로 어떤 EAI 상용 제품은 기업 통합 패턴의 번호표 패턴[EIP]를 제공하기 위해 수십 페이지 정도의 설정 절차를 숙지해야 하는 경우도 있다.) 그럼에도 상용 EAI 제품만이 해결할 수 있는 통합은 없으며, 오픈 소스를 잘 이용한다면 그에 못지 않는 통합 품질뿐만 아니라 솔루션 구조도 단순화시킬 수 있다는 점은 고무적인 것이다.

필자는 기업 통합 패턴과 통합 프레임워크에서 많은 가능성을 전망하고 있다. 기업 통합 패턴과 Apache Camel 통합 프레임워크는 이 글의 예처럼 상용 EAI인프라를 대체해 기업을 통합시킬 뿐만 아니라, ETL, 배치, 동기화 등 통합의 각론 분야에서도 충분히 가치를 발휘한다. 또한 새롭게 등장하는 개념의 마이크로 서비스(Microservice)를 개발하는 데 있어서도 Apache Camel은 가장 적합한 도구가 되어 가고 있다. 그러므로 아키텍트와 개발자들도 기업 통합 패턴과 Apache Camel에 관심을 갖기 바란다.

참고 사이트

• 1) [EIP] 기업 통합 패턴(Enterprise Integration Patterns)
• 2) [EAA] Patterns of Enterprise Application Architecture
• 3) Apache Camel을 이용한 마이크로 웹 서비스
• 4) Apache Camel
• 5) Apache CXF
• 6) Spring Framework
• 7) Apache ActiveMQ
• 8) Ehcache
• 9) Camel in Action
• 10) Apache Camel Developer's Cookbook
• 11) SOAP
• 12) Microservices
• 13) TIBCO Integration
• 14) 슬라이드 쉐어 - 기업 통합 패턴 강의
• 15) 기술 자문 문의

실시간 트위터 이미지 사이트 개발기 3

웹소켓(WebSocket)

웹 브라우저에서 오랫동안 사용한 통신 프로토콜은 HTTP다. HTTP는 동기 방식의 요청-응답 프로토콜로 반드시 클라이언트인 웹 브라우저가 요청해야만 서버인 웹 서버가 응답하는 프로토콜이다. 그러므로 HTTP 접속은 요청으로 시작해서 요청-응답을 반복하다가 반드시 응답으로 끝난다. 이 방식은 최초에 웹 혁명을 이끄는 데 있어서 중요한 단순성을 제공했다. 단순한 요청-응답 방식은 극단적인 수준까지 요청-응답을 처리하도록 서버를 개선하도록 했다. 범용 웹 사이트를 가능하게 하기 위해 TCP/IP 스택은 비약적으로 개선됐고, 아파치 웹 서버 같은 견고하고 성능도 좋은 서버들도 개발됐다. 사실 웹 기술이 보급되기 전까지 전통적인 클라이언트 서버 방식의 서버는 수십 클라이언트들의 접속을 처리할 수 있다면 할 일을 충분히 한다고 인정받던 시절도 있었다. 그러나 웹의 보급과 발전 덕분에 서버는 동시에 수천 접속을 유지하고 수만 요청도 처리할 수 있도록 비약적으로 진화했다. C10k 문제(일만 동시 접속 문제)라는 용어가 등장할 정도로 다수 동시 접속 처리 문제는 개발자들을 골치 아프게 했지만, 현재는 다양한 아키텍처 패턴을 이용해 이 문제를 극복하고 있다. 그러나 시대가 발전하면서 요청-응답으로는 처리하기 어려운 시나리오들도 웹 브라우저를 이용해 처리하고자 하는 요구가 끊임없이 확대됐다. 예를 들어 웹에서 실시간으로 변하는 증권 시세를 표시하려면 요청-응답 방식만으로는 해결할 수 없었다. 해결했다손 치더라도 속도나 성능 효용성이 충분하지 못했다. 그래서 자바 애플릿이나 액티브X 컨트롤을 이용해 소켓 통신으로 문제를 우회하려고도 했다. 그러나 이런 플러그인 기술들도 만족스럽지 못했고 보안 취약성이 또 다른 문제가 되기도 했다. 또 다른 예로 웹 채팅 애플리케이션이 있다. 웹 채팅을 구현하려면 Ajax 같은 복잡한 기술을 사용해야 그런대로 가능했다. 이런 방법들은 온전한 비동기 통신 기술이 아니다. 채팅은 상대방이 입력한 글이 웹 브라우저의 요청 없이도 즉시 본인의 웹 브라우저에 도착해야 하는 전형적인 비동기 통신 모델이다. 그런데 Ajax도 반드시 요청해야만 응답을 (비동기로) 수신할 수 있으므로 온전한 비동기 통신 방식은 아니다. 결국 요청-응답 방식의 HTTP 프로토콜 덕에 가질 수 있었던 단순성이 웹의 성공을 이끌었던 반면, 이 단순성은 웹 기반 비즈니스 시나리오가 확대됨에 따라 점점 부족함으로 작용하게 됐다. 완전한 비동기를 웹 브라우저에서 사용하려고 할 때, 단순함이 도리어 복잡한 Ajax 방식을 사용하게 강요한 면도 있었다. 이와 같이 확장되는 웹 기반 비즈니스 시나리오를 충족시키기 위해서는 좀더 편리한 통신 방법이 필요했다. 그리고 그 산물로 완전한 양방향 통신을 지원하는 웹소켓 프로토콜이 등장했다.

웹소켓 프로토콜은 상당히 최근에 등장했다. 2011년에서야 IETF는 웹소켓 프로토콜을 정의한 RFC 6455 문서를 표준으로 제정했다. 이에 따라 웹 브라우저들은 2011년부터 상호 호환성이 보장되는 RFC 6455 웹소켓 표준으로 웹소켓 지원을 통일했다 크롬 16, 사파리 6, 파이어폭스 11, 인터넷 익스플로러 10 이후 웹 브라우저들은 RFC 6455 웹소켓 표준을 준수한다. 웹소켓은 글자 그대로 소켓과 거의 같은 기능을 제공한다. 즉 일반적인 소켓이 제공하는 양방향 통신을 제공한다. (그러나 TCP/IP 계층보다 상위 계층 프로토콜로 독자적인 패킷 구조를 갖는다.) 그러므로 HTTP 프로토콜과 달리 접속이 완성된 후 TCP 소켓 접속처럼 서버의 우선 전송도 가능해 진다. 즉 요청-응답 순서가 클라이언트에서 서버뿐만 아니라 서버에서 클라이언트로도 가능하다. 그러므로 웹소켓은 클라이언트 풀(pull) 뿐만 아니라 서버의 푸시(push)도 어렵지 않게 제공한다. 그 결과 웹소켓은 동기 방식뿐만 아니라 비동기 방식 통신 프로토콜로 완벽하게 구현하게 하는 기반을 제공한다.

웹소켓은 HTTP 프로토콜에서 프로토콜 갱신 핸드쉐이크를 통해 웹소켓 프로토콜로 전환이 되는 구조를 가지고 있어, HTTP 표준 포트인 TCP 80 포트를 그대로 활용할 수 있다는 장점을 가진다고 한다. 그러나 이 부분에 있어서 필자는 다른 견해를 갖는데, 그 이유는 TCP 80 포트를 바인드하는 웹 서버가 HTTP 프로토콜과 웹소켓 프로토콜을 동시에 처리하려면 내부 아키텍처가 상당히 다른 두 프로토콜 스택을 서버 안에 함께 포함해야 한다. 웹소켓은 Stomp 같은 상위 프로토콜의 하부 프로토콜로 사용되기도 하는데 이 경우 또 다른 Stomp 프로토콜 스택도 웹 서버에 포함시켜야 하는 문제가 발생한다. 프로토콜 스택 개발은 웹 서버 개발과는 다른 문제일 수 있다. 그리고 아직 웹 서버들이 충분이 웹소켓을 다루는 기술이 성숙되지 않은 문제도 있다. 그러므로 웹소켓을 사용해야 한다면 웹 서버와 별도로 전용 웹소켓 서버를 운영하면서 TCP 포트를 별도로 개방하거나 방화벽 등의 정책으로 인해 접속 문제가 있을 수 있다면 별도 서버에 또 다른 TCP 80 포트를 개방해 웹소켓 서버를 운영하는 방법이 합리적이지 않을까 생각된다. 아직까지는 웹소켓의 사용 방식에 대해 뚜렷한 일관적인 방식이 등장하고 있지는 않은 것 같다.

웹소켓의 또 다른 문제는 웹소켓 위의 애플리케이션 프로토콜이 충분히 성숙돼지 않았다는 점이다. 웹소켓은 TCP 계층에 아주 얇은 층을 추가한다. 그러므로 웹소켓을 직접 사용하는 것은 마치 TCP 소켓을 직접 사용하는 것과 같다. 일반적으로 개발자들은 TCP 소켓을 직접 사용하기보다 상위 애플리케이션 프로토콜을 이용한다. 이런 예로 Telnet, Ftp, Ssh, HTTP, AMQP, OpenWire, Stomp, MQTT 등등이 애플리케이션 프로토콜이다. 그러므로 웹소켓을 충분히 잘 활용하려면 웹소켓 위의 애플리케이션 프로토콜이 많아지고 또 쓰임새도 정비돼야 한다.

실시간 트위터 이미지 사이트의 웹소켓 사용

웹소켓을 먼저 설명한 이유는 실시간 트위터 이미지 사이트도 웹소켓을 사용하기 때문이다. 실시간 트위터 이미지 사이트는 웹소켓을 아주 쓸모 있게 사용한다. 실시간 트위터 이미지 사이트의 전체적인 정보 흐름과 통신 프로토콜들은 다음과 같다.

1) 미국에 위치한 실시간 트위터 이미지 사이트의 백그라운드 Camel 서비스는 트위터에서 고양이로 트윗을 검색해 결과들을 수신한다. 2) 그 중 이미지를 포함한 트윗을 추출해 한국에 위치한 ActiveMQ 서버에 OpenWire 프로토콜을 사용해 메시지로 전달한다. 3) 메시지를 수신한 ActiveMQ 서버는 메시지를 게시 구독 방식의 토픽에 게시한다. 실시간 트위터 이미지 사이트에서 페이지를 조회한 웹 브라우저는 이미 웹소켓 위의 Stomp 프로토콜로 ActiveMQ 서버에 접속한 토픽 구독자다. 4) 토픽에 게시된 고양이 이미지 트윗 메시지 사본은 웹소켓 위의 Stomp 프로토콜을 통해 ActiveMQ 서버로부터 웹 브라우저로 비동기적으로 전송된다. 웹 브라우저는 비동기적으로 수신된 메시지를 웹 브라우저 화면에 고양이 쎔네일 이미지로 출력한다.

미국에 위치한 실시간 트위터 이미지 사이트 웹 서버의 Camel 서비스와 대한민국에 위치한 ActiveMQ 서버는 메시징 프로토콜로 OpenWire 프로토콜을 사용했다. OpenWire 프로토콜은 다양한 언어나 플랫폼에서 ActiveMQ에 접속할 수 있게 하는 메시징 프로토콜이다. ActiveMQ는 OpenWire, AMQP, XMPP, MQTT 등 다양한 메시징 프로토콜을 지원한다. 웹 브라우저와 ActiveMQ 서버는 웹소켓 위의 Stomp 프로토콜을 사용한다. Stomp 프로토콜을 사용한 이유는 WebSocket 위의 Stomp 프로토콜을 지원하는 STOMP.js라는 JavaScript 라이브러리가 있고, ActiveMQ 서버도 웹소켓 위의 Stomp 프로토콜을 잘 지원하기 때문이다. 참고로 TCP/IP 위의 Stomp 프로토콜과 웹소켓 위의 Stomp 프로토콜은 호환되지 않는다. TCP/IP 위의 Stomp 프로토콜은 Stomp 프로토콜이 TCP 계층 바로 위에 구현되는 반면, 웹소켓 위의 Stomp 프로토콜은 TCP 계층 위에 웹소켓 계층이 있고 그 위에 Stomp 프로토콜이 구현된다. 그러므로 Stomp 프로토콜을 지원한다고 해도 직접적으로 웹소켓 위의 Stomp 프로토콜로 통신할 수 없다. 문자 기반 프로토콜이어서 인지, 웹소켓 위에서 가장 구현하기 쉬워서 인지 상당히 이른 시기에 웹소켓 위의 Stomp 프로토콜은 등장했다. 한편 RabbitMQ의 기본 프로토콜인 AMQP 프로토콜이 웹소켓 위의 JavaScript 라이브러리로 개발이 된다면 웹 브라우저에서도 AMQP 프로토콜을 사용할 수 있을 것이다. 그러나 현재 RabbitMQ 쪽에서는 Node.js와 연결에 주력하고 있는 것 같다. RabbitMQ는 Node.js에서 동작하는 AMQP JavaScript 라이브러리까지만 지원하고 있다. 아마도 이 JavaScript 라이브러리는 TCP/IP 위에서 구현된 라이브러리일 것이다. 즉 AMQP 프로토콜의 하부 통신 계층이 TCP일 것이다. 그러므로 현재 웹소켓 위에서 사용할 수 있는 메시징 프로토콜 라이브러리는 STOMP.js이 유일하다. (글을 쓰면서 좀더 조사해 보니 최근 들어 웹소켓 위의 MQTT 프로토콜도 사용 가능한 것으로 보인다. 이에 대한 검토는 독자들에게 맡긴다!) 여기서 주목할 점은 메시징 프로토콜과 메시지 채널(큐, 토픽)은 서로 다른 종류의 개체라는 점이다. 즉 같은 메시지 채널이라도 여러 프로토콜로 발신, 수신, 게시, 구독이 가능하다. 실시간 트위터 이미지 사이트도 동일한 토픽에 대해 메시지 전송은 OpenWire 프로토콜을 메시지 수신은 웹소켓 위의 Stomp 프로토콜을 사용했다.

웹소켓을 사용하면 웹 브라우저를 기업 통합 솔루션의 비동기 메시징 컴포넌트의 일원으로 포함시킬 수 있게 된다. 실시간 트위터 이미지 사이트는 트위터 이미지 메시지를 비동기로 전송하는 용도로 간단하게 웹소켓을 사용했지만, 앞서 언급했듯이 웹소켓은 웹 브라우저의 요청-응답 또는 폴링 방법으로는 해결하기 어려운 실시간 비동기 정보를 손쉽게 처리할 수 있게 해준다. 예를 들어 실시간 뉴스, 실시간 대시보드, 실시간 제어, 실시간 게임, 실시간 그래프 애플리케이션 같은 것들도 웹 브라우저로 구현할 수 있는 가능성을 열어준다. 이를 위해서는 SVG(SVG(Scalable Vector Graphics)나 Canvas 같은 HTML5의 다른 기능들도 활용해야 할 것이다. 또한 필자도 웹소켓이 요청-응답 형식의 기존 HTTP 프로토콜을 완전히 대체할 수 있다고는 생각지 않는다. 기존 HTTP 프로토콜은 화면 조회, 웹 서비스, Restful, Ajax RPC 등 다양한 요청-응답 패턴을 여전히 잘 수용한다. 그러므로 웹소켓의 역할은 요청-응답 방식의 HTTP 프로토콜로는 쉽게 해결할 수 없었던 실시간 비동기 통신을 웹 브라우저에 제공함으로 웹 브라우저의 사용 범위를 넓혀주는 것으로 봐야 한다. 즉 실시간 비즈니스 시나리오가 포함된 멋진 웹 애플리케이션을 만들려면, HTTP 프로토콜과 웹소켓 프로토콜 중 어느 하나만을 고집하는 것이 아니라 서로의 장점을 함께 활용해야 한다. 편식은 언제나 몸을 해롭게 한다.

웹소켓은 표준이 2011년에 완성됐고 표준을 지원하는 브라우저도 2011년 이후 버전들이고 특히 대한민국에서 많이 사용하는 인터넷 익스플로러는 버전 10부터 지원되므로 아직은 웹소켓을 사용한 사례가 많지 않은 것도 사실이다. 그러나 웹소켓을 범용 서비스가 아닌 기업 통합 등 기업의 특화된 서비스에 이용한다면 실시간 정보의 사용에 있어서 전용 클라이언트 애플리케이션 못지 않게 훌륭한 웹 브라우저 애플리케이션을 개발할 수 있을 것이라 기대한다. 이 글을 통해 독자들도 웹소켓의 가능성에 주목할 수 있는 계기가 됐으면 한다.

참고 사이트

• 1) 실시간 트위터 이미지 웹 페이지

• 2) 실시간 트위터 이미지 사이트 개발기 1

• 3) 실시간 트위터 이미지 사이트 개발기 2

• 4) Apache ActiveMQ

• 5) Apache Camel

• 6) 레드햇 오픈시프트 클라우드

• 7) Bilgin Ibryam의 올림픽 실시간 트위터 이미지 블로그

• 8) WebSocket

• 9) OpenWire Version 2 Specification

• 10) Stomp(Simple Text Oriented Messaging Protocol)

• 11) STOMP.js

• 12) Ajax for Java developers: Build dynamic Java applications

• 13) The C10K problem

실시간 트위터 이미지 사이트 개발기 2

시스템 구성

실시간 트위터 이미지 사이트의 웹 서버는 미 동부에 위치한 레드햇 오픈시프트 클라우드에서 운영된다. 그러나 이 서비스에 참여하는 메시징 시스템은 대한민국에 위치한다. 즉 실시간 트위터 이미지 사이트는 범세계적인 분산 시스템이다. 이 실시간 트위터 이미지 사이트의 시스템 구성은 다음과 같다.

위 구성도는 트위터 이미지 사이트의 서버 배치와 실행 순서를 설명한다. 미국 동부에 위치한 오픈시프트에서 운영되는 웹 서버는 트위터 서버로부터 실시간으로 고양이 이미지를 포함한 트윗을 추출하고 메시지로 변환하여, 이 트윗 메시지를 대한민국에 위치한 ActiveMQ 서버의 토픽으로 실시간 전송한다. 웹 브라우저는 미국 동부에 위치한 웹 서버의 트위터 이미지 웹 페이지를 조회하면서 동시에 대한민국에 위치한 ActiveMQ 서버에 웹소켓으로 접속하여 ActiveMQ의 토픽을 구독한다. ActiveMQ 서버에서 트윗 메시지는 실시간으로 토픽에 게시 중이므로 토픽을 구독하는 웹 브라우저는 ActiveMQ 서버의 토픽으로부터 트윗 메시지를 실시간으로 수신한다. 이렇게 실시간 트위터 이미지 사이트에서 “고양이를 보여줘” 웹 페이지에 접근한 웹 브라우저는 두 대륙에 걸쳐 분산되어 있는 서버들을 이용한다.

실시간 트위터 이미지 사이트의 아키텍처가 일반적인 웹 서비스의 아키텍처와는 다른 점은 분산 아키텍처를 위해 ActiveMQ라는 메시징 시스템과 웹소켓 기술을 추가로 사용했다는 점이다.

이 글을 읽는 독자는 왜 일반적인 웹 서비스 아키텍처를 사용하지 않고, 메시징 기반의 아키텍처를 추가로 이용한 것일까? 라는 의문을 가질 수 있을 것이다. 일반적으로 웹 서비스는 요구-응답 방식에 적합한 아키텍처이다. 실시간 트위터 이미지 사이트처럼 지속적으로 데이터 스트림을 처리해야 하는 아키텍처 모델로는 적합하지 않다. 적합하지 않다라는 뜻은 웹 서비스의 요구-응답 통신은 동기 통신 기술로 지속적인 메시지 흐름을 갖는 비동기 통신을 구현하기 위해서는 기술적인 어려움과 복잡성을 부가해야 한다라는 말이다. 또한 요구-응답 방식의 서비스로는 게시-구독 방식의 서비스를 구현하는 것이 쉽지 않다. 더 나아가 메시지의 흐름 제어를 처리하는 것도 쉽지 않다.

반면 메시징 시스템을 이용하는 경우, 참여 시스템들은 느슨한 결합 아키텍처(loosely coupled architecture) 구조를 갖게 된다. 메시징 시스템을 통해 비즈니스 로직들이 서로 분리되어 시스템들 사이 상호 의존성이 감소한다는 말이다. 실시간 트위터 이미지 사이트는 ActiveMQ 메시징 시스템을 이용하여 웹 브라우저와 웹 서버 사이 단단하게 결합될 수 있었던 트위터 비즈니스 로직을 독립적으로 동작 가능하게 분리했다. 그 결과 실시간 트위터 이미지 사이트는 웹 서버의 중단이나 이전 없이 비즈니스 로직을 다른 서버로 이전하거나 심지어 다른 대륙에 위치시킬 수도 있게 됐다. 필자는 실시간 트위터 이미지 사이트를 디버깅하는 과정에서 필자의 PC로 비즈니스 로직을 이동시켜 디버깅을 진행하기도 했다. 디버깅을 위해 비즈니스 로직을 이동시킨 가장 큰 이유는 PAAS 환경이 디버깅이 용이하지 않은 점이 있었기 때문이었다. 단단히 결합된 아키텍처(tightly coupled architecture)를 가진 웹 서비스 방식이었다면, 디버깅을 위해 서비스를 옮기는 경우, 좀더 많은 설정이나 프로그램의 변경이 수반됐을 것이다. 또한 메시징 시스템을 이용하면 실시간 데이터의 비동기적 처리가 가능하다. 즉 데이터 생산자와 데이터 소비자가 메시징 시스템을 매개로 분리됨으로 메시지 수신과 발신이 독립적으로 발생할 수 있게 된다. 그 결과 발신자는 수신자의 대기 없이도 지속적으로 생성한 메시지를 메시징 시스템으로 전송할 수 있고, 수신자는 발신자의 메시지 발신 속도와 무관하게 자신의 처리 속도에 따라 메시징 시스템으로부터 비동기적으로 메시지를 수신하고 처리할 수게 된다. 메시징 시스템을 이용하면 게시-구독 서비스도 구현하기가 쉽다. 가장 대표적인 게시-구독 패턴은 그룹 채팅이다. 그리고 이전 글에서도 언급했듯이 실시간 복수 소비자들이 주가 변화를 지속적으로 수신하는 것과 같은 비즈니스를 쉽게 구현할 수 있게 해 준다. 그리고 ActiveMQ 메시징 시스템의 경우 새롭게 등장한 웹소켓과의 결합도 쉽게 해준다. 실시간 트위터 이미지 사이트에 접속한 웹 브라우저는 웹소켓의 상위 프로토콜로 메시지 프로토콜인 STOMP 프로토콜을 이용하여 대한민국에 위치한 ActiveMQ 메시징 시스템에 직접 접속한다. 웹 브라우저는 이 접속 채널을 통해 비동기적으로 트윗 메시지를 ActiveMQ 메시징 시스템으로부터 지속적으로 수신하여 웹 페이지에 이미지를 표시한다.

실시간 트위터 이미지 사이트는 어떤 패턴의 비즈니스로 발전할 수 있을 지를 생각해 보자. 첫째, 실시간 트위터 이미지 사이트는 트위터에서 실시간으로 트윗을 추출 방법을 보여 준다. 그러므로 이 사이트는 트위터에서 발생하는 유행들을 실시간으로 분석하거나 추출, 저장하는 용도로 쉽게 변경될 수 있다. 필자는 개발 과정에서 사용자가 입력한 검색어를 이용하여 실시간으로 트위터에서 이미지들의 추출하여 표시하는 웹 페이지도 개발했다. 그러나 이 웹 페이지는 사용자들의 과도한 검색으로 트위터의 채널 할당량 정책을 초과할 수 있어 공개하지는 않았다. 검색어를 이용해 트윗 결과를 실시간으로 획득할 수 있는 기능을 이용하면 트위터로부터 필요한 유행 정보를 좀더 쉽게 획득할 수 있을 것이다. 둘째, 실시간 트위터 이미지 사이트는 ActiveMQ 메시징 시스템이 대륙 간의 메시지 통신에도 잘 사용될 수 있다는 것을 보여준다. 그러므로 여러 지역에 분산된 본점과 지점들 사이 메시지 통신이 필요한 비즈니스 모델에 ActiveMQ 메시징 시스템을 이용할 수 있다. 셋째, 실시간 트위터 이미지 사이트는 웹소켓을 이용하여 웹 페이지에 실시간으로 이미지를 보여줄 수 있다는 것을 보여준다. 그러므로 웹 페이지에 실시간 정보를 표시하는 비즈니스는 웹소켓 기술을 이용할 수 있을 것이다. 예를 들어 웹 페이지에 채팅 메시지 서비스를 제공한다든지, 웹 페이지에 주가를 실시간으로 표시하는 서비스를 제공한다든지, 웹 페이지에 비즈니스 이벤트를 모니터링하는 서비스를 제공한다지 등등 웹 페이지에 실시간으로 데이터 전달이 필요한 어떤 비즈니스에도 응용될 수 있을 것이다.

이 글을 통해 독자들은 실시간 트위터 이미지 사이트가 보기와 달리 범 대륙적인 분산 시스템으로 메시징 시스템과 웹소켓을 이용해 이미지가 포함된 트위터를 실시간으로 추출 및 전송하고 웹 화면에 이미지를 실시간으로 표시하는 시스템이라는 것을 알았을 것이다. 이상으로 실시간 트위터 이미지 웹 사이트의 시스템 구성에 대한 설명을 마친다.

참고 사이트

• 1) 실시간 트위터 이미지 웹 페이지

• 2) 실시간 트위터 이미지 사이트 개발기 1

• 3) 실시간 트위터 이미지 사이트 개발기 3

• 4) Apache ActiveMQ

• 5) 레드햇 오픈시프트 클라우드

• 6) Bilgin Ibryam의 올림픽 실시간 트위터 이미지 블로그

실시간 트위터 이미지 사이트 개발기 1

들어가며

우리는 가끔 노래 가사처럼 덜컹거리는 기차를 타고 어디론가 떠나며, 차창 밖에 보이는 풍경을 느긋이 감상하고 싶을 때가 있다. 우리는 가끔 우리가 좋아하는 관심사를 보며 마음을 정화시키기도 한다. 일반적으로 사람들은 관심사를 중심으로 세상의 흐름을 읽는다. 사랑, 행복, 월드컵, 올림픽, 전쟁, 선거 등등 그러나 이런 관심사들을 일일이 찾아 다니는 것도 귀찮은 일이다. 그래서 우리는 TV 앞에 모여든다. 생각하지 않아도 알아서 찾아주고 보여주니 편하다. 그런데 우리가 이렇게 편안하게 우리의 관심사를 둘러보기 위해서는 어디선가, 누군가는 일을 해야 한다. 그것이 자발이던, 지시건, 사람이건, 컴퓨터건, 기계건, 누군가는 편안함을 위해 일해야 한다.

재작년에 런던 올림픽 당시 관람객들은 스스로 영광의 순간을 찍은 사진들을 사회 관계망 서비스를 이용하여 순식간에 인터넷으로 전세계에 확산시켰다. 그 중 트위터는 독보적이었다. 이 영광의 순간들은 트위터로 실시간으로 트윗되었고, 신문, 방송 기사들조차 이 순간을 전달에 트윗을 이용했다. 그러나 당시 트위터로 올라오는 트윗과 리트윗들은 올림픽에 관련된 것뿐만 아니라, 일상 관심사에 대한 것들로 뒤섞여 있었고 올림픽 사진뿐만 아니라 다양한 일상의 사진들도 포함되었다. 올림픽에 관심이 많은 사람일지라도 일일이 트위터에서 올림픽의 순간이 포함된 트윗만을 찾아 보는 것은 쉽지 않았다. 결과적으로 사람들은 올림픽의 영광의 순간을 그 순간이 아닌 이후 매체나 글자가 뒤섞인 트윗을 통해야 확인해야 했다. 그런데 이런 지구적인 이벤트에서 영광의 순간을 가장 빨리 편안하게 보려면 어떻게 해야 할지를 고민한 개발자가 있었다.

이 개발자는 올림픽의 순간을 보기 위한 웹 페이지를 개발했다. 그리고 그는 이 웹 페이지 개발에 Apache Camel 통합 프레임워크를 이용했다. 이 웹 페이지는 실시간으로 올라오는 올림픽의 영광의 순간을 담은 트윗들에서 사진들을 별도로 모아 보여주었다. 이 웹 페이지 프로젝트가 통합 커뮤니티에 알려지면서 커뮤니티는 웹 페이지 개발자에게 찬사를 보냈고 통합의 가치에 자부심을 가지게 되었다.

다음은 당시 이 웹 페이지가 보여주었던 화면이다.

이 웹 페이지는 실시간으로 올라오는 수많은 트윗들 중에서 런던 올림픽과 관련된 트윗을 검색하고 찾아낸 결과 트윗들 중 이미지를 포함한 트윗에서 위 화면처럼 웹 페이지에 썸네일 이미지를 보여준다. 그리고 썸네일을 클릭하면 원래 이미지가 나타난다. 올림픽 사진들은 최소 5초마다 계속 페이지에 추가된다. 놀라운 점은 이 웹 페이지가 중복된 사진을 실시간으로 걸러준다는 것이다. 즉 웹 페이지를 감상하는 사람에게 같은 이미지로 도배된 웹 페이지의 보여 주지 않음으로 영광의 순간들을 하나 하나 의미 있게 한다. 마치 기차를 타며 어딘가를 갈 때 창 밖으로 계속 바뀌는 풍경을 감상하는 것처럼 이 웹 페이지는 지나가는 풍경과 같은 감성을 조회자들에게 전달한다. 그 결과 이 사이트에 접속한 사람들은 올림픽의 순간을 마치 TV처럼 사진으로 편안하게 즐길 수 있었었다.

그런데 기술적으로도 놀라운 점은 이런 멋진 웹 페이지의 핵심 로직의 구현에 단지 수십 줄의 코드가 사용됐다는 점이다. 핵심 로직에 단지 23줄이 사용됐다. 이것은 일반 개발자들뿐만 아니라 통합 개발자들에게도 신선한 반향을 일으켰다. 이 핵심 코드는 다음과 같다.

이 코드는 Apache Camel 프레임워크의 라우팅에 대한 정의이다. 이 핵심 로직을 간단히 설명하면 다음과 같다. 검색어를 이용해 트위터로부터 실시간으로 트윗 결과들을 얻은 후, 이미지가 포함된 트윗을 선별하고, 선별된 트윗의 중복을 배제하고, 이미지를 포함한 정제된 트윗은 5초 동안의 여유가 적용된 수 후 웹소켓에 접속한 페이지들에게 브로드캐스트된다.

위와 같은 핵심 로직을 일반적인 웹 개발 방법을 사용하여 구현한다면 어떤 기술과 얼마의 자원과 시간이 필요할까? 아마도 기술을 깊이 이해하고 있는 개발자나 아키텍트라면 단언하기 쉽지 않을 것이다. 그런데 이런 핵심 기능을 23줄이 가능하게 했다. 통합 커뮤니티에서조차도 이 프로젝트가 통합을 창의적으로 적용한 것에 대해 열광했다. 필자가 볼 때도 이 핵심 로직은 프로그램이기보다 시에 가깝다. 이 프로젝트의 개발자는 "Instant Apache Camel Messaging"이란 책을 쓴 실력자이다.

그런데 올림픽은 끝나면서 올림픽의 순간들은 사람들에게 잊혀져 갔고, 아마존의 공짜 마이크로 인스턴스에서 운영되던 이 사이트도 폐쇄되었다. 아마존은 마이크로 인스턴스를 약 한 달인 750시간까지 사용할 수 있게 해준다. 결국 올림픽이 끝나면서 웹 페이지가 동작되던 마이크로 인스턴스의 생애도 끝나버렸다. 필자처럼 이 웹 페이지 개발자도 공짜를 몹시 밝히는 사람인 것 같다. 그의 블로그를 보면 무려 10달러를 사용했다는 것을 글에 남길 정도로 그도 짠돌이다. 그러나 이런 집착은 오픈 소스를 이용한 개발자들의 미학이다.

필자가 이 프로젝트에 다시 관심을 가진 이유는 얼마 전 레드햇의 오픈시프트 퍼블릭 클라우드 사이트에 가입했기 때문이었다. 현재 레드햇의 오픈시프트 퍼블릭 클라우드는 온라인 가입자들에게 놀라운 정책을 제공하고 있다. 이 놀라운 정책이란 무려 3개의 기어라고 불리는 가상 PAAS 서버를 무료로 사용하게 해 준다는 것이다. 각 기어 당 메모리 512M, 디스크 1G까지 네트워크 트래픽에 대한 언급은 없으므로 무제한(?)을 제공해 줄 것으로 생각된다. 필자가 가지고 있는 라즈베리 파이만한 기계를 가상 환경이지만 3개나 공짜인 제공한다는 것이다. 아마존 웹서비스의 마이크로 인스턴스 정책과 비교해 보라. 정말로 파격적인 정책임을 알 수 있다. 아이러니 한 점은 레드햇의 오픈시프트 클라우드가 아마존 웹서비스 클라우드에서 운영된다는 점이다. 그것도 SUSE Linux로…… 필자는 오픈시프트 기술에 대해 검토하면서 "그래 공짜 서버가 생겼는데 놀리면 안되겠다"라는 생각을 했다. 그러면서 위에 설명한 올림픽의 영광의 순간을 담는 웹 페이지를 필자의 방식대로 새로 만들어 이곳에서 운영하면 좋겠다고 생각하고 만들어 보았다.

다음은 필자가 개선한 새로운 실시간 트위터 이미지 웹 페이지다.

들어가는 글은 이 정도로 마치고 이어지는 글에서는 필자가 실시간 트위터 이미지 웹 페이지를 개발하면서 분석하고, 고민하고, 개선하고, 결정했던 이야기들을 하려고 한다.

참고 사이트

• 1) 실시간 트위터 이미지 웹 페이지

• 2) 실시간 트위터 이미지 사이트 개발기 2

• 3) 실시간 트위터 이미지 사이트 개발기 3

• 4) Apache Camel

• 5) 레드햇 오픈시프트 클라우드

• 6) 아마존 웹서비스 클라우드 무료 이용 정책

• 7) Bilgin Ibryam의 올림픽 실시간 트위터 이미지 블로그