はじめに
みなさん、こんにちは。グローバルでは単なるクラウドの活用から先に進み、クラウドのビジネス価値を最大化するための取り組みである「FinOps」の実践が当たり前になりつつあります。
もちろんFinOpsの目指すべきゴールは、正しくはコスト削減ではないものの、今回はあえて削減の部分にフォーカス当てて紹介していきたいと思います。
よくあるコスト最適化のポイント
まず前段として、クラウドにおける一般的なコスト最適化のポイントとしては以下のような項目が挙げられます。
- コンピューティングの適正化
- 未使用リソースの棚卸
- 料金プランの適正化
- ストレージ/ネットワークの適正化
- ライセンスの適正化、など
もちろんこれらの項目はLambdaにも当てはまってくる部分があります。今回はこちらに沿ってLambdaの最適化ポイントを紹介していきたいと思います。
コンピューティングの適正化
過剰または過少なサイジングの見直し
必要なメモリサイズに対して過剰にプロビジョニングしている場合、使わないコンピューティングリソースに対して過剰に料金を支払っていることになります。そのため、メモリサイズを適正化することでLambdaのコストを削減できます。
また、必要なメモリサイズに対してプロビジョニングしているリソースが不足している場合は、リソース解放待ちなどの余計な処理に時間を要してしまっている可能性があります。メモリサイズを増加することで単価自体はあがってしまうものの実行時間は短くなり、結果としてトータルコストを低減できる可能性があります。
過剰なサイジングやプロビジョニング不足となっている可能性のあるリソースを特定する簡単な方法としては「AWS Compute Optimizer」を活用することです。標準機能のみの利用であれば無料で活用できるため、無効化されている場合はぜひ有効化し、コスト最適化の機会特定に活用ください。
レコメンデーションを鵜呑みにしてはいけない
レコメンデーションはあくまでこんなところに最適化の機会がありそうだ、という気づきとして活用ください。パフォーマンス問題を起こさないためにも、すべてを鵜呑みにせず、本当に適用して大丈夫なのか事前に評価を行うことが重要です。
Armベースの命令セットアーキテクチャーの活用
x86ベースの命令セットアーキテクチャーを採用している場合は、コスト効率や性能に優れるArmベースへ切り替えることでコストを20%ほど節約することができます。動作に影響がないことを十分に評価した上で命令セットアーキテクチャーを切り替えられないか検討してみてください。
導入ミドルウェアの制約云々の話があるEC2だとArmベースへの切り替えはかなり難しいものの、それらの制約の少ないLambdaであえばArmベースへの切り替えも現実的な選択肢と言えるかと思います。
スケーリングの調整
Provisioned Concurrencyのオートスケール
バーストアクセスへの対応のためにProvisioned Concurrencyを活用している場合は、バーストアクセスを予測した上で「Application Auto Scaling」を設定し、使用率や時間帯でプロビジョニング数をオートスケールさせることでコストを削減できる可能性があります。
料金プランの適正化
Savings Plansの適用
定常的にLambdaの利用料が発生する場合は、Savings Plans（SP）を適用することによってオンデマンド料金よりもコストを削減できる可能性があります。
SP購入によるコスト最適化の機会の気づきとして、AWS Billing and Cost ManagementのSPレコメンデーション機能が活用できます。稼働統計データを基にSP購入に関するレコメンデーションが提供された場合は、詳細調査を行った上でSPを追加購入できないか検討してみてください。
その他
過剰なタイムアウトやエラー発生の改善
タイムアウト終了してしまったということは処理が中断された、つまり結果として実行時間分の料金を無駄にしてしまった可能性があります。また同様に、エラーが発生しているということは期待した動作をせずに終了した、つまり結果として実行時間分の料金を無駄にしてしまった可能性があります。
そのため、関数の設定値を見直すなどしてタイムアウトを起こさないよう修正したり、エラー率を高めている要因の排除やエラーリカバリー処理を追加するなどのエラー終了しないようにする工夫などによってコストを改善できる可能性があります。
過剰なタイムアウト率やエラー率となっているリソースを特定する簡単な方法としては「AWS Trusted Advisor」を活用することです。
Trusted Advisorのコスト最適化チェックは、さまざまなAWSサービスに対するコスト削減の機会を特定することができるAWSサポートのひとつの機能で、ビジネス以上のAWSサポートプランに加入することで利用できるようになります。Trusted Advisor有効化のためだけにサポート加入する必要はありませんが、すでにビジネス以上のサポートに加入している方は、ぜひコスト最適化の機会特定に活用してみてください。
非同期処理による呼び出し回数の低減
同期処理をしている場合はキューイングサービスなどを中間に入れて非同期処理に変更し、複数のリクエストをまとめて処理することによって、Lambdaの呼び出し回数を減らすとともに起動/停止に伴う共通部分の処理を毎回実行しなくてよくなるため、結果として処理効率があがり全体的なコストを低減できる可能性があります。
コードのリファクタリング
同じ処理をするにしてもコードの良し悪しで効率は変わってきます。コードのロジックを見直し、コード改善によって処理効率を良くすることで使用メモリ量の低減や処理時間の短縮、結果としてLambdaの料金を削減できる可能性があります。
改善ポイントの特定する取っ掛かりとしては、プロファイラなどの活用が有効です。アプリケーションのパフォーマンスに対する分析を行い、より多くの時間を消費している処理から改善できないか検討していくようにしましょう。
最後に
もちろん今回紹介したもの以外にも最適化ポイントはあります。とはいえ、まずは今回紹介したような、よくある最適化ポイントから始めてみるのが良いのかなと思っています。
なお、一点注意していただきたいのですが、コスト削減に注力するがあまり、パフォーマンスを損なってしまうようでは本末転倒です。修正を加える際は、実際の環境への影響をしっかりと調査を行った上で実行するとともに仮に悪影響が出てしまった際には、すぐ切り戻せるようにしておくことも重要であることをご認識いただければと思います。
以上、AWS Lambdaのよくあるコスト最適化ポイントのご紹介でした。今回の内容は基本的に使い古された情報ですが新たな気づきがひとつでもあったなら幸いです。
- AWS は、米国その他の諸国における Amazon.com, Inc. またはその関連会社の商標です。
- その他、本資料に記述してある会社名、製品名は、各社の登録商品または商標です。