개발 기능 소개

아키텍처를 완성하곤 ERD와 API 명세서를 빠르게 완성했다

나는 여기서 팔로우 기능을 맡았다.
맛집 추천 피드 시스템 특성상 특정 시간에는 트래픽이 몰릴 수 있고, 특히 좋아요나 팔로우는 대량의 요청이 들어올 수 있어서 이를 안정적으로 처리하기 위해 sqs와 lambda로 비동기적으로 처리하기로 했다. 로직은 다음과 같다.

1. userId와 hashtagId가 파라미터로 요청이 들어온다.
2. 파라미터는 메시지화 되어 큐에 저장된다.
3. lambda의 트리거로 sqs를 지정해 큐에 메시지가 들어오면 lambda가 이를 인지하고 자동으로 메시지를 넘겨받는다.
4. followLambda 함수로 userId와 hashtagId로 이루어진 follow 객체를 만들어 redis에 저장한다. (unfollow 요청의 경우 해당하는 follow 객체를 삭제한다.)
5. migrateLambda 함수의 트리거로 이벤트브릿지를 지정해 특정 주기마다 모든 레디스의 데이터를 객체화하여 rdbms에 저장한다.

로직 자체는 저장 로직만 있어 단순해 람다 함수로 사용하기 적합하다고 생각했다.

해커톤(개발) 후기

간단한 로직임에도 사용하는 인프라가 많아서 고민점이 많았다.

1. Lambda와 Java는 공존이 가능한가 ..

Lambda는 콜드 스타트라는 고질적인 문제가 있다. 함수가 처음 호출되거나 오랫동안 호출되지 않으면 Lambda는 이 런타임 환경을 새로 생성해야 하므로 스크립트 언어는 이 과정이 컴파일 언어에 비해 길어질 수 있다. 특히 자바는 JVM 환경에서 실행되기 때문에 Lambda 가 호출될 때마다 JVM이 초기화되는 무거운 과정을 거치므로 콜드 스타트에 취약하다. 또 코드 편집기에서 바로 작성이 불가능하고 애플리케이션 전체를 빌드해 S3를 통해 업로드 해야되는데 가벼운 람다의 특성과는 잘 맞지 않다고 느꼈다.

그럼에도 불구하고 숙련도가 낮은 파이썬이나 노드로 작성하는 것보다는 하나의 언어로 통일하는게 낫다고 생각했지만, 전자와 같은 이유로 레퍼런스조차 찾기 힘들어 구현하는데 수많은 문제를 만났고 이를 해결하는데 오랜 시간이 걸렸다.

2. Redis 저장은 되는데 읽기가 안됨

모든 로직과 인프라 설정을 마치고 테스트를 돌리는데 Redis 쪽에서 문제가 터졌다.
Redis에 저장이 되는 것까지 CLI 로 확인했는데 문제는 읽어오는게 안됨 ..

migrateDB 로직은 다음과 같다. Redis의 데이터를 모두 읽어와 RDBMS를 비운 뒤 저장하는 간단한 로직이다.

getFollows 는 레디스에 저장된 key와 value를 읽어와 캐스팅해준 뒤 Follow 객체로 만들어 List로 반환하는 메소드다. 근데 여기서

List<Object> userIds = redisTemplate.opsForList().range(key, 0, -1);

데이터를 읽어오는 opsForList 메소드에서 자꾸 캐스팅 오류가 났다.

private final RedisTemplate<String, Object> redisTemplate;

분명 redisTemplate은 String 타입의 key와 Object 타입의 value로 저장하고 있는데, Object로 읽어오려 해도 읽어와지지가 않았다. 이 이슈가 터진게 새벽 5시쯤이라 너무 졸려서 제정신이 아니라 이성적으로 문제를 해결하기 너무 어려웠다. 따라서 follow api는 구현을 못한 채 제출하게 되었다. 🥲 해커톤은 끝났지만 좀 더 알아보고 수정한 뒤 스스로 완성본을 만들어볼 생각이다.

후기 및 생각 정리

• Lambda의 ColdStart는 Snapstart로 성능 개선의 여지가 있다. 시간이 없어서 적용을 못했는데 리팩토링 할 때 적용해볼 생각이다.

• SQS 코드를 너무 간략하게 작성해서 아쉽다 !

  

사실상 로그와 전송 로직 밖에 없다. TimeOut이나 중복 필터링을 적용하지 못했다. DLQ (처리 실패 메시지 큐) 에 대한 로직도 작성하지 못했다. 이에 대한 코드를 추후 작성하여 더욱 안정성 있는 로직으로 개선하고 싶다.

• Redis 에 대한 숙련도가 너무 낮은 것 같다 ! 😭 레디스에 데이터가 저장될 때 어떤 형식으로 저장되는지, 읽어올 땐 어떻게 읽어오는지 프로세스에 대한 이해도를 높여야 될 것 같다.
• 아직 리팩토링 계획이 구체적이진 않지만, 만약 한다면 이번엔 이미 EC2가 띄워져있는 김에 SQSListener을 활용하거나 Lambda의 성능최적화, 그리고 Redis 문제 해결 등을 할 것 같다.
• 이벤트 브릿지로 배치 저장을 구현했는데 (Lambda에선 스프링 스케줄러 못 씀) Lambda에서도 스프링 배치가 활용 가능할지? 한 번 고민해봐야될듯