ザ・イミックス アセットマネージャー 私たちのプラットフォームの重要なコンポーネントです。私たちは、AIを活用した画像のタグ付け、危険なコンテンツに対する警戒アラート、高度な検索の強化など、ユーザーのあらゆる資産管理要件をサポートすることに専念しています。アセットマネージャーを支えるインフラの信頼性と効率性は、重要なだけではありません。効率的なだけでなく、高品質な画像とユーザーへのサービス提供に対する私たちの情熱に共鳴する体験を提供するという私たちの取り組みの礎でもあります。

画像や動画のデータベースが拡大するにつれ、当社の業務能力はますます課題に直面するようになりました。これは、現時点ではお客様が気付かないことでも、関心を引くこともないでしょうが、将来にわたって当社の事業が迅速で信頼性が高く、回復力を維持し続けることを確実にすることが、私たちの根強いコミットメントです。imgix が視野を広げ続けている中で、需要の急増に対してもレジリエンスを維持するというビジョンに突き動かされています。以下のセクションでは、インフラストラクチャに対する進化する需要を常に先取りしながら、業務の改善に情熱を注いだ経緯を詳しく説明していきたいと思います。

課題：カイテフィンを操作上の負担から解放する

内部では、Google Cloud Spanner と Dataflow を使用してアセットマネージャーの重要な機能を推進しています。これには、動画のトランスコーディング、画像 AI のタグ付け、アップロードステータスの追跡など、幅広いタスクが含まれます。Spanner は当社最大のデータベースです。CDN から提供されるすべてのアセットが Spanner データベースへの対応する書き込み操作をトリガーするからです。

アセットマネージャーの中核となるのは、内部では「カイトフィン」と呼ばれる一連のデータフローパイプラインです。Kitefin は Spanner データベースを体系的に探索して、新しいアセットを特定したり、既存のアセットの変化を監視したりして、Spanner のデータとオリジンソースのデータの一貫性を確保します。データベース内の資産の数が時間の経過とともに増加するにつれて、Kitefin はデータベースの進化状態を絶えず分析する必要があったため、インフラストラクチャへの需要は倍増しました。これにより、Asset Manager で新規または更新されたアセットを更新するまでの待ち時間やタイムアウトが長くなるなど、パフォーマンスが低下するリスクが高まりました。また、運用コストが大幅に上昇する可能性もあります。以下は、キャパシティ消費量を 30% 削減するために実施した措置です。

対処法 1-クエリの最適化

Kitefinの最初の実装では、分割可能なクエリを使用して複数のソースから同時にアセットを取得し、Dataflowの基盤となるライブラリとしてApache Beamを活用しました。Apache Beam は作業を効果的に並列化できるため、このアプローチは有望に思えました。しかし、クエリのパフォーマンスには一貫性がありませんでした。これは主に、分割されたクエリがソースを一貫してバッチ処理していなかったためです。

これらのクエリは次第に時間がかかるようになり、ときどきタイムアウトが発生し、最終的には頻繁になりました。そこで、Spanner へのクエリ方法を再検討することにしました。

プロファイリングを行い、さまざまなアイデアを試した結果、データソースごとに複数のクエリを個別に発行すると、最も一貫したパフォーマンスが得られることがわかりました。これらのクエリは、自動スケーリングを行わないワーカープール内で並行して実行されたため、Spanner への接続数が最小限に抑えられました。クエリの速度をさらに向上させるため、これらのジョブに合わせた専用の読み取りインデックスも作成しました。この最適化には数テラバイトの追加ストレージが必要で、構築には数日かかりましたが、クエリの効率は大幅に向上しました。

さらに、この最適化により、これらのクエリの実行に必要な CPU 時間が短縮されたため、Dataflow の請求にもプラスの影響がありました。

この変更を適用した後の結果は次のとおりです。

対処法 2-スパナにデータブーストを与える

当初から、Kitefinからの大量の要求に効果的に対応できるよう、十分な数のSpannerコンピュートノードをプロビジョニングしました。この戦略的なプロビジョニングにより、アセット処理の需要が予期せず急増した場合でも、データベースの CPU 使用率を Google が推奨するしきい値をはるかに下回るレベルに抑えることができました。ある程度期待していたことですが、これにより Spanner に依存する他のサービスのパフォーマンスがデータベース操作によって妨げられることがなくなりました。

さらに、Googleが2023年6月にSpanner Data Boostを導入したとき、私たちはすぐに、Spannerワークロード用のオンデマンドコンピューティングリソースとしてのその可能性を評価し始めました。その後まもなく、私たちは最も重要なタスクをこの新機能を活用するように移行しました。オンデマンドのコンピューティングリソースを利用することは、プロビジョニングされたノードを 24 時間稼働させる場合と比較して、はるかに費用対効果が高いことが証明されました。その結果、Spanner ノード数を 40% 削減し、運用効率を損なうことなく大幅なコスト削減につながりました。

コンピューティングコストの一部はデータブーストの費用に転嫁されましたが、キャパシティの削減による全体的な節約は、追加のデータブーストコストを補う以上のものでした。

この機能を有効にした後の結果は次のとおりです。

テイクアウェイ

• 複数のシャードにわたってデータをクエリする場合、複数のシャードを同時にクエリするよりも、シャードを個別にクエリする方がパフォーマンスが向上します。
• Data Boostは、コンピューティングリソースのサーバーレスプールを維持して、突然の負荷の急増を効果的に処理できるので便利です。

この旅は、進化するサービスの需要を満たすために、テクノロジースタックと運用戦略を継続的に改善するという私たちの取り組みを浮き彫りにしています。こうした取り組みを通じて、私たちはパフォーマンスの向上とコスト削減のバランスを取り、以下のことを確実にしてきました。 アセットマネージャー 当社のインフラにおいて信頼性が高く効率的な構成要素であることに変わりはありません。