'스토리지'에 해당되는 글 3건

  1. 2022.01.10 Github의 최대 용량은?
  2. 2021.12.08 AWS 인프라 구축 실습 11회 - EFS
  3. 2020.04.30 Github의 최대 용량을 알고 싶어요
반응형

Github의 최대 용량은?


Github.com 을 많은 사람들이 사용하고 있습니다.

github은 점점 기능을 추가하고 개선을 하면서 여러가지 기능을 제공하고 있습니다.

거기에다 자동으로 버전업(형상관리)를 해주고 있으니 얼마나 편리한지 모르겠습니다.

간단한 text 파일 작성이라든가, markdown 파일 작성, 각종 소스관리가 무척 편리합니다.

그래서, github 이용자는 점점 늘어나고 있습니다.

github project 관리 기능

그런데, 단지 텍스트 파일이 아닌 다른 파일들 즉, 이미지나 특정 문서 포맷 파일, 다이어그램 파일 등을

업로드해서 저장하려고 하면 용량이 기하급수적으로 늘어납니다.

이럴 경우에는 내가 사용할 수 있는 용량이 얼마인지 점차 궁금해지고

구글링이나 다음에서 검색해서 찾아보게 되겠죠.

그래서 좀 알아봤습니다. github는 개인의 용량 관리를 어떻게 하고 있을까?

https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-large-files-on-github

위 사이트에 들어가서 확인해보면

큰 파일에 관하여

GitHub는 일반 Git 리포지토리에서 추적할 수 있는 파일의 크기를 제한합니다. 제한을 초과하는 파일을 추적하거나 제거하는 방법을 알아보세요.

파일 크기 제한

GitHub는 리포지토리에 허용되는 파일 크기를 제한합니다. 50MB보다 큰 파일을 추가하거나 업데이트하려고 하면 Git에서 경고가 표시됩니다. 변경 내용이 저장소에 성공적으로 푸시되지만 커밋을 제거하여 성능에 미치는 영향을 최소화할 수 있습니다.

깃허브 블록은 100MB를 초과하는 푸시입니다.

이 제한을 초과하는 파일을 추적하려면 Git LFS(Git Large File Storage)를 사용해야 합니다. 자세한 내용은 "Git 대용량 파일 저장소 정보"를 참조하십시오."

리포지토리에 대용량 파일을 배포해야 하는 경우 파일을 추적하는 대신 GitHub.com에서 릴리스를 생성할 수 있습니다. 자세한 내용은 "대형 바이너리 배포"를 참조하십시오."

Git은 대용량 SQL 파일을 처리하도록 설계되지 않았다. 다른 개발자와 대용량 데이터베이스를 공유하려면 Dropbox를 사용하는 것이 좋습니다.

리포지토리 크기 제한

리포지토리의 크기는 1GB 미만으로 유지하는 것이 좋으며 5GB 미만이 좋습니다. 저장소가 작을수록 복제 속도가 빨라지고 작업 및 유지 관리가 쉬워집니다. 저장소가 인프라에 과도하게 영향을 미치는 경우 GitHub Support로부터 수정 조치를 취하라는 이메일을 받을 수 있습니다. NAT은 특히 공동작업자가 많은 대규모 프로젝트에 유연성을 발휘하기 위해 노력하고 있으며, 가능한 경우 항상 귀사와 협력하여 해결책을 모색할 것입니다. 저장소의 크기와 전체 상태를 효과적으로 관리하여 저장소가 인프라에 영향을 미치지 않도록 할 수 있습니다. github/git-sizer 저장소에서 저장소 분석을 위한 조언 및 도구를 찾을 수 있습니다.


Git 대용량 파일 저장소 정보

Git LFS는 저장소에 파일에 대한 참조를 저장함으로써 대용량 파일을 처리하지만 실제 파일 자체는 처리하지 않는다. Git의 아키텍처에서 작업하기 위해 Git LFS는 실제 파일(다른 곳에 저장)에 대한 참조 역할을 하는 포인터 파일을 만든다. GitHub는 저장소에서 이 포인터 파일을 관리합니다. 저장소를 복제하면 GitHub가 포인터 파일을 맵으로 사용하여 대용량 파일을 찾습니다.

Git LFS를 사용하면 다음과 같이 파일을 저장할 수 있습니다.

https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-git-large-file-storage


저장소 및 대역폭 사용량

Git Large File Storage를 사용하는 모든 계정에는 매월 1GB의 여유 저장 공간과 1GB의 여유 대역폭이 제공됩니다. 대역폭 및 스토리지 할당량이 충분하지 않은 경우 Git LFS에 대한 추가 할당량을 구입하도록 선택할 수 있습니다.

예를들면,

500MB 파일을 Git LFS에 푸시하면 할당된 500MB의 스토리지를 사용하고 대역폭은 사용하지 않습니다. 1바이트를 변경하고 파일을 다시 푸시하면 500MB의 스토리지를 추가로 사용하고 대역폭은 사용하지 않으므로 이 두 푸시에 대한 총 사용량이 1GB의 스토리지와 0대역폭으로 늘어납니다.

LFS로 추적되는 500MB 파일을 다운로드하면 저장소 소유자가 할당한 대역폭 중 500MB를 사용하게 됩니다. 공동작업자가 파일을 변경하고 새 버전을 로컬 리포지토리로 가져오면 500MB의 대역폭을 추가로 사용하여 두 다운로드의 총 사용량을 1GB의 대역폭으로 가져옵니다.

깃허브 액션이 LFS로 추적되는 500MB 파일을 다운로드하면 저장소 소유자가 할당한 대역폭 중 500MB를 사용하게 된다.

스토리지 할당량

데이터 팩을 구입하지 않고 1GB 이상의 스토리지를 사용하는 경우에도 자산이 큰 리포지토리를 클론할 수 있지만 포인터 파일만 검색하고 새 파일을 다시 푸시할 수 없습니다. 포인터 파일에 대한 자세한 내용은 "Git 대용량 파일 저장소 정보"를 참조하십시오.

대역폭 할당량

데이터 팩을 구매하지 않고 월 1GB 이상의 대역폭을 사용하면 다음 달까지 계정에서 Git LFS 지원이 비활성화됩니다.

https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-storage-and-bandwidth-usage

 

반응형
Posted by SB패밀리

댓글을 달아 주세요

AWS 인프라 구축 실습 11회 - EFS

- 사전 준비 사항
1. 인터넷 게이트웨이
2. 보안그룹
   - EC2 : ssh(anywhere), http(anywhere)
   - EFS : nfs(anywhere)
3. VPC : my-vpc
4. 서브넷 : my-subnet-2a
5. EC2 : Amazon Linux 2 AMI, 퍼블릭자동IP활성화,생성스크립트(web), 'web-01'

- 실습과정
1. EFS생성
2. EFS 마운트
3. 재부팅 마운트 유지설정



1. EFS

EFS(Amazon Elastic File System)는 한 번만 설정하면 되는 단순한 탄력적 서버리스 파일 시스템입니다. 
Amazon Elastic File System(Amazon EFS)은 스토리지를 프로비저닝하거나 관리하지 않고도 파일 데이터를 공유할 수 있게 해주는 단순한 1회 설정 방식의 탄력적 서버리스 파일 시스템을 제공합니다. AWS 클라우드 서비스 및 온프레미스 리소스와 함께 사용할 수 있으며, 애플리케이션 중단 없이 온프레미스에 페타바이트 규모로 확장할 수 있도록 구축되었습니다.
EFS는 파일을 추가하고 제거할 때 자동으로 확장되고 축소되며 관리 또는 프로비저닝이 필요하지 않습니다.

출처: amazon tink


EFS는 모든 가용영역의 서브넷에 대하여 파일 시스템을 제공하거나 하나의 가용영역에 제공하거나 온 프레미스 환경의 파일 시스템과 연동할 수 있습니다. 우리는 이 중에서 모든 가용영역의 서브넷에 대하여 파일 시스템을 제공하는 실습을 해보겠습니다.



1.1 EFS 생성

EFS 메뉴로 이동합니다. 파일 시스템 생성 버튼을 클릭하여 생성 과정을 진행합니다.


파일 시스템 생성 창에서 이름은 'my-efs', VPC는 'my-vpc', 가용성은 '리전'으로 선택합니다.

리전으로 설정하게 되면 간략 설명처럼 여러 가용영역에 대하여 파일 시스템을 연동할 수 있습니다.
사용자 지정 버튼을 클릭하면 추가적인 설정이 가능합니다만 실습에서는 기본값으로 생성하도록 합니다.
사용자 지정 버튼에서 설정할 수 있는 것 들 중에서 몇가지 설명을 덧붙였습니다.

수명주기관리
Amazon EFS 수명 주기 관리는 파일 시스템에 대한 비용 효율적인 파일 스토리지를 자동으로 관리합니다. 
이 기능이 활성화되면 수명 주기 관리가 설정된 기간 동안 액세스하지 않은 파일을 Infrequent Access(IA) 스토리지 클래스로 마이그레이션합니다. 수명 주기 관리가 파일을 IA 스토리지 클래스로 이동하면 해당 파일은 무기한 보존됩니다.


성능모드
성능 모드 광범위한 클라우드 스토리지 워크로드를 지원하기 위해 Amazon EFS는 두 가지 성능 모드를 제공합니다. 파일 시스템의 성능 모드는 파일 시스템을 만들 때만 선택할 수 있습니다. 이들 두 가지 성능 모드에는 추가 비용이 청구되지 않으므로 Amazon EFS 파일 시스템은 성능 모드와 관계없이 동일하게 청구 및 측정됩니다.


* 범용 성능 모드
대부분의 Amazon EFS 파일 시스템에는 범용 성능 모드를 사용하는 것이 좋습니다. 범용은 웹 서비스 환경, 콘 텐츠 관리 시스템, 홈 디렉터리 및 일반 파일 서비스 등과 같이 지연 시간에 민감한 사용 사례에 이상적입니다. 파일 시스템을 만들 때 성능 모드를 선택하지 않으면 Amazon EFS에서는 기본적으로 범용 모드가 자동으로 선택됩니다.

* 최대 I/O 성능 모드
최대 I/O 모드의 파일 시스템은 더 높은 수준의 집계 처리량 및 초당 작업으로 확장할 수 있습니다. 이 확장으 로 인해 파일 메타데이터 작업에 대한 지연 시간이 약간 더 높아집니다. 이 모드는 빅 데이터 분석, 미디어 처 리 및 게놈 분석 등과 같은 고도의 병렬 처리가 필요한 애플리케이션 및 워크로드에 유용할 수 있습니다.

처리량모드
처리량 모드 파일 시스템에 대해 버스팅 처리량과 프로비저닝 처리량의 두 가지 처리 모드 중에서 선택할 수 있습니다. 버스팅 처리량 모드에서는 표준 스토리지 클래스의 파일 시스템 크기가 커짐에 따라 Amazon EFS의 처리량이 조정됩니다. 프로비저닝 처리량 모드를 사용하면, 저장된 데이터의 양과 상관없이 파일 시스템의 처리량(MiB/s)을 즉시 프로비저닝 할 수 있습니다.


* 버스팅 모드를 사용하여 처리량 조정
버스팅 처리량 모드에서는 표준 스토리지 클래스에 저장된 파일 시스템이 커짐에 따라 Amazon EFS의 처리량이 조정됩니 다. 파일 기반 워크로드는 일반적으로 급증하기 때문에 즉, 단기간에 처리량을 크게 끌어 올리고 나머지 기간에는 처리량 이 낮게 유지됩니다. 이를 위해 Amazon EFS는 일시적으로 높은 처리량 수준으로 버스트하도록 설계되었습니다. 크기에 관계없이 모든 파일 시스템은 100MiB/s의 처리량으로 버스트할 수 있습니다.

* 프로비저닝 모드를 사용하여 처리량 지정 
프로비저닝 처리량 모드는 처리량 대 스토리지(TiB당 MiB/s) 비율이 높은 애플리케이션 또는 버스팅 처리량 모드에서 허용하는 것보다 더 많은 요구 사항이 필요한 애플리케이션에 사용할 수 있습니다. Amazon EFS를 파일 시스템의 데이터 크기가 처리량 요구 사항에 비해 작은 것에 사용할 경우, 파일 시스템을 패딩하지 않고도 파일 시스템에서 애플리케이션 에서 필요로 하는 처리량을 높일 수 있습니다. 프로비저닝 처리량 모드 사용 시 추가 요금이 발생합니다. 프로비저닝 처리량 모드를 사용하면 사용하는 스토리지에 대한 요금과 제공되는 것보다 많은 프로비저닝 처리량에 대한 요금이 청구됩니다.

생성된 파일시스템입니다.




VPC의 경우 DNS이름 활성화가 체크되어 있어야 합니다.


파일시스템이 생성되었다면 EC2로 파일시스템에 인스턴스 네트워크 액세스 권한을  연동이 사전에 생성한 EC2의 보안그룹을 변경합니다. EC2를 선택하고 작업메뉴에서 보안 > 보안그룹 변경을 클릭합니다.

보안그룹 'my-efs-sg'를 추가합니다.

저장을 클릭하여 보안그룹 추가를 완료합니다.



2. EFS 마운트

EFS와 EC2 인스턴스를 연결해야합니다.
EC2 인스턴스에 SSH 연결하여 파일 시스템을 탑재하고 이용하기 위해서는 마운트 하는 과정이 필요합니다.
EC2 인스턴스와 아마존 EFS 연결은 DNS를 이용하는 방법과 IP를 이용하는 2가지 방법이 있습니다.
DNS를 이용한 연결

# EFS 탑재 헬퍼 사용하는 경우
$ sudo mount -t efs -o tls fs-0ca1d1ccb46ab4782:/ efs

# NFS 클라이언트 사용하는 경우
# NFS 클라이언트 설치
$ sudo yum install -y nfs-utils

# 마운트할 폴더 생성
$ sudo mkdir efs

# NFS 클라이언트 사용
$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-0ca1d1ccb46ab4782.efs.ap-northeast-2.amazonaws.com:/ efs
# 파일시스템 마운트 확인
$ df -h
Filesystem                                               Size  Used Avail Use% Mounted on
devtmpfs                                                 482M     0  482M   0% /dev
tmpfs                                                    492M     0  492M   0% /dev/shm
tmpfs                                                    492M  416K  492M   1% /run
tmpfs                                                    492M     0  492M   0% /sys/fs/cgroup
/dev/xvda1                                               8.0G  1.7G  6.4G  21% /
tmpfs                                                     99M     0   99M   0% /run/user/1000
fs-0ca1d1ccb46ab4782.efs.ap-northeast-2.amazonaws.com:/  8.0E     0  8.0E   0% /home/ec2-user/efs

연결이 되었는지 확인 작업을 합니다.
간단한 dd 명령을 실행하여 새 파일 시스템에서 테스트 파일을 생성하고 새 디렉토리에 1GiB파일을 생성해 봅니다.

$ sudo dd if=/dev/zero of=~/efs/1GiB bs=1M count=1024 status=progress
1016070144 bytes (1.0 GB) copied, 7.034657 s, 144 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 8.98902 s, 119 MB/s
# 파일시스템에 1기가 파일이 제대로 생성이 되었는지 확인합니다.
$ cd efs
$ ls -al
합계 1048580
drwxr-xr-x 2 root     root           6144 11월  2 01:45 .
drwx------ 4 ec2-user ec2-user         85 11월  2 01:40 ..
-rw-r--r-- 1 root     root     1073741824 11월  2 01:45 1GiB

EFS 파일시스템 페이지리를 리프레시를 하면 추가된 1GiB 파일의 용량이 표시되고 있음을 확인할 수 있습니다.



* 덧붙여서, 파일 시스템의 루트 디렉토리는 생성 시 루트 사용자가 소유하고 쓸 수 있으므로 파일을 추가하려면 권한을 변경해야 합니다.

# 현재 루트 권한
$ ls -al
합계 1048580
drwxr-xr-x 2 root     root           6144 11월  2 01:45 .
drwx------ 4 ec2-user ec2-user         85 11월  2 01:40 ..
-rw-r--r-- 1 root     root     1073741824 11월  2 01:45 1GiB

# 권한 변경
$ sudo chmod go+rw .
$ $ ls -al
합계 1048580
drwxrwxrwx 2 root     root           6144 11월  2 01:45 .
drwx------ 4 ec2-user ec2-user         85 11월  2 01:40 ..
-rw-r--r-- 1 root     root     1073741824 11월  2 01:45 1GiB


IP를 이용한 연결 명령어 입니다.

# NFS 클라이언트 사용
$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 10.0.14.90:/ efs


AMI가 ubuntu 서버인 경우

# AMI를 ubuntu server를 이용하는 경우

# aws에서 제공하는 efs-utils를 설치합니다. 
# 이 모듈을 설치하면 더 쉽게 사용할 수 있습니다. 

# 먼저 efs-utils 파일을 받습니다. 
git clone https://github.com/aws/efs-utils

# 다운로드 받은 efs-utils 파일 경로에 접근합니다. 
# 받은 파일 안에서 build를 하게 됩니다. 
cd ./efs-utils
sudo apt-get -y install binutils
./build-deb.sh
sudo apt-get update
sudo apt-get -y install ./build/amazon-efs-utils*deb

# 임의로 efs 경로를 만들어서 사용합니다. 
cd ../
mkdir efs

# 이 명령어로 실제로 efs 서비스와 위에서 생성한 efs 경로가 연결이 됩니다. 
# "fs-64a2fc05"는 efs 대시보드에 들어가서 efs의 dns이름을 사용하시면 됩니다. 
sudo mount -t efs fs-64a2fc05:/ efs

EC2 인스턴스에 Amazon EFS 파일 시스템을 성공적을 마운트했습니다.
(마운트 해제는 이후에 연재될 AWS 클라우드 구축 실습 - Route53, EBS를 참고하시면 해제를 하실 수 있습니다)



3. 재부팅 마운트 유지설정

이렇게 마운트까지 했는데 끝난 것 같지만 끝난 게 아닙니다. 마운트한 파일 시스템은 재부팅 후에도 지속되어 연결되어 있지 않습니다. 디렉토리를 자동으로 재 마운트하려면 fstab파일을 사용하여야 합니다. 

/etc/fstab을 사용하여 자동으로 마운트

# 자동 탑재 명령어 "/home/ec2-user/efs"를 마운트 지점으로 설정합니다.
# 다음 형식으로 설정하려고 합니다 : 
# "file-system-id:/ efs-mount-point efs _netdev,noresvport,tls,iam 0 0"
# "fs-0ca1d1ccb46ab4782: /home/ec2-user/efs efs _netdev,noresvport,tls,iam 0 0"
# vi 편집기로 fstab을 오픈
$ sudo vi /etc/fstab

# 변경사항을 저장한 후 fstab을 사용하여 항목을 테스트합니다.
$ sudo mount -fav
/home/ec2-user/efs       : successfully mounted
# 재부팅하여 마운트 여부를 확인합니다.

'_netdev' 옵션은 네트워크에 연결 후 마운트하라는 옵션입니다. 이 옵션이 누락되면 EC2 인스턴스가 응답하지 않습니다.

위의 내용 AWS에서의 가이드 주소 "Amazon EFS 파일 시스템 자동 마운트"에서 확인해 보세요.


AWS 인프라 구축 실습 11회 - EFS에 대하여 실습해 보았습니다.
다음은 CloudFront에 대해서 실습해보도록 하겠습니다.


반응형
Posted by SB패밀리

댓글을 달아 주세요

Github의 최대 용량을 알고 싶어요

 

Github.com 을 많은 사람들이 사용하고 있습니다.

github은 점점 기능을 추가하고 개선을 하면서 여러가지 기능을 제공하고 있습니다.

거기에다 자동으로 버전업(형상관리)를 해주고 있으니 얼마나 편리한지 모르겠습니다.

간단한 text 파일 작성이라든가, markdown 파일 작성, 각종 소스관리가 무척 편리합니다.

그래서, github 이용자는 점점 늘어나고 있습니다.

github project 관리 기능

그런데, 단지 텍스트 파일이 아닌 다른 파일들 즉, 이미지나 특정 문서 포맷 파일, 다이어그램 파일 등을

업로드해서 저장하려고 하면 용량이 기하급수적으로 늘어납니다.

이럴 경우에는 내가 사용할 수 있는 용량이 얼마인지 점차 궁금해지고

구글링이나 다음에서 검색해서 찾아보게 되겠죠.

그래서 좀 알아봤습니다. github는 개인의 용량 관리를 어떻게 하고 있을까?

https://help.github.com/en/github/managing-large-files/what-is-my-disk-quota 

 위 사이트에 들어가서 확인해보면

Github에 업로드할수 있는 최대 용량은 단일 파일 100MB, repos(저장소) 용량 최대 100GB이다. 하지만 저장소 용량은 사실상 100GB를 채울수 없게 만들고, Github에서도 1GB 이하로 유지하기를 바라고 있다. 오늘은 왜 100GB를 채울수 없게 만드는지 알아볼 필요가 있습니다.

 

 

반응형
Posted by SB패밀리

댓글을 달아 주세요