글

라벨이 Web Services인 게시물 표시

컬럼: 전환기의 미들웨어

사보에 실었던 컬럼(2012년 4월호)을 블로그로 포스팅합니다. 한계가 컸던 웹서비스 지난 10 여년간 컴퓨팅 패러다임을 바꿀 것으로 기대했던 흐름 중 하나는 웹서비스였다 . 1998 년 마이크로소프트 사에서 정의한 SOAP (Simple Object Access Protocol) 스펙에 기원을 둔 웹서비스는 마이크로소프트 , IBM, BEA( 지금은 Oracle 에 인수됨 ) 3 사의 엄청난 지원에 힘입어 국제 표준으로 자리잡았으며 , 플랫폼과 프로그래밍 언어에 독립적인 XML 의 장점과 원격 프로세스 호출 (RPC) 아키텍처를 결합한 서비스 중심 아키텍처 (SOA) 라는 IT 패러다임을 만들었다 . 하지만 웹서비스는 기대했던만큼 혁신적인 변화를 가져오지 못했다 . 기업은 웹서비스 도입을 꺼려했고 , 컨설팅 주도로 부풀려진 SOA 아키텍처는 기대했던 유연성과 확장성을 가져오지 못했다 . 오히려 성능 저하 , 처리 능력 저하 , 하드웨어 비용 증가의 문제를 일으켰다 . 웹서비스의 실패와 이에 따른 SOA 기피 현상은 기업 주도로 만들어진 인위적인 새로운 흐름의 문제점을 보여주었다 . 가장 큰 문제는 CPU 과다 사용이었는데 XML 자체의 파싱 오버헤드도 있었지만 SOAP 규격이 정의한 Enveloping 오버헤드 문제 , XML namespace 규격의 불필요한 prefix 오버헤드 문제 등 표준 규격 진행 과정에서 성능을 고려하지 않은 부분들이 스스로의 한계를 규정하고 말았다고 볼 수 있다 . 클라우드 컴퓨팅 뜬구름 같은 이야기 , 클라우드 컴퓨팅은 웹서비스의 한계를 여러 측면에서 반성하면서 탄성 있는 확장성과 관리 비용 절감 등을 내세우며 아마존 , 구글과 같은 웹 중심 기술 기업에서 구현하여 제시하고 있는 새로운 컴퓨팅 스택이다 . 클라우드 컴퓨팅은 컴퓨팅 리소스의 위치에 따라 public cloud 와 private cloud 로 구분할 수 있다 . Public cloud 의 ...

REST가 SOAP을 밀어내고 Web API의 실질적 표준으로

이미지
아래 그림은 New Job Requirement: Experience Building RESTful APIs 라는 기사에서 인용해온 것입니다. 출처 :  New Job Requirement: Experience Building RESTful APIs Web API로 제공되는 프로토콜의 추세를 보여주는 그림으로 이미 2008년에도 REST가 SOAP의 두 배 이상을 제공하고 있었지나 지금은 다섯 배에 가까운 비중을 차지하므로, 대부분의 신규 웹 API들은 REST 기반이라고 읽을 수 있습니다. SAAS(Software as a Service)의 대명사라고 할 수 있는 Salesforce.com은 SOAP API 기반의 웹서비스로 구축되어 있었는데 최근에 REST API를 제공하기로 결정했다고 합니다. 개인적으로는  2003년부터 SOAP을 직접 XML 파싱하여 처리하면서 성능이나 효율을 높이기 위해 고심을 했었는데, 결과적으로 스펙이 처리 성능을 전혀 고려하지 않았다는 심증을 굳히곤 했습니다. SOAP은 불필요한 envelope을 원본 데이터 XML 위를 감싸고 또 뜯어내는 처리를 필요로 합니다. 대부분의 경우 별도의 의미를 갖지 않음에도 불구하고 만들어진 XML 문서를 다시 envelope의 body 부에 끼워넣고 또 발라내는 작업을 해야 합니다. API 호출 빈도가 높아질수록 가벼운 API가 점점 더 성능의 한계로 다가오게 됩니다. 개인적으로는 XML도 성능 관점에서 선호하지 않는 편인데요, 특히 namespace 덕분에 프로세싱에 부담을 주는 XML의 발전 방식은 불필요한 무거움 자체입니다. ns 표준을 프로세싱을 전혀 신경 안쓰고 정하는 것이 맞을까? API들은 분산 환경에도 불구하고 상당히 상세한 수준에서 open되어 하나의 기능을 위해 매우 많이 호출되는 경우도 많습니다. 전통적으로 원격 통신을 하는 방법은 상위 수준의 API만 노출하고 빈번하게 호출될 가능성이 높은 하위 수준의 세세한 API는 공개하지 않거나 사용...