AWS ( 스토리지)

Numberbeen·2023년 1월 5일
0

AWS

목록 보기
5/13
post-thumbnail

🔆 Storage Intro

AWS 스토리지 서비스는 다음과 같이 세 개의 카테고리로 나누어진다.

💥 객체 스토리지 (Object Storage)

여기서 객체란 문서, 이미지, 비디오 등 비교적 단순한 구조에 메타데이터를 포함하고 있는 데이터 를 의미하며, 인터넷으로 연결된 API를 통해 데이터를 애플리케이션에 제공한다.

💥 블록 스토리지(Block Storage)

블록 스토리지에서 데이터는 서버 인스턴스에 디스크 볼륨의 형태로 제공되는 데이터를 의미 한다. 이를 통해 EC2 인스턴스에 포함된 볼륨에 고속으로 접근 가능 합니다.

대표적인 서비스인 Elastic Block Store, EBS는 EC2 인스턴스를 위한 부트 볼륨 및 데이터베이스로 널리 사용.

💥 파일 스토리지(File Storage)

파일 스토리지에서 데이터란 서버 인스턴스에 파일 시스템 인터페이스 방식으로 제공되는 데이터를 의미 하며, 서버 인스턴스에 파일 스토리지를 추가하면 로컬 파일 시스템처럼 작동합니다.

대표적으로 Elastic File System, EFS는 고속으로 다수의 EC2 인스턴스를 통해 데이터에 접근할 수 있도록 합니다.

Action Item
객체, 블록, 파일 스토리지의 차이점과 장단점은 무엇일까?


🔆 S3 Intro


S3 가 무엇인지 알기 전, 클라우드 스토리지 개념에 대해 잠시 알아보자.

❓ 클라우드 스토리지란 무엇인가?
클라우드 스토리지란 쉽게 말해서 인터넷 공간에 데이터를 저장하는 저장소 이다. 컴퓨터 부품으로 비유하면 하드디스크의 역활을 하는 서비스이다. ( 예시로는 구글 드라이브, 네이버 MY BOX 등 )


💥 클라우드 스토리지 서비스의 장점은?

클라우드 스토리지 서비스의 뛰어난 접근성을 가지고 있다. 컴퓨터의 하드디스크에 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야만 한다. 그러나 클라우드 스토리지를 이용하면 웹 한경이라면 언제 어디서나 저장된 파일에 접근할 수 있다. 또한 컴퓨터뿐만 아니라 웹에 접속이 가능한 다른 전자기기를 활용하여 클라우드 스토리지에 저장된 데이터에 접속할 수 있다.

💡 S3 는 Simple Storage Service 의 약자로 AWS 에서 제공하는 클라우드 스토리지 서비스.

앞서 언급했듯이 클라우드 스토리지 서비스는 뛰어난 접근성을 가지고 있다는 점과 마찬가지고 S3 역시 뛰어난 접근성을 가지고 있다. 그 외에도 S3 사용이 얻을 수 있는 이점은 여러가지인데 그 이점에 대해 알아보자.


S3 사용 시 얻을 수 있는 이점으로 높은 확장성 이 있다.

확장성이 높으면 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소 할 수 있다.

또한, S3 에서는 스토리지의 용령을 무한히 확장 할 수 있다. 그리고 사용한 만큼만 비용을 지불 하면 되기 때문에 비용적인 측면에서 매우 효율적이다.


스토리지의 내구성이 높으면 저장된 파일을 유실할 가능성이 적어진다. S3는 99.999999999% 의 내구성을 보장 한다.

S3 스토리지의 내구성에 대한 실생활의 예를 들자면, S3에 저장된 파일을 잃어버릴 확률보다, 길을 걷다가 벼락을 맞을 확률(약 0.0000007% 의 확률) 이 700배나 더 높다.

이런 예시를 통해 S3 스토리지의 내구성이 얼마나 대단한지 가늠이 될거라 생각된다.


가용성이 높으면 스토리지에 저장된 파일들을 정삭적으로 사용할 수 있는 시간이 길어진다. ✅ S3는 연간 99.99% 의 스토리지 가용성을 보장하도록 설계 되어있다.

❓AWS 는 어떤 원리로 해당 서비스들의 높은 가용성과 내구성을 보장할 수 있을까?

위의 지도를 보면 주황색 동그라미가 쳐진 지역을 '리전(Region)' 이라 부른다. 리전 이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치 를 뜻한다.

지도를 다시 보면 주황색 동그라미 안에 숫자가 새겨져 있는데, 이 숫자는 리전에 위치한 가용 영역의 수를 뜻 한다. 가용 영역(Availability Zone)이란 각 리전 안에 존재하는 데이터 센터(IDC)를 뜻 한다.

가용 영역은 각각 개별적인 위치에 떨어져서 존재한다. 그래서 **한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제없이 서버가 가동**되게 한다.

❗️ 이런 가동 방식 덕분에 AWS에서 제공하는 서비스들은 높은 가용성과 내구성을 보장


또 다른 특징으로 S3는 다양한 스토리지 클래스를 제공. 저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라진다.

S3 사용자들이 대표적으로 많이 선택하는 스토리지 클래스는 두 가지가 있다.
Standard 클래스Glacier 클래스입니다.

Standard 클래스는 범용적인 목적으로 사용하기 좋다.
데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠르다.

대신 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 ❌. 보관 비용이 높게 발생하기 때문


장기적인 보관 목적으로 스토리지를 사용하실 때는 Glacier를 사용하는 것이 효율적

비록 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점 이 있습니다.

이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등등 여러 가지 스토리지 클래스가 존재하여 사용자의 이용 목적에 따라 다양한 스토리지 클래스를 사용할 수 있다.


S3 사용 시 얻는 이점 중 하나로, 정적 웹 사이트 호스팅이 가능 하다.

❓ 정적 웹 사이트 호스팅이란 뭘까?

먼저 정적 웹 사이트 호스팅이 무엇인지 알기 위해 '정적' 파일에 대한 이해가 선행되어야 한다.

'정적' 파일은 서버의 개입 없이 생성된 파일을 뜻 한다. 반대로 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일을 '동적' 파일 이라고 부릅니다.

그럼 ❓ 웹 호스팅(Web Hosting)이란 뭘까?

웹 호스팅이란 서버의 한 공간을 임대해 주는 서비스 를 뜻한다.

구글에 '웹 호스팅'이란 단어를 검색하시면 여러 웹 호스팅 업체의 목록이 뜨시는 것을 확인할 수 있다.
웹 호스팅 업체들을 통해 개인 또는 단체가 웹 호스팅 업체가 제공하는 서버의 한 공간을 빌려서 원하는 서비스를 배포할 수 있다.

S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공한다. 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있다.

여기서 또 생소한 '버킷'이라는 개념이 나왔다. 다음은 버킷이 무엇인지 알아보자.


버킷이란 S3에 저장되는 파일들이 담기는 바구니 이다. 파일을 저장하는 최상위 디렉터리라고도 설명할 수 있다.

📌S3에서 저장되는 모든 파일은 버킷 안에 저장 되어야 하고, 📌버킷에는 무한한 양의 파일을 저장 할 수 있습니다. 그리고 각각의 버킷은 이름을 가지고 있는데, 📌버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일 해야 합니다.

또한 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있다.


S3에서 버킷에 담기는 파일을 객체 라고 부른다.

❓ 왜 객체라고 부를까?

S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문

S3에 저장되는 객체는 파일과 메타데이터로 구성 된다.

파일에 대해서 먼저 알아보면 파일은 위에 설명한 대로 키-값 페어 형식으로 데이터를 저장합니다.

파일의 값에는 실제 데이터를 저장 한다. S3 객체의 값으로써 저장될 수 있는 데이터의 최대 크기는 5TB
파일의 키각각의 객체를 고유하게 만들어주는 식별자 역할을 합니다.
파일의 키를 이용하여 원하는 객체를 검색할 수 있습니다.

메타데이터 는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터 입니다.
객체를 설명하는 데이터 라고 이해하시면 좋습니다.

모든 객체는 고유한 URL 주소를 가지고 있습니다.

URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띠고, URL 주소를 통해서도 원하는 데이터에 접근할 수 있다.


🔆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:GetObjects3:DeleteObject 권한을 사용자에게 부여합니다.

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

또한 세번째로 콘솔에서 객체를 복사, 자르기 및 붙여넣기를 할 수 있으려면 s3:PutObjectAcls3: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 스토리지 클래스


🔆 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 볼륨 유형


🔆 Storage - EFS

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

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

💥 EFS 스토리지 클래스

profile
내기 이해한 것을 보관하는 곳

0개의 댓글