【実践ガイド】Git LFS×AWS S3で実現！スケーラブルなGitリポジトリ構築の極意

皆さん、こんにちは！

Gitを使っていて「重たいファイル」の管理に困っていませんか？リポジトリが肥大化して、クローンやプッシュが遅い…そんな悩みを解決するのが「Git LFS（Large File Storage）」と「AWS S3連携」です。

Git LFSとは？

Git LFSは、サイズの大きいファイルをGitリポジトリ本体から切り離し、外部ストレージで管理する拡張機能です。これにより、Gitリポジトリは軽量に保たれ、パフォーマンスが向上します。リポジトリにはLFSが管理するファイルへのポインタのみが保存されます。

なぜAWS S3と連携するのか？

Git LFSはデフォルトでGitLabサーバー内にデータを保存しますが、サーバーのディスク容量には限りがあります。そこで、スケーラブルで堅牢なクラウドストレージであるAWS S3と連携することで、Git LFSの保存先を事実上無限の容量を持つS3バケットに移すことが可能になります。

この連携のメリットは、以下の通りです:

ストレージ容量の心配不要: S3のほぼ無限の容量を活用できます。
GitLabサーバーの負荷軽減: 大規模なLFSデータがサーバーから切り離され、ディスクIO負荷を軽減します。
高い可用性と耐久性: S3の堅牢性により、データの安全性が確保されます。

Git LFSとAWS S3連携の概要（ハンズオン含む）

それでは、Git LFSの保存先をAWS S3に変更する手順の概要を見ていきましょう。

既存LFSデータのパスと容量を確認: 現在のLFSデータは /var/opt/gitlab/gitlab-rails/shared/lfs-objects に保存されています。

GitLab設定ファイル (gitlab.rb) の修正: /etc/gitlab/gitlab.rb をバックアップし、以下の設定を追記・変更します。

オブジェクトストレージの有効化とAWS接続情報の設定（プロバイダー、リージョン、アクセスキー、エンドポイントなど）。 【重要セキュリティ注意点】 アクセスキーではなく、IAMロールの使用がセキュリティ上推奨されます。
LFSオブジェクトストレージの有効化とS3バケット名の指定。
Git LFS機能自体の有効化。

# grep -vE '^\s*#|^\s*$' /etc/gitlab/gitlab.rb
external_url 'http://testgitlab.local'
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
'provider' => 'AWS',
'region' => 'ap-northeast-1',  # 東京リージョンなどに応じて変更
'aws_access_key_id' => 'AAAAAAAAKKKKKKKK1111',
'aws_secret_access_key' => 'AAAAAAABBBBBBBCCCCCCCDDDDDDDEEEEEEEFFFFF',
'endpoint' => 'https://s3.ap-northeast-1.amazonaws.com'
}
gitlab_rails['object_store']['objects']['artifacts']['enabled'] = false
gitlab_rails['object_store']['objects']['external_diffs']['enabled'] = false
gitlab_rails['object_store']['objects']['lfs']['enabled'] = true
gitlab_rails['object_store']['objects']['lfs']['bucket'] = 'lsf-test-**********-backet'
gitlab_rails['object_store']['objects']['uploads']['enabled'] = false
gitlab_rails['object_store']['objects']['packages']['enabled'] = false
gitlab_rails['object_store']['objects']['dependency_proxy']['enabled'] = false
gitlab_rails['object_store']['objects']['terraform_state']['enabled'] = false
gitlab_rails['object_store']['objects']['ci_secure_files']['enabled'] = false
gitlab_rails['object_store']['objects']['pages']['enabled'] = false
gitlab_rails['lfs_enabled'] = true

設定のリロード: gitlab-ctl reconfigure コマンドでGitLabをリロードし、変更を適用します。
.gitattributesのプッシュ: Git LFSの対象としたい拡張子を記述したファイル「.gitattributes」をプロジェクトへアップロードします。

※「.pdf」「.pptx」「.iso」を除外する場合
```
*.pdf filter=lfs diff=lfs merge=lfs -text
*.pptx filter=lfs diff=lfs merge=lfs -text
*.iso filter=lfs diff=lfs merge=lfs -text# grep -vE '^\s*#|^\s*$' /etc/gitlab/gitlab.rb
```
LFSデータのアップロードと確認: Git LFSでファイルをアップロードし、実際にS3にデータが保存されているか確認します。

アップロードしたパワーポイントファイルにLFSアイコンがついています。

クリックするとDownloadされます。

AWS S3からはこのように見えます。

ご留意いただきたい点

Git LFS をご利用いただく際の注意事項として、LFS の対象となるファイルについては、通常の Git データのように複数バージョンの管理が難しい点にご留意ください。また、通常の Git データと混在しないよう、運用上の整理・管理が必要です。
LFS 対象ファイルは、S3 上ではランダムな文字列を含むファイル／フォルダ名で保存される仕様となっております。 そのため、バックアップ取得後に内容を特定することが困難となり、S3 側でのバックアップ運用に制限が生じます。
LFS を無効にした状態で、大容量ファイル（LFS 除外対象外の拡張子など）を Git に直接プッシュした場合、GitLab サーバのローカルディスクを圧迫する恐れがあります。適切なリソース管理のためにも、利用者間でルールに沿った運用を徹底していただく必要があります。