민감한 데이터를 보호하기 위해 AWS에서 가명화 서비스 구축: 2부 | Amazon Web Services

파트 1 두 부분으로 구성된 이 시리즈에서는 일반 텍스트 데이터 속성을 가명으로 또는 그 반대로 변환하는 가명화 서비스를 구축하는 방법을 설명했습니다. 중앙 집중식 가명화 서비스는 가명 생성을 위해 독특하고 보편적으로 인식되는 아키텍처를 제공합니다. 결과적으로 조직은 모든 플랫폼에서 민감한 데이터를 처리하는 표준 프로세스를 달성할 수 있습니다. 또한 이를 통해 개발 팀과 분석 사용자의 다양한 규정 준수 요구 사항을 이해하고 구현하는 데 필요한 복잡성과 전문 지식이 제거되어 비즈니스 결과에 집중할 수 있습니다.

분리된 서비스 기반 접근 방식을 따른다는 것은 조직으로서 비즈니스 문제를 해결하기 위해 특정 기술을 사용하는 데 편견이 없다는 것을 의미합니다. 개별 팀이 어떤 기술을 선호하든 상관없이 가명화 서비스를 호출하여 민감한 데이터를 가명화할 수 있습니다.

이 게시물에서는 가명처리 서비스를 사용할 수 있는 일반적인 ETL(추출, 변환 및 로드) 소비 패턴에 중점을 둡니다. ETL 작업에서 가명화 서비스를 사용하는 방법에 대해 논의합니다. 아마존 EMR (사용 EC2의 Amazon EMR) 스트리밍 및 일괄 사용 사례의 경우. 또한 다음을 찾을 수 있습니다. 아마존 아테나 과 AWS 접착제 기반 소비 패턴 GitHub 레포 솔루션의.

솔루션 개요

다음 다이어그램은 솔루션 아키텍처를 설명합니다.

오른쪽 계정은 이 시리즈의 1부에서 제공된 지침을 사용하여 배포할 수 있는 가명화 서비스를 호스팅합니다.

왼쪽 계정은 이 게시물의 일부로 설정한 계정으로, 가명처리 서비스를 사용하는 Amazon EMR 기반 ETL 플랫폼을 나타냅니다.

동일한 계정에 가명처리 서비스와 ETL 플랫폼을 배포할 수 있습니다.

Amazon EMR을 사용하면 Apache Spark와 같은 빅 데이터 프레임워크를 빠르고 비용 효율적으로 생성, 운영 및 확장할 수 있습니다.

이 솔루션에서는 가명처리 서비스를 사용하는 방법을 보여줍니다. 아마존 EMR 과 아파치 스파크 일괄 및 스트리밍 사용 사례에 적합합니다. 배치 애플리케이션은 다음 위치에서 데이터를 읽습니다. 아마존 단순 스토리지 서비스 (Amazon S3) 버킷, 스트리밍 애플리케이션은 다음에서 레코드를 사용합니다. Amazon Kinesis 데이터 스트림.

일괄 및 스트리밍 작업에 사용되는 PySpark 코드

두 애플리케이션 모두 가명처리에 연결된 API 게이트웨이에 대해 HTTP POST 호출을 수행하는 공통 유틸리티 기능을 사용합니다. AWS 람다 기능. REST API 호출은 Spark RDD를 사용하여 Spark 파티션별로 이루어집니다. 지도파티션 기능. POST 요청 본문에는 지정된 입력 열에 대한 고유 값 목록이 포함되어 있습니다. POST 요청 응답에는 해당하는 가명화된 값이 포함되어 있습니다. 코드는 특정 데이터 세트에 대해 민감한 값을 가명처리된 값으로 바꿉니다. 결과는 Amazon S3에 저장되며 AWS 접착제 Apache를 사용하는 데이터 카탈로그 빙산 테이블 형식.

Iceberg는 ACID 트랜잭션, 스키마 진화 및 시간 여행 쿼리를 지원하는 개방형 테이블 형식입니다. 이러한 기능을 사용하여 다음을 구현할 수 있습니다. 잊혀 질 권리 (또는 데이터 삭제) SQL 문이나 프로그래밍 인터페이스를 사용하는 솔루션입니다. Iceberg는 버전 6.5.0, AWS Glue 및 Athena부터 Amazon EMR에서 지원됩니다. 배치 및 스트리밍 패턴은 Iceberg를 대상 형식으로 사용합니다. Iceberg를 사용하여 ACID 호환 데이터 레이크를 구축하는 방법에 대한 개요는 다음을 참조하세요. Amazon EMR에서 Apache Iceberg를 사용하여 고성능, ACID 준수, 진화하는 데이터 레이크 구축.

사전 조건

다음 전제 조건이 있어야 합니다.

An AWS 계정.
An AWS 자격 증명 및 액세스 관리 (IAM) 배포 권한이 있는 주체 AWS 클라우드 포메이션 스택 및 관련 리소스.
XNUMXD덴탈의 AWS 명령 줄 인터페이스 (AWS CLI) 제공된 스크립트를 실행하는 데 사용할 개발 또는 배포 머신에 설치됩니다.
솔루션이 배포될 동일한 계정 및 AWS 리전에 있는 S3 버킷.
Python3 명령이 실행되는 로컬 시스템에 설치됩니다.
PyYAML 사용하여 설치 삐악 삐악 울다.
CloudFormation 스택을 배포하는 bash 스크립트를 실행하는 bash 터미널.
Parquet 파일의 입력 데이터 세트를 포함하는 추가 S3 버킷(배치 애플리케이션에만 해당) 복사 샘플 데이터 세트 S3 버킷에.
사본 최신 코드 저장소 로컬 컴퓨터에서 다음을 사용하여 git clone 또는 다운로드 옵션.

새 bash 터미널을 열고 복제된 저장소의 루트 폴더로 이동합니다.

제안된 패턴의 소스코드는 복제된 저장소에서 확인하실 수 있습니다. 다음 매개변수를 사용합니다.

ARTEFACT_S3_BUCKET – 인프라 코드가 저장될 S3 버킷입니다. 버킷은 솔루션이 있는 동일한 계정 및 리전에 생성되어야 합니다.
AWS_지역 – 솔루션이 배포될 지역입니다.
AWS_프로필 – 다음에 적용될 명명된 프로필 AWS CLI 명령. 여기에는 관련 리소스의 CloudFormation 스택을 배포할 수 있는 권한이 있는 IAM 주체에 대한 자격 증명이 포함되어야 합니다.
SUBNET_ID – EMR 클러스터가 가동될 서브넷 ID입니다. 서브넷은 이미 존재하며 데모 목적으로 기본 VPC의 기본 서브넷 ID를 사용합니다.
EP_URL – 가명처리 서비스의 엔드포인트 URL입니다. 다음과 같이 배포된 솔루션에서 이를 검색합니다. 파트 1 이 시리즈의.
API_SECRET - 아마존 API 게이트웨이 키 다음에 저장될 것입니다. AWS 비밀 관리자. API 키는 다음에 설명된 배포에서 생성됩니다. 파트 1 이 시리즈의.
S3_INPUT_PATH – 입력 데이터 세트가 Parquet 파일로 포함된 폴더를 가리키는 S3 URI입니다.
KINESIS_DATA_STREAM_NAME - CloudFormation 스택과 함께 배포된 Kinesis 데이터 스트림 이름입니다.
BATCH_SIZE - 배치당 데이터 스트림에 푸시할 레코드 수입니다.
THREADS_NUM - 데이터 스트림에 데이터를 업로드하기 위해 로컬 시스템에서 사용되는 병렬 스레드 수입니다. 스레드가 많을수록 메시지 볼륨이 높아집니다.
EMR_CLUSTER_ID – 코드가 실행될 EMR 클러스터 ID입니다(EMR 클러스터는 CloudFormation 스택에 의해 생성되었습니다).
스택_이름 – 배포 스크립트에 할당된 CloudFormation 스택의 이름입니다.

일괄 배포 단계

전제 조건에 설명된 대로 솔루션을 배포하기 전에 Parquet 파일을 업로드합니다. 테스트 데이터 세트 아마존 S3로. 그런 다음 파일이 포함된 폴더의 S3 경로를 매개변수로 제공합니다. <S3_INPUT_PATH>.

AWS CloudFormation을 통해 솔루션 리소스를 생성합니다. 다음을 실행하여 솔루션을 배포할 수 있습니다. 배포_1.sh 내부에 있는 스크립트 deployment_scripts 폴더에 있습니다.

배포 필수 구성 요소가 충족되면 다음 명령을 입력하여 솔루션을 배포합니다.

sh ./deployment_scripts/deploy_1.sh 
-a <ARTEFACT_S3_BUCKET> 
-r <AWS_REGION> 
-p <AWS_PROFILE> 
-s <SUBNET_ID> 
-e <EP_URL> 
-x <API_SECRET> 
-i <S3_INPUT_PATH>

출력은 다음 스크린샷과 같아야 합니다.

정리 명령에 필요한 매개변수는 명령 실행이 끝날 때 인쇄됩니다. deploy_1.sh 스크립트. 이러한 값을 기록해 두십시오.

배치 솔루션 테스트

다음을 사용하여 배포된 CloudFormation 템플릿에서 deploy_1.sh 스크립트, 다음을 포함하는 EMR 단계 스파크 배치 애플리케이션 EMR 클러스터 설정이 끝나면 추가됩니다.

결과를 확인하려면 변수를 사용하여 CloudFormation 스택 출력에서 식별된 S3 버킷을 확인하세요. SparkOutputLocation.

Athena를 사용하여 다음을 수행할 수도 있습니다. 테이블을 쿼리하다 pseudo_table 데이터베이스에서 blog_batch_db.

일괄 리소스 정리

이 연습의 일부로 생성된 리소스를 파괴하려면

Bash 터미널에서 복제된 저장소의 루트 폴더로 이동합니다. 이전 실행의 출력으로 표시된 정리 명령을 입력하십시오. 배포_1.sh 스크립트:

sh ./deployment_scripts/cleanup_1.sh 
-a <ARTEFACT_S3_BUCKET> 
-s <STACK_NAME> 
-r <AWS_REGION> 
-e <EMR_CLUSTER_ID>

출력은 다음 스크린샷과 같아야 합니다.

스트리밍 배포 단계

AWS CloudFormation을 통해 솔루션 리소스를 생성합니다. 다음을 실행하여 솔루션을 배포할 수 있습니다. 배포_2.sh 내부에 있는 스크립트 deployment_scripts 폴더. 이 패턴에 대한 CloudFormation 스택 템플릿은 다음에서 사용할 수 있습니다. GitHub 레포.

배포 필수 구성 요소가 충족되면 다음 명령을 입력하여 솔루션을 배포합니다.

sh deployment_scripts/deploy_2.sh 
-a <ARTEFACT_S3_BUCKET> 
-r <AWS_REGION> 
-p <AWS_PROFILE> 
-s <SUBNET_ID> 
-e <EP_URL> 
-x <API_SECRET>

출력은 다음 스크린샷과 같아야 합니다.

정리 명령에 필요한 매개변수는 명령의 출력 끝에 인쇄됩니다. 배포_2.sh 스크립트. 나중에 사용할 수 있도록 이 값을 저장해 두십시오.

스트리밍 솔루션 테스트

다음을 사용하여 배포된 CloudFormation 템플릿에서 deploy_2.sh 스크립트, 다음을 포함하는 EMR 단계 스파크 스트리밍 애플리케이션 EMR 클러스터 설정이 끝나면 추가됩니다. 엔드투엔드 파이프라인을 테스트하려면 배포된 Kinesis 데이터 스트림에 레코드를 푸시해야 합니다. Bash 터미널에서 다음 명령을 사용하면 프로세스가 수동으로 중지될 때까지 스트림에 레코드를 지속적으로 저장하는 Kinesis 생산자를 활성화할 수 있습니다. 수정하여 생산자의 메시지 볼륨을 제어할 수 있습니다. BATCH_SIZE 그리고 THREADS_NUM 변수.

python3 -m pip install kiner
python3 
consumption-patterns/emr/1_pyspark-streaming/kinesis_producer/producer.py 
<KINESIS_DATA_STREAM_NAME> 
<BATCH_SIZE> 
<THREADS_NUM>

결과를 확인하려면 변수를 사용하여 CloudFormation 스택 출력에서 식별된 S3 버킷을 확인하세요. SparkOutputLocation.

Athena 쿼리 편집기에서 다음을 쿼리하여 결과를 확인합니다. table pseudo_table 데이터베이스에서 blog_stream_db.

스트리밍 리소스 정리

이 연습의 일부로 생성된 리소스를 삭제하려면 다음 단계를 완료하세요.

이전 섹션의 bash 터미널에서 시작된 Python Kinesis 생산자를 중지합니다.
다음 명령을 입력하십시오.

sh ./deployment_scripts/cleanup_2.sh 
-a <ARTEFACT_S3_BUCKET> 
-s <STACK_NAME> 
-r <AWS_REGION> 
-e <EMR_CLUSTER_ID>

출력은 다음 스크린샷과 같아야 합니다.

성능 세부정보

사용 사례는 데이터 크기, 컴퓨팅 용량 및 비용과 관련된 요구 사항이 다를 수 있습니다. 우리는 성능에 영향을 미칠 수 있는 몇 가지 벤치마킹 및 요소를 제공했습니다. 그러나 특정 요구 사항을 충족하는지 확인하려면 더 낮은 환경에서 솔루션을 검증하는 것이 좋습니다.

가명처리 서비스에 대한 최대 병렬 호출 수와 각 호출의 페이로드 크기에 따라 제안된 솔루션(Amazon EMR을 사용하여 데이터 세트를 가명화하는 것을 목표로 함)의 성능에 영향을 미칠 수 있습니다. 병렬 호출 측면에서 고려해야 할 요소는 다음과 같습니다. Secrets Manager의 GetSecretValue 호출 제한 (초당 10.000, 하드 제한) 및 Lambda 기본 동시성 병렬 처리(기본적으로 1,000, 할당량 요청으로 늘릴 수 있음). 실행기 수, 데이터 세트를 구성하는 파티션 수, 클러스터 구성(노드 수 및 유형)을 조정하여 최대 병렬 처리량을 제어할 수 있습니다. 각 호출의 페이로드 크기 측면에서 고려해야 할 요소는 다음과 같습니다. API 게이트웨이 최대 페이로드 크기(6MB) Lambda 함수 최대 런타임(15분). 각 API 호출마다 가명처리할 항목 수를 결정하는 PySpark 스크립트의 매개변수인 배치 크기 값을 조정하여 페이로드 크기와 Lambda 함수 런타임을 제어할 수 있습니다. 이러한 모든 요소의 영향을 포착하고 Amazon EMR을 사용하여 소비 패턴의 성능을 평가하기 위해 다음 시나리오를 설계하고 모니터링했습니다.

일괄 소비 패턴 성능

배치 소비 패턴의 성능을 평가하기 위해 각각 1MB의 Parquet 파일 10개, 100개, 97.7개로 구성된 XNUMX개의 입력 데이터 세트를 사용하여 가명화 애플리케이션을 실행했습니다. 우리는 다음을 사용하여 입력 파일을 생성했습니다. 데이터 세트_generator.py 스크립트.

클러스터 용량 노드는 기본 1개(m5.4xlarge)와 코어 15개(m5d.8xlarge)였습니다. 이 클러스터 구성은 세 가지 시나리오 모두에서 동일하게 유지되었으며 Spark 애플리케이션이 최대 100개의 실행기를 사용할 수 있었습니다. 그만큼 batch_size이는 세 가지 시나리오에서도 동일했으며 API 호출당 900VIN으로 설정되었으며 최대 VIN 크기는 5바이트였습니다.

다음 표에는 세 가지 시나리오에 대한 정보가 나와 있습니다.

실행 ID	파티션 나누기	데이터세트 크기	실행자 수	실행자당 코어	실행자 메모리	런타임
A	800	9.53 GB	100	4	4 GiB	11 분 10 초
B	80	0.95 GB	10	4	4 GiB	8 분 36 초
C	8	0.09 GB	1	4	4 GiB	7 분 56 초

보시다시피 가명화 서비스에 대한 호출을 적절하게 병렬화하면 전체 런타임을 제어할 수 있습니다.

다음 예에서는 가명처리 서비스에 대한 세 가지 중요한 Lambda 지표를 분석합니다. Invocations, ConcurrentExecutions및 Duration.

다음 그래프는 Invocations 통계와 함께 측정항목 SUM 오렌지색과 RUNNING SUM 파란색으로.

누적 호출의 시작점과 끝점의 차이를 계산하여 각 실행 동안 몇 번의 호출이 이루어졌는지 추출할 수 있습니다.

실행 ID	데이터세트 크기	총 호출
A	9.53 GB	1.467.000-0 = 1.467.000
B	0.95 GB	1.467.000-1.616.500 = 149.500
C	0.09 GB	1.616.500-1.631.000 = 14.500

예상대로 호출 수는 데이터 세트 크기에 비례하여 10씩 증가합니다.

다음 그래프는 총계를 나타냅니다. ConcurrentExecutions 통계와 함께 측정항목 MAX 파란색으로.

애플리케이션은 병렬로 처리할 수 있는 Spark 작업(Spark 데이터 세트 파티션)의 양에 따라 최대 동시 Lambda 함수 실행 수가 제공되도록 설계되었습니다. 이 숫자는 다음과 같이 계산할 수 있습니다. MIN (집행자 x executor_cores, Spark 데이터 세트 파티션).

테스트에서 A는 각각 800개의 코어가 있는 100개의 실행기를 사용하여 400개의 파티션을 처리했습니다. 이렇게 하면 400개의 작업이 병렬로 처리되므로 Lambda 함수 동시 실행은 400을 초과할 수 없습니다. 실행 B와 C에 동일한 논리가 적용되었습니다. 이전 그래프에 반영된 것을 볼 수 있습니다. 40, 4, XNUMX개 값.

조절을 방지하려면 병렬로 처리할 수 있는 Spark 작업의 양이 Lambda 함수 동시성 제한을 초과하지 않는지 확인하십시오. 이 경우 Lambda 함수 동시성 제한을 늘리거나(성능을 유지하려는 경우) 파티션 수 또는 사용 가능한 실행기 수를 줄여야 합니다(애플리케이션 성능에 영향을 미침).

다음 그래프는 Lambda를 보여줍니다. Duration 통계와 함께 측정항목 AVG 오렌지색과 MAX 녹색.

예상한 대로 데이터 세트의 크기는 가명화 기능 실행 기간에 영향을 미치지 않습니다. 이는 콜드 스타트에 직면한 일부 초기 호출을 제외하고 세 가지 시나리오 전체에서 평균 3밀리초로 일정하게 유지됩니다. 이는 각 가명화 호출에 포함되는 최대 기록 수가 일정하기 때문입니다(batch_size 값).

Lambda는 호출 횟수와 코드 실행에 걸리는 시간(기간)을 기준으로 요금이 청구됩니다. 평균 기간 및 호출 지표를 사용하여 가명처리 서비스 비용을 추정할 수 있습니다.

스트리밍 소비 패턴 성능

스트리밍 소비 패턴의 성능을 평가하기 위해 우리는 다음을 실행했습니다. producer.py 이 스크립트는 레코드를 Kinesis 데이터 스트림에 일괄적으로 푸시하는 Kinesis 데이터 생산자를 정의합니다.

스트리밍 애플리케이션은 15분 동안 실행 상태로 유지되었으며 다음과 같이 구성되었습니다. batch_interval 스트리밍 데이터가 일괄 처리되는 시간 간격인 1분입니다. 다음 표에는 관련 요소가 요약되어 있습니다.

파티션 나누기

클러스터 용량 노드

실행자 수

집행자의 기억

배치 창

배치 크기

VIN 크기

1차(m5.xlarge),

3코어(m5.2xlarge)

9 GiB

60 초

900 VIN/API 호출.

5바이트/VIN

다음 그래프는 Kinesis Data Streams 지표를 보여줍니다. PutRecords (파란색) 및 GetRecords (주황색)은 1분 기간으로 집계되었으며 통계를 사용하여 SUM. 첫 번째 그래프는 측정항목을 바이트 단위로 표시하며 분당 최대 6.8MB입니다. 두 번째 그래프는 분당 85,000개 레코드로 최고치를 기록하는 레코드 수의 지표를 보여줍니다.

측정항목이 GetRecords 과 PutRecords 거의 전체 애플리케이션 실행에 대해 겹치는 값이 있습니다. 이는 스트리밍 애플리케이션이 스트림 로드를 따라잡을 수 있었음을 의미합니다.

다음으로 가명처리 서비스에 대한 관련 Lambda 지표를 분석합니다. Invocations, ConcurrentExecutions및 Duration.

다음 그래프는 Invocations 통계와 함께 측정항목 SUM (주황색) 및 RUNNING SUM 파란색으로.

누적 호출의 시작점과 끝점의 차이를 계산하여 실행 중에 몇 번의 호출이 이루어졌는지 추출할 수 있습니다. 구체적으로 말하면, 스트리밍 애플리케이션은 15분 동안 가명화 API를 977회 호출했는데, 이는 분당 약 65회 호출에 해당합니다.

다음 그래프는 총계를 나타냅니다. ConcurrentExecutions 통계와 함께 측정항목 MAX 파란색으로.

재파티션 및 클러스터 구성을 통해 애플리케이션은 모든 Spark RDD 파티션을 병렬로 처리할 수 있습니다. 결과적으로 Lambda 함수의 동시 실행은 항상 다시 파티션 번호인 17 이하입니다.

조절을 방지하려면 병렬로 처리할 수 있는 Spark 작업의 양이 Lambda 함수 동시성 제한을 초과하지 않는지 확인하십시오. 이 측면에서는 일괄 사용 사례와 동일한 제안이 유효합니다.

다음 그래프는 Lambda를 보여줍니다. Duration 통계와 함께 측정항목 AVG 파란색과 MAX 주황색으로.

예상한 대로 Lambda 함수의 콜드 스타트를 제외하고 가명화 함수의 평균 지속 시간은 실행 전반에 걸쳐 거의 일정했습니다. 이는 batch_size 통화당 가명화할 VIN 수를 정의하는 값은 900으로 설정되어 일정하게 유지되었습니다.

Kinesis 데이터 스트림의 수집 속도와 스트리밍 애플리케이션의 소비 속도는 가명처리 서비스에 대한 API 호출 수와 그에 따른 관련 비용에 영향을 미치는 요소입니다.

다음 그래프는 Lambda를 보여줍니다. Invocations 통계와 함께 측정항목 SUM 주황색, Kinesis Data Streams GetRecords.Records 통계와 함께 측정항목 SUM 파란색으로. 분당 스트림에서 검색된 레코드 양과 Lambda 함수 호출 양 사이에 상관 관계가 있어 스트리밍 실행 비용에 영향을 미치는 것을 확인할 수 있습니다.

이외에도 batch_interval, 다음을 사용하여 스트리밍 애플리케이션의 소비 속도를 제어할 수 있습니다. Spark 스트리밍 속성 처럼 spark.streaming.receiver.maxRate 과 spark.streaming.blockInterval. 자세한 내용은 Spark 스트리밍 + Kinesis 통합 과 Spark 스트리밍 프로그래밍 가이드.

결론

데이터 개인 정보 보호법의 규칙과 규정을 살펴보는 것은 어려울 수 있습니다. PII 속성의 가명처리는 민감한 데이터를 처리할 때 고려해야 할 여러 사항 중 하나입니다.

두 부분으로 구성된 이 시리즈에서는 강력한 데이터 플랫폼을 구축하는 데 도움이 되는 기능을 갖춘 다양한 AWS 서비스를 사용하여 가명화 서비스를 구축하고 사용할 수 있는 방법을 살펴보았습니다. ~ 안에 파트 1, 가명화 서비스 구축 방법을 보여줌으로써 기반을 구축했습니다. 이 게시물에서는 비용 효율적이고 효율적인 방식으로 가명처리 서비스를 사용하기 위한 다양한 패턴을 소개했습니다. 확인해 보세요 GitHub의 추가 소비 패턴을 위한 저장소.

저자에 관하여

에드빈 할박슈 AWS Professional Services의 수석 글로벌 보안 설계자이며 사이버 보안 및 자동화에 대한 열정이 있습니다. 그는 고객이 클라우드에서 안전하고 규정을 준수하는 솔루션을 구축하도록 돕습니다. 일 외에는 여행과 스포츠를 좋아합니다.

라훌 샤우리야 AWS Professional Services의 수석 빅 데이터 설계자입니다. 그는 AWS에서 데이터 플랫폼 및 분석 애플리케이션을 구축하는 고객을 돕고 긴밀하게 협력합니다. 업무 외에 Rahul은 자신의 개 Barney와 함께 긴 산책을 하는 것을 좋아합니다.