AWSのコスト削減: ストレージクラスの最適化

クラウドインフラに関わるコストは、各企業にとって1つの重要テーマかと思います。毎月、支払うコストであり、数％の増減であったとしても最終的にかなりの金額になります。

昨今の為替事情もあり、そんなクラウドインフラのコストを弊社で削減してきた方法を本記事で紹介いたします。本記事を読むことで、実例と共に手法を学んでいただけます。

何を実施したか？ ストックマークでは、クラウドインフラに AWS を活用しています。AWS のコスト削減のプラクティスは広く知られており、公式からもドキュメントが提供されています。

具体的な方法の中からいくつか代表的なものを取り上げると次のような項目があります。

コスト分析と監視 リザーブドインスタンス、スポットインスタンスの活用 オートスケーリングの活用 ストレージの最適化 データ転送の最適化 リソースの削除や停止 たとえばリザーブドインスタンスの導入といったすでに利用中なものもあります。本記事では、昨年度下期に実施した以下の3つ、特にストレージの最適化に焦点を当てて紹介します。

コスト分析と監視 ストレージの最適化 リソースの削除や停止　（本記事では割愛） コスト分析と監視: コストが高い要素の把握 「推測するな、計測せよ」という格言があるとおり、パフォーマンスのみならずコストについても、まずは実測されているデータに注目するのが第一です。コストは自動的にAWS側で計算されているため、そのコストの内訳を確認するのが初手になります。

ストックマークでも、コストを定期的に確認しています。本記事では、一定のインパクトのあった S3 のコスト削減について紹介していきます。

ストレージの最適化 今回のコスト削減では、クラウドストレージとして利用していた AWS S3(Simple Storage Service) のストレージクラスを AWS S3 Glacier へと変更しました。

Glacier はアクセスが遅い、という欠点があるもののコストは非常に安価です。そこで、ユースケースがハマれば、コスト削減につながる有力な手段になり得ます。

もちろん、結論だけ切り取ってしまえば、非常に簡単な処理であるため「単にちょっとした変更をするだけでは？」とお考えになるかもしれません。しかし、現実には S3 に蓄積しているデータを活用する業務フローがいくつかあるため、既存業務にインパクトを与えない、もしくは与えたとしても問題のない方法で移行する必要があります。

コスト試算時の注意点 次に移行に関わる作業・影響調査に着手する前に、 Glacier に移行時のコストを試算しています。試算の結果、一時的にコストが増えるものの3ヶ月でペイしそう、と分かってきました。

詳細な金額は掲載していませんが、試算コストのイメージがわかる画像を以下に載せておきます。

AWSの移行前後のコスト試算イメージ なお、試算時にはオブジェクト数やメタデータも考慮に含めてください。利用タイプによってはコストに効いてくる可能性があります。

ストレージクラスの変更に伴う影響調査 コスト削減につながることがわかったため、次はストレージクラスの変更に伴う実影響を把握しにいきます。ここは、実際にS3を利用している各メンバーへのヒアリングや、S3を利用しているプロダクトコードの調査といった地道な作業が必要になります。

単純に開発メンバーだけに閉じていれば簡単ですが、実際にはお客様からの問い合わせ起点で、過去のデータを確認したいケースもあるため、そんなに簡単ではありません。今回は、実際にお客様対応をしているメンバーに確認して、「（過去の対応履歴から）1ヶ月あれば十分」と判断できました。

実際の移行 ストックマークではクラウドインフラの管理に、 terraform を活用しており、変更は非常に簡単です。公式ドキュメントにあるように、 “storage_class” に “GLACIER” を設定し、必要な日数 “days” に数値を設定すればOKです。

なお、移行時には verisoning にも留意ください。（設定されていないと期待どおりに動かないことがあります）

今後に向けて コストの最適化は、ワンショットで終わるものではなく、継続的にふりかえりしながら進めていくのが効果的であると考えています。実際に、プロダクトの作りとしてキャッシュをさらに上手く活用して AWS lambda の実行回数を減らすといった改善の余地も見えています。

現時点で、もっとも ROI の高い活動を見極めた上で、各チームがコストに責任を持って自律的に最適化していきたいと考えています。 1