개요

- AWS Managed Flink에서는 사용자가 정의할 수 있는 설정이 제한적입니다.

- 사용자가 Parallelism 과 ParallelismPerKPU를 입력하면 이에 맞춰서 필요한 KPU가 계산되고

- 1 KPU 당 1 vCPU, 4GB메모리를 기준으로 AWS 에서 적당하게 컨테이너를 기동합니다.

내용

-  Flink는 TaskManager 와 slot을 기반으로 병렬처리를 제어하는데

- AWS Managed Flink는 KPU를 중심으로 제어하게 됩니다. (과금단위 이기 때문에)

- 이를 좀 더 자세히 살펴보고 원하는 세팅을 만들기 위해서 수치를 어떻게 제어해야 하는지 이해하는 것이 목적입니다.

Amazon MSF 리소스 구성 요소 간의 관계

I. KPU (Kinesis Processing Unit): 물리적 리소스 단위

실제 예시

- Parallelism 20, ParallelismPerKPU 1 = 총 20 KPU

1. 리소스 할당 (KPU 기준)

2. Task Manager 개수 및 Slot 할당 검증

A. 총 Task Slot 수

B. Task Manager당 슬롯 개수와 ParallelismPerKPU의 차이

AWS Managed Flink 네트워크 오류 원인 분석 및 튜닝 가이드

 
오늘은 AWS MSF(Managed Service for Apache Flink) 애플리케이션에서 발생한 오류(예: RemoteTransportException: Connection unexpectedly closed by remote task manager)의 원인과 해결 방안을 분석합니다.

애플리케이션 로그를 보면 10월 16일 오후 10시 21분 24초에 remote task manager error가 발생했고, 이후 partial recovery 후 다시 TaskManager 연결 오류가 반복되는 모습을 확인할 수 있었습니다.

이러한 로그는 TaskManager 간 통신이 불안정함을 나타내며, 주된 원인으로 메모리/리소스 부족, GC 지연, Heartbeat 타임아웃 등이 의심됩니다.

로그

원인 분석

• 메모리 부족 및 리소스 고갈: AWS MSF 문서에 따르면, TaskManager가 할당된 메모리를 초과하거나 CPU/메모리 과부하에 걸리면 TaskManager 프로세스가 비정상 종료되고, 이로 인해 RemoteTransportException이 발생할 수 있습니다 .
  • 예를 들어, KPU(Kinesis Processing Unit)당 메모리(4GiB, 이 중 3GiB는 힙 메모리)가 부족하면 OOM(OutOfMemory)으로 TaskManager가 죽을 수 있습니다  . 이 경우 Flink가 TaskManager 연결이 끊어졌다고 보고 오류를 출력합니다.
  • 현재 처리하고 있는 내부 Key 값 및 State의 용량이 크기 때문에 heapMemory사용량이 90%를 유지하고 있어서 원인 중 하나일 것으로 예상합니다.
• GC(Garbage Collection) 지연: 장시간 Full GC가 발생하면 TaskManager가 일정 시간 응답하지 못해 JobManager에 Heartbeat를 제때 보내지 못합니다. Flink 커뮤니티의 해결책에 따르면, 이러한 경우 TaskManager가 ‘unresponsive’ 상태로 간주되어 슬롯이 해제되고, 결국 연결이 끊어집니다.
  • 이를 방지하려면 G1GC와 같은 빠른 GC를 사용하거나 TaskManager 메모리 설정을 조정해 GC 시간을 단축해야 합니다 . 또한, 필요시 akka.watch.heartbeat.pause와 같이 Heartbeat 시간을 늘려 JobManager의 타임아웃을 늘리는 방안도 고려할 수 있습니다.
  • AWS MSF는 이미 G1GC 적용이 되어 있었습니다.
• Data Skew (데이터 불균형)
  • 특정 TaskManager 또는 Subtask에 비정상적으로 많은 데이터가 집중되어 처리 부하가 쏠릴 수 있습니다.
  • 이 현상은 다음과 같은 이유로 RemoteTransportException과 같은 네트워크 오류로 이어질 수 있습니다.
    • 특정 TaskManager만 메모리 과부하
      • 동일한 데이터 분포를 가정하고 병렬 처리를 수행하지만, 실제로는 일부 키(key)나 파티션에 데이터가 몰리면 해당 TaskManager만 힙 메모리가 1GB 이상까지 치솟습니다.
    • 백프레셔(Backpressure) 전파:
      • 특정 Subtask가 느려지면 상류(upstream)의 데이터 송신 속도가 제한되고, 네트워크 버퍼가 포화되어 Task 간 통신 오류나 Partial Recovery가 반복됩니다.
    • 네트워크 셔플 불균형:
      • Flink는 keyBy, rebalance, broadcast 연산 시 네트워크를 통해 데이터를 재분배합니다. 이때 데이터 스큐가 있으면 특정 TaskManager의 네트워크 I/O가 폭증하며, 네트워크 버퍼 부족과 연결 끊김이 함께 발생할 수 있습니다.
  • 내부적으로 각 이벤트를 시나리오와 매핑하는 처리를 하고 있는데 특정 시나리오의 이벤트가 많이 발생하고 있어서 역시 의심이 되는 부분입니다.
  • 시나리오 매핑이후는 개별Key를 통해서 keyBy연산으로 하고 있기 때문에 체이닝이 적절하게 동작하고 있습니다.
• 네트워크 버퍼 부족: 병렬처리가 높아지거나 연산자 체이닝이 해제되면 셔플(shuffle)이 증가해 네트워크 버퍼 소모가 커질 수 있습니다. AWS 문서에는 네트워크 버퍼가 부족해지면 Insufficient number of network buffers 오류가 발생할 수 있으며, 이를 해결하기 위해 parallelismPerKPU를 낮춰 TaskManager당 메모리(및 버퍼)를 늘리거나 연산자 체이닝을 활용할 것을 권장하고 있습니다 
  • 참고로 한 플로우에서 필요한 버퍼 개수는 (slots_per_TM)^2 * number_of_TMs * 4 공식으로 대략 산출할 수 있습니다.
  • 즉, TaskManager의 슬롯 수나 셔플 횟수가 많을수록 네트워크 버퍼가 대폭 늘어납니다.
• Heartbeat 타임아웃: Flink의 Heartbeat 설정이 너무 짧거나 네트워크 지연이 있으면 TaskManager와 JobManager 간 연결이 끊길 수 있습니다.
  • 이 경우 AWS MSF에서는 heartbeat.timeout 설정을 지원 티켓으로 늘릴 수 있으며 , 위에서 언급한 GC 지연 대응책(Heartbeat 지연 허용)도 도움이 됩니다.
• 기타 원인: TaskManager 노드의 일시적 네트워크 장애, 컨테이너 리소스 제한(예: CPU 쿼터 초과), 코드 레벨 메모리 누수 등도 원인이 될 수 있습니다.
  • TaskManager 로그에서 OOM 오류나 비정상 종료 메시지를 확인하고, 메모리 누수 가능성을 코드 리뷰로 점검해야 합니다.

해결 방안 및 튜닝 가이드

• KPU 및 병렬성 조정: KPU 리소스를 늘리거나 TaskManager당 할당되는 작업 수(ParallelismPerKPU)를 줄여 각 작업에 더 많은 메모리를 할당합니다.
  • AWS 문서에 따르면 하나의 KPU는 1 vCPU와 4GiB 메모리(힙 3GiB, 네이티브 1GiB), 50GiB 스토리지를 제공합니다 .
  • 예를 들어, ParallelismPerKPU=4(기본)인 경우 KPU당 4개의 슬롯에 약 1GiB씩 메모리가 분할되지만, ParallelismPerKPU=2로 낮추면 슬롯당 약 2GiB를 확보할 수 있습니다.
  • 전체 병렬도(Parallelism)가 고정되어 있다면 ParallelismPerKPU를 낮추면 필요한 KPU수가 증가하여 리소스가 더 할당됩니다 .
  • AWS도 PPK를 낮춰 메모리당 할당량을 높이는 방안을 제시하고 있으며, 이를 통해 메모리 부족으로 인한 OOM 재시작을 줄일 수 있습니다. (단, PPK를 낮추면 비용이 늘어나므로 병렬도를 적절히 조정하거나 오토스케일링을 활용해야 합니다.)
• Data Skew 완화
  • Key 균등화 전략 적용 (keyBy 연산 시 key 값의 불균형이 발생하는 경우)
    • 해시 기반 샘플링 후 파티션 재조정
    • “composite key” (예: userId_mod_10) 기반 가상 key 확장
    • rebalance() → map() 단계 삽입을 통해 균등 분배 가능 

• • Aggregation 단계 분리
    • 데이터가 한 TaskManager로 몰리는 경우, 1차 로컬 집계(Local aggregation) → 2차 글로벌 집계(Global aggregation) 구조로 바꾸면, 네트워크 트래픽 및 skew 부담을 크게 줄일 수 있음
  • Metrics 기반 모니터링 : 특정 TaskManager만 유독 높아서 key 분포 불균형 확인함
    • numRecordsIn, busyTimeMsPerSecond, heapMemoryUsed 메트릭을 TaskManager 단위로 비교하여 Skew 구간을 확인
• Operator 체이닝 활용 및 네트워크 최적화: 가능한 Operator들을 체이닝하여 별도 서브태스크로 분리될 필요가 없도록 합니다.
  • MSF 문서에 따르면 체이닝은 동일 서브태스크 내에서 연산자들을 묶어 실행함으로써 네트워크 호출을 줄이고 리소스를 절약합니다.
  • 반대로 체이닝을 해제하거나 인위적으로 새 체인을 시작하면 불필요한 셔플이 증가합니다. 실제 사례에서도 체이닝 해제가 네트워크 부담을 크게 늘려 오류 원인이 되므로, 가능하면 체이닝을 활성화할 것을 권장합니다.
  • 또한, 앞서 언급한 네트워크 버퍼 부족을 피하기 위해 플로우를 단순화하고 셔플 단계를 최소화하는 것도 중요합니다.
• I/O 바운드 워크로드 고려: 외부 서비스와의 블로킹 I/O가 많은 경우, 오히려 ParallelismPerKPU를 높여 KPU 리소스를 최대한 활용하는 것이 효율적일 수 있습니다 .
  • 즉, 네트워크 지연이 주요 병목이라면 병렬 슬롯을 늘려 I/O 대기 동안 더 많은 작업을 병렬 처리하도록 조정합니다.
  • 하지만 현재는 TaskManager 재시작 문제가 우려되므로, 우선은 안정적인 메모리 확보에 중점을 두고 PPK를 낮추었습니다.
• 모니터링 강화 및 추가 점검: CloudWatch의 주요 메트릭을 면밀히 모니터링합니다.
  • cpuUtilization, heapMemoryUtilization 등은 전체 리소스 사용률을 보여주며 문제 지표가 될 수 있습니다.
  • 또한 oldGenerationGCTime과 같은 GC 메트릭을 살펴보면 GC 지연 여부를 판단할 수 있습니다. 장애가 발생할 때는 CloudWatch Downtime, FullRestarts 값도 확인합니다.
  • TaskManager JVM 로그에서 GC 타임, 힙 사용량, OOM 에러를 찾아보고, 코드에 메모리 누수 가능성은 없는지 검토해야 합니다.
    • TaskManager 로그를 보고 싶으면 Flink구성에서 로그항목 [Application]으로 설정해야 합니다.
  • Heartbeat 타임아웃이 잦다면 heartbeat.timeout 설정을 AWS 지원 티켓으로 늘려보는 것도 고려할 수 있습니다 .
• 추가 적인 점검 사항
  • 일시적인 AWS 네트워크 장애 가능성도 염두에 두고, 다른 애플리케이션이나 Kinesis 스트림의 상태(예: 지연, 스로틀링)도 확인해 봅니다.
  • 코드 레벨에서는 대용량 데이터 처리 시 메모리 소비가 급증하지 않는지, Checkpointing 지연으로 백프레셔가 걸리지는 않는지도 함께 살펴봅니다.

결론

 
이번 오류는 단순한 네트워크 불안정이 아니라,

• TaskManager 메모리 부족
• Data Skew로 인한 특정 TaskManager 과부하
• GC 지연 및 Heartbeat 누락
• 복합적으로 작용한 결과입니다.

 
현재 발생한 오류를 해결하기 위해서는 메모리 확보, DataSkew 해소 및 네트워크 통신 부하 완화가 주요 내용입니다.

다음과 같은 액션을 수행했습니다.

1. ParallelismPerKPU 재조정
   1. TaskManager 슬롯 수를 줄여 각 슬롯이 더 많은 메모리를 갖도록 합니다.
   2. PPK를 4에서 2로 낮추어 슬롯당 메모리 할당량을 늘림 (1G -> 2G)
2. 전체 병렬도 검토
   1. PPK를 낮춘 뒤에 처리량이 부족하다면, 전체 병렬도(Parallelism) 자체를 늘려 필요한 KPU 수를 확장
3. Data Skew 해소
   1.  DataStream에서 .rebalance() 수행 후 이후 map() 하도록 파이프라인 수정
4. 비용 대비 효율 검토
   1. 리소스 조정으로 비용이 상승할 수 있으므로, 변경 전후의 KPU 사용량과 애플리케이션 처리율을 비교하여 최적점을 찾습니다
5. 모니터링 강화
   1. heapMemoryUtilization, oldGenerationGCTime, cpuUtilization, fullRestarts 등 주요 메트릭을 CloudWatch에서 계속 감시하고, 설정 변경 후 리소스 압박이 해소되었는지 검증이 필요 !!

 
이상으로 발생한 TaskManager 관련 오류 원인을 분석하고 해결 방안을 공유합니다.

다음 글에서는 AWS Managed Flink에서 KPU, Parallelim 의 관계와 TaskManager에 할당되는 관계를 알아보도록 하겠습니다.
https://icthuman.tistory.com/entry/%EC%8B%A4%EC%8B%9C%EA%B0%84-%EB%8D%B0%EC%9D%B4%ED%84%B0%EC%B2%98%EB%A6%AC-%EA%B5%AC%ED%98%84-4-Parallelism-ParallelismPerKPU

 
참고: AWS MSF 공식 문서 및 Flink 자료
- https://docs.aws.amazon.com/managed-flink/

- https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/deployment/memory/mem_setup_tm/

1.삶은 풀어야 할 숙제가 아니라 겪어봐야 할 신비다
문제는 당신 안에 있다
나만의 고유한 삶을 살자
의미와가치는 평판에 달려 있지 않다


2.배움을 멈추지 않는 한 우리는 계속 성장할 것이다
앎을 실천함으로써 삶을 바꾸자
바꿀수 없는것에 매이지 말고, 바꿀 수있는것에 살아라


3.인생은 빗속에서 춤추는 법을 배우는 것
해결할 수 있는 일은 근심할 필요가 없다
해결할 수 없는 일 또한 근심할 필요가 없다.

반드시라는 마음을 내려놓고
물 흐르듯이

욕망, 두려움 을 초월한다면 자유롭다

[어떻게 어른이 되는가]-엄성우 지음 

1. 겸손이란 무엇일까.

신이 아니기에 모든면에서 완벽하지 않고,

그런 불완정성을 스스로 인지할 수 있기에 다른 동물과 구분이 된다.

자신의 가치와 남의 가치를 비교하지 않는 것으로 출발

2. 왜 겸손해야 할까.

남을 불쾌하게 하지 않고 자신도 미움받지 않는다.

자기평가에 연연하지 않고 진정으로 중요한 것을 추구한다.

귀한 배움을 얻기 위해서는 남의 잘난척 정도는 가볍게 받아줄수도 있는 여유로운 태도가 필요할수도 있다. (이것도 겸손)

겸손만큼 쉽고 안전한 덕목이 없다.

3. 겸손은 예의나 친절함과 어떻게 다를까

예의 바름은 대부분 겉으로 드러나는 것.

겸손은 친절과는 다르다. 친절하게 태도를 가질수는 있으나

겸손은 결국 스스로를 어떻게 여기는가에 내면에서 나오는 소리에 달려있음

내적겸손을 갖추어야 외적겸손이 자연스럽게 발현된다.

4. 겸손한 사람은 자신에 대해 잘 알까?

자신의 탁월함을 알고도 겸손할 수 있는가.

내가 뛰어나다고 해서 내가 남보다 가치가 있는 것은 아니다. 탁월성을 안다고 겸손하지 못한것은 아님.

오히려 자신이 가진 힘과 영향력을 제대로 알지 못해서 생기는 문제도 있다. (가진자의 횡포, 상처주는 막말)

자신이 가진 탁월함을 제대로 알아야 적절히 활용하며 그에 걸맞는 행동을 할 수 있다.

"너 자신을 알라"

"내가 모른다는 사실이라도 알면 지혜로울 수 있다"

5. 겸손한 사람은 스스로를 어떻게 의식할까?

지나치게 자신을 의식하면 겸손하지 못할 수 있다.

"겸손이란 자신을 하찮게 생각하는 것이 아니라 자신에 대해 너무 많은 생각을 하지 않는 것이다" - C.S. 루이스

자신의 가치를 알맞게 가늠하는 사람은 꼭 필요한 경우가 아니면 자신을 화제의 중심에 두지 않는다.

"우리는 우리에 대해 무슨 이야기를 하는지보다 우리에 대한 이야기 자체에 더 신경을 쓰고,

우리를 어떻게 부르는지와 상관없이 사람들 입에 오르내린다는 사실로 만족스러워 한다. " - 몽테뉴

쓸데없는 것에 기뻐하는 사람들

우리는 자신의 것이 아닌 것에 대해서 과시하지 않아야 한다.

6. 감사와 겸손, 겸손과 자기비하, 겸손과 오만

보통 겸손한 사람은 감사를  잘한다. 하지만 감사할 줄은 알지만 겸손하지 못한 사람도 있다. 

진짜 겸손한 사람은 자신을 중심에 두려는 성향이 적어서, 남을 돕거나 진리를 추구하는 등

인생의 중요하고 가치있는 일을 실천해 나가는 사람.

---------

겸손과 자기비하는 마치 비슷해보이지만 다르다.

자신을 스스로 깎아 내리려는 성향이 선의,용기 등 다른 덕목을 발휘하는데 방해가 되는를 기준으로 본다면

자기비하는 그 부정적인 태도로 자신과 그 주위에 악영향을 미친다.

예를 들어서 상을 받거나 축하를 받을때 스스로 깎아내린다면, 혹은 자신이 받은 상의 가치를 깎아 내린다면

그 상을 준사람, 받은 또 다른 사람, 또 그 상을 받지 못한사람과 그 상을 받도록 도와준 모든 사람에게 실례

겸손은 자신을 낮추는 태도가 아닙니다. 자신에게 엄격한 것도 아니며,

자신을 깎아 내린다는 것은 결국 자신과 비슷한 위치에 있는 사람도 깎아내리는 것이 되기 때문이다.

자신을 드러내는 행동이 반드시 오만한 것은 아니다.

자랑에도 이유가 있다면 겸손에 어긋나지 않으며

결국 겸손은 자기비하와 오만 사이의 중용이다.

"덕 이란 모자람과 지나침의 양 극단 사이의 중용" - 아리스토텔레스

** 자존감의 크기가 아니라 자존감의 근거에 달려있다.

겸손하지 못한 사람은 Better에 중점을 두고,

겸손한 사람은 Good에 중점을 둔다. 즉, 가치있고 의미있는 것을 추구하고 실현함으로써 높아진 자존감을 얻게 되는 것

Flink State vs 외부 저장소를 활용한 값 관리: 어떤 선택이 더 합리적일까?

개요

실시간 데이터 처리 파이프라인에서 흔히 등장하는 과제 중 하나는 “사용자 피로도, Aggregation등” 값 관리입니다.
예를 들어, 마케팅 알림이나 이벤트 푸시 발송 시스템에서 동일 사용자에게 너무 많은 알림이 전달되지 않도록 시간/횟수 기반 제약을 두어야 할 필요도 있고, 일정 시간내의 이벤트 Aggregation등의 처리가 필요한 경우도 있습니다.
 
이를 구현하는 방법은 크게 두 가지로 나눌 수 있습니다.

1. Flink State를 통한 관리
2. Redis 등 외부 저장소를 통한 관리

 실제 운영 환경에서 이 두 가지 접근법을 모두 검토했으며, 각 방식의 장단점과 보완 방법을 정리해 보았습니다.
 

Flink State 기반 관리

동작 방식

• Flink의 KeyedProcessFunction 또는 RichFlatMapFunction에서 ValueState, ListState, MapState 등을 활용.
• 사용자별 키(userId)로 state를 유지하고, 이벤트 처리 시 조건을 체크.
• checkpoint/restore 메커니즘을 통해 exactly-once 보장 가능.

장점

• 일관성 보장: Flink state는 checkpoint와 함께 관리되어 장애 상황에서도 데이터 유실 최소화.
• 처리 성능 최적화: 외부 호출 없이 JVM 내부 메모리/로컬 RocksDB로 state 접근 → 지연(latency) 최소화.
• 운영 단순화: 외부 저장소 장애와 무관하게 파이프라인 내에서 관리 가능.

단점

• 확장성 한계: State 크기가 커질수록 checkpoint 부하가 증가.
• 비즈니스 연계성 부족: 파이프라인 외부 서비스(예: CRM, 백오피스)에서 동일 피로도 정책 확인 어려움.
• 운영 가시성 부족: state는 Flink 내부에 있어 모니터링/조회가 불편.
• 복원 불안정 : Operator나 내부 Class등의 변경이 생길경우 복원이 정상적으로 되지 않음

보완 방법

• TTL(State Time-to-Live)을 활용해 불필요한 state 자동 정리.
• State backend(RocksDB) 튜닝으로 대규모 데이터 관리 가능.
• 필요 시 side-output 등으로 state snapshot을 외부 DB로 export하여 조회용 데이터 구축.

외부 저장소(Redis 등) 기반 관리

동작 방식

• 이벤트 처리 시 Redis에 사용자별 카운터 / 타임스탬프를 저장.
• 피로도 체크 시 Redis 조회 → 조건 충족 시 이벤트 처리, 아니면 drop.
• Redis의 INCR, EXPIRE 등을 활용하여 TTL 기반 제어 가능.

장점

• 외부 접근성 우수: CRM, 백오피스, API 등 다양한 외부 시스템에서 즉시 참조 가능.
• 운영 유연성: Redis 데이터만 보면 전체 상태 확인 가능.  (Prefix 를 이용, 전체 Keys는 운영중 절대 안됨!)
• 확장성: Redis Cluster 등으로 수평 확장 가능.
• 안정성 : Flink App의 재부팅 / 결함으로부터 자유로움

단점

• 일관성 취약: Flink 처리 중 실패/재처리 시 Redis 값이 중복 증가할 수 있음.
• 성능 부담: 외부 I/O 호출로 인해 latency 증가 가능.
• 운영 복잡성: Redis 장애 시 파이프라인도 영향 받을 수 있음.

보완 방법

• 원자적 연산(GET+INCR) 사용 및 Lua Script 기반 트랜잭션 처리.
• 배치 보정 파이프라인: 하루/주 단위로 Redis 카운트를 원천 이벤트 로그와 맞추어 정합성 보정.
• 모니터링/알림 : Redis Replica/Cluster 구성을 통한 가용성 확보

보관하는 값의 종류에 따른 차이점

운영 중 겪었던 문제

처음에는 모든  데이터를 Flink state로 관리하려 했습니다.
하지만 장애 복구 시 state 복원 크기가 커지면서 문제가 발생했습니다.

• 복원 사례: 수십 GB 단위 state를 가진 잡이 재시작될 때→ 그동안 KPU(Flink 작업 슬롯)를 넉넉하게 늘려야만 안정적인 복구 가능
• → 운영 비용과 복잡성이 증가
• → Checkpoint restore 시간이 수십 분 이상 소요

이 경험을 통해 모든 값을 state에 넣는 건 정답이 아님을 깨달았습니다.
 

State로 관리하면 좋은 값들

State는 Flink의 강력한 무기입니다. 특히 **“스트림 내에서 바로 계산되는 값”**에는 최적화되어 있습니다.

• 누적 값 (counters): 예) 특정 키(userId)의 이벤트 누적 개수
• 평균/합/통계치 (aggregation): 예) 지난 5분간 클릭률 평균
• 세션/윈도우 기반 임시 상태: 예) 10분 세션 동안 발생한 이벤트 패턴
• 비교적 작은 사이즈의 데이터: 예) 단일 사용자 최근 5개 이벤트 저장

➡️ 이런 값들은 Flink checkpoint/restore와 exactly-once 보장이 잘 맞아떨어집니다.
 

외부 저장소로 관리하면 좋은 값들

반면, **“외부에서 참조가 필요하거나, 중복 증가가 치명적이지 않은 값”**은 Redis 같은 외부 저장소가 더 적합합니다.

• Fatigue (발송 제약):→ CRM/운영툴에서 실시간 확인 가능
  • 중복으로 값이 과증가해도 보수적으로 동작 (안 보내는 쪽으로 기울어 안전)
• 장기 보존이 필요한 값:→ Redis/DB에 두면 조회와 보정(batch pipeline) 용이
  • Flink state에 두면 checkpoint 부하 ↑
• 운영 가시성이 중요한 값:
  • 운영자가 즉시 확인하고 조정해야 하는 데이터 (예: 사용자별 발송 제한 카운터)

➡️ 이런 값들은 Flink state보다 외부 저장소 + 보정 파이프라인이 더 안정적입니다
 

결론 및 선택 가이드

• Flink State 중심 전략: 성능과 일관성이 가장 중요할 때 선택.
  • 알림 피로도 관리가 파이프라인 내부 로직에 국한되고, 외부에서 별도 조회 필요성이 적을 경우 적합.
• Redis 중심 전략: 운영 가시성, 보수적 동작, 외부 연계성
  • 단, 재처리/중복 처리 리스크를 줄이기 위한 보완책이 필수.

맺음말

결국, fatigue 관리의 초점이 “실시간 정확성”인지 “운영 편의성”인지에 따라 선택지가 달라집니다.
저의 고민과 정리를 바탕으로, 비슷한 고민을 하고 계신 분들께 도움이 되길 바랍니다.

AWS Managed Flink + Kinesis DataStream 실시간 데이터 처리 시스템 개요

1. 개요

최근 데이터 처리 환경은 “실시간”이라는 키워드가 핵심입니다.

대용량 이벤트 스트림을 빠르게 수집하고, 실시간으로 분석·가공한 뒤 다양한 시스템에 전달해야 하는 요구가 있어서

AWS에서 제공되고 있는 Amazon Kinesis DataStream와 **Amazon Managed Service for Apache Flink(이하 Managed Flink)**를 활용해봤습니다.

이번 글에서는 이 두 서비스를 활용해 실시간 데이터 파이프라인을 구축하는 기본 개념과 설계 포인트를 정리해봅니다.

2. 서비스 개요

2.1 Amazon Kinesis

Kinesis는 AWS의 완전관리형 스트리밍 데이터 서비스입니다. (Kafka 와 유사하다고 생각하시면 됩니다.)

이 중 **Kinesis Data Streams(KDS)**를 사용하면 초당 수백 MB~GB급 이벤트를 안정적으로 수집·버퍼링할 수 있습니다.

특징

• 샤드(Shard) 단위로 처리량 확장 가능 -> 파티션 과 유사
• 순서 보장 및 재처리 지원
• 초당 수천 TPS 가능
• SDK, Firehose, CLI 등 다양한 연동 방식

2.2 Amazon Managed Flink

Apache Flink를 완전관리형으로 제공하는 서비스입니다.

Managed Flink를 사용하면 클러스터 관리나 배포 인프라 고민 없이, Flink 애플리케이션 개발에 집중할 수 있습니다.

단, 기본 Flink와 다르게 조정할 수 없는 Configuration 들이 있으니 공식문서를 참조해야 합니다.

특징

• Flink 버전 업그레이드 및 인프라 관리 자동화
• Kinesis, S3, DynamoDB 등 AWS 서비스와 Native 연동
• Checkpoint/Savepoint를 통한 상태(State) 복구 지원
• Scaling 자동화(Parallelism 조정)

3. 시스템 아키텍처 개요

1. Producer: 실시간 Event 수집 Platform
2. Kinesis Data Streams: 실시간 데이터 Queue
3. Managed Flink: 실시간 데이터 처리(Enrichment, Filtering, Aggregation)
4. Sink: 결과 저장(S3)

4. 구현 시 주요 고려사항

4.1 데이터 모델 & 직렬화

• Flink와 Kinesis 간 전송 데이터는 기본사용은 kryo사용(reflect방식)으로 성능이 떨어지기 때문에 추후 스키마 진화를 생각하면 Avro, Protobuf 등 직렬화 포맷 선택하는것이 유리하다.

4.2 상태 관리(State Management)

• Flink는 Keyed State와 Operator State를 제공
• 상태 크기가 커질수록 Checkpoint 주기와 저장소 성능이 중요하다.
• AWS에서는 기본적으로 S3에 Checkpoint/Savepoint 저장하며 사용자는 접근이 불가능하다.

4.3 Checkpoint / Savepoint 전략

• Checkpoint: 장애 시 자동 복구
• Savepoint: 버전 배포·롤백 시 수동 복구
• 체크포인트 주기는 1분~5분 권장, 처리량과 지연 시간에 따라 조정

4.4 Source/Sink Connector

• Source: KinesisStreamsSource 또는 Flink Kinesis Connector
• Sink: S3 로 기본사용

4.5 확장성(Scaling)

• Kinesis는 샤드 수로 확장
• Flink는 parallelism 조정 
• 병목 지점(Shard → Flink 병렬도) 일치 여부 체크 필요
• Parallelism과 KPU가 자동으로 계산되는데  4.2의 상태관리와 연관되어 재기동시 backpressure , 지연이 발생하지 않도록 처리시간 + 복원시간을 고려해야 한다.

5. 운영 팁

1. CloudWatch + Managed Flink Metrics로 레이턴시, 백프레셔(backpressure) 모니터링
2. Kinesis 샤드 모니터링 → 샤드 split/merge 자동화 스크립트 준비
3. Flink 애플리케이션 버전 관리 → Git + CI/CD (CodePipeline, CodeBuild) 연동 , Flink재기동은 자동보다는 수동을 추천
4. Data retention: Kinesis는 최대 7일, 그 이상은 S3에 Raw Data 저장
5. 배포 전 로컬 환경에서 Flink MiniCluster로 테스트
6. Flink 내 ProecssFunction에 대해서는 Harness를 이용해서 최대한 Test Code를 작성해둔다.

6. 간단한 예제 플로우

• Source: Kinesis에서 JSON 데이터 읽기
• KeyBy: UserId 단위 처리
• ProcessFunction: 룰 매핑, 데이터 보강
• Sink: S3 저장

DataStream<Event> source = env
    .fromSource(kinesisSource, WatermarkStrategy.noWatermarks(), "Kinesis Source")
    .map(json -> parseJson(json));

source
    .keyBy(Event::getUserId)
    .process(new CustomEnrichmentFunction())
    .addSink(s3Sink);

7.  결론

AWS Managed Flink + Kinesis 조합은 실시간 데이터 분석 파이프라인을 빠르고 안정적으로 구축할 수 있는 강력한 도구입니다.

인프라 운영 부담을 줄이고, 비즈니스 로직에 집중할 수 있다는 점이 가장 큰 장점입니다.

다만, 체크포인트 전략, 상태 크기 관리, Kinesis 샤드 수 조정 등 운영 노하우가 중요하니, 충분히 검증 / 모니터링을 후 본격 도입하는 것을 추천드립니다.

OAuth 2.0 Resource Server에서 JWT 토큰을 검증하고 권한을 처리하는 방법에 대해 알아보겠습니다. Spring Security를 사용하여 Resource Server를 구성하고, JWT 토큰의 scope와 roles 클레임을 권한으로 변환하는 과정을 살펴볼 것입니다. 또한, 자주 발생하는 SSL 관련 오류와 그 해결 방법에 대해서도 다룰 예정입니다.

OAuth2 Authorization Server Setup

개요

AWS RDS와 DynamoDB의 비용 및 성능 비교는 데이터베이스 선택 시 중요한 고려사항입니다. 이 분석에서는 두 서비스의 비용 구조, 성능 특성, 그리고 대규모 쓰기 작업 시나리오에서의 비용 효율성을 살펴보았습니다. 또한 고가용성을 위한 중복 구성 시의 비용과 Spring Boot와의 연동 방법에 대해서도 논의하였습니다.