Jason | Solution Engineer - 마테크, 애드테크

AWS Solution Architect 준비: EBS - IOPS

Jason Nam — Sat, 13 Dec 2025 15:53:39 +0900

AWS EBS IOPS

클라우드 스토리지 성능의 핵심 지표, IOPS를 제대로 이해하고 활용하는 방법

들어가며

AWS에서 애플리케이션을 운영하다 보면 "IOPS"라는 용어를 자주 접하게 됩니다. 특히 데이터베이스나 ETL 작업처럼 디스크 I/O가 중요한 워크로드에서는 IOPS 설정이 성능과 비용을 좌우하는 핵심 요소가 됩니다. 이 글에서는 EBS IOPS의 개념부터 실전 최적화 전략까지 상세히 알아보겠습니다.

IOPS란 무엇인가?

**IOPS(Input/Output Operations Per Second)**는 스토리지 볼륨이 초당 처리할 수 있는 읽기/쓰기 작업의 수를 의미합니다.

핵심 특징

측정 기준: 16KiB I/O 작업 단위로 측정
워크로드 유형: 데이터베이스, 가상 데스크톱, 부트 볼륨 등 transactional workload에 중요
성능 지표: SSD 기반 볼륨의 주요 성능 측정 기준

쉽게 말해, IOPS는 스토리지의 "처리 속도"를 나타내는 지표입니다. 높은 IOPS는 더 많은 데이터 요청을 동시에 처리할 수 있음을 의미합니다.

️ EBS 볼륨 타입별 IOPS 성능 비교

AWS EBS는 워크로드 특성에 따라 다양한 볼륨 타입을 제공합니다.

SSD 기반 볼륨 (Transactional Workload)

1. gp3 (General Purpose SSD) - 권장 옵션

최대 IOPS: 80,000
기본 제공: 3,000 IOPS (추가 비용 없음)
용량: 1 GB ~ 64 TB
가격: $0.08/GB-month + 추가 IOPS 비용
특징: 가장 비용 효율적, 대부분의 워크로드에 적합

비용 구조:

기본 3,000 IOPS 무료
3,000 IOPS 초과 시: $0.005/provisioned IOPS-month
125 MB/s 무료, 초과 시: $0.04/provisioned MB/s-month

2. gp2 (General Purpose SSD) - 레거시

최대 IOPS: 16,000
성능 확장: 3 IOPS/GiB (용량에 비례)
용량: 1 GB ~ 16 TB
특징: Burst 크레딧 시스템, gp3로 마이그레이션 권장

성능 계산:

33.33 GiB 이하: 최소 100 IOPS
33.33 GiB 초과: 용량(GiB) × 3 IOPS
5,334 GiB에서 최대 16,000 IOPS 도달

3. io2 Block Express - 최고 성능

최대 IOPS: 256,000
IOPS/GiB 비율: 1,000:1
용량: 최대 64 TB
처리량: 4,000 MB/s
레이턴시: 평균 500 마이크로초 미만
가격: $0.125/GB-month + $0.065/provisioned IOPS-month

최적 사용 케이스:

SAP HANA, Oracle, Microsoft SQL Server
Mission-critical 데이터베이스
99.999% 내구성 요구 워크로드

4. io1 - 고성능

최대 IOPS: 64,000
IOPS/GiB 비율: 50:1
용량: 4 GB ~ 16 TB
특징: io2로 업그레이드 권장 (동일 가격에 더 나은 성능)

HDD 기반 볼륨 (Throughput 중심)

st1 (Throughput Optimized): MapReduce, 로그 처리
sc1 (Cold HDD): 아카이브, 저빈도 액세스

⚡ 실제 IOPS 성능 결정 요소

프로비저닝한 IOPS를 모두 활용하려면 세 가지 요소를 고려해야 합니다.

1. 볼륨 설정

볼륨 타입과 크기, 프로비저닝한 IOPS 값

2. EC2 인스턴스 제한

중요: 인스턴스의 EBS 성능은 인스턴스 타입의 성능 제한 또는 연결된 볼륨의 총합 성능 중 더 작은 값으로 제한됩니다.

예시: r6i.16xlarge에서 80,000 IOPS 달성

옵션 1: gp2 볼륨 5개 × 16,000 IOPS = 80,000 IOPS
옵션 2: gp3 볼륨 1개를 80,000 IOPS로 프로비저닝
옵션 3: io2 Block Express 1개

3. 네트워크 대역폭

EBS-Optimized 인스턴스 사용 필수
인스턴스별 "Dedicated EBS Bandwidth" 확인
예: m7i.large는 10 Gbps 전용 EBS 대역폭 제공

IOPS 모니터링 및 최적화 전략

CloudWatch 핵심 메트릭

필수 모니터링 메트릭:
  VolumeReadOps/VolumeWriteOps:
    설명: 실제 읽기/쓰기 작업 수
    활용: 초로 나누어 실제 IOPS 계산
    
  VolumeThroughputPercentage:
    설명: IOPS 사용률 (%)
    알람 기준: 80% 초과 시 알림
    
  VolumeQueueLength:
    설명: 대기 중인 I/O 작업 수
    알람 기준: 10 초과 시 병목 가능성
    
  BurstBalance:
    설명: gp2 볼륨의 burst 크레딧 잔량
    알람 기준: 20% 미만 시 성능 저하 경고

CloudWatch 알람 설정 예시

# IOPS 사용률 높음 알람
aws cloudwatch put-metric-alarm \
  --alarm-name high-iops-usage \
  --metric-name VolumeThroughputPercentage \
  --namespace AWS/EBS \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2

# gp2 Burst Balance 낮음 알람
aws cloudwatch put-metric-alarm \
  --alarm-name low-burst-balance \
  --metric-name BurstBalance \
  --namespace AWS/EBS \
  --statistic Average \
  --period 300 \
  --threshold 20 \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 1

비용 최적화 실전 가이드

1. gp2 → gp3 마이그레이션

절감 효과: 약 20%

# 마이그레이션 전 (gp2)
volume_size = 1000  # GB
cost_gp2 = 1000 * 0.10  # $100/month
auto_iops = 1000 * 3    # 3,000 IOPS

# 마이그레이션 후 (gp3)
cost_gp3_storage = 1000 * 0.08  # $80/month
cost_gp3_iops = 0                # 3,000 IOPS는 무료
total_cost_gp3 = 80              # $80/month

# 절감: $20/month (20%)

2. 과다 프로비저닝 방지

많은 팀이 "혹시 몰라서" 10,000~16,000 IOPS를 프로비저닝하지만, 실제 사용량은 2,000 IOPS 미만인 경우가 많습니다.

최적화 절차:

1. CloudWatch에서 지난 2주간 메트릭 확인
2. 95th percentile IOPS 확인
3. 프로비저닝 값이 95th percentile보다 훨씬 높으면 감축
4. 30% 여유분만 유지 (예: 95th percentile이 2,000이면 2,600 IOPS)

3. 인스턴스 타입 매칭

안티패턴:

❌ io2 Block Express (64,000 IOPS) + t3.medium 인스턴스
→ t3.medium은 최대 2,880 IOPS만 지원
→ 비싼 볼륨 비용 낭비

권장:

✅ 워크로드 분석 → 필요 IOPS 산정 → 적절한 인스턴스 선택
✅ EBS-Optimized 인스턴스 사용
✅ 인스턴스 스펙 페이지에서 "Maximum IOPS" 확인

️ 실전 사례: ETL 워크로드 IOPS 설계

시나리오

GCP BigQuery → AWS Redshift 데이터 마이그레이션

임시 프로젝트 (6개월)
이벤트 기반 처리
레코드별 처리 (배치 아님)
VPN 터널링 환경

아키텍처별 IOPS 설정

1. Lambda 함수 (데이터 추출 → S3)

lambda_storage_config = {
    "volume_type": "gp3",
    "size_gb": 100,
    "iops": 3000,        # 기본값, 추가 비용 없음
    "throughput_mbps": 125,  # 기본값
    "rationale": "짧은 실행 시간, 가벼운 I/O, 비용 효율성"
}

# 예상 비용
monthly_cost = 100 * 0.08  # $8/month

2. Glue ETL 작업 (데이터 변환)

glue_storage_config = {
    "volume_type": "gp3",
    "size_gb": 500,
    "iops": 5000,        # 3,000 초과 시 비용 발생
    "throughput_mbps": 250,
    "rationale": "중간 크기 변환 작업, 확장 가능성"
}

# 예상 비용
storage_cost = 500 * 0.08           # $40/month
iops_cost = (5000 - 3000) * 0.005   # $10/month
throughput_cost = (250 - 125) * 0.04 # $5/month
total_cost = 55  # $55/month

3. Redshift (대상 데이터베이스)

Redshift는 자체 managed storage 사용
별도 EBS 볼륨 불필요

모니터링 전략

Phase 1 - 초기 배포:
  - 보수적 IOPS 설정 (3,000~5,000)
  - CloudWatch 상세 모니터링 활성화
  - 1주일간 실제 사용 패턴 수집

Phase 2 - 최적화:
  - 95th percentile 기준 IOPS 조정
  - VolumeQueueLength > 5이면 IOPS 증가
  - VolumeThroughputPercentage < 50%이면 IOPS 감소

Phase 3 - 안정화:
  - 주간 리뷰로 지속 최적화
  - 프로젝트 종료 시 리소스 즉시 삭제

하이브리드 클라우드 환경 고려사항

VPN 터널링과 IOPS

GCP-AWS 간 VPN 연결 시:

EBS IOPS는 로컬 성능만 보장
네트워크 레이턴시 추가 발생
io2 Block Express의 500 마이크로초 레이턴시 + VPN 레이턴시

권장 사항:

1. 엔드투엔드 성능 테스트 필수
2. 네트워크 병목 vs 스토리지 병목 구분
3. CloudWatch Logs로 전체 파이프라인 레이턴시 추적

보안과 성능

암호화 영향:
  EBS 암호화: IOPS 성능 영향 거의 없음
  AWS KMS: 투명하게 적용
  전송 중 암호화: VPN/TLS 오버헤드 고려

권장 설정:
  - EBS 기본 암호화 활성화
  - KMS Customer Managed Key 사용
  - 암호화로 인한 IOPS 손실 걱정 불필요

성능 벤치마킹 가이드

FIO를 이용한 IOPS 테스트

# 랜덤 읽기 IOPS 테스트
sudo fio --filename=/dev/xvdf \
  --direct=1 \
  --rw=randread \
  --bs=16k \
  --ioengine=libaio \
  --iodepth=256 \
  --runtime=120 \
  --numjobs=4 \
  --time_based \
  --group_reporting \
  --name=iops-test-job

# 랜덤 쓰기 IOPS 테스트
sudo fio --filename=/dev/xvdf \
  --direct=1 \
  --rw=randwrite \
  --bs=16k \
  --ioengine=libaio \
  --iodepth=256 \
  --runtime=120 \
  --numjobs=4 \
  --time_based \
  --group_reporting \
  --name=iops-test-job

결과 해석

예상 결과:
  gp3 (3,000 IOPS): ~2,800-3,000 IOPS
  gp3 (10,000 IOPS): ~9,500-10,000 IOPS
  io2 (50,000 IOPS): ~48,000-50,000 IOPS

성능 미달 시 체크리스트:
  ☐ EBS-Optimized 인스턴스인가?
  ☐ 인스턴스 최대 IOPS 제한은?
  ☐ 다른 볼륨이 대역폭을 소비하는가?
  ☐ gp2의 Burst Balance가 고갈되었는가?

워크로드별 IOPS 권장사항

데이터베이스

OLTP (트랜잭션 처리):
  추천: io2 Block Express
  IOPS: 10,000 ~ 64,000
  이유: 낮은 레이턴시, 일관된 성능

OLAP (분석):
  추천: gp3
  IOPS: 5,000 ~ 16,000
  이유: 순차 읽기 중심, 비용 효율적

개발/테스트:
  추천: gp3
  IOPS: 3,000 (기본값)
  이유: 프로덕션 대비 저비용

빅데이터 & ETL

Spark/Hadoop:
  추천: st1 (Throughput Optimized HDD)
  이유: 대용량 순차 I/O, MB/s 중심

Lambda 기반 ETL:
  추천: gp3
  IOPS: 3,000 ~ 5,000
  이유: 짧은 실행, 비용 효율

Glue/EMR:
  추천: gp3
  IOPS: 5,000 ~ 10,000
  이유: 중간 크기 변환, 확장 가능

웹/애플리케이션 서버

프로덕션:
  추천: gp3
  IOPS: 3,000 ~ 5,000
  이유: 적절한 성능, 비용 효율

고트래픽:
  추천: gp3
  IOPS: 10,000+
  이유: 동시 요청 처리

부트 볼륨:
  추천: gp3
  IOPS: 3,000 (기본값)
  크기: 30-50 GB

흔한 실수와 해결책

실수 1: Burst Balance 무시 (gp2)

문제:

gp2 100GB 볼륨
→ 기본 300 IOPS (100GB × 3)
→ Burst로 3,000 IOPS 가능
→ Burst 크레딧 고갈 시 300 IOPS로 급락

해결:

✅ gp3로 마이그레이션
✅ 또는 볼륨 크기를 1,000GB로 증가 (3,000 IOPS 보장)

실수 2: 인스턴스 타입 미스매치

문제:

io2 Block Express 64,000 IOPS + t3.large
→ t3.large는 최대 2,780 IOPS
→ 61,220 IOPS 낭비

해결:

✅ 인스턴스 타입 업그레이드 (예: m6i.4xlarge)
✅ 또는 볼륨 IOPS를 인스턴스 한계에 맞춤

실수 3: 과다 프로비저닝

문제:

"혹시 몰라" 16,000 IOPS 프로비저닝
→ 실제 사용: 평균 800 IOPS
→ 불필요한 비용 발생

해결:

✅ 2주간 모니터링 후 적정 크기 산정
✅ 95th percentile + 30% 여유분
✅ Auto Scaling 고려 (Elastic Volumes)

Elastic Volumes로 동적 조정

EBS Elastic Volumes 기능으로 중단 없이 IOPS 조정 가능:

# 볼륨 IOPS 증가 (gp3)
aws ec2 modify-volume \
  --volume-id vol-12345678 \
  --iops 10000

# 볼륨 타입 변경 (gp2 → gp3)
aws ec2 modify-volume \
  --volume-id vol-12345678 \
  --volume-type gp3 \
  --iops 5000

# 변경 상태 확인
aws ec2 describe-volumes-modifications \
  --volume-id vol-12345678

주의사항:

6시간에 한 번만 수정 가능
일부 변경은 파일시스템 확장 필요
프로덕션 환경은 점진적 변경 권장

핵심 정리

IOPS 선택 체크리스트

☐ 워크로드 유형 파악 (OLTP vs OLAP vs ETL)
☐ 필요 IOPS 산정 (CloudWatch 기반)
☐ 볼륨 타입 선택 (gp3 vs io2)
☐ 인스턴스 타입 호환성 확인
☐ 비용 대비 성능 평가
☐ 모니터링 및 알람 설정
☐ 정기적 리뷰 및 최적화

볼륨 타입 선택 플로우차트

시작
 ├─ 임시/개발 환경? → gp3 (3,000 IOPS)
 ├─ 범용 웹/앱? → gp3 (3,000-10,000 IOPS)
 ├─ 데이터베이스?
 │   ├─ OLTP? → io2 Block Express (10,000-64,000 IOPS)
 │   └─ OLAP? → gp3 (5,000-16,000 IOPS)
 ├─ 빅데이터 순차 I/O? → st1 (HDD)
 └─ Mission-critical? → io2 Block Express (최고 성능)

결론

EBS IOPS는 단순한 숫자가 아니라, 애플리케이션 성능과 비용을 직접 좌우하는 핵심 요소입니다.

성공적인 IOPS 관리의 3대 원칙:

측정 우선: 추측이 아닌 데이터 기반 결정
점진적 최적화: 작게 시작해서 필요에 따라 확장
지속적 모니터링: 워크로드 변화에 맞춰 조정

특히 하이브리드 클라우드 환경이나 ETL 워크로드에서는 초기 보수적 설정으로 시작해, 실제 사용 패턴을 수집한 후 최적화하는 것이 가장 안전하고 비용 효율적입니다.

AWS는 Elastic Volumes 기능을 통해 중단 없는 IOPS 조정을 지원하므로, 과도한 오버 프로비저닝보다는 적정 수준에서 시작해 필요시 확장하는 전략을 추천합니다.

참고 자료

이 글이 도움이 되셨다면 공유해주세요! 궁금한 점은 댓글로 남겨주시면 답변드리겠습니다.

[Firebase] iOS Swizzling 기능 이해하기

Jason Nam — Tue, 18 Feb 2025 22:31:22 +0900

iOS Swizzling 기능 이해하기

Firebase Swizzling이란?

iOS 개발에서 말하는 Method Swizzling은 “메서드 동적 교체”라고 번역할 수 있는데, 이는 특정 메서드의 동작을 런타임에 바꿔치기하는 기술을 의미한다. iOS 앱 개발에서 Firebase를 활용하면 푸시 알림, 애널리틱스, 딥링크 등 다양한 기능을 쉽게 구현할 수 있다. 이러한 편리함의 핵심 기술 중 하나가 Method Swizzling이다. 이번 포스트에서는 Firebase Swizzling이 무엇인지, 왜 활성화되어 있는지, 그리고 이를 비활성화하는 방법에 대해 알아보겠다.

Firebase에서 Swizzling을 사용하는 이유

Swizzling은 iOS의 Objective-C 런타임 기능을 활용하여 특정 메서드를 런타임에 동적으로 교체하는 기술이다. Firebase는 이 기법을 사용하여 앱의 코드 수정 없이도 자동으로 특정 기능을 활성화할 수 있도록 돕는다. 따라서 개발자가 직접 여러 가지 설정을 하지 않아도 Firebase가 자동으로 필요한 작업을 수행하도록 하며 대표적인 예는 다음과 같다:

1. 푸시 알림(APNs) 자동 등록

Firebase Cloud Messaging(FCM)은 앱이 실행될 때 자동으로 APNs 토큰을 등록하고 Firebase 서버로 전송한다. Swizzling이 활성화되어 있으면 개발자가 didRegisterForRemoteNotificationsWithDeviceToken을 직접 구현하지 않아도 된다.

2. Firebase Analytics 자동 이벤트 수집

Firebase Analytics는 Swizzling을 이용하여 화면 이동이나 특정 이벤트를 자동 감지하고 데이터를 수집한다. 이를 통해 개발자가 별도로 코드 추가 없이도 사용자 행동을 분석할 수 있다.

3. Firebase Dynamic Links 자동 처리

Firebase Dynamic Links는 Swizzling을 통해 앱이 특정 URL을 통해 실행될 경우 자동으로 관련 정보를 가져와 처리한다. 이를 통해 딥링크 관련 추가 코드를 최소화할 수 있다.

Firebase Swizzling 비활성화 방법

Swizzling이 편리하지만, 특정한 이유로 직접 제어하고 싶다면 비활성화할 수 있다. Swizzling을 끄는 방법은 Firebase 서비스별로 다르다.

1. FCM Swizzling 비활성화

푸시 알림에서 Swizzling을 끄려면 Info.plist에 아래 설정을 추가하면 된다.

<key>FirebaseAppDelegateProxyEnabled</key>
<false/>

이렇게 하면 Firebase가 자동으로 푸시 알림을 설정하지 않으며, 직접 UNUserNotificationCenterDelegate와 UIApplicationDelegate의 didRegisterForRemoteNotificationsWithDeviceToken을 구현해야 한다. 이번에 테스트한 케이스에서 FirebaseApp.configure() 함수를 선언하고 이후에 registerForRemoteNotifications를 호출하면 swizzling이 발생하는 것을 확인하였다.

2. Firebase Analytics Swizzling 비활성화

애널리틱스 이벤트 자동 추적을 비활성화하려면 Info.plist에 다음 키를 추가한다.

<key>FIREBASE_ANALYTICS_COLLECTION_ENABLED</key>
<false/>

이렇게 하면 Firebase가 자동으로 애널리틱스 데이터를 수집하지 않으며, 개발자가 수동으로 Analytics.logEvent를 호출해야 한다.

3. Firebase Dynamic Links Swizzling 비활성화

Dynamic Links Swizzling을 비활성화하려면 Info.plist에 아래 설정을 추가한다.

<key>FirebaseDeepLinkAutomaticRetrievalEnabled</key>
<false/>

이렇게 하면 Firebase가 자동으로 딥링크를 처리하지 않으며, 개발자가 직접 handleOpenURL 또는 continueUserActivity를 구현해야 한다.

결론

Firebase Swizzling은 개발자의 편의를 위해 자동화된 기능을 제공하지만, 프로젝트에 따라 불필요하거나 원치 않는 동작을 할 수도 있다. 앱의 동작을 더욱 세밀하게 제어하고 싶다면 Swizzling을 비활성화하고 필요한 기능을 직접 구현하는 것이 좋다. Swizzling을 끄는 경우, 반드시 관련된 기능을 수동으로 설정해야 한다는 점을 잊지 말자.

Web to app 어트리뷰션 트래킹하기

Jason Nam — Wed, 20 Nov 2024 13:45:52 +0900

Web to app 어트리뷰션 트래킹하기

디지털 마케터들이 꼭 알아야 할 웹투앱 어트리뷰션에 대해 상세히 알아보겠습니다. 특히 Singular의 솔루션을 중심으로, 실제 구현 방법과 활용 전략까지 자세히 다뤄보겠습니다.

1. 웹투앱 어트리뷰션이란?

웹투앱 어트리뷰션은 사용자가 모바일 웹사이트에서 네이티브 앱으로 전환되는 여정을 추적하는 기술입니다. 예를 들어, 페이스북 광고를 통해 웹사이트에 방문한 사용자가 나중에 앱을 설치하는 경우, 이 설치가 어떤 웹 광고로부터 발생했는지 추적할 수 있습니다.

왜 중요할까요?

정확한 마케팅 ROI 측정
크로스 플랫폼 사용자 경험 이해
웹과 앱 전환 최적화 가능
통합된 마케팅 성과 분석

2. Singular의 웹투앱 어트리뷰션 솔루션 살펴보기

Singular에서는 두 가지 핵심 요소를 통해 웹투앱 어트리뷰션을 구현합니다:

Singular Links: 스마트한 추적 링크 시스템
Singular Web SDK: 웹사이트 데이터 수집 도구

따라서 웹투앱 어트리뷰션을 실행하기 위해서는 웹 SDK와 앱 SDK를 모두 적용해야 합니다.

웹투앱 플로우

구현코드 예시

// 기본적인 앱 오픈 구현
singularSdk.openApp("https://mydomain.sng.link/Buour/55cx");

// 상세 파라미터를 포함한 구현
singularSdk.openApp("https://mydomain.sng.link/Auour/55ba",
"deeplink_value", 
"passthrough_value", 
"deferred_value");

3. UTM 파라미터 활용하기

Singular는 웹 마케팅에서 흔히 사용하는 UTM 파라미터를 자동으로 매핑합니다:

UTM 파라미터 <--> Singular 매핑

utm_source	Source
utm_campaign	Campaign Name
utm_content	Creative Name
utm_term	Keyword

4. 실전 활용 팁

구현 전 체크리스트

Singular Web SDK 최신 버전 설치 (v1.0.8 이상)
기본 Singular Link 생성
딥링크 지원 설정 (필요한 경우)

리포팅 활용하기

"Mobile Web to App" 트래커로 웹투앱 전환 모니터링
Link Type 차원을 통한 상세 분석
UTM 기반 웹 캠페인 성과 확인

5. 마무리

웹투앱 어트리뷰션은 현대 디지털 마케팅에서 필수적인 도구입니다. 특히 옴니채널 전략을 구사하는 기업이라면, 이 기술을 통해 더 정확한 마케팅 성과 측정과 최적화가 가능합니다.

다음 단계 추천

Singular 웹 SDK 설치
테스트 캠페인 실행
데이터 분석 및 최적화

더 자세한 내용이 궁금하시다면 댓글로 남겨주세요! 다음 포스트에서는 웹투앱 어트리뷰션의 고급 활용 전략에 대해 다루도록 하겠습니다.

[Langchain] AWS Bedrock과 Langchain 활용한 LLM 어플리케이션 개발

Jason Nam — Wed, 20 Nov 2024 07:13:42 +0900

[Langchain] AWS Bedrock과 Langchain 활용한 LLM 어플리케이션 개발

RAG 및 Agent를 활용하여 솔루션 엔지니어링에 도입하기에 앞서 AWS Bedrock과 Langchain을 활용하여 LLM(Large Language Model) 어플리케이션을 개발하는 방법에 대해 단계별로 알아보려고 합니다. 우선 개념에 대한 내용을 정리한 후 솔루션 엔지니어링 가이드 및 헬프센터 내용을 RAG를 통해 이해하고 답변을 하는 어플리케이션 개발을 진행할 예정이며, 이번 아티클에서는 LLM 개발을 처음 시작할 때 필요한 기초개념 및 기본 설계에 대한 내용을 다룹니다.

Langchain에 대한 이해

Langchain은 LLM 어플리케이션 개발을 위한 프레임워크로 다양한 컴포넌트들을 제공하여 LLM 기반 어플리케이션을 쉽게 구축할 수 있습니다.

LLM 컴포넌트

Models: LLMs, Chat Models, Embeddings
Prompts: 템플릿, Few-shot Examples
Memory: 대화버퍼(이전 대화내용 저장), 요약메모리(긴 대화 내용을 요약하여 저장)
Chains: LLMChain, 순차체인
Agents: Zero-shot Agent, Structured Agent
Tools: 검색(웹), 계산기

AWS Bedrock에 대한 이해

AWS Bedrock은 Amazon Web Services에서 제공하는 완전 관리형 서비스로, 다양한 기초 모델(Foundation Models)을 API를 통해 쉽게 사용할 수 있게 해주는 플랫폼입니다. Anthropic의 Claude, OpenAI의 GPT AI21 Labs의 Jurassic, Amazon의 Titan 등 최고 수준의 AI 모델들을 단일 API로 통합하여 제공합니다.

Bedrock의 특징

다양한 모델 선택 가능
보안 및 프라이버시
비용효율성
AWS 솔루션과의 통합 용이

Langchain - Bedrock 연동 플로우

Langchain에서 Bedrock을 통해 LLM Application을 구축할 경우, 직접 LLM Models(OpenAI GPT, Anthropic Claude 등)의 API를 호출하지 않고, AWS Bedrock을 통해 간접적으로 모델과 통신하게 됩니다. 즉 Langchain Framework ▶ AWS SDK ▶ Bedrock Runtime ▶ LLM Model 순서로 통신을 합니다. Langchain을 통해 직접 LLM 어플리케이션 개발과 달리 AWS Bedrock을 통해 간접적으로 LLM 모델과 통신하므로 직접 OpenAI, Anthropic 등에서 API 키를 발급받지 않아도 되며, 과금 또한 AWS 사용비용으로 대체됩니다.

Lanchain - AWS Bedrock 연동 플로우

Bedrock 역할

API 게이트웨이 역할
인증(Authentication)/인가(Authorization)
요청 및 응답
모델 버전 관리

Langchain 역할

프롬프트 엔지니어링
Chain/Agent 로직 처리
응답 후 처리

API Key 연동 및 이에 따른 과금이 다름

Note. AWS Bedrock 연동시 장점
- 보안 강화: AWS IAM을 통한 접근제어
- 관리 용이성: AWS 모니터링 및 로깅 활용 가능
- 확장성: Bedrock을 통한 다양한 파운데이션 모델 사용 가능
- 비용효율성: 사용량에 비례하여 AWS 비용 과금

연동 상세

사전 준비사항

LLM 어플리케이션 개발을 위해 아래 환경을 준비합니다.

Python 3.8 이상: Poetry를 활용한 설치 권장
AWS 계정: Bedrock 접근권한 추가

Bedrock 기본권한 정책 추가

정책 생성

aws iam create-policy \
    --policy-name BedrockAccessPolicy \
    --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BedrockFullAccess",
            "Effect": "Allow",
            "Action": [
                "bedrock:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "BedrockModelAccess",
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "arn:aws:bedrock:*:281606047546:model/*"
        }
    ]
}'

IAM User에 정책추가

aws iam attach-user-policy \
    --user-name bedrock-user \
    --policy-arn arn:aws:iam::<User-ID>:policy/BedrockAccessPolicy

BedrockAccessPolicy 추가

정책추가 확인

aws iam list-attached-user-policies --user-name bedrock-user

Python 환경 설정

AWS Bedrock을 활용하여 테스트하기 위해 Langchain 공식문서의 ChatBedrock을 사용하였습니다. boto3를 활용한 AWS SDK기반 구현도 가능한 옵션입니다. 테스트시 anthropic.claude-3-5-sonnet-20240620-v1:0을 사용하였고, Python 가상환경 및 의존성 설치는 Poetry를 활용하였습니다.

Poetry shell

poetry shell

Poetry 환경에서 모듈 설치

poetry add langchain_aws

코드작성

- ChatBedrock:

from dotenv import load_dotenv
from langchain_aws import ChatBedrock
from langchain_teddynote import logging
import time
from botocore.exceptions import UnknownEndpointError

load_dotenv()

logging.langsmith("langchain_on_aws")

def get_bedrock_client():
    return ChatBedrock(
        model="anthropic.claude-3-5-sonnet-20240620-v1:0",
        model_kwargs={
            "temperature": 0.7,
            "max_tokens": 1024,
            "top_p": 0.9
        },
        region="ap-northeast-2"
    )

def get_bedrock_llm():
    try:
        llm = get_bedrock_client()
        return llm
    except Exception as e:
        print(f"Error creating Bedrock client: {e}")
        return None
    

def main():
    llm = get_bedrock_llm()
    if llm is None:
        print("LLM 초기화 실패")
        return
    # invocation
    message = [
        (
            "system",
            "You are a helpful assistant. Answer the user's question. Translate the answer to Korean."
        ),
        ("human", "What is the capital of Korea?")
    ]

    # 최대 재시도 횟수와 대기 시간 설정
    max_retries = 3
    retry_delay = 2  # 초단위
    
    for attempt in range(max_retries):
        try:
            response = llm.invoke(message)
            print(response.content)
            break
        except UnknownEndpointError as e:
            if attempt < max_retries - 1:
                print(f"요청이 제한되었습니다. {retry_delay}초 후 재시도합니다... ({attempt + 1}/{max_retries})")
                time.sleep(retry_delay)
                retry_delay *= 2  # 지수 백오프
            else:
                print("최대 재시도 횟수를 초과했습니다.")
                raise

if __name__ == "__main__":
    main()

실행결과

FastAPI 기반 이커머스 아키텍쳐 설계 - 1. 대용량 트래픽 아키텍쳐 개요

Jason Nam — Sat, 2 Nov 2024 20:55:14 +0900

FastAPI 기반 이커머스 아키텍쳐 설계 - 1. 대용량 트래픽 아키텍쳐 개요

이커머스 서비스를 구현하기 위해 대용량 트래픽 처리를 고려한 아키텍쳐 설계 방안에 대해 정리해 보았습니다. 프론트엔드는 Next.js 기반, 백엔드는 FastAPI, 인프라는 AWS를 활용하여 서비스 개발을 진행하도록 아키텍쳐를 구성하였습니다. 대용량 트래픽 처리가 가능한 시스템 구현시 확장성 및 높은 동시성을 확보하는 것이 중요합니다.

대용량 트래픽 처리시 "확장성"과 "동시성"의 개념에 대한 이해

확장성(Scalability):

사용자 증가나 데이터 확장에 따라 성능을 유지하며 성장할 수 있는지 여부를 의미합니다. 이는 시스템이 변하는 부하를 효과적으로 처리하고, 사용자가 증가하더라도 안정성과 성능을 유지할 수 있도록 하는 설계와 구조를 갖추는 것입니다. 확장성은 크게 두가지로 구분할 수 있습니다.

수평적 확장성(Horizontal Scaling):

서버 수를 확장함으로서 성능을 높이는 방식으로 여러 서버를 네트워크로 연결. 개별 서버에 부하가 집중되지 않도록 분산처리하는 것을 고려합니다.

■ 방안: 로드밸런서(e.g. NGINX)를 통해 트래픽을 각 서버로 고르게 분산하고 이를 통해 시스템 전체가 더 많은 요청을 안정적으로 처리

■ 특성 및 고려사항

1. 개별 서버의 성능에 상대적으로 덜 의존하게 되며, 필요에 따라 새로운 서버를 추가함으로써 트래픽 처리 용량을 늘릴 수 있음

2. 고려사항: 복잡한 관리, 데이터 일관성, 네트워크 지연, 디버깅 및 모니터링 복잡성, 로드 밸런싱의 한계 고려 필요

1) 복잡한 관리: 수평적 확장성을 고려하여 대용량 트래픽 처리가 가능하도록 설계 시 관리상의 복잡도가 증가할 수 있으며, 이를 보완하기 위해 컨테이너화, 오케스트레이션 도구 활용, IaC 등을 고려할 수 있습니다.

어플리케이션 측면

1. 컨테이너화: 도커와 같은 컨테이너 기술을 활용하여 일관된 어플리케이션 환경을 제공하여, 서버관리의 복잡성을 줄일 수 있음
2. 오케스트레이션 도구 활용: 쿠버네티스(k8s), 도커 스웜(Docker Swarm) 같은 오케스트레이션 도구를 활용하여 서버배포,운영을 자동화하여 관리 부담을 줄일 수 있음

인프라 측면

1. Infrastructure as Code(IaC): Terraform, Ansible 등을 사용해 인프라 코드를 관리하여 반복적인 설정 및 변경작업을 자동화하고 일관성을 유지할 수 있음

2) 데이터 일관성 문제: 분산 시스템에서는 여러 서버에 데이터를 나누어 저장하거나 처리하기 때문에, 데이터 일관성을 유지하는 데 어려움이 있을 수 있습니다. 예를 들어, 데이터베이스 샤딩을 적용했을 때 데이터 간의 동기화를 보장하는 데 추가적인 노력이 필요합니다. 이를 보완하기 위해 Apache Cassandra나 Google Spanner 등의 분산 DB를 사용하여 데이터 일관성 및 분산된 환경에서의 가용성을 보장하는 방법을 고려할 수 있습니다.

3) 비용: 서버를 추가할 때마다 추가적인 하드웨어 비용뿐만 아니라, 네트워크 인프라, 유지 보수, 전력 비용 등도 증가합니다. 클라우드 서비스를 사용하더라도 트래픽 분산과 관련된 비용이 높아질 수 있습니다. 이를 보완하기 위해 자동 스케일링, 서버리스 컴퓨팅 도입을 고려할 수 있습니다.

자동 스케일링: 클라우드 서비스에서 제공하는 자동 스케일링 기능을 활용하여 트래픽 증가시에만 서버 인스턴스를 자동으로 늘리고 부하가 줄어들면 인스턴스를 축소하여 비용을 절감할 수 있음
서버리스 컴퓨팅 도입: AWS Lambda, Google Cloud Functions 등의 서버리스 기능을 활용하여 트래픽 변화에 따라 유연하게 대응할 수 있으며, 실행된 만큼 비용이 청구되므로 이를 통한 경제적인 운영이 가능함

4) 네트워크 지연: 여러 서버가 분산되어 있으면 요청과 응답 과정에서 네트워크 지연(latency)이 발생할 수 있습니다. 특히, 서버 간의 데이터 전송이 필요한 경우 지연 시간이 성능에 영향을 줄 수 있습니다.

CDN 활용: 정적 자산(static asset) 및 캐시가능한 컨텐츠를 CDN에 배포하여 클라이언트-서버간 지연을 줄일 수 있음
Static asset: HTML, CSS, Javascript(클라이언트 측 스크립트), 이미지파일, 폰트파일, 동영상 및 오디오 컨텐츠, 아이콘 및 벡터 이미지, 애플리케이션 번들 및 라이브러리, 변경빈도가 적은 API 응답
지연 최소화 전략: 각 서버의 지리적 위치를 사용자와 가깝게 두거나, edge 서버를 활용한 시간을 줄이는 방안
네트워크 최적화: 트래픽 우선순위 설정 및 압축기법을 적용해 네트워크 대역폭(bandwidth)를 효율적으로 사용

5) 디버깅 및 모니터링 복잡성: 분산된 여러 서버에서 문제가 발생했을 때, 디버깅과 모니터링이 어렵습니다. 로그를 중앙에서 관리하고, 각 서버의 상태를 추적하는 시스템이 필요하며 이로 인한 운영상의 부담을 증가시킬 수 있습니다. 이를 보완하기 위해 통합로깅, 분산추적시스템, 모니터링 도구 도입을 고려하는 것이 필요합니다.

통합로깅시스템 도입: ELK, Grafana 등의 툴을 활용하여 모든 서버의 로그를 중앙에 수집하고 이를 시각화하여 관리
분산추적시스템: Jaeger, Zipkin 등을 통해 분산된 시스템에서의 요청지점을 분석하고 병목지점을 파악
모니터링 도구: Prometheus와 같은 모니터링 툴을 활용해 각 서버의 상태, 자원 사용률, 응답시간을 실시간으로 추적하고 경고알림을 설정하여 빠르게 대응할 수 있음

6) 로드 밸런싱의 한계: 로드 밸런서가 모든 서버에 트래픽을 균등하게 분산해도, 각 서버의 상태나 성능이 다를 경우 특정 서버에 과부하가 걸릴 수 있습니다. 로드 밸런싱 자체가 병목점이 되지 않도록 주의해야 합니다. 이를 보완하기 위해 지능형 로드밸런싱, 부하분산전략 다중화를 고려할 수 있습니다.

지능형 로드밸런싱: 단순한 라운드로빈방식 대신, 각 서버의 상태를 고려해 트래픽을 분산하는 지능형 로드밸런서 도입: AWS ELB, NGINX의 상태기반 로드밸런싱 기능
부하분산전략 다중화: 로드밸런서 이중화

수직적 확장성(Vertical Scaling):

기존 서버의 하드웨어 성능을 업그레이드하여 더 많은 요청처리가 가능하도록 하는 방식으로 CPU, RAM, 스토리지 등의 자원을 추가하거나 교체하여 처리성능을 개선하게 되어 이를 통해 더 많은 요청을 처리할 수 있습니다. 이를 위해 CPU 코어를 늘리거나 더 빠른 메모리, 더 큰 스토리지를 추가해 성능을 높입니다.

장점: 시스템을 상대적으로 간단한 구조로 유지할 수 있으며, 복잡한 네트워크 구성 없이 처리 성능을 올릴 수 있습니다.
단점: 하드웨어 한계에 도달시 추가 확장이 어렵다는 점, 하드웨어 관련 비용증가를 고려해야 합니다.

동시성(Concurrency):

아키텍쳐 레벨의 동시성:

수천~수만의 사용자가 동시에 서비스를 요청할때 이를 효율적으로 트래픽을 처리할 수 있는 아키텍쳐가 필요합니다. 이 레벨에서는 다수의 서버, 로드밸런싱, 분산처리시스템 등이 동시성을 보장합니다.

예시:

로드밸런서
CDN
분산 데이터베이스
메시지큐: Kafka, RabbitMQ 등의 시스템을 활용하여 대량의 데이터를 비동기적으로 처리할 수 있습니다. 이는 트래픽 급증 시 서버가 즉시 모든 요청을 처리할 필요없이 작업을 큐에 쌓아두고 차례대로 처리하도록 합니다.

단일 어플리케이션 레벨의 동시성:

I/O 대기시간을 최소화하고 단일 서버가 최대한 많은 클라이언트 요청을 처리하도록 하는 것이 목적
현재 개발시 활용중인 Fast API를 통해 어플리케이션 레벨에서의 비동기 처리가 가능합니다.
비동기 엔드포인트: 아래 예시는 FastAPI와 asyncio를 사용하여 엔드포인트 호출시 비동기적으로 대기를 진행하면서 다른 클라이언트의 요청을 비동기처리하는 것을 보여줍니다.

from fastapi import FastAPI
import asyncio

app = FastAPI()

@app.get("/process-data")
async def process_data():
    await asyncio.sleep(5)  # 비동기적으로 대기, 다른 요청을 병행 처리 가능
    return {"message": "Data processed"}

비동기 데이터베이스 라이브러리 지원: asyncpg와 같은 비동기 데이터베이스 클라이언트를 사용하여 DB와의 비동기 연동을 지원할 수 있습니다.

기본 아키텍쳐 구성

Python - Shallow Copy와 Deep Copy의 차이점 및 사용법

Jason Nam — Sun, 23 Jun 2024 10:43:33 +0900

Shallow Copy와 Deep Copy의 차이점 및 사용법

파이썬 개발자로서 코드를 작성하다 보면 객체를 복사해야 하는 상황이 자주 발생합니다. 객체를 복사하는 방법에는 크게 두 가지가 있습니다: Shallow Copy(얕은 복사)와 Deep Copy(깊은 복사). 이 두 가지 복사 방식은 동작 방식과 결과가 다르기 때문에, 언제 어떤 방식을 사용해야 하는지 정확히 이해하는 것이 중요합니다.

Shallow Copy (얕은 복사)

특징

Shallow Copy는 객체의 가장 바깥쪽 객체만 복사하고, 그 객체가 참조하는 내부 객체들은 원본 객체와 동일하게 참조하는 방식입니다. 즉, 복사된 객체 내부의 가변 객체(리스트, 딕셔너리 등)는 원본 객체와 동일한 참조를 가리키게 됩니다.

사용법

파이썬에서 얕은 복사는 copy 모듈의 copy 함수를 사용하거나, 리스트의 경우에는 슬라이싱을 이용해 생성할 수 있습니다.

코드 예시

import copy

# 원본 리스트 생성
original_list = [[1, 2, 3], [4, 5, 6]]

# 얕은 복사 생성
shallow_copied_list = copy.copy(original_list)

# 값 변경
shallow_copied_list[0][0] = 99

print("원본 리스트:", original_list)
print("얕은 복사 리스트:", shallow_copied_list)

예상결과값

원본 리스트: [[1, 2, 3], [4, 5, 6]]
깊은 복사 리스트: [[99, 2, 3], [4, 5, 6]]

위의 코드에서 shallow_copied_list의 내부 리스트 요소를 변경하면, original_list도 영향을 받습니다. 이는 얕은 복사가 내부 객체를 동일하게 참조하기 때문입니다.

Deep Copy (깊은 복사)

특징

Deep Copy는 객체와 그 객체가 참조하는 모든 객체를 재귀적으로 복사하여 완전히 독립적인 복사본을 만듭니다. 따라서 복사된 객체와 원본 객체는 서로 전혀 영향을 주지 않습니다.

사용법

파이썬에서 깊은 복사는 copy 모듈의 deepcopy 함수를 사용합니다.

코드 예시

import copy

# 원본 리스트 생성
original_list = [[1, 2, 3], [4, 5, 6]]

# 깊은 복사 생성
deep_copied_list = copy.deepcopy(original_list)

# 값 변경
deep_copied_list[0][0] = 99

print("원본 리스트:", original_list)
print("깊은 복사 리스트:", deep_copied_list)

예상 결과값

원본 리스트: [[1, 2, 3], [4, 5, 6]]
깊은 복사 리스트: [[99, 2, 3], [4, 5, 6]]

위의 코드에서 deep_copied_list의 내부 리스트 요소를 변경해도 original_list는 영향을 받지 않습니다. 이는 깊은 복사가 모든 객체를 재귀적으로 복사하여 독립적인 객체를 생성하기 때문입니다.

언제 사용해야 할까?

Shallow Copy는 복사된 객체와 원본 객체가 일부 데이터를 공유해도 상관없을 때 사용합니다. 예를 들어, 불변 객체나 단순한 데이터 구조를 사용할 때 적합합니다.
Deep Copy는 복사된 객체와 원본 객체가 완전히 독립적이어야 할 때 사용합니다. 예를 들어, 중첩된 데이터 구조가 있는 경우나 복사본이 원본 데이터에 영향을 주지 않도록 보장해야 하는 경우에 사용합니다.

결론

파이썬에서 Shallow Copy와 Deep Copy는 각각의 특성과 용도에 맞게 적절히 사용해야 합니다. Shallow Copy는 객체의 가장 바깥쪽만 복사하고 내부 객체는 참조를 공유하는 반면, Deep Copy는 모든 객체를 재귀적으로 복사하여 독립적인 복사본을 만듭니다. 이를 잘 이해하고 상황에 맞게 활용하면 더 안정적이고 예측 가능한 코드를 작성할 수 있습니다. 파이썬의 copy 모듈을 통해 쉽게 Shallow Copy와 Deep Copy를 구현할 수 있으니, 필요에 따라 적절한 방법을 선택하여 사용하시기 바랍니다.

참고자료

Understanding the Difference Between Shallow Copy, Deep Copy, and References in Python

Understanding the Difference Between Shallow Copy, Deep Copy, and References in Python

Understanding shallow and deep copy in Python is crucial for effective data manipulation and maintaining data integrity. These concepts are essential when working with complex data structures like lists and dictionaries.

www.linkedin.com

Airflow 로컬 환경 설치 및 테스트

Jason Nam — Wed, 29 May 2024 16:43:05 +0900

Airflow 로컬 환경 설치 및 테스트

ETL(Extract, Transform, Load)은 데이터 통합 및 분석의 핵심 프로세스입니다. Apache Airflow는 이러한 ETL 파이프라인을 관리하고 자동화하는 강력한 도구로 자리잡았습니다. 이 글에서는 Airflow를 활용하여 ETL 파이프라인을 설계, 구현, 운영하는 방법을 단계별로 설명하겠습니다.

1. Airflow 소개

Apache Airflow는 데이터 파이프라인을 작성, 스케줄링 및 모니터링하기 위한 오픈 소스 플랫폼입니다. Airflow의 주요 특징은 다음과 같습니다:

다양한 연산 지원: Python을 기반으로 DAG(Directed Acyclic Graph)를 작성하여 다양한 작업을 정의할 수 있습니다.
스케줄링: 원하는 시간에 작업을 자동으로 실행할 수 있습니다.
모니터링: 작업의 상태를 시각적으로 확인하고 관리할 수 있습니다.
확장성: 플러그인을 통해 다양한 데이터 소스와 통합할 수 있습니다.

2. Airflow 설치

Airflow를 설치하려면 Python과 pip이 필요합니다. 기본 설치 과정은 다음과 같습니다:

pip install apache-airflow

Airflow를 설치한 후 초기화 및 웹 서버를 실행합니다:

# 데이터베이스 초기화
airflow db init

# 사용자 생성 (선택 사항)
airflow users create \\\\
    --username admin \\\\
    --firstname FIRST_NAME \\\\
    --lastname LAST_NAME \\\\
    --role Admin \\\\
    --email admin@example.com

# 웹 서버 실행
airflow webserver --port 8080

다른 터미널에서 스케줄러를 실행합니다:

airflow scheduler

3. ETL 파이프라인 설계

ETL 파이프라인을 설계할 때 각 단계는 개별 작업(task)으로 정의됩니다. 예제에서는 간단한 CSV 파일을 추출, 변환, 로드하는 파이프라인을 생성해보겠습니다.

3.1 추출 단계

데이터를 추출하는 작업을 정의합니다. 예를 들어, 원격 서버에서 CSV 파일을 다운로드하는 작업입니다.

from airflow import DAG
from airflow.operators.python_operator import PythonOperator
from datetime import datetime
import requests

def extract_data(**kwargs):
    url = '<https://example.com/data.csv>'
    response = requests.get(url)
    with open('/path/to/save/data.csv', 'wb') as f:
        f.write(response.content)

with DAG(dag_id='etl_pipeline', start_date=datetime(2023, 1, 1), schedule_interval='@daily') as dag:
    extract_task = PythonOperator(
        task_id='extract_data',
        python_callable=extract_data

3.2 변환 단계

추출한 데이터를 변환하는 작업을 정의합니다. 예를 들어, 데이터를 정리하고 필요한 형식으로 변경합니다.

import pandas as pd

def transform_data(**kwargs):
    df = pd.read_csv('/path/to/save/data.csv')
    df['new_column'] = df['existing_column'].apply(lambda x: x * 2)
    df.to_csv('/path/to/save/transformed_data.csv', index=False)

transform_task = PythonOperator(
    task_id='transform_data',
    python_callable=transform_data
)

3.3 로드 단계

변환한 데이터를 데이터베이스 또는 데이터 웨어하우스로 로드하는 작업을 정의합니다.

import sqlalchemy

def load_data(**kwargs):
    engine = sqlalchemy.create_engine('postgresql://user:password@localhost:5432/mydatabase')
    df = pd.read_csv('/path/to/save/transformed_data.csv')
    df.to_sql('my_table', engine, if_exists='replace', index=False)

load_task = PythonOperator(
    task_id='load_data',
    python_callable=load_data
)

3.4 작업 연결

모든 작업을 DAG에 추가하고 의존성을 정의합니다.

extract_task >> transform_task >> load_task

4. ETL 파이프라인 실행 및 모니터링

Airflow 웹 UI를 통해 파이프라인의 상태를 모니터링하고 실행 결과를 확인할 수 있습니다. 각 작업의 상태(성공, 실패, 진행 중)를 직관적으로 파악할 수 있으며, 실패한 작업에 대한 로그를 확인하여 문제를 해결할 수 있습니다.

5. 결론

Apache Airflow를 활용하면 ETL 파이프라인을 효율적으로 관리하고 자동화할 수 있습니다. 이 글에서 설명한 예제는 기본적인 ETL 파이프라인을 다루었지만, 실제 환경에서는 다양한 연산과 데이터 소스를 다룰 수 있습니다. Airflow의 강력한 기능을 활용하여 복잡한 데이터 워크플로우를 쉽게 관리해보세요.

참고 자료

Pandas를 이용해 데이터를 Merge하는 방법과 로깅 활용하기

Jason Nam — Wed, 29 May 2024 11:17:55 +0900

Pandas를 이용해 데이터를 Merge하는 방법과 로깅 활용하기

Pandas는 Python의 강력한 데이터 처리 라이브러리로, 다양한 데이터를 쉽고 빠르게 처리할 수 있도록 도와줍니다. 이번 글에서는 여러 CSV 파일을 하나로 병합하고, 이를 로깅을 통해 기록하는 방법을 소개하겠습니다.

준비물

Python
Pandas 라이브러리
CSV 파일

코드 설명

필요한 라이브러리 임포트

import pandas as pd
import logging
import os

pandas는 데이터 처리를 위해, logging은 로깅을 위해, os는 파일 존재 여부 확인을 위해 사용합니다.

CSV 파일 리스트 준비

csv_files = ['./origin/sample_historical_install.csv','./origin/sample_historical_install_2.csv','./origin/sample_historical_install_3.csv']

여러 CSV 파일을 하나의 리스트에 저장합니다. 이 리스트에 포함된 모든 파일을 병합할 것입니다.

로깅 설정

logging.basicConfig(level=logging.INFO, filename="py_log.log", filemode="w",
                    format="%(asctime)s %(levelname)s %(message)s")

로깅을 설정하여 로그 메시지를 파일에 기록하도록 합니다. level=logging.INFO는 정보 수준 이상의 로그만 기록하겠다는 의미입니다.

데이터프레임 리스트 생성 및 CSV 파일 읽기

dfs = []

try:
    for i, file in enumerate(csv_files):
        if os.path.exists(file):
            df = pd.read_csv(file)
            dfs.append(df)
            logging.info(f"Successfully appended DataFrame from {file}")
        else:
            logging.error(f"File not found: {file}")

여기서는 csv_files 리스트에 있는 각 파일을 읽어 데이터프레임으로 변환한 후, dfs 리스트에 추가합니다. 각 파일을 성공적으로 읽었는지 로그에 기록합니다. 파일이 존재하지 않을 경우, 에러 로그를 남깁니다.

데이터프레임 병합

    if dfs:
        merged_df = pd.concat(dfs, axis=0, ignore_index=True)
        output_path = './origin/merged_sample_install.csv'
        merged_df.to_csv(output_path, index=False)

        if os.path.exists(output_path):
            logging.info("Successfully merged and saved DataFrame")
    else:
        logging.warning("No DataFrames to merge")
except Exception as e:
    logging.error(f"An error occurred: {e}")

모든 데이터프레임을 하나로 병합한 후, 새로운 CSV 파일로 저장합니다. 병합된 파일이 성공적으로 생성되었는지 확인하고, 최종 로그를 기록합니다. FileNotFoundError 외에 다른 예외 상황도 처리하여 더욱 안정적인 코드를 만들었습니다.

Pandas concat 함수 설명

pd.concat() 함수는 여러 데이터프레임을 하나로 합칠 때 사용합니다. 이 함수는 다양한 옵션을 제공하며, 데이터 병합을 매우 유연하게 처리할 수 있습니다.

axis=0: 행을 따라 데이터프레임을 병합합니다. 즉, 데이터프레임들이 위아래로 쌓이게 됩니다. 반대로 axis=1이면 열을 따라 병합되어, 데이터프레임들이 좌우로 병합됩니다.
ignore_index=True: 병합된 데이터프레임의 인덱스를 재설정합니다. 원본 데이터프레임의 인덱스를 무시하고, 병합된 새로운 데이터프레임에 대해 0부터 시작하는 새로운 인덱스를 생성합니다.

전체 코드

import pandas as pd
import logging
import os

csv_files = ['./origin/sample_historical_install.csv','./origin/sample_historical_install_2.csv','./origin/sample_historical_install_3.csv']

dfs = []

logging.basicConfig(level=logging.INFO, filename="py_log.log", filemode="w",
                    format="%(asctime)s %(levelname)s %(message)s")

try:
    for i, file in enumerate(csv_files):
        if os.path.exists(file):
            df = pd.read_csv(file)
            dfs.append(df)
            logging.info(f"Successfully appended DataFrame from {file}")
        else:
            logging.error(f"File not found: {file}")

    if dfs:
        merged_df = pd.concat(dfs, axis=0, ignore_index=True)
        output_path = './origin/merged_sample_install.csv'
        merged_df.to_csv(output_path, index=False)

        if os.path.exists(output_path):
            logging.info("Successfully merged and saved DataFrame")
    else:
        logging.warning("No DataFrames to merge")
except Exception as e:
    logging.error(f"An error occurred: {e}")

마무리

이 글에서는 Pandas를 사용하여 여러 CSV 파일을 병합하고, 로깅을 통해 프로세스를 기록하는 방법을 배웠습니다. pd.concat() 함수를 활용하 여 여러 데이터셋을 행을 따라 데이터프레임을 병합하고, 인덱스를 재설정할 수 있습니다. 또한 로깅을 통해 코드의 실행 과정을 기록하면 디버깅과 유지 보수가 훨씬 쉬워집니다. 이 코드를 바탕으로 다양한 데이터를 효과적으로 처리해보세요!

참고자료

Logging in Python: A Developer’s Guide

Logging in Python: A Developer’s Guide

Have you ever had a tough time debugging your Python code? If yes, learning how to set up logging in Python can help you streamline your…

blog.sentry.io

[iOS 앱 개발의 핵심 이해] SceneDelegate와 AppDelegate의 차이점

Jason Nam — Tue, 28 May 2024 12:24:06 +0900

SceneDelegate와 AppDelegate의 차이점: iOS 앱 개발의 핵심 이해

iOS 앱 개발에서는 AppDelegate와 SceneDelegate가 중요한 역할을 합니다. iOS 13부터는 멀티 윈도우 환경을 지원하기 위해 SceneDelegate가 도입되었습니다. 이 두 클래스는 각각 다른 책임을 가지며, 앱의 생명주기 및 상태 관리를 처리합니다. 이 글에서는 AppDelegate와 SceneDelegate의 차이점과 각각의 역할을 예제를 통해 설명하겠습니다.

AppDelegate

AppDelegate는 앱의 전반적인 생명주기를 관리합니다. 앱이 시작되고 종료되며, 백그라운드나 포그라운드로 전환되는 등의 전반적인 이벤트를 처리합니다. AppDelegate는 주로 다음과 같은 작업을 수행합니다.

앱 초기화: 앱이 시작될 때 초기 설정을 처리합니다.
푸시 알림 설정: 푸시 알림을 설정하고 처리합니다.
백그라운드 작업: 앱이 백그라운드로 전환될 때 필요한 작업을 수행합니다.

다음은 AppDelegate의 예제 코드입니다.

import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // 앱 초기화 코드
        print("앱이 시작되었습니다.")
        return true
    }

    func applicationWillResignActive(_ application: UIApplication) {
        // 앱이 비활성화될 때 호출
        print("앱이 비활성화 상태로 전환됩니다.")
    }

    func applicationDidEnterBackground(_ application: UIApplication) {
        // 앱이 백그라운드로 전환될 때 호출
        print("앱이 백그라운드로 전환되었습니다.")
    }

    func applicationWillEnterForeground(_ application: UIApplication) {
        // 앱이 다시 포그라운드로 전환될 때 호출
        print("앱이 포그라운드로 전환됩니다.")
    }

    func applicationDidBecomeActive(_ application: UIApplication) {
        // 앱이 활성화 상태로 전환될 때 호출
        print("앱이 활성화 상태로 전환되었습니다.")
    }

    func applicationWillTerminate(_ application: UIApplication) {
        // 앱이 종료될 때 호출
        print("앱이 종료됩니다.")
    }
}

SceneDelegate

SceneDelegate는 iOS 13 이후로 도입된 클래스이며, 앱의 각 장면(Scene)에 대한 생명주기를 관리합니다. 멀티 윈도우 환경을 지원하기 위해 도입되었으며, 앱이 여러 UI 창을 가질 수 있는 경우 각 창의 상태를 독립적으로 관리합니다. SceneDelegate는 주로 다음과 같은 작업을 수행합니다.

UI 상태 관리: 각 장면의 UI 상태를 관리합니다.
장면 생명주기 이벤트 처리: 장면이 활성화되거나 비활성화될 때 이벤트를 처리합니다.

다음은 SceneDelegate의 예제 코드입니다.

import UIKit

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(_ scene: UIScene,
               willConnectTo session: UISceneSession,
               options connectionOptions: UIScene.ConnectionOptions) {
        // 장면이 연결될 때 호출
        guard let _ = (scene as? UIWindowScene) else { return }
        print("장면이 연결되었습니다.")
    }

    func sceneDidDisconnect(_ scene: UIScene) {
        // 장면이 분리될 때 호출
        print("장면이 분리되었습니다.")
    }

    func sceneDidBecomeActive(_ scene: UIScene) {
        // 장면이 활성화될 때 호출
        print("장면이 활성화되었습니다.")
    }

    func sceneWillResignActive(_ scene: UIScene) {
        // 장면이 비활성화될 때 호출
        print("장면이 비활성화됩니다.")
    }

    func sceneWillEnterForeground(_ scene: UIScene) {
        // 장면이 포그라운드로 전환될 때 호출
        print("장면이 포그라운드로 전환됩니다.")
    }

    func sceneDidEnterBackground(_ scene: UIScene) {
        // 장면이 백그라운드로 전환될 때 호출
        print("장면이 백그라운드로 전환되었습니다.")
    }
}

guard let _ = (scene as? UIWindowScene) else { return } 이 코드는 Swift에서 사용되는 guard 구문을 활용한 옵셔널 바인딩입니다. 이 코드의 목적은 주어진 scene 객체를 UIWindowScene 타입으로 안전하게 캐스팅(casting)하고, 만약 캐스팅에 실패하면 함수의 실행을 중단시키는 것입니다.

코드 설명

guard let _ = (scene as? UIWindowScene) else { return }

이 코드는 다음과 같은 의미를 갖습니다:

guard 구문: 조건이 만족되지 않으면 코드 블록을 빠져나가기 위해 사용됩니다. 여기서는 조건이 false일 경우 else 블록이 실행됩니다.
옵셔널 바인딩: scene as? UIWindowScene 표현식은 scene 객체를 UIWindowScene 타입으로 안전하게 캐스팅하려고 시도합니다. 이 캐스팅은 성공할 수도 있고 실패할 수도 있으며, 실패할 경우 nil을 반환합니다.
let _: 캐스팅이 성공할 경우, 결과 값을 _에 바인딩합니다. _는 특별한 식별자(identifier)로, 실제로 사용하지 않겠다는 의미입니다. 따라서 바인딩한 값이 필요하지 않은 경우 사용됩니다.
else { return }: 캐스팅이 실패하면 else 블록이 실행됩니다. 여기서는 return이 호출되어 현재 함수 또는 메서드의 실행을 중단합니다.

코드 흐름

이 코드는 주어진 scene이 UIWindowScene 타입인지 확인하고, 그렇지 않으면 함수를 종료합니다. UIWindowScene은 iOS 13에서 도입된 클래스로, 앱의 UI를 구성하는 창(window)을 나타냅니다. 이 코드는 일반적으로 SceneDelegate의 scene(_:willConnectTo:options:) 메서드 내에서 사용됩니다.

예제

다음은 SceneDelegate 내에서 이 코드를 사용하는 예제입니다:

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        // scene이 UIWindowScene으로 캐스팅되지 않으면 함수 종료
        guard let windowScene = (scene as? UIWindowScene) else { return }

        // window를 생성하고 UIWindowScene에 연결
        let window = UIWindow(windowScene: windowScene)
        let viewController = UIViewController()
        viewController.view.backgroundColor = .white
        window.rootViewController = viewController
        self.window = window
        window.makeKeyAndVisible()
    }
}

이 예제에서:

scene 객체가 UIWindowScene으로 캐스팅됩니다.
캐스팅에 성공하면 windowScene에 바인딩되고, 실패하면 함수가 종료됩니다.
성공한 경우 window를 생성하고 windowScene에 연결한 후, 루트 뷰 컨트롤러를 설정합니다.

이렇게 guard 구문을 사용함으로써 코드의 가독성을 높이고, 불필요한 중첩을 피할 수 있습니다. 또한, 예상치 못한 타입의 객체를 처리할 때 안전하게 대처할 수 있습니다.

주요 차이점 정리

역할:
- AppDelegate: 앱 전체의 생명주기를 관리.
- SceneDelegate: 각 장면의 생명주기를 관리.
도입 시기:
- AppDelegate: iOS 초기 버전부터 존재.
- SceneDelegate: iOS 13부터 도입.
사용 목적:
- AppDelegate: 전반적인 앱 상태 관리 (앱 시작, 종료, 백그라운드 진입 등).
- SceneDelegate: 멀티 윈도우 환경에서 각 장면의 상태 관리.

결론

iOS 앱 개발에서 AppDelegate와 SceneDelegate의 차이점을 이해하는 것은 중요합니다. AppDelegate는 여전히 앱의 전반적인 생명주기를 관리하지만, SceneDelegate는 멀티 윈도우 지원을 위해 각 장면의 생명주기를 관리합니다. 이를 통해 개발자는 더 유연하고 강력한 앱을 만들 수 있습니다. 이 두 클래스의 역할을 잘 이해하고 활용하면, 보다 안정적이고 사용자 친화적인 앱을 개발할 수 있을 것입니다.

[GA4] WebhookNotification 연동하기 - GCP 및 Slack 활용

Jason Nam — Sat, 20 Apr 2024 22:21:22 +0900

GA4 Webhook Notification 연동하기

시작하기 Getting Started

GA4는 시간이 걸리는 작업에 대한 처리완료 시 GA4 Data API에 웹훅 알림(Webhook Notification)을 설정하여 지정한 웹훅 서버로 데이터 변경에 대한 알림을 보내는 기능을 제공합니다.

웹훅이란?

웹훅이란 데이터가 변경되었을 때 실시간으로 알림을 받을 수 있는 기능입니다. 웹 서비스의 이벤트 데이터를 전달하는 HTTP 기반 콜백 함수입니다. 특정 이벤트가 발생하면 웹훅이 클라이언트에게 이벤트 데이터를 보내요. 웹훅이라는 단어는 2007년에 Jeff Lindsay에 의해 처음 사용되었어요. HTTP 기반의 웹 특징과 훅(Hook) 기능을 합친 용어죠.
(출처: 토스페이먼츠 개발자센터)
API 폴링과 웹훅의 차이점 (출처: 토스페이먼츠 개발자센터)

준비사항

GA4 Data API
GCP Cloud Functions
Slack API: Incoming Wehbhook

API 훑어보기

WebhookNotification은 audienceList API 속성에 추가하여 사용하면 됩니다. 웹훅 기능을 검증하기 위해v1alpha.properties.audienceLists.create에 Webhook 속성값을 추가하여 테스트를 진행하였습니다.

properties.audienceLists REST API

WebhookNotification API 규격 상세

WebhookNotification 상세

적용가능 API: Data API > v1alpha > properties.audienceLists 또는 properties.recurringAudienceLists에 적용 가능
Note: Google Analytics 리포트 데이터에 접근하기 위해서는 Data API를 사용해야 합니다. WebhookNotification 속성은 uri와 channelToken으로 구성됩니다.

JSON 포맷

{
  "uri": string,
  "channelToken": string
}

uri를 설정할 때 아래와 같은 특징 및 제약사항을 확인해야 합니다.

웹훅 알림을 받을 웹주소
웹훅 수신메시지는 POST request로 리턴됨
sentTimestamp: 보낸 시간(UNIX microseconds). 재전송되었는지 확인할 때 사용
HTTPS만 가능하며, 유효한 SSL 인증서가 있는 웹서버여야 함

Audience List API

HTTP Request

POST https://analyticsdata.googleapis.com/v1alpha/{parent=properties/*}/audienceLists

Path Parameter

properties값은 GA Admin > Property > Property Detail 메뉴에서 확인하세요. 위 {parent=properties/*}에 아래와 같은 형식으로 Property값을 추가하면 됩니다.

properties/262940150

Request

GA Admin API 조회에서 받아온 audience값을 Request audience값에 추가합니다. dimensionName은 deviceId로 추가합니다. uri에는 웹훅서버용으로 생성한 GCP Cloud Functions URL(https://us-central1-singular-XXXXXX.cloudfunctions.net/ga4-webhook)을 추가하였습니다.

{
  "audience": "properties/262940150/audiences/5816450822",
  "dimensions": [
    {
      "dimensionName": "deviceId"
    }
  ],
  "webhookNotification": {
    "uri": "https://us-central1-singular-XXXXXX.cloudfunctions.net/ga4-webhook"    
  }
}

Response

아래 리턴 예시에서 state가 CREATING으로 리턴된 것을 볼 수 있습니다. 작업이 완료되면 state가 ACTIVE로 변경되어 한번 더 웹훅이 리턴됩니다.

{
  "name": "operations/262940150pa2597756",
  "response": {
    "@type": "type.googleapis.com/google.analytics.data.v1alpha.AudienceList",
    "name": "properties/262940150/audienceLists/2597756",
    "audience": "properties/262940150/audiences/5816450822",
    "audienceDisplayName": "GA Data API 연동하기 - 1. Overview 페이지 방문자",
    "dimensions": [
      {
        "dimensionName": "deviceId"
      }
    ],
    "state": "CREATING",
    "beginCreatingTime": "2024-04-20T11:02:28.096195246Z",
    "rowCount": 0,
    "percentageCompleted": 0,
    "webhookNotification": {
      "uri": "https://us-central1-singular-XXXXXX.cloudfunctions.net/ga4-webhook"
    }
  }
}

GCP 설정

Cloud IAM 설정

Webhook uri 부분 가이드에 따라 역할을 부여합니다.

Webhook 가이드 내용
In Cloud IAM, you will need to grant the service account permissions to the Cloud Run Invoker (roles/run.invoker) & Cloud Functions Invoker (roles/cloudfunctions.invoker) roles for the webhook post request to pass Google Cloud Functions authentication.

가이드 내용과 같이 google-analytics-audience-export@system.gserviceaccount.com에 Cloud Run 호출자, Cloud Functions 호출자 역할을 추가했습니다. (아래 그림)

Cloud Function 생성

Cloud Functions 함수 만들기

환경: 2세대(2nd gen)
Function name: ga4-webhook
Region: us-central1(선택)
Trigger
- Trigger type: HTTPS
- Authentication: Require authentication 선택

Cloud Functions 생성

웹훅 코드 추가

웹훅 코드 추가

샘플코드

package.json

{
  "dependencies": {
    "@google-cloud/functions-framework": "^3.0.0",
    "axios": "1.6.7"
  }
}

index.js

const functions = require('@google-cloud/functions-framework');
const http = require('axios');

functions.http('ga4webhook', async (req, res) => {
  // res.send(`Hello ${req.query.name || req.body.name || 'World'}!`);
  const postback_body = req.body;
  console.log(`postback: ${JSON.stringify(req.body)}`);

  const response = await http.post('<Slack Incoming Webhook URL>',{
    text: JSON.stringify(req.body)
  });
  console.log(`response: ${response.data}`);
  res.json({ "result": response.data }).status(200);
});

Slack 앱 생성 및 웹훅 주소 가져오기

앱 생성

https://api.slack.com/apps에서 슬랙앱을 생성합니다.
GA4웹훅을 슬랙으로 받기 위해 GA4 Report 앱을 생성하였습니다.

슬랙 앱 생성

Incoming Webhook 주소 확인

생성된 앱을 클릭하면 아래와 같이 Incoming Webhooks 메뉴를 확인할 수 있습니다. 아래 Webhook URL에 있는 URL을 복사하여 GCP Cloud Functions post URL에 추가합니다.

Cloud Functions 웹훅 수신결과

Slack Incoming Webhook 수신결과

아래 그림과 같이 CREATING 상태에 대한 웹훅이 먼저 수신되고, 데이터처리가 완료된 후 ACTIVE 상태에 대한 웹훅이 추가로 수신된 것을 확인할 수 있습니다.

Reference

WebhookNotification

WebhookNotification | Data API | Google for Developers

이 페이지는 Cloud Translation API를 통해 번역되었습니다. WebhookNotification 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 리소스가 업데이트될 때 Google Analytics Da

developers.google.com

Data API - proeperties.audeinceLists

REST Resource: properties.audienceLists | Data API | Google for Developers

이 페이지는 Cloud Translation API를 통해 번역되었습니다. REST Resource: properties.audienceLists 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 리소스: AudienceList 잠재

developers.google.com

Axios module - POST requests

POST Requests | Axios Docs

POST Requests How to perform POST requests with Axios Performing a POST request JSON axios.post('/user', { firstName: 'Fred', lastName: 'Flintstone' }) .then(function (response) { console.log(response); }) .catch(function (error) { console.log(error); });

axios-http.com

슬랙 API: 앱 생성

Slack API: Applications | Slack

Your Apps Don't see an app you're looking for? Sign in to another workspace.

api.slack.com