Vert.x 3 의 아버지 Tim Fox 와의 인터뷰 (Node,Akka,마이크로서비스등)

 Vert.x 3 의 아버지 Tim Fox 와의 인터뷰 

(https://www.infoq.com/articles/vertx-3-tim-fox)

Vert.x는 비동기식의 확장 가능한 동시 서비스 개발 모델을 제공하는 JVM용 리액티브 마이크로 서비스 툴킷입니다. 자바스크립트, 루비, 그루비, 스칼라에 대한 폴리글랏 언어 개발을 지원합니다. 물론 자바도.

InfoQ는 Vert.x 수석 아키텍트이자 창시자인 Tim Fox와 함께 Vert.x와 곧 출시 될 Vert.x 3 릴리즈에 대한 생각을 접할 기회를 얻었습니다. Tim은 Vert.x와 Java EE, Spring, Akka 를 비교하고 Vert.x가 마이크로서비스, 리액티브 개발에 어떻게 적합한 지를 설명할 것입니다.

InfoQ : Vert.x 란 무엇이며 왜? 그리고 누가 Servlet이나 Java EE 또는 Spring과 같은 전통적인 Java 스택 대신 이를 선택합니까?

Tim : Vert.x는 JVM에서 플리글랏 리액티브 애플리케이션을 작성하기위한 툴킷입니다. 전통적인 스택과는 달리 마이크로 서비스를 염두에 두고 설계되었으며, 확장성을 염두에두고 설계되었으므로 거의 블로킹되지 않습니다 (OS 스레드).

이는 많은 동시성을 처리해야하는 많은 현대적 응용 프로그램에 중요합니다. 많은 메시지 또는 이벤트를 처리하거나 많은 연결을 처리합니다.

또한 기존 Java 스택과 달리 Vert.x는 Java가 아닌 다른 언어를 지원합니다. JS, Ruby 및 Groovy를 사용하여 항상 Java를 사용하도록 강요하지 않으며 현재 작업 중이거나 팀의 기술 집합에 가장 적합한 언어를 사용할 수 있습니다.

Vert.x는 컨테이너 또는 "프레임 워크"가 아니라 툴킷입니다. 즉, 기존 응용 프로그램에서이 응용 프로그램을 사용하여 Vert.x 초능력을 사용할 수 있습니다. 예를 들어 Spring 애플리케이션 내에서 사용할 수 있으며 많은 사용자가 사용할 수 있습니다.

InfoQ : 스프링에 대한 당신의 생각은 무엇입니까? 스프링 리액터? 스프링 부트? Node.js?

Tim : 나는 스프링을 존경합니다. 그들은 풍부한 생태계를 만드는 데 놀라운 일을 해 왔으며 에코시스템 아래 모든 것을 수행하는 구성 요소가 있습니다. Vert.x의 가장 큰 장점은 Spring API가 블로킹하고 확장성을 제한한다는 것입니다. 그리고 Spring은 Vert.x와 같이 다중 언어가 아니라 Java 만 사용합니다.

그러나 나는 Vert.x를 Spring의 경쟁자로 보지는 않을 것 입니다. Vert.x는 Spring 생태계 만큼 많은것들을 포함 할 것 같지 않습니다. Vert.x는 단지 라이브러리이며 같은 애플리케이션에서 Spring과 함께 사용할 수 있다는 것을 잊지 마십시오. 시간이 지남에 따라 Spring 생태계의 더 많은 구성 요소가 블로킹 되지 않게 되므로 확장성있는 응용 프로그램에서 더 성공적으로 사용 될 수 있습니다.

우리는 이미 Spring 에코 시스템의 일부 (예 : project reactor) 가 논블럭, 이벤트 중심 접근법을 사용하고 있음을 알고 있습니다.

참고 : SpringSource / VMWare의 프로젝트 리액터는 Tim Fox가 VMware를 떠나 RedHat에 합류 한 직후에 나왔습니다. Project Reactor는 Vert.x의 경쟁자이며 초점과 스타일면에서 비슷합니다.

InfoQ : Java EE에 대한  생각은 무엇입니까? 애플리케이션 서버에 대한 귀하의 생각은 무엇입니까?

Tim : Java EE는 원래 현대 응용 프로그램에 필요한 것과 매우 다른 개발 및 배포 모델로 설계되었습니다. Java EE 애플리케이션 서버는 네트워크상의 어딘가에 있고 JAR 패키지 된 애플리케이션을 배치한 monolithic  서버를 가지고있었습니다. 이것은 마이크로서비스 모델의 반대입니다.

게다가 대부분의 Java EE API는 기본적으로 동기식이므로 대부분의 Java EE 응용 프로그램 서버는 I / O에서 블럭되는 많은 것들 (원격 JDBC 호출, JTA 호출, JNDI 조회, JMS가 많이 포함되어 있어도) 이기 때문에 스레드 풀을 추가하여 확장해야합니다. 우리가 알고있는 것처럼 스레드 풀을 추가한다고 해도 확장성 측면에서 부족합니다. 그래서  Java EE는 기본 디자인 자체가  절름발이라 많은 동시성이 필요한 응용 프로그램에 대해서는 결코 좋은 선택이 될 수 없습니다.

Vert.x는 여러면에서 Java EE에 대한 반작용으로 만들어지게 되었습니다.공정하게 말하면, 지난 몇 년 동안 Java EE를보다 쉽게 ​​사용하기위한 움직임이 있었고 일부는 리액티브 마이크로 서비스에 적합한 모델로 Java EE를 재 포장하려는 노력을 보았습니다. Java EE는 그 모델을 염두에두고 설계된 적이 없으며,  그러한 깊은 변화를 위해서는 이를 버리고 다시 시작해야 할 수도 있습니다. 나에게 이것은 엄청나게 힘든 투쟁일것 같습니다. Vert.x를 만들 때 우리가 했던 것과 정확히 같습니다.

InfoQ : Scala와 Akka에 대한 생각은 무엇입니까?

Tim : 스칼라의 힘, 그리고 스칼라에서 프로그램 할 수있는 사람들을 존경합니다. 나에게 스칼라가 가지는 주요한 문제는 너무 어렵고 많은 일을 시도하는 것 입니다. 이는 자바처럼 진정한 주류가 될 수 없다는 것을 의미하는데요. 하지만 당신이 그것을 처리 할 수있는 슈퍼 인텔리전트 개발팀을 가지고 있다면 스칼라가 훌륭한 선택이 될 것입니다.  

Akka는 제가 존중할 수있는 훌륭한 시스템입니다. 일부에서는 Vert.x와 유사한 접근 방식을 취합니다. Vert.x는 동시성에 대해 "액터와 같은"접근 방식을 사용하며 변경 가능한 공유 데이터를 사용하지 않습니다. 또한 Vert.x와 Akka는 새로운 반응형 스트림 "표준"을 사용하여 상호 운용됩니다. Vert.x와 Akka는 어느 정도까지 동일한 Zeitgeist (시대정신) 을 가지고 있습니다. ^^

저는 Vert.x와 Akka를 "어느 쪽이든" 하나를 선택하는 상황으로 보지 않습니다. 나는 Vert.x와 Akka 각각이 설치되어 서로가 행복하게 대화하는 것을 보게 될 것이라고 생각합니다.

InfoQ : Vert.x의 성능은 Node.js의 성능과 어떤 차이가 있습니까?

Tim : 글쎄, 요기서 함 보실래요?   -TechEmpower BenchMarks (Vert.x 가 월등) 

InfoQ : 마이크로 서비스 및 리액티브 아키텍처에 대한 업계의 방향을 감안할 때 Vertx 의 방향이 옳은 것으로 느껴지십니까?

Tim : 그렇게 생각합니다. 2011 년에 Vert.x (또는 Node.x)를 시작했을 때 응용 프로그램 서버 기반 응용 프로그램의 복잡성에 대한 대처 방법으로 시작된 것입니다.

첫 번째 버전부터 Vert.x는 항상 자체 인프라 스트럭처 또는 "응용 프로그램 서버"를 사전에 배포하지 않고도 어디서나 원하는 언어로 실행하여 자체 코드로 코드를 작성했습니다.

응용 프로그램 개발 및 배포의 마이크로 서비스 모델을 추진하는 첫 번째 프로젝트 중 하나였습니다. 이제는 이것이 대중화되고 있음을 알았습니다. 그렇습니다. 나는 확신합니다.

그러나 이것에 또 다른면이 있습니다. 아이디어가 더 주류가되면 보다 넓은 생태계가  함께 오는 것 같아요. 모두가 뛰어들어서 스스로를 마이크로 서비스로 선언할것입니다.  우리는 이제 이것을 하나의 jar 로 압축하여 메인 클래스를 추가하고 스스로를 마이크로서비스 또는 "비 반응적"이라고 선언하는 모놀리식 (monolithic)으로 설계된 다양한 전통적인 플랫폼을 볼 수 있습니다.

마이크로서비스 외에도 Vert.x의 핵심 기능은 항상 논블럭입니다. 최소한의 스레드를 사용하여 많은 동시성을 처리 할 수 ​​있도록 응용 프로그램을 확장 할 수 있어야합니다. 많은 사용자가 이제 이것이 중요하다는 것을 깨닫고 있습니다.

대부분의 최신 응용 프로그램은 많은 양의 데이터를 처리하고 많은 메시지와 이벤트를 처리하거나 많은 연결을 처리하기 때문에 스레드 풀 및 블로킹 (OS 스레드) 구현을 통해이를 효과적으로 수행 할 수 없습니다. 확장성을위한 이벤트는 "반응성"의 큰 부분이며 반응성 또한 주류가되고 있음을 알면 좋습니다. 지난 2년 동안 리액티브 시스템이 JAX 혁신상 (작년 Vert.x, 올해 Akka)을 수상했습니다.

많은 사용자가 이제 이것을 얻었으며 논블럭은 이제 몇 년 전보다 훨씬 주류처럼 보이기 때문에 이것이 접근법의 근거라고 생각합니다.

InfoQ : Vert.x 2와 Vert.x 3의 주요 차이점은 무엇입니까?

Tim : 우리는 Vert.x 3에서 많은 것을 할애하여 사용하기가 더 쉬워졌습니다.

몇 가지면에서 Vert.x 2는 꽤 컨테이너와 비슷했지만 Vert.x 3에서는 그 중 많은 부분을 제거했으며 Vert.x 3은 실제로 삽입 가능합니다. Vert.x 3 문서에서 Vert.x가 프레임 워크 또는 컨테이너가 아니라고 말하는 이유가 여기에 있습니다.

또한 클래스 로더 모델을 간소화했으며 기본적으로 단순한 플랫 모델 (예 : 별도의 클래스 로더가 없음)을 보유하고 있습니다. 이것은 단순 메인 클래스로 마이크로 서비스를 작성하고 원하는 부분을 사용하고 이동하려는 세계에 훨씬 더 적합합니다.

Vert.x 3에는 RxJava에 대한 지원 기능이 내장되어 있습니다. 모든 API의 Rx ified 버전을 제공하므로 콜백 기반 방식 (예 : Node.js와 유사)을 선호하지 않는 경우가 있습니다. 특히 여러 개의 데이터 스트림을 조정하려는 경우 Rx API를 사용하면 기능 스타일 작업을 사용하여 스트림을 결합 및 변환 할 수 있습니다.

또한 우리는 Vert.x의 실험적인 새로운 기능을 연구하여 클래식 동기 스타일로 응용 프로그램을 작성할 수 있지만 실제로 OS 스레드를 블럭하지는 않습니다. 아이디어를 사용하면 확장 성 이점을 얻을 수 없습니다. OS 스레드를 블럭하지만 비동기 API에 대한 프로그래밍의 콜백 지옥이 없습니다. 즉, 누워서 떡먹기입니다. 우리가 올바르게 이해할 수 있다면, 이것이 킬러 기능이라고 생각합니다.

Vert.x 3의 또 다른 핵심 기능은 바로 Vert.x-Web입니다.이 도구는 Vert.x를 사용하여 최신 웹 응용 프로그램을 작성하기위한 툴킷입니다.

Vert.x-Web에는 세련되고 현대적인 확장 가능한 웹 응용 프로그램을 만드는 데 필요한 모든 요소가 포함되어 있으며 물론 Vert.x에서 지원하는 모든 언어에서 사용할 수 있습니다. 여기에는 쿠키 및 세션 처리, 플러그 가능 인증, 템플리트 작성, 웹 소켓, SockJS 지원, 컨텐츠 협상 및 기타 많은 기능 등 기대할 수있는 모든 것이 포함되어 있습니다.

'전통적인'서버에서 렌더링 된 웹 응용 프로그램, HTTP / REST 마이크로 서비스 또는 클라이언트에서 렌더링 된 웹 응용 프로그램 등, 작성중인 모든 종류의 웹 응용 프로그램에 가장 적합합니다.

진행중인 새로운 작업 인 Vert.x 3 웹 사이트를 탐색 할 수 있습니다.이 사이트에는 다양한 부품에 대한 많은 정보가 있습니다.

InfoQ : 리액터 패턴에 대한 귀하의 의견은 무엇입니까?   Vert.x 에 어떻게 들어 맞는다고 생각합니까?

Tim : Vert.x는 "다중 반응기"라고 불리는 리액터 패턴의 변형을 사용합니다. 따라서 하나의 이벤트 루프를 갖는 대신 다중 이벤트 루프를 갖지만 동일한 핸들러가 항상 동일한 이벤트 루프에 의해 호출되도록 보장합니다. 즉, 코드를 단일 스레드로 작성 (동기화, 휘발성 등) 할 필요는 없지만 쉽게 확장 할 수 있습니다.

따라서 리액터 모델의 이점을 누릴 수 있지만 순수한 리액터 구현 (Node.js 와 달리)은 여러 서버 인스턴스를 배포하지 않고도 서버 코어를 통해 쉽게 확장 할 수 있습니다.

InfoQ : 런타임 메트릭스가 현대 개발에 얼마나 중요하다고 생각하십니까? Vert.x 3은 메트릭 수집을 쉽게 지원합니까?

Tim : 런타임 메트릭은 매우 중요하므로 Vert.x에서 무엇이 진행되고 있는지 알 수 있습니다. Vert.x 3은 Vertix 용 메트릭을 수집하기 위해 제공자를 플러그인 할 수있는 메트릭 SPI를 제공합니다. 우리는 DropWizard 메트릭을 사용하는 상자 메트릭 구현과 Hawkular를 사용하는 작업에서 또 다른 메트릭 구현을 제공합니다.

InfoQ : 성능 : TechEmpower 벤치 마크를 보았을 때 Vert.x를 사용하기 시작했고 Vert.x가 매우 독창적이었습니다. 일부 테스트에서는 가장 빠른 속도 였지만 가장 빠른 속도는 아니지만 3 위 안에 포함되었습니다. 최근에 나는 벤치 마크에서 경쟁하는 것을 보지 못했으며 Vertx 3에 초점을두고 있다고 가정합니다. Vertx 3 성능은 어떻습니까?

Tim : 이전 버전의 Vert.x에 대해 테스트했기 때문에 더 최근의 결과를 철회 했으므로 최신 버전을 실제로 나타내지 못했으며 벤치 마크를 최신 상태로 유지할 시간이나 리소스가 없었습니다. 

Vert.x 3은 아직 성능이 조정되지 않았지만이를 완료하고 3.0을 완성하면 벤치 마크를 최신 상태로 유지하고 결과를 게시하는 데 시간을 할애 할 수 있습니다.

InfoQ : Vertx는 다국어인가요? 어떤 언어의 개발자가 가장 성가시며 Vertx 커뮤니티가 구성하는 각 언어의 몇 퍼센트입니까? Vert.x 커뮤니티의 규모는 어느 정도입니까?

Tim : 제 견해로 모든 언어 커뮤니티에는 성가신 개발자와 매우 유익하고 지식이 많은 개발자가 있습니다.

InfoQ  Vert.x 커뮤니티의 규모는 어느 정도입니까? 

측정하기는 꽤 어렵지만 우리는 매우 적극적인 구글 그룹을 가지고 있으며 우리는 GitHub에서 가장 유명한 자바 프로젝트 중 하나입니다. 우리는 생산에서 우리를 사용하는 회사가 많습니다. 

InfoQ : Vert.x 개발을 쉽게하기 위해 Vert.x 3에서 수행 된 작업은 무엇입니까?

Tim : Vert.x 2에서 우리가 발견 한 사실 중 하나는 바로 Vert.x 전용 방식으로 일부 작업을 수행했기 때문에 일부 개발자들, 특히 "전통적인"Java 배경에서 나오는 개발자들에게는 상당히 까다로워 보일 수 있습니다. Maven 기반의 프로젝트와 패키징에 사용되는 것들. 예를 들어 다른 곳에서는 찾을 수없는 자체 설명자를 가진 모듈 시스템이있었습니다. 또한 Vert.x 2에는 다소 복잡한 클래스 로더 모델이있어서 IDE에서 쉽게 실행하기가 다소 까다 롭습니다.

Vert.x 3에서 우리는 그 grain 에 대한 압박을 그만두고 대부분의 Java 개발자가 기대하는 방식으로 작업을하기로 결정했습니다. 따라서 모듈 시스템을 제거하고 클래스 로더 모델을 단순화했습니다 (기본적으로 평면 클래스 로더 모델). 이제 Vert.x 구성 요소는 Maven 또는 Bintray의 다른 종속성처럼 처리 할 수있는 표준 병으로 패키지됩니다. 플랫 클래스 로더 모델은 IDE에서 실행하고 디버그하는 것을 더 쉽게 만들어주었습니다. 이 모든 것들이 Vert.x 3에 훨씬 쉽고 간단한 개발자 경험을 제공하는 데 기여했습니다.

InfoQ : Vert.x는 MongoDB, MySQL, PostgreSQL에 어떤 지원을합니까? 데이터베이스에서 비동기가 중요한 이유는 무엇입니까?

Tim : Vert.x 3은 단지 라이브러리이므로 다른 데이터베이스 라이브러리를 포함하여 다른 Java 라이브러리와 함께 사용할 수 있습니다. 그러나 대부분의 Java 데이터베이스 클라이언트는 블로킹하는 경향이 있으므로 Vert.x 이벤트 루프를 블럭하지 않도록주의해야합니다.

Vert.x 3은 기본적으로 JDBC 인터페이스를 랩핑하고 스레드 풀을 사용하여 호출하고 사용자에게 비동기 인터페이스를 제공하는 비동기 JDBC 클라이언트를 제공하므로 사용자가 직접 래핑하는 것에 대해 걱정할 필요가 없습니다. 분명히 클라이언트는 여전히 JDBC에 대한 내부 호출을 블럭하고 있지만 JDBC가 본질적으로 동기적이고 호출이 일반적으로 네트워크 I / O에서 블럭되기 때문에 우리가 할 수있는 일은별로 없습니다. 이상적인 세계에서 오라클은 공식 비동기 JDBC API를 가져올 것이고 드라이버 공급 업체는 논블럭 버전의 드라이버를 작성할 것입니다.하지만 전통적인 RDBM 벤더는 느린 속도로 보입니다.

NoSQL 공급 업체는 논블럭이 중요하다는 사실을 이해하는 데 훨씬 빠르다. 예를 들어 MongoDB는 Vert.x 3에서 사용하는 Mongo 3.0에서 완전히 비동기식 클라이언트를 가져 왔습니다. 또한 멋진 Mongo Rx 클라이언트가 있습니다.

따라서 데이터 액세스를 블럭하지 않는 옵션이 점점 늘어나고 있습니다. DB 벤더가 수요가 있다는 것을 깨닫고 시간이 지남에 따라 그 수가 증가 할 것으로 기대합니다.

논블럭 데이터베이스 액세스가 중요한 이유는 무엇입니까? 다시 말하지만, 많은 동시성으로 애플리케이션을 확장하는 것에 관한 것입니다.

애플리케이션이 JDBC API를 사용하여 원격 데이터베이스에 대해 데이터베이스 쿼리를 실행해야한다고 가정 해 보겠습니다. 명심하십시오. 이것은 하나의 데이터베이스가 아니며 다른 서버에있는 100 개의 데이터베이스가 될 수 있습니다. 결과를 반환하기 위해 각 쿼리가 평균 1 초가 걸린다고 가정 해 보겠습니다. 그리고 최대 200 (합리적인 숫자처럼 보임) 크기로 이러한 요청을 실행하는 스레드 풀이 있다고 가정 해 보겠습니다.

수학을 사용하면 초당 200 건이 넘는 요청을 처리 할 수 ​​없다는 것을 쉽게 알 수 있습니다. 이것이 시스템의 병목 현상입니다. 원격 서버는 더 많은 부하에 쉽게 대처할 수 있지만 최대 200 개의 스레드가 있기 때문에 결코 빠르게 진행될 수 없습니다. 당연히 DB 서버가 이미 클라이언트에서 비동기를 사용하면 처리량을 향상시키지 않을 것입니다. 그러나이 경우에는 전체 처리량을 제한하는 블로킹 모델의 여유 용량이 있습니다.

InfoQ : Java 8이 Vertx 3에 얼마나 중요합니까? 익명의 내부 클래스를 사용하는 것보다 람다 표현으로 Vertx가 더 매력적이라고 ​​생각하십니까?

Tim : Java 8은 Vert.x 3에서 매우 중요합니다. 아마도 우리에게 가장 중요한 두 가지 기능은 lambdas와 Nashorn입니다. Lambda는 이벤트 스타일 API에 대한 프로그래밍을 훨씬 더 멋지게 만들고 JavaScript 구현에서 Nashorn JavaScript 엔진을 사용합니다.