使用頻度の高いアプリケーション Mendix; 同時接続ユーザー数 100 万

挑戦が始まります！

ここで、 Mendix私たちは、プラットフォームを限界まで押し上げるのが好きです。最終的に壊れるまで、物事をより大きく、より良く、より大胆に作り続けるのが好きです。結局のところ、破壊することがテストの最良の方法です。この昔ながらの趣味を追求する中で、私たちは自分自身に尋ねました。「何人の同時ユーザーをサポートできますか? 1,000 人? 1 万人? 10 万人はどうですか?」それに対して、私たちはこう答えました。「調べてみましょう!」

我々は何を知っていますか？

世界中のお客様がアプリケーションを Mendix プラットフォーム。少数のユーザー向けに実行される小規模なアプリもあれば、膨大な数のユーザー向けに実行される真のエンタープライズ レベルのアプリケーションもあります。

例えば、PostNLは注文管理システムで1日100万件以上の注文を処理しており、ドバイ市は毎月150万件以上のページビューを受けています。 Mendix アプリケーションは重いワークロードを処理できます。問題は、どれだけ重いワークロードを処理できるかということです。

私たちのテストはどのようなものですか?

この場合の 1 回のテストでは、ユーザーが複数のトランザクションを完了します。10 万人のユーザーが同時にトランザクションを完了することを目指します。

まず、トランザクションを定義しましょう。完了したトランザクションとは何でしょうか? 完了したデータベース コミット アクション、つまりデータベースに新しいデータを追加するアクションを探しています。これはまったく新しいレコードの場合もあれば、既存のレコードへの変更の場合もあります。重要なのは、データベース内のデータがアクションによって永続的に変更されることです。

Mendix は、アプリケーションを構築する際にさまざまな可能性を提供する巨大なプラットフォームです。このため、この課題に取り組む方法を選択する際に、さまざまなオプションが与えられました。実際のビジネス状況に合わせるために、比較的単純なタスクである経費請求を選択しました。

基本的な原理は、ユーザーがシステムにログインし、一連の簡単な経費請求を送信することです。この時点では、データの量が制限要因にならないように、ファイルのアップロードを省略することにしました。基本的な挿入および更新トランザクションを使用して評価したいと考えました。

私たちの Mendix パフォーマンス限界テスト

アプリの実装

テスト アプリケーションでは、基本的なテンプレートから始めて、いくつかの非常にシンプルなフォームと機能を追加し、経費アプリケーションを作成しました。フロントエンドは最小限に抑えられ、画像、CSS、スクリプトを最適化する努力は行われませんでした。私たちの注意は、主に、テストを可能にするために舞台裏のロジックを作成することに集中しました。

テストツール

これらのテストを実行するために、私たちは社内ですでに使用していたツール、Gatling を利用しました。このツールは、スクリプトを使用してテスト プラットフォームをロードするように設計されています。すでにいくつかのスクリプトが作成されており、それらを変更するために必要な経験があることを考えると、これは賢明な選択肢のように思えました。これにより、私たちが目指していた目標を達成するために必要な規模で、上記のタスクを実行するテスト スクリプトを作成することができました。

インフラの出発点

大きくするか、やめるしかないですよね？最初に検討したのは、サポートチームがプロビジョニングできる最大のカスタムノードを要求することでした。しかし、このテストを機能させるために必要なレベルのログ記録と制御を実装することはできませんでした。 Mendix クラウドは、ユーザーに代わってログ記録とメトリックを処理するように設計されており、管理と展開が簡単です。カスタム トラッキングを追加したり、構成をいじったりできるようには設計されていないため、限界を押し広げて物事を打破するために、より手動で制御できる環境が必要でした。

そこで、AWS EC2 に最初のプライベートインスタンスを設定し、システムのパフォーマンスを追跡するために Grafana と InfluxDB を使用してカスタム分析とメトリック収集を追加しました。また、ランタイムをより詳細に直接観察するために、async-profiler と YourKit もインストールしました。物事をシンプルに保ち、簡単に変更できるようにするために、アプリケーションとデータベースの両方をホストするために単一のノードを使用しました。

パフォーマンス限界テストの実行

初回実行結果

このサーバー設定で最初のテストを実行したとき、5000 という立派な同時ユーザー数を達成できました。これは良いスタートでしたが、私たちが望んでいたレベルではありませんでした。その後、サーバー設定を繰り返して、可能な限りパフォーマンスを引き出そうとしました。

反復と改善

最初の変更は、AWS EC 2 インスタンスのサイズを 7000 倍に増やし、Java 設定とデータベース プールにいくつかの変更を加えることでした。これにより、同時ユーザー数が 180 になり、XNUMX 秒あたりの処理数が XNUMX になりました。

次に、データベースをメイン インスタンスから分離し、完全に別のノードに配置しました。また、社内の特殊作戦チームと協力してセットアップのサイズを拡大しました。これにより、トランザクション数が再び増加しました。現在、15,000 秒あたり 373 エクスペンスのスループットで XNUMX 人の同時ユーザーを達成しています。

これらのテストの過程で、Gatling のテスト スクリプトに矛盾があることもわかりました。このため、MxClient によって送信された情報に近づくようにペイロードを変更し、予想される値により適合するように送信された値を変更しました。

次に私たちが達成した大きな飛躍は、インスタンスのスケール アウトでした。30,000 つのデータベース サーバーの前に 700 つのアプリケーション サーバーを配置して、水平にスケールされたランドスケープに切り替えました。この設定により、XNUMX 秒あたり XNUMX 件を超えるトランザクションで XNUMX 人の同時ユーザーに到達できるようになりましたが、Gatling の負荷増加を妨げる一般的なネットワーク ボトルネックがあることにも気付きました。

ネットワークのボトルネックを回避し、Gatling がより多くの負荷を提供できるようにするために、より小さな Gatling インスタンスを多数使用するように切り替えました。まず、アプリケーション ノードの 1 つを再利用して、以下のセットアップを作成しました。

これらの変更により、25,000 人の同時ユーザーを安定して有効にできるようになりました。予想どおり、アプリケーション サーバーが XNUMX 台あったため、合計数はわずかに減少しましたが、これは目標を達成するために拡張できる設定でした。

最後のプッシュでは、まさにそれを実行しました。処理能力の 4 倍の増加を快適にサポートできるようにセットアップを拡張し、4 つの大きなアプリ ノードと 2 倍の DB サーバーを備えたクラスターに到達しました。これはかなり大きなことのように思えますが、私たちが目指している同時ユーザー数の処理を期待している企業では、この規模のインフラストラクチャを期待する必要があります。

100 台のアプリケーション サーバーを導入すると、魔法の XNUMX 万の顧客数を達成できました。

テイクアウェイ

私たちが証明したのは、 Mendix プラットフォームとランタイム、そして Mendix アプリケーションは、この量の同時ユーザーを処理する能力が十分あります。サーバーの構成と展開に関するこの演習から得た洞察は、クラウドチームと共有されており、今後はクラウドインフラストラクチャの改善を検討する予定です。すでに良好な基本レベルのパフォーマンスを標準でさらに向上させることができれば幸いです。 Mendix ノードは可能です。

次回は、この驚異的な結果を達成するために作成したセットアップと行った変更について、より詳細なガイドを紹介します。