비정상 사용자를 모니터링하고 대응하기 위해 만든 이상 로그인 감지 시스템과 기반 기술인 카프카 스트림즈(Kafka Streams) 도입기를 소개합니다.안녕하세요. 무신사 회원개발팀 백엔드 엔지니어 채희원입니다.  회원개발팀은 무신사에서 회원가입 등 회원과 관련된 도메인을 맡고 있으며 메시지, 후기, 적립금의 도메인을 담당하는 팀입니다.이 글에서는 비정상 사용자를 모니터링하고 대응하기 위해 만든 이상 로그인 감지 시스템과 기반 기술인 카프카 스트림즈(Kafka Streams) 도입기를 소개하겠습니다.[그림 1] 이상 감지 로그인을 표현도입 배경무신사는 가파른 성장을 이룩하고 있으며 매년 사용자 수가 크게 증가하고 있습니다. 이에 따라 어뷰징, 매크로, 해킹 시도와 같이 비정상적인 사용자도 꾸준히 늘어나고 있습니다.[그림 2] 무신사 성장 그래프이러한 비정상 사용자를 확인하기 위한 방법으로는 WAF를 통한 트래픽 확인, 주문 정보 확인, VoC(Voice of Customer) 접수 등이 있습니다. 이런 확인 방법은 이슈가 발생한 후에야 파악할 수 있다는 문제점이 있습니다. 이에 이슈 발생 전 비정상 사용자를 모니터링하고 조치하여 피해를 막을 필요성이 대두되었습니다.사용자는 로그인 시도 시 많은 정보를 남깁니다. IP, ID, Referrer 등의 정보 패턴을 분석한다면 로그인 단계에서 비정상적인 접속을 파악할 수 있으리라 생각했습니다. 이를 위해 실시간 모니터링과 선제적인 조치가 가능한 이상 로그인 감지 시스템을 도입하였습니다.기술 선택이상 로그인 감지 시스템을 개발하기 위한 기술 선택 과정과 결론에 대해 설명드리겠습니다. 요구 사항 확인이상 로그인을 감지하기 위해서는 실시간으로 들어오는 로그인 정보를 활용하여 데이터를 집계하고 분석해야 했습니다. 그러면서도 적은 학습 비용의 기술을 활용하면서 서드파티 인프라를 추가하지 않고 문제를 해결해야 했습니다. 활용 데이터 분석[그림 3] 로그인 이력 정보 데이터의 흐름분석 대상인 로그인 이력 정보는 로그인 처리 후 Kafka를 통해 이벤트를 발행, 후처리로 RDB에 저장하는 프로세스를 가지고 있습니다.로그인 이력 정보를 실시간으로 집계하기 위해서는 초당 수백 건으로 들어오는 데이터와 연관 있는 특정 기간의 데이터들을 집계하여 패턴을 분석해야 했습니다.[그림 4] Batch를 이용한 모델우선적으로 떠오른 것은 RDB를 조회하는 배치를 개발하는 모델이었습니다. 하지만 RDB에 직접 조회하고 집계하는 방식은 부하와 실시간 처리의 보장이 어려워 제외되었습니다. 따라서 Kafka 메시지를 활용하여 데이터를 처리하기로 결정했습니다. 기술 후보 비교Kafka 메시지를 이용하여 집계를 위한 기술 후보로는 Flink, Spark, Kafka Streams, KsqlDB이 후보로 거론되었습니다.1) Apache Spark분산 처리를 위한 오픈 소스 클러스터 컴퓨팅 프레임워크. 대규모 데이터 처리, 데이터 집계, 머신 러닝 등 다양한 작업을 지원.장점   메모리 내에서 데이터 처리를 수행하여 빠른 속도를 제공.   SQL 쿼리, 스트리밍 처리, 머신 러닝 등 다양한 기능을 제공.   사용자가 데이터를 탐색하고 실험할 수 있는 대화형 쉘을 제공.단점   대규모 데이터셋을 처리할 때 메모리 사용량이 높다.   마이크로 배치 방식을 사용으로 인한 지연이 발생.2) Apache Flink스트리밍 및 배치 처리를 위한 분산 데이터 처리 엔진.실시간 이벤트 스트리밍과 배치 프로세싱을 모두 지원.장점   스트림 처리에 초점을 맞춰 실시간 처리 및 일괄 배치를 제공.   이벤트 시간 기반의 처리를 지원하여 데이터의 지연과 순서를 관리.   최적화된 실행 계획을 생성하여 성능을 향상.   내부 상태 관리를 통해 정확한 결과를 보장.단점   러닝 커브가 높다.   메모리 요구량이 많아 대규모 클러스터가 필요.3) Kafka StreamsKafka 클러스터에서 데이터를 처리하고 분석하기 위한 클라이언트 라이브러리이다. 애플리케이션에서 데이터를 읽고 쓸 수 있으며, 스트림 처리를 위한 고수준 API를 제공.장점   Kafka cluster와 함께 확장되므로 처리량을 쉽게 조정 가능.    Kafka cluster와 연동되어 데이터 손실 없이 안정적 내결함성 제공.   Java 라이브러리로 구현.   Exactly-once를 보장.단점   일부 복잡한 처리 작업에는 기능이 제한적.   Kafka 컨슈머 그룹을 사용하여 데이터를 처리. 따라서 컨슈머 그룹의 부하나 지연이 Kafka Streams 애플리케이션의 처리 속도에 영향.4) KsqlDBKafka 스트림 처리를 위한 오픈 소스 SQL 엔진.SQL 스타일의 문법을 사용하여 Kafka topic에서 stream을 query하고 처리 가능.장점   코드 작성 없이 SQL query로 데이터 처리가 가능한 높은 생상성 제공.   스트림 데이터를 실시간으로 처리할 수 있어 실시간 분석에 적합.   외부 시스템과의 데이터 통합을 위해 내장된 Kafka Connect를 지원.단점   세밀한 기능 구현이 어려워 복잡한 작업에는 적합하지 않음.   스트림 처리를 위해 Kafka 클러스터와 함께 동작하므로 클러스터의 스케일링 제한에 따라 성능이 제약.여러 논의를 거친 결과, 최종적으로 아래와 같은 이유로 Kafka Streams를 사용하기로 결정하였습니다.1. 서드파티를 추가 사용하지 않음.2. Java 라이브러리를 사용.3. 복잡한 기능을 구현할 수 있음.4. 멀티 모듈 환경에서 별도의 독립된 서비스로 관리 가능함.Kafka Streams란[그림 5] Kafka Streams와 Kafka Broker간의 데이터 흐름Kafka Streams는 Kafka에서 공식적으로 지원하는 라이브러리입니다. Broker에 적재되는 메시지를 실시간으로 더 빠르고 안전하게 처리할 수 있도록 기능을 제공합니다. 또한 Topic으로 들어오는 데이터를 소비(consuming)하여 Kafka Streams에서 제공하는 처리 로직을 적용하여 집계하거나 재가공 후 다른 Topic으로 발행하거나 Kafka Connect를 이용하여 DB에 적재하는 등의 스트림 처리

소프트웨어 엔지니어들은 수많은 추상화 속에서 살아갑니다. 하위 레벨에서 제공하는 추상화는 공기처럼 당연한 것으로 여겨지고, 그 위에 무엇을 어떻게 쌓아 올릴지 고민하는 게 소프트웨어 엔지니어링이라 할 수 있습니다. 오늘은 이렇게 당연하게 여겼던 추상화를 하나하나 파고들어간 이야기를 소개해 볼까 합니다. 수십 명의 개발자들이 만들었던 게임. 36시간 장애 속에서 수백만 명이 서비스 오픈만을 기다리고 있고, DB를 만든 회사에서 복구는 불가능하다고 얘기하는 극한의 상황 속에서 CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기를 소개합니다.이야기를 시작하기에 앞서 해커 문화(Hacker Culture)를 알고 갑시다. 대중적으로 ‘해킹’이라는 단어는 시스템을 불법적으로 침입하는 행위로 알려져 있습니다. 원래 ‘해킹’의 개념은 MIT에서 시작되었는데, 소프트웨어 시스템이나 하드웨어의 제약사항을 창조적으로 함께 극복해 내는 행위를 뜻합니다. 문제를 해결하거나 시스템의 한계를 극복하기 위해 시스템의 밑바닥까지 파고들고, 그 시스템에 대한 완벽한 이해를 추구합니다. 이러한 해커 문화를 이끌어간 리더들로는 GNU 창시자 RMS, C 언어를 개발한 Dennis Ritchie, Go 언어를 개발한 Ken Thompson, 리눅스를 개발한 Linus Torvalds 등이 있습니다. 보시면 아시겠지만 해커 문화와 오픈소스와는 밀접한 연관이 있습니다.데브시스터즈의 엔지니어링 조직은 뛰어난 엔지니어링을 지향함과 동시에 해커 문화와 오픈소스를 좋아합니다. 사용하는 오픈소스 제품의 코드 레벨까지 뛰어드는 걸 주저하지 않습니다. 여기서 소개되는 이야기는 이러한 문화가 얼마나 극한까지 갈 수 있는지 보여주며, 극한의 데이터베이스 해킹을 통해 장애를 극복하는 기술적 이야기를 다룹니다.이야기의 시작은 데브시스터즈 역사상 가장 길었던 쿠키런: 킹덤의 36시간 장애에서 시작합니다. 쿠키런: 킹덤은 메인 데이터베이스로 CockroachDB를 사용합니다. CockroachDB는 우리가 익숙한 전통적인 RDBMS처럼 ACID 특성을 가지고 있으며, SQL 기반의 트랜잭션 처리가 완벽하게 작동하는 분산 데이터베이스입니다. 런칭 전부터 대규모 사용자 유입을 대비하여 데이터베이스는 24대의 노드, 12TB의 스토리지, 7개의 복제본을 두는 설정으로 만반의 준비를 했는데요. 실제로 오픈 직후 어마어마한 사용자 유입이 있었고, 한 주가 채 지나기도 전에 스토리지가 약 8TB 정도로 꽉꽉 차기 시작합니다.일반적으로 공휴일이 가장 큰 허들인데요. DevOps 조직인 인프라셀은 런칭 첫 주 주말을 장애 없이 넘어갑니다. 이후 월요일부터 스토리지가 차는 문제를 대응하기 위한 작업에 들어갑니다. 여기서 문제의 발단이 시작됩니다. 데이터베이스 확장 작업 전에 안전장치를 설정하기 위한 작업을 하던 중 의도치 않은 설정 미스로 인해 데이터베이스 노드 중 절반 이상이 다운되게 됩니다.앞서 CockroachDB는 트랜잭션을 지원한다고 했는데요. CockroachDB 클러스터는 기본적으로