Web 2.0 Killed the Middleware Star

원제 : Web 2.0 Killed the Middleware Star

번역 : Web 2.0 Killed the Middleware Star

"PaaS 서비스 확장을 위한 모델은 정확하게 무엇인가? HTTP/REST 통합에 바탕을 두고 있다면, 꽤 단순합니다. 기본 미들웨어를 사용한다면, 입력은 ……. " 라는 아주 순수하게 간단한 질문에서 시작했습니다. 여러분은 추가된 단계를 받아들여야 합니다 – Twitter의 한계는 때때로 이런 본성에 대한 대화를 만듭니다 … 흥미롭지요.

토론은 미들웨어가 PaaS 측면에서 거의 한물간 구식이라는 정서로 끝이 납니다.

THE OLD WAY

응용프로그램 아키텍처 유능하기 보다 인프라스트럭처 / 네트워크를 잘 이해하는 여러분들을 위해 매우 간단하게, 전통적인 미들웨어 기반 응용프로그램 아키텍처를 살펴봅시다.

일반적으로, 미들웨어는 – 일명 JMS, MQ 시리즈와 대부분 ESB- 지렛대 데이터 공유의 발행-구독 모델을 가능하게 하는 수단으로써 사용됩니다. 기본적으로, 미들웨어는 통합 패턴이지만, 기업환경에서 사악한 단어 "통합(integration)"의 함축 때문에 누구도 정말로 받아들이기를 좋아하지 않습니다. 그러나 이점이 사용하는 목적입니다 – 자료공유를 통해 응용프로그램을 통합하기 위해서죠. 포인트-포인트 통합 모델에서 더욱 효율적인데, 특별히 응용프로그램 하나가 둘 이상의 다른 응용프로그램과 데이터를 공유가 필요할 때입니다. 하나의 응용프로그램은 데이터를 큐에 넣고 다른 응용프로그램은 큐에서 데이터를 꺼냅니다. "메시지"의 목적이 다중 응용프로그램이거나 사람이면, 큐는 주어진 시간 동안 메시지를 유지하고 반면에, 의도한 수신자가 메시지를 받은 후에 메시지를 지우거나 보관합니다(또는 둘 다 합니다).

이 패턴이 최근 활동하는 대부분의 SNS와 비슷하기 때문에, 이 패턴은 아마도 기업 응용프로그램 아키텍처에서 견고하지 못한 사람들과 매우 유사합니다. 한 사람은 상태 갱신과 메시지를 적고, 모든 응용프로그램과 구독한 사용자에게(follow-twitter, circle-google+, friended-facebook) 전달됩니다. 웹 기반 SN과 전통적인 기업 응용프로그램과 차이점은 두 가지 입니다.:

• 첫째–  Web 2.0과 특별히 AJAX가 출현하기 전까지, 웹 기반 응용프로그램은 메시지를 "polling for" 또는 "구독하는" 데 잘 어울리지 않는다. 따라서 웹 응용프로그램을 위한 전통적인 발행-구독 아키텍처의 사용은 더 이상 견인을 얻지 못한다.
• 둘째– 미들웨어는 전통적인 확장 모델을 이용하여 잘 확장한 적이 없습니다(scale-up, scale-out). 웹 기반 응용프로그램은 일반적으로 미들웨어의 장점을 적용한 전통적인 응용프로그램보다 더 높은 용량과 트랜잭션 비율을 요구하고, 확장이 안 되는 미들웨어를 문제로 만듭니다. 미들웨어는 응답의 민첩함이 성공의 필수적인 요소인 SN이나 다른 큰 크기의 데이터 공유 시스템에 어울리지 않습니다.

또한 James Urquhart 가 토론에서 앞서 밝힌 것처럼, 클라우드 컴퓨팅(cloud computing)과 가상화가 VM계층에서 미들웨어를 확장하여 확장이슈를 다루는 능력을 보였지만 – VM 계층은 확실히 성공적이고 규모의 관점에서 솔루션을 확장 가능하게 해준다. - 이 점은 CAP처럼 일치에 대한 이슈가 나왔는데(introduces issues with consistency, a.k.a. CAP), 지속성은 다루지 못하며 따라서 사용자들이 공유한 큐 사이의 메시지의 일치는 항상 의문점이다. 기본적으로, –James Saull 이 지적한 대로 - 우리는 기본적으로 문제를 다른 티어-확장 가능한 지속 서비스-로 차버리고 토론을 끝냈다. 메시지 미들웨어 확장에 관련된 타고난 도전을 다루는 가상화와 클라우드 컴퓨팅의 힘을 사용하더라도 일반적으로 데이터베이스 기반의 솔루션을 의미한다. 기억하세요, RDBMS가 관련된 게 아니고, 몇 종류의 데이터 저장과 모든 데이터 저장이 일치, 신뢰, 확장에 대한 비슷한 아키텍처와 기술적인 이슈를 도입하고 있습니다.

THE NEW WAY

Now this is not meant to say the concept of queuing, of pub-sub, is absent in web applications and social networking. Quite the contrary, in fact. The concept is seen in just about any social networking site today that bases itself on interaction (integration) of people. What’s absent is the traditional middleware as a means to manage the messages across those people (and applications). See, scaling middleware ran into the same issues as stateful applications – they required persistence or a shared-nothing architecture to ensure proper behavior. The problem as you added middleware servers became the same as other persistence-based issues seen in web applications, digital shopping carts and even today’s VDI implementations. How do you ensure that having been subscribed to a particular topic that you actually manage to get the messages when the load balancing solution arbitrarily directs you to the next available server?이것은 큐와 발행-구독의 개념을 이야기하는 것을 의미하지 않고, 웹 응용프로그램과 소셜 네트워킹에서 부재를 의미한다. 오히려 그 반대가, 사실이다. 개념은 사람들의 상호동작(통합)에서 스스로를 기본으로 하는 최근의 어떤 소셜네트워크 사이트에서 보여지고 있다. 부재했던 무엇은 사람들간의(그리고 응용프로그램간의) 메시지를 관리하는 수단으로서 전통적인 미들웨어이다. 보라, 미들웨어 확장은 상태 있는 응용프로그램으로서 같은 이슈를 발생시켰다 – 상태 있는 응용프로그램은 지속성이나 적절한 동작을 보장하기 위해 아무것도 공유하지 아키텍처를 필요로 한다. 여러분이 미들웨어 서버를 추가함으로 문제는 웹 응용프로그램, 디지털 쇼핑 카드와 심지어 오늘날의 VDI 구현에서 보아온 다른 지속성 기반 이슈(persistence-based issues)와 동일하게 되었다. 로드밸런싱(load balancing) 솔루션이 임의적으로 다음 가능한 서버로 여러분을 이끌어주는데, 메시지를 얻기 위해 실제적으로 관리하는 특정한 주제의 구독을 어떻게 확신할 것인가요?

여러분은 할 수 없습니다. 이런 이유로 미들웨어의 확장을 가능하게 하는 지속적인 저장의 사용. 여러분이 끝내야 하는 것은 근본적으로 4 tier 입니다 – 웹, 응용프로그램, 미들웨어, 데이터베이스. 이 점에서 여러분은 이들 중의 하나가 불필요하고, 웹 기반 제약의 상위이고, 불필요하다는 것을 인식하게 되었을 것입니다. 세 개중의 하나라고 추정하고, 처음 두 개는 포함되지 않습니다. 

맞습니다. 미들웨어 티어입니다. Web 2.0 응용프로그램은 일반적으로 사용자 또는 응용프로그램을 가로지는 메시징을 가능하게 하기 위해 미들웨어 티어를 사용하지 않습니다. Web 2.0 응용프로그램은 API와 소스에 직접 다가가는 웹 기반 데이터베이스 접근 메서드를 사용합니다. 같은 개념으로, 더욱 확장 가능한 구현, 더 적은 복잡성. James과 토론 이후에 추가를 했듯이, "'증명된' 아키텍처는 Web2로 보이며, 자체의 한계를 가지고 있습니다the “proven” architecture seems to be Web2, which has its limitations."

BRINGING IT BACK to PaaS

이런 점이 PaaS와 어떻게 관련될까요? 자, PaaS는 클라우드 컴퓨팅 환경에서 개발자 서비스를 묘사하는 모호한 방법인 서비스로서 플랫폼(Platform as a Service)입니다. 데이터, 메시징, 세션 관리, 라이브러리; 전반적인 응용프로그램 개발 생태계. 이런 컴포넌트의 하나가 메시징이고, 그럴 것처럼, 전통적인 미들웨어 입니다(물론, 서비스로서). 그러나 미들웨어 확장 이슈는 실제로 해결되지 못했고 지속성 이슈는 남아 있습니다.

 

압력을 가하는 것은 미들웨어는 전통적으로 배제하던 웹 개발 패러다임입니다. 대부분 젊은 개발자는 큐 시스템과 전통적인 발행-구독 구현을 다뤄본 경험이 없습니다(그리고 그들은 이점에 대해 스스로 다행으로 생각해야 합니다).  그들은 직접 데이터베이스 연결을 이용하고 AJAX와 API를 통해 최신 내용을 가져오는 메시징 개념을 구현한 개발자의 3-티어 세대입니다. 큐는 포함되었지만 포함되었다면, 큐는 데이터베이스-지속적인 저장-와 함께 결합으로 구현되었고 클라이언트는 미들웨어를 통하지 않고 직접 응용프로그램 티어를 통해 접근합니다.

 

웹과 응용프로그램 티어 가 클라우드 컴퓨팅 환경에서 확장되기 쉬운 점은, 더 나아가, 최근의 높게 통합된 웹 응용프로그램과 관련된 높은 동시접속자와 트랜잭션 규모 요구사항(성능에 관한 게 아닌)에 직면하게 됩니다. 가상 계층에서 미들웨어 서비스 확장은, 위에서 말한 것처럼, 가능하지만, 지속적인 저장의 필요성을 다시 꺼냅니다. 지속적인 저장을 사용하기로 했다면, Web 2.0이 우리에게 소스에 직접 붙는 것이 가능할 뿐 아니라 더욱 확장성 이 있다고 보여주고 있는데, 왜 아키텍처에 복잡한 계층을 추가해야 할까요?

그날의 끝에, 클라우드 컴퓨팅 모델과 Web 2.0이 서비스로서 한물간 미들웨어 없이 메시징을 공유하는 개념을 해결하도록 – 이게 성공적으로 이뤄지고 있는데- 강제하고 있다고 확실하게 보였습니다. 죽지 않았지만, 기억하세요, 누군가 필수적인 컴포넌트인 유스케이스를 발견한다면, 그런 경우는 매우 극소수이겠죠.  확장과 연관된 지속성 이슈는 몇몇 제공자들이 해결 했으며 – 예로 RabbitMQ – 그러나 미들웨어를 요구 하지 않는 Web 2.0이 강제하는 솔루션의 실제 아래에 놓여있어 잊고 있었으며 발행-구독과 다른 비슷한 아키텍처 패턴을 구현하는 메커니즘으로써 거의 모든 웹 기반 응용프로그램은 미들웨어를 피해야 합니다. 미들웨어 없이 웹에서 상쾌하고 싶고, 좋은 이유가 아니라면 클라우드 에서 복잡성과 비용의 또 다른 계층을 왜 도입해야 할까요..

Viva la evolution(진화 만세!).

Related Articles

• On Hacker News