제공 :
한빛 네트워크
저자 : Dan McCreary
역자 : 유일호
원문 :
Five RESTful Friends
1990년대 NeXT에서 근무하면서 처음으로 최신기술을 배우고 있을 무렵에 객체지향은 비교적 새로운 주제였다. 그리고 캡슐화, 상속, 메시징 및 동적결합 처럼 배워야 할 소프트웨어 테크닉들이 아주 많았다. 그러나 이런 시스템들의 상당수가 월드와이드웹이 있기 이전에 만들어졌고 그것이 전달하는 중요한 메시지들의 상당부분이 그 당시에는 적합했지만 넓게 분포된 오늘날의 웹 환경에서는 덜 중요하게 되어버렸다. 나는 웹 응용프로그램 개발의 새로운 측면을 다시 한번 재조명해 볼 것을 제안하고자 한다. : 리소스 지향
리소스 지향은 여러분이 관리하기를 원하는 것들에 대해 조화롭고 견조한 URL(URI) 들을 만드는 법에 대해 생각하도록 묻는다. 만약에 여러분이 고객, 송장, 구매주문이나 상품을 관리한다면 어떻게 이런 물품들과 그들이 지닌 데이터를 구별해야 할지 생각해봐야 할 것이다. 이것을 모두 하려면 여러분의 응용프로그램을 훨훨 날게 해줄 새로운 친구들을 사귀어야 할 것이다. 그 친구들을 소개시켜 주도록 하겠다.
여러분의 첫번째 친구는
컴퓨터의 로컬 메모리 또는 RAM 자원이다. 로컬 메모리는 매우 빠르고 자원을 메모리상에서 변환시켜 매우 짧은 시간 안에 화면에 표출할 수 있다. 여러분은 느리게 돌아가는 하드디스크 드라이브에게 자원이 어딨는지 찾아보라고 물어볼 필요가 없다. - 아마도 그것은 바로 저만치에 있을 것이다.
XForms 를 사용하면 자원을 브라우저 안의 “model” 안으로 직접 적재할 수 있는 능력을 갖게 된다. 모든 선택 리스트는 화면에 띄워지기 이전에 메모리 상에서 대기하고 있을 수가 있고, 더불어 크기가 크고 많은 수의 선택 리스트를 가지는 웹 응용프로그램을 당신의 브라우저에 바로 띄울 수가 있다.
두번째 친구는
로컬 하드디스크 드라이브 혹은 웹브라우저 캐쉬라고 알려져 있는 녀석이다. 비록 로컬 캐쉬가 풍부하지만, 그만큼 느리기 때문에 여러분의 로컬 하드드라이브가 아직까진 데이터들을 담아두기엔 아주 좋은 장소이다. 많은 사람들이 웹브라우저 캐쉬는 정적 HTML페이지와 이미지들을 위한 것이라고 생각하곤 한다. 그러나 그것은 XML 데이터를 저장하는데 또한 알맞으며, 화면 또는 웹 응용프로그램에 재사용할 수 있다.
세번째 친구는
지역 웹캐쉬 또는 공용 캐쉬이다. 이것들은 캐쉬를 관리하고 최적화하기 위해 만들어진 인기있는 오픈소스 소프트웨어 패키지의 이름을 따와서 간혹
Squid cache 라고 부르기도 한다. 만약 여러분이 조직의 IT를 담당하는 사람이라면 공용 프록시 캐쉬가 효과적으로 인터넷 대역폭 요구량을 감소시키고, 캐슁과 함께 정적 페이지, 이미지 및 XML 리소스 같이 빈번하게 요청되는 웹 자원을 재사용 함으로써 응답시간을 향상시킬 수 있음을 알고 있을 것이다. 비록 초기에는 Squid 양식장이 작고 단촐했지만 지금은 인터넷 공간의 데이터 재전송 최적화를 시도하기 위해 한층 더 복잡한 Squid 캐쉬 계층을 가지고 있다. Squid 는 또한 컨텐츠 공급자들이 전세계에 컨텐츠를 배포하는데 사용될 수 있다 – 부피가 큰 컨텐츠 전부를 비효율적으로 복사하는 것 보다는 사용될 컨텐츠만 복사하는게 더 효율적이다.
공용 프록시의 확장은
Akamai 같은 상용회사에 의해 제공되는 지역 데이터 캐쉬이다. 비록 실시간 재생이 필요한 사운드 또는 비디오파일과 같이 시간이 중요시되는 파일전송에 많이 사용하지만, 이런 시스템들은 지금의 인터넷 인프라를 구성하는 필수적인 요소이며, 많은 지역 ISP 들이 끊임없이 인터넷 백본(backbone) 으로 오고가며 재전송 되는 데이터를 최소화하기 위해 이 시스템들을 사용하여 서비스를 제공하고 있다.
네번째 친구는
웹 응용프로그램 서버 클러스터의 웹캐쉬이다. 웹서버들은 종종 단독 웹서버가 아닌 전면에 로드밸런싱 장치를 갖춘 여러대의 웹서버 클러스터들로 구성된다. 이 로드밸런서들은 모든 웹자원 요청을 효과적으로 처리하기 위해 각각의 웹리퀘스트를 최대한 여유가 있는 웹서버로 지정한다. 그것들은 보통 웹자원이 정적인지, 로컬 복사본을 가지는지, 아니면 새로운 데이터를 얻기 위해 데이터베이스를 귀찮게 할 필요가 있는지를 알 수 있을 만큼 똑똑하다. 그것들은 종종 다른 서버로부터 변경된 파일을 업데이트할 필요가 있다면 그것을 알아 차리기 위해 타임스탬프를 사용하곤 한다.
그리고 마지막으로,
데이터베이스 서버 그 자체에 대해서 생각해 보면 그것 또한 어떤 처리를 하기에 앞서 그것을 잠시 보유하는 정보 캐쉬를 가질 것이다. 많은 최신 데이터베이스들은
column store 같이 미리 계산된 합계들과 평균들을 제공하는 혁신적인 구조를 가진다. 여러분이 주문이 업데이트된 총계가 필요하다면 총계는 벌써 데이터베이스에 의해 미리 계산되어 있을 것이다.
내가 발견한 것은 몇몇 새로운 웹 응용프로그램 아키텍트들이 어떻게 이 다섯 친구들이 응용프로그램을 수행하는데 서로 도움을 줄 것인지에 대한 명확한 사고모델(mental model)을 가지고 있지 않다는 것이다. 많은 웹 응용프로그램 엔지니어들은 SOAP 메시지들을 서버에서 클라이언트 응용프로그램으로 보낼 때 이 다섯 친구들이 그들을 돕기 위한 많은 힌트를 줄 것이란 사실을 이해하지 못한다. 그러나 만약 여러분이 여러분의 URI를 정확하게 디자인했다면 당신의 다섯 친구들은 언제나 당신곁에 도움을 주기 위해 기다릴 것이다.
이것이 바로 XRS 웹 응용프로그램 아키텍처가 점점 인기를 끄는 이유 중 하나이다. 그들은 웹인프라를 극대화할 수 있도록 하지만 시스템을 망가뜨리려고 하지 않으며 당신을 돕기 위한 준비가 항상 되어 있다.
수많은 테이블에 Join이 포함된 막대한 양의 SELECT 로 당신의 데이터베이스를 귀찮게 하기 전에 도움을 얻기 위한 질문을 여러분의 다섯 친구들에게 해보길 바란다. 아마도 여러분은 여러분의 웹 어플리케이션이 조금은 빠르게 동작한다는 사실을 발견하게 될 것이다. 그리고
MarkLogic 과 같은 네이티브 XML 데이터베이스는 어떤 정보를 고유의 계층구조 형태로 미리 저장하기 때문에 대개 본질적으로 RDBMS 보다 더 빠르다는 것을 기억해 두길 바란다.
그외 부가적인 정보는 Wikipedia 에서
REST 와
XRX 에 관련된 글을 볼 수 있다.