私たちは複数のノードを持つ Jenkins サーバーを実行しています。時間が経ち、インスタンスにプロジェクトが追加されるにつれて、複数の問題が発生しています (解決できる人数が少なすぎるため、これは別のトピックです)。
本当に心配なのは、サーバーとして使用する VM のサイズです。保存されるデータは 10 TB を超えており、今後さらに増える一方です (数年または数十年後に成果物にアクセスする必要があるため)。
現時点での私の疑問は、一般的に、こうした大規模な設備について経験のある方がいて、適切な処置を施さなかった場合にシステム全体に何が起こる可能性があるのか、また、今後どのような対策を講じるべきなのかについて、概算を教えていただけるかどうかです。
ここからどこへ向かうのかは不明です。経験豊富な人ならどうするか、意見を聞きたいだけです。
答え1
キャパシティ プランニングには、現在のやり方でどれくらいのコストがかかるかを組織に伝えることも含まれます。
今後 1 年程度で必要な容量を見積もります。少し切り上げ、75% の使用を計画すると少し余裕ができます。使用可能な容量だけでなく、1 つの LUN/ファイル システム/ストレージ アレイの最大サイズを超えることで予想されるコストも追加します。さらに、冗長ストレージとバックアップのコストも追加します。
コストの低い代替案を提供します。
「古いビルドを破棄する」は、保持を制御する Jenkins オプションです。実際の要件は、価格が判明したときに明らかになる場合があります。ただし、多くの組織は IT 料金を直接支払わないため、ビジネス ユニットは気にしない可能性があります。
古いアーティファクトをどのくらい前にリクエストできるかを話し合います。数日で取得できるということは、コールド ストレージ層に保管できることを意味します。バックアップ テープは、オンライン システムよりもはるかに安価です。また、異なるメディアを使用した別のバックアップ システムを使用すると、データが「数十年」存続する可能性が高まります。40 年前のデータを保守するためにハードウェアと人材を用意しておくと、何十年も費用がかかる可能性があるかを調べます。
出力がどの程度再現可能かを調べます。すべての入力がバージョン管理されており、出力が一貫している場合は、出力を長期間アーカイブする必要がない可能性があります。ただし、これには規律ある手順が必要です。特にソフトウェアを構築する場合、出力を決定論的にすることは容易ではありません。