APIアプリケーションへのアクセスをすばやく簡単に加速する方法は？

答えは簡単です。キャッシングや水平スケーリングなどの実績のあるツールを使用します。これらが唯一のツールではないことをすぐに言わなければなりませんが、ほとんどの場合、現代の条件でも最も効果的であることが判明したのは、実証済みの古典的なアプローチです。実際の例を見てみましょう。

元の問題について

PREMIERビデオプラットフォームは、最新のリソースにふさわしく、機械学習に基づいてクライアント向けの推奨サービスを作成しました。多くのユーザーがビデオプラットフォームを利用しています（1日約100万人、PREMIERは非常に人気があります）。通話は、ウェブフォーム、モバイルデバイス用のアプリケーション、スマートTVの両方から行われます。



当社のサービスの機械学習が機能するための基礎となる初期データは、柱状のClickHouseDBMSに保存されます。スケジュールに従って、データはバックグラウンドで処理されてモデルが構築されます（最終的な推奨事項を発行するために使用されます）。計算結果はPostgreSQLリレーショナルDBMSに保存されます。



アプリケーションサーバーとクライアント間の短時間での高速な相互作用の問題に対する解決策は常に重要です。必要な作業速度（および応答時間が50ミリ秒以下である必要があります）を確保するには、リレーショナルデータベースの構造を最適化し、キャッシングと水平スケーリングを実装する必要がありました。ここで、いくつかのテクニックについて説明します。

キャッシングについて

キャッシングは一般的な最適化手法です。メインストレージよりも高速な追加の中間ストレージを作成し、最も人気のあるデータをそこに配置します。キャッシュされたデータへのアクセスが劇的に加速され、アプリケーションの速度が大幅に向上します。高負荷のアプリケーションを開発する場合、ハードウェアリソースを拡張せずにアプリケーションのパフォーマンスを最適化するための最も一般的なオプションはキャッシングです。キャッシングは、同じ入力に対して同じ出力を再生成するために、リソース使用量の点でいくらかの節約を引き起こす可能性があります。



キャッシュ容量には制限があり、ストレージが高速であるほど高価になるため、効率的に使用する必要があります。もちろん、メインストレージが十分に高速であれば、理論的にはキャッシュなしで実行できます。しかし、それは経済的に不採算になります。大幅なハードウェアのアップグレードを実行する必要があります。多くの場合、RAMの増加や、HDDからSSDへのディスクの交換になります。それら。インフラストラクチャ要件が大幅に増加し、作成されるアプリケーション全体の経済的パラメータに影響を与えます。実績のあるキャッシングがなければ、ほとんどの場合、大量の製品を作成することはほとんど不可能です。



ただし、キャッシングレイヤーを追加しても、すべての問題が自動的に解決されるわけではありません。また、タスクの特性に応じて、状況やサービスの発展に応じて変化する可能性のある、その充填のルールを検討する必要があります。また、これは万能薬ではなく、アプリケーションの特定の部分でのパフォーマンスの問題の症状を緩和する唯一の救済策であることに注意してください。アプリケーションに深刻なアーキテクチャ上の問題、平凡な実行環境がある場合、キャッシングによって問題が増える可能性が高くなります。



キャッシュされたリソースを保存する場所には、いくつかのオプションがあります。ローカル-ブラウザのクライアントインスタンス、サードパーティのCDNサービス、アプリケーション側。アプリ内キャッシングについて説明します。アプリケーションプロセスメモリは、おそらく最も一般的なデータキャッシングオプションです。ただし、このソリューションには欠点があります。メモリは、特定のタスクを実行するプロセスに関連付けられています。アプリケーションをスケールアウトする場合は、プロセス間でメモリが割り当てられないため、これはさらに重要です。非同期処理を担当するプロセスなど、他のプロセスでは使用できません。はい、キャッシングは機能しますが、実際にはそのメリットを十分に享受できていません。

レコメンダーキャッシング

プロジェクトに戻ると、一元化されたキャッシングソリューションの必要性を理解しています。共有キャッシュの場合、たとえば、Memcachedを使用できます。アプリケーションが同じインスタンスに接続されている場合、それを多くのプロセスで使用できます。 Memcachedは、シンプルで便利なソリューションですが、無効化、データの入力、およびキャッシュされたデータストアへのより複雑なクエリの正確な管理に関してはかなり制限されています。実際、Redisストレージはキャッシュタスクの標準になり、Memcachedの欠点はありません。



Redisは、キー値の高速ストアです。データの操作効率が向上します。構造を定義することが可能になります。障害とプリエンプションをきめ細かく制御できるため、6つの異なるポリシーから選択できます。 Redisは、レイジープリエンプションとイーガープリエンプションの両方、およびタイムプリエンプションをサポートしています。 Redisデータ構造を使用すると、事業体に応じて具体的な最適化を提供できます。たとえば、オブジェクトをシリアル化された文字列として保存する代わりに、開発者はハッシュデータ構造を使用して、フィールドと値をキーごとに保存および操作できます。ハッシュを使用すると、文字列全体をフェッチして逆シリアル化し、更新のたびにキャッシュ内の新しい値に置き換える必要がなくなります。つまり、リソースの消費が少なくなり、パフォーマンスが向上します。その他のデータ構造、Redisが提案する「シート」、「セット」、「ソートされたセット」、「ハイパーログ」、「ビットマップ」、「ジオインデックス」）を使用して、さらに複雑なシナリオを実装できます。時系列データを分析するためのソートされたセットにより、データの処理と転送の複雑さと量が軽減されます。 HyperLogLogデータ構造を使用して、少量の永続的なメモリ、具体的にはHyperLogLogごとに12KB（およびキー自体に数バイト）のみを使用して、セット内の一意のアイテムをカウントできます。 Redisで使用可能な約200のコマ​​ンドの大部分は、データ処理操作と、Luaスクリプトを使用したデータベース自体へのロジックの埋め込みに専念しています。組み込みのコマンドとスクリプト機能により、ネットワーク経由でアプリケーションにデータを送信することなく、Redisで直接データを処理する柔軟性が提供され、追加のキャッシングロジックを実装するオーバーヘッドが削減されます。再起動直後にキャッシュデータを利用できるようにすると、キャッシュのウォームアップ時間が大幅に短縮され、メインデータストアからキャッシュコンテンツを再計算する負担が軽減されます。次の記事では、Redis構成の機能とクラスタリングの見通しについて説明します。次の記事では、Redis構成の機能とクラスタリングの見通しについて説明します。次の記事では、Redis構成の機能とクラスタリングの見通しについて説明します。



キャッシングツールを選択した後の主な問題は、キャッシュに保存されているデータとアプリケーションに保存されているデータの同期であるように見えました。アプリケーションのビジネスロジックに応じて、データを同期するさまざまな方法があります。私たちの場合、データを無効にするためのアルゴリズムを作成するのが困難でした。キャッシュに配置されたデータは、現在の状況で使用する必要がある限り、または少なくともその可能性がある限り、限られた時間だけそこに保存されます。状況が進展するにつれて、彼らは、変化した状況において、より必要とされる他のデータのための余地を作らなければなりません。この場合の主なタスクは、データがキャッシュから削除される基準の選択です。ほとんどの場合、これはデータの関連性の時期ですが、他のパラメーターについて覚えておく価値があります。ボリューム、ランキング（同等、許容範囲、ライフタイム）、カテゴリ（メインまたは補助データ）など。



データを最新の状態に保つための基本的で一般的な方法は、時間の廃止です。この方法は、推奨アプリケーションデータが定期的に一元的に更新されるため、当社でも使用されています。ただし、すべてが一見したほど単純ではありません。この場合、本当に人気のあるデータのみがキャッシュに入るように、ランキングを監視することが非常に重要です。これは、クエリ統計の収集と「データ予熱」の実装のおかげで可能になります。アプリケーションの開始時にデータをキャッシュにプリロードします。キャッシュサイズ管理もキャッシングの重要な側面です。私たちのアプリケーションでは、約数百万の推奨事項が生成されるため、このすべてのデータをキャッシュに保存することは非現実的です。キャッシュサイズの管理は、キャッシュからデータを削除して新しいデータ用のスペースを確保することによって行われます。いくつかの標準的な方法があります：TTL、FIFO、LIFO、最後にアクセスされました。これまでのところ、TTLを使用しています。 Redisインスタンスは、割り当てられたメモリとディスクリソースを超えることはありません。



キャッシュが異なることを思い出してください。ほとんどの場合、ライトスルーと遅延の2つのカテゴリがあります。最初のケースでは、書き込みはキャッシュとメインストレージの両方に対して同期的に実行されます。2つ目は、最初はキャッシュ内でのみ書き込みが行われ、変更されたデータが別のキャッシュブロックに置き換わるまで、メインストレージへの書き込みが延期されます。ライトバックキャッシュは、キャッシュから削除されたときにメインストアに後で書き込むためにキャッシュ内のデータを監視する必要があるため、実装がより困難です。最初のオプションは、キャッシュのウォームアップ手順と組み合わせて使用​​します。「ウォーミングアップ」自体が重要で難しいタスクであることに注意してください。私たちのソリューションについては、次の記事で説明します。

レコメンデーションアプリでスケールアウト

推奨アプリケーションへのプレミアアクセスを提供するために、HTTPプロトコルを使用します。これは、多くの場合、アプリケーションの対話における主要なオプションです。特にKubernetesとIngressControllerがインフラストラクチャ環境として使用されている場合は、アプリケーション間の相互作用を整理するのに適しています。 Kubernetesを使用すると、スケーリングが簡単になります。このツールは、クラスター内のポッド間で要求のバランスを自動的に取り、操作を均等にすることができるため、開発者は簡単にスケールアップできます。 Ingress Controllerモジュールがこれを担当し、Kubernetesのアプリケーションへの外部接続のルールを定義します。デフォルトでは、Kubernetesのアプリケーションは外部ネットワークからアクセスできません。アプリケーションへの外部アクセスを提供するには、自動バランシングをサポートするIngressリソースを宣言する必要があります。SSL / TLS、URI書き換えルール、VirtualServerおよびVirtualServerRouteをサポートするNginx Ingress Controllerを使用して、URIとホストヘッダーに応じてさまざまなアプリケーションに要求をルーティングしています。



Ingress Controllerの基本構成では、Nginxの基本機能のみを使用できます。これはホストとパスに基づくルーティングであり、URI書き換えルール、追加の応答ヘッダー、接続タイムアウトなどの追加機能は使用できません。Ingressリソースに適用される注釈を使用すると、Nginx自体の機能（通常はアプリケーション自体の構成を通じて使用可能）を使用し、IngressリソースごとにNginxの動作を変更できます。



Nginx Ingress Controllerは、現在検討しているプロジェクトだけでなく、後で説明する他の多くのアプリケーションでも使用する予定です。これについては、次の記事で説明します。

キャッシングを使用することのリスクと結果

データ集約型アプリケーションの最適化に取り組んでいるチームは、キャッシングを最適化する方法について多くの質問をするでしょう。同時に、キャッシングの問題は「一度限り」解決することはできません。時間の経過とともに、さまざまな問題が発生します。たとえば、ユーザーベースが拡大するにつれて、カテゴリ別のデータの人気に関する統計が矛盾する可能性があり、この問題に対処する必要があります。



キャッシングはアプリケーションを高速化するための強力なツールですが、それだけが解決策ではありません。状況によっては、アプリケーションロジックを最適化し、スタックとインフラストラクチャ環境を変更する必要がある場合があります。機能しない要件を検証するときも注意する必要があります。製品の所有者と話し合った後、アプリケーションの要件が誇張される可能性があります。各ソリューションには独自の特性があることを覚えておく必要があります。



プロジェクトにキャッシュ方法を適用する前に、古いデータを提供するリスク、ソリューション全体の複雑さを増すリスク、潜在的なバグが発生する可能性に対処する必要があります。結局のところ、この場合、キャッシングは問題の解決を複雑にするだけでなく、パフォーマンスとスケーラビリティの問題を隠すだけです。データベースクエリは遅いのでしょうか。 -キャッシュにより高速ストレージになります！ API呼び出しは遅いですか？ -結果をクライアントにキャッシュします！これは、ビジネスロジックの複雑さが増すにつれて、キャッシングを管理するコードの複雑さが大幅に増すためです。



アプリケーションの最初のバージョンでは、キャッシュは実装直後に実際に具体的な効果があります。結局のところ、ビジネスロジックも単純です。値を保存して元に戻します。事業体間の依存関係は取るに足らないか存在しないため、無効化は簡単です。ただし、時間の経過とともにパフォーマンスを向上させるには、ますます多くのビジネスエンティティをキャッシュする必要があります。



キャッシングは、パフォーマンスの問題に対する特効薬ではありません。多くの場合、コードとコアストレージを最適化することで、長期的にはうまくいくでしょう。さらに、キャッシングの導入は問題への反応であるべきであり、時期尚早の最適化ではありません。



結論として、アプリケーションのパフォーマンスを最適化し、スケーラブルにすることは、指定された非機能要件内で予測可能な動作を実現することを目的とした継続的なプロセスです。パフォーマンスとスケーラビリティの向上に費やされるハードウェアコストと開発時間を削減するには、キャッシングが必要です。



リンク：

• redis.io/topics/client-side-caching
• docs.nginx.com/nginx-ingress-controller