AWSのサーバーレスのコストを管理するための10つの方法

AWS Lambdaの登場により開発者はアプリケーションが利用する計算量に応じた料金のみを支払うことができるようになり、全く新しいサーバーレスコンピューティングという概念が生まれました。DynamoDBなどの他のサーバーレスなサービスもLambdaと同じような価格体系が適用されます。従来のアーキテクチャと比較して、サーバーレスアーキテクチャは開発者の生産性を向上させるだけでなく、大幅なコスト削減を実現しています。

しかしながら、サーバーレスアーキテクチャの総インフラコストはアクセス数やデータ量の増加とともに増加する傾向にあります。この記事ではサーバーレスのコストを最適化するための10つの方法を紹介しています。

Cost Allocation Tagsの有効化

AWS BillingのCost Allocation Tagsを有効化すると、特定のTag付けされたAWSリソースの料金を合計で見ることが出来ます。 おそらくあなたのサーバーレスアプリケーションはCloudFormationで管理されていると思いますが、そのStackにTagを指定することで、そこに紐づくAWSリソースに同じTagが割り当てられます。こうすることで、あなたのサーバーレスアプリケーションにかかるコストを把握することが可能になります。

DynamoDB Capacityモードの使い方

DynamoDBにはオンデマンドとプロビジョニングの2種類のキャパシティモードがあります。選択したモードによって、読み書きのスループットに対する課金方法が決まります。オンデマンドは使用した分だけ料金を支払うため、より柔軟性がありますが、DynamoDBはアプリケーションのトラフィックに合わせて自動的にスケールアップされるため、コストが高くなり、コスト管理が難しくなることもあります。

プロビジョニングモードでは、1秒あたりに必要なReadとWriteのキャパシティを指定し、スロットリングによってアプリケーションがその容量を超えないようにします。オートスケーリングを使用してプロビジョニングされた容量を調整することができますが、通常よりも高いトラフィックに対応するために、これを上下させるのはユーザの責任となります。

すべての新規プロジェクトに対してオンデマンドのプロビジョニングから始め、トラフィックパターンがほぼ予測可能であることが確認できた場合にはプロビジョニングに切り替えることでコストを最適化することができます。

Savings plansとDynamoDB Reserved Capacityの活用

Savings plansは、AWSが提供する価格モデルです。基本的には1年から3年の間に一定の利用量を約束し、その代わりにAWSがインフラのコストを削減してくれるプランです。Savings PlansはLambdaとFargateの両方が対象となっているため、長期的にAWSのこれらのサービスを使用することが決まっている場合には、コスト削減のための良い方法となります。AWSでは、Savings Plansでどの程度の割引が行われるかを計算できる価格計算機を提供しています。

DynamoDBは大きなトラフィックがある場合に多くのコストが発生するケースがあります。DynamoDB Reserved CapacityはSavings Planと同じコンセプトの価格モデルです。時間単位で指定されたキャパシティを予約して、その料金を前払いします。ここで注意したいのは、プロビジョニングモードになっていないと予約容量を利用できないということです。

DynamoDBのクエリコストに注意しましょう

DynamoDBのクエリコストを念頭に置いてテーブル設計を最適化することは、高トラフィックアプリケーションのコスト最適化のための良い方法です。DynamoDBへの書き込みは読み込みの10倍のコストがかかるため、クエリを最適化して書き込みを最小限に抑えることで、コストを大幅に削減できる可能性があります。

また、DBの項目内の特定の属性を更新する場合、その書き込みのコストは、そのテーブル内のすべての属性の容量に基づいて計算されるということも覚えておきましょう。

Lambdaのメモリサイズの最適化

Lambdaのメモリサイズは少ない設定だからといって必ずしも低コストであるとは限りません。Lambda関数のメモリを増やすことで、実行時間が大幅に短縮され、全体的なコストが削減されると同時に、パフォーマンスも向上することがあります。Alex Casalboni氏のAWS Lambda Power Tuningは、このプロセスを自動化するための素晴らしい方法です。このプロジェクトはOSSであり無料で使えるため是非興味があれば試してみてください。

API GatewayのAPIタイプ適切なものを選びましょう

AWS API Gatewayには主に2つのモードがあります。Rest APIとHTTP APIです。HTTP APIはコア機能のみに限定されますが、REST APIに比べてレイテンシーが低く、コストも抑えられています。REST APIで提供されている追加機能を必要としない限り、HTTP APIを利用することでコストを削減することができます。

CloudWatch Logsの保持期間の最適化

CloudWatchLogsは、AWSのサーバーレスアーキテクチャの中でコストがかかることが多いです。保存期間を調整することでログの保存量を調整し、コストに大きなな影響を与えることができます。ステージング環境の場合に大量のログを長期間保存する設定になっていませんか?本番で実際に利用しているログの量はどれくらいでしょうか?余分なログは吐かれていないでしょうか?これを定期的に見直し、CloudWatchの設定が十分に最適化されていることを確認してください。

Step Functionsのコストに注意しましょう

Step FunctionsはLambdaを中心にワークフローを定義できるサービスです。アプリケーションを構成する関数全体を管理するための余分なコーディングが不要になり、そのワークフローは可視化されます。それにより問題が起こった時は簡単に追跡して調査が可能になります。

しかし、一方Step Functionsは$25 per million state transitionであり、これはLambdaの15倍の価格になります。Step Functionsを使用する際はコストに対するメリットを正しく理解しておくことをお勧めします。

Lambdaの無限ループに注意しましょう

エラーやセキュリティーホールを突かれた攻撃が原因で、Lambdaが予期せぬ実行を行い、コストが増大する事故を起こすケースがたまに見受けられます。CloudWatchなどで通知を行い、予期せぬ動作が発生した際はアラートが上がるようにしておきましょう。請求が発生してから気づいても遅すぎます。

バグやセキュリティ攻撃によって、Lambdaが無限ループに陥ったり、想定外の数の呼び出しが発生したりすることがあります。これらが迅速に発見されないと非常に高いコストがかかることを月末の請求にて気付くことになります。このようなリスクを軽減するために、CloudWatchで検知し、このような予期せぬ動作が発生したときにアラートを発生させましょう。

Kinesis Data Streamsのシャード数を最適にしましょう

Kinesisデータストリームのシャード数は、スループットとコストの両方を決定します。この設定を最適化することで、無駄にコストを上げることなく、ストリームのパフォーマンスを向上させることができます。事前に負荷テストを行い予測されるトラフィック量から最適なシャード数を計算することをお勧めします。