4월 2주 있었던 일 정리

Introduction

• 정산 작업
  • 0. 데이터 모델링
  • 1. 빠른 정산 내역 조회 기능을 제공하는 일
  • 2. 데이터 동기화하는 일
  • 마무리

거의 한 달만에 회고를 작성한다. 변명하자면 알던 지식을 세련하는 시간을 가지다보니 회고할 일이 적어졌다. 4월 한 달 간 갑자스럽게 업무량이 늘어나기도 했지만 업무하면서 놓치는 것들을 다시 작성해보려 한다.

정산 작업

포인트 관련 업무 중 정산 작업을 진행하게 되었다. 정산 작업에서 신경써야 할 포인트는 두 가지다. (1)빠른 정산 내역 조회 기능을 제공하는 일과 (2)계열사 별로 정산하는 일이었다.

0. 데이터 모델링

계열사 별로 정산하는 일은 데이터 모델을 손봐서 해결할 수 있지만, 변경 전 내역도 관리하려면 복잡해진다. 변경 전 내역도 데이터 모델을 손보는 일보다 새롭게 테이블을 생성해 정산 이력을 관리하는 게 리소스나 데이터 무결성 관리 측면에서 좋아보였다.

작업하면서 제 2 정규화가 생각났다. 완전 함수 종속을 만족하도록 테이블을 분리하는 일이다.

분리하면 가독성과 테이블 수정 리소스를 줄일 수 있다고 쉽게 생각할 수 있다. 심지어 어쩌면 읽기 작업이 분산되는 이점도 생길 수 있다.

1. 빠른 정산 내역 조회 기능을 제공하는 일

사용 이력은 몇 백만 건 수준이라 정산 이력도 동일한 규모가 발생한다. 그럼 정산 백오피스에서 날짜 기준으로 정산 이력을 조회하면 어떻게 될까?

인덱스는 일정 범위를 넘어서면 풀 스캔으로 변경하게 된다. 즉, 사용자의 입력 값에 따라 성능이 결정되어 버린다.

백오피스라 성능을 조금 포기하고 빠르게 개발하는 일을 목표로 할 수 있지만, 연간 365개의 데이터로 해결 할 수 있다면 괜찮지 않을까?

날짜 별로 집계 배치를 돌린다면 정산 이력 조회 시간을 줄일 수 있다. 만약 실시간을 보장하길 원한다면 이전 날짜는 배치로 생성된 당일 집계 데이터와 오늘 날짜는 오늘 날짜에 생성된 정산 데이터를 집계해 보여주면 된다.

2. 데이터 동기화하는 일

앞서 이야기 했듯이 새로운 정산 테이블을 생성하고 날짜를 기준으로 업데이트하는 방식을 선택했지만, 기존 사용 이력과 새로운 사용 이력 간 오차도 걱정됐다. 0.01%의 오차를 신경써서 지속적으로 동기화하는 것 보다 집계 기준인 날짜로 동기화할 수 있도록 구성했다.

더 이상의 검증은 필요하지 않느냐? 라는 의문이 들 수 있지만 나는 최종 일관성을 지키고 있다라고 이야기 할 수 있다. 즉, 사용 이력과 정산 이력을 비교하면서 검증한다면 정산 이력은 집계 기준으로 동기화되어 있기 때문에 걱정 없다.

마무리

개발 과정을 거치면서

성능을 확인하면서 진행하기 전에 어느 정도 유추할 수 있음을 깨닫고 있다. 돌아갈지 확인하는건 미리 계산해도 되지 않나?라는 생각이 든다. 덕분에 사용자 입력에 따라 성능 변화가 발생함을 감지할 수 있고 쉽게 해결 할 수 있었다.

검증 과정을 고민하면서

백엔드에서 짐은 곧 행동의 제약이다. 이것저것 검증 과정을 붙여보려고 했지만 결국 짐이 되지 않을까 걱정됐다. 처음에는 동기화가 잘 되어줄지 걱정하는 마음이 굴뚝이었지만 어떤 작업이 정말 필요한 검증 과정인지, 중복은 아닌지 생각하게 되었다. 결국 객관적인 이론을 통해 스스로를 납득시키는 과정이 꽤나 괜찮았다. 괜한 고민이 없어졌기 때문이다. 고민이 생기면 정리해보는 것도 방법같다.

개선과 목표

서버에서 여러 개의 작업을 스케줄링하는 모습을 확인했다. 업데이트마다 변경해야 하는 코드를 일일이 배포한다고 생각하면 리소스가 너무 많이 든다. 해당 작업을 람다로 변경하면 24시간 떠 있는 비용과 관리 포인트를 줄일 수 있어보인다.

이 부분은 아직 구상 중이기도 하고 작업 리소스와 리스크 그리고 성과 윤곽이 드러나지 않아서 구상만 하고 있다. 최근에 대규모 시스템 설계에서 다음과 같은 글귀를 봤다.

아키텍처를 단순하게 만든다면 더 많은 메모리를 투입할 만한 가치가 충분하다.

조금의 이득만 발생해도 좋은 방법이 아닐까하는 생각이 든다.

그럼 여기에서 lambda 로 실행하게 두 번 이상 실행하면 문제가 발생하지 않을까?라는 큰 고민이 생긴다. 지금 준비하는 작업들은 멱등성이 보장된다. 작업 중 하나가 일정 기간 지난 데이터는 만료 처리를 하는 건데 날짜가 같으면 결과가 항상 같다.

그럼 앞으로 멱등성이 보장되지 않는 작업이 생기면 어떡할까? 음… 작업을 하는 데이터베이스에 작업 디스크립터를 넣어 멱등성 키를 관리해보는건 어떨까... 레디스를 활용하면 만료처리를 쉽게 할 수 있어서 더 우아하게 처리할 수 있어보인다.