Apache Flink란?

Flink는 일반적인 데이터 프로세서로 구축되었지만, 바인딩되지 않은 스트림을 기본적으로 지원하는 스트림 프로세서로 인기를 얻었습니다. Flink의 일반적인 사용 사례는 Apache Kafka의 사용 사례와 매우 유사하지만, Flink와 Apache Kafka는 용도가 약간 다릅니다. 일반적으로 Apache Kafka는 이벤트 스트리밍을 제공하고 Flink는 해당 스트림의 데이터를 처리하는 데 사용됩니다. Flink와 Apache Kafka는 일반적으로 다음과 같은 용도로 함께 사용됩니다.

• 일괄 처리: Flink는 바인딩된 데이터 집합을 처리하는 데 매우 탁월하기 때문에 데이터가 유한하고 청크로 처리되는 기존의 일괄 처리 작업에 적합합니다.

• 스트림 처리: Flink는 바인딩되지 않은 데이터 스트림을 처리하도록 설계되었습니다. 따라서 실시간으로 데이터를 지속적으로 처리할 수 있으므로 실시간 분석 및 모니터링이 필요한 애플리케이션에 적합합니다.

• 이벤트 기반 애플리케이션: Flink는 이벤트 스트림을 처리하는 기능 덕분에 사기 및 이상 징후 감지 시스템, 신용카드 거래 시스템, 비즈니스 프로세스 모니터링 등과 같은 이벤트 중심 애플리케이션을 구축하는 데 유용하게 활용되는 도구입니다. 

• 상태 유지 애플리케이션(세이브포인트) 업데이트: Flink의 상태 유지 처리 및 세이브포인트를 통해 상태 유지 애플리케이션을 업데이트하고 유지할 수 있습니다. 따라서 장애가 발생해도 일관성과 연속성이 보장됩니다.

• 스트리밍 애플리케이션: Flink는 간단한 실시간 데이터 처리부터 복잡한 이벤트 처리 및 패턴 감지에 이르기까지, 광범위한 스트리밍 애플리케이션을 지원합니다.

• 데이터 분석(배치, 스트리밍): Flink는 배치 데이터와 스트리밍 데이터를 모두 처리할 수 있어 데이터 분석에 적합합니다. 실시간 데이터 분석과 과거 데이터 처리가 여기에 포함됩니다.

• 데이터 파이프라인/ETL: Flink는 다양한 소스에서 데이터를 추출하고 변환한 후 추가 분석을 위해 데이터 웨어하우스나 기타 스토리지 시스템으로 로드하는 ETL 프로세스를 위한 데이터 파이프라인을 구축하는 데 사용됩니다.

Apache Flink의 단점

Apache Flink는 복잡한 아키텍처를 가지고 있습니다. 따라서 배우기가 쉽지 않을 수 있으며, 경험 많은 실무자조차도 이를 이해하여 사용하고 디버그하기 어려울 수 있습니다. Flink 개발자와 운영자는 커스텀 워터마크, 직렬화, 유형 진화 등과 관련된 복잡한 문제로 어려움을 겪는 경우가 많습니다.

대부분의 분산 시스템보다 좀 더 복잡할 수 있는 Flink는 하드웨어 선택 및 작업 특성을 고려하기 위한 성능 조정과 같은 배포 및 클러스터 작업에 어려움을 초래합니다. 일반적인 문제로는 역압, 느린 작업, 지나치게 큰 상태에서 세이브포인트 복원과 같은 성능 문제의 근본 원인에 대한 추론 등이 있습니다. 다른 일반적인 문제로는 체크포인트 실패 수정, 메모리 부족 오류와 같은 작업 실패 디버깅 등을 들 수 있습니다. 

Flink를 사용하는 조직은 전문가 팀을 꾸려 스트림 처리 작업을 개발하고 스트림 처리 프레임워크의 운영을 전담하게 하는 경향이 있습니다. 이러한 이유로, Flink는 복잡한 고급 스트림 처리가 필요한 대규모 조직에서만 경제적으로 실현할 수 있었습니다.

Flink와 Kafka, Spark 비교 및 각 제품에 적합한 환경

Apache Kafka Streams는 입력 및 출력 데이터가 Apache Kafka Cluster에 저장될 때 스트림 처리에 사용되는 인기 있는 클라이언트 라이브러리입니다. Apache Kafka의 일부이기 때문에 기본적으로 Kafka의 장점을 활용합니다.

ksqlDB는 Kafka Streams에 SQL의 간단함을 계층화하여 스트림 처리를 시작할 수 있는 좋은 기반을 제공하고 이를 넓혀 줍니다.

Apache Kafka 사용자와 Confluent 고객은 여러 가지 이유로 스트림 처리 요구 사항을 충족하기 위해 Apache Flink를 사용하는 경우가 많습니다. 예를 들어, 복잡한 스트림 처리는 종종 대규모 중간 상태를 의미하는데, 이 상태가 충분히 커지면 이 상태 자체가 Kafka Cluster를 운영하는 데 필요한 리소스와 계획에 영향을 미치기 때문에 Apache Kafka를 사용하는 것이 항상 합리적이라고 할 수는 없습니다. 또한 서로 다른 위치에 있는 여러 Kafka Cluster의 스트림을 처리해야 하거나, Kafka의 스트림과 Kafka 외부의 스트림을 처리해야 하는 등의 요구 사항이 있을 수 있습니다.

Flink는 고유한 복잡성과 운영 상의 뉘앙스를 가진 자체 분산 시스템이기 때문에 특히 Kafka Streams 또는 Apache Spark와 같은 다른 스트림 처리 기술을 사용할 수 있는 경우 Apache Flink로 작업할 때 발생하는 복잡성이나 관련 비용과 비교해 더 큰 이점을 얻을 수 있는지 여부가 명확하지 않았습니다.

Confluent를 통한 완전 관리형 Flink의 이점

하지만 클라우드는 이러한 우려를 뒤엎고 Apache Flink를 완전히 받아들일 수 있게 해줍니다. Apache Flink를 완전 관리형 클라우드 서비스로 제공함으로써 Confluent Cloud가 Kafka에 제공하는 이점을 Apache Flink에도 제공할 수 있습니다. 인스턴스 유형 또는 하드웨어 프로파일 선택, 노드 구성, 상태 백엔드 선택, 스냅샷, 세이브포인트 관리 등 Apache Flink를 복잡하고 비용이 많이 들게 하는 운영 상의 복잡성과 뉘앙스를 처리하므로 개발자는 Flink와 관련된 뉘앙스가 아닌 애플리케이션 논리에만 집중할 수 있습니다.

이렇게 하면 Flink의 기능을 Confluent Cloud에 제공할 뿐만 아니라 Flink가 스트림 처리에 적합할 때 경제성에도 변화가 생깁니다. 즉, 조직이 스트리밍 성숙도 초기에 있을 때 더 많은 사용 사례에 Flink를 사용할 수 있습니다. 또한 개발자가 적합한 스트림 처리 계층을 선택해 사용할 수 있으므로, 요구 사항이 변경되거나 복잡성이 증가해도 개발자가 하나의 플랫폼을 고수할 수 있습니다.

이제 Flink는 성숙하고 강력한 SQL 인터페이스를 갖추고 있으므로 스트림 처리를 도입하는 최종 사용자뿐만 아니라 Apache Flink를 도입하는 Confluent도 이 인터페이스에서 시작하는 것이 당연합니다.

자세히 알아보기 관리형 Kafka + Flink 사용해 보기