IT STUDY LOG
[AWS] 04. 스토리지 본문
# 학습 목표
- Cloud와 Deployment의 의미를 각각 알고, 서비스를 남에게 배포할 수 있다.
- 클라우드 컴퓨팅이 무엇인지 설명할 수 있다.
- 애플리케이션 배포가 어떻게 변화되어 왔는지 이해할 수 있다.
- AWS의 각 서비스가 어떤 목적에 부합하는지 이해할 수 있다.
- S3의 목적과, 정적 웹 사이트 배포 방법을 이해할 수 있다.
- EC2의 주요 용어를 이해할 수 있다. (AMI, 인스턴스, 인스턴스 유형, 스토리지 타입, 퍼블릭/프라이빗 IP)
- EC2의 인스턴스 시작/중지/종료에 대해 이해할 수 있다.
- RDS와 EC2에서의 MySQL 사용이 어떻게 다른지 이해할 수 있다.
- CloudFront의 목적을 이해할 수 있다.
- Auto Scaling의 특징 및 역할을 알 수 있다.
- 로드 밸런서 중 ELB, 그 중에서 Application Load Balancer의 목적을 이해할 수 있다.
- AWS 인프라 중 VPC에 대해서 이해할 수 있다.
- Route 53의 목적을 이해하고, 도메인을 연결해 HTTPS로 배포할 수 있다.
- 빌드 및 배포시 필요한 환경 설정을 할 수 있다.
- 배포 시 발생하는 문제를 이해하고 고칠 수 있다.
# 학습 내용
1. Storage 개요
스토리지 서비스
객체 스토리지(Object Storage)
- 객체(문서, 이미지, 비디오 등 비교적 단순한 구조에 메타데이터를 포함하고 있는 데이터를 의미)를 인터넷으로 연결된 API를 통해 데이터를 애플리케이션에 제공
블록 스토리지(Block Storage)
- 블록 스토리지에서 데이터는 서버 인스턴스에 디스크 볼륨의 형태로 제공되는 데이터를 의미
- 이를 통해 EC2 인스턴스에 포함된 볼륨에 고속으로 접근 가능
- 대표적인 서비스인 Elastic Block Store, EBS는 EC2 인스턴스를 위한 부트 볼륨 및 데이터베이스로 널리 사용
파일 스토리지(File Storage)
- 파일 스토리지에서 데이터란 서버 인스턴스에 파일 시스템 인터페이스 방식으로 제공되는 데이터를 의미
- 서버 인스턴스에 파일 스토리지를 추가하면 로컬 파일 시스템처럼 작동
- 대표적으로 Elastic File System, EFS는 고속으로 다수의 EC2 인스턴스를 통해 데이터에 접근할 수 있도록 함
객체, 블록, 파일 스토리지 서비스의 차이점과 장단점
| 분류 | 객체 스토리지(Object Storage) | 블록 스토리지(Block Storage) | 파일 스토리지(File Storage) |
| 특징 | - 데이터를 개별 객체 단위로 저장하며, 고유한 식별자를 가짐 - 객체는 메타데이터와 데이터를 함께 저장하며, 폴더 구조나 디렉토리 개념이 없음 |
- 데이터를 작은 블록 단위로 저장하며, 블록은 고유한 주소를 가짐 - 파일 시스템을 사용하여 데이터를 구성하고, 파일 단위로 데이터를 읽고 쓸 수 있음 |
- 데이터를 파일 단위로 저장하며, 파일 시스템을 사용하여 데이터를 구성하고 파일 단위로 읽고 씀 - 파일은 폴더와 디렉토리 구조 지님 |
| 장점 | - 확장성이 높아 대용량의 데이터를 처리하는 데 효율적이고, 분산 스토리지로 구성될 수 있어 데이터의 안정성과 내구성이 뛰어남 - 객체 단위로 데이터를 저장하므로 데이터의 검색과 관리가 용이 |
- 데이터를 블록 단위로 읽고 쓸 수 있어 파일의 특정 부분을 업데이트하는 데 효율적 - 데이터의 일부 수정이 가능하고, 다양한 파일 시스템을 지원하여 다양한 운영 체제와 호환성 좋음 |
- 사용이 쉬우며 다양한 운영 체제와 호환성이 높음 - 파일 단위로 데이터를 읽고 쓸 수 있어 애플리케이션에 따른 다양한 데이터 접근 방식을 지원 - 파일 단위로 데이터를 수정하거나 삭제하는 것이 용이 |
| 단점 | - 데이터의 일부 수정 또는 삭제가 어려울 수 있고, 파일의 일부를 업데이트하는 데에도 전체 객체를 업데이트해야 할 수 있음 - 고비용 |
- 확장성이 낮아 대용량 데이터 처리에는 제약 - 데이터의 내구성이 낮아 데이터 손실의 위험 |
- 확장성이 낮아 대용량 데이터 처리에는 제약 - 데이터의 내구성이 낮아 데이터 손실의 위험 - 데이터를 파일 단위로 읽고 쓰기 때문에 작은 크기의 데이터를 처리하는 데에는 비효율적 |
2. S3(Simple Storage Service) 개요
클라우드 스토리지란?
- 인터넷 공간에 데이터를 저장하는 저장소로, 하드디스크에 비유 가능
- 뛰어난 접근성으로 클라우드 스토리지를 이용하면 웹 환경이라면 다양한 기기를 통해 언제 어디서나 저장된 파일에 접근 가능
S3 (Simple Storage Service)
- AWS에서 제공하는 클라우드 스토리지 서비스
S3 사용의 이점
확장성
- 데이터를 무한하게 저장 가능
- 스토리지 규모 확장/축소 가능
- on-demand이므로 비용 효율적
강력한 내구성
- 99.999999999%의 내구성을 보장
가용성 보장
- 연간 99.99%의 스토리지 가용성을 보장하도록 설계
다양한 스토리지 클래스 제공
- 저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라짐
- 스토리지 클래스의 대표적인 종류
> Standard 클래스 : 가장 일반적으로 사용되는 클래스로 범용적인 목적 (데이터에 자주 액세스해야 할 경우). 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠르나 고비용이므로 데이터를 오래 보관하는 목적으로는 부적합
> Glacier 클래스 : 데이터의 장기 보관 목적. 데이터 액세스 속도는 느리나 데이터 보관 비용이 저렴
- 기타 스토리지 클래스 종류 : Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등
정적 웹 사이트 호스팅 가능
- 정적 파일 : 서버 개입 없이 생성된 파일로 서버의 처리 작업 없이 클라이언트에 제공이 가능한 파일
- 웹 호스팅 : 서버의 한 공간을 임대해주어서 웹 사이트의 배포, 운영이 가능하게 만들어주는 서비스
- S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공
- 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포 가능
S3의 핵심 개념
버킷
- S3에 저장되는 파일이 담기는 바구니로, 파일을 저장하는 최상위 디렉터리
- S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고 버킷에는 무한한 양의 파일 저장이 가능
- 버킷의 이름은 각 리전에서 고유해야 함
- 버킷 정책을 생성해 해당 버킷에 대한 다른 유저의 접근 권한 부여 가능
객체
- 버킷에 담기는 파일, S3에서는 저장소에 데이터를 저장할 때 키-값 페어 형식으로 저장
- 객체는 파일과 메타 데이터로 구성
> 파일 값 : 실제 데이터, S3 객체 값으로 저장 가능한 최대 크기 5TB
> 파일의 키 : 각각 객체 고유하게 만들어주는 식별자 키
> 메타 데이터 : 객체 생성일, 크기, 유형 등 객체 정보
- 모든 객체는 고유한 키를 가짐
- URL 주소를 통해 객체 접근 가능
- URL 주소 형식 : http://[버킷의 이름].S3.amazonaws.com/[객체의 키]
3. Storage - S3
Simple Storage Service, S3
- 객체 스토리지
- 데이터 백업, 정적 웹사이트 호스팅, 애플리케이션 호스팅, 재난 복구, 콘텐츠 배포, 데이터 레이크, 프라이빗 저장소 등에 활용 가능
기본 개념
버킷
- 버킷은 객체를 저장하는 컨테이너 역할을 하며, 컴퓨터로 비유하자면 파일을 담는 폴더 역할
- 한 버킷 내에 여러 개의 폴더를 생성 가능
- 버킷 이름은 여러 리전에서 유일무이한 이름을 사용해야 하며, 그래야 사용자가 버킷 URL을 통해 해당 데이터에 접근 가능
- 버킷은 어떤 리전에서나 생성할 수 있고, 명시적으로 복제 작업을 수행하지 않으면, 한 다른 리전에 특정 버킷의 데이터가 복제 되지 않음
- S3 버킷은 버전 부여 기능을 제공하므로 객체가 버킷에 추가될 때마다 해당 객체에 유일한 ID가 할당
만약 S3 버킷에 사용자 지정 도메인을 사용하고 싶다면?
- 참고 레퍼런스 : 두 개의 버킷 생성 부분
자습서: Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성 - Amazon Simple Storage
변경 사항은 일반적으로 60초 이내에 모든 Route 53 서버로 전파됩니다. 전파가 완료되면 이 절차에서 생성한 별칭 레코드의 이름을 사용하여 트래픽을 Amazon S3 버킷으로 라우팅할 수 있습니다.
docs.aws.amazon.com
객체
- 문서, 이미지, 비디오 등 비교적 단순한 구조에 메타데이터을 포함하고 있는 데이터로, 버킷에 저장한 모든 것
> 메타데이터: 해당 객체를 설명하는 이름-값 쌍으로 표시하며 여기에는 최종 수정일, 파일 타입 등 부가 정보가 기록
- 객체는 이름, 키 또는 버전 ID를 통해 식별 가능하며 키를 통해 버킷에서 유일한 것으로 식별. ∴버킷에 존재하는 모든 객체는 단 하나의 키를 가짐
접근성 통제
- S3 버킷에 누가 어떻게 접근하도록 할 것인지를 정의하는 것
- 접근성 통제 방식은 주로 JSON을 이용해 작성된 정책(Policy)를 통해 이루어지며, 접근 정책, 버킷 정책, 접근 제어 목록 등의 방식을 사용
- 정책 JSON 파일의 구조
- 하나의 Statement에는 하나의 permission 정보가 포함되며, 정책에 포함된 다수의 statement은 논리합(Logical OR) 관계
> ID : 정책의 ID 값으로, UUID를 사용하기를 권장
> SID : Statement ID로 statement 를 구분하기 위해서 사용
> Effect : 정책의 효과를 나타내며, 허용할 것인지 거부할 것인지를 선택 가능
> Principal : 대상 및 주체를 지정 (ex. Users, Services 등)
> Action : 정책을 통해 승인 혹은 거절할 동작을 의미
> Resource : Action이 영향을 미치는 리소스 리스트를 지정
> Condition : 조건이 충족되는 경우에는 해당 정책 적용
- 작성되는 정책의 구분 By principal 필드
> Identity-based policies : 사용자, 그룹, 및 롤에 할당하는 IAM 정책으로 Principal 항목 미포함
> Resource-based policies : S3 Bucket, SES Queue 등 AWS 자원에 할당되는 정책으로 Principal 항목 포함
접근 정책 : Identity-based policies
- IAM, 즉 신분 및 접근 관리 정책으로 S3의 객체를 매우 세분화해 통제 가능
- 유저, 그룹, 롤 등 IAM 정책을 정의 (ex. 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 작업 부여
버킷 정책 : Resource-based policies
- 버킷 레벨에서 생성한 정책을 의미하며, S3 버킷을 세분화된 방식으로 제어 가능
- 대표적인 버킷 정책의 사례는 특정 버킷에 있는 객체에 대한 익명의 사용자로부터의 리드 온리 접근을 허용하는 케이스
> S3 리소스 기반의 정적 웹 사이트를 운영하거나, 웹을 통해 불특정다수의 접근을 허용할 때 자주 사용되는 방법으로 버킷에 GetObject 액세스 권한을 부여
(예제) devopscodestates를 위한 S3 버킷 정책, Principal 필드 값을 통해 Read-Only 설정
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"PublicRead",
"Effect":"Allow",
"Principal": "*",
"Action":["s3:GetObject"],
"Resource":["arn:aws:s3:::devopscodestates/*"]
}
]
}
S3의 보안 Best Practice
- 일반적으로 S3 버킷에 대한 퍼블릭 액세스를 불허 : S3 버킷을 퍼블릭 액세스 할 수 있다는 말은 모든 파일이 아무에게나 노출될 수 있다는 의미
- 최소한의 접근 권한 전략을 사용 : S3 버킷에 접근해야 하는 사람에게도 관련 작업에 해당하는 만큼만 권한을 부여하고, 그외 사람에게는 접근 거부 정책을 적용
- 다중인증(MultiFactor Authentication, 이하 MFA) 시스템을 활용 : MFA Delete를 설정하여 데이터 삭제 권한이 없는 사람은 삭제 할 수 없도록 제한
S3 스토리지 클래스
- 참고 레퍼런스 : S3 스토리지 클래스
Amazon S3 스토리지 클래스 사용 - Amazon Simple Storage Service
S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 스토리지 클래스를 선택하면 객체가 Amazon S3에 그대로 유지됩니다. 별도의 Amazon S3 Glacier 서비스를 통해 객체에 직접 액세스할 수 없습니다.
docs.aws.amazon.com
| 스토리지 클래스 | 다음으로 설계됨 | 내구성(설계상) | 가용성(설계상) | 가용 영역 | 최소 스토리지 기간 | 최소 요금 객체 크기 | 기타 고려 사항 |
| S3 Standard | 자주 액세스하는 데이터(한 달에 한 번 이상), 밀리초 단위의 액세스 | 99.999999999% | 99.99% | >= 3 | 없음 | 없음 | 없음 |
| S3 Standard-IA | 밀리초 단위의 액세스로 한 달에 한 번 이따금 액세스하는 수명이 긴 데이터 | 99.999999999% | 99.9% | >= 3 | 30일 | 128KB | GB당 검색 요금이 적용 |
| S3 Intelligent-Tiering | 알 수 없거나 변경되거나 예측할 수 없는 액세스 패턴이 있는 데이터 | 99.999999999% | 99.9% | >= 3 | 없음 | 없음 | 객체당 모니터링 및 자동화 비용이 적용되며 검색 요금이 없음 |
| S3 One Zone-IA | 재생성 가능하고 자주 액세스하지 않는 데이터(한 달에 한 번), 밀리초 단위의 액세스 | 99.999999999% | 99.5% | 1 | 30일 | 128KB | GB당 검색 요금이 적용되며 가용 영역의 손실에 대한 복원력이 없음 |
| S3 Glacier Instant Retrieval | 밀리초 단위의 액세스로 분기에 한 번 액세스하는 수명이 긴 아카이브 데이터 | 99.999999999% | 99.9% | >= 3 | 90일 | 128KB | GB당 검색 요금이 적용 |
| S3 Glacier Flexible Retrieval | 몇 분에서 몇 시간의 검색 시간으로 1년에 한 번 액세스하는 수명이 긴 아카이브 데이터 | 99.999999999% | 99.99%(객체 복원 후) | >= 3 | 90일 | 40KB | GB당 검색 요금이 적용되며 이 객체에 액세스하려면 먼저 보관된 객체를 복원해야 함(자세한 정보는 아카이브된 객체 복원 섹션을 참조) |
| S3 Glacier Deep Archive | 몇 시간의 검색 시간으로 1년에 한 번 미만 액세스하는 수명이 긴 아카이브 데이터 | 99.999999999% | 99.99%(객체 복원 후) | >= 3 | 180일 | 40KB | GB당 검색 요금이 적용되며 이 객체에 액세스하려면 먼저 보관된 객체를 복원해야 함(자세한 정보는 아카이브된 객체 복원 섹션을 참조) |
| RRS(권장되지 않음) | 자주 액세스하는 중요하지 않은 데이터, 밀리초 단위의 액세스 | 99.99% | 99.99% | >= 3 | 없음 | 없음 | 없음 |
4. Storage - EBS (Elastic Block Store)
- EC2 인스턴스에 사용할 수 있는 블록 수준 영구 스토리지(EC2 인스턴스의 수명주기를 넘어서서 존재할 수 있는 스토리지) 볼륨
- EBS 볼륨은 형식이 지정되지 않은 원시 블록 디바이스처럼 동작
> 볼륨 위에 파일 시스템을 생성하거나 하드 드라이브와 같은 블록 디바이스를 사용하는 것처럼 볼륨을 사용 가능
> 인스턴스에 연결된 볼륨의 구성을 동적으로 변경 가능
- EBS 볼륨은 EC2 인스턴스의 부트 파티션으로 사용되거나 실행 중인 EC2 인스턴스의 표준 블록 디바이스로 사용됨
- EC2 인스턴스에 EBS 볼륨을 부착하면, 서버를 위한 하드 드라이브와 같은 기능을 수행
- 하나의 EC2에 여러 개의 EBS 볼륨을 부착 할 수도 있으며 이 경우 부트 볼륨과 데이터 볼륨을 별도로 관리 할 수 있어서 편리
- EC2에 부착한 EBS 볼륨은 언제든 분리 가능하며 다른 EC2에 부착도 가능하지만, EBS 볼륨은 특정 AZ에 속한 자원이기도 하므로, 서로 다른 AZ 간의 EC2에 EBS 볼륨을 분리하고 부착하는 것은 불가능
- EBS 볼륨은 부트 파티션으로도 사용 가능한데, 이 경우 EC2 인스턴스가 정지 후 재시동돼 해당 인스턴스 상태를 유지하기 위한 스토리 리소스로서의 기능만 담당
- EBS 볼륨은 서버 재시동 후에도 유지되므로 기존에 저장된 내용은 그대로 남게 되며 EC2 인스턴스의 로컬 스토리지에 비해 훨씬 높은 수준의 견고성을 제공
- EBS는 볼륨에 대한 특정 시점의 스냅샷을 지속적으로 작성해 S3에 저장하는 방식으로 다수의 AZ에서 자동 복제 기능을 제공
> 생성된 스냅샷은 또 다른 EBS 볼륨 생성을 위한 시작점으로 활용 가능
> 스냅샷을 통해 장기간 서버와 관련된 데이터를 안전하게 보호 가능
> 냅샷은 리전 간 복제해서 사용할 수도 있으므로 재난 복구, 데이터센터 마이그레이션 등에도 편리하게 사용 가능
EBS 볼륨 유형
- 참고 레퍼런스 : EBS 볼륨 유형 관련 레퍼런스
Solid State Drive(SSD) 볼륨
- SSD 지원 볼륨은 작은 I/O 크기의 읽기/쓰기 작업을 자주 처리하며 기준 성능 속성은 IOPS인 트랜잭션 워크로드에 최적화
- SSD 지원 볼륨 유형 : 범용 SSD, 프로비저닝된 IOPS SSD
하드 디스크 드라이브(HDD) 볼륨
- HDD 기반 볼륨은 기준 성능 속성이 스루풋인 대규모 스트리밍 워크로드에 최적화
- HDD 볼륨 유형 : 스루풋 최적화 HDD, 콜드 HDD
Amazon EBS 볼륨 유형 - Amazon Elastic Compute Cloud
마그네틱은 이전 세대 볼륨 유형입니다. 이전 세대 볼륨이 제공할 수 있는 것보다 더 높은 성능 또는 성능 일관성이 필요한 경우 최신 볼륨 유형 중 하나를 사용하는 것이 좋습니다.
docs.aws.amazon.com
5. Storage - EFS (Elastic File System)
- EFS는 서버를 사용하지 않는 간단한 탄력적인 파일 시스템을 제공
- EFS 로 파일 시스템을 생성하고 EC2 인스턴스에 파일 시스템을 탑재한 후 파일 시스템에 데이터를 작성하거나 파일 시스템에서 데이터 읽기 가능
- 애플리케이션을 중단하지 않고 온디맨드 방식으로 페타바이트 규모까지 확장되도록 구축되어, 사용자가 파일을 추가하고 제거할 때 자동으로 확장/축소되므로 데이터 증가에 맞춰 용량을 프로비저닝 및 관리할 필요가 없음
- EFS 는 파일 시스템을 빠르고 쉽게 만들고 구성할 수 있는 간편한 웹 서비스 인터페이스를 제공하며 모든 파일 스토리지 인프라를 관리해 주므로 사용자는 복잡한 파일 시스템 구성을 배포, 패치 및 유지 보수하는데 따르는 복잡성 해소 가능
EFS 스토리지 클래스
- 참고 레퍼런스 : EFS 스토리지 클래스에 대한 레퍼런스
| 스토리지 클래스 | 다음으로 설계됨 | 내구성(설계상) | 가용성 | 가용 영역 | 기타 고려 사항 |
| EFS 스탠다드 | 자주 액세스하는 데이터에는 최고의 내구성과 가용성이 필요 | 99.999999999% (11 9) | 99.99% | >=3 | 없음 |
| EFS 표준—드문 액세스 (IA) | 수명이 길고 액세스 빈도가 낮은 데이터에는 최고의 내구성과 가용성이 필요 | 99.999999999% (11 9) | 99.99% | >=3 | GB당 검색 요금이 적용 |
| EFS One Zone | 자주 액세스하는 데이터로 최고 수준의 내구성과 가용성이 필요하지 않음 | 99.999999999% (11 9) * | 99.90% | 1 | 가용 영역의 손실에 대한 복원력이 없음 |
| EFS One Zone Zone-IA | 수명이 길고 액세스 빈도가 낮은 데이터로 최고 수준의 내구성과 가용성이 필요하지 않음 | 99.999999999% (11 9) * | 99.90% | 1 | 가용 영역의 손실에 대한 복원력이 없으며 GB당 검색 요금이 적용됩니다. |
'devops bootcamp 4 > 클라우드 서비스 운영' 카테고리의 다른 글
| [AWS] 06. VPC (0) | 2023.04.17 |
|---|---|
| [AWS] 05. RDS 관련 개념 (0) | 2023.04.14 |
| [AWS] 03. EC2 관련 개념 (0) | 2023.04.14 |
| [AWS] 02. AWS 서비스 소개 (0) | 2023.04.14 |
| [AWS] 01. 클라우드 컴퓨팅 (0) | 2023.04.14 |
