본문 바로가기

.Net Technology/.NET General

COM+와 분산 트랜잭션의 이해

이번 강좌에서는 엔터프라이즈급 솔루션을 설계하기 위해서 반드시 알고 있어야 하며 닷넷 프로젝트 설계에 있어서 기본적으로 알고 있어야 하는 개념인 분산 트랜잭션의 개념과 COM+의 개념을 집중 해부 해보고자 한다이 글을 읽는 독자는 닷넷과 트랜잭션의 개념은 이미 알고 있다고 가정아래 썰을 풀도록 하겠다.

 

MTS(Microsoft Transaction Server)의 이해

 

분산 트랜잭션에 대한 이야기를 다루기 전에 10년 전 과거로 올라가 보고자 한다마이크로소프트는 엔터프라이즈급 규모로 확장 가능한 서버 애플리케이션 개발 환경을 지원하기 위해 마이크로소프트 트랜잭션 서버(MTS)를 1996년에 만들어 발표하였다. MTS COM DCOM으로 개발된 기업용 어플리케이션 시스템을 위한 실행 환경을 가지고 있고 무엇보다도 분산 컴퓨팅 환경에서 안정적이고 확장이 가능하다무엇보다도 가장 중요한 것은 분산 트랜잭션을 지원하고 있다는 것이다분산 트랜잭션 즉, DTC에 대한 자세한 이야기는 뒤에서 다루도록 하겠다.

 

MTS.. 트랜잭션 서버라는 명칭 때문에 어렵게 받아들일 수도 있지만 한 걸음 물러나서 보면 아주 간단한 시스템으로 생각할 수도 있다. MTS 기반의 모든 애플리케이션은 COM 컴포넌트의 집합으로 이뤄져 있으며이를 사용하는 클라이언트는 DCOM을 사용해 원격지에서 MTS 애플리케이션을 사용한다즉 마이크로소프트의 기반 기술인 COM/DCOM을 보다 효율적이고 안정적으로 사용 가능하게 만들어 주는 통합 환경으로 생각하면 된다.

 

COM/DCOM은 뭐냐?

 

닷넷부터 시작한 개발자라면 COM/DCOM을 직접 구현해보지 않았기 때문에 개념에 다소 혼란이 올 수 있을 것이다.아주 간단하게 정리해 보겠다. 1차적으로 개념으로 DLL->COM->DCOM으로 발전해 왔다고 개념을 잡도록 한다. DLL먼저 살펴 보자면 EXE라는 실행 파일에 의존적이고 유지보수에 있어서 많은 문제를 가지고 있다이런 단점을 보완해주는 것이 COM이라는 개념이고 특정 프로그래밍 언어에 의존적이지 않고 자원을 공유할 수 있도록 해주는 것이다.물론 COM 규격은 정해져 있고 그 규격에 맞아야 사용할 수 있을 것이다그럼 DCOM은 무엇인가? DCOMDistributed + COM 으로 풀 수 있다. COM을 여러 원격지에서 호출할 수 있다는 것이다. DCOM의 목록은 [관리도구]-[구성요소서비스에서 확인할 수 있다.

[DCOM 목록]

 

그럼 MTS를 발표할 그 당시의 반응은 어땠을까발표 당시에 TP-Monitor(Transaction Processing Monitor)라는 기능과ORB(Object Request Broker)의 기능을 동시에 처리하는 시스템이 존재하지 않았지만 바로 MTS가 이러한 두 가지 기능을 처리할 수 있어서 많은 개발자들의 주목을 모았었다그럼 TP-모니터와 ORB는 무엇인가먼저 TP-모니터는 트랜잭션이 이루어지는 과정을 모니터링 하는 기술이라 할 수 있다지금이야 엔터프라이즈급 환경에서 유용하게 사용할 수 있는 여러 미들웨어 제품들이 나와 있지만 그 당시에는 이런 기술들이 존재하지 않았다는 것이다.

 


[
윈도우 서버2003에서 제공하는 트랜잭션 통계기능]

 

그 다음 ORB CORBA라는 분산 기술에서 처음 등장한 개념이다. (그럼 CORBA가 또 무엇이냐라는 질문의 답은 분산 트랜잭션 이야기가 너무 삼천포로 빠지기 때문에 생략하도록 하겠다.)ORB는 객체들 간의 클라이언트/서버 관계를 맺어주는 미들웨어다. ORB를 사용하면 클라이언트는 서버객체에 있는 메서드를 같은 컴퓨터에 있든 또는 네트워크 상에 있든 상관없이 투명하게 호출할 수 있다. ORB는 호출을 가로채어 요구를 처리할 객체를 찾고매개변수를 전달하고메서드를 호출하고또 처리결과를 되돌려주는 일 등을 담당한다.

 

아무튼 이런 개념의 기술들이 도입된 MTS는 그 당시 많은 주목을 받았다는 것이다.

 

 

COM+와 분산 트랜잭션

 

앞에서 COM MTS에 대해서 이해해 보았다이 두 가지 개념이 잘 정립되어 있다면 COM+는 쉽게 이해할 수 있다. COM+ COM MTS의 핵심기능을 지원하고 있기 때문이다.

 



[COM+
의 정의]

 

닷넷 프로젝트를 설계할 때 COM+기반의 아키텍쳐를 도입하는 이유 중 하나는 바로 MTS 분산 트랜잭션을 이용하기 위한 목적도 상당한 비중을 차지할 것이다. COM+에서 제공되는 트랜잭션의 환경은 앞에서 설명한 MTS 실행 환경을 그대로 이어 받고 있다그렇기 때문에 서버 시스템 개발자가 직면한 다양한 문제를 해결하고 애플리케이션 본연의 업무에 충실할 수 있도록 만들어 준다시스템 부하는 약간 늘다 하더라도 개발자의 생산성과 시스템의 안전성은 그만큼 높아진다는 것이다다음은 트랜잭션기능을 자동으로 지원하는 COM+ 객체를 만드는 코드이다다음 코드만 보더라도 아주 간단하게 기능을 구현할 수 있는 것을 볼 수 있을 것이다이것이 바로 닷넷 프로젝트에서 COM+를 자주 도입하는 이유가 되기도 한다.

 

[Transaction(TransactionOption.Required)]

class A : ServicedComponent

{

  [AutoComplete]

  public void foo()

  {

    B obj = new B();

    try

    {

      obj.TransactionTest();

    }

    finally

    {

      obj.Dispose();

    }

  }

}

 

[Transaction(TransactionOption.Supported)]

class B : ServicedComponent

{

  [AutoComplete]

  public void TransactionTest()

  {

    // 데이터베이스 액세스 코드

  }

}

[자동 트랜잭션 처리 코드]

 

 

분산 트랜잭션(Distributed Transaction)

 

분산 트랜잭션의 내부 구조는 단일 트랜잭션에 비해서 많이 복잡하다다음 그림을 살펴보자.

 

 

이 그림을 보면 트랜잭션의 고유한 아이디를 이용하여 각 서버의 일관성을 유지한다.

 

먼저 DTC라는 개념을 정리해 보겠다. DTC(Distributed Transaction Coordinator)는 클라이언트 응용 프로그램이 한 트랜잭션에 여러 다른 데이터 원본을 포함할 수 있도록 해주는 트랜잭션 관리자이다. DTC는 트랜잭션에 포함된 모든 서버에서 분산 트랙잭션 커밋을 조정하고 있기 때문에 DTC에 분산 트랜잭션을 위임할 수 있는 것이다. DTC에선 위의 그림처럼TXID라는 고유한 아이디를 관리하게 된다. DTC는 많은 컴퓨터들의 연결을 처리하기 때문에 호출 객체의 고유한 아이디가 필요한 것이다로컬 트랜잭션은 하나의 커넥션을 가지고 있지만 분산 트랜잭션은 여러 개의 커넥션을 가지고 연결을 하게 되며 리소스 매니저에서 관리하게 된다여기서 반드시 잡아야 할 개념은 DTC는 트랜잭션 관리자라는 것이며 3자의 입장이라는 것이다.

 

단일 서버의 트랜잭션 관리자는 DTC가 아닌 LTM이 이용된다. LTM은 보다 좋은 성능을 가지고 있고 단일 서버에서만 사용될 수 있다성능을 좌우하는 것은 어떤 프로토콜을 사용하느냐에 따라서 좌우된다.

 

트랜잭션의 프로토콜

 

Lightweight 프로토콜

이 프로토콜은 같은 App 도메인 안에서 로컬 컨텍스트 안에서 트랜잭션을 관리하기 위해서만 사용된다.이 프로토콜은 App 도메인 경계 밖으로 전달이 불가능하고 또한 어떤 서비스 경계 밖의 트랜잭션 역시 전달이 불가능하다. Lightweight 프로토콜은 단지 서비스 안에서 혹은 서비스 밖에서만 이용된다. Lightweight 프로토콜은 다른 프로토콜과 비교해서 가장 좋은 성능을 가지고 있다.

 

OleTx 프로토콜

이 프로토콜은 App 도메인프로세스 그리고 머신들의 경계로부터 전달된 트랜잭션을 이용할 수 있고 두 단계의 커밋 프로토콜” 다룰 수 있다이 프로토콜은 RPC 호출을 이용하고 여기서 사용되는 정확한 이진 포맷은 Windows에 의존적이다하지만 RPC와 Windows-specific 포맷 둘 다 이용하기 때문에 윈도우 기반이 아닌 플랫폼과 상호운용이 어렵다그렇다고 특별히 문제될 것은 없다왜냐하면 OleTx를 이용하는 가장 주된 이유는 윈도우 기반의 인트라넷 안에서 트랜잭션을 관리하기 위해서이기 때문이다.

 

WS-Atomic Transaction (WSAT) 프로토콜

이 프로토콜은 App 도메인프로세스 그리고 머신들의 경계로부터 확장된 트랜잭션을 이용할 수 있고 두 단계의 커밋 프로토콜” 다룰 수 있다는 점에서 OleTx 프토토콜과 비슷하다하지만 OleTx 프로토콜과 다른 부분은 WSAT 프로토콜은 산업 표준 기반이라는 것이고 HTTP를 이용해 text 인코딩을 사용하는 경우 방화벽을 통과 할 수 있다. WSAT 프로토콜이 인트라넷에서 이용할 수 있지만 이것을 이용하는 주된 이유는 다중의 트랜잭션 관리자들이 호출되는 인터넷 기반에서 트랜잭션을 이용할 수 있다는 것이다.

 

 

두 단계의 커밋 프로토콜(Two-Parse Commit Protocol)

 

분산 트랜잭션의 복잡함을 극복하기 위해서 두 단계의 커밋 프로토콜을 이용하여 트랜잭션을 처리하게 된다다음 그림을 살펴보자.

 


[
두 단계 커밋 프로토콜]

 

두 단계 커밋 프로토콜은 두 단계로 작업을 진행한다. 먼저 첫 번째 단계에서는 Commit을 해도 되는지에 대한 여부를 수집하게 된다그리고 두 번째 단계에서 커밋을 할지 롤백을 할지를 결정하게 되는데 모든 리소스들이 커밋을 요청하게 되면 트랜잭션 관리자는 변경된 것들을 모두 커밋 시키게 될 것이고 만약 하나의 리소스라도 커밋을 원하지 않게 된다면 두 번째 단계에서 트랜잭션 관리자는 변경된 데이터들을 롤백 시키게 될 것이다그리고 트랜잭션은 중단되고 트랜잭션 이전 상태로 복구하게 된다.

 

 

닷넷 2.0에서는 COM+안 쓴다(?)

 

필자의 주위 닷넷 개발자들중에 닷넷 2.0에서는 COM+ 안 쓰잖아요~” 라는 말을 하는 것을 여러 번 들었다하지만 여기서 그 이유에 대해서 물으면 그냥 그렇게 들었다는 것이다. 이 말이 맞는 말인지 틀린 말인지를 떠나서 여기서 이런 말이 나오게 된 원인이 무엇일지 먼저 분석해 보도록 하겠다이미 알고 있는 독자도 있겠지만 이 말이 나오게 된 것은 닷넷 2.0에서 새롭게 추가된 System.Transaction 네임스페이스 때문이라는 생각을 먼저 해 볼 수 있다. 바로System.Transaction 네임스페이스는 기존 COM+에서 지원되었던 자동 트랜잭션을 지원하고 어느정도 제약이 있긴 하지만 분산 트랜잭션 기능 또한 지원해주고 있기 때문이다. 기존의 자동 트랜잭션 기능만을 위해서 COM+를 선택했다면 닷넷2.0에서는 더이상 COM+를 선택할 이유는 없다는 것이다.

 

그럼 트랜잭션 기능을 뺀다면 COM+ 볼품없는 기술이 되어 버린 것인가그래서 닷넷 2.0에서는 COM+를 쓰지 않는다는 말이 나오고 있는 것일까결론부터 말하자면 “No” 이다물론기존에 닷넷 시스템을 설계하면서 자동 트랜잭션과 분산 트랜잭션을 위해서 COM+를 선택했다면 그럴 수 있다여기서 간과하기 쉬운 COM+ 개념을 다시 정립할 필요가 있다. COM+는 미들웨어라는 것을 반드시 명심해야한다. COM+는 System.Transaction에서 제약을 가지고 있는 분산 트랜잭션뿐만 아니라 객체 풀링객체 생성 문자열메시지 큐 사용 그리고 분산 프로그래밍에서 가장 중요한 모듈 배포 및 관리를 해줄 수 있다는 점에서 COM+는 분명 아직까지 미들웨어의 핵심적인 기술임이 분명하다. 그렇기 때문에 엔터프라이즈 급 환경을 아키텍쳐 할때 반드시 1순위로 오르는 것이 COM+인 것이다. 여기서 System.Transaction의 프로그래밍에 대해서는 자세히 언급하지 않는다필요하다면 MSDN링크를 확인해보면 기능이나 프로그래밍에 대한 정보를 얻을 수 있을 것이다.

 

 

정리

 

닷넷의 기본 신조자체는 성능이 아닌 안전성이다닷넷 뿐만 아니라 최근에 여러 IT기술의 신조 역시 마찬가지일 것이다.하드웨어는 놀랍도록 발전하고 있고 충분히 성능을 끌어 올려 줄 수 환경은 이미 만들어져 있다이런 상황에서 단0.~~X 초에 민간 할 이유가 없다는 것이다그것보다 중요한 것은 엔드유저가 얼마나 더 신뢰를 가지고 사용할 수 있냐는 것이기 때문이다그래서 COM+나 자동 분산 트랜잭션의 기능은 성능의 부하가 있다 하더라도 반드시 큰 의미가 있는 기술이라는 것을 말하고 싶다.

 

또한 닷넷의 뛰어난 장점인 개발 생산성!! 이것은 말로 하지 않아도 충분히 이해할 수 있을 것이다앞에서 언급했듯이 트랜잭션을 개발자가 일일히 코드를 작성하기란 쉽지 않다그것이 분산 트랜잭션이라면 더 그렇다. 좀 더 가슴에 와닿을 만한 예를 들어 보자면 원격 RM(리소스 관리자)에 데이터를 처리하는 로직을 짜는데 조금 복잡한 로직이라고 가정해보자그럼 이 로직은 분명 에러가 발생할 가능성이 높을 것이다그래서 그 로직 사이에는 일일이 복구하는 로직을 개발자가 작성해야 하는 번거러움이 존재한다. 그런데 그 개발자가 작성한 복구 로직에서 에러가 발생하면 어떻게 될 것인가?여기서 더 난감한 것은 그런 복구로직을 테스트하는 작업이 더욱더 난감하다는 것이 문제고 개발자를 2~3번 죽이는 일이될 것이 분명하다. 이렇기 때문에 우리는 닷넷에서 친절하게 제공해 주고 있는 COM+ System.Transaction의 도움을 받아야 할 것이다.