SOA 어플라이언스, “해답인가, 문제인가”
상태바
SOA 어플라이언스, “해답인가, 문제인가”
  • 데이터넷
  • 승인 2008.06.20 00:00
  • 댓글 0
이 기사를 공유합니다

SOA 어플라이언스
SOA 어플라이언스, “해답인가, 문제인가”
‘웹 티어·보안·통합 및 관리’에서 활용 … ‘XML 가속화·보안·거버넌스’ 해결

SOA(Service Oriented Architecture) 아키텍처 표준과 툴은 이제 잘 여물어 가고 있다. 하지만 ‘희망을 함부로 입에 담지 말라’는 속담도 있듯이 많은 IT 그룹에서는 현재 SOA 이행이 성숙해지는 데 따라오는 문화, 관리 및 정치적인 문제들을 해결하느라 고심하고 있다. 과연 이러한 복잡한 문제들은 어디까지 해결할 수 있을까?

수많은 업체들이 통합, 보안 및 거버넌스(governance)에 있어 IT를 괴롭히는 문제들에 대한 치료책으로 SOA 어플라이언스를 선전하고 있다. 하지만 이런 새로운 ‘SOA 인 어 박스(SOA-in-a-box)’ 시스템을 구입하러 나선 설계자와 개발자들은 해답보다 의문만 더 많이 품은 채 돌아오곤 하는 경우가 너무도 많다. 심지어 SOA 어플라이언스가 정확히 무엇을 의미하는지조차도 여전히 제대로 규정되지 않은 상태다.

정확한 의미가 무엇인가
이에 본지에서는 기존의 제품들이 XML 보안, 가속화, 변환 및 파싱(parsing) 기능의 기본적인 것들을 얼마나 잘 처리하는지를 알아보기 위한 롤링 리뷰를 실시해 보기로 했다. 우리는 캐스트아이언(Cast Iron), 시스코시스템즈, IBM, 레이어7, 소프트웨어 AG 및 보델(Vordel)의 SOA 어플라이언스들을 두고 설치와 구성의 편의, 기능성의 폭, 관리 능력, 사양 및 가격 등을 평가해 볼 계획이다.
모든 유형의 어플라이언스들은 IT 전문가에게 인기가 있는데, 그 이유는 이들이 프로젝트를 빨리 돌아가게 하고 처음부터 시스템을 구축하는 것보다 저렴한 총소유비용이 들기 때문이다. 이상적으로 볼 때 이들은 설치와 유지보수의 편의성을 고려해 설계되며, 거의 즉각적으로 네트워크에 통합시킬 수 있다. 그런 다음에는 지원이 거의, 혹은 전혀 필요치 않다.


대부분은 이 어플라이언스를 특수하게 구성된 하드웨어에 미리 설치된 소프트웨어라고 생각하지만, 가상화가 인기를 얻어가면서 하드웨어를 뛰어넘는 ‘가상 어플라이언스’를 추구하는 동향도 목격되고 있다.

세 가지 활용 상황
그렇다면 과연 이러한 정의를 감안할 때 SOA 어플라이언스란 무엇인가? 이 질문에 대답하기 위해서는 SOA에 대한 이해와 어플라이언스가 언제 어디서 도움이 될지에 대한 판단이 필요하다.
<그림: SOA 어플라이언스 활용 상황>에서 보는 바와 같이, SOA 어플라이언스들은 보통 웹 티어(Web tier), 보안, 그리고 통합 및 관리 등 세 가지 이용 상황에 처하게 된다. SOA 어플라이언스는 XML 가속기 어플라이언스에 그 혈통을 두고 있기 때문에 이들 대부분이 웹 티어나 보안 작업에 가장 적합하다고 해서 놀랄 일은 아니다. 하지만 최근에 업체들은 거버넌스 같은 문제를 해결하는 데 목표를 두고 있으며, 이것은 통합 및 관리 부문에 속하는 일이다.
그렇다면 이제 각각의 이용 상황들을 좀더 자세히 살펴보자.
웹 2.0과 SOA의 등장으로 조직들은 웹 티어에서 더 많은 양의 XML 메시지를 경험하고 있다. 애플리케이션에 있는 XML 프로세싱 양이 서버 용량을 초과할 때는 두 가지 일을 할 수 있는데, 즉 더 많은 서버를 추가하거나 프로세싱 부하를 하드웨어 기반의 SOA 어플라이언스로 넘기는 것이다.
SOA 어플라이언스는 또한 애플리케이션 서버나 전통적인 웹 인프라 장비와 짝을 이뤄 역동적이고 확장 가능한 고성능 콘텐츠 전달을 제공할 수도 있다. SOA 어플라이언스에 XML 가속화 기능이 더해지면 XSLT 변환이나 XML 스키마 검증 같은 무거운 XML 프로세싱 작업부하를 힘겨워하는 애플리케이션 서버로부터 덜어줄 수 있다.
보안을 처리하는 SOA 어플라이언스는 채택자들이 최근에 SOA 채택에 가장 큰 장애로 부상하고 있는 것을 극복할 수 있게 해준다. 사실 웹 2.0이나 SOA 같은 기술들은 새롭고 강력한 기능을 선사해주긴 하지만 새로운 취약성을 갖고 올 가능성도 그만큼 늘어난다.
웹 서비스 보안의 베스트 프랙티스를 이행하기 위한 기본적인 XML 프로세싱을 향상시킴으로써, SOA 어플라이언스는 XML 보안에 내재된 성능 감소 요소를 피해갈 수 있음은 물론이고 새로운 표준을 둘러싼 FUD도 극복할 수 있다. 회사 내에서 SOA 어플라이언스는 내외부의 웹 서비스 소비자들을 위한 보안 게이트웨이의 역할을 할 수 있다.
보안 기능이 있는 SOA 어플라이언스가 해결을 시도하는 XML 보안 위협은 넓게 보면 네 가지로 구분된다.

>> 공격자가 웹 서비스를 과부하시킴으로써 유효 요청이 방해를 받거나 거부되는 xDoS, 즉 XML 서비스 거부
>> 웹 서비스나 그 데이터로의 허가받지 않은 액세스
>> 웹 서비스 요청 데이터를 타깃으로 하는 데이터 무결성/기밀성 공격
>> 공격자가 웹 서비스 자체나 이것이 호스팅하는 서버를 더럽히고자 하는 시스템 손상(system compromise)


마지막으로 어플라이언스는 서비스들간의 상호작동에 대한 집중식 관리 및 모니터링을 제공할 수 있는데, 이것은 많은 IT 조직의 운영 범위를 훨씬 벗어나는 일이다. SOA는 그 분산적인, 그리고 잠재적으로 이기종적인 본성으로 인해 거버넌스 또한 문제로 만든다. SOA 어플라이언스는 서비스와 연관된 메타데이터의 수집, 분석 및 관리 기능을 제공할 수 있다. 이것은 따라서 모니터링 능력이 한정된 조직들로 하여금 SOA 거버넌스 전략을 이행할 수 있게 해준다. 결국 모니터링을 할 수 없다면 관리도 할 수 없는 일이다.
관리 능력이 있는 어플라이언스들은 정보를 뽑아내서 이것을 SOA에 있는 다른 컴포넌트와 공유할 수 있는 기능 외에도, 다양한 유형의 콘텐츠들간에 변환을 수행하고 수준 높은 통합을 이행할 수 있는 능력을 갖고 있다. 기업간 SOA를 이행하는 조직들에게는 상호운용성이 문제가 되는 경우가 많다. SOA 어플라이언스는 보안이나 신원정보 같은 데이터를 중개하는 게이트웨이로 작동함으로써 호환되지 않는 환경을 연결시켜 줄 수 있다.

구성에 대한 모든 것
SOA는 다름 아니라 기존의 IT 자산을 활용하는 것이며, 여기서부터 통합이 개입이 된다. 레거시 애플리케이션을 선별해서 이들의 웹 서비스로서의 분리된 기능성을 전용 어댑터를 통해 노출시킴으로써 기존의 IT 자산들이 느슨하게 연결될 수 있다. 이것은 통합을 맞춤식 개발 작업이 아니라 구성 작업이 될 수 있게 해준다. 건축에서 보면 건설이라기보다는 구조, 조립에 가깝다.
어플라이언스는 SOA 부문에 잘 들어맞는데, 그 이유는 이들은 분명 구성이 가능하기 때문이다. 이들은 당신이 코드를 개발해야 할 무엇이 아니다. SOA 설계자에게 있어 SOA 어플라이언스는 하나의 실체적인 서비스로 여겨질 수 있다. SOA에 별개의 기능성을 제공하는 네트워크 컴포넌트며, SOA에 있는 다른 여느 컴포넌트와 마찬가지로 독립적으로 확장되거나, 혹은 구조적인 필요에 따라 제거될 수 있다.
SOA의 본성은 조직에게 아키텍처를 운영적으로 제어할 수 있게 해주며, 그럼으로써 TCO가 감소된다. 어플라이언스는 또 여기서 한 단계 더 나아가 그 자체로는 적합한 수준의 서비스를 제공할 수 없는 소프트웨어 조각들에 대해 성능과 확장성 면에서 서비스 수준을 향상시킨다. 필요에 맞는 최고의 SOA 어플라이언스를 선택할 수 있도록, 우리는 보안, 가속화, 변환 및 파싱 기능을 염두에 두고 SOA 어플라이언스 제품들을 비교해 보았다(테스트 사양은 <박스: SOA 어플라이언스 롤링 리뷰> 참조).


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.