クラウドって、何がそんなに高いんですか？

著者 |ヤン・ジェン

制作 | 51CTO テクノロジースタック (WeChat ID: blog)

会社の事業が好調なときは、クラウドのコストは「デジタルの繁栄」の中に埋もれてしまうが、配当が減ると、クラウドの極めて高いコストが経営者を悩ませることになる。これは一夜にして起こる問題ではありません。

このような環境において、企業の焦点は、アプリケーションのパフォーマンスに影響を与えず、インフラストラクチャを可能な限り変更せずにクラウド費用を削減する方法に移っています。

本日の記事では、インフラストラクチャに簡単な変更を加えるだけでコストを 30% 削減する方法のケース スタディを紹介し、クラウド コストが高額になる部分を探ります。

1. 1回の手術で6万ドルが消えた

クラウド コンピューティングによってもたらされるエクスペリエンスは、前例のないものと言えます。数秒でサーバーを生成し、サーバーレス バックエンドとフロントエンドのストレージ バケットを使用して、Web サイト全体をホストできます。このプロセスには、通話回数が制限に達するまで 1 ペニーもかかりません。

しかし、トラフィックが増加し始めると、苦痛が始まります。まるで綱の上を歩いているようだ。無料は一時的なものなので、十分注意する必要があります。操作を間違えると、悪いことが起こります。

クラウド コスト アカウントと銀行カードが一晩で「上限に達した」と通知された企業や開発者に関する恐ろしい話が、オンライン上にたくさんあります。本当に衝撃的です:

上記によって発生したクラウドの請求の一部は、Lambda 関数の呼び出しによるもので、4,500 ドルの料金が発生しましたが、他の請求は、特定のクラウドの指示書に従って実行されたテスト タスクによるもので、3 か月後に 60,000 ドルの請求書が郵送で届きました。

写真

これらは孤立した事例ではありませんが、クラウドを利用するためのコストが高いために人々が単純に、そして無礼にクラウドを放棄したという事実は、ここでは触れないもう一つのスリリングな話です。

2. クラウドがなぜそんなに高価なのか？

問題は、クラウドの効率性、利便性、柔軟性、メンテナンスのしやすさは欲しいが、クラウドの料金が制御不能にならないようにしたい場合、参考になる方法や実践方法はあるかということです。

この法案を見てみましょう:

写真

21,433.21ユーロ。これは、2022 年 10 月に私の会社がステージング環境と本番環境に支払った合計コストです。詳細には、K8s クラスターとクラウド ストレージが目立つように記載されています。

• Kubernetes クラスター 13,743.83 EUR (割引 2,333.84 EUR)
• クラウドストレージ（バケット） 6,124.75 EUR
• SQL データベース 3,237.22 EUR
• この記事では無視されている、その他の小さなコストもあります。

コストは制御不能ではありませんでしたが、Kubernetes クラスターとストレージに多大なコストがかかっていました。

3. K8s クラスターはなぜ高価なのですか?

次に、これら 2 つの部分のコスト生成プロセスを個別に見ていきます。 1 つ目は、本番環境における Kubernetes クラスター自体のコストの内訳です。次のグラフは、3 つの主な原因を示しています。

コンピューティング エンジンの N1 定義済みインスタンスは、コア/RAM、スポット プリエンプティブ インスタンス、およびリージョン間ネットワーク送信コストが最も高くなります。

写真

ステージング環境と本番環境の料金を示す Google Cloud の請求ページのスクリーンショット

ヒント: 馴染みのない方には、これらのタグについて説明が必要かもしれません。

• N1 定義済みインスタンス コア/RAM は、Kubernetes クラスターで毎日使用されるノードです。 N1 はノード タイプです。
• スポット プリエンプティブ インスタンス コア/RAM は、非同期タスクを実行するために生成するノードです。プリエンプティブとは、これらのノードに対して支払う料金が少なくなることを意味しますが、可用性は保証されません。
• ネットワーク出力インターゾーンは、ネットワーク経由でアベイラビリティーゾーン (AZ) 間で移動するデータです。リージョン AZ のノードでホストされている API があると仮定します。その API が AZ B のノード内の別の API にクエリを実行すると、AZ B から AZ A へのデータに対して課金されます。

問題 1: Kubernetes の期待を管理していない

それから私たちはそれらを一つずつ取りました。最もコストの内訳が最も高い N1 定義済みインスタンス コア/RAM から始めます。

問題の根本は、Kubernetes に新しいノードをスケーリングする方法を指示したかどうかにあります。

N1 定義済みインスタンス コア/RAM に関しては、現在、使用量に基づいて自動的にスケーリングされる n1-standard-8 ノードを使用しています。修正を行う前に、Kubernetes が新しいノードをスケールアウトする方法を理解することが重要です。

Pod を定義するときは、Kubernetes に 1 つのことを伝える必要があります。それは、Pod が適切に動作するために必要な RAM と CPU の量です。これは Kubernetes ではリクエストと呼ばれます。

API のポッド A が正常に動作するために 400mo RAM と 0.2 vCPU が必要であり、Kubernetes ノードの容量が 30 GB RAM と 8 vCPU であると仮定します。 8 個の vCPU を 0.2 個の vCPU で割ると 40 個のポッドになり、30,000mo を 400mo で割ると 75 個のポッドになるため、このノードには 40 個のポッドを収容できます。

したがって、K8s クラスターの場合、予想されるリソースと未使用のリソースを明確にすることは技術的な仕事です。

要求されたCPUとノードの実際の容量を表すスキーマ

問題2: 設定ファイル内の悪魔の詳細: CPUとメモリの値

8 vCPU ノードで 0.2 vCPU を要求するポッドが 40 個ある場合、それらのポッドが 4 vCPU しか使用していないにもかかわらず、Kubernetes はノードがいっぱいであると見なし、新しいノードを起動します。

適切な構成により、ノード数によって発生する支払いを大幅に削減できます。同時に、要求されたリソースに応じてノードが拡張されます。拡張中にリソースの過剰な浪費を避けるにはどうすればよいでしょうか?

これには、Kubernetes yaml 構成ファイルを詳しく調べて、何を変更できるかを確認する必要があります。

最初に行ったのは、ポッドの yaml 定義と Grafana の実際のリソース使用量を比較することでした。以下に示すように、Grafana を使用すると、リクエストと実際の使用量を簡単に比較できます。

写真

1 つのポッドを実行している場合の 1 つの API に対する Grafana RAM 要求/使用量 (スクリーンショットはこの記事の執筆時点で撮影されたもので、構成の更新後です)。

このグラフでは、平均 RAM 使用量は 0.1go であるのに対し、要求された RAM は 0.4go であることがわかります。

この API の YAML 構成と比較すると、同様のことがわかります。

IAC リポジトリのデプロイメント.yaml ファイルからの変更のスクリーン キャプチャ

実際の API 使用量に近づけるために、要求されるメモリと CPU の値を大幅に削減しましたが、それでもまだ慎重な姿勢を保っています。さらに削減することができます。当社ではすべてのサービスにこのプロセスを実装しています。

問題3: 1つのサービスに対してデフォルトで実行されているポッドが多すぎる

たとえば、このデプロイメントでは少なくとも 3 つの Pod を実行します。つまり、夜間に API がほとんど呼び出しを受けなくても、3 つの Pod が実行されることになります。

そこで、各サービスを調べて、ポッドレプリカの最小数を 1 つに減らしました (安全な範囲で)。

写真

これらの変更により、N1 定義済みインスタンス コア/RAM のコストは 4,235.43 EUR から 1,973.28 EUR に増加しました。

質問4: 地域間ネットワーク出口におけるデータ交換料金

この点は非常に注意が必要であり、ネットワーク可用性ゾーン間でのデータ交換には多額のクラウド料金が発生します。

当社には 40 を超えるマイクロサービスがありますが、幸いなことに、マイクロサービスはうまく機能しており、マイクロサービス間の直接通信はほとんどありません。ただし、すべてのマイクロサービスの前に GraphQL ゲートウェイがあります。このゲートウェイは多くの呼び出しを受信します。

著者はこの問題を次の 2 つの方法で解決しました。

1 つ目は、フロー ログを使用して、返されるデータに関してどの呼び出しが最も大きいかを追跡することです。

2 番目のアプローチ、そして私たちが最も自信を持っていたアプローチは、どの API が最も多くの呼び出しを受けたか、その API 内のどのエンドポイントがキャッシュに適しているかを確認することでした。すでに Redis を pub/sub ソリューションとして使用しているため、キャッシュとしても簡単に使用できます。

いずれにせよキャッシュが必要であり、すべてがすでに設定されていたため、最初にキャッシュを実行することにしました。しかし、これはまだ間違いです。問題をキャッシュ システムに移動しただけであり、データが大きすぎるのはコードのせいなのか、呼び出しが多すぎるせいなのかがわからないからです。

Kiali を使用すると、どの API が最も多くの呼び出しを受けているかを確認できます。

写真

この情報とアプリケーションの機能的側面に基づいて、どのエンドポイントをキャッシュするかを決定します。この方法では、GraphQL ゲートウェイはキャッシュを実装し、データを取得するためにサービスに HTTP 呼び出しを行う必要がなくなるため、Egress コストが削減されます。

最初のソリューションを実装するだけで、輸出コストを 2,712.34 ユーロから 1,095.19 ユーロに削減することができました。

残念ながら、大量のデータを転送する残りの HTTP 呼び出しを追跡するための 2 番目のソリューションはまだ実装されていません。

4. クラウド ストレージはなぜ高価なのでしょうか?

そうです、クラウド ストレージのコストの大部分は、ストレージ バケット内で転送されるデータのコストではなく、容量自体に関連しています。解決策は当然簡単です。削除するだけです。

私の会社のアプリケーションはユーザーからビデオを受信し、それらを正規化して、元のバージョンと正規化されたバージョンの両方を保存します。その後、ビデオはクライアントによって編集され、検証（または拒否）されます。

これまでにコンテンツを削除したことはありません。当社は長年にわたりユーザーの未使用のビデオを保存しており、そのデータは 100 TB を超えます。そこで、法務チームと製品チームからの意見を参考に、データベースに対して動的パラメータ（「ビデオ拒否」など）を照会し、それらのファイルをアーカイブする CRON ジョブを設定しました。

回復不可能なエラーを防ぐために、まず GCP (S3 では Glacier) でファイルのストレージ クラスを「アーカイブ」に切り替え、ライフサイクル ルールを使用して 6 か月後にファイルを完全に削除しました。

2022年10月の本番環境ストレージコスト

2023年9月の本番環境ストレージコスト

何を削除するかを慎重に決定する必要があるため、これはまだ進行中のプロセスですが、運用時のストレージ コストを 4,754.85 ユーロから 3,029.93 ユーロに削減することができました。

5. 一時的な環境にかかるコストも膨大

ここで、見逃してはならないもう 1 つの詳細があります。つまり、一時的な環境によって発生するコストも膨大であるということです。 2022 年 10 月には、本番環境の約 4 分の 1 に相当するステージング環境に 4,059.25 ユーロを支払いました。

本番環境とステージング環境のコストの内訳

一時的な環境におけるコストの内訳

コストを削減するために、次の 4 つの簡単な手順を実行しました。

営業時間外は環境を閉鎖しました。残念ながら、私たちは国際的なチームなので、平日の夜にはあまり時間がありません。

Kubernetes クラスターをスケールダウンし、すべてのデプロイメントの最小ポッド サイズを 1 に設定し、一部の重要なサービスを除いて、1 つのポッドを超える自動スケーリングを防止しました。

Cloud Storage バケットにライフサイクル ルールを追加し、6 か月以上経過したものをすべて削除しました。データベースをクリーンアップし、以前の開発者や QA によって使用されなくなったデータを削除しました。

写真

これら 4 つの簡単な手順に従うことで、ステージング環境の月間費用を 2,500 ユーロ以上削減できました。

6. クラウドコストをさらに削減するためのアイデア

クラウドコストを削減する他の方法はありますか?

もちろん、上記の観点から、コストをさらに削減する計画についてはすでにいくつかのアイデアがあります。

（1）Kubernetesリクエストを微調整して、マイクロサービスが実行する必要があるものをより正確に把握します。

（２）当初計画に従って残りの輸出コストを追跡する

（3）アーカイブcronに新しいルールを実装し続け、バケットから不要なファイルを削除してください。

（4）ビデオ処理をCPUからGPUに切り替える（GPUの方が高速で安価であることがわかりました）。

（５）運用中のSQLデータベースをクリーンアップし、アーカイブ可能なTBレベルのイベントデータを保存します。

2022 年 10 月と 2023 年 10 月を比較すると、月額 6,369.75 ユーロ、約 30% の節約となり、さらに節約できると確信しています。

7. 最後に

クラウド コストを追跡し、最適化することは、非常に困難ですが、やりがいのある作業です。クラウド エンジニアやアーキテクトにとって、クラウド料金を支払うのは彼ら自身ではなく会社です。

しかし、言うのは簡単ですが、実行するのは難しいのです。個人プロジェクトでクラウドの無料レベルを使用することと、1 日に何百万もの呼び出しがある実稼働環境でクラウドを使用することは、まったく異なるものです。

この記事では、本番環境での K8s クラスター、クラウド ストレージの問題、一時的な環境での不要な費用など、クラウド コストが高額になるいくつかの問題を最初から分析し、解決策と計画を示します。

覚えておいてください: ドキュメントに盲目的に従って展開を構成するのではなく、最初からアプリケーションのライフサイクルを考慮し、クラウド コストが高くなりすぎないように適切な保護対策を講じてください。そうしないと、高額の請求通知が表示されるだけです。

参考リンク: https://alexandreolive.medium.com/how-we-manage-to-reduce-our-cloud-costs-by-25-percents-3f8c26db704a