본문 바로가기

AWS19

[AWS] API Gateway와 Lambda 연동 시 제어권 문제 트러블 슈팅 (프록시 통합) MSA(Microservice Architecture)로 아키텍처를 전환하는 과정에서, 기존 서비스 일부를 AWS Lambda 기반의 서버리스 API로 마이그레이션하는 작업을 진행 중이었다. API Gateway와 Lambda를 연동하는 초기 테스트 단계에서, 논리적으로 모순되는 현상을 발견했다.1. 현상 분석API Gateway 엔드포인트(예: /v0/location?q=검색어)로 쿼리 파라미터를 포함하여 정상적인 GET 요청을 보냈음에도, API Gateway는 "400 Bad Request"를 반환했다.반환된 응답 body는 두 가지 명백한 문제를 동시에 보여주었다.문제 1: 400 에러 - "쿼리 파라미터 누락"Lambda 코드는 event.queryStringParameters.q에서 검색어를 .. 2025. 11. 16.
[AWS Athena] S3 Parquet 파티션 빅데이터 쿼리 엔진 설정 (테이블/파티션 인식 불가 트러블 슈팅) 1. 개요: 전체 파이프라인 흐름과 현재 위치이 아키텍처는 공공데이터 API의 대용량 데이터를 '최소 비용'으로 분석하는 것을 목표로 한다. 이 목표를 달성하기 위해 데이터는 다음과 같은 파이프라인을 거친다.[API → Lambda] : OutOfMemory 문제를 피하기 위해 Lambda가 API를 스트리밍으로 호출한다.[Lambda → S3 RAW] : Lambda는 데이터를 메모리에 쌓아두지 않고, part_N.json 형태의 작은 파일로 분할하여 S3 RAW 버킷에 즉시 적재한다.[S3 RAW → Glue] : Glue (PySpark) Job이 S3 RAW의 분할 JSON '폴더'를 통째로 읽어 9가지 전처리 로직을 적용한다.[Glue → S3 Processed] : Glue는 처리된 데이터를 .. 2025. 11. 9.
[AWS Glue] PySpark: 스트리밍된 분할 JSON을 Parquet +Partitioning기법을 이용해서 칼럼 기반 데이터로 전처리로 전환 개요공공데이터포털 API를 호출하여 대용량 데이터를 S3 RAW 영역에 적재하고, AWS Glue를 통해 ETL 작업을 수행하는 배치 파이프라인을 구축 중이었다.이전 단계(Lambda 스트리밍)로 인해 S3 RAW 버킷에 데이터가 '단일 JSON 파일'이 아닌, part_N.json 형태의 '분할된 파일 폴더'로 적재되기 시작했다. 이로 인해 기존의 '단일 파일'을 읽도록 설계된 AWS Glue Job이 더 이상 작동하지 않게 되었다.이 글은 이 Glue (PySpark) 스크립트를 수정하는 과정을 다룬다. '폴더' 입력을 처리하고, '동적 JSON 키'를 파싱하며, 나아가 Athena 쿼리 비용 최적화를 위해 Parquet과 파티셔닝(Partitioning)을 적용한 개념과 과정을 설명한다.1. 단일 .. 2025. 11. 9.
[AWS Lambda] 빅데이터 배치 처리 파이프라인 구축 도중 Runtime.OutOfMemory 발생하여 Streaming + Chunk 기법 적용 1. 개요공공데이터포털 API를 호출하여 대용량 데이터를 S3 RAW 영역에 적재하고, AWS Glue를 통해 ETL 작업을 수행하는 배치 파이프라인을 구축 중이었다.배치 작업(Batch Job)은 AWS Lambda를 사용했다. 핵심 요구사항은 '최소 비용'이었기 때문에, Lambda의 메모리를 512MB와 같이 낮게 제한하며 테스트를 진행했다. 이 과정에서 두 가지 주요 문제를 만났고, 이를 해결하며 페이지네이션(Pagination), 스트리밍(Streaming), 그리고 S3의 고수준/저수준 API 차이에 대해 명확히 알게 되었다.2. 문제 1: Runtime.OutOfMemory (메모리 초과)초기 코드는 API가 제공하는 페이지네이션(Pagination)을 활용했다. while 반복문으로 1,0.. 2025. 11. 9.
[AWS] 서버리스 솔루션 아키텍처(SA) 적용 과정과 EDA, MSA (마이크로서비스, 이벤트 기반 아키텍처) 1단계: 고전적인 서버리스 REST API 구축모바일 애플리케이션을 위한 서버리스 백엔드를 구축하는 첫 번째 단계이다.요구 사항HTTPS 엔드포인트를 가진 REST API서버리스 아키텍처사용자 인증데이터베이스는 스케일링이 가능하고 읽기(Read) 비중이 매우 높음v1.0: 기본 API 백엔드 구축가장 고전적인 서버리스 API 패턴으로 시작한다.Client (Mobile): 사용자의 모바일 기기이다.Amazon API Gateway: HTTPS 요청을 받는 REST API 엔드포인트 역할을 한다. 모든 API의 '관문'이다.AWS Lambda: API Gateway를 통해 호출되며, 실제 비즈니스 로직(데이터 저장, 조회)을 수행한다.Amazon DynamoDB: 서버리스 NoSQL 데이터베이스이다. La.. 2025. 11. 4.
[AWS] DynamoDB, API Gateway, Cognito - 서버리스 주요 솔루션 개념과 사용법 Amazon DynamoDBDynamoDB는 AWS에서 제공하는 완전 관리형, 고가용성 NoSQL 데이터베이스이다.멀티 AZ 복제를 통해 장애, 확장성 문제에 강하며, 트랜잭션도 지원하는 비관계형 DB이다.초당 수백만 요청, 수조 개 행, 수백 테라바이트까지 확장될 수 있다.단일 밀리초 수준의 빠르고 일관된 성능을 제공한다.다양한 IAM 인증과 권한 관리가 적용된다.낮은 비용/오토스케일링, 무중단 운영이 가능하며, Standard 및 Infrequent Access(IA) 테이블 클래스도 지원된다.NoSQL의 주요 특징비관계형 데이터베이스(Non-relational):RDBMS와 달리 테이블 간 Join/외래키 제약이 없다.각 데이터 단위(Item)는 키-값, 문서, 그래프, 컬럼 패밀리 등 다양한 데이.. 2025. 11. 3.
[AWS] 람다(lambda)를 이용한 서버리스 컴퓨팅 개념과 사용법 Serverless란?Serverless란 개발자가 더 이상 서버를 직접 운영하거나 관리하지 않아도 되는 새로운 패러다임이다.개발자는 단지 코드를 배포(주로 함수 단위 배포)하기만 하면 된다.초기에는 AWS Lambda가 대표적이었으며, FaaS(Function as a Service)라고도 불렸다.지금은 데이터베이스, 메시징, 스토리지 등 모든 Managed 서비스(Aurora Serverless, DynamoDB, SQS, S3 등)까지 확장되어 있다.Serverless라는 명칭이 '서버가 없다'는 뜻이 아니라, 서버를 직접 관리/프로비저닝/모니터링할 필요가 없다는 의미이다.AWS에서의 Serverless 서비스아래 서비스들이 Serverless 모델에 포함된다.AWS LambdaDynamoDBAWS.. 2025. 11. 2.

티스토리툴바