Sprykerのパフォーマンスとスケーラビリティの概念

記事Spryker Performance and Scalability Conceptsの翻訳に注目してください。



Sprykerは、eコマースのフレームワークであり、100を超える個別のeコマースプロジェクトの結果です。 すぐに使用できる2つの最も重要なアーキテクチャー品質-高いパフォーマンスとスケーラビリティーを提供します。 この記事では、それらを達成するための基本概念について説明します。

なぜパフォーマンスとスケーラビリティがそれほど重要なのですか？

誰もが、サーバーのパフォーマンスの低下が本当の変換キラーであることを知っています。 疑いもなく、高速なWebサイトは楽しく使用できますが、サーバーの応答時間を短縮するために戦う他の理由があります。



高負荷で低速のアプリケーションを操作することの難しさを覚えているかもしれません。 Sprykerでは、オンラインストアがテレビ広告、大量メール送信、SEMキャンペーンなどのマーケティングキャンペーンの「ボトルネック」にならないようにしたいと考えています。



優れたアプリケーションパフォーマンスは、ITチームの生産性にプラスの効果をもたらします。 開発者は、データベース複製や高価なサーバー構成のための複雑なメカニズムの実装に、ビジネスにとって価値のない時間を費やす必要がありません。 明らかな理由から、フルページキャッシュも避けたいと思います 。



高速アプリケーションのもう1つの利点は、テストと実稼働の両方で、クラウド内の小さな（安価な）サーバーでストアを実行できることです。 一般に、ハードウェアの最適化と調整に時間を費やす必要がない場合、サーバーハードウェアの複雑さを大幅に簡素化できます。

建築上の目標

通常の負荷では、典型的なSprykerストアの平均応答時間は約50ミリ秒です。 カートへのアイテムの追加など、このような費用のかかるリクエストでも、150ミリ秒未満で完了する必要があります。 これらの数値で何もわからない場合は、 Dmitry Sorokaが公開した（非公式の） Magentoパフォーマンステストと比較できます。 DmitryはMagentoの元リードアーキテクトであるため、彼の姿は現実とそれほど変わらないと考えられます。 彼は、古いがまだ有名なMagento 1と新しいMagento 2を比較しました。

Magento 1製品ページでは、サーバーレスポンスは90％のケースで250ミリ秒以下でした。 Magento 2の場合、250ミリ秒を満たすことができたリクエストは25％未満でした。 次のグラフに示すように、ほとんどのリクエストは600ミリ秒以上実行されました。

これらの結果と比較すると、SprykerはMagento 1の5倍、Magento 2の5〜12倍の速さです。最初の結果として、Sprykerストアホームページの応答時間のグラフを示します（その動作は製品ページに似ています）。 テストは、1分間に3000リクエストの負荷で単一のHerokuサーバーで実行されました。フルページキャッシュはありません。





3k RPM / Heroku 1パフォーマンスLダイノ/ PHP7



スケーラブルなシステムは、低負荷および高負荷、最大機器負荷の両方での応答時間の短縮に加えて、応答時間が遅くなります。 不良なシステムは、単に応答を停止します;これは、SQLデータベースがキューにクエリを蓄積し始めるか、I / Oレイテンシーが長くなりすぎるときによく起こります。



また、消費されるメモリ量を削減しようとします。これにより、高価なサーバーメモリを購入することなく、多数の並列リクエストを実行できます。

そして最後に、ボトルネックやコールドキャッシュなしで、簡単に水平方向にスケーリングできるようにしたいと考えています。



特定のプロジェクトの実際のパフォーマンスは、特定のホスティング設定、サイト構造、製品数、他のサービスとの相互作用、そしてもちろん、開発されたソリューションのパフォーマンスなど、多くの要因に依存します。 負荷の高いプロジェクトの場合、実際のユーザートラフィックをシミュレートする専用の負荷テストを常にお勧めします。 Sprykerは高速のPHPフレームワークを提供するため、お客様はサーバーを最適化または構成するために多大な努力をする必要はありません。

最適化されたソフトウェア設計

上記の目標を達成するために、ストアアプリケーションをYvesとZedの2つの部分に分けることにしました。 Yves-クライアントのフロントエンド。 これは、 Silex SensioLabsマイクロフレームワークに基づいた小さなPHPアプリケーションです。 Zedは、すべてのビジネスロジックを含む「重い」サーバーアプリケーションです。



Yvesは、不要なアーキテクチャレイヤーと簡単な読み込みプロセスを必要としない簡素化された設計により、その速度のほとんどを実現します。 Yvesのもう1つの重要な概念は、データにアクセスする方法です。 多くの関係と条件を持つリレーショナルデータベースに対する高価なSQLクエリの代わりに、Yvesは非常に高速なキー値データストア（デフォルトはRedis）からデータを読み取ります。 Yvesの全文検索とファセット検索の速度は、強力なElasticsearchによるものです。 多くの場合、スケーラビリティのボトルネックとなるリレーショナルデータベースは、Yvesから直接アクセスできません。 代わりに、Zedはすべてのデータ変更を収集し、それらをRedisおよびElasticsearchに準備します。

パフォーマンスイブ

Yvesのパフォーマンスを評価するには、そのアクションのシーケンスを検討します。 典型的なYvesリクエストは次のとおりです。



（1）URL解析

（2）Redisおよび/またはElasticsearchからすべてのデータを取得する

（3）このデータをプリコンパイル済みTwigテンプレートに追加する



明らかに、単純化されたアーキテクチャのために、PHPコードに対するアクションはそれほど多くありません。 パフォーマンスに関しては、YvesがRedisやElasticsearchからデータを受信する2番目のステップで最も重要な部分が始まります。 製品、CMSページ、および翻訳に関するすべてのデータはRedisに保存されます。 一方、各製品に関する正規化されたPostgreSQLまたはMySQLリレーショナルデータベース情報は、在庫、価格、税などの複数のテーブルに分散されます。 これらはすべて水素化されて単一のデータセットになり、Redisに保存されます。 コストのかかる複数のクエリの代わりに、Yvesは単純にRedis :: get（）を実行して、必要なすべてのデータを一度に取得します。



各ページには複数のデータセットが必要です。 Redisは、大量のデータと多数の接続がある場合でも非常に高速です。 Spiskerと同じサーバーにRedisをインストールする場合、単一のRedis :: get（）リクエストには0.1ミリ秒しかかかりません。 顧客の90％を占めるクラウドサービスでSprykerを実行すると、ネットワーク遅延が発生します。 ローカルRedisをRAMですばやく検索する代わりに、遅いネットワークでは実行時間が大幅に増加します。 このため、Yvesはデータを多数のRedis :: get（）ではなく、単一のRedis :: mget（）リクエストに自動的にマージします。 これにより、クラウドサービスの概念的な制限を平準化し、Redisから最大のパフォーマンスを得ることができます。



Redisとは異なり、Elasticsearchはカタログにのみ使用されます。 1つのリクエストのみを実行しますが、このリクエストはRedis :: get（）よりもはるかに遅くなります。 クエリの遅延を防ぐために、クイック検索用にデータが準備されるインデックス作成を最適化しました。 これについては、別の記事で詳しく説明します。



最後に、スケーラビリティについて少し説明したいと思います。 クラウドサービスのスケーラビリティのためにSprykerを準備するために、12の要因の方法論を厳守します。 その最も重要な部分は、「アプリケーションプロセスは内部状態を保存せず（ステートレス）、共有データを持たない（share-nothing）」ということです。 Yvesのすべての部分は、アプリケーションの他の部分とは独立してスケーリングできます。 Yvesのインスタンスを追加したり、RedisまたはElasticsearchのリソースを追加したりできます。 これはすべてダウンタイムなしで可能であり、アプリケーションをデプロイする必要さえありません。 この質問については、今後の記事で詳しく説明します。



Sprykerプロジェクトに慣れていただければ幸いです。 VirtualBoxのベース仮想マシンですべての設定が準備されているため、コンピューターで簡単に実行できます 。 重要：この画像ではOpcacheは無効になっています。