많이 사용되는 응용 프로그램 Mendix; 동시 사용자 100만 명

도전이 시작되었습니다!

여기에서 Mendix, 우리는 플랫폼을 한계까지 밀어붙이는 것을 좋아합니다. 우리는 더 크고, 더 좋고, 더 대담하게 만들어서 결국 깨질 때까지 계속합니다. 깨는 것은 결국 테스트의 가장 좋은 방법입니다. 이 오래된 오락을 추구하면서 우리는 스스로에게 "동시 사용자를 얼마나 지원할 수 있을까? 천 명? 만 명? 십만 명은 어떨까?"라고 물었습니다. 이에 우리는 "알아보자!"라고 답했습니다.

우리가 뭘 안다고?

전 세계적으로 고객이 당사에서 애플리케이션을 실행하고 있습니다. Mendix 플랫폼. 일부는 소수의 사용자를 위해 실행되는 소규모 앱이고, 일부는 방대한 수의 사용자를 위해 작동하는 진정한 엔터프라이즈급 애플리케이션입니다.

예를 들어, PostNL은 주문 관리 시스템을 통해 하루에 백만 건 이상의 주문을 처리하고, 두바이 시청은 매달 150만 건 이상의 페이지 뷰를 받습니다. 그래서 우리는 Mendix 애플리케이션은 무거운 작업 부하를 처리할 수 있습니다. 문제는 얼마나 무겁게 만들 수 있는가입니다.

우리의 테스트는 어떤 모습일까요?

이 경우 단일 테스트는 사용자가 여러 거래를 완료하는 것입니다. 우리는 10만 명의 사용자가 동시에 거래를 완료하도록 할 것입니다.

먼저 트랜잭션을 정의해 보겠습니다. 완료된 트랜잭션이란 무엇일까요? 우리는 완료된 데이터베이스 커밋 액션을 찾고 있습니다. 데이터베이스에 새 데이터를 추가하는 것입니다. 완전히 새로운 레코드일 수도 있고, 기존 레코드를 변경하는 것일 수도 있습니다. 중요한 것은 데이터베이스의 데이터가 액션에 의해 영구적으로 변경된다는 것입니다.

Mendix 애플리케이션을 구축할 때 다양한 가능성을 제공하는 거대한 플랫폼입니다. 이를 통해 이 과제를 어떻게 해결할지 선택할 때 선택의 폭이 넓어졌습니다. 실제 비즈니스 상황에 맞게 유지하기 위해 비교적 간단한 작업인 경비 청구를 선택했습니다.

기본 원리는 사용자가 시스템에 로그인하여 일련의 간단한 경비 청구를 보내는 것입니다. 이 시점에서는 파일 업로드를 제외하기로 했기 때문에 데이터 양이 제한 요소가 되지 않았습니다. 우리는 기본 삽입 및 업데이트 트랜잭션을 사용하여 평가하고 싶었습니다.

우리가 어떻게 설정했는지 Mendix 성능 한계 테스트

앱 구현

테스트 애플리케이션의 경우, 기본 템플릿으로 시작하여 매우 간단한 양식과 기능을 추가하여 경비 애플리케이션을 만들었습니다. 프런트엔드는 최소한으로 유지되었고 이미지, CSS 또는 스크립트를 최적화하려는 노력은 없었습니다. 우리의 관심은 주로 테스트를 가능하게 하는 백그라운드 로직을 만드는 데 집중되었습니다.

테스트 도구

이러한 테스트를 실행하기 위해 우리는 이미 사업의 다른 곳에서 사용하던 도구인 Gatling을 활용했습니다. 이 도구는 스크립트를 사용하여 플랫폼 로드 테스트를 위해 설계되었습니다. 이미 몇 가지 스크립트를 만들었고 이를 변경하는 데 필요한 경험이 있었기 때문에 합리적인 옵션처럼 보였습니다. 이를 통해 우리가 목표로 삼았던 목표에 도달하는 데 필요한 규모로 위에 나열된 작업을 수행하는 테스트 스크립트를 만들 수 있었습니다.

인프라 시작점

크게 하거나 집에 가는 게 맞지? 우리가 가장 먼저 고려한 것은 지원팀이 프로비저닝할 수 있는 가장 큰 사용자 지정 노드를 요청하는 것이었습니다. 그러나 이 테스트를 작동시키는 데 필요한 로깅 수준을 구현하고 제어 수준을 가질 수 없었습니다. 우리의 Mendix 클라우드는 로깅과 메트릭을 대신 처리하도록 설계되었으며 관리 및 배포가 쉽습니다. 맞춤형 추적을 추가하고 구성을 조정할 수 있도록 의도된 것이 아니므로 경계를 넓히고 문제를 해결하기 위해 수동 제어가 더 많은 환경이 필요했습니다!

그래서 우리는 AWS EC2에서 첫 번째 개인 인스턴스를 설정하고 Grafana와 InfluxDB를 사용하여 시스템 성능을 추적하기 위해 일부 사용자 지정 분석 및 메트릭 수집을 추가했습니다. 또한 async-profiler와 YourKit을 설치하여 런타임을 더 자세히 직접 관찰했습니다. 간단하게 유지하고 쉽게 변경할 수 있도록 단일 노드를 사용하여 애플리케이션과 데이터베이스를 모두 호스팅했습니다.

성능 한계 테스트 실행

첫 번째 실행 결과

이 서버 설정에서 첫 번째 테스트를 실행했을 때, 우리는 존경할 만한 5000명의 동시 사용자를 달성했습니다. 좋은 시작이었지만, 우리가 원하는 수준은 아니었습니다. 그런 다음 우리는 가능한 한 많은 성능을 짜내기 위해 서버 설정을 반복하기 시작했습니다.

반복과 개선

첫 번째 변경 사항은 AWS EC 2 인스턴스의 크기를 두 배로 늘리고 Java 설정과 데이터베이스 풀을 약간 변경하는 것이었습니다. 이를 통해 동시 사용자 7000명과 초당 비용 180건을 달성할 수 있었습니다.

다음으로, 우리는 데이터베이스를 메인 인스턴스에서 분리하여 완전히 별도의 노드에 두었습니다. 또한 우리는 내부 spec-ops 팀과 협력하여 설정 크기를 늘렸습니다. 이를 통해 거래 수를 다시 늘렸습니다. 이제 우리는 초당 15,000건의 비용 처리량으로 373명의 동시 사용자를 달성했습니다.

이러한 테스트 과정에서 우리는 또한 Gatling의 테스트 스크립트에서 불일치를 발견했습니다. 이 때문에 MxClient에서 제출한 정보와 더 유사하도록 페이로드를 변경했고, 예상 값에 더 잘 맞도록 제출된 값을 변경했습니다.

우리가 이룬 다음 큰 도약은 인스턴스를 확장하는 문제였습니다. 우리는 하나의 데이터베이스 서버 앞에 세 개의 애플리케이션 서버를 사용하여 수평적으로 확장된 랜드스케이프로 전환했습니다. 이 설정으로 초당 30,000개가 넘는 트랜잭션으로 700명의 동시 사용자에게 도달할 수 있었지만 Gatling이 부하를 증가시키는 것을 막는 일반적인 네트워킹 병목 현상도 발견했습니다.

네트워크 병목 현상을 해결하고 Gatling이 더 많은 부하를 제공할 수 있도록, 우리는 더 많은 수의 작은 Gatling 인스턴스를 사용하기로 전환했습니다. 우리는 애플리케이션 노드 중 하나를 재활용하여 아래 설정을 만들었습니다.

이러한 변경 사항으로 우리는 25,000명의 동시 사용자를 성공적으로 안정적으로 활성화할 수 있었습니다! 예상하셨겠지만, 애플리케이션 서버가 XNUMX개였던 총 수는 약간 감소했지만, 이는 우리가 목표를 달성하기 위해 확장할 수 있는 설정이었습니다.

마지막 푸시를 위해 우리는 정확히 그렇게 했습니다. 우리는 처리 능력의 4배 증가를 편안하게 지원할 수 있도록 설정을 확장하여 4개의 대형 앱 노드와 두 배 더 큰 DB 서버가 있는 클러스터에 도달했습니다. 많은 것처럼 보이지만, 우리가 달성하고자 하는 동시 사용자 수를 처리할 것으로 기대하는 회사라면 이 규모의 인프라를 기대해야 할 것입니다.

100개의 앱 서버를 갖춘 후, 우리는 마법 같은 XNUMX만 명의 고객을 확보하는 데 성공했습니다!

테이크 아웃

우리가 증명한 것은 Mendix 플랫폼과 런타임, 그리고 따라서 Mendix 애플리케이션은 이 동시 사용자 볼륨을 처리할 수 있는 능력이 충분합니다. 서버 구성 및 배포와 관련하여 이 연습에서 얻은 통찰력은 클라우드 팀과 공유되었으며 앞으로 클라우드 인프라를 개선하고자 합니다. 이미 좋은 기본 수준의 성능을 개선하는 데 도움이 되기를 바랍니다. Mendix 노드는 할 수 있다.

다음 시간에는 이 놀라운 결과를 얻기 위해 우리가 만든 설정과 변경 사항에 대해 더 자세히 설명하는 가이드를 제공해 드리겠습니다.