こんにちは、WEAR部の繁谷です。SREとしてWEARの運用・保守・開発をしています。

WEARでは、以前の記事で説明した通り、画像配信のリプレイスを行ってきました。本記事ではSRE観点で画像配信のリプレイスやAkamai Image & Video Manager（以下、Image Manager）を利用した画像リサイズの導入の事例を説明します。

WEARにおける画像配信の課題

前述の記事でも紹介している通り、リプレイス前のWEARの画像配信は下図の構成でした。コーディネート投稿時などのタイミングでIISのAPIを叩き、オリジナル画像をS3に保存します。その書き込みをフックとし、オリジナル画像をリサイズするAWS Lambdaが実行され、派生画像を作成します。そして、作成された派生画像をCDNで配信します。

図1 : リプレイス前の構成図

しかし、この構成は下記の諸々の課題を抱えていました。

• 画像アップロードのアプリケーションがメンテナンスできないIISやVBScriptで稼働している
• IaC（Infrastructure as Code）されていないAWSのリソースがある
• 画像のリサイズを行うLambdaアプリケーションが古いNode.jsで書かれている
• 膨大なオリジナル画像と、それらをリサイズした派生画像によりS3のコストが増加している

上記の課題のうち、上の2つは前回の記事で、APIのリプレイス、新しいAWSアカウントへの移行によってそれぞれ解決できました。本記事では、主に下の2つの課題に対するアプローチを紹介します。

リプレイス戦略

本章では、前章同様に前回の記事の再掲を含みますが、上記の課題を解決するためのリプレイス戦略を説明します。

リプレイスのゴール

まず始めに、リプレイスで目指す完成形を紹介します。

図2 : リプレイス後の構成図

図1で示したリプレイス前の構成と比較すると、非常にシンプルな構成になっています。以下が変更点です。

• AWSのリソースをIaCされた新アカウントへ移行
• 画像アップロードAPIをECS上のRuby on Railsアプリケーションへリプレイス
• CDNをAkamaiへ変更
• LambdaによるリサイズをImage Managerに変更し、動的に画像リサイズを行うことで派生画像が削除可能な構成に変更

なお、このゴールを目指すなかで、以下の制約も存在していました。

• ダウンタイムをなるべくなくす
• 画像のURLは変更しない

前者のダウンタイムを短くすることは当たり前のことです。それに加え、リプレイスによりURLのドメインやパスを変更してしまうとアプリケーションコードを変更しなければならないため、後者の制約も課しています。これらの制約をクリアしつつ、リリースを4つのフェーズに分けてリプレイスを進めていきます。

各フェーズの内容を順に説明します。

フェーズ1 : アップロードAPIのリプレイス

本フェーズの内容は、前述の過去記事で詳しく説明しているため、詳細は割愛します。下図に示す通り、新しいAWSのリソースを作成し、新規のアップロードは新しいAPIで行うようにしました。

続きはこちら