DevOps28일차 - 스토리지

1. 블록 스토리지

블록 스토리지는 데이터를 일정한 크기의 블록으로 저장하는 방식입니다.
블록은 파일 보다는 작은 단위로서 조각으로 나누어 저장

나누어진 각각의 블록은 고유한 주소를 가지고 있습니다. 이 주소를 통하여 재구성하여 데이터를 불러올 수 있습니다.

SAN(Storage Area Network) 또는 가상머신의 디스크로 사용하며, 정형화된 데이터를 빠르게 처리하는 용도로 많이 사용됩니다.

블록 스토리지는 주차장에 비유됩니다. 주차장의 한 구획이 블록으로 비유되어 특정 공간에 차를 주차하듯이 정해진 블록에 데이터를 저장합니다.

장점

블록 스토리지에서는 고유 주소가 있어 파일 스토리지와 달리 계층 구조도 필요없고, 경로도 하나만 있는 것이 아니라 다양하게 가지고 있습니다. 그만큼 데이터를 신속하게 검색할 수 있습니다.

또한 파티션으로 분할될 수 있어 서로 다른 운영 체제에서 엑세스할 수 있습니다. 자유롭고 효율적이며 안정적이기 때문에 대규모 DB운영에 잘 맞습니다.

단점

비용이 많이 든다는 점이 단점입니다. 메타데이터 처리가 제한적이기 때문에 데이터 단위가 아닌 애플리케이션 또는 데이터베이스 수준에서 작업을 진행하여 관리자의 부담이 있습니다.

파일 스토리지 (file storage)

파일 스토리지는 파일과 폴더의 계층 구조로 이루어진 방식입니다.
윈도우 사용자에겐 익순한 방식입니다.
파일들은 이름, 위치, 생성일, 크기 등의 제한적인 메타데이터를 가지고 있습니다.
파일이 늘어나면 데이터도 늘어나고 파일을 찾는것도 그만큼 힘들어집니다.
파일 스토리지는 일반적으로 NAS(Network Attached Storage)에 사용됩니다.!1. 블록 스토리지

파일 스토리지는 주차타워에 비유됩니다. 주차타워에 차가 많아지면 차가 차곡차곡 쌓이고 차를 되찾으시려면 시간도 오래걸리게 됩니다.

장점

파일 스토리지는 오래전부터 사용해온 전통적인 데이터 스토리지 시스템입니다.
사용이 친숙하고 표준화가 잘 되어 있습니다.

단점

데이터가 많아지면 파일과 폴더를 찾기 위하여 리소스가 많이 들기 때문에 성능이 저하됩니다.

오브젝트 스토리지(Object Storage)

오브젝트 스토리지는 오브젝트라는 개별 데이터 단위로 데이터를 저장하는 유형이다. 오브젝트 비디오, 오디오, 텍스트, 기타 다른 파일 유형 등의 모든 데이터를 포괄하는 유형이다.
폭증하는 대량의 데이터를 저장하고 관리하기 좋은 최신의 스토리지 방식입니다.

오브젝트 스토리지는 대리주차에 비유합니다
자동차 키만 건네면 어디에 주차를 하는지 알 필요 없이 알아서 공간을 효율적으로 활용하여 빈틈없이 주차를 해줍니다. 찾을 때도 보관증만 건네면 쉽게 가져다 주듯이 말이죠.

장점

데이터 구조가 계층이 아닌 평면구조로 데이터 접근이 빠르고 확장성이 좋습니다.
메타데이터가 오브젝트 자체로 저장되므로 접근과 검색이 쉽습니다.

단점

오브젝트를 수정할 수 없어 덮어쓰는 방법을 사용합니다.
자주 변경되는 데이터는 맞지 않고 수정이 잘 일어나지 않는 이미지나 영상 데이터에 적합합니다.

AWS 스토리지 종류

Simple Storage Service, S3

AWS의 대표 스토리지 서비스인 S3는 객체 스토리지로 데이터 백업, 정적 웹사이트 호스팅, 애플리케이션 호스팅, 재난 복구, 콘텐츠 배포, 데이터 레이크, 프라이빗 저장소 등에 활용할 수 있습니다.

버킷(bucket)

버킷은 객체를 저장하는 컨테이너 역할을 하며, 컴퓨터로 비유하자면 파일을 담는 폴더 역할을 합니다. 따라서 한 버킷 내에 여러 개의 폴더를 생성할 수도 있습니다.

버킷 생성 시 주의해야 할 점은 버킷 이름을 붙일 때 여러 리전에서 유일무이한 이름을 사용해야 합니다. 그래야 사용자가 버킷 URL을 통해 해당 데이터에 접근할 수 있습니다.

버킷은 어떤 리전에서나 생성할 수 있고, 명시적으로 복제 작업을 수행하지 않으면, 한 다른 리전에 특정 버킷의 데이터가 복제 되지 않습니다. 또한 S3 버킷은 버전 부여 기능을 제공하므로 객체가 버킷에 추가될 때마다 해당 객체에 유일한 ID가 할당됩니다.

🖍 참고
만약 S3 버킷에 사용자 지정 도메인을 사용하고 싶다면? - 레퍼런스의 2단계: 두 개의 버킷 생성 부분을 참고하여 도메인과 같은 이름의 S3 버킷을 생성해야 합니다.

객체(object)

앞서 언급했듯 객체란 문서, 이미지, 비디오 등 비교적 단순한 구조에 메타데이터을 포함하고 있는 데이터로, 버킷에 저장한 모든 것을 객체라고 부릅니다. 이는 가장 기본적인 요소로, 각 객체는 데이터와 메타데이터를 가집니다. 메타데이터는 해당 객체를 설명하는 이름-값 쌍으로 표시하며 여기에는 최종 수정일, 파일 타입 등 부가 정보가 기록됩니다.

객체는 이름, 키 또는 버전 ID를 통해 식별할 수 있으며, 키를 통해 버킷에서 유일한 것으로 식별합니다. 따라서 버킷에 존재하는 모든 객체는 단 하나의 키를 가집니다.

접근성 통제

접근성 통제(Access Control)란, S3 버킷에 누가 어떻게 접근하도록 할 것인지를 정의하는 것을 말합니다. 접근성 통제 방식은 주로 JSON을 이용해 작성된 정책(Policy)를 통해 이루어지며, 접근 정책, 버킷 정책, 접근 제어 목록 등의 방식을 사용합니다.

정책을 만드는 JSON 파일의 구조는 아래와 같습니다. 하나의 Statement에는 하나의 permission 정보가 포함됩니다. 정책에 포함된 다수의 statement은 논리합(Logical OR) 관계를 맺습니다.

위의 정책에서 사용되는 각 필드는 다음과 같은 의미를 갖습니다.

• ID : 정책의 ID 값으로, UUID를 사용하기를 권장합니다.
• SID : Statement ID로 statement 를 구분하기 위해서 사용합니다.
• Effect : 정책의 효과를 나타내며, 허용할 것인지 거부할 것인지를 선택할 수 있습니다.
• Principal : 대상 및 주체를 지정합니다. Users, Services 등이 될 수 있습니다.
• Action : 정책을 통해 승인 혹은 거절할 동작을 의미합니다.
• Resource : Action이 영향을 미치는 리소스 리스트를 지정합니다.
• Condition : 조건이 충족되는 경우에는 해당 정책을 적용시킬 수 있습니다.

더불어 정책은 사용자, 그룹, 및 롤에 할당하는 IAM 정책인 Identity-based policies 와 - S3 Bucket, SES Queue 등 AWS 자원에 할당되는 정책인 Resource-based policies로 나뉘어 작성됩니다.

이 둘을 구분하기 위해서는 필드에 Principal이 있는지 확인해보면 됩니다. AWS 자원에 할당되는 정책에는 Principal 항목이 포함되어 있고, IAM 정책에는 Principal 항목이 포함되어 있지 않습니다. 아래에서 더 자세히 설명하도록 하겠습니다.

접근 정책

• Identity-based policies
  IAM, 즉 신분 및 접근 관리 정책으로 S3의 객체를 매우 세분화해 통제할 수 있습니다. 먼저 유저, 그룹, 롤 등 IAM 정책을 정의합니다. 예를 들어, S3 풀 액세스 정책을 생성하고, 10명의 유저가 포함된 그룹에 해당 정책을 할당합니다. 그러면 해당 그룹에 속한 10명의 회원 모두 S3 버킷에 대한 풀 액세스 권한에 접근 가능합니다.

IAM과 S3를 이용하면 특정 IAM 유저와 공유되고 있는 버킷을 선택할 수 있고, 특정 유저가 해당 버킷에 접근하도록 허용할 수 있습니다. 또한 특정 버킷의 내용을 회원 모두 혹은 일부 회원이 열람하도록 할 수 있고, 고객 또는 파트너가 특정 버킷에 객체를 추가하도록 허용할 수 있습니다.

다음 예시를 통해 살펴보겠습니다.

이 예제에서는 AWS 계정 의 IAM 사용자에게 버킷 중 하나인 awsexamplebucket1에 대한 액세스 권한을 부여하고 이 사용자에게 객체를 추가, 업데이트, 삭제하도록 허용하려 합니다.

    {
       "Version":"2012-10-17",
       "Statement":[
          {
             "Effect":"Allow",
             "Action": "s3:ListAllMyBuckets",
             "Resource":"*"
          },
          {
             "Effect":"Allow",
             "Action":["s3:ListBucket","s3:GetBucketLocation"],
             "Resource":"arn:aws:s3:::awsexamplebucket1"
          },
          {
             "Effect":"Allow",
             "Action":[
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:GetObject",
                "s3:GetObjectAcl",
                "s3:DeleteObject"
             ],
             "Resource":"arn:aws:s3:::awsexamplebucket1/*"
          }
       ]
    }

위 예시에서는 하나의 정책에 총 3개의 statement 가 삽입 되었습니다.

첫번째로, s3:PutObject, s3:GetObject 및 s3:DeleteObject 권한을 사용자에게 부여합니다.

두번째로 이 정책에서는 s3:ListAllMyBuckets, s3:GetBucketLocation 및 s3:ListBucket 권한 역시 부여합니다. 이러한 권한은 콘솔에 필요한 추가 권한입니다.

또한 세번째로 콘솔에서 객체를 복사, 자르기 및 붙여넣기를 할 수 있으려면 s3:PutObjectAcl 및 s3:GetObjectAcl 작업이 필요합니다. 따라서 총 세 개의 statement가 하나의 정책으로 작성된 것을 확인 할 수 있고, 이렇게 작성된 정책을 그룹, 유저 등에 할당하여 사용할 수 있습니다.

버킷 정책

• Resource-based policies
  버킷 정책이란 버킷 레벨에서 생성한 정책을 의미하며, S3 버킷을 세분화된 방식으로 제어할 수 있도록 합니다.

대표적인 버킷 정책의 사례는 특정 버킷에 있는 객체에 대한 익명의 사용자로부터의 리드 온리 접근을 허용하는 케이스입니다. 이는 S3 리소스 기반의 정적 웹 사이트를 운영하거나, 웹을 통해 불특정다수의 접근을 허용할 때 자주 사용되는 방법으로 버킷에 GetObject 액세스 권한을 부여하면 됩니다.

다음의 예시는 devopscodestates를 위한 S3 버킷 정책입니다.

    {
      "Version":"2012-10-17",
      "Statement":[
        {
          "Sid":"PublicRead",
          "Effect":"Allow",
          "Principal": "*",
          "Action":["s3:GetObject"],
          "Resource":["arn:aws:s3:::devopscodestates/*"]
        }
      ]
    }

devopscodestates 버킷의 모든 리소스를 GetObject 작업으로 누구나 접근할 수 있음을 Principal 필드의 값을 통해 확인할 수 있습니다.

S3의 보안 Best Practice

• 보통의 경우 S3 버킷에 대한 퍼블릭 액세스를 허용해서는 안됩니다. S3 버킷을 퍼블릭 액세스 할 수 있다는 말은 모든 파일이 아무에게나 노출될 수 있다는 의미입니다.
• 최소한의 접근 권한 전략을 사용합니다. S3 버킷에 접근해야 하는 사람에게도 관련 작업에 해당하는 만큼만 권한을 부여하고, 그외 사람에게는 접근 거부 정책을 적용합니다.
• 다중인증(MultiFactor Authentication, 이하 MFA) 시스템을 활용합니다. MFA Delete를 설정하여 데이터 삭제 권한이 없는 사람은 삭제 할 수 없도록 제한합니다.

S3 스토리지 클래스

S3 스토리지 클래스 레퍼런스

Storage - EBS

Elastic Block Store, EBS는 EC2 인스턴스에 사용할 수 있는 블록 수준 영구 스토리지 볼륨입니다. 영구 스토리지는 EC2 인스턴스의 수명주기를 넘어서서 존재할 수 있는 스토리지의 의미입니다. EBS 볼륨은 형식이 지정되지 않은 원시 블록 디바이스처럼 동작합니다. 이러한 볼륨 위에 파일 시스템을 생성하거나 하드 드라이브와 같은 블록 디바이스를 사용하는 것처럼 볼륨을 사용할 수 있습니다. 인스턴스에 연결된 볼륨의 구성을 동적으로 변경할 수 있습니다.

EBS 볼륨은 EC2 인스턴스의 부트 파티션으로 사용되거나 실행 중인 EC2 인스턴스의 표준 블록 디바이스로 사용됩니다. EC2 인스턴스에 EBS 볼륨을 부착하면, 서버를 위한 하드 드라이브와 같은 기능을 수행하게 됩니다.

그 뿐만 아니라 하나의 EC2에 여러 개의 EBS 볼륨을 부착 할 수도 있는데 이렇게 하면 부트 볼륨과 데이터 볼륨을 별도로 관리 할 수 있어서 편리합니다.

EC2에 부착한 EBS 볼륨은 언제든 분리할 수 있고, 다른 EC2에 부착도 가능하지만, EBS 볼륨은 특정 AZ에 속한 자원이기도 하므로, 서로 다른 AZ 간의 EC2에 EBS 볼륨을 분리하고 부착하는 것은 불가능 합니다.

EBS 볼륨은 부트 파티션으로도 사용할 수 있습니다. 이때는 EC2 인스턴스가 정지 후 재시동돼 해당 인스턴스 상태를 유지하기 위한 스토리 리소스로서의 기능만 담당하게 됩니다. 또한 EBS 볼륨은 서버 재시동 후에도 유지되므로 기존에 저장된 내용은 그대로 남게 됩니다. EBS 볼륨은 EC2 인스턴스의 로컬 스토리지에 비해 훨씬 높은 수준의 견고성을 제공합니다.

EBS는 볼륨에 대한 특정 시점의 스냅샷을 지속적으로 작성해 S3에 저장하는 방식으로 다수의 AZ에서 자동 복제 기능을 제공합니다. 이렇게 생성된 스냅샷은 또 다른 EBS 볼륨 생성을 위한 시작점으로 활용할 수 있으며, 장기간 서버와 관련된 데이터를 안전하게 보호할 수 있습니다. 이 스냅샷은 리전 간 복제해서 사용할 수도 있으므로 재난 복구, 데이터센터 마이그레이션 등에도 편리하게 사용할 수 있습니다.

EBS 볼륨 유형

EBS 볼륨 유형 관련 레퍼런스

Storage - EFS

Elastic File System, EFS는 서버를 사용하지 않는 간단한 탄력적인 파일 시스템을 제공합니다. EFS 로 파일 시스템을 생성하고 EC2 인스턴스에 파일 시스템을 탑재한 후 파일 시스템에 데이터를 작성하거나 파일 시스템에서 데이터를 읽을 수 있습니다.

애플리케이션을 중단하지 않고 온디맨드 방식으로 페타바이트 규모까지 확장되도록 구축되어, 사용자가 파일을 추가하고 제거할 때 자동으로 확장/축소되므로 데이터 증가에 맞춰 용량을 프로비저닝 및 관리할 필요가 없습니다. EFS 는 파일 시스템을 빠르고 쉽게 만들고 구성할 수 있는 간편한 웹 서비스 인터페이스를 제공합니다. 이 서비스에서 모든 파일 스토리지 인프라를 관리해 주므로 사용자는 복잡한 파일 시스템 구성을 배포, 패치 및 유지 보수하는데 따르는 복잡성에서 벗어날 수 있습니다.

EFS 스토리지 클래스

EFS 스토리지 클래스에 대한 레퍼런스