画像配信サーバーのコストを 1/10 にした話 [DeNA インフラ SRE]

はじめに

こんにちは。IT 基盤部の増田です。 IT 基盤部は、DeNA のさまざまなサービスのインフラを横断的に担当している部署です。 IT 基盤部では、安定的なシステム基盤の提供をすることだけでなく、運用コストの削減にも力を入れています。

本日は、運用コストの削減に関する話をご紹介します。対象は、Mobage の静的画像を配信するシステムです（以下では「画像配信システム」と呼びます）。

当時私は、部署に配属されて 1 年ちょっとでした。今回のコスト削減では、方針そのものの検討から任されました。このように、プロジェクトをまるごと任されるのは初めてでした。

プロジェクトを進めるうえで、以下のようなことに注意しながら仕事をしました。

言われたことを鵜呑みにせず、裏取りをする
全体ではなく、一部に試す

IT 基盤部で 1 年働いて、基本的な仕事の仕方として、この習慣が身につきました。この習慣がコスト削減にどう活きたかにご注目ください。

構成の確認

まずは、画像配信システムの構成を確認します。構成は以下の図のようになっていました。

構成を文字にすると、下記のとおりです。

CDN
ロードバランサー; Elastic Load Balancing（ELB）
サーバー群; Amazon Elastic Compute Cloud（EC2）
- リバースプロキシ 3 台
- 静的画像を配信するサーバー（以下では、「画像配信サーバー」と呼びます）約 80 台
  - 約 40 系統
  - 冗長化のため、各系統は 2 台構成

読者の皆さんは、ロードバランサーの裏にリバースプロキシがあり、構成が不自然なことにお気づきかもしれません。実は、このシステムは今はクラウド（AWS）にありますが、元々はオンプレで稼働していました。クラウドへの移行の際、諸事情があったため、オンプレのときの構成がほぼそのまま残っています。このため、クラウドに最適化された構成にはなっていませんでした。そこで、クラウドに最適化することで、不自然さの解消とコストの削減を図ろうと思います。

費用の確認

次に、費用の内訳を確認しました。費用の大部分は、約 80 台ある画像配信サーバーのものでした。そして、サーバーの費用をさらに分解すると、コンピューティングリソースとストレージの費用が多くを占めていました。

さらに、これらのコストに削減余地があるかを確認しました。

まず、コンピューティングリソースに関しては、リソースがかなり余っていました。各画像配信サーバーには、ほぼ最小のリソースを割り当てていました。しかし、静的画像をホストするだけなので、それでもリソースが余っていました。

次に、ストレージの費用に削減余地がないかを確認しました。オンプレの構成の名残で、EBS を各系統で 2 つずつ用意してストレージを冗長化していました。クラウドの機能をもっと活用して、ストレージを冗長化できないか、検討の余地がありそうです。

構成変更によって、これらの問題を解決できないか考えてみます。

一つめの構成

そこで、新たな構成を検討しました。

コンピューティングリソースに関しては、約 40 系統ある画像配信サーバーを 1 系統に集約します。そして、そこにほぼ最小のコンピューティングリソースを割り当てることで、コンピューティングリソースを削減します。

ストレージに関しては、冗長性を確保しながらコストを削減するために、下図のようにします。

文字にすると、下記のとおりです。

今までのストレージ
- EC2 用の EBS * 約 80
これからのストレージ
- EC2 用のストレージ * 1
  - 全系統の画像を集約し、1 つのストレージを複数台の EC2 で共用
- バックアップ用のストレージ * 1
  - バックアップの実行とバックアップ用のストレージの管理をする「AWS Backup」を使用

ストレージの総使用量は変わりませんが、AWS Backup のストレージは EBS よりも安いので、コストが削減できます。

ストレージを共用するためには、Amazon Elastic File System（EFS）を利用します。 EFS は、マネージドなネットワークファイルシステムで、複数のホストでストレージを共有できます。

EFS には、「ストレージクラス」という概念があり、性能や料金体系の異なるいくつかの選択肢があります。そして、最適なストレージクラスは、アクセスパターンによって変わります。このシステムでは、画像は CDN にキャッシュされるので、画像サーバーそのものへのアクセス頻度は低いです。一般に、アクセス頻度が低いときは、「低頻度アクセスストレージ」というストレージクラスを使うと良いので、それを採用します。

構成は以下の図のようになります。

当初の構成との差分は、下記のとおりです。

リバースプロキシ廃止
- 画像配信サーバー約 40 系統をまとめたので不要
画像配信サーバー約 80 台 => 3 台
画像は 1 つの EFS に集約

この構成の最大のメリットはもちろん、費用が大幅に削減できることです。コンピューティングリソースの費用は、EC2 の台数が減ったおかげで削減できています。ストレージの総容量は変わりませんが、それぞれのストレージの単価は、EBS よりも安いので、ストレージの費用も削減できています。

もうひとつのメリットは、システムのコードをほぼ改修しないで済むことです。このシステムでは、Mobage のユーザーが画像を投稿すると、その画像は Web サーバーを経由して、最終的には画像配信サーバーに保存されます。 EFS を利用した構成では、画像配信サーバーのストレージが変わるだけなので、この流れは変わりません。そのため、既存のコードをそのまま残せます。

意外な見落とし

しかし、よく調べてみると、このコストの見積もりには見落としがありました。実は、EFS の低頻度アクセスストレージには、使用するための条件があったのです。その条件とは、保存するファイルのサイズが 128 KB 以上でなければならないことでした。そして、このシステムの画像のほとんどは、この条件を満たしていないので、低頻度アクセスストレージは使えませんでした。かといって、低頻度アクセストレージでないストレージクラスは、費用が上がってしまうので、それらは使えません。

結局、残念ながら、この案は見送ることにしました。この構成を考えたのは前任者だったのですが、削減額を自分でも裏取りをしたおかげで、作業の手戻りが防げました。やはり、自分で裏取りをすることは重要だと再認識しました。

もうひとつの構成

新たな案として、Amazon Simple Storage Service（S3）を使う構成を考えてみました。なぜなら、一般的に、静的画像の配信には、S3 を使うと良いことが多いからです。 S3 なら、手間をかけずに、ストレージの冗長性・可用性を確保できます。

具体的には、以下の図のような構成を考えました。

ロードバランサーも、リバースプロキシも、画像配信サーバー群もなくなり、ずいぶん構成がシンプルになりました。

この構成でも、大幅なコスト削減ができます。まず、コンピューティングリソースの費用が掛かりません。さらに、冗長化が不要、かつ、単価も EBS と比べて安いので、ストレージの費用も安くなっています。ちなみに、一つめの削減案よりもさらにコストが削減できています。（怪我の功名！）

一方、デメリットもあります。それは、先程述べたアップロードの流れが変わるため、コードの修正が必要になることです。というのも、画像の最終的なアップロード先が EC2 から S3 に変わっているからです。ただ、コードの改修は工数はそこそこかかるものの、コスト削減効果で十分ペイできるので、このデメリットは許容することにしました。

構成変更の実施

構成が決まったので、約 40 系統ある画像配信サーバーを S3 に移行していきます。その際、もし問題が発生しても影響を最小限に抑えられるように、一気に移行するのではなく、徐々に進めていきます。具体的には、全系統を一度に移行せずに、数系統ずつ移行していきます。

さらに、各系統の移行も一度には行いません。各系統に対するアクセスは、一度に全てではなく、一部分だけ S3 に転送することができます。これを利用して、一部のアクセスで動作確認をしながら、徐々に移行を進めます。

実は、移行を進める中で、本当に問題が発生してしまいました。それは、コードの改修漏れにより、ユーザーが見られるはずの画像が見られなくなるという問題でした。改修漏れそのものは、もちろん反省しなければなりません。ただ、変更をいきなり全部に適用しなかったおかげで、ユーザーへの影響は非常に小さく済みました。

おわりに

このようにして、自分は初めてのコスト削減を進めました。

コスト削減を進めるにあたって、IT 基盤部で身につけた以下の習慣が役に立ちました。

言われたことを鵜呑みにせず、自分で裏取りをするという習慣のおかげで、作業の手戻りが防げました。
最初から全部に適用するのではなく、まず一部に試すという習慣のおかげで、問題は発生したものの、ユーザーには大きな影響を与えずに済みました。

また、作業の中で、クラウドサービスには、意外な制限があるのを実感しました。今回は、EFS の低頻度アクセスストレージにはファイルサイズの制限があることが分かりました。 EFS に限らず、クラウドサービスには、見落としやすい制約がよくあります。このような制約に引っかからないために、皆さんにとって新しいサービスを使用し始める際は、そのサービスで意外な制約にはまった事例がないか、ネットで調べてみてください。

ちなみに、構成変更は現在も進行中です。まだ完了してはいませんが、進捗に見合ったコスト削減効果が得られています。