なぜビルドサイズがそんなに心配なのですか?


8

「ビルド/スラッグのサイズが大きい」とよく聞かれます(人々からだけでなく、有益なCLIからも)。これは特に、ビルドのサイズが0.5〜2 GBの場合に当てはまります。

なぜ(またはどのような状況で)ビルドサイズがこのような懸念事項なのですか?

注:私が尋ねる理由は、ストレージやコンピューティングなどのリソースが以前に比べて比較的安価であると考えているためです。したがって、どちらかと言えば、ビルドサイズは以前ほど問題にはならないと思います


ビルドの頻度、ビルドされているさまざまなプロジェクトの数、ビルドしているブランチの数、保持しているビルドの数(不良リリースの復帰を可能にするため、またはおそらく監査者のため)を確認する必要があります。それを乗算して、ディスク容量だけでなくネットワーク帯域幅も取得します。たとえば、200MBビルド* 20マイクロサービス* 1日あたり5ビルド= 20GB /日。年間200日を構築する場合、それは4TB /年です。ネットワークとディスクについては、開発者がWiFi経由でダウンロードし、小さなSSDに保存することも考慮してください。
BMitch

回答:


11

懸念としてビルドサイズの問題を提起した場合、通常は「サイズが大きいため、保存するのにコストがかかります」という問題ではありません。

大規模なビルドの主な問題は次のとおりです-

  • 発送時間の増加。大きな場所を頻繁に移動するのは時間がかかります。
  • 大きなアーティファクトに頻繁な変更を加え、大きな保持期間を設定すると、そのようなアーティファクトの保存にコストがかかり、Dockerイメージなどの階層化されたアーティファクトを使用するとコストが低くなります。
  • このような大きなアーティファクトの作成には、通常、非常に小さなアーティファクトを作成するよりも時間がかかります。小さなアーティファクトを作成するプロセスの自動化には時間がかかる場合がありますが、迅速なフィードバックを可能にするために、繰り返し可能な自動化は可能な限り短くする必要があります。
  • 障害からの回復(構成によって異なります)は、アーティファクトが大きいほど時間がかかることがあります。特に、障害のある新しいアーティファクトの代わりに古いアーティファクトを再適用する必要がある場合はそうです。

私は4つのdevopsメトリックをサブスクライブします。

  • 変更のリードタイム-短縮
  • 展開頻度-頻度を増やす
  • サービスを復旧する時間-短縮
  • 失敗率を変更-絶対に減らします

通常、大きなアーティファクトはこれらの各メトリックに問題を引き起こし、これらのメトリックはどれも実際にはストレージのコストに実際には関係していません。それは安価であり、時間がかかるためです。


5

Evgenyの回答をさらにいくつかの例で補足します。

ビルドサイズの意味は少し重要かもしれません。

  • 構築するアーティファクトのサイズ(個別に、またはそれらを組み合わせたサイズ)の場合-これらの操作にサイズ制限があり、それらを超えると、アーティファクトの格納または使用/展開操作で問題になる可能性があります。たとえば、Google App Engineアプリにはこのようなデプロイ制限があり、到達したデプロイが失敗する場合は、Google App Engineへのデプロイ時のエラーを参照してください。

  • ビルドを実行するワークスペースのサイズである場合、ワークスペース管理の観点から問題になる可能性があります。2Gでも重要な場合があります。たとえば、RAMが少ないマシンのRAMファイルシステムでビルドしている場合です。しかし、一部のビルドはもっと大きくなる可能性があります-(ほとんどのサーバーディスクが1T未満の場合)500G以上のワークスペースを処理する必要がありました。

ビルドがCI / CDパイプラインの一部である場合、ビルドサイズが大きいほど、パイプラインの実行時間は長くなります(実際のビルドを実行し、該当する場合は、アーカイブ、テストのためにデプロイ、失敗した場合の分析、クリーンアップ、等)-あなたの全体的な開発が遅い/リスクが高い/コストがかかるかもしれません。

ハードリミットに達した場合は、クリエイティブに対処する必要があります(常にシンプル/可能であるとは限りません)。それが単なるパフォーマンス/コストヒットの場合は、それを受け入れてそれと共存するか、部分的または段階的に対処するかを選択できます。

以下を区別することは価値があります。

  • 肥大化したビルド-サイズが不必要に大きくなった場合-不要な部分をドロップすることで問題を修正できます
  • ビルド自体のコンテンツが本当に必要な場合-サイズはそれほど重要ではありません-必要です。アドレス指定する唯一の方法は、いくつかの機能を犠牲にすることによるかもしれません

2

実際に遭遇する非常に具体的な問題を追加します。これは、私たちが現在苦しんでいる悪いアーキテクチャの副作用です。

私たちのビルドは大きく、多くの依存関係をロードする必要があるため、単純にすべてを組み合わせるだけで非常に長い時間がかかります。1つの大きなモノリスではなく、マイクロサービスアーキテクチャへのアプローチとして、ビルドを多数の小さなビルドに分割して久しいはずです。

モノリスのすべてのテストの実行には約45分かかり、当面はCI環境をブロックします。

これは非常に負荷が大きく、時間がかかるため、現在、複数のビルドを互いに並行して実行することは不可能です。

したがって、私の前のポスターがすでにより理論的なレベルで述べているように、これは、大規模なビルドがハードドライブ上により多くのスペースを必要とする以外に、潜在的な(そしておそらく)副次的な影響を示すはずです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.