皆さん、こんにちは。ソニー・ミュージックエンタテインメントのクラウドエンジニア、二十五時です。この記事のテーマはずばり「AWSのコスト最適化」。多くのシステム担当者が日々の開発などに追われてコスト最適化に集中できない中、私たちがどのようにこの課題に取り組んでいるか、何を大切にしているのかをお伝えできればと思います。
CFMはコスト最適化のための有用なツール
コスト最適化に際し、何より大切なのが現状や施策の効果に対する客観的な分析・評価です。私たちはこれにAWSの「CFM（Cloud Financial Management）」を利用しています。CFMは、AWSのコスト最適化支援プログラム「AWS コスト最適化フレームワーク」で提供されるサービスの一つで、専門の分析チームがAWS Cost Explorerのデータなどを元に、適切なコスト最適化計画を提示してくれるというもの。この際、実施しようとしている個々の施策に、どれほどの効果が期待できるかもレポートしてくれるため、どこから手をつけていいのかわからない場合などにとても役立ちます。
なお、我々はこれを社内で実施してきたコスト改善活動の「答え合わせ」に利用。私の所属部門ではBtoC向けサービスを中心に約50のAWSアカウントを運用しているのですが、その中でも特に利用料の高い3つのアカウントと、長期間コスト最適化を行ってきた3つのアカウントに対して、CFM分析を依頼しました。
結果、利用料の高い3つのアカウントに対しては、まさに社内で改善項目として挙げていた箇所がレポートされた形となり、改善活動の後押しになりました。また、コスト最適化を行ってきた3つのアカウントについては、現在の手法で限界まで最適化されていることがわかり、それまでの取り組みが正しかったことが証明されています。
CFMの使い方としてはちょっと変化球的ではあるのですが、こういう使い方もあるよということで紹介させていただきました。
システム部門だけでコスト最適化はできない
ここからは、我々がコスト削減を行うに際して、大切にしていることを大きく2つ紹介したいと思います。1つ目は、コスト最適化は「サービスオーナーや営業担当者も巻き込んで行う」ことです。
サーバー代が高いと言われても、システム担当者だけでリソースの削減を判断・実施することはできません。そこでサービスオーナーや営業担当者をしっかりと巻き込んでいくことが大切になります。しかし、彼らはシステムの専門家ではありませんから、システム構成など技術的な議論については他人ごとになってしまいがちです（逆にシステム担当者はサービスの運用について意識が薄いことが多い）。
彼らを巻き込むコツは、議論を技術ではなくコストの側面から行っていくこと。何に、どのように費用が発生しているのか、すなわちサービス、システムのコスト特性の理解をシステム部門以外の人にも説明し、理解してもらうことで、よりコストセーブした運用につなげることができるようになります。
例えば、あるサービスにおいて、イベント時のサーバー増強が日単位で行われていたことがありました。しかし、実際にアクセスが集中するのはせいぜい最初の5分から長くて１時間で、それ以外の時間はサーバー代が無駄に。これは、営業担当者がクラウドの利用料が時間単位・分単位で課金されることを知らず、1日を最低単位として申請していたことが原因です。この事例ではシステム担当者がAWSの課金体系を営業担当者に説明し、以降、サーバー増強依頼を日単位から時間単位に改めることで利用料を大幅に削減することに成功しました。
また、別のケースでは、サービスオーナーとしてもコスト削減を希望しており、サービスの状況と合わせて会話をする中で、一定のサービスダウンリスクを許容してもらってランニングコストを半分に下げたというケースもあります。このケースも、あとから柔軟に台数を変更することが可能なクラウドだからこその、サービスのフェイズに合わせて柔軟に対応できたケースかと思います。
どちらの事例でも、システム部門でクラウドを使っていく内に体感的にも理解していく部分であり、クラウドの一番のメリットとも言える「いつでもリソースが追加できること」をサービスオーナーに伝えたという点がポイントです。
システム部門やエンジニアからすると当たり前なことかもしれませんが、サービスオーナーにとって、サーバー調達や、リソース追加のイメージは、まだまだ物理的なサーバーだった頃の運用イメージがあることも多いかなと感じます。
オンプレミスと異なり、日々の状況に合わせてコスト最適化ができるクラウドでは、システム部門だけではコスト最適化はできません。積極的にサービスチーム全体を巻き込んでいくことで、ちょっとした認識合わせや、説明だけでもコスト削減につながる可能性があります。
「ベストプラクティス」の実現はコスト最適化にも有効
2つ目は、「AWS設計のベストプラクティスを常に意識する」ということです。先に紹介したCFM分析では軽減できないコストに「コスト最適化するための作業コスト」があります。
これはまさに今、私が悩んでいることでもあるのですが、社内調整が面倒だったり、一つの最適化作業に膨大な手間が発生したりすることがハードルになりコスト最適化が進まない問題があります。何とか一度はやれても、継続的なコスト最適化活動につながらないなんてこともよくありますね……。
私はこの悩みを解決するヒントが「AWS設計のベストプラクティス」の実現にあると考えています。
例えば、「AWS 設計のベストプラクティスで最低限知っておくべき 10 (+1) のこと」として公開されている中で言われていることを例に上げると下記のようにも解釈できると思います。
| ベストプラクティス | ベストプラクティスで伝えたいこと | コスト削減や最適化の観点からみた効果や考え方 |
|---|---|---|
| スケーラビリティを確保する | システムの利⽤や負荷の増⼤、⽤途の拡⼤などに応じて、柔軟に性能や機能を向上、拡張できるようにする。 | 普段は最低限のリソースで稼働することで、コスト削減につながる。 夜間や営業時間外の停止が可能になる。 |
| 環境を⾃動化する | リソースの作成（プロビジョニング）、終了、設定は可能な限り自動化することで、リクエストに応じたスケーリングや、操作ミスをなくす。 | 不要になったタイミングで余剰リソースを最短で削減する。 人の手が不要なスケーリングにすることで運用コストの削減が可能。 自動化するためには、「正常性確認」が含まれることが多く、インスタンスリプレイスなどの際の運用コストを下げることが可能。 |
| 使い捨て可能なリソースを使⽤する | 動的にプロビジョニングされるクラウドコンピューティングの特性を活⽤するために、各リソースは使い捨て可能な状態にし、環境の自動化などと合わせ、問題がおきた場合には新しいインスタンスに入れ替えるなどを行えるようにする。 | より最適なインスタンスや、新しい世代が出た場合に切り替えが容易になることで、ランニングコストや、運用コストの削減につながる。 AWSの場合、新しい世代のインスタンスは、コストパフォーマンスが高い場合が多い。 また、サービス拡大で変化する負荷特性にも対応しやすくなる。 |
| コンポーネントを疎結合にする | 疎結合とは、システムの構成要素 (コンポーネント) 間の結びつきや、互いの依存関係、関連性などが弱く、各々の独⽴性が⾼い状態のことを表し、 メリットとして、 • 障害ポイントが判別しやすい • 必要な部分のみに変更（アプリ修正、拡張、縮⼩など）を適⽤できる などが挙げられる。 |
サービスとして、必要な機能やリソースのみを増強したり、追加リソースを行えることで、余剰リソースの発生を防止できる。 |
| サーバーではなくサービスで設計する | AWS マネージドサービスには、耐障害性や可⽤性がすでに組み込まれており、テクノロジーをサービスとして活⽤できる | 自身で開発、デプロイしないことにより不要なリソースが発生しにくく、マネージドサービスを使うことにより、運用コストを抑えることが可能。 |
| 適切なデータベースソリューションを選択する | テクノロジーに基づいてワークロードを選択するのではなく、ワークロードに基づいてテクノロジーを選択する。 | データベースは、AWSの中でも比較的費用がかかる部分であるため、適切に選択することでコストを最適化できる。 |
| 単⼀障害点を排除する | 単⼀障害点とは、その箇所が停⽌するとシステムの全体が停⽌するような箇所。SPOF (Single Point of Failure) とも呼ばれる。 全てのシステムは意図しない停止や、故障がある前提で設計することがよいとされる。 |
単一障害点になりうる箇所を理解しておくことで、逆に冗長化レベルを下げるなど、リスクを許容することで、コストを下げる選択ができる箇所を認識できる。 |
| キャッシュを使⽤する | キャッシュとは、⼀度アクセスしたデータを⼀時的に保管し、次回アクセス時よりも⾼速にアクセスする仕組み。 キャッシュを使⽤して、重複するデータ取り出しオペレーションを最⼩限にする。 |
CDNなどを使用したほうがコスト安になることも多く、キャッシュ利用によるサーバーリソースの削減効果がある。 例えば、サービスオーナーがキャッシュについて正しく理解していないなどの場合、説明や会話をすることで、アーキテクチャに大きく手を入れずにコスト最適化が可能。 |
| すべてのレイヤーでセキュリティを確保する | ビジネスリスクの回避・継続性の担保を目的にセキュリティの確保が重要である。 責任共有モデルを正しく理解し、必要な設定を行う。 |
最⼩権限の原則や、デプロイの自動化など、セキュリティを確保するために行う行動が、他の項目における実行のしやすさに繋がり、結果としてコスト最適化しやすい環境が出来上がる。 |
| 増加するデータの管理 | データストアと、データ処理を分離し、保存と用途に応じた適切な方法の選択を可能にする。 | 用途に応じたデータ保存により、データ保存のコストの最適化を行う。 またデータの管理を最適化すると、分析処理を管理画面などから分離するなどにより、定常的なインスタンスの起動コストを抑えることができる可能性もある。 例えば、アクセスログなど、管理画面機能としてイメージされるものを、裏側のリソースとしては疎結合でかつ最適な保存方法にすることにより、システム全体のコストを最適化しながら、要求された機能を実装することが可能になる。 |
注：「ベストプラクティスで伝えたいこと」は私が資料から感じた内容です。
AWS Well-Architected Frameworkの中にも「コスト最適化」という項目がありますが、アーキテクチャを最適化していくことで、コスト最適化そのものが可能であったり、コスト最適化に繋がりやすい環境を作ることが可能であったりすると考えます。
コスト最適化するための作業コストを下げることで、これまで以上にコスト最適化がしやすくなりますし、継続的なコスト最適化活動にもつながります。作業コストも含むTCO（総所有コスト）が下がると、継続的なコスト最適化活動もしやすくなります。これは、他のクラウドサービスにも当てはまる原則です。
まとめ
AWSのコストや、サーバコストはどうしてもシステム部門に対して改善を求められることが多いと思います。そういった中で、システム部門に限らず、AWSの特徴の理解を進めていくことや、AWSに合わせたアーキテクチャにしていくことで、コストを最適化しやすい環境作りができると思います。
単なるサーバーのコストではなく、TCO（総所有コスト）として考えることで、さらにコスト最適化できる可能性が見つけられるかもしれません。
