データの永続化

Last updated
Tags Cloud Server v3.x Server v2.x

ここでは、 CircleCI ビルド内外でデータを永続化する様々な方法を概説します。 ジョブ間およびジョブの内外にデータを移動したり、データを保持して後で使用するには複数の方法があります。 適切なタスクに適切な機能を使用することで、ビルドが高速化し、再現性と効率が向上します。

キャッシュの活用方法

キャッシュのデータ フロー

save_cache ステップで作成されたキャッシュは、最長 15 日間保存されます。

キャッシュにより、異なるビルドにおける同じジョブのデータが保持され、高コストなフェッチ操作のデータを以前のジョブから再利用することができます。 ジョブを一回実行すると、その後のインスタンスでは同じ処理をやり直す必要がないため、実行が高速化されます(キャッシュが無効になっていない場合)。

わかりやすい例としては、Yarn や Bundler、Pip といった依存関係管理ツールが挙げられます。 キャッシュから依存関係を復元することで、yarn install などのコマンドを実行するときに、ビルドごとにすべてを再ダウンロードするのではなく、新しい依存関係をダウンロードするだけで済むようになります。

キャッシュは、プロジェクト内でグローバルに配置されます。 1 つのブランチに保存されたキャッシュが他のブランチで実行されるジョブでも使用されるため、キャッシュはブランチ間での共有に適したデータに対してのみ使用してください。

詳細については、依存関係のキャッシュガイドを参照してください。

ワークスペースの使用

Workspace のデータフロー

ワークスペースは最長で15日間保存されます。

ジョブ内でワークスペースが宣言されていると、ファイルやディレクトリを追加することができます。 追加するたびにワークスペースのファイルシステム内に新しいレイヤーが作成されます。 ダウンストリーム ジョブで必要に応じてこのワークスペースを使用したり、レイヤーをさらに追加することができます。

ワークスペースは異なるパイプラインの実行において共有されません パイプラインの実行後にワークスペースにアクセスできるのは、ワークフローが 15 日以内に再実行された場合のみです。

ワークスペースを使用してワークフロー全体のデータを保持する方法の詳細については、ワークフローガイドをご覧ください。 CircleCI のワークスペースの詳細に関するブログ記事もご覧ください。

アーティファクトの使用

アーティファクトのデータ フロー

アーティファクトは最長で 30 日間保存されます。

アーティファクトは、パイプラインの出力を長期保存するために使用されます。 たとえば Java プロジェクトを使用している場合、ビルドにより多くの場合、コードの .jar ファイルが生成されます。 このコードはテストによって検証されます。 ビルドやテストプロセスがすべて成功した場合は、プロセスの出力( .jar )をアーティファクトとして保存できます。 この jar ファイルは、ファイルを作成したワークフローの終了後も長期間アーティファクトシステムからダウンロードできます。

プロジェクトをパッケージ化する必要がある場合は、.apk ファイルが Google Play にアップロードされる Android アプリを使用して、アーティファクトとして保存することをお勧めします。 多くのユーザーがアーティファクトを Amazon S3 や Artifactory などの全社的な保存先にアップロードしています。

アーティファクトを使用してジョブの完了後にデータを保持する方法の詳細については、ビルドアーティファクトの保存方法を参照してください。

ネットワークとストレージ使用の管理

以下では、ネットワークとストレージの使用量がどのように蓄積されるかを説明しています。最適化やコスト削減方法の検討にお役立てください。

注意: お客様の全体的なネットワーク転送量は、課金対象の使用量を表すものではありません。 特定のアクションによるネットワーク使用が、結果として課金対象となります。 これらのアクションについて、以下に説明します。

ストレージとネットワーク転送の概要

ジョブ内でデータを保持するための操作には、ネットワークとストレージの使用が発生します。関連するアクションは次のとおりです。

  • キャッシュのアップロードとダウンロード
  • ワークスペースのアップロードとダウンロード
  • アーティファクトのアップロード
  • テスト結果のアップロード

上記のアクションを行うジョブを決定するには、プロジェクトの config.yml ファイルで次のコマンドを検索します。

  • save_cache
  • restore_cache
  • persist_to_workspace
  • store_artifacts
  • store_test_results

ネットワーク転送使用(課金対象)が発生するネットワークに関連するアクションは、キャッシュとワークスペースをセルフホストランナーにリストアすることです。

ストレージとネットワーク転送の使用状況の詳細は、プラン > プランの使用状況画面で確認できます。 この画面では以下のことが確認できます。

  • 課金対象となるネットワーク転送使用状況
  • 個々のプロジェクトのネットワークとストレージの使用状況は、プロジェクト タブに表示されます。
  • ストレージのデータとアクティビティは、ネットワーク タブに表示されます。
  • ストレージ総量のデータは、ストレージ タブに表示されます。

個々のステップのストレージおよびネットワーク転送の使用方法の詳細については、以下のジョブページのステップ出力を参照してください。

save-cache-job-output

1 か月の料金の概算方法

組織で、ストレージとネットワーク使用に含まれる GB を超えるランナー ネットワークを使用した場合、課金されます。

ストレージ

使用量はリアルタイムで課金され、一定期間保持されます。ワークスペースとキャッシュは15日間、アーティファクトとテスト結果は30日間保持されます。

日々の使用量から1 か月のストレージコストを計算するには、 Storage(ストレージ) タブをクリックし、組織の月間の割り当て GB を超過していないかを確認します。 超過分(GB-Months/TB-Months)に420クレジットを乗じることで、月の料金を見積もることができます。 計算例:2 GB-Months の超過 x 420 クレジット = 840 クレジット ($.50)。

ネットワーク

使用量から 1 か月のネットワーク コストを計算するには、 Network (ネットワーク) タブをクリックし、組織で超過が発生していないかを確認します。 上記のストレージの場合と同様に、超過分の GB/TB に 420 クレジットを乗じることで月の料金を見積もることができます。 計算例:2 GB-Months の超過 x 420 クレジット = 840 クレジット ($.50)。

GB の割り当ては、CircleCI 外部へのトラフィックにのみ適用されます。 CircleCI 内部のトラフィックには制限はありません。

ストレージとネットワーク転送の使用を最適化する方法

ストレージとネットワークの使用を最大限に活用するために設定を最適化する一般的な方法は複数あります。

たとえば、データ使用量を減らしたい場合、特定の使用方法が保持に値する価値を提供しているか検討してください。

キャッシュとワークスペースの場合、比較が非常に簡単です。キャッシュによる開発 / 計算時間の節約は、ダウンロードとアップロードのコストを上回っていますか?

以下では、アーティファクト、キャッシュ、ワークスペースのトラフィックを減らすことによる、ストレージとネットワークを最適化例について説明しています。

アップロードされているアーティファクトの確認

実際に必要なファイルがわずかでも、store_artifacts ステップが大きなディレクトリで使用されているケースがよくあります。その簡単な対策として、どのアーティファクトがなぜアップロードされているかをご確認ください。

ジョブで並列処理を使用している場合は、各並列タスクが同じアーティファクトをアップロードしている可能性があります。 実行ステップで CIRCLE_NODE_INDEX 環境変数を使用して並列タスクの実行に応じてスクリプトの動作を変更することができます。

大きなアーティファクトのアップロード

テキスト形式のアーティファクトは、非常に低いコストで圧縮できます。

UI テストのイメージや動画をアップロードする場合は、フィルタを外し、失敗したテストのみをアップロードします。 多くの組織では UI テストからすべてのイメージをアップロードしていますが、その多くは使用されません。

パイプラインがバイナリの uberJAR をビルドしている場合、コミットのたびにそれが必要なのかどうかを検討してください。 フィルタを使用して失敗時または成功時のみアーティファクトをアップロードする、または単一のブランチにのみアーティファクトをアップロードすることが可能です。

大きなアーティファクトをアップロードする必要がある場合、ご自身のバケットに無料でアップロードすることが可能です。

未使用または余分な依存関係のキャッシュ

ご使用の言語およびパッケージ管理システムによっては、不要な依存関係をクリアまたは「削除」するツールを利用できる場合があります。

たとえば、 node-prune パッケージは、node_modules から不要なファイル (マークダウン、TypeScript ファイルなど) を削除します。

キャッシュ使用率の最適化

キャッシュの使用率が高く使用率を下げたい場合は以下をお試しください。

  • config.yml ファイルで save_cache コマンドと restore_cache コマンドでキャッシュを使用するすべてのジョブを検索し、キャッシュの削除が必要かどうかを判断する。
  • キャッシュの範囲を大きなディレクトリから特定のファイルの小さなサブセットに縮小する。
  • キャッシュの keyベストプラクティスに従っているかを確認する。
       - save_cache:
         key: brew-{{epoch}}
         paths:
           - /Users/distiller/Library/Caches/Homebrew
           - /usr/local/Homebrew

上記の例は、ベストプラクティスに従っていません。 brew- はビルドごとに変更され、値が変更されていない場合でも毎回アップロードされます。 この方法では結局コストもかかり、時間も短縮できません。 代わりに、次のようなキャッシュ key を選択します。

     - save_cache:
         key: brew-{{checksum “Brewfile”}}
         paths:
           - /Users/distiller/Library/Caches/Homebrew
           - /usr/local/Homebrew

この場合、要求された依存関係のリストが変更された場合にのみ変更されます。 これでは新しいキャッシュのアップロードの頻度が十分でないという場合は、依存関係にバージョン番号を含めます。

キャッシュをやや古い状態にします。 新しい依存関係がロックファイルに追加された時や依存関係のバージョンが変更された時に新しいキャッシュがアップロードされる上記の方法とは対照的に、あまり正確に追跡しない方法を用います。

アップロードする前にキャッシュを削除しますが、キャッシュキーを生成するものはすべて削除してください。

ワークスペースの使用率の最適化

ワークスペースの使用量が多く、減らしたい場合は、config.yml ファイル内の persist_to_workspace コマンドを検索し、ワークスペースを利用するすべてのジョブを探し、パス内のすべてのアイテムが必要かどうかを判断してください。

ネットワーク転送の過剰な使用を減らす

ネットワーク使用量を減らしたい場合、次のことをお試しください。

  • Runner の場合は、 AWS US-East-1 にクラウドベースのランナーをデプロイします。
  • アーティファクトを 1 度ダウンロードし、ご自身のサイトに保存して処理を追加します。


ドキュメントの改善にご協力ください

このガイドは、CircleCI の他のドキュメントと同様にオープンソースで、GitHub で使用できます。 ご協力いただき、ありがとうございます。