インフラストラクチャにどれくらい費やしますか? そして、どうすればこれでお金を節約できますか？

プロジェクトのインフラストラクチャにどれくらいの費用がかかるか疑問に思ったことがあるでしょう。 同時に、驚くべきことに、コストの増加は負荷に対して直線的ではありません。 多くの事業主、ガソリンスタンド、開発業者は、自分たちが払いすぎていることをひそかに理解しています。 しかし、正確には何のためにあるのでしょうか？

通常、コストの削減は、単純に最も安価なソリューション、AWS プランを見つけるか、物理ラックの場合はハードウェア構成を最適化することに帰着します。 それだけではありません。実際、神が望むように、誰でもこれを行っています。スタートアップについて話している場合、これはおそらく、多くの頭の痛い問題を抱えている一流の開発者です。 大きなオフィスでは、この問題は CMO/CTO が対応し、場合によっては部長が会計責任者とともに個人的に問題に関与することもあります。 一般に、十分な「コア」な懸念事項を持っている人々です。 そして、インフラ関連の料金が上昇していることが判明しましたが、それに対処する時間がない人々がそれに対処しているのです。

オフィス用のトイレットペーパーを購入する必要がある場合は、供給マネージャーまたは清掃会社の責任者が購入します。 開発について言えば、リードと CTO です。 販売 - すべても明確です。 しかし、「サーバー ルーム」とは、RAID 内にもう少し多くの RAM と XNUMX 台のハード ドライブを備えた通常のタワー システムが置かれているキャビネットの名前だった昔から、誰も (または少なくとも多くの) がサーバー ルームを無視していました。実際、容量の購入は特別な訓練を受けた担当者が行う必要があります。

悲しいことに、歴史の記憶と経験は、何十年もの間、このタスクが「ランダムな」人々に移され、最も近い人が質問を拾ったことを示しています。 そしてつい最近になって、FinOps という専門職が市場に登場し、具体的な形を取り始めました。 これは、容量の購入と使用を制御することを任務とする特別な訓練を受けた同じ担当者です。 そして最終的には、この分野における企業のコストを削減します。

私たちは、高価で効果的なソリューションを放棄することを主張しているわけではありません。各企業は、ハードウェアとクラウドの料金に関して、快適に存続するために何が必要かを自ら決定する必要があります。 しかし、多くの企業にとって、その後の使用状況の監視と分析を行わずに「リストに従って」軽率に購入すると、最終的にはバックエンドの「資産」の非効率な管理により、非常に多額の損失が発生するという事実に注意を払わずにはいられません。

FinOps とは

営業担当者が「企業」について息の詰まるような口調で話す、評判の高い企業があるとします。 おそらく、「リストによれば」十数台か XNUMX 台のサーバー、AWS、その他の「ちょっとしたもの」を購入したことでしょう。 これは論理的です。大企業では、ある種の動きが常に起こっています。成長するチームもあれば、解散するチームもあり、隣接するプロジェクトに異動するチームもあります。 そして、これらの動きと「リストベース」の調達メカニズムが組み合わさることで、最終的には次の毎月のインフラストラクチャ請求書を検討する際に新たな白髪が発生することになります。

では、何をすべきか - 根気よくグレーを塗り続けるか、その上にペイントするか、支払いにこれらの恐ろしいゼロが多数表示される理由を解明するか？

正直に言うと、社内での同じ AWS 料金の申請の承認、承認、直接支払いは、必ずしも (実際にはほとんど) 迅速に行われるわけではありません。 そしてまさに企業の絶え間ない動きのせいで、同じ買収の一部がどこかで「失われる」可能性があります。 そして何もしないで立っているのは簡単なことです。 気配りのある管理者がサーバールームに所有者のいないラックに気づいた場合、クラウド料金の場合、すべてがはるかに悲しいことになります。 これらは、代金を支払って数か月間保管される可能性がありますが、同時に、それらを購入した部門の誰も必要としなくなりました。 同時に、隣のオフィスの同僚たちは、頭だけでなく他の場所でもまだ白髪になっていない髪を引き抜き始めます。彼らは、n 週目でほぼ同じ AWS の料金を支払うことができませんでした。切実に必要とされています。

最も明白な解決策は何ですか? そう、困っている人に手綱を渡せば、みんな幸せになるのです。 しかし、水平方向のコミュニケーションが必ずしも十分に確立されているわけではありません。 そして、XNUMX番目の部門は、どういうわけか実際にはこの富を必要としないことが判明した最初の部門の富について単に知らない可能性があります。

これについて誰が責任を負うのでしょうか？ - 実際には、誰もいません。 これで今のところすべてが設定されています。
誰がこれで苦しんでいますか？ - 以上です、会社全体です。
誰が状況を解決できるでしょうか？ - はい、はい、FinOps です。

FinOps は、開発者と開発者が必要とする機器との間の単なる層ではなく、企業が購入した同じクラウド料金の観点から、どこに、何が、どの程度「存在する」のかを知る人やチームです。 実際、これらの人々は、一方では DevOps、もう一方では財務部門と連携して作業し、効果的な仲介者として、そして最も重要なことにはアナリストとしての役割を果たさなければなりません。

最適化について少し

雲。 比較的安くてとても便利です。 しかし、サーバーの数が XNUMX 桁または XNUMX 桁に達すると、このソリューションは安価でなくなります。 さらに、クラウドにより、サービスとしてのデータベース (Amazon AWS、Azure Database)、サーバーレス アプリケーション (AWS Lambda、Azure Functions) など、以前は利用できなかった多くのサービスを使用できるようになります。 これらはどれも使いやすく、買ってすぐに使えるので、問題ありません。 しかし、会社とそのプロジェクトが雲の中に深く沈むほど、CFO の睡眠は悪化します。 そして将軍が灰色になるのが早ければ早いほど。

実際のところ、さまざまなクラウド サービスの請求書は常に非常にわかりにくいものです。XNUMX つの項目について、お金が何を、どこに、どのように使われたかについて XNUMX ページにわたる説明が届くこともあります。 もちろん、これは楽しいことですが、それを理解することはほとんど不可能です。 さらに、この問題に関する私たちの意見は唯一のものではありません。クラウド アカウントを人間のアカウントに移行するには、たとえば次のようなサービス全体が必要です。 www.cloudyn.com または www.cloudability.com。 誰かがわざわざ請求書を解読するための別のサービスを作成した場合、問題の規模はヘアカラーのコストを超えています。

では、この状況で FinOps は何を行うのでしょうか。

• クラウド ソリューションがいつ、どのくらいの量購入されたかを明確に理解できます。
• これらの容量がどのように使用されるかを知っています。
• 特定のユニットのニーズに応じてそれらを再配布します。
• 「そうなるように」は買わない。
• そして最終的にはお金の節約になります。

良い例は、データベースのコールド コピーのクラウド ストレージです。 たとえば、ストレージを更新するときに消費されるスペースとトラフィックの量を削減するために、アーカイブしますか? 確かに、状況は XNUMX つの特定のケースでは安いように見えますが、そのような安い状況全体が後でクラウド サービスの法外なコストにつながります。

または別の状況: ピーク負荷に陥らないように AWS または Azure で予約容量を購入した場合。 これが最適な解決策であると確信できますか? 結局のところ、これらのインスタンスの 80% がアイドル状態であれば、Amazon にお金を提供していることになります。 さらに、そのような場合に備えて、同じ AWS と Azure にはバースト可能なインスタンスがあります。ツールを使用してピーク負荷の問題を解決できるのに、なぜアイドル状態のサーバーが必要なのでしょうか? または、オンプレミス インスタンスの代わりに、予約済みインスタンスに注目する必要があります。これらのインスタンスははるかに安価で、割引も提供されます。

ちなみに割引については

冒頭で述べたように、調達は多くの場合誰でも行われます。彼らは最後のものを見つけて、どういうわけか自分でそれを行います。 ほとんどの場合、すでに忙しい人が「極端」になり、その結果、人が何をどのくらいの量で購入するかを迅速かつ巧みに、しかし完全に独立して決定する状況が発生します。

ただし、クラウド サービスの営業担当者とやり取りすると、容量の卸売購入に関して、より有利な条件を得ることができます。 無言で一方的な登録の車からはそのような割引を得られないことは明らかですが、本物の営業マネージャーと話をした後は燃え尽きてしまうかもしれません。 あるいは、現在割引を受けている商品を教えてくれるかもしれません。 役に立つこともあります。

同時に、AWS や Azure では光がくさびのように収束しなかったことを覚えておく必要があります。 もちろん、独自のサーバー ルームを組織することに疑問の余地はありません。しかし、大手企業が提供するこれら XNUMX つの古典的なソリューションに代わるものがあります。

たとえば、Google は企業に Firebase プラットフォームを導入し、企業は同じモバイル プロジェクトをターンキー ベースでホストできるようになりましたが、これには急速な拡張が必要になる場合があります。 このソリューションを例として使用すると、ストレージ、リアルタイム データベース、ホスティング、クラウド データ同期を XNUMX か所で利用できます。

一方、モノリシックなプロジェクトについて話しているのではなく、その全体について話している場合、一元化されたソリューションが必ずしも有益であるとは限りません。 プロジェクトの存続期間が長く、独自の開発履歴があり、対応する量のデータがストレージに必要な場合は、より断片的な配置を検討する価値があります。

クラウド サービスのコストを最適化するとき、ビジネス クリティカルなアプリケーションについては、会社に継続的な収益をもたらす、より強力な料金を購入できることに突然気づくかもしれません。 同時に、開発の「遺産」、古いアーカイブ、データベースなどを高価なクラウドに保存することが解決策になります。 結局のところ、このようなデータには、通常の HDD と追加機能のない中出力のハードウェアを備えた標準的なデータセンターが非常に適しています。

ここでもまた、「そんな大騒ぎをする価値はない」と思うかもしれないが、この出版物全体の問題は、責任ある人々がさまざまな段階で些細なことを無視し、より便利で早いことをしているという事実に基づいている。 それが、結局、数年後には、まさに恐怖の体験談を生み出すことになるのです。

その結果は？

一般に、クラウドは優れたものであり、あらゆる規模の企業にとって多くの問題を解決します。 しかし、この現象の新しさは、私たちがまだ消費と管理の文化を持っていないことを意味します。 FinOps は、クラウドの力をより効果的に活用するのに役立つ組織の手段です。 重要なことは、このポジションを銃殺隊のようなものにしないことです。銃殺隊の任務は、不注意な開発者を手で捕まえて、ダウンタイムを「叱る」ことです。

開発者は会社の資金を数えるのではなく、開発する必要があります。 したがって、FinOps は、購入プロセスとクラウド容量の廃止または他のチームへの移管プロセスの両方を、すべての関係者にとってシンプルで楽しいイベントにする必要があります。

出所： habr.com