経験的に、サイト上の画像を操作する方法は、品質のリトマス試験であることがわかりました。 人が5つのサイズの画像をどのように操作するかを見て、プロジェクト全体について結論を出すことができます。 その理由は理解できます。画像を保存、更新、操作するためのロジックを説明した本や記事を見たことはありません。誰かがコメントで指摘した場合、感謝します。 それぞれが独自のサービスバイクを思い付き、特定のディレクトリ構造またはデータベースに従って保存する方法を知っていました。 時間が経つにつれて、サポートサイトが開発され、どこかで画像サイズが変更され、どこかで以前にアップロードされた画像の新しいサイズを必要とする新しい機能が追加されました。 各ステップで、既にデバッグされた手順の新しいラウンドが追加されました。すべてのイメージ（オリジナル）を調べ、サイズを変更し、必要なパラメーターを保存します。 長くて高価。
遅かれ早かれ手動制御は失敗につながり、テスト環境でテストするには余分なお金が必要になります。 私は他の人と同様の問題を探し始めました。問題がある場合、あなたはその問題に最初に遭遇するのではないことが長い間知られていたからです。 すぐに、画像の変更、キャッシュ、配置のクラウドサービスに行きました。 ソリューションのシンプルさ、元の画像へのリンクとその中の制御パラメーターを使用して、クロップ、圧縮、反転、シフト、透明、印刷されたテキストと効果のある画像、その他さまざまなものを手に入れることができてうれしく思いました。 これらのサービスの1つは、私にとって最もシンプルで便利なように思えたので、試してみることにしました。 これを行うために、必要な機能のリストを作成し、時間特性を削除することにしました。サイトの速度がユーザーと検索エンジンの観点から非常に重要なパラメーターであることは秘密ではないからです。
メモリからのサンプルリスト：
- 幅の変化、高さの比例変化。
- 高さの変化、幅の比例的な変化。
- 指定された境界で画像を切り抜きます。
- 画像を長方形の境界に合わせます。
- ETagおよびMaxAgeに応じて定期的に更新しながら、サービスの側で結果をキャッシュおよび保存します。
- ロシアから新しいユーザーが変更した画像を受け取る時間。
- HTTPの可用性。
- サービスの合理的な価格と支払いの透明性。
機能要件を調べたところ、それぞれに使用例が反映されており、完全に満足していました。使用に関する簡単な指示と、統計を監視してバランスを低下させる小さなコントロールパネルがありました。
同時に、速度を調べましたが、率直に言って、ロシアが処理サーバーとストレージサーバーの場所の地図に表示されなかったため、速度に良い結果を期待していませんでした。 しかし、ヨーロッパとアメリカへの速度が近隣の都市よりもはるかに優れていることに気付く前に、私はそれをチェックすることにしました。 結果は許容範囲であり、画像幅を3000から500に変更した場合、画像あたり約35〜60ミリ秒で、結果は30〜150 KBでした。
さらにキャッシュはMaxAgeとLast-modifiedに基づいており、ETagは存在せず、ソースストレージサーバーからブロードキャストしませんでしたが、Last-modifiedがある場合に必要になる状況は考えられませんでした。 適切に構成されたMaxAgeは、静かにサービスに流れました。 サービスがサーバーストレージ上の元のイメージの変更をどのように処理するのか疑問に思っていました。 私の頭には3つのアルゴリズムがありました。最初のアルゴリズムでは、画像を返す前に、ソースリポジトリに移動して最終変更を確認する必要がありました。2番目のアルゴリズムでは、サービスに保存されている情報とバックグラウンドのリポジトリに関する情報を比較する必要がありましたたとえば、次の更新がMaxAgeによって割り当てられたときに、MaxAgeと3番目を介して受信されたが、クライアントが要求を行った場合にのみ発生しました。 オリジナルを変更し、サービスからイメージを要求するという簡単な実験でインストールすることにしました。 その後、イメージが変更されていないことを発見したため、サービスは特定のポイントまでストアにアクセスしません。 さらに、イメージを再度変更すると、元のイメージはストレージではなくサービスキャッシュから取得されます。 さらに、MaxAgeを変更して、サービスキャッシュ内の元のイメージを更新することに成功しました。
私のリストでは、価格は最下位にありましたが、優先順位はありませんでした。 元の画像へのアクセス数のプランもうまく機能しなかったのに対し、SLAを使用したプランの価格（今日の価格を引用）が500ドルであることに不満を感じました。 同時に、元の画像へのアクセスがどのように考慮されるかは明確ではありませんでした。 アクセスが、ブラウザキャッシュを使用せずに、サービスキャッシュからの以前に変更されたイメージに対する繰り返し要求であるかどうか、つまり 新しいユーザーが、誰かが既にそれを呼び出して変更する前。 この質問は、プロジェクトの1つで毎日150以上の新しいオリジナル画像があり、毎日少なくとも5,000人が閲覧していたために生じました。 キャッシュからのリクエストは、リクエストの約50％しか占めていません。 答えは簡単でした。イメージサービスをキャッシュにロードした後、それに対するすべての操作は無制限であり、制限は消費されたトラフィックに対してのみです。 画像の数を見積もると、トラフィックなしで月に約150ドルがリリースされました。
すべてがうまくいくでしょうが、2014年が来て、ドルは合理的で、親切で、永遠の境界を自信を持って克服し始めました。 戦利品は悪を打ち負かし始め、その場で画像を変更するサービスを作成する決定が下されました。 そこで、内部プロジェクトが登場し、最近（約1年前）、チームと私は公開テスト用のベータ版を公開しました。 このサービスは、Microsoft .NETテクノロジーと、元の画像をキャッシュするためのNoSQL Redisを使用して構築されています。 合計で約15のサイトで、さまざまな国が私たちと協力しています。 ベトナムの人気ベトナム音楽のサイトであるクライアントの1人ですが、私たちが知る限り、彼が私たちのサービスをどのように見つけたのかはまだ謎です。 1日あたり50〜30,000人の各サイトの出席者。 私たちのターゲットオーディエンスは比較的少ない（1日あたり最大50,000-100,000人。元の画像のサイズはそれぞれ最大10MB、システム内で制限）情報サイト、オンラインストア、製品カタログ、およびレスポンシブデザインとトラフィックを減らしたい、またはギャップを埋めたいサイトのみ古いIEでの画像圧縮。
建築
プロジェクトの最初のバージョンは、簡単な処理であり、許可がなく、サービスのユーザーに対する完全な行動の自由でした。 サービスが悪意のあるユーザーの負担になるか、法律に直接違反するまで、ユーザーの利便性を除くすべての点で、これは悪い考えであるとすぐに言います。 これは図に最もよく示されており、主要なコンポーネントを識別します。
すべてのクエリ統計、すべてのキャッシュパラメーター、Redisに保存しました。 ディスクへの参加を最小限に抑えながら、ユーザーへのコンテンツ配信の最大速度を達成したいため、オリジナルと処理済みのファイルがそこに保存されました。 プロトタイプを立ち上げたところ、非常に実行可能であり、関心のあるサイト（1日あたり5,000〜10,000ユーザー）の要件をカバーしていることがわかりました。 独自のハードウェアに配置され、使用を開始しました。 問題は、私たちがスケールしたいときに始まりました。 一定の解決策を得たからではなく、他のクライアントが私たちに興味を示し始め、増加する負荷に対処できないのではないかと恐れ始めたからです。
そこで、サービスの2番目のバージョンが誕生しました。 このキューのイベントをリッスンするRedisおよびマイクロサービスの上にあるキュー上に構築されたバージョン。 ファサードはIISのままでしたが、かなりの重量を失い、必要なサービスのリクエストをプロキシするようになりました。 ファイルの数とサイズの両方に制限があり、ドメイン名にバインドして、悪意のあるユーザーを回避し、関心がある場合は関連する構造に所有者を示します。 DNSは、ラウンドロビンと、意図したクライアントアドレス（CDN）に関連するアドレスを発行する機能とともに登場しました。
このスキームにより、処理サービスを分散し、フォールトトレランスとパフォーマンスの観点からそれらを複製し、システム全体を停止することなく独立してエンドポイントをサービスに送信することができました。 さらに、サービスは地理的にリンクされなくなりました。
サービスの2番目のバージョンの開発を続けています。 私たちは本当にユーザーからフィードバックを得たいと思っています。 新しい機能を備えた、可能な開発のリストがあります。
- 画像上にテキストを描画-すでに実装されています
- ドメイン、ルール、および/または操作のコンテキストで品質を設定する（これは厳しいOptimalCompression値です）
- システム選択の追加-元のイメージキャッシングプラン
- サイト以外のソースを追加する（たとえば、Amazonやコールドストレージ付きの新しいメール）
- 中央地域外への追加サービスの配置
必要です-必要ではありません、重要です-したがって、登録時に、500 MBのストレージ、最大5つのドメイン、2000の元のイメージを含むアーリーアダプタープランが発行されます。 アカウントを削除しない場合にのみ、彼はあなたと一緒に残ります（これはいつでもコントロールパネルから独立して行うことができます）。 すべてのオファーは、サポートの連絡先またはここのコメントに送信できます。 アーリーアダプターのプランは柔軟であり、大規模なシステムが必要な場合は、サポートにご連絡ください。 あなたが助けられる可能性は高いです。 また、パーツの1つが内部にどのように配置されているかに関心がある場合は、記述します。 私はすべての質問に答えようとしますが、どこかでコード例を示します。
よろしくお願いします！
連絡先 私は、アプローチのシンプルさに関する私の考えを共有するために、トピックや広告のルールに違反することなく、客観的に記事にアプローチしようとしました。 ご清聴ありがとうございました。 連絡先は、関心がある場合、個人的なメッセージまたはコメントで報告されます。