Amazon SAA-C03: 분석, 데이터 레이크, ML 및 특수 워크로드 — 학습 가이드

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

다음의 일부입니다: AWS SAA-C03 — 완벽 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

데이터 레이크 기초: Lake Formation과 Glue 데이터 카탈로그

AWS 분석의 중심에는 AWS Glue 데이터 카탈로그가 있습니다. 이는 Athena, Redshift Spectrum, EMR, Glue ETL이 모두 사용하는 Hive 메타스토어와 호환되는 메타스토어입니다. 모든 테이블 정의, 파티션, 열 유형, SerDe 구성이 여기에 저장되며, 모든 다운스트림 엔진이 여기에서 정보를 읽어갑니다. 만약 두 개의 수집 경로(예: Glue 크롤러와 수동 CREATE EXTERNAL TABLE 문)가 동일한 S3 접두사의 스키마에 대해 서로 다른 정보를 가지고 있다면, 쿼리는 조용히 잘못된 결과를 반환하거나 실패합니다. 올바른 패턴은 테이블당 단일 권한 소스를 지정하는 것입니다. 즉, 크롤러가 스키마를 소유하거나, ETL 작업이 glueContext.write_dynamic_frame.from_catalog을 통해 쓰도록 하되, 병합 전략 없이는 두 가지를 동시에 사용해서는 안 됩니다. 배치 ETL, Firehose Parquet 변환, 수동 DDL이 모두 동일한 테이블에 쓸 때, 카탈로그 드리프트(catalog drift)는 조용한 장애의 주범이 됩니다. 테이블당 하나의 소유자를 강제하고, 스트리밍 생산자(producer)를 위해 Glue Schema Registry를 사용하며, ETL 작업이 소유한 테이블에 대해서는 크롤러를 UPDATE_IN_DATABASE 모드가 아닌 LOG 모드로 실행하여 큐레이션된 스키마를 덮어쓰지 않고 드리프트를 발견하도록 하십시오.

AWS Lake Formation은 데이터 카탈로그 위에 위치하며, 거친 입도의 IAM/S3 버킷 정책 모델을 데이터베이스 스타일의 권한 레이어로 대체합니다. 특정 접두사에 s3:GetObject 권한을 부여하는 대신, GRANT SELECT ON customers.orders TO role/AnalystRole과 같이 권한을 부여하면, Athena나 Redshift Spectrum이 기본 객체에 접근할 때 Lake Formation이 투명하게 단기 자격 증명을 제공합니다. Lake Formation의 진정한 가치는 세분화된 권한 부여에 있습니다. 즉, 열 수준 필터링, 데이터 필터를 통한 행 수준 보안, 그리고 수천 개의 테이블에 걸쳐 확장 가능한 태그 기반 액세스 제어(LF-Tags)입니다. customers 테이블에 PII(개인 식별 정보)가 있는 리테일 플랫폼은 분석가에게 customer_id, region, signup_date에 대한 접근 권한을 부여하면서 email과 ssn은 차단할 수 있으며, 이는 뷰(view)를 무분별하게 만들 필요 없이 쿼리 시점에 강제됩니다.

거버넌스가 적용된 데이터 레이크의 표준적인 구성은 다음과 같습니다.

1. Register S3 locations with Lake Formation (removes IAMAllowedPrincipals default).
2. Create databases and let Glue crawlers populate tables.
3. Define LF-Tags (e.g., Classification=PII, Domain=Sales).
4. Grant tag-based permissions to IAM principals.
5. Point Athena/Redshift/QuickSight at the catalog — permissions flow through.

Lake Formation 블루프린트는 JDBC 소스나 S3에서 큐레이션된 레이크로 데이터를 수집하기 위해 크롤러, 작업, 트리거를 함께 엮어주는 사전 구축된 워크플로우 템플릿입니다. 이를 통해 수십 개의 수작업으로 연결된 Glue 리소스가 필요했던 작업을 마법사 기반의 흐름으로 줄일 수 있습니다.

자주 저지르는 실수 중 하나는 QuickSight에서만 열 수준 제한을 적용하려고 시도하는 것입니다. QuickSight는 데이터 세트에 연결된 행 및 열 수준 보안 기능을 가지고 있지만, 이는 QuickSight 인터페이스만 보호합니다. Athena나 S3에 직접 접근하는 사람은 이 보안을 우회할 수 있습니다. 열 수준 제어는 반드시 데이터 레이어(Lake Formation 권한 부여 또는 ETL 중 열을 물리적으로 분리)에서 강제되어야 하며, QuickSight는 IAM 역할을 통해 이러한 정책을 상속받습니다.

Athena: S3에 대한 서버리스 SQL

Athena는 Amazon S3에서 직접 데이터를 읽는 서버리스, 쿼리당 과금 방식의 Presto/Trino 엔진입니다. 프로비저닝할 클러스터도 없고, 쿼리 전에 ETL 단계도 필요 없으며, 유휴 상태일 때는 비용이 발생하지 않습니다. 오직 스캔한 바이트에 대해서만 비용을 지불합니다(일반적으로 TB당 5달러). 이 때문에 Athena는 JSON 애플리케이션 로그, CSV 추출 파일, Parquet 팩트 테이블 등 S3에 이미 저장된 파일에 대한 애드혹(ad-hoc) 분석을 위한 표준적인 선택입니다. Athena는 스키마와 파티션 레이아웃이 필요하며, 이는 Glue 데이터 카탈로그에 저장됩니다.

Athena는 스캔한 테라바이트당 비용이 청구되므로, 스토리지 형식이 비용과 지연 시간에 큰 영향을 미칩니다. 두 가지 핵심 요소는 형식과 파티셔닝입니다.

• 열 기반 형식(Parquet, ORC)을 사용하면 Athena가 열과 행 그룹을 건너뛸 수 있습니다. Parquet 형식에 대해 SELECT sum(amount) FROM orders WHERE region='us-east-1'과 같은 쿼리를 실행하면 참조된 두 개의 열만 읽지만, CSV 형식에서는 모든 행의 모든 바이트를 읽습니다.
• 선택도(selectivity)가 높은 열(예: dt=2024-03-11/)로 파티셔닝하면 전체 테이블 스캔이 대상 리드로 축소됩니다. 수 테라바이트에 달하는 로그(CloudFront, ALB, VPC Flow Logs)의 경우, 이는 0.15달러짜리 쿼리와 30달러짜리 쿼리의 차이를 만듭니다.

원본 JSON이나 CSV를 파티셔닝되고 Snappy로 압축된 Parquet으로 변환하는 것은 거의 항상 비용을 절감하기 위해 가장 먼저 취해야 할 조치입니다. LIMIT 푸시다운과 결합하면, Athena는 인프라 없이도 대부분의 S3 기반 분석 요구를 처리할 수 있습니다.

파티셔닝된 Parquet으로 저장된 “readings” 테이블에 대한 비용 효율적인 패턴은 다음과 같습니다.

CREATE EXTERNAL TABLE readings (
  station_id string,
  reading_ts timestamp,
  temp_c    double
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://weather-lake/readings/'
TBLPROPERTIES ('has_encrypted_data'='true');

SELECT station_id, AVG(temp_c) OVER (
         PARTITION BY station_id
         ORDER BY reading_ts
         ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg
FROM readings
WHERE dt = '2024-03-11';

크롤러를 건너뛰는 것은 흔한 실수입니다. 카탈로그 항목이 없으면, 수동으로 CREATE EXTERNAL TABLE DDL을 작성하거나(스키마가 진화함에 따라 깨지기 쉬움) 모든 파일을 스캔하는 스키마 온 리드(schema-on-read) 꼼수를 사용해야 합니다. 더 나쁜 것은, MSCK REPAIR TABLE이나 파티션 프로젝션 없이는 Athena가 모든 쿼리에서 전체 접두사를 스캔한다는 점입니다. Glue 크롤러는 스케줄에 따라 새로운 파티션을 감지하고 카탈로그를 원자적으로 업데이트합니다.

암호화된 S3 데이터에 대한 Athena 사용. Athena는 SSE-S3, SSE-KMS, CSE-KMS를 지원하지만, 호출자가 올바른 KMS 권한을 가지고 있고 작업 그룹이나 클라이언트가 사용 중인 암호화 모드에 맞게 구성된 경우에만 가능합니다. CSE-KMS의 경우, 파일은 업로드 전에 클라이언트 측에서 암호화됩니다. 쿼리를 실행하는 IAM 보안 주체는 CMK에 대한 kms:Decrypt 및 kms:GenerateDataKey 권한이 필요하며, 키 정책도 이를 허용해야 합니다. 흔한 실패 사례는 CSE-KMS로 암호화된 Parquet을 로드한 후, Athena 역할에 S3 읽기 권한만 부여하고, 그 결과 모호한 AccessDenied 또는 HIVE_CANNOT_OPEN_SPLIT 오류가 발생하는 것입니다. 이는 객체는 읽을 수 있지만 암호문을 풀 수 없기 때문입니다. 또 다른 흔한 실수는 객체가 CSE-KMS로 작성되었음에도 불구하고 테이블 속성에서 잘못된 암호화 모드(예: SSE-KMS)로 테이블을 등록하는 것입니다. 이 경우 Athena는 GetObject 중에 서버 측 복호화를 시도하고, 페이로드가 원시 암호문으로 반환되어 Parquet 매직 넘버(magic-number) 검사에 실패합니다.

Athena 연합 쿼리를 사용하면 데이터를 이동하지 않고도 S3 데이터를 운영 스토어(DynamoDB, RDS)와 조인할 수 있습니다. Athena는 읽기 중심의 애드혹 분석에 사용하고, 큐레이션된 영역을 정기적으로 가공하는 작업에는 Glue 작업을 사용하십시오.

Glue 크롤러, ETL 작업 및 작업 북마크

Glue 크롤러는 S3 경로를 스캔하고, year=2024/month=01/과 같은 디렉터리 구조에서 파티션 키를 포함하여 스키마를 추론하며, 카탈로그에 테이블을 등록하거나 업데이트합니다. 이는 “S3에 파일을 놓으면 쿼리할 수 있게 해달라"는 요구에 대한 로우코드(low-code) 솔루션입니다. 랜딩 버킷에 대해 크롤러를 매시간 예약하면 Athena는 즉시 새로운 파티션을 인식합니다.

aws glue create-crawler \
  --name logs-crawler \
  --role AWSGlueServiceRole-Logs \
  --database-name analytics_db \
  --targets '{"S3Targets":[{"Path":"s3://acme-logs/app/"}]}' \
  --schedule "cron(0 * * * ? *)"

Glue ETL 작업(Spark, Python 셸 또는 Ray)은 변환 부분을 처리합니다. Glue는 서버리스이며, 최소 1분 단위의 DPU-시간당 요금을 지불하고 런타임이 워커를 자동으로 확장합니다. 주요 패턴은 CSV/JSON을 입력받아 파티셔닝된 Parquet으로 출력하는 것입니다:

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="raw", table_name="reports_csv")
glueContext.write_dynamic_frame.from_options(
    frame=df,
    connection_type="s3",
    connection_options={"path": "s3://curated/reports/",
                        "partitionKeys": ["report_date"]},
    format="parquet",
    format_options={"compression": "snappy"})

운영상 중요한 기능은 **작업 북마크(job bookmark)**입니다. Glue는 이미 처리한 파일이나 파티션에 대한 상태를 유지하므로, 후속 실행에서는 새로운 데이터만 읽습니다. 북마크를 활성화하는 것을 잊으면 매 실행마다 전체 데이터셋을 처음부터 다시 처리하게 되어 비용과 실행 시간이 선형적으로 증가하고 종종 중복된 출력을 생성합니다. 북마크는 작업별로 활성화되며, 이를 지원하는 소스 옵션과 함께 사용해야 합니다 (Glue DynamicFrame 리더를 통한 S3 소스는 지원하지만, 임의의 Spark 읽기는 지원하지 않습니다). 북마크를 사용하려면 모든 소스에 transformation_ctx 인수가 필요하며, job.init(...) / job.commit()으로 코드를 감싸야 합니다:

job = Job(glueContext)
job.init(args['JOB_NAME'], args)   # bookmark state loaded

datasource = glueContext.create_dynamic_frame.from_catalog(
    database="analytics_db",
    table_name="app_logs",
    transformation_ctx="datasource"   # required for bookmarking
)
# ... transforms ...
job.commit()                          # bookmark state persisted

로직 없이 순수한 형식 변환만 하는 경우, 가장 노력이 적게 드는 옵션은 원본 데이터에 대한 Glue 크롤러와 시각적 편집기에서 작성된 Glue 작업(또는 DataBrew 레시피)을 사용하는 것입니다. Spark 코드가 필요 없습니다. 사용자 지정 EMR 클러스터나 Lambda 변환기는 Glue의 서버리스 모델이 제거하는 운영 오버헤드를 추가합니다.

S3 데이터를 큐레이션하고 Redshift Serverless에 로드하는 일반적인 일일 작업:

# Glue 4.0 PySpark: S3 raw -> curated -> Redshift Serverless
df = glueContext.create_dynamic_frame.from_catalog(
        database="raw", table_name="orders").toDF()
df = df.filter("order_status <> 'CANCELLED'") \
       .withColumn("order_date", to_date("order_ts"))

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame       = DynamicFrame.fromDF(df, glueContext, "out"),
    catalog_connection = "redshift-serverless-conn",
    connection_options = {"dbtable": "fact_orders", "database": "analytics"},
    redshift_tmp_dir   = "s3://stg/redshift-tmp/")

Glue 보안 구성 및 멀티테넌트 ETL

Glue 크롤러와 작업은 Athena와 동일한 암호화 인식이 필요합니다. Glue **보안 구성(security configurations)**은 S3 대상, CloudWatch 로그, 작업 북마크를 암호화하는 방법을 지정하는 명명된 번들입니다. 특정 CMK를 사용하는 CSE-KMS를 포함합니다. 보안 구성에 연결된 작업은 작업의 IAM 역할이 참조된 키에 대한 KMS 권한을 가지고 있다면, CSE-KMS 입력을 투명하게 복호화하고 출력을 동일한 방식으로 암호화합니다.

멀티테넌트 ETL의 경우(각 고객의 데이터를 해당 고객의 CMK로 처리하는 SaaS 플랫폼), 올바른 패턴은 고객별로 하나의 보안 구성을 사용하거나(또는 CMK를 선택하는 작업 파라미터 사용) 해당 CMK로 범위가 지정된 IAM 역할을 사용하는 것입니다. 모든 고객을 단일 공유 키를 사용하는 단일 작업으로 처리하면 CSE-KMS가 제공하려는 격리 보장을 무효화합니다.

관련된 원칙: 프로덕션 분석 테이블은 탐색적 Glue 작업이나 노트북의 직접적인 대상이 되어서는 안 됩니다. 스냅샷을 S3의 “analytics” 접두사로 내보내고 Athena나 Spark가 그 복사본을 가리키도록 하십시오. 라이브 테이블에서 실험적인 변환을 실행하면 파티션 수준의 재작성, 북마크 손상, 잠금 경합의 위험이 있으며, 운영 데이터와 분석 파생물 간의 감사 경계를 모호하게 만듭니다.

AWS Glue DataBrew

DataBrew는 Spark를 작성할 수 없거나 작성해서는 안 되는 사용자를 위한 Glue의 로우코드(low-code) 자매품입니다. 스프레드시트 스타일의 UI를 제공하며, 250개 이상의 사전 구축된 변환 기능(결측치 처리, PII 마스킹, 이상치 구간화, 날짜 파싱 등)을 제공합니다. 차별점은 공유 레시피(shared recipes)(버전 관리되는 JSON 아티팩트로, 여러 프로젝트에 걸쳐 게시하고 재적용할 수 있음)와 데이터 계보 시각화(data lineage visualization)(소스 데이터셋의 열이 레시피와 작업을 거쳐 출력 위치까지 어떻게 변환되는지 추적함)입니다. 분석가가 변환 로직을 소유할 때는 DataBrew를 선택하고, 엔지니어가 소유하고 파이프라인에 사용자 지정 코드, 스트리밍 또는 복잡한 조인이 필요할 때는 Glue Studio/스크립트를 선택하십시오.

Amazon EMR: 분산 배치 및 런타임 역할

Amazon EMR은 Spark, Hadoop, Hive, Presto, HBase, Flink를 실행하는 관리형 클러스터 플랫폼입니다. EMR의 강점은 페타바이트 규모의 S3 데이터셋을 읽고 이를 다른 기록 시스템(주로 Redshift)과 조인하여 보강하는, 병렬화 가능한 대규모 배치 또는 대화형 워크로드입니다. EMR은 임시 클러스터(시작, 실행, 종료) 또는 장기 실행 클러스터를 운영할 수 있으며, 인스턴스 플릿을 통해 온디맨드, 스팟, 예약 인스턴스를 혼합하여 사용할 수 있습니다.

대표적인 패턴: Spark 작업이 S3에서 Parquet을 읽고, UNLOAD-to-S3를 통해 Redshift에서 차원 테이블을 가져와 여러 엑시큐터에 걸쳐 조인한 다음, 보강된 출력을 다시 S3에 씁니다:

# Spark on EMR: enrich S3 events with Redshift dimensions
df_events = spark.read.parquet("s3://raw/events/dt=2024-11-01/")
df_dims = (spark.read
    .format("io.github.spark_redshift_community.spark.redshift")
    .option("url", "jdbc:redshift://cluster:5439/analytics")
    .option("dbtable", "public.customer_dim")
    .option("tempdir", "s3://staging/redshift-unload/")
    .load())

enriched = df_events.join(df_dims, "customer_id", "left")
enriched.write.mode("overwrite").partitionBy("region").parquet("s3://curated/events/")

여기서 EMR이 유리한 이유는 Spark가 수십 개의 노드에 조인을 분산시키고 S3를 통한 스테이징이 단일 스레드 JDBC 병목 현상을 피하게 해주기 때문입니다. S3 데이터를 쿼리해야 할 때마다 반사적으로 EMR을 사용하는 것이 함정입니다. 수십 또는 수백 기가바이트에 대한 애드혹 SQL의 경우, Spark 클러스터를 프로비저닝하고 튜닝하는 것(클러스터 크기 조정, YARN 구성, 오토스케일링, 로그 로테이션, 패치 등)은 순전히 운영 오버헤드입니다. EMR은 볼륨, 사용자 지정 코드 또는 실행 엔진의 유연성이 이를 정당화할 때만 그 가치를 발휘합니다.

EMR 런타임 역할(runtime roles). 과거에는 클러스터의 모든 스텝이 기본 노드에 연결된 단일 역할인 EC2 인스턴스 프로파일을 상속했습니다. 이는 클러스터를 공유하는 모든 팀이 다른 팀에 필요한 모든 권한의 합집합을 가졌다는 의미입니다. 런타임 역할은 이 문제를 해결합니다. 사용자가 스텝을 제출할 때 --execution-role-arn을 전달하면, EMR은 해당 스텝이 실행되는 동안 그 역할을 수임(assume)합니다. A팀은 s3://team-a/*로, B팀은 s3://team-b/*로 제한할 수 있습니다. 인스턴스 프로파일은 클러스터 아티팩트를 가져오는 역할만 하는 얇은 부트스트랩 역할이 됩니다.

런타임 역할은 IMDS 액세스를 차단하는 메커니즘이기도 합니다. 이 기능이 활성화되면(YARN 기반 Spark/Hive를 사용하는 EMR 6.7+), 플랫폼이 해당 호출을 가로채기 때문에 사용자 코드는 IMDSv2를 포함한 인스턴스 메타데이터 서비스에 접근할 수 없습니다. 이는 작업이 http://169.254.169.254/latest/api/token을 호출하여 강력한 EC2 인스턴스 프로파일을 수임할 수 있었던 권한 상승 경로를 차단합니다.

aws emr create-cluster \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --security-configuration team-isolation-sc \
  --service-role EMR_DefaultRole \
  --ec2-attributes InstanceProfile=EMR_EC2_MinimalRole,...

aws emr add-steps --cluster-id j-XXXX \
  --steps Type=Spark,Name="TeamA-ETL",\
ActionOnFailure=CONTINUE,\
Jar=command-runner.jar,\
Args=[spark-submit,s3://team-a/jobs/etl.py] \
  --execution-role-arn arn:aws:iam::111122223333:role/TeamA-EMRRuntime

보안 구성은 런타임 역할 강제 및 IMDS 차단을 활성화하는 요소입니다. 이것이 없으면 EMR 워크로드가 ‘자동으로 최소 권한 역할을 사용한다’고 가정하는 것은 잘못입니다. 기본적으로 워크로드들은 인스턴스 프로파일을 공유하며 사용자 코드에서 IMDS에 접근할 수 있습니다.

Amazon Redshift와 Redshift ML

Redshift는 1초 미만의 대시보드 응답 시간, 수십억 개 행에 대한 복잡한 조인, 다수의 BI 사용자가 동시에 접속해도 일관된 지연 시간을 요구하는 지속적인 분석 워크로드를 위한 컬럼 기반 MPP 데이터 웨어하우스입니다. RA3 노드는 관리형 스토리지에서 컴퓨팅을 분리합니다. Redshift Serverless는 구성된 기본 용량을 기준으로 RPU-초 단위로 과금되며, 부하에 따라 확장되고 유휴 상태일 때 일시 중지되어 기존의 클러스터 크기 조정 문제를 해결합니다.

Redshift는 두 가지 보강 모드로 분석 파이프라인에 참여합니다.

• 소스로서: EMR의 Spark가 UNLOAD-to-S3를 통해 차원(dimension) 데이터를 가져오거나, Glue가 Redshift Data API를 통해 읽습니다.
• 대상으로서: Firehose나 Glue 작업이 보강된 데이터를 COPY합니다.

Redshift Spectrum은 Redshift SQL이 Glue Data Catalog(Athena가 사용하는 것과 동일한 카탈로그)를 통해 S3를 직접 쿼리할 수 있게 하여 이 기능을 확장합니다. 이것이 바로 레이크하우스 패턴을 가능하게 하는 요소입니다. 이미 Redshift 클러스터가 있고 데이터를 이동하지 않고 웨어하우스에 저장된 팩트(fact) 데이터와 S3의 콜드 히스토리 데이터를 조인하고 싶을 때 이상적입니다.

배치 로드는 S3로부터 COPY 명령을 사용하며, 컴퓨팅 노드 전반에 걸쳐 병렬화됩니다. 병렬 처리를 위해 파일은 대략 동일한 크기의 청크(슬라이스 수의 배수)로 분할되어야 합니다.

COPY events FROM 's3://acme-lake/events/dt=2024-05-12/'
IAM_ROLE 'arn:aws:iam::111:role/RedshiftLoader'
FORMAT AS PARQUET;

스트리밍 수집은 일반적으로 운영 부담이 없는(zero-ops) 전송을 위해 Firehose(버퍼링된 COPY)를 통해 이루어집니다.

Redshift ML을 사용하면 SQL 사용자가 CREATE MODEL을 통해 모델을 생성, 학습 및 호출할 수 있습니다.

CREATE MODEL churn_predictor
FROM (SELECT tenure, plan, monthly_spend, churned FROM customers)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'redshift-ml-artifacts');

SELECT customer_id, predict_churn(tenure, plan, monthly_spend)
FROM customers_current;

내부적으로 Redshift는 학습 세트를 S3로 내보내고, SageMaker Autopilot(또는 XGBoost와 같은 지정된 알고리즘)을 호출한 다음, 컴파일된 모델을 가져와 데이터베이스 내 추론을 수행합니다. 분석가들이 이미 SQL 환경에 익숙할 때 강력한 기능이지만, 완전한 ML 플랫폼을 대체하지는 않습니다. S3로의 데이터 이동 및 SageMaker 학습 컴퓨팅 비용은 별도로 청구되며, 대규모 학습 세트는 상당한 이그레스(egress) 및 Autopilot 실행 요금을 발생시킬 수 있고, 피처 스토어, 실험 추적, A/B 배포를 위한 내장 워크플로우가 없습니다. Redshift ML은 범용 학습이 아닌, Redshift 데이터에 대한 민주화된 추론 기능으로 취급해야 합니다.

Athena와 Redshift 중 선택하기

스트리밍 수집: Kinesis Data Streams, Firehose, MSK

세 가지 AWS 스트리밍 서비스는 서로 겹치는 문제를 해결하지만 실질적으로 다른 보장 사항을 제공합니다.

Kinesis Data Streams는 샤드(또는 온디맨드 모드)를 사용합니다. 동일한 파티션 키를 가진 레코드는 동일한 샤드에 저장되고 순서대로 소비됩니다. 소비자는 기존의 GetRecords 또는 향상된 팬아웃(소비자당 2MB/s 전용)을 사용합니다. 이벤트 소스로 연결된 Lambda 함수는 샤드별 배치로 호출되어 순서를 보존합니다. 다운스트림 로직이 간단하지 않거나, 여러 독립적인 소비자가 기록을 재실행해야 하거나, 클릭스트림 볼륨이 막대한 경우에 올바른 선택입니다. 예를 들어, 하루에 30TB를 생성하는 사이트의 데이터는 KDS를 통해 Firehose로 흐르고 S3에 저장되어 Athena/Spectrum 분석에 사용될 수 있습니다.

Kinesis Data Firehose는 일단 보내고 잊는(fire-and-forget) 방식의 관리형 전송 서비스입니다. 크기 또는 시간(예: 5MB / 300초)에 따라 데이터를 버퍼링하고, 선택적으로 변환을 위해 Lambda를 호출하며, 선택적으로 Glue 테이블 스키마를 사용하여 JSON을 Parquet/ORC로 변환한 후 S3, Redshift(S3 + COPY 경유), OpenSearch 또는 Splunk에 기록합니다. Firehose에서 Parquet 변환을 활성화하는 것은 다운스트림 Glue 작업 없이 스트리밍 데이터를 쿼리에 최적화된 형식으로 저장하는 가장 손쉬운 방법입니다.

Firehose delivery stream → 
  Record transformation: Lambda (optional, for enrichment) →
  Format conversion: enabled, schema from Glue table "events.raw" →
  Destination: s3://lake/events/ partitioned by !{timestamp:yyyy/MM/dd}

Firehose는 종단 간(end-to-end) 순서를 보장하지 않으며, 여러 재실행 가능한 소비자를 지원할 수 없고, 목적지가 고정된 싱크로 제한됩니다. “각 레코드를 순서대로 처리” 또는 “여러 독립적인 소비자"라는 요구사항이 있을 때 Firehose를 선택하는 것은 두 가지 모두에서 잘못된 결정입니다. 마찬가지로, Firehose 단독으로 복잡한 변환을 수행할 것으로 기대하는 것은 함정입니다. 유일한 변환 후크(hook)는 버퍼링된 배치마다 호출되는 Lambda뿐입니다. 외부 데이터 보강, 다중 레코드 집계, 조건부 라우팅과 관련된 모든 작업은 해당 Lambda 내에서 처리하거나, 상위 스트림인 Managed Service for Apache Flink로 옮겨야 합니다.

Amazon MSK는 관리형 Apache Kafka입니다. 이미 Kafka 생산자/소비자를 사용하고 있거나, Kafka 관련 특정 기능(압축 토픽, 트랜잭션, Kafka Streams, Connect 등)이 필요하거나, 샤드 기반 Kinesis가 편안하게 제공할 수 있는 처리량을 넘어서는 성능이 필요할 때 선택합니다.

SQS나 EventBridge를 분석 데이터 수집 경로로 사용하는 것은 실수입니다. SQS는 스트림별로 순서가 보장되지 않고 재실행 기능이 없으며, EventBridge는 지속적인 초당 수 MB의 데이터 수집이 아닌 이벤트 라우팅에 최적화되어 있습니다.

실시간 검색: KDS + Firehose + OpenSearch + QuickSight

온프레미스 Elasticsearch+Logstash 스택에 대한 표준적인 대체 구성은 다음과 같습니다:

Firehose는 스트림 레코드를 버퍼링하여 OpenSearch 도메인으로 직접 전달하며, 재시도, S3 백업, 선택적 Lambda 변환을 처리합니다. OpenSearch Dashboards는 도메인에 내장되어 무료로 제공되며 실시간 스트림을 모니터링하는 운영자에게 적합합니다. QuickSight는 비즈니스용 분석을 위해 이를 보완합니다. QuickSight는 Athena, Redshift, RDS, OpenSearch를 직접 쿼리하며, SPICE 인메모리 컬럼 엔진은 처리된 데이터 세트를 캐시하여 대시보드 성능을 수 초 내로 단축합니다.

일반적인 역할 분담은 다음과 같습니다: 운영자는 OpenSearch Dashboards를, 경영진은 Athena/Glue 레이크에서 집계되고 선별된 데이터 세트를 소비하기 위해 QuickSight를 사용합니다. 두 서비스 모두 IAM 읽기 액세스 권한과, 해당하는 경우 기본 스토리지를 보호하는 CMK에 대한 KMS Decrypt 권한을 부여받아야 합니다. 그렇지 않으면 시각화 계층은 쿼리 로그에 숨겨진 권한 오류와 함께 빈 패널을 렌더링합니다.

QuickSight 액세스 제어

QuickSight는 데이터 세트(논리적 쿼리, 계산된 필드, 행 수준 보안 포함)를 구축하고, 데이터 세트 위에 분석을 생성한 다음, 대시보드(읽기 전용 공유 가능 뷰)를 게시합니다. 액세스 제어는 계층화되어 있으며 올바른 계층에 적용해야 합니다. 흔히 저지르는 실수는 대시보드 수준에서 광범위한 액세스 권한을 부여하는 것입니다. 즉, 기본 데이터는 일부만 볼 수 있어야 함에도 불구하고 조직 전체 그룹에 공유하는 경우입니다.

QuickSight에서의 최소 권한 원칙은 다음을 의미합니다:

• 데이터 세트는 필요한 사용자/그룹과만 공유합니다.
• 사용자 이름이나 그룹별로 행을 필터링하는 권한 데이터 세트를 통해 행 수준 보안을 적용합니다.
• 민감한 필드를 숨기기 위해 열 수준 보안을 적용합니다.
• 대시보드는 특정 사용자, 그룹 또는 (임베디드 분석의 경우) 네임스페이스와 공유합니다.

대시보드를 공개하거나 계정 전체에 공유하면 데이터 세트 수준 제어의 의도를 우회하게 됩니다. 왜냐하면 대시보드 뷰어는 기본 소스 권한과 관계없이 시각화된 데이터에 대한 읽기 액세스 권한을 상속받기 때문입니다. QuickSight의 열 수준 보안은 QuickSight 인터페이스만 보호한다는 점을 기억해야 합니다. Athena나 S3에 직접 액세스할 수 있는 사람은 이를 우회할 수 있으므로, 민감한 제어는 QuickSight 단독이 아닌 Lake Formation이나 ETL에 적용해야 합니다.

QuickSight 역할(Admin, Author, Reader)은 사용자가 무엇을 볼 수 있는지를 제어하는 공유 권한과 구별되며, 사용자가 무엇을 할 수 있는지를 제어합니다. Reader는 Author 라이선스보다 세션당 비용이 저렴하므로, 뷰어 그룹은 기본적으로 Reader로 설정해야 하며, 액세스는 개별 할당이 아닌 그룹 멤버십을 통해 부여해야 합니다.

그래프 워크로드를 위한 Amazon Neptune

Neptune은 속성 그래프 모델(Gremlin, openCypher)과 RDF(SPARQL)를 지원하는 관리형 그래프 데이터베이스입니다. 소셜 관계, 사기 조직망, 지식 그래프, 추천 엔진과 같이 고도로 연결된 데이터에 특화되어 있으며, 이러한 데이터는 관계형 데이터베이스에서 재귀적 조인이 감당하기 어려워지는 경우에 사용됩니다. 사용자, 팔로우, 좋아요, 게시물이 있는 소셜 플랫폼은 정점(vertices)과 간선(edges)으로 자연스럽게 매핑되며, Neptune은 (“X를 좋아한 친구의 친구"와 같은) 다중 홉 순회 쿼리에 밀리초 단위로 응답합니다.

Neptune Streams는 그래프에 대한 모든 변경 사항의 순서화된 시간 기반 로그를 제공합니다. 스트림을 폴링하는 Lambda나 애플리케이션은 별도의 변경 데이터 캡처(CDC) 파이프라인 없이도 변경 사항에 반응하여 추천을 재계산하거나, 검색 인덱스를 업데이트하거나, 사기 경고를 트리거할 수 있습니다. Aurora나 DynamoDB에서 이를 재현하려면 애플리케이션 수준의 그래프 순회와 별도의 CDC 설비가 필요합니다. 문제 설명에 “관계 분석"과 “변경 모니터링"이 모두 포함된 경우, Streams를 사용하는 Neptune이 가장 직접적인 해답입니다.

SageMaker: 엔드투엔드 맞춤형 ML

SageMaker는 Studio 노트북, 관리형 학습 작업(스팟 인스턴스 지원 포함), Model Registry, 실시간 및 서버리스 엔드포인트, 배치 변환, MLOps를 위한 Pipelines 등 전체 라이프사이클을 제공합니다. 일반적인 흐름은 학습 데이터를 S3에 업로드하고, 내장 알고리즘이나 사용자 지정 컨테이너를 지정하여 학습 작업을 시작하는 것입니다. 그러면 SageMaker가 임시 인스턴스를 프로비저닝하고, CloudWatch로 로그를 스트리밍하며, 모델 아티팩트를 S3에 다시 기록합니다. 배포는 단일 API 호출로 이루어집니다:

from sagemaker.estimator import Estimator
est = Estimator(image_uri=xgb_image, role=role,
                instance_count=2, instance_type="ml.m5.xlarge",
                output_path="s3://models/xgb/")
est.fit({"train": "s3://data/train/", "validation": "s3://data/val/"})
predictor = est.deploy(initial_instance_count=1, instance_type="ml.m5.large")

관리할 Kubernetes, GPU 드라이버 또는 모델 서버가 없습니다. “모델을 학습하고 노출"하는 것이 요구사항인 팀에게 SageMaker는 자체적으로 ECS/EC2 추론 환경을 구축하는 것에 비해 거의 항상 오버헤드가 가장 적은 해답입니다.

SageMaker Savings Plans는 1년 또는 3년 동안 적격 구성 요소(Studio, 학습, 처리, 실시간 추론)에 대해 시간당 달러 지출을 약정하여 온디맨드 요금에서 최대 64% 할인을 제공합니다. 이 플랜은 인스턴스 패밀리, 크기, 리전, 구성 요소에 걸쳐 유연하지만, Ground Truth, 스토리지 또는 데이터 전송 비용은 포함하지 않습니다. 기본 ML 사용량이 예측 가능할 때 Savings Plans를 사용하고, 급증하는 학습 작업은 스팟 인스턴스에 맡겨 비용 절감을 극대화하십시오.

관리형 AI 서비스와 사용자 지정 ML 비교

Amazon Rekognition(이미지/동영상: 객체 및 장면 감지, 얼굴 분석, 콘텐츠 조정), Textract(OCR 및 양식/테이블 추출), Comprehend(NLP: 개체 인식, 감성 분석, PII 탐지, 사용자 지정 분류)는 사전 훈련된 모델을 간단한 API 뒤에 노출합니다. Comprehend의 DetectEntities는 COMMERCIAL_ITEM 카테고리를 포함한 유형별 개체를 반환합니다. 이는 레시피 텍스트에서 재료 이름을 추출하여 DynamoDB 조회에 제공하는 데 완벽하며, 훈련 데이터나 호스팅 없이 요청당 과금 방식으로 사용할 수 있습니다.

aws comprehend detect-entities \
    --language-code en \
    --text "Combine 2 cups flour, 1 tsp salt, and 3 eggs..."

일반적인 실패 패턴은 오버엔지니어링입니다. 즉, 관리형 서비스가 훨씬 적은 운영 비용으로 요구 사항을 충족할 수 있음에도 불구하고 SageMaker 훈련 작업을 설정하고, Ground Truth로 데이터에 레이블을 지정하고, 엔드포인트를 호스팅하는 것입니다. 사용자 지정 ML은 도메인 특정 데이터에 대한 정확도가 훨씬 높거나, 필요한 개체 유형이 관리형 스키마와 일치하지 않거나(이 경우에도 Comprehend Custom Classification/Entity Recognition이 순수 SageMaker보다 저렴합니다), 지연 시간 및 데이터 상주 제약 조건으로 인해 프라이빗 모델이 필요할 때만 정당화됩니다.

HPC 스토리지 및 네트워킹: FSx for Lustre와 EFA

CFD, 분자 동역학, 지진파 이미징, 대규모 훈련과 같은 긴밀하게 결합된(Tightly coupled) HPC 워크로드에는 두 가지 필수 요구 사항이 있습니다. 바로 극도로 짧은 노드 간 통신 지연 시간과 높은 처리량의 공유 스토리지입니다.

**Elastic Fabric Adapter (EFA)**는 특정 EC2 패밀리(hpc7a, hpc6id, c6in, p4d/p5 등)에서 사용할 수 있는 네트워크 인터페이스입니다. OS-bypass Libfabric를 사용하여 커널 TCP/IP 스택을 우회함으로써 MPI와 NCCL이 수백 개의 노드에 걸쳐 마이크로초 단위의 지연 시간을 달성할 수 있도록 합니다. EFA를 사용하려면 인스턴스가 동일한 가용 영역(Availability Zone)에 있어야 하며, 최대 대역폭을 위해서는 **클러스터 배치 그룹(cluster placement group)**에 있어야 합니다.

FSx for Lustre는 수백 GB/s의 처리량과 밀리초 미만의 지연 시간을 제공하는 관리형 병렬 파일 시스템입니다. S3와 기본적으로 통합됩니다. FSx 파일 시스템을 버킷에 연결하여 객체가 POSIX 파일처럼 보이게 할 수 있으며, Lustre에 기록된 결과를 다시 S3로 내보낼 수 있습니다. 영구 SSD(Persistent SSD) 배포는 오래 지속되는 스크래치 공간에 적합하며, 임시 작업 데이터에는 Scratch2가 더 저렴합니다.

잘못된 패턴은 HPC에 EFS를 사용하는 것입니다. EFS는 NFS 기반으로, 범용 파일 I/O를 수행하는 다수의 소규모 클라이언트에 맞게 조정되었습니다. 500개 노드의 MPI 작업에 필요한 총 처리량이나 메타데이터 IOPS를 유지할 수 없으며, 다중 AZ 설계는 지연 시간을 추가합니다. EFA 대신 표준 ENA를 사용하면 MPI가 TCP 지연 시간으로 제한되어, allreduce 집약적인 작업의 실행 시간이 몇 배로 늘어납니다. 올바른 조합은 클러스터 배치 그룹 내에서 FSx for Lustre를 마운트하는 EFA 지원 인스턴스를 사용하고, S3를 파일 시스템에 연결된 내구성 있는 콜드 스토리지로 활용하는 것입니다.

← 데이터베이스 및 캐싱 · 모든 도메인 · 애플리케이션 통합 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →