Miniservices : MSA에 대한 현실적 대안

 

마이크로 서비스가 현재 프로덕트를 만들때 가장 인기 있는 트렌드 중 하나라는데 이견이 없습니다. 하지만 모든 상황에서 마이크로 서비스가 적합한지에 대해서는 의문이 듭니다.

제가 블로그에 그동안 많이 언급했던 마이크로 서비스 아키텍처에 대해 마틴 파울러는 다음의 조건을 충족해야 한다고 언급합니다.

• 독립적으로 배포 가능하고 확장이 가능해야 함
• 단일 책임
• 느슨한 결합

하지만, 현실은 만만치 않습니다. Legacy가 있는 경우에는 더욱 그렇습니다.

오늘 소개하려고 하는 미니 서비스는 “마이크로 서비스 그룹이 작은 패턴으로 모인 것”과 같습니다.

위의 그림에 미니 서비스가 중간에 위치한 것을 알 수 있습니다. 흔히들 모놀리스는 레거시라고 하며, 마이크로 서비스는 복잡하고 어렵다라고 합니다.

미니서비스 아키텍처는 여러 책임과 공유 데이터 저장소가 있는 아키텍처입니다. 서비스와 구현 세부 정보가 완전히 분리된 마이크로서비스와 달리 미니서비스는 라이브러리와 데이터베이스를 공유할 수 있습니다.

미니서비스 아키텍처 특징

• 관련 서비스는 동일한 데이터베이스를 공유할 수 있습니다.
  • 서로 관련된 모듈이 데이터베이스를 공유할 수 있습니다. 예를 들어서 미니서비스는 이미지 처리, 이미지 렌더링 또는 애플리케이션에 대한 기타 관련 기능을 포함한 여러 기능을 수행할 수 있습니다.
• 서비스 간 통신은 REST API를 통해 이루어집니다.
• 관련 서비스는 배포에 사용되는 코드베이스 및 인프라를 공유할 수 있습니다.

미니서비스 사용 이점

미니서비스는 확장성, 내결함성 및 견고성을 포함한 마이크로서비스 아키텍처의 모든 이점을 상속합니다.

• 향상된 성능
  • 도메인 간의 서비스, 상호 연결 및 네트워크 트래픽의 수를 줄임으로써 애플리케이션 성능을 향상 시킵니다.
• 공유 유지 관리 오버헤드
  • 다양한 관련 기능을 처리하는 서비스를 통해 마이크로서비스와 관련된 유지 관리 오버헤드가 감소합니다.
• 개발자 친화적
  • 미니서비스는 종종 각 개별 서비스를 전담하는 소규모 개발팀을 구성할 여력이 없는 회사에 더 적합합니다.

미니서비스 한계

종단간 테스트는 단일 서비스와 관련된 종속 항목 수로 인해 미니서비스에서는 어려울 수 있습니다. 그렇기에 효율적인 오류 처리 관련하여 복잡성을 증가 시킬 수 있습니다.

마이크로서비스와 미니서비스

미니서비스는 데이터 저장 및 인프라 공유를 허용한다는 점에서 마이크로서비스와 다릅니다. 미니서비스는 마이크로서비스에 대한 보다 실용적인 접근 방식으로 꾸준히 추진력을 얻고 있습니다.

각 아키텍처별로 장점과 한계가 존재하기에 아키텍처를 선택전 철저하게 분석 및 조사를 하는 것이 중요합니다.

미니서비스란?

이런 상황에서 우리가 행복해지는 무엇일까요? 다음은 레거시가 존재하는 상황에서 미니서비스 아키텍처를 선택해야 하는 이유입니다.

1. 재사용성

미니서비스는 재사용 가능한 코드를 생성하기가 수월합니다. 미니서비스는 프로젝트가 제공해야 하는 모든 도메인간 기능에 쉽게 접근할 수 있도록 합니다. Shared 방식을 활용하기에 모든 서비스가 항상 최신 버전의 기능을 참조합니다. copy-past 코드가 없습니다.

2. 단순성

기존 모놀리스는 경량화하는데 초점을 두고 있기에 우리가 구축하는 애플리케이션의 아키텍처를 관리하는데 이보다 좋은 방법은 없습니다.

애플리케이션 아키텍처는 코드 표준을 생각하고, 구성하고, 적용하는 프로세스로 진행됩니다. 아래의 다이어그램은 다계층 코드 구조를 보여줍니다. domain1은 추가 기능을 위해 domain2의 컨트롤러를 호출합니다.

미니서비스를 올바르게 수행하려면, 합당한 경우에만 커플링을 식별해야 합니다.

3. 분리 그리고 빠른 속도

모든 서비스는 애플리케이션 수준에서 “결합”됩니다. 마이크로서비스처럼 도메인 사이를 이동시 네트워크 트래픽을 걱정할 필요가 없습니다. 아키텍처 구조에 스며들었던 대기열도 발생하지 않습니다.

4. DevOps

각 미니서비스를 독립적으로 배포하여 탄력적으로 만들 수 도 있지만, 그것이 필요한것인지 고민할 필요가 있습니다.

5. 쉬운 디버깅

단일 프로젝트 또는 도메인에 대한 모든 미니서비스를 로컬에서 쉽게 실행 할 수 있습니다. 로그는 쉽게 통합되고 캡쳐되기에 기본적인 디버깅을 수월하게 할 수 있습니다.

6. 네크워크 트래픽 감소

Network Hop이 적을 수록 대기 시간이 줄어들며, 성능이 향상됩니다. 미니서비스는 코드 기반으로 미니서비스간 통신을 허락하거나 혹은 네트워크를 통해 통신을 하도록 선택할 수 있습니다. 어느 방식을 선택하던 런타임을 줄일 수 있는 옵션이 존재합니다.

7. 빠른 개발

각 마이크로서비스별 별도의 데이터베이스를 두는 것이 효율적일지 고민해봐야할 문제입니다. 데이터베이스를 중앙 집중화해도 문제가 없다면, 이렇게 진행하는 것도 방법입니다.

이렇게 하게 될 경우에는 코딩 표준, 원칙, 좋은 코드 작성이 핵심입니다.

8. 공유 간접비

“미니”의 기본 목표와 원칙은 필요한 비즈니스 로직의 양을 최소화 하지만, 분리되는 형태의 아키텍처에 충실하다는 것입니다. 또한 코드를 쉽게 재사용할 수 있는 기능이 제공됩니다.

9. 필요한 경우 마이크로서비스화

미니서비스를 올바르게 수행하려면, 합당한 경우에만 커플링을 식별해야 합니다.

마이크로서비스와 미니서비스는 분리될 수 있습니다. 미니서비스로 구축하고 진행하다가 특정 서비스의 경우 마이크로서비스로 분리가 가능합니다. 이미 앞써서 코드 표준을 지켰기에., 미니서비스와 연동에 대한 부분만 네트워크 접근 방식으로 변경하면 됩니다.

결론

미니서비스는 대부분의 서비스가 매우 느슨하게 결합되는 경향이 있는 애플리케이션에 적합합니다. 마이크로서비스가 원하는 아키텍처라고 해도 미니서비스로 시작하는 것이 프로젝트를 위한 더 나은 출발점이 될 수 있습니다.

자, 우리팀은 어떤 선택을 할까요? 정리되면 공유하도록 하겠습니다.

References:

• https://www.bmc.com/blogs/microservices-vs-miniservices/#
• https://medium.com/@tommanion_47885/miniservices-are-how-to-move-fast-e29139d1f13c

Read More

자율 주행이 시장에 미치는 영향

최근 자율주행 기술력을 확보하고 있는 회사와 함께 자율주행에 관련된 버티컬 서비스를 기획하고 구축하는 일을 진행하고 있다.

자율 주행 기술은 단계별로 분류된다. SAE(미국 자동차 공학회)에서 자동화 레벨을 2016년에 정의했다.

자율 주행 기술 단계

• Level 0 (비자동화)
  • 인간이 제어와 주행 책임을 갖는다.
• Level 1 (운전자 보조)
  • 인간 + 시스템이 차를 제어하며, 주행 책임은 인간이 갖는다. (e.g 차간거리, 조항등 보조)
• Level 2 (부분 자동화)
  • 인간 + 시스템이 차를 제어하며, 주행 책임은 인간이 갖는다. (e.g 특정한 상황에서 시스템이 보조 운행)
• Level 3 (조건부 자율주행)
  • 시스템이 제어와 주행 책임을 갖는다. (e.g 특정 조건에서 자율 주행, 위험시 운전자 개입)
• Level 4 (고등 자율주행)
  • 시스템이 제어와 주행 책임을 갖는다. (e.g 운전자 개입 불필요)
• Level 5 (완전 자율주행)
  • 시스템이 제어와 주행 책임을 갖는다. (운전자 불필요)

우리나라의 경우 국토교통부가 세계 최초로 자율주행 레벨4에 대한 안전기준을 제정했다. (참고: https://bit.ly/3xy3e23) 그리고 실증 대상지를 선정하여 레벨4에 대한 시범 사업을 진행하고 있다.

상상을 해보자. “완전자율주행”이 상용화 된다면 세상은 어떻게 변할 것인가?

시장 규모

완전자율주행이 현실화된다면 영향을 미칠 시장 규모를 분석했다.

택시

생활에 가장 밀접한 택시 시장의 규모는 2020년 기준 약 8조원이고 카카오, UT, 타다, 마카롱, 티머니onda, 반반택시등과 같은 플랫폼 기업들이 기존 시장을 플랫폼화 시키고 있다.

현재 전국에 약 25만대의 택시가 있으며, “가맹택시”로 확보하기 위한 전쟁을 벌이고 있다.

전국택시운송사업조합연합회의 자료에 의하면,

• 택시 면허대수: 252,254대
• 택시 운전자수: 267,842명
• 일반택시:
  • 등록대수: 9,813대
  • 운전자수: 102,960명
• 개인택시:
  • 등록대수: 164,662대

2020년 기준 택시 운전자 분들의 월수입은 평균 150만원 ~ 200만원이고, 평균 200만원으로 단순 계산을 하면 매달 약 5400억원이 임금으로 지불된다.

이중, 65세 이상의 택시 운전자가 72,800명이다. 전체 택시 운전자의 약 27% 수준이다. 즉, 택시 운전자 4명중 1명은 고령 운전자이다.

배달

2020년 기준 음식 서비스 배달 시장의 규모는 약 17조 2828억원이다. 코로나로 인해 시장의 규모가 19년에 비해 78.6% 증가했고, 3년동안 약 536% 증가했다.

• 2017년 2조 7326억원
• 2018년 5조 2628억원
• 2019년 9조 7328억원
• 2020년 17조 3828억원

음식 배달 시장의 성장을 이끌고 있는 것은 배달앱이다. 배달의 민족, 요기요, 쿠팡이츠등 전국민의 절반 가량이 배달앱을 이용하고 있다. 어린이와 고령층을 제외하면 거의 모든 사람이 배달앱을 사용하고 있는 것이다.

고용노동부에 따르면 2019년 기준 배달대행원 숫자 추정치는 약 13만명이고 통계청에 따르면 19년 기준 평균 소득은 약 309만원이다.

19년 기준으로 평균 300만원으로 단순 계산을 하면 매달 약 3,900억원이 임금으로 지불된다.

택배

2019년 기준 국내 택배 시장 규모는 5조 6673억원이다.

2019년 기준 국내 택배 점유율

택배 운송을 자율주행으로 하게 될 경우 고려해야 할 부분은 집앞까지의 배송 및 여러개의 택배가 실린 짐칸에서 배송해야 할 택배를 정확하게 빼야 하는 상황이 존재한다. 그래서 완전자율주행이 되더라도 문앞까지 배송해야 하는 상황으로 인해 전체에 적용되기는 어려워 보인다.

택배 기사님이 직접 운전하지 않고, 아파트까지 자율주행으로 이동 후 그 이후 부터 관여할 가능성이 높다.

캠핑

국토교통부에 따른 2019년 기준 전국에 등록된 캠핑카는 24,869대이다. 2011년에 1300대였지만 8년만에 20배 가량 성장한 수치다.

캠핑카로 튜닝하는 자동차 튜닝 시장은 2019년 기준 3조 8000억원 규모이다.

뜬금없이 캠핑 시장 규모를 조사한다고 생각할 수 도 있다. 캠핑장이나 노지에서 타프와 텐트를 치고 캠핑을 즐기는 방식도 있지만 “차박”도 존재한다. “완전자율주행”이 가능해지면 차 내부의 변화가 “차박”에 많은 영향을 줄 수 있을 것으로 판단되고 더 나아가 캠핑 시장에 영향을 끼칠 수 있다고 생각한다.

자율주행이 일자리를 뺏을 것인가?

자율주행이 보급화되면 승객을 운송하는 차량보다 물류 운송에 더 큰 영향을 미칠 것으로 보는 사람들이 있지만, 물류 운송 운전자들은 단순히 운전하는 것 이상의 일을 하고 있다.

고도로 자동화된 트럭에도 적재, 하역, 유지보수와 같은 손길이 필요하기에 다른 이유로 일자리는 남아 있을 것이다.

승객을 운송하는 분야의 경우에는 커다란 실직 위험이 다칠 수 있다고 생각했다. (e.g 택시)

하지만, 골드만삭스경제연구그룹의 분석결과는 정반대의 결과가 나왔다. 승객을 운송하는 운전자보다 트럭 운전자의 일자리가 더 많이 사라질 것이라는 전망이다.

Stacy Liberatore, Self-Driving Vehicles Are Set to Take 25,000 Jobs a MONTH Away from Americans with Truck Drivers being Worst Hit, DailyMail, 2018. 5. 23.

위의 결과가 모든 국가에 정확히 매칭된다고 생각하지는 않는다. 아파트나 골목이 많은 우리나라의 경우에는 맞지 않을 수 있다고 생각한다.

결론

AI 및 디지털 기술이 발전함에 따라 시스템과 로봇에 의해 일자리가 줄어들 것이라 생각한다. 본 글에서 언급한 자율주행도 대표적으로 일자리를 뺏을 것 같은 기술중에 하나이다.

“어플라이드 인튜이션”의 창업자인 카사르 유니스와 피터 루드비히는

“새로운 기술에 대해 일자리가 대체될 수 있다는 것을 간과해서는 안되지만, 동시에 더 많은 기회가 자율주행이나 새로운 기술로 만들어 질 수 있다”고 얘기한다.

완전자율주행이 시장에 출시되어 기존 택시를 대체한다고 했을 때, 기존에 택시를 소유한 회사/개인에게 사업 라이센스를 부여할 수 있을 것이다. 그리고 자율주행차의 수익의 일부를 가져갈 수 있다고 한다면 새로운 기회가 만들어질 수 도 있지 않을까? 물론, 이와 같은 새로운 기회는 정책이 뒷받침되어야 할 것이다.

Read More

Serverless vs. Container 선택 가이드

이번 글에서는 서버리스와 컨테이너에 대해서 설명하고자 한다.

일을 하다보니, VM을 이용할 경우 유후 시간이 많을 때 비용이 최적화되지 못하다는 느낌이 많이 들었다.

서버리스는 서버 프로비저닝 및 유지 관리를 추상화하는 클라우드 아키텍처 모델이다.

FaaS(Function-as-a-Service)라 불리며, 필요에 따라 코드를 실행하는 개념이고 실행 후 종료된다.

일반적으로 FaaS와 Container를 많이 비교하곤 한다. FaaS와 Container는 몇 가지 공통점이 존재한다. 분산 시스템 및 대규모 애플리케이션 개발에 특화 되어 있고 관리상의 번거로움을 제거하고 애플리케이션과 비즈니스의 가치에 집중하고자 하는 목적이 있다.

Container

애플리케이션을 박스에 담아 어디서든 실행 할 수 있다면 좋지 않을까? 호스트 시스템이 무엇이든, 어디에 위치하든 상관없이…

이것이 컨테이너화의 아이디어이다. 필요한 모든 종속성이 사전에 설치되어 있는 컨테이너를 만들고 안에 애플리케이션을 넣고 컨테이너 런타임이 설치된 모든 곳에서 실행되게 한다.

이런 장점으로 인해 많은 기업이 컨테이너를 채택했고, 표준으로 정의되었다. 오늘날 대부분의 클라우드 제공사는 컨테이너화된 애플리케이션을 호스팅하는 방법을 제공하고 있다.

컨테이너의 장점

• 제어 및 유연성
• 공급 업체에 Lock-In 되지 않음
• 쉬운 마이그레이션
• 휴대성

컨테이너의 단점

• 관리 작업 (e.g. 패치 적용)
• 확장 속도가 느림
• 유지비용
• 처음 시작시 Learning Curve가 존재
• 수동 개입이 필요

Serverless (FaaS)

서버리스의 기본 전제는 애플리케이션(모든 비즈니스 로직)이 기능과 이벤트로 구현된다는 점이다.

클라우드 제공사가 어떤 일이 있어도 기능을 사용할 수 있도록 보장한다.

2014년도에 서버리스 컴퓨팅이 처음 도입되었을 때, 워크로드가 상당히 제한된 상태였고 이미지 혹은 데이터 처리와 같은 소규모 작업에만 사용되었었다. 하지만 AWS가 Lambda의 이벤트 소스로 API Gateway를 도입한 후 모든 것이 바뀌게 되었다. 서버리스 컴퓨팅으로 구동되는 전체 API를 만드는 것이 가능하게 되었다. 점점 더 많은 서비스가 Lambda 제품과 통합되어 복잡한 상황의 애플리케이션을 구축할 수 있게 되었다.

서버리스의 장점

• 관리 필요 없음
• 사용시에만 비용 지불
• 유휴 시간 비용 없음
• 자동 확장
• 시장 출시 시간 단축
• 마이크로 서비스 특성 → 명확한 코드 분리
• 관리 부담 대폭 감소

서버리스의 단점

• 블랙 박스 환경
• 공급 업체 종속
• 콜드 스타트
• 아주 복잡한 앱을 구축하기 어려울 수 있음

서버리스는 서버 또는 가상머신을 프로비저닝하고 관리할 필요가 없다.

AWS를 예를 들면, EC2서버를 프로비저닝 할 필요 없이 프로그래밍 언어로 작성된 코드를 실행할 수 있다. 내부적으로는 Lambda가 임시 마이크로 컨테이너를 생성하고 코드를 실행하고 결과를 반환하는 역할을 수행한다. 따라서 인프라를 관리할 필요가 없어지게 된다. 개발자는 코드를 배포하고 실행하기만 하면 된다.

흔히, 이런 코드들도 서버에서 실행되기 때문에 서버리스라는 용어가 잘못된 것이라고 주장하는 이들도 있지만, 개발자의 관점에서 서버 처리가 필요하지 않다는 점이 중요하다.

서버 기반 시스템은 주어진 기간 동안 사용한 리소스에 대해 요금을 청구한다. (e.g. EC2는 시간단위로 청구됨)

반면 서버리스는 실제 사용량을 청구한다. 사용하지 않을때는 비용이 청구되지 않는다.

AWS의 Lambda의 경우, 함수 코드 1백만건에 대해 0.2USD, 요청당 0.0000002USD만 청구하고 해당 기능이 동작하기 위해 필요한 메모리의 양에 따라 추가 요금이 부과된다.

이 가격 모델은 고정 비용을 가변 비용으로 전환하기에 스타트업 및 중소형 애플리케이션에 유리하다.

대규모 애플리케이션에서도 유리할 수 도 있다. 피크 타임때 기존 인프라에서는 프로비저닝을 미리 해야하기에 유휴 리소스에 대한 추가 비용이 생기기 때문이다.

예를 들어서, 미국내 뉴스 및 엔터테인먼트 서비스인 Bustle은 IT지출이 약 84% 감소했다. 유지 보수 직원이 자체 서버를 관리하는 비용 대비 저렴하기 때문이다.

서버리스 비용 계산은 여기를 참고하길 바란다.

“우리가 프로젝트를 진행할 때 어떤 기술을 선택해야 할까? 아마도 상황에 따라 다를 것이다.”

컨테이너를 선택해야 하는 경우

컨테이너를 사용하면 기본 운영 체제를 선택하고 설치된 프로그래밍 언어 및 런타임 버전을 완전히 제어할 수 있다. 따라서 특정 버전에 대한 요구사항이 있는 소프트웨어를 활용할 경우 유용하다.

대규모 컨테이너에서 서로 다른 소프트웨어 스택을 사용하여 컨테이너를 운영할 수 있다. 특히 오래된 레거시 시스템을 컨테이너 환경으로 마이그레이션을 해야 하는 경우 매우 유용하다.

하지만 이러한 유연성에는 운영 비용이 함께 제공된다. 컨테이너는 여전히 많은 유지 관리 및 설정이 필요하다.

최대한 이점을 취하려면 Monolithic 애플리케이션을 마이크로 서비스로 분리해야 하며, 이를 개별 컨테이너 그룹으로 이용해야 한다. 또한 정기적으로 업데이트를 통해 운영 체제를 최신 상태로 유지해야 하는 번거로운 작업을 수행해야 한다.

트래픽이 없는 경우, 완전한 종료가 불가능하다. 따라서 항상 런타임 비용이 지불해야 한다는 점을 고려해야 한다.

서버리스를 선택해야 하는 경우

서버리스는 트래픽을 자동으로 감지하고 즉시 처리해야 하는 경우 유용하다. 트래픽이 전혀 없으면 애플리케이션이 완전히 종료된다. 사용한 리소스에 대해서만 비용을 지불하게 된다.

서버리스로 개발하게되면 기본 인프라 관리에 대해 신경 쓸 필요가 없다. 최종 사용자에 대한 코드와 비즈니스 가치에만 집중하면 된다. 설정이나 프로비저닝 없이 코드를 더 빠르게 전달 할 수 있기에, 개발시간이 빨라질 수 있다.

그러나 현재 몇가지 제약이 존재한다. 프로그래밍 언어 및 런타임은 공급자가 지원하는 범위내에서 사용 가능하다.

또한, 인프라와 코드가 너무 분리되어 있으면 애플리케이션 스택의 모든 부분에 대해 추론하기가 어려워진다.

결론

유연성이 필요하거나 레거시 서비스를 마이그레이션 해야 하는 경우에는 컨테이너를 선택하고 개발 속도, 자동 확장 및 현저히 낮은 런타임 비용을 지불하고 싶으면 서버리스를 선택하는 것을 고려했으면 한다.

Read More

GraalVM 소개

 

“Graal”이라는 단어는 “Grail”을 의미하는 고대 프랑스어에서 유래되었다. GraalVM의 “VM”은 “JVM”내부에서 실행된다는 사실에서 비롯되었다.

GraalVM은 Java 코드를 작성하고 실행할 수 있는 도구이다. Oracle에서 만든 JVM(Java Virtual Machine) 및 JDK(Java Development Kit)이고 애플리케이션의 성능과 효율성을 개선하는 목적으로 나온 고성능 런타임이다.

GraalVM의 목표는 더 빠르고 유지하기 쉬운 컴파일러 작성, JVM에서 실행되는 언어의 성능 향상, 애플리케이션 시작 시간 단축, Java 에코 시스테에 다국어 지원 통합이다.

GraalVM은 JDK에 최적화 컴파일러를 추가하여 성능 최적화와 다중 언어 애플리케이션에 대한 상호 운용성을 제공한다. Java코드 지원 외에도 Scala, Kotlin, Groovy, Clojure, R, Python, Javascript, Ruby등을 추가로 지원한다. 기본적으로 GraalVM을 사용하면 개발자가 단일 애플리케이션에서 여러 언어 및 라이브러리를 효율적으로 실행할 수 있다.

GraalVM은 많은 것을 제공한다.

Graal?

Graal은 오라클 연구소에서 진행하는 프로젝트이다. 2012년부터 개발팀은 GraalVM에 대한 60개 이상의 논문을 발표했다. 이 프로젝트는 매우 오래 지속된 프로젝트이고 성공적으로 보고 있다.

위의 그림에서 Truffle은 GraalVM의 다국어를 전담한다. Javascript, Ruby, R 및 모든 LLVM 언어의 영역이다. LLVM 컴파일러는 C코드를 LLVM 비트 코드로 변환하여 GraalVM에서 실행되게 만든다.

GraalVM의 구성 요소

GraalVM을 구성하는 세 가지 구성 요소는 고성능 최적화 Just-In-TIme 컴파일러, 네이티브 실행 파일을 빌드하기 위한 Ahead-of-Time 컴파일러, 다국어 지원이다.

GraalVM 컴파일러 (Just-In-Time 컴파일러)

• Ahead-of-Time 컴파일러
• JVM기반 애플리케이션을 기본적으로 실행 가능한 바이너리로 컴파일하는데 사용

다국어 프로그래밍 언어 지원

• 프로그래밍 언어 인터프린터를 제공한다. 이를 통해 GraalVM을 확장하여 Java 에코 시스템에 언어를 추가할 수 있다. 또한 언어에 구애받지 않는 디버거, 프로파일러 및 힙 뷰어와 같은 도구를 지원한다.

JVM 대체제로써의 GraalVM

GraalVM은 Java, Scala, Kotlin 및 Java 바이트 코드에서 실행되는 모든 언어를 실행하는 JVM을 대체하려고 한다. 2019년 부터 GraalVM은 Linux상에서 프로덕션 준비가 완료되었다. 그리고 20.1.0 버전에서 Windows도 지원한다고 밝혔다.

여러 언어를 지원한다는 장점이 있지만, 아직까지 성능은 빠른 언어쪽도 있지만, 개별 컴파일러에 미치지는 못한다. 그럼에도 불구하고 GraalVM에 주목을 하는 이유는 무엇일까?

유지 보수

HotSpot컴파일러는 C/C++로 작성되어 있지만, Java로 JVM 컴파일러를 다시 작성하면 새로운 기회가 열린다. 수많은 자바 프로그래머가 GraalVM에 시간을 할애하고 개선에 기여할 것이기 때문이다. V8엔진과 HotSpot 컴파일러는 모두 수십년간 최적화의 어려움을 겪고있다. 개선을 하려면 큰 틀을 깨뜨려야 하는 문제점도 안고 있다. GraalVM은 새로운 아이디어를 바탕으로 이 문제에 대한 새로운 해석을 가지고 있다. 최적화 및 확장성을 염두해두고 만들어졌기 때문이다.

이런 부분들이 트위터가 GraalVM을 채택한 이유중에 하나일 것이다. 트위터는 Scala를 이용해 서비스를 만들고 있고, Scala는 JVM 바이트 코드로 컴파일되는 언어이다.

Truffle

Truffle는 컴파일러는 만드는 영리한 접근 방식이다. 최적화 Just-In-Time 컴파일러를 사용하면 모든 것을 컴파일하고 최적화한다는 아이디어이다. 인터프리터를 작성하면 인터프리터도 Just-In-Time 컴파일러에 의해 컴파일되고 최적화된다. 이 방식의 장점은 인터프리터이자 Compiler라고 불린다. Graal은 Ruby를 수동으로 최적화된 어셈블리 코드와 거의 비슷한 네이티브 코드로 컴파일한다.

Truffle을 사용하면 새로운 프로그래밍 언어를 작성할 수 있다. 각 언어마다 특징이 존재하는데 예를 들어서 동적 타이핑은 Groovy와 Ruby에 의해 유명해졌다. Scala와 Groovy의 출현으로 스트림과 함수형 프로그래밍이 현실화되었다. 향후 Kotlin이 이 아이디어를 채택한 후 마침내 Java8에 적용되었다.

Truffle로 프로그래밍 언어를 쉽게 구현할 수 있기 때문에 위와 같은 새로운 개념을 쉽게 사용할 수 있다. Truffle은 괜찮은 프로그래밍 언어를 사용하는데 걸리는 시간을 절반으로 줄여준다. 이는 결국 개발자가 프로그래밍 언어를 잘 선택하도록 도울 수 있다.

클라우드

GraalVM의 가장 큰 핵심은 AOT 컴파일러이다. 20년이 지난 후 Java가 어셈블리 코드로 컴파일 할 수 있게 되었다. 더 중요한 점은 네이티브 코드가 필요한 상황이 존재한다는 것이고 이는 AWS Lambda로 표현되었다.

Lambda의 흥미로운 점은 사용량에 따라 비용을 지불한다는 것이다. 코드가 실행되는 경우에만 비용을 지불한다는 의미다. 만약 이를 VM기반으로 구현한다고 가정하면 사용하지 않을 때 VM을 반복해서 종료해야 할 것이다. 그리고 요청이 왔을때 구동을 해야 할 것이다. 이 경우 대략 3초의 시간이 필요하다.

이런 문제를 AOT 컴파일러가 해결 할 수 있다. 일반적으로 Java는 수천 개의 클래스를 로드해야 하기 때문에 느리게 시작한다. 그러나 간단한 CRUD 애플리케이션은 로드된 클래스의 극히 일부만 사용한다. GET 요청에 응답하기 위해 Spring Boot의 모든 기능이 필요하진 않다.

AOT 컴파일러는 코드를 최적화하고 컴파일 후 네이티브 코드로 제공된다. Quarkus, Helidon과 같은 클라우드 네이티브 프레임워크를 이용하면 0.005초에 응답하는 Lambda 함수를 만들 수 있다.

GraalVM의 가격

GraalVM의 가격은 버전에 따라 달라진다. Community Edition은 오픈 소스이다. Enterprise는 Oracle GraalVM OTN 라이센스 계약 및 Oracle 마스터 라이센스 계약에 따라 사용할 수 있다. 엔터프라이즈 에디션의 가격은 라이센스에 따라 달라진다.

Oracle Master License Agreement에 따라 GraalVM Enterprise는 프로덕션 용도로 구입해야 한다.

결론

https://jaxenter.com/graalvm-chris-thalinger-interview-163074.html 에서는 트위터가 GraalVM을 사용하는 이유에 대해서 설명하고 있다.

GraalVM은 새로운 마이크로서비스 프레임워크를 촉진하는 것처럼 보인다. 예를 들어, Quarkus는 업계 표준 프레임워크의 모음이며 네이티브 바이너리를 생성할 수 있도록 확장해준다.

앞으로 GraalVM이 클라우드 네이티브 영역과 R, Python 및 Ruby와 같은 프로그래밍 언어에 상당한 영향을 미칠 것으로 기대한다.

Read More