あなたの会社のサービスはクラウドに毎月いくらかかっているでしょうか？

この問いに答えられる方は、それほど多くはいないかもしれません。なぜならコスト情報は限られた社員のみ閲覧できる場合が多いためです。

note社内でもクラウドコストは一部の権限でしか確認できませんでしたが、現在では誰もが閲覧できるようになっています。

コストを可視化した大きなきっかけは、トラフィックが劇的に増えたことにより約10倍ものクラウドコストがかかるようになったためです。コストの急激な増加を見逃さないためにも、可視化する必要がでてきたのです。

また、Slackにも定期的にコスト情報を流すようにしたことにより、不必要なログを見直すきっかけにもなりました。ログの精度を高めることにより、コストを大幅に削減することができたのです。

急成長を遂げるnoteでは、いかにしてコストを削減するのかという問題に立ち向かっている最中です。今回はCTOである今さん、SREチームの飯野さんと中村さんにクラウドとコストの関係についてお聞きしました。

サービス成長の裏で起きた、クラウドコストの高額化

ー 2020年はnoteのトラフィックが急増しましたが、ここまで伸びることは予想していましたか？

今さん：いえ、完全に予想外でした。2020年に入ってMAUが一気に3倍以上伸びたときに、「トラフィックが増大したときクラウドのコストをどう抑えるのか」という対策がほとんどできていないことに気がつきました。初めて直面することも多く、とても苦労しましたね。

中村さん：クラウドのコストが高額化したのは、トラフィック増大に伴ってEC2インスタンス数が増加したことや、RDSインスタンスのスペックをあげたことが要因としてあります。それ以外にもログ系のサービスでも想定以上の課金が発生していました。大量のログをCloudWatch Logsに投げてしまったり、CloudTrailで監査ログがリージョンごとに二重に課金されていたりと。これらが必要以上のコストの増加に繋がっていました。

中村昴 / SRE
株式会社ドリコムにて、ソーシャルゲームタイトルのAWSインフラを担当。2020年9月よりnote株式会社に入社し、現在はSREとしてnote、cakesのインフラ周りの改善を行っている。https://note.com/varu3

飯野さん：こういった問題がすぐに判明しなかったのは、長年サービス運営を続けるなかでクラウドサービスの運用担当者間で設定の意図が伝わっていなかったことが原因でした。「過去に誰がなんのために入力したのかわからない設定」や「テスト用に試しに入れた設定」など、本番で必要なのかどうかわからない設定値が増えていってしまったのです。ひと目見ただけではわからないことが多くなってしまっていました。

今さん：クラウドコストが見すごせない金額になってきたため、AWSで設定値を入力をするときのルール化について強化するよう取り組んでいます。クラウドのリソースや設定をTerraformでコード化（IaC）する範囲を以前にも増して拡大しています。

データ処理量が急増したことで言えば、ログ監視に使用しているDatadogの問題もありました。これについては飯野さんとすぐに対策の検討をしましたね。

飯野正之 / SRE
ブイキューブやサイバーエージェント、スタートアップを経て2018年1月noteに入社。SREチームのリーダーとして、noteのインフラを陰から支えている。

※インタビュー記事：いまのnoteは、インフラエンジニアにとってボーナスステージだ

飯野さん：最初はDatadogに転送したログをすべてインデックスする設定にしていましたが、これがあまりよくありませんでした。ログをすべて処理するためデータ量も多くなってしまったのです。現在はインジェストのステップでフィルターをかけて、設定した予算内でのみログがインデックスに乗るように変更しています。

そのため、インデックスに乗らないログというのも発生しうるのですが、そうはならないように事前にログの総量を概算して設定しています。重要でないログは、そもそも送らないようにするといったインフラ側の見直しも行いました。

ログはとても重要なものですが、不要なログはそもそも出力・保存しない、またその見極めをすることがクラウドのコストを削減するうえでは非常に重要だと思います。

今さん：ひとつの設定を見直すことで大きくクラウド側のデータ処理を効率化でき、その結果コストを削減できるということですね。ログが大量になるサービスの場合、そのすべてを流して監視するとその分のコストが料金に跳ね返る。当たり前といえばそうなのですが、ビッグデータ系のサービスを扱うときのいい教訓になりました。

コストを可視化して、会社の意識を変える

ー 急なコスト増加が発生しないために、なにか対策は行っているのでしょうか？

今さん：まずはコストを可視化するところから始めました。万が一設定ミスがあってコストのスパイクがあったとしても、可視化しておけば視覚的に気づくことができるからです。この作業は中村さんにやってもらいました。

中村さん：AWSのコストを可視化するところから始めました。可視化する方法は色々とあるのですが、弊社では誰でも見ることができるダッシュボードサービスとしてRedashを利用しているため、そこにコストを出すようにしました。

これらの結果はSlackにも毎日投稿されるように自動化しています。金額を見ることを強制するわけではなく、全社員に公開することで全員がコストを意識できるようになればいいなと思っています。

今さん：これは本当にありがたかったですね、毎日見てます。実際に可視化してみると他にも削減可能なコストがあることもわかり、少しずつコストを減らしている最中です。順調にいけば月間で100万円以上コストを削減できるかもしれません。

中村さん：ただ、まだ全体のコストしか確認できないという課題があります。いずれは開発チームごとにコストを可視化できるようにしたいと思っています。複数チームがインスタンスを使っている場合に、どのチームのコストなのかわかるようにしたい。

今さん：あとは機能ごとにコストがわかれば最高ですね。たとえばKinesis Firehoseを機能Aと機能Bで使っているときに、どちらが原因でコストが膨れ上がっているのかわかればいいなと。

中村さん：AWS以外の他のSaaSを可視化したいという要望もあるので実現したいです。あとは「前月と今月で○円増えています」といったレポートを自動で作成する仕組みも導入したい。まだまだ課題は山ほどあります。

ただ『コストをみんなが見える状態にする』ということを入社1ヶ月で、スピード感を持って達成できたのは嬉しかったです（笑）。noteはプロダクトの数も限られていますし、今さんや飯野さんのように意思決定者がすぐ近くにいて、すばやく判断してくれたことも要因のひとつだと思います。チーム外との社内調整に時間をかけなくてもよかったので。

コストは悪ではない

ー その他にも現状でコストを削減しようと思っている箇所はありますか？

中村さん：EC2のオンデマンドインスタンスとスポットインスタンスの割合を調整すれば、コストを下げられるかもしれません。

飯野さん：EC2で言えばサーバのコンテナ化を進めている関係で、コンピューティングが安くなる可能性もありますね。ただ、監視用にコンテナのログを飛ばすことになり、外部ストレージを永続化する必要もでてくるため、大幅なコスト削減にはならないかもしれませんが。むしろ、コンテナのログに気をつけないとコストが増える可能性もありますね。

中村さん：今まで以上に、シビアに管理していかないといけませんね。

飯野さん：大量のログがコストのネックになるというのは直近の体験でわかったので、いらないログは捨てるという判断が大事になってくるでしょう。盲目的になんでもログをとるのはコスト的にもよくありませんし、ログにノイズが乗るとそもそものデータとしての利用価値が下がってしまいますし。

中村さん：あとはRDSのクラスタを分けてデータ分割もしていきたいですね。今のままだとnoteのトラフィックとともにコストも増大していくことになるので、DBのパフォーマンス改善もしていかないと。

ー「〇〇円までコストを下げれば成功」というような指標はあるのでしょうか？

飯野さん：ここでいうコストというのは「サービスを適切に運用していくために必要なコスト」ということなので、必ずしも コスト＝悪 ということではないです。サービスにとって必要であればコストは積極的にかけていく必要がありますし、そのために重要なのはいかに無駄なコストを生まないようにするかということだと思います。

今さん：たとえば、SendGridでは大量のメールを送っているため金額も高くなりますが、これは必要なコストですね。自前でメールサーバを作るくらいなら、お金を使ってサービスを使うというわかりやすい例でしょう。

中村さん：運用で人が苦労するのであれば、コストをかけて効果を出したいですね。

今さん：開発の自動化系はまさにそうですね。CircleCIやmablなどの開発支援系サービスはコストをかけていくべきです。

飯野さん：あとは細かい部分で言えば、会社としてエンジニアへの補助なども必要なコストだと思っています。たとえばIDEを経費で買えるとか。

今さん：そうですね。そういったことで開発へのモチベーションが大きく変わるため、大事なコストだと捉えています。

ー 最後になりますが、それぞれ今後どのようにコストに対して取り組んでいきますか？

今さん：SaaS周りの改善はもちろんですが、アプリケーション側からも改善していこうと思っています。言語の変更やコードの改善でサーバの台数を減らすことは可能なので。アプリケーションレイヤーの効率化に興味あるエンジニアも仲間に迎えたいですね。

飯野さん：アーキテクチャの変更へ柔軟に対応できるインフラの仕組みを作っていきたいですね。そのためにも設定した本人しか理解できないという状況を作らない、ゴミを残さないということが重要です。ルール化だったり、仕組み化だったりを進めることで解決できると思いますし、それがコスト削減にもつながっていくと思っています。

中村さん：今後も可視化に焦点を当てていきたいです。エンジニアにしかわからない部分をできるだけ可視化して、社員全員が現状をわかるようにしたい。たとえばパフォーマンス面やアラート周りなど。

noteはアクセス数も扱うデータ量も膨大に増えていくことが予想されるので、パフォーマンスを改善していかなければいけません。またこれらの成果が視覚的にわかるようにして、問題があればそれを迅速に共有できるようにしたいですね。

今さん：SREチームはまだまだやることが山積みなので、もっと応募もきてほしいですね。セキュリティやエッジの最適化に興味がある人は良い体験ができるはずなのでぜひ。

▼noteを一緒に作りませんか？

Text by megaya