ESB와 SOA가 대체 뭔가요?

"시스템의 시스템을 위한 훌륭한 기술서", Alyssa Coghlan

Available in Català, Deutsch, English, Français, Italiano, Português, and 한국어.

ESB, 그리고 그와 관련된 SOA는 상당히 혼동되는 용어일 수 있습니다. ESB는 Enterprise Service Bus의 축약어이고 SOA는 Service Oriented Architecture를 나타내는 말입니다.

이것만으로는 설명이 부족하겠지요. 이 문서에서 최대한 장황하지 않게 핵심 개념을 설명드리겠습니다.

사례 예시

당신의 은행 앱을 사용하는 상황을 한번 생각해보세요.

1. 당신의 이름이 표시되고
2. 당신의 잔고가 표시되고
3. 당신의 신용카드와 직불카드가 표시되고
4. 당신의 뮤추얼 펀드 리스트가 있을 수도 있겠죠
5. 혹은 당신을 위한 매력적인 대출 광고 리스트가 보일 수도 있습니다.

위의 상황을 고려했을 때, 저 모든 것들은 서로 다른 시스템과 앱에서 인터페이스를 통해 데이터를 노출시키고 있다고 생각해 볼 수 있습니다. (REST, JSON, AMQP, SOAP, FTP, CSV 등 인터페이스가 무엇인지는 중요하지 않습니다):

• 1) 그것은(인터페이스는) 리눅스나 오라클에서 실행중인 고객 관계 관리(CRM) 프로그램일 수 있습니다.
• 2) 그것은 z/OS에서 실행되는 코볼 프로그램일 수 있습니다.
• 3) 그것이 메인프레임인 것은 맞지만 CSV를 공개하는 것 외에는 아무것도 알려진 것이 없는 것일수도 있습니다.
• 4) 그것은 윈도우에서 실행중인 PHP와 Ruby의 혼용 프로그램일 수 있습니다.
• 5) 그것은 리눅스나 솔라리스에서 실행중인 PostgreSQL, Python 그리고 Java 프로그램일 수 있습니다.

여기서 제기되는 질문은, 당신이 어떻게 이런 1~5가지 프론트엔드 앱들간에 데이터를 교환 할 수 있느냐는 겁니다. 그렇게는 못합니다.

이것은 제어 가능한 시스템 범주에서 스케일을 동적으로 확장할 수 있는 환경을 만드는 가장 기초적인 내용입니다. 즉, 당신은 인터페이스 간에 서로 직접적으로 통신하게 해서는 안됩니다

아래의 다이어그램에서, 서로 다른 시스템간의 교환을 각각의 너비와 스타일을 가진 선으로 나타냈습니다:

사실 이 그림에서는 더 높은 단계(higher-level)의 프로세스는 생략되어 있습니다(앱1이 앱2를 호출하고 앱3 또는 앱5가 앱6의 결과값을 성공적으로 반환 받는지에 의존하고 그에의해 앱4는 나중에 앱2에 의해 발생하는 결과값에 의존하지만 앱1이 그 반환값을 허용하는 경우에만 교환이 이루어지는 등).

또한 우리는 서버단에서 발생하는 프로세스를 아직 이야기 하지 않았습니다 - 각 시스템은 아마도 10개의 물리적인 서버에서 돌아가고 그래서 적어도 60개의 물리적인 컴포넌트들 간의 교환이 생겨날 수 있습니다.

하지만 여전히 몇가지 의문점이 남습니다.

어떻게 인터페이스를 분리할 수 있을까요? 어떻게 서비스를 기획할까요? 각각의 앱이나 서비스가 다른 팀이나 공급업체, 혹은 원년 멤버의 반이 나간 부서에서 관리한다면 어떻게 서비스를 업데이트 하거나 점검을 위해 일시 중지를 할 수 있을까요?

만약 당신이 6개의 서로 다른 앱을 통제할 수 있다고 한다면, 30개는 어떤가요?

400개는 어떤가요? 2000개는요? 각 앱들은 10개의 서버에서 돌아가거나 앱을 실행하기 위한 장치가 필요하는 등, 고유의 개발 환경이 필요할 수 있겠죠. 그래서 이런 2만개의(2000개 앱의 10대의 서버) 동적인 부분들이 대륙간에 퍼져있고 각각의 고유 기술과 문화 경계를 가지고 있고, 그 모든 부분이 끊임없이, 지속적으로 메시지를 교환하고 서로간에 결코 쉬지 않고 대화를 하겠죠.(다이어그램으로 보여드렸습니다)

이런 상황에서 할 수 있는 말은, 소위 엉망이라고 하죠.

이런 엉망인 상태를 어떻게 정리할 수 있을까요?

첫단계는 이 상황이 통제범위에서 벗어났다고 솔직히 인정하는 겁니다. 그럼으로써 우리는 죄의식을 많이 느끼지 않고 치유를 시작할 수 있을겁니다. 좋습니다. 그런 엉망인 상황은 발생했고, 당신은 어쩌면 좋을지 모르겠지만, 이런 상황을 해결할 수 있는 방법이 있습니다.

그 방법은 IT에서 조직적인 변화를 만드는 것과, 시스템이나 앱이 서로간에 데이터를 주고받기 위해 만들어진 게 아니라는 걸 다시금 상기하는 겁니다. 그런 시스템이나 앱은 비즈니스 프로세스를 지원하기 위해 만들어진 것입니다. 그것이 뱅킹, 음성 녹음, 전파위치 장치 등 어떤 비즈니스든 상관 없습니다.

당신이 이 두가지를 명확하게 인지하고 있다면 다음으로 당신의 서비스 시스템을 다시 구축하거나 디자인하는 것을 고려 할 수 있을 것입니다.

서비스는 한 시스템이 여러 앱에서 잘 사용할 수 있게끔 제공하는 뭔가 흥미로운 것이고, 재사용 가능하며 원자성을 보유하고 있는 것입니다. 그리고 서비스는 절대 서로간에 직접적으로 노출시키면 안됩니다. 이것은 짧지만 의미있는 정의입니다.

만약 시스템의 특정 기능이 다음의 3가지 요구사항을 충족시키는 경우, 즉, 만약 서비스가 다음과 같다면

• 흥미롭고 I nteresting

• 재사용성 R eusable

• 원자성 A tomic

그렇다면 이 서비스는 다른 시스템들에 노출시키는 것이 좋습니다. 물론 직접 노출시키면 안되겠지요.

몇가지 예를 통해 IRA(Interesting, Reusable, Atomic) 접근법에 대해 논의해 보겠습니다.

만약 당신이 지난 50년 혹은 그에 준하는 기간 안에 프로그래밍을 해본 적이 있다면, 서비스를 노출시키는 것은 코드의 한 부분에서 다른 부분으로 API를 노출시키는 것과 정확히 같다는 것을 알 것입니다. 한가지 다른점은, 당신은 한 시스템 안의 하위 모듈들을 다루는게 아니라는 겁니다. 당신은 분산된 시스템 전체 환경을 다루고 있는 것입니다.

SOA에서 ESB로 서비스 만들기

이제 당신은 시스템에서 정보 교환을 직접적으로 하면 안되는 걸 알았고, 서비스가 무엇인지 이해했으니, ESB로 서비스를 만들 준비가 되었습니다.

통합된 시스템에서 서비스를 노출시키거나 호출하는 것은 ESB가 해야할 일이 되었습니다. 그런 식으로, 대부분의 경우 오직 하나의 접근 메서드와 하나의 인터페이스가 ESB와 각 시스템간에 정의되어 있어야 합니다.

그래서 만약 위와 같은 다이어그램에서라면, 당신에게 8개의 시스템이 있고, 만들고, 유지하고, 관리해야 할 16개의 인터페이스가 있는 것입니다(한 방향에 하나씩).

ESB가 없다면, 당신이 다루어야 할 인터페이스의 숫자는 56가지 입니다 (각 시스템이 직접적으로 교신하는 경우를 가정하면).

인터페이스가 40가지라고 하더라도 그것이 56가지보다 더 적은 시간 낭비와, 더 작은 의미를 지닌다거나 돈을 더 많이 아낄 수 있다는 걸 의미하지는 않습니다. 이것이 바로 당신이 금요일에 마음 편히 쉴 수 없는 이유중 하나가 될 수 있습니다.

이러한 사실 하나만으로도 당신은 ESB를 도입하는걸 적극 고려해야 합니다.

만약 시스템이 재정비를 하거나, 소유주가 바뀐다거나, 부서나 공급업체가 나뉘는 상황에 있다면 그런 변화를 따르는 것이 ESB의 의무가 될 것입니다. 기존의 시스템들은 어떤 변화도 감지하지 못할 것입니다. 왜냐하면 기존의 시스템과 ESB가 사용하던 인터페이스는 그대로 둘 것이기 때문입니다.

당신이 IRS 서비스를 다루기 시작한 사람이라면, 당신은 복합적인 것을 생각하기 시작할 것입니다.

위에서 예로든 '고객의 가능한 모든 정보를 주세요' 서비스를 기억하나요?

그것을 서비스로 만드는 것은 좋은 생각은 아니지만, 당신은 가끔 고객의 앱에서 통합되고 요약된 정보를 다루어야 할 필요가 있을 것입니다. 그것이 바로 ESB의 책임이 될 것입니다. 최적의 원자적 서비스 고르고 그로부터 복합적인 서비를 만들어 특정 클라이언트 시스템에서 요구하는 복합적인 데이터를 만들어 내는 일이 ESB가 하는 일입니다.

시간이 지남에 따라, 사람들은 이러한 것들이 데이터 베이스의 테이블이나, 파일, 배치, 함수, 루틴이나 레코드와 관련된 것이 아니라는 것을 이해하기 시작했습니다. 이것은 ESB가 제공하는 흥미롭고(I), 재사용 가능하고(R) 원자성을 지닌(A) 서비스 앱을 중심으로 한 아키텍처입니다.

더이상 사람들은 앱과 시스템간에 직접적인 교신을 생각 할 필요가 없게 되었습니다. 사람들은 ESB를 그들의 시스템에서 각 서비스에 접근하고 사용할 수 있게 하는 통로로 여기게 되었습니다. 그리고 그들은 더이상 어떤 서비스가 무엇을 제공하는지 신경쓰거나 매번 체크할 필요가 없어졌습니다. 그들의 시스템은 ESB만 다루면 되는 것입니다.

이 과정은 시간이 걸리겠지만, 인내심을 가지고 어느정도 노력한다면 그렇게 할 수 있을 것입니다.

그러나 주의하세요...

SOA의 전체 컨셉을 망치는 가장 좋은 방법은 시스템에 ESB를 적용하고 나서 그것이 문제들을 알아서 잘 조정하리라 생각하는 것입니다. 이것은 훌륭한 아이디어이긴 하지만, 불행하게도, 단순히 ESB를 설치하는 것 만으로는 그렇게 까지 문제가 스스로 해결되지는 않습니다.

이것의 대표 사례로, 카펫 아래에 무언가 깔아놓는다고(아래의 다이어그램처럼) 달라지는 것은 없습니다.

당신의 IT 사람들은 위와 같은 시스템을 혐오할 것입니다. IT 관리자들은 ESB를 처음에는 참을성 있게 받아들이지만 나중에는 ESB를 비웃을 것입니다. "뭐, 만능 해결사라고? 웃기고 있군 ㅎㅎㅎ"

만약 ESB가 당신의 시스템의 더 큰 계획의 일부분으로 사용되지 않는다면 그러한 결과는 불가피합니다. (따라서, 다시 말하지만, ESB를 설치하는 것 만으로는 충분치 않습니다.)

ESB는 은행권이나 유사 업종에만 적용 가능한가요?

전혀 그렇지 않습니다. 다수의 데이터 소스와 다수의 접근 메서드가 함께 동작해서 흥미로운 결과값을 도출해야 할 상황이라면 언제나 좋은 선택이 될 수 있습니다.

예를들면, 열 센서에서 가장 최근의 값을 측정해 여러 채널에 이메일 알람처럼 전달하는 경우입니다. 그리고 아이폰 앱은 통합 플랫폼으로서 값을 전달하기 가장 적합해 보입니다.

주요 앱에서 모든 인스턴스가 모두 잘 작동하는지 주기적으로 컨설팅과 모니터링을 하고, 만약 잘 작동하지 않는다면 사전에 준비된 스크립트를 실행시킴과 동시에 관리자에게 문자 메시지를 보내는 것이 좋아 보입니다.

명확하고, 잘 정의된 환경으로 통합하기 위해 필요한 모든 것은 ESB 서비스를 위한 좋은 환경이 될 것입니다. 그러나 언제나처럼 무언가 정말로 적합한지 결정하는 일은 그것을 실제로 경험해본 후에야 내릴 수 있을 것입니다. Zato의 지원팀이 도움을 드릴 수 있습니다.

그러나 저는 SOA가 XML에 관한 것이고 SOAP은 웹 서비스에 관한 것이라고 들었어요

그런 말이 있습니다만, 그것은 어떤 사람들이 당신에게 그렇게 믿게 만들고 싶기 때문입니다.

만약 당신과 일하는 사람들 혹은 공급 업체가 어떤 일을 하는데, 예를들어 BASE64로 CSV 파일을 인코딩하고 그것을 SAML2로 보안화된 SOAP 메시지로 당신에게 보내려 할 때, 당신이 그런 인상을 품고 있는 것도 이해할 만 합니다.

XML, SOAP 그리고 웹 서비스는 그것들 만의 사용처가 있고, 잘못 사용 될 수도 있는겁니다.

SOA는 깔끔하고 다루기 쉬운 아키텍처에 관한 것입니다. 특정 서비스가 SOAP을 사용 하고 안하고는 SOA와 거의 관련이 없습니다. 아키텍처 차원에서 접근해보면, SOAP 서비스가 전혀 사용되지 않더라도 SOA는 여전히 유효합니다.

건축가가 아름다운 건물을 디자인한다고 할 때, 그 건축가들은 사람들이 인테리어를 위해 선택하는 페인트 색상에 대해서는 거의 할 수 있는게 없습니다.

그래서, SOA는 XML, SOAP, 웹 서비스에 관한 것이 아닙니다. 이러한 것들을 SOA에서 사용할 수는 있지만, 그것이 SOA를 구성하는 전체는 아니라는 말입니다.

SOA가 진정 무엇인지 이해할 수 있게 SOA를 잘 모르고있는 동료들에게 친절하게 이 문서에 대해 언급해주세요

몇가지 더 말할게 있습니다

현재 문서는 가장 기초적이지만 ESB와 SOA가 어떠한 것인지, 어떻게 해야 성공적으로 사용할 수 있는지 정확하게 이해할 수 있게 작성되었습니다.

여기서 다루지는 않았지만, 다음 주제들을 포함시킬 수 있고 이것에만 국한되지 않습니다:

• 어떻게 ESB를 관리하기 위한 지원받을 수 있을지
• 어떻게 SOA 설계자와 분석팀을 구할 수 있는지
• 조직에 표준 데이터 모델(Canonical Data Model - CDM)을 도입하기
• 핵심 성과 지표(Key Performance Indicators - KPI) - 이제 당신은 시스템 전체에서 제공할 수 있는 공통되고 통합된 메서드를 가지고 있으니, 모니터링과 평가를 통해 진짜 무엇이 개선되었는지 확인해 볼 수 있습니다.
• 비즈니스 프로세스 관리(Business Process Management - BPM) - 어떻게, 그리고 언제 BPM을 선택하여 서비스를 조직적으로 관리할 수 있을까요? (답은, 너무 서두르지 않는게 좋습니다. 당신은 먼저 멋지고 반할만한 서비스를 만드는데 익숙해 져야 합니다.)
• 시스템에 API가 없는데 어떻게 해야할까요? 예를들어, ESB가 데이터베이스에 직접 접근할 수 있게 해야하나요? (답은, 상황에 따라 다릅니다. 이에 대한 공식적인 룰이 있는 것은 아닙니다.)

그래서 Zato가 정확히 뭘 하는 건가요?

Zato 는 ESB와 앱 서버로서 파이썬으로 작성되어있고 미들웨어나 백엔드 시스템을 위해 사용할 수 있습니다. 오픈소스로 작성되어 있지만 상용을 위해 지원 가능하고 커뮤니티 지원또한 가능합니다. 그리고 Python 은 생산성이 높고 사용하기 쉬워 널리 사랑받는 프로그래밍 언어입니다.

파이썬과 Zato를 함께 사용한다는 것은 당신이 더욱 생산적이고 성가신 일에 덜 신경쓰게 된다는 것입니다.

Zato는 실용주의자를 위해 실용주의자가 작성한 프로그램입니다. Zato는 ESB와 SOA의 과대 광고의 물살에 휩쓸려 시스템을 빠르게 대충 연결시키는 종류의 것과는 다릅니다.

사실, Zato는 실용적인 경험을 통해 그러한 (엉망인)시스템의 화제를 진압하는 과정을 통해 탄생했습니다. Zato의 저자는 사실상 어떠한 화재에도 면역인, 그러한 끔찍한 환경을 다루는데 매우 많은 시간을 썻습니다.

이것이 Zato가 탄생하게 된 배경입니다. 이것이 Zato가 유사 솔루션들과 비교할 수 없는 높은 생산성을 제공하고 사용 편의를 제공할 수 있는 이유입니다.

Zato에 관한 더 자세한 내용은 이곳에서 확인해주세요!