Discordはボイス＆テキストチャットアプリケーションですが、毎日1億枚​​以上の画像が通過します。 もちろん、すべてのチャンネルで友人に写真をリダイレクトするだけで、タスクはシンプルになります。 しかし実際には、これらの画像の配信は非常に大きな技術的問題を引き起こします。 写真への直接リンクは、写真を持つホストにユーザーのIPアドレスを提供し、大きな画像は多くのトラフィックを消費します。 これらの問題を回避するには、ユーザーの画像を受信し、トラフィックを節約するために画像のサイズを変更する中間サービスが必要です。

画像プロキシに会う

これを行うために、Pythonサービスを作成し、創造的にImage Proxyという名前を付けました。 リモートURLから画像をダウンロードしてから、 pillow-simdパッケージを使用して、リソースを大量に消費するサイズ変更タスクを実行します 。 このパッケージは驚くほど高速で、可能な限りx86 SSE命令のサイズ変更を高速化します 。 画像プロキシは、最終画像をアップロード、サイズ変更、および最終的に表示するURLを含むHTTPリクエストを受信します。



さらに、サイズ変更された画像をメモリに保存するキャッシュレイヤーを設定し、可能であれば、メモリから直接発行しようとします。 HAProxyレイヤーは、URLハッシュに基づいてリクエストをNginxキャッシングレイヤーにリダイレクトします。 キャッシュはクエリのマージを実行して、画像のサイズ変更に必要な変換の数を最小限にします。 キャッシュとプロキシの組み合わせにより、サイズ変更サービスを数百万人のユーザーに拡張できました。







Discordが成長するにつれて、Image Proxyは過負荷の兆候を示し始めました。 最大の問題は、負荷が不均等に分散され、帯域幅が低下することでした。 リクエストは、最大数秒まで、まったく異なる時間に実行されました。 既存のImage Proxyでこの問題を解決することはできましたが、当時はGoの追加使用を試していましたが、ここではGoを使用するのに最適な場所のように思えました。

だからメディアプロキシがありました

すでに実行中のサービスを書き換えることは難しい決断になりました。 幸いなことに、Image Proxyは比較的単純であり、Image Proxyと新しい代替の結果を簡単に比較できました。 クエリ実行の高速化に加えて、新しいサービスには、.mp4および.webmビデオの最初のフレームを抽出する機能など、いくつかの新機能もあります。したがって、Media Proxyと呼びましょう。



Goで画像のサイズを変更するために既存のパッケージのパフォーマンスを測定することから始め、すぐにがっかりしました。 Goは一般的にPythonよりも高速な言語ですが、パッケージのどれもが確実にPillow-simdの速度を上回っていません。 Image Proxyの作業の主な部分は、画像のトランスコードとサイズ変更でした。したがって、Media Proxyのパフォーマンスのボトルネックになることは間違いありません。 Go言語は、HTTPを処理するときに少し速くなる場合がありますが、写真のサイズをすばやく変更できない場合は、サイズ変更のための追加の時間によって速度の向上が平準化されます。



Goで賭けを2倍にし、独自の画像サイズ変更ライブラリを構築することにしました。 OpenCVに基づく1つのGoパッケージによっていくつかの有望な結果が示されましたが、必要なすべての機能をサポートしていませんでした。 OpenCVの上に独自のCgo ラッパーを備えたLilliputというGoリサイザーを作成しました。 作成時に、Goで余分なゴミが生成されないように注意して監視しました。 Lilliputラッパーは、必要に応じてOpenCVを少しフォークしましたが、必要なほぼすべてを実行します。 特に、画像を解凍するかどうかを決定する前にヘッダーをチェックできるようにしたかったのです。この方法では、大きすぎる画像のサイズ変更を即座に拒否できます。



Lilliputは、既存および実績のあるCライブラリ（たとえば、JPEGのlibjpeg-turbo、PNGのlibpng）、および圧縮と解凍のサイズをすばやく変更するためのベクトル化されたOpenCVコードを使用します。 HTTPクライアントとサーバーを同時に使用するための要件を満たすために、 fasthttpを追加しました。 その結果、この組み合わせにより、合成ベンチマークでImage Proxyを着実に上回るサービスを開始できました。 加えて、リリプットは私たちが必要とするタスクでpillow-simdより悪くも良くも働きませんでした。







最初のコードには問題がなかったわけではありません。 最初、Media Proxyはリクエストごとに16バイトをリークしました。 これは、特に少量のリクエストでテストする場合にすぐに気付くほど小さいです。 この問題を解決するために、Media Proxyはサイズ変更のために大きな静的ピクセルバッファーをインストールしました。 CPUごとにこのようなバッファを2つ使用するため、32コアのマシンではすぐに32ギガバイトのメモリを消費します。 テスト中、メディアプロキシはすべてのメモリを使用するため、メディアプロキシの再起動には数時間かかりました。 これは、状況を明確にするのを困難にするのに十分な時間です：本当にメモリリークがあるか、または動作中に単純に制限を超えています。



最終的に、何らかの種類のメモリリークがまだあると判断しました。 このリークがGoにあるのかC ++にあるのかはわかりませんでした。コードを調べても答えが得られませんでした。 幸いなことに、Xcodeには優れたメモリプロファイラーが付属しています 。これは、[ 機器 ]メニューの [ リーク]ツールです 。 このツールは、リークのサイズと、リークが発生するおおよその場所を示しました。 このようなヒントは、ソースを特定し、リークを修正するためのより徹底的な調査に十分でした。



メディアプロキシでは、別のバグが発生したため、中断しました。 時々、彼は奇妙に甘やかされて育った写真を配りました。その半分は通常のままで、残りの半分は「バギー」でした。 どこかで画像を部分的にエンコードしているのか、OpenCVを間違って呼び出しているのではないかと考えました。 バグはめったに現れず、診断が困難でした。



調査を進めるために、シミュレータ内のHTTPサーバーへのリンクを含むURLを返す高性能クエリシミュレーターを開発し、このシミュレーターが要求クライアントとホストサーバーの両方として機能するようにしました。 彼は、Media Proxyでこのような画像の破損を引き起こすために、応答にランダムに遅延を挿入しました。 問題を確実に再現したため、Media Proxyのコンポーネントを分離し、サイズ変更された画像を含む出力バッファーで競合状態を見つけることができました。 最初のイメージがシステムに返される前に、1つのイメージがこのバッファーに書き込まれ、次に別のイメージが書き込まれました。 実際には、グリッチな写真は2つのJPEGであり、一方が他方の上に記録されました。









Media Proxyによって生成される実際のバグのあるJPEG



複雑なシステムのバグを探す別の方法は、ランダムな入力データが生成されてシステムに送信されるときのファジングです。 この場合、システムは奇妙な動作または崩壊を示す可能性があります。 私たちのシステムは入力データに対して耐性がなければならないため、この重要な手法をテストプロセスに適用することにしました。 AFLは非常に優れたファザーであるため、それを選択してLilliputに設定しました。これにより、初期化されていない変数によるいくつかの失敗を識別できました。



これらのバグを修正した後、Media Proxyを本番環境に導入するのに十分な自信が生まれました。そして、私たちの努力がそれだけの価値があることを嬉しく思いました。 Media Proxyは、Image Proxyと同じ数のリクエストを処理するために必要なサーバーインスタンスが60％少なく 、これらのリクエストをはるかに少ない時間分散で実行します。 プロファイリングにより、新しいサービスのCPU時間の90％以上が解凍、サイズ変更、および圧縮に費やされていることが示されました。 これらのライブラリはすでに大幅に最適化されています。つまり、追加の成長は容易ではありません。 さらに、サービスはプロセスでガベージをほとんど生成しませんでした。



現在、Media Proxyは中央値25ミリ秒で画像サイズ変更を実行し、応答遅延は中央値85ミリ秒です。 毎日1億5,000万枚以上の写真のサイズを変更します。 メディアプロキシは、 n1-standard-16自動スケーラブルGCE ホストグループで実行され、通常は12インスタンスのピークを迎えます。

メディアプロキシでメディアをダウンロードする

サービスが静止画像で正常に機能した後、アニメーションGIFのサイズ変更のサポートを接続したかったため、OpenCVはこの作業を行いません。 LilliputがアニメーションGIF全体のサイズを変更し、PNG形式で最初のフレームを提供できるように、 giflibの上に別のCgoラッパーをLilliputに追加することにしました。



GIF標準では各フレームで256色のパレットを使用できるようになっており、サイズ変更モジュールはRGBスペースで機能するため、GIFのサイズ変更はそれほど簡単ではありませんでした。 新しいパレットを計算するのではなく、各フレームのパレットを保存することにしました。 RGBをパレットインデックスに戻すために、Lilliputに単純なルックアップテーブルを提供しました。このテーブルは、RGBビットを受け取り、その結果をパレットインデックステーブルのキーとして使用しました。 これはうまく機能し、元の色を維持しましたが、このアプローチは、Lilliputがこの形式のソースファイルからのみGIFを作成できることを意味しません。



また、 giflibにパッチを適用して、一度に1つのフレームのみをデコードしやすくしました。 これにより、フレームをデコードし、サイズを変更してから、次のフレームに進む前にエンコードおよび圧縮できます。 これにより、GIFサイズ変更モジュールのメモリ消費が削減されます。 フレームごとにいくつかのGIF状態を保存する必要があるため、これはLilliputを少し複雑にしますが、Media Proxyのより予測可能なメモリ使用量は明らかな利点のようです。



giflibはサイズ変更プロセスを完全に制御できるため、LilliputのgiflibラッパーはImage Proxy GIFリサイザーにあった問題の一部を修正します。 かなりの数のNitroユーザーが、 GIFアニメーションアバターをアップロードします。これらのアバターは、Image Proxyでサイズを変更した後、バグがあるか透明度エラーがありますが、Media Proxyを処理した後は正常に動作します。 一般に、判明したように、サイズ変更プログラムにはGIF形式のいくつかの側面に問題があるため、透明なフレームまたは部分的なフレームの視覚的な不具合が発生します。 独自のラッパーを作成することで、発生した問題を解決できました。



最後に、 libavcodecの CgoラッパーがLilliput に追加され、ビデオを停止し、MP4およびWEBMクリップの最初のフレームを受信できるようになりました。 この機能により、Media Proxyはユーザーが投稿したビデオファイルのプレビューを生成できるため、このプレビューに基づいて他のユーザーがビデオを開始するかどうかを決定できます。 最初のフレームの抽出は、公開されたファイルおよびリンク用にクライアントに組み込みのビデオプレーヤーを追加することを妨げる最後の要因の1つであり続けました。

もっとオープンソース

Media Proxyの作業に満足したので、MITライセンスの下でLilliputを公​​開します。 このパッケージが、生産的な画像サイズ変更サービスを必要とする人々に役立つことを願っています。この記事では、他の人が新しいGoパッケージを作成することをお勧めします。