ソーシャル経済メディア「NewsPicks」SREチームの美濃部です。

NewsPicksではアプリケーションのビルドにAWS CodeBuildを使用しており、ビルドキャッシュの格納先としてAmazon EFS（AWSのフルマネージド型NFSファイルシステムサービス）を利用しています。

以前はS3に格納していましたが、EFSにする事でビルド時間が2分程短縮できる事がわかったので多少コストを払ってでも開発者の生産性を重視しました。1日に何度もビルドを行う開発者にとってこの2分の積み重ねは大きな価値があります。開発者の人数が多ければ多いほどこの価値もあがります。

ただし、想像以上にEFSの利用料金が発生してビルドに関わるコストが上がってしまいました。

この記事ではバーストクレジットを効果的に活用することでコストを4分の1に削減する事に成功したお話をしたいと思います。

※ 具体的なコストについては言及しません。

補足ですが弊社ではGithubを利用しているのでGithub Actionsのプラットフォーム上でビルドする選択もあるのですが、Github ActionsのコンピューティングリソースよりさらにスペックをあげたCodeBuildで行う事によってビルド時間を短縮しています。これによりコストも多少上がってしまうのですが弊社ではいかに開発生産性を重視しているのかという事が伝わるかと思います。詳細は以下のブログ記事を参照して下さい。 tech.uzabase.com

Amazon EFSについての基本的な話

まずはAmazon EFSについてスループットモードと料金体系について簡潔に説明させて下さい。ストレージクラスについては標準ストレージを前提に話を進めます。

スループットモード

まず、ベースラインスループットとバーストクレジットというキーワードが重要なので先に説明します。

ベースラインスループットとは

ストレージ使用量に比例して割り当てられるスループットのことです。1GiBあたり50KiB/秒が提供されます。例えば使用量が100GiBの場合、ベースラインスループットは5,000KiB/秒（=5MiB/秒）になります。

バーストクレジットとは

ベースラインスループットにはバーストクレジットという概念があり、使用されなかったベースラインスループットはバーストクレジットとして蓄積されていきます。100GiBの場合は5MiB/秒なので、例えば24時間何も使用されなかった場合は432MiB/秒分 (5MiB/秒 * 86,400秒) のバーストクレジットが蓄積されます。バーストクレジットはストレージ使用量1TiBあたり最大100MiB/秒なのでこれを考慮すると100MiB/秒のスループットが1日最大72分（5MiB/秒 * 86,400秒 / 最大100MiB/秒 / 60秒）でる計算になります。

バーストクレジットがゼロになるとスループットはベースラインスループットまで低下します。ベースラインスループットについては最低1MiB/秒が保証されるので例えばストレージ使用量が10GiBであれば通常の計算であれば0.5MiB/秒のスループットになりますがこの場合でも最低1MiB/秒が保証されます。

新規に作成されたファイルシステムは最初に2.1TiBのバーストクレジットが与えられます。

ストレージ使用量については約1時間ごとに計測処理が実行されるのでベースラインスループットの更新は最大1時間のラグがあります。

次に3つのスループットモードについて説明します。

バーストスループット

前述したベースラインスループット及びバーストクレジットの話になります。

プロビジョンドスループット

バーストスループットモードに加えて、バーストクレジットを使い切っても最低維持したいスループット量を指定できるモードです。指定したスループット量よりもベースラインスループット（バーストクレジットも適用されます）が多い場合はこちらが適用されるのでプロビジョンドの料金は発生しません。当然ベースラインスループットよりも低いスループット量を指定しても意味がありません。

エラスティックスループット

自動的にスケールアップまたはスケールダウンします。ベースラインスループットの概念もない為バーストクレジットも与えられません。使用したスループット全てに対して料金が発生します。

（参考） docs.aws.amazon.com repost.aws aws.amazon.com

料金体系

EFSの料金体系はシンプルにいうと以下の2つの利用料になります。

ストレージ使用量
スループット（ネットワーク転送量）

実際に運用してみると、ストレージ使用量に対するコストはスループットと比較してさほど影響がないことが大半です。他のAWSサービスも同様ですがストレージコストよりもデータ通信コストの方がコストとしては高くなることの方が多いです。

（参考） aws.amazon.com

ワークロードに応じた適切なスループットモードを調査

アプリケーションビルドに使用しているので基本的には開発者が稼働している平日の日中帯が主な利用時間となります。開発がさかんに行われるほど利用され、比例してワークロードがあがります。また、アプリケーションが大きく変更されない限りはキャッシュ容量は一度作成されたら容量はあまり変わりません。

料金に関わる重要な点としては以下となります。

キャッシュの格納先として利用しているだけなのでストレージ使用量は一般的なストレージのユースケースから考えると少ない
スループットは一定ではなく主に平日の日中帯にあがるがそれ以外はほぼない

実際に運用の経緯について説明します。

まずはバーストスループットモードで運用

まずはバーストスループットモードで運用を開始しました。問題だったのはストレージ使用量が当初2GiBしかなかったのでベースラインスループットは100KiB/秒（2GiB * 50KiB/秒）しかありませんでした。バーストクレジットが蓄積しても微々たるものでした。24時間スループットが何もない状態であっても8,640MiB/秒（0.1MiB/秒 * 86,400秒）しか蓄積されません。要件として平日の日中帯の必要なスループットが10MiB/秒だと仮定した場合、14.4分しかもたない計算になります。14.4分間以外の時間はベースラインスループットの最低ラインである1MiB/秒になってしまいます。この状態ではすぐに性能劣化してしまいアプリケーションビルドの時間が大幅に伸びてしまいました。

エラスティックスループットモードに変更

性能問題を即時に解決する為に自動でスケールするエラスティックスループットモードに変更しました。性能は改善しましたがコストが大幅に増加してしまいました。もっとコスト効率よく運用できないかを調査した結果、バーストスループットモードで意図的にダミーファイルを作成してストレージ使用量を増加させることでベースラインスループットをあげる方法があることを知りました。

ダミーファイルを用意して再度バーストスループットモードに変更

再度バーストスループットモードに変更し、ダミーファイルは以下のようにddコマンドで作成しました。

# 100GiBのダミーファイル作成
dd if=/dev/zero of=100GiB.dummy bs=1GiB count=100

これにより簡単にベースラインスループットをあげることができました。ベースラインスループットをあげることによって使用していない時間帯のバーストクレジットの蓄積が多くなります。このバーストクレジットを有効に使うことでコスト効率よく運用できます。

仮定の要件として平日の日中帯を8時間とし平均スループット10MiB/秒を担保するとした場合、バーストクレジットを加味した場合の必要なストレージ使用量はどれくらいか計算してみます。

必要なスループットは合計288,000MiB/秒（8時間 * 60分 * 60秒 * 10MiB/秒）
バーストクレジットを蓄積できるのは57,600秒（16時間 * 60分 * 60秒）
必要なベースラインスループットは約5MiB/秒（≒5,000KiB/秒）（288,000MiB/秒 / 57,600秒）
必要なストレージ使用量は1GiBあたり50KiB/秒なので100GiB（5,000KiB/秒 / 50KiB/秒）

100GiBの使用量があれば要件を満たせることがわかりました。この場合バーストクレジットを使いきった場合は100GiBのベースラインスループットである5MiBまで低下します。もしバーストクレジットを使い切った場合でも10MiB/秒のスループットを維持したいのであればプロビジョンドモードにする必要があります。前述した通りプロビジョンドモードでもバーストクレジットが優先されて使用されるので常に10MiB/秒の料金が発生するわけではなく実際に使用した分だけ発生します。