[AWS EC2] Region, Availability Zone, AWS Local Zone, Wavelength, AWS Outposts 개념 정리

 

l  Version : AWS Elastic Compute Cloud

 

클라우드 서비스의 여러 장점 하나는 다양한 지역에 서비스를 배포하고 원하는 지역에서 빠르게 서비스를 제공할 있는 것이다. Amazon EC2 세계 각지의 여러 곳에서 호스팅 되고 있으며 위치는 리전, 가용 영역, Local Zone, AWS Outposts Wavelength Zone으로 구성된다. 이번 포스트는 이러한 구성에 따른 개념 특징을 정리해 본다.

 

리전(Region)

AWS에는 리전이라는 개념이 있다. AWS 세계에서 데이터 센터를 클러스터링하는 물리적 위치를 리전이라고 한다. 논리적 데이터 센터의 그룹을 가용 영역이라고 하는데, AWS 리전은 지리적 영역 내에서 격리되고 물리적으로 분리된 여러 개의 AZ 구성된다. AZ 독립된 전원, 냉각 물리적 보안을 갖추고 있으며 지연 시간이 매우 짧은 중복 네트워크를 통해 연결된다.

(아래 그림에서 설명은 현재와 맞지 않으므로 그림만 참고한다.)

AWS 북미, 남미, 유럽, 중국, 아시아 태평양, 남아프리카 중동의 리전을 포함하여 여러 지리적 리전을 유지 관리하고 있다. 리전은 추가 또는 변경될 있으므로 최신의 리전 정보는 아래 링크를 참고 한다.

l  리전 엣지 네트워크 : https://aws.amazon.com/ko/about-aws/global-infrastructure/regions_az/

 

글을 쓰는 현재, 세계 26개의 지리적 리전에 84개의 가용 영역을 운영하고 있으며, 호주, 캐나다, 인도, 이스라엘, 뉴질랜드, 스페인, 스위스 아랍에미리트(UAE) 8개의 리전과 24개의 가용영역을 추가할 계획이다.

 

일부 정부기관 중국의 경우 리전 제약이 있으므로 공식 문서를 반드시 확인할 있도록 한다.

 

가용 영역 (Availability Zone)

AZ(가용 영역) AWS 리전의 이중화 전력, 네트워킹 연결이 제공되는 하나 이상의 개별 데이터 센터로 구성된다. AWS 리전의 모든 AZ 높은 대역폭, 지연 시간이 짧은 네트워킹, 완전한 이중화를 갖춘 전용 메트로 네트워크와 상호 연결되어 있어 AZ 간에 높은 처리량과 지연 시간이 짧은 네트워킹을 제공한다. 네트워크 성능은 AZ 동기 복제 기능을 충분히 수행할 있으며 AZ 간의 모든 트래픽은 암호화된다. AZ 다른 모든 AZ 킬로미터에 상당하는 유의미한 거리를 두고 물리적으로 분리되어 있다. 다만 모든 AZ 서로 100km(60마일) 이내의 거리에 위치한다.

(아래 그림에서 설명은 현재와 맞지 않으므로 그림만 참고한다.)

 

AWS Local Zone

AWS 로컬 영역은 컴퓨팅, 스토리지, 데이터베이스 기타 셀렉트 AWS 서비스를 최종 사용자에게 가까운 위치에서 실행할 있게 한다. , 주요 리전이 없는 전략적 위치에 소규모 데이터 센터( AWS Outposts 설계 기반) 구축하여 범위를 확장한다. AWS 로컬 영역을 사용하면 미디어 엔터테인먼트 콘텐츠 작성, 실시간 게임, 저장소 시뮬레이션, 전자 설계 자동화, 기계 학습과 같이 지연 시간이 10밀리초 미만이어야 하는 매우 까다로운 애플리케이션을 쉽게 실행할 있다.

 

AWS 로컬 영역 위치는 최종 사용자에게 근접한 지역에서 Amazon Elastic Compute Cloud, Amazon Virtual Private Cloud, Amazon Elastic Block Store, Amazon File Storage, Amazon Elastic Load Balancing 등의 AWS 서비스를 사용하여 지연 시간에 민감한 애플리케이션을 실행할 있는 AWS 리전의 확장이다. AWS 로컬 영역은 로컬 워크로드와 AWS 리전에서 실행 중인 워크로드 간의 고대역폭 보안 연결을 제공하여 동일한 API 도구 세트를 통해 전체 리전 서비스에 원활하게 다시 연결할 있게 한다.

 

AWS Wavelength

AWS Wavelength 사용하면 개발자가 모바일 디바이스 최종 사용자 측에서 발생하는 지연 시간이 10밀리초 미만인 애플리케이션을 제작할 있다. AWS 개발자는 이동 통신 사업자 데이터 센터 내의 5G 네트워크 엣지에 AWS 컴퓨팅 스토리지 서비스를 포함하는 AWS 인프라 배포 환경인 Wavelength Zone 애플리케이션을 배포하고 해당 리전의 다양한 AWS 서비스에 원활하게 액세스할 있다. 이를 통해 개발자는 게임 라이브 동영상 스트리밍, 엣지의 기계 학습 추론, 증강 가상 현실(AR/VR) 10밀리초 미만의 지연 시간이 요구되는 애플리케이션을 제공할 있다. AWS Wavelength 5G 네트워크 엣지에 AWS 서비스를 제공하여 모바일 디바이스에서 애플리케이션에 연결할 발생하는 지연 시간을 최소화 한다. 애플리케이션 트래픽은 모바일 사업자 네트워크 내의 Wavelength Zone에서 실행되는 애플리케이션 서버로 전송될 있다. 이를 통해 지연 시간이 100밀리초를 초과하게 만들어 고객이 5G 향상된 대역폭 지연 시간을 완전히 활용하지 못하게 있는 인터넷에 대한 추가적인 네트워크 홉이 줄어들게 된다. 아래 그림은 미국 버라이즌 통신사에 구축된 Wavelength 이다.

 

Wavelength 여러 면에서 Outpost 유사하지만 다르다. 물리적으로 엣지 액세스에서 컴퓨팅을 제공하는 개념은 비슷하지만 Wavelength 주요 목표는 가용성 영역과 같은 리전의 확장이다. Wavelength 데이터 센터에서 물리적으로 구매하고 컴퓨팅을 배치할 필요가 없다는 점에서 매우 유사하지만 이동 통신사에서 제공된다.

 

AWS Outposts

AWS Outposts() AWS 인프라, 서비스, API 도구를 고객 온프레미스로 확장하는 완전관리형 서비스이다. AWS 관리형 인프라에 대한 로컬 액세스를 제공하는 AWS Outposts() 통해 고객은 AWS 리전에서 사용하는 것과 동일한 프로그래밍 인터페이스를 사용해 온프레미스에서 애플리케이션을 구축하고 실행할 있으며, 짧은 지연 시간과 로컬 데이터 처리가 필요한 경우에 로컬 컴퓨팅 스토리지 리소스를 사용할 있다. , 데이터 센터 또는 코로케이션 시설에 설치형 기반 솔루션을 제공하여 AWS 기술 서비스를 사용하는 것이다.

 

Outposts 고객 사이트에 배포된 AWS 컴퓨팅 스토리지 용량 풀이다. AWS 용량을 AWS 리전의 일부로 운영, 모니터링 관리한다. Outposts 서브넷을 만들고 EC2 인스턴스, EBS 볼륨, ECS 클러스터 RDS 인스턴스와 같은 AWS 리소스를 생성할 해당 서브넷을 지정할 있다. Outposts 서브넷의 인스턴스는 프라이빗 IP 주소를 사용하여 AWS 리전의 다른 인스턴스와 통신한다 (모두 동일한 VPC 있음).

 

아래 그림은 Outposts 서비스에 사용되는 랙의 모습이다.

 

 

 

 

 

[참고자료]

l  글로벌 인프라 : https://aws.amazon.com/ko/about-aws/global-infrastructure/

l  리전 영역 : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#az-ids

l  리전 가용 영역 : https://aws.amazon.com/ko/about-aws/global-infrastructure/regions_az/

l  AWS Outposts : https://docs.aws.amazon.com/ko_kr/outposts/latest/userguide/what-is-outposts.html

l  Local Zone: https://aws.amazon.com/blogs/aws/announcing-a-second-local-zone-in-los-angeles/

l  Outpost vs Azure MEC: https://msandbu.org/amazon-outpost-vs-azure-stack-hub/  https://noise.getoto.net/2019/12/03/aws-now-available-from-a-local-zone-in-los-angeles/

 

2022-05-08 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, Region, Availability Zone, Local Zone, Wavelength Zone, Outposts

[AWS RDS] Devops Guru for RDS 기능을 사용하여 데이터베이스의 이상 현상을 사전에 감지하기

 

l  Version : Devops Guru for RDS

 

이전 포스트에서 AWS Performance Insight(성능 개선 도우미) 사용하여 데이터베이스 운영에 필요한 다양한 지표 쿼리 관련 모니터링에 대해서 살펴 보았다.

l  [AWS RDS] Performance Insight DB부하의 원인 찾기 : https://sungwookkang.com/1503

 

이러한 모니터링은 데이터를 수집하고 관리자가 대시보드를 통한 정보 확인후 문제점 여부를 확인하는데 매우 도움이 된다. 하지만 조금 발전시켜 이러한 이상 현상을 사전에 탐지하고 진단 결과를 알려준다면 조금 빠르게 사전 대응이 가능하지 않을까 생각해 있다. 물론 AWS CloudWatch 사용하여 이상 패턴 발견 SNS 등을 사용하여 알림을 보낼 수도 있지만, 알림은 단순 임계치 값에서 변경이 발생하였을 경우에만 가능 하기 때문에 아래 솔루션을 사용하면 조금 스마트한 모니터링 병목 구간에 대한 진단이 가능하다.

 

Amazon DevOps Guru for RDS 기계 학습(ML) 기반으로 하는 서비스로 모든 AWS RDS 엔진에서 사용할 있으며 이를 통해 애플리케이션의 운영 성능 가용성을 쉽게 개선할 있다.

l  Amazon DevOps Guru for RDS : https://aws.amazon.com/ko/devops-guru/features/devops-guru-for-rds/

 

서비스는 ML 사용하여 호스트 리소스의 과도한 사용, 데이터베이스 병목 현상 또는 SQL 쿼리의 오작동과 같은 광범위한 성능 관련 데이터베이스 문제를 자동으로 식별하고 분석한다. 또한 발견한 문제를 수정하기 위한 가이드라인을 제공한다. 이상 현상이 감지되면 콘솔에서 결과를 확인할 있을 뿐만 아니라 Amazon Event Bridge또는 Amazon SNS 사용하여 알림을 보낼 있다.

 

 

 DevOps Guru for RDS 사용하기 위해서는 Amazon Console에서 RDS 성능 개선 도우미(Performance Insight) 활성화 DevOps Guru 콘솔로 이동하여 활성화 한다.

 

RDS DevOps Guru 데이터베이스 로드(DB Load) 성능 메트릭에서 이상 감지를 사용하여 문제를 감지한다. DB 로드는 AAS(Average Active Sessions) 단위로 측정된다. DB 로드는 데이터베이스의 활동 수준을 측정하므로 DB 부하가 높으면 성능 문제가 발생할 있다. 메트릭은 가상 CPU(vCPU) 수와 비교할 있으며, DB 부하가 수보다 높으면 문제가 발생할 있다.

 

아래 그림은 DevOps Guru for RDS리포트 결과로, 그래프는 AAS에서 대부분이 테이블 또는 CPU 대한 액세스를 기다리고 있음을 보여준다. 대기 이벤트는 현재 실행 중인 SQL 기다리고 있는 상태로 가장 일반적인 이유는 CPU 기다리거나 읽기 또는 쓰기를 기다리거나 잠긴 리소스를 기다리는 상태이다. Top SQL 차원은 DB 로드에 가장 많이 기여하는 쿼리를 보여준다.

 

DevOps Guru for RDS 분석 페이지에서는 문제의 원인과 해결을 위한 가지 권장 사항도 보여주는데 메트릭에서의 이상 징후는 높은 로드 대기 이벤트와 CPU 용량 초과라는 가지 문제가 감지되었다. 그리고 아래와 같은 분석결과는 나타내었다.

l  IO CPU 대기 유형에 대한 27개의 AAS 있는 고부하 대기 이벤트를 있으며 전체 DB 로드의 99%이다.

l  실행 중인 작업이 6 프로세스를 초과했음을 알려준다. 데이터베이스에는 2개의 vCPU 있으며 권장되는 실행 프로세스 수는 최대 4(vCPU 2)여야 한다.

 

다른 예외에서 그래프는 대기 이벤트의 로드가 높았고 하나의 SQL 쿼리에 추가 조사가 필요한 것으로 나타났다. SQL 다이제스트 ID 클릭하면 정확한 SQL 쿼리를 수도 있다. 예를 들어 대기 이벤트 wait/io/table/sql/handler 또는 문제 해결 문서 보기 링크에서 대기 이벤트를 클릭하면 자세한 정보를 많이 얻을 있다.

 

 

외에도 데이터베이스 분석을 보려면 Insight 페이지로 이동하여 분석 정보를 확인할 있다.

 

 

 

[참고자료]

-          Amazon DevOps Guru for RDS : https://aws.amazon.com/ko/devops-guru/features/devops-guru-for-rds/

-          Amazon DevOps Guru for RDS to Detect, Diagnose, and Resolve Amazon Aurora-Related Issues using ML : https://aws.amazon.com/ko/blogs/aws/new-amazon-devops-guru-for-rds-to-detect-diagnose-and-resolve-amazon-aurora-related-issues-using-ml/

 

 

 

 

2022-04-25 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, RDS, Performance Insight, 성능 개선 도우미, DB 모니터링, 쿼리 모니터링, DB 성능 개선, DevOps Guru for RDS, 사전탐지, 장애방지, 장애대응

[AWS RDS] Performance Insight DB부하의 원인 찾기

 

l  Version : Performance Insight

 

AWS RDS 데이터베이스를 사용할 , 데이터베이스 인스턴스의 성능 지표 로그를 CloudWatch에서 수집하여 여러 성능 지표에 대한 모니터링을 진행할 있다. 하지만 슬로우 쿼리, 대기정보, 세션별 쿼리 실행 데이터베이스를 운영하기 위해 조금 자세한 정보를 확인하려면 RDS 성능 개선 도우미(Performance Insight) 사용할 있다.

 

성능 개선 도우미를 사용하려면 DB 인스턴스 또는 다중 AZ DB 클러스터에서 활성화 해야한다. 필요에 따라 활성/비활성이 가능하며, 상태 변경 재부팅 또는 장애조치가 발생하지 않는다. 성능 개선 도우미를 사용하면 에이전트가 실행되는데 이때 약간의 오버헤드가 발생하기 때문에 DB 로드가 높은 경우 수집 빈도를 조절하여 사용할 있도록 한다.

 

성능 개선 도우미는 콘솔에서 쉽게 설정이 가능하며 AWS CLI RDS API 통해서도 설정이 가능하다.

 

성능 개선 도우미의 활성화에 대한 자세한 내용은 아래 공식 문서를 참고 한다.

l  성능 개선 도우미 설정 해제 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Enabling.html

 

성능 개선 도우미에 액세스 하려면 IAM(Identity and Access Management) 적절한 권한이 있어야 한다. IAM 대한 정책은 아래 문서를 참고한다.

l  Performance Insights 대한 액세스 정책 구성 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.access-control.html

 

성능 개선 도우미의 대시 보드는 기본적으로 마지막 1시간 동안 수집된 데이터를 표시한다.

 

대시보드는 아래와 같이 부분으로 나눌 있다.

l  카운터 지표 : 특정 성능 카운터 지표의 데이터를 표시

l  DB 부하 차트 : DB 부하와 DB 인스턴스 용량을 비교하여 최대 vCPU 선으로 표시

l  상위 항목(Top Item) : DB 로드에 기여하는 상이 차원을 표시

 

부분에 대한 자세한 내용은 아래 링크를 참고한다.

l  성능 개선 도우미 대시보드 개요 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.Components.html

 

대시보드 화면의 데이터베이스 로드(Database load) 차트에서는 병목 현상에 대한 정보를 확인할 있다. 어떤 데이터베이스 로그가 최대 CPU(Max CPU) 선을 상회하는지 확인할 있고 어떤 작업이 DB 부하를 차지하는지 보여준다. 아래 그림에서는 로그 파일 동기화 대기 시간이 대부분의 DB 부하를 차지한다. 그리고 LGWR all worker groups 대기 시간도 높다. TOP SQL 차트는 로그 파일 동기화 대기의 원인에 사용된 SQL 구문인 COMMIT 문을 보여준다.

 

TOP SQL 에서는 데이터베이스 로드에 영향을 미치는 상위 SQL 쿼리가 표시된다. TOP SQL 탭에서는  SQL 통계(SQL Statistics) 대기별 로드(AAS), SQL 정보, 환경설정 정보 등을 확인할 있다.

 

SQL 통계 (SQL Statistics) SQL 쿼리에 대한 성능 관련 지표이다. 초당 실행 횟수 초당 처리된 행을 표시한다.

 

 

대기 시간별 로드(Load by waits AAS) 상위 로드 항목과 연결된 데이터베이스 로드의 비율을 나타낸다. 예를 들어 DB 로드 차트를 대기 상태별로 그룹화 있다. 쿼리가 영향을 미치는 대기 상태의 정도를 크기, 세그먼트 컬러 코드로 표시한다.

 

 

SQL 정보에서는 TOP SQL 실행된 쿼리와 SQL ID, Support Digest ID등을 확인할 있다.

 

환경설정에서는 수집되는 항목을 설정 있다.

 

 

위에서 나열한 항목의 자세한 내용은 아래 공식 문서를 참고 한다.

l  상위 SQL(Top SQL) 개요 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.html

 

 

기본적으로 TOP SQL 테이블의 행에는 SQL 문에 대해 500 byte SQL 텍스트가 표시된다. SQL 문이 500byte 이상인 경우 성능 개선 도우미 대시보드에서 해당문을 열어 많은 텍스트를 있다. 경우 최대 4KB까지 표시된다. 또한 쿼리를 다운로드 있다. TOP SQL 텍스트에 대한 자세한 내용은 아래 문서를 참고 한다.

l  SQL 문의 텍스트 액세스 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.SQLTextSize.html

 

 

성능 개선 도우미를 사용할 있는 RDS 엔진 버전은 지속적으로 업데이트 되므로 항상 최신의 정보를 확인할 있도록 아래 링크의 공식 문서를 참고한다. 현재 Aurora 서버리스는 성능 개선 도우미를 지원하지 않는다.

l  Amazon RDS DB 엔진의 성능 개선 도우미 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Engines.html

 

성능개선 도우미는 대부분의 리전에서 사용 가능하며, 아래 링크를 참고한다.

l  AWS성능 개선 도우미를 위한 리전 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Regions.html

 

 

 

[참고자료]

l  성능 개선 도우미 설정 해제 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Enabling.html

l  Performance Insights 대한 액세스 정책 구성 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.access-control.html

l  성능 개선 도우미 대시보드 개요 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.Components.html

l  SQL 문의 텍스트 액세스 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.SQLTextSize.html

l  Amazon RDS DB 엔진의 성능 개선 도우미 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Engines.html

l  Amazon RDS DB 엔진의 성능 개선 도우미 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Engines.html

 

 

2022-04-24 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, RDS, Performance Insight, 성능 개선 도우미, DB 모니터링, 쿼리 모니터링, DB 성능 개선

[AWS S3] Amazon s3 연결 URI 형식(s3://, s3a://, s3n://) 다른 차이점은 무엇일까?

 

l  Version : AWS Simple Storage Service(S3)

 

AWS에서 제공하는 스토리지 서비스에는 Amazon S3(Simple Storage Service)라고 불리는 오브젝트 스토리지가 있다. Amazon S3 여러 사용 사례에 맞춰 다양한 스토리지 클래스를 제공한다. 예를 들어 자주 액세스 하기 위해 미션 크리티컬 프로덕션 데이터는 S3 Standard 저장하고, 액세스 빈도가 낮은 데이터는 S3 Standard-IA 또는 S3 One Zone-IA 저장하여 비용을 절감하고, S3 Glacier Flexible Retrieval S3 Glacier Deep Archive 가장 낮은 비용으로 데이터를 보관할 있다. 또한 액세스 패턴을 예측할 없거나 자주 변경되는 경우 S3 Intelligent-Tiering 저장하면 액세스 패턴에 따라 자동으로 4계의 액세스 계층 간에 데이터를 자동으로 이동하여 스토리지 비용을 최적화 있다.

 

Amazon S3 버킷을 생성하고 폴더에 접근할 고유한 URI 사용하게 되는데, 일반적인 URI 형식은 s3://bucket-name/folder-name/ 형식으로 생성된다. 그런데 가끔 S3 연결할 URI 형식이 조금씩 다른 s3://, s3a://, s3n:// 경우가 있다. URI 대한 차이점이 무엇인지 살펴보자. 차이점에 대해서 알아보기 전에 S3 File System 아닌 Object Storage라는 점을 다시 한번 인지하고, S3 분산 저장하는 경우 Hadoop 클라이언트를 거쳐 저장하게 된다. Hadoop S3N, S3A, S3 이렇게 세가지 시스템이 클라이언트를 제공한다.

 

S3N (URI 형식: s3n://)

l  S3에서 일반 파일을 읽고 쓰기 위한 기본 파일 시스템

l  안정적이며 널리 알려져 있지만 현재 업데이트가 중단된 상태

l  다른 도구로 작성된 S3 파일에 액세스가능. 반대로 다른 도구는 Hadoop 사용하여 작성된 파일에 액세스 가능

l  S3에서 저장할 있는 단일 파일 크기에 대한 5GB 제한있음

 

S3A (URI 형식: s3a://)

l  S3 Native s3n fs 후속

l  Amazon 라이브러리를 사용하여 S3 상호 작용

l  S3a 파일(5GB 제한 없음), 고성능 작업 등을 지원 가능

l  s3n://URL에서 액세스할 있는 모든 객체는 URL 스키마를 교체하는 것만으로 s3a에서도 액세스 가능

 

S3 (URI 형식: s3://)

l  S3 지원하는 블록 기반 파일 시스템

l  파일은 HDFS 있는 것처럼 블록으로 저장

l  파일 시스템을 사용하려면 파일 시스템 전용 버킷이 필요

l  파일이 포함된 기존 버킷을 사용하거나 다른 파일을 동일한 버킷에 쓰지 않아야

l  파일 시스템에 의해 저장된 파일은 5GB보다 있지만 다른 S3 도구와 상호 운용할 없음

 

AWS EMR 경우에는 별도로 EMRFS라는 파일 시스템이 존재한다. 그래서 EMR S3 파일 시스템과 Hadoop에서의 S3 파일 시스템은 서로 다르기 때문에 사용할 주의해야 한다. 따라서 ERM 경우 S3 사용하는 것을 권장하고 있다. 하지만 s3a 경우 EMRFS 호환되지 않기 때문에 오류가 발생할 있다.

 

자체 Hadoop 사용하면서 데이터 저장소만 Amazon S3 사용할 경우 S3A 사용하면 자체 하둡에서 S3 저장소를 연결하여 객체를 직접 읽고 있다.  S3A 탄생 배경에 대해 궁금하다면 아래 블로그를 참고할 있다.

l  Community collaboration: The S3A story : https://aws.amazon.com/ko/blogs/opensource/community-collaboration-the-s3a-story/

 

 

[참고자료]

l  What is Amazon S3 : https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html

l  Work with storage and file systems : https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-file-systems.html

l  Community collaboration: The S3A story : https://aws.amazon.com/ko/blogs/opensource/community-collaboration-the-s3a-story/

l  Enabling Amazon Simple Storage Service (Amazon S3) Access Points in Apache Hadoop S3A : https://aws.amazon.com/ko/blogs/opensource/enabling-amazon-simple-storage-service-s3-access-points-in-apache-hadoop-s3a/

 

 

2022-04-20 / Sungwook Kang / http://sungwookkang.com

 

 

AWS Simple Storage Service, S3, S3N, S3A, EMR, EMRFS

+ Recent posts