みなさん、こんにちは
SOMPOシステムズのクラウドエンジニアです。
FinOpsのナレッジについて、紹介します。

「FinOpsってなに？」と思った方は、まずは以下のブログをご覧いただいた後に、本ブログをご覧ください。

1. はじめに

今回は、とあるクラウド(AWS)の構成において「EC2」観点で注意が必要なポイントを紹介します。

2. 構成

2.1 利用サービス（開発環境・本番環境ともに同様の構成）

• Amazon EC2

• Amazon RDS

• Elastic Load Balancer

• CloudFront

• Route53

• Amazon S3

2.2 構成図（インターネット公開のWebシステム）

2.3 構成概要

• マルチAZ構成

• 通常時zone aのEC2を利用

• ELBでヘルスチェックし、失敗した場合zone bのEC2に切り替え

• 開発、本番環境ともにリソースのスペック同等

• 24/365 稼働システム

3. FinOps観点でチェックすべきポイント

3.1 開発環境の稼働時間

• 開発環境のEC2の稼働時間の確認をする。

「本番環境が24/365 稼働のシステムだから」という理由で、開発環境も24/365 稼働の必要はないはずです。あくまでも開発環境は運用者・開発者が利用する環境であるため、常に稼働しておく必要はなく、必要な時のみ稼働していれば良いという考え方ができます。また、開発環境が本番環境同等の構成をしている場合、普段利用していないのにも関わらず本番環境と同じコストがかかります。特に、EC2などのIaaSのサービスは、起動しているだけでコストがかかるため、注意が必要です。

3.2 本番・開発環境のインスタンスサイズ

• 開発環境のリソースのサイズを確認する。

構築期間中のテスト時以外はEC2のインスタンスサイズをスケールダウンする。本番環境のリリース後に、開発環境において本番同等のスペックは必要かどうかを見直すことが大切です。また、一度インスタンスをスケールダウンしても必要な時にスケールアップして、本番同等の環境を再現することができます。クラウドのリソースのサイジングは柔軟に行えることが特徴であるため、存分に活かしましょう。

• 本番環境のリソースのサイズ確認をする。

本番環境は、実際に稼働中のシステムのリソース利用状況(わかりやすいところですと、CPU,メモリ等)を確認したうえでインスタンスのスケールダウンを行う必要があります。特に、システムの特性上「常に一定の使用率」「一時的に高騰する」などを考慮したサイジングが必要です。そのため、本番環境のEC2のスケールダウンをする際は、事前に開発環境で本番環境同等の負荷テストを実施し、スケールダウン後でも耐えうるインスタンスサイズとします。

3.3 本番・開発環境のマルチAZ構成

• 開発環境のマルチAZ構成の要否について確認する。

構築期間中または障害時以外で、開発環境の可用性が必要な場合は数少ないと思います。それでいて、常時利用しない環境で2倍(EC2×2)のコストがかかっていることになります。そのため本番環境のリリース後、開発環境はシングルAZ構成とするということも検討が必要です。

• 本番環境のマルチAZ構成の要否について確認する。

24/365稼働のシステムの場合、マルチAZ構成であると良さそうですが、システムのサービスレベルによって判断することも重要です。サービスレベルは高くなく、数日のサービス停止があっても問題ないシステムであればコストを優先して、シングルAZ構成にすることも検討は必要です。

4. 総括

第3章で述べた3つのポイントは、比較的コスト効果が高く、作業コストが少ないポイントになります。
例として、EC2に100万/月のランニングコストがかかっているとき、3つのポイントの対応をした場合、コスト効果は以下となります。（大まかな概算コストになります。。。）

参考までにEC2のインスタンスサイズごとの料金表が公開されているため、実際にそれらのリソースを利用する際は、確認してみてください。

ぜひ、皆さまもクラウドを最適な状態で利用するために、本ブログのナレッジを活用してみてください。