TV 프로그램 <놀면 뭐하니?> ‘유플래시' 편에서 영감을 받은 서비스로, 녹음을 기반으로 한 온라인 릴레이 음악 합주 플랫폼 웹 서비스
해당 프로젝트의 요구사항으로 구글, 네이버, 카카오에 대한 로그인 기능을 제공해야 했습니다. 우선 구현을 위해 각 서비스의 API 공식 문서를 파악하였습니다. OAuth 2.0의 큰 흐름을 따르지만 서비스마다 세부적인 url과 파라미터 등은 달라 각 서비스에 대한 Controller-Service 클래스를 작성하였습니다.
기능 동작에는 큰 문제가 없었지만, 서비스만 다를 뿐 동일한 기능을 제공한다는 점에서 서비스마다 Controller를 가지는 설계에 대해 의문을 가지게 되었습니다. 특히, 로그인 과정에서 비즈니스 로직이 추가가 된다면 각 Service 클래스에서 변경이 생겨 OCP 를 위반하게 되고 유지보수에 용이한 코드가 아니라고 생각했습니다.
이를 개선하기 위해 요청에 대한 공통된 흐름은 하나의 Controller의 메소드에서 처리하도록 하고, 소셜 서비스마다 다른 세부적인 처리는 소셜 서비스마다 Service 클래스를 작성하였습니다. 또다른 소셜 서비스가 추가된다고 하더라도 Controller에서는 변경 지점이 생기지 않도록 할 수 있다는 이점을 가져왔습니다. 또한 각 Service 클래스는 공통의 인터페이스의 구현체가 되도록 설계하여 클래스의 기능을 추상화 시킬 수 있었습니다.
이미지 데이터는 RDBMS에 직접 저장하는 것은 DB 성능에 부하를 가져오기 때문에 이미지를 비롯한 서비스에 필요한 파일 스토리지로 S3를 사용하였습니다.
하지만 필요할 때마다 Origin Server인 S3에 요청을 하기 되면 여러 라우터를 거치게 되어 지연시간이 길어진다는 문제점이 있었습니다. 또한 우리 서비스가 성장해 전세계 사람들이 많이 사용한다면 S3에 요청량이 많아지고 지연시간 또한 지속해서 길어진다는 문제점이 있었습니다.
이 문제를 해결하기 위해 CDN 서비스인 CloudFront를 이용하여 S3로의 직접적인 요청을 줄이는 방식을 선택해 반영하였습니다. Edge Location or Edge Server에서 요청에 대한 응답을 대신 처리해주기 때문에 Origin Server에 대한 부담도 덜면서 짧은 지연시간으로 응답이 가능했습니다.
🔗AWS S3 + CloudFront + Lambda를 이용한 사용자 프로필 이미지 업로드 API 구현기
해당 서비스에서는 하나의 프로젝트라는 개념에 최대 10개의 트랙만이 포함되어야한다는 요구사항이 있었습니다. 트랙 생성 API를 구현하고 동시성이 보장되는지 확인을 위해 테스트코드를 작성하여 확인한 결과 10개 이상의 데이터가 생성되는 문제가 발생했습니다.
동시성 이슈를 해결하기 위해 제일 먼저 synchroized 키워드를 사용하는 방안을 시도했습니다. 해당 방식은 동시성 이슈는 해결이 되었지만, 분산 서버 환경에서는 동시성이 보장되지 않는다는 문제가 발생했습니다.
분산 서버 환경에서도 동시성을 보장할 수 있도록 Database의 낙관적 락과 비관적 락에 대해 학습하였고, 낙관적 락은 롤백을 개발자가 직접해야한다는 단점이 있었지만, 서비스 특성상 충돌이 빈번하게 일어나지 않고, 성능상 유리하다는 점에서 해당 서비스에서 적합하다고 생각되어 낙관적 락 방식을 통해 문제를 해결하였습니다.