[MSA]Monolithic vs. MSA: 성능과 확장성 평가(10.1109/ACCESS.2022.3152803)

목차

 

https://ieeexplore.ieee.org/abstract/document/9717259

Monolithic vs. Microservice Architecture: A Performance and Scalability Evaluation

저번에 이어서 MSA에 관한 논문이다. 지난번이 최신 논문이자 현업자들을 인터뷰한 논문이었다면

 

이번 논문은 2022년 논문이자 인용 횟수가 많은(26회), 성능과 확장성에 대한 실제 벤치마크 통계 논문이다.

 

좀 더 포장하자면 지난 번 논문이 정성적인 분석이었다면, 이번 논문은 정량적인 분석에 가깝다고 볼 수 있다.

 

15페이지 정도 되는 분량으로 적당한 길이를 자랑하지만, 전에도 그랬듯 논점과 결론만 정리하려고 한다.

 

생각보다 번역투를 벗어나는 것이 쉽지 않아서.. 어쨌건 시작.

 

Abstract

 

2012년 이래로 가용성, 확장성, 개발 속도(Agility)를 바탕으로 MSA는 인기를 얻어가고 있다.

 

하지만 소규모 기업이 MSA로 리팩터링 한다고 해서 대기업만큼 성과를 얻을 거라는 기대는 환상에 가깝다.

 

실제로 동시 이용자 규모가 수천명 단위가 되지 않으면서 수직적으로 확장할 여력이 있는 시스템의 경우

 

MSA로의 마이그레이션이 가져다 주는 이득이 충분히 연구되지 않았으며, 증거 역시 일관성이 없는 상태다.

 

이 논문의 목적은 레퍼런스 웹 앱에서 모놀리식/MSA의 성능과 확장성을 비교하는 것이며,

 

해당 앱은 4가지 버전(모놀리식/MSA ↔ Java/C# .NET)으로 구현되었다.

 

또한 세 가지 다른 배포 환경(로컬, Azure Spring Cloud, Azure App Service) 및 제어 하에서 실험을 수행했다.

 

그 결과는 아래와 같다.

 

1. 단일 기계에서의 성능은 모놀리식 아키텍처가 MSA에 비해 성능이 좋다.
2. Java 플랫폼이 .NET에 비해 연산이 많이 수행되는, 고성능 기계를 더 잘 활용한다.
3. Azure cloud에서는 수직확장이 수평 확장에 비해 비용 대비 효율적이다(!).
4. 인스턴스가 특정 개수를 넘어가도록 확장하면 앱 성능을 저하시킨다.
5. 구현 기술(Java/C# .NET)은 확장성과 성능에 뚜렷한 영향을 끼치지 않는다.

 

Method

 

실험에 쓰일 앱은 다음의 두 가지 엔드포인트를 가지고 있다.

 

• City Service
  간단한 단일 객체에 대한 쿼리. 입력은 도시 이름이 문자열로 주어지며, 응답은 해당 도시에 대한 데이터를 포함한다.
• Route Service
  연산 집약적인 쿼리. 10000개의 무작위 지점 사이의 최단경로를 포함하며, 매번 최단경로는 'Traveling salesman problem'의 휴리스틱 알고리즘으로 계산된다.

이를 그림으로 나타내면 아래와 같다.

 

또한 실험에 사용된 기술은 각각 아래와 같다.

 

• Java - 스프링 부트 2.3.0을 사용한 Java 8
• .NET - ASP.NET 코어 프레임워크 3.1을 사용한 C# 8

 

Result

 

LOCAL ENVIRONMENT

 

위 그림은 로컬 환경에서 처리량을 나타낸다. 왼쪽이 City, 오른쪽이 Route 서비스이며 MS는 Microservices를 가리킨다.

 

마이크로서비스 앱에서는 요청이 게이트웨이에서 백엔드 서비스로 전달되는 과정에서 오버헤드가 생긴다.

 

연산 집약적인 Route 서비스의 경우에는 이 오버헤드의 영향이 미미하기 때문에 모놀리식 앱의 처리량이 아주 조금 높다.

 

하지만 단순한 쿼리를 날리는 City 서비스의 경우 이 오버헤드가 크게 영향을 끼쳐

 

모놀리식 앱이 .NET의 경우 2배가 넘는 처리량을, Java의 경우 1.37배의 처리량을 보일 수 있었다.

 

.NET과 Java를 비교해 보면, City 서비스의 경우에는 .NET이 Java보다 통신 요청을 효율적으로 처리하며

 

Route 서비스의 경우 Java로 구현한 쪽이 모놀리식과 MSA 모두에서 더 나은 처리량을 보여준다.

 

이 차이에는 .NET의 JSON 직렬화에 대한 성능 최적화, Java의 CPU 사용률 등이 영향을 미쳤으며

 

램 사용량은 두 경우 모두 비슷했다.

 

AZURE SPRING CLOUD(Azure Spring Apps) ENVIRONMENT

 

스프링은 자바의 프레임워크이기 때문에 여기선 자바 버전만 테스트했다.

 

대신 CPU/RAM 를 4가지 다른 방식으로 할당해 실험을 진행했으며, City 서비스에 대한 결과를 보면 아래와 같다.

 

위 그림은 다르게 할당된 리소스에 따른 처리량을 나타낸다.

 

참고로 여기서 파레토 효율(Pareto Efficient)이란 해당 시스템이

 

• 다른 시스템에 비해 비교우위에 있는 지표가 있으나
• 모든 면에서 우수한 경우는 아닐 수 있는 경우이면서
• 시스템 지표 개선을 위해선 다른 지표를 희생해야 하는 상태

를 말한다.

 

계속 가자면 위 그림에서 확인할 수 있듯이 가장 높은 처리량은 2 CPU + 2 GB RAM으로 이루어진

 

두 대의 마이크로서비스에서 얻을 수 있었다.

 

또한 수직/수평적 확장에 따른 성능 향상에 특정한 한도가 있다는 것을 확인할 수 있는데,

 

비용을 비교하면 스프링 클라우드 환경에선 저성능(1 CPU + 1 GB RAM)머신의 수평확장이

 

파레토 지배로 이어진다는 결론을 얻을 수 있다.

 

• 파레토 지배(Pareto Dominated)는 위와 반대로 불필요한 비용 지출이나 성능 저하가 발생하는 경우를 가리킨다.

Route 서비스의 경우는 결과가 다른데, 6개의 1 CPU + 1GB RAM으로 이루어진 마이크로서비스가

 

가장 좋은 효율을 보였다. 이는 연산 집약적인 앱의 경우 수평적 확장의 효과가 명백하게 나타난다는 결론을 나타내는데,

 

그림을 보면 처리량이 인스턴스의 수와 비례해서(선형적으로) 증가하고 있다.

 

추가로 같은 리소스를 가진 모놀리식/MSA의 처리량에는 큰 차이가 없는 것도 확인할 수 있다.

 

또한 그림 8을 보면 세 가지 MSA가 파레토 지배로 판정되었으며 가장 빠른 구성은 6개의 1 CPU + 1GB RAM MSx6이지만

 

2 CPU + 2 GB RAM MSx2 구성과 4 CPU + 6 GB RAM의 모놀리식 버전은 꽤 낮은 가격으로 비슷한 성능을 제공했다.

 

AZURE APP SERVICE ENVIRONMENT

 

 

그림 9는 City 서비스에서 수평적 확장의 영향을, 그림 10은 수직적 확장의 영향을 분석하기 위한 결과를 보여준다.

 

오른쪽으로 갈수록 마이크로서비스 인스턴스 개수와 컴퓨팅 파워가 오름차순으로 증가한다.

 

최적의 구성은 .NET으로 작성된 6 × S4:7이다. Java의 최적 구성은 6 × S4:7이며, 전체에서는 5위에 랭크되었다.

 

이는 위에서 진행한 LOCAL ENVIRONMENT 테스트와 일관된 결과이며, Java는

 

낮은 전력 구성에서 가장 나쁘게, P4:14와 같이 수직적으로 확장된 환경에서는 .NET과 유사하거나 더 나은 성능을 발휘했다.

 

이는 Java 앱이 상당한 리소스 오버헤드와 더 많은 컴퓨팅 파워가 필요하다는 것을 나타낸다.

 

계속해서 그림 11을 인스턴스 증가에 따른, 12는 수직적 확장에 따른 처리량 중앙값의 변화를 퍼센트로 나타낸다.

 

그림 11은 City 서비스의 경우 1에서 3, 3에서 6으로 증가하는 것이 가장 효과적이며, 더 많은 인스턴스 수는

 

오히려 성능을 저하시킨다는 것을 보여준다.이는 로드밸런싱과 통신 오버헤드 때문이다.

 

그림 12의 경우 수직적 확장이 수평적 확장에 비해 명백하게 유의미하다는 것을 보여주는데,

 

예를 들어 Java 모놀리식 앱의 경우 업스케일링시 24%의 처리량이, 수평적 확장 시 9%의 처리량이 증가한다.

 

하지만 요구사항을 충족하지 못하는 B/S1:175 환경에서의 처리량이나, CPU 아키텍처가 변경되는 P4:14로의 업스케일링은

 

오히려 부정적인 영향을 미치기 때문에 주의해야 한다.

 

그림 13은 여태까지 등장한 앱 구성의 비용 대비 성능을 나타낸 그래프이다.

 

계속해서 Route 서비스에 대해 보자. 그림14는 수평적 확장에 따른 중앙값의 변화를, 15는 수직적 확장에 대한 변화를 나타낸다.

 

역시 Java가 모든 부분에서 나은 성능을 발휘하며, 수평/수직적 확장의 효과가 뚜렷하게 나타난다.

 

가장 뛰어난 성능은 10 x P4:14 Java 구성에서 등록되었으며, 이와 같은 결과는 로컬 구성에서 얻은 결과와 일관성이 있다.

 

연산 집약적인 서비스, 그리고 가상 머신의 전력이 증가함에 따라 Java는 큰 폭의 성능 증가를 보인다.

 

City 서비스에서와 마찬가지로, 그림 16과 17은 수평/수직적 확장에 따른 처리량 증가를 보여준다.

 

City 서비스와 일관되게 인스턴스 수가 1에서 3으로, 그리고 3에서 6으로 증가할 때 가장 큰 처리량 증가가 측정되었다.

 

하지만 증가 규모에서 큰 차이를 보이는데, 다섯 가지 케이스의 경우 성능이 이전 대비 100% 이상 증가했다.

 

가장 큰 증가폭은 148%이며, City 서비스에서의 9%와 비교하면 상당한 차이이다.

 

또한 인스턴스 수가 15개로 증가하는 경우엔 성능 향상이 미미하며, 20개로 증가하는 경우 오히려 처리량이 감소했다.

 

수직적 확장의 경우도 뚜렷하게 큰 효과가 있었는데, Java 플랫폼의 경우 1 x S2:3.5로 변경하면 200%의 성능 향상이 있었다.

 

또한 City 서비스의 경우 수직적 확장시 처리량이 감소하는 것이 11개 케이스에서 측정되었으나

 

Route 서비스의 경우 거의 모든 경우에서 성능 향상을 가져오는 것으로 확인되었다.

 

마지막으로 Route 서비스에서 비용 대비 성능을 나타낸 그래프이다.

 

도입부에 적었던 이 논문의 결론에 대해 다시 언급하고 글을 마쳐야겠다.

 

1. 단일 기계에서의 성능은 모놀리식 아키텍처가 MSA에 비해 성능이 좋다.
2. Java 플랫폼이 .NET에 비해 연산이 많이 수행되는, 고성능 기계를 더 잘 활용한다.
3. Azure cloud에서는 수직확장이 수평 확장에 비해 비용 대비 효율적이다(!).
4. 인스턴스가 특정 개수를 넘어가도록 확장하면 앱 성능을 저하시킨다.
5. 구현 기술(Java/C# .NET)은 확장성과 성능에 뚜렷한 영향을 끼치지 않는다.