brunch

You can make anything
by writing

C.S.Lewis

by 밍써니 Nov 29. 2024

[기획자의 개발지식] 서비스 안정성을 위한 고려사항

feat. 배치, 갱신, 색인, 캐싱, 서버 증설

| 신뢰도 있는 서비스 제공, 안정적인 서비스 제공이 사용자의 경험에 중요하다.  


많은 커머스 회사들에서 11월을 맞아 블랙프라이데이 행사를 진행하고 있다. 이렇게 트래픽이 많이 몰리는 행사에서 안정적이지 못한 서비스는 사용자의 신뢰도를 잃을 뿐만 아니라 매출에도 직접적으로 연결될 수 있다. 이렇기 때문에 사전에 서비스가 안정적으로 제공될 수 있는지 점검하는 것은 중요하다.



이번 글에서는 배치, 갱신 주기, 색인, 캐싱, 서버 증설 등 서비스의 안정성을 위해 실무에서 알아두면 유용한 개발 기본 개념과 어떻게 활용되는지 소개한다. 자주 들어도 아직도 조금은 헷갈리는 개념들이라 스스로 정리해보는 차원에서 이렇게 정리해보며, 다른 주니어 PM에게도 이 글이 도움이 되었으면 한다.



1. 배치(Batch): 대량 데이터 처리의 핵심


배치란?

특정 시간에 데이터를 대량으로 처리하는 작업.      

eg. 하루 동안 쌓인 로그 데이터를 새벽에 정리, 대량의 고객 메세지를 한 번에 발송.      


기획 시 고려할 점

1) 배치는 대량의 데이터를 처리하기 때문에 시스템에 부하가 되어 느려질 수 있다. 시스템이 느려지면 고객 경험에도 문제가 될 수 있기 때문에 트래픽이 적은 시간대(새벽)에 실행하도록 설정해야 한다.

2) 배치 작업 실패 시 장애가 확산되지 않도록 분리 설계하는 점도 엔지니어링 사이드에서 고려될 수 있도록 확인해야 한다. (eg. 주문 내역 배치 실패 시, 배송 진행에는 영향이 없도록 설계)    




2. 갱신 주기(Refresh Cycle): 데이터 업데이트 빈도 조절  


갱신 주기란?

시스템이 데이터를 업데이트하거나 새로고침하는 간격.

eg. 실시간 랭킹 데이터를 5분 주기로 업데이트, 사용자의 알림 상태 정보를 10분 주기로 업데이트 한다.


기획 시 고려할 점

1) '상품 판매가 정보', '재고 정보', '실시간 랭킹' 등 실시간성이 중요한 데이터는 짧은 주기로, 중요도가 낮은 데이터는 긴 주기로 갱신 주기 정책을 잡는다.

2) 갱신 주기가 짧으면 서버 부담이 커지므로 적절한 갱신 주기를 고려하여 설정한다. 특히 블랙프라이데이와 같은 트래픽이 많은 시점에는 서버 부담을 고려하여 갱신 주기를 평소보다 길게 설정하기도 한다.

 

참고사항

아래는 실제 일하면서 겪었던 갱신 주기 관련한 사례이다.

eg. 기획전 갱신 주기가 1시간으로 잡혀 있었으나, 운영 쪽에서 기획전을 발행했음에도 확인되지 않는다고 문의가 많이 들어와 갱신 주기를 10분으로 수정하였다.




3. 색인(Indexing): 검색과 데이터 일관성의 연결고리  


색인이란?

데이터를 검색엔진에 최적화된 형태로 변환하는 작업.

eg. 상품 정보(가격, 재고, 태그 등)를 색인해 빠른 검색 결과 제공.      


기획 시 고려할 점

1) 색인을 언제, 얼마나 자주할 것인지 고려가 필요하며 그 주기를 알고 있다면 도움이 된다.

2) 색인은 특정 케이스에는 실시간으로 색인할 수 있도록 조건을 걸 수 있다. 중요한 정보가 업데이트 되었을 땐 그 상품을 실시간으로 색인하고, 그 외 정보는 배치 색인을 진행하는 방식으로도 고려할 수 있다.

eg. 실시간 색인: 가격, 재고 등 사용자 경험에 민감한 데이터는 실시간 색인 설계.

eg. 배치 색인: 대량의 데이터 변경(eg. 상품의 태그 정보)은 주기적으로 처리.

3) 색인 주기가 길어지면 검색엔진 정보와 다른 지면에서 데이터 불일치가 발행할 수 있기 때문에, 이런 점들을 고려해 적정 주기 및 정책을 설정할 필요가 있다.


참고사항

내가 많이 겪었던 에러사항 중 색인과 관련한 사례가 있었다. 실시간 DB 정보와 색인 데이터 간의 시간차로 인해 정보가 맞지 않아 에러사항으로 많이 문의가 오는 것이다.

eg. 상품을 세일 상품으로 등록하였고 상품 배치는 돌아가서 세일 상품으로 적용이 되었으나, 색인이 아직 반영되지 않아서 '세일' 필터로 걸었을 때 상품이 '세일' 필터링에 걸리지 않음




4. 캐싱(Caching): 빠른 데이터 제공의 비결  


캐싱이란?

자주 요청되는 데이터를 미리 저장해 서버와 DB 부하를 줄이는 기술.

eg. 사용자 닉네임 등을 캐싱해두고, 화면에서 닉네임을 호출할 때 사용한다.


캐싱의 작동원리 (ChatGPT의 도움을 받아 직접 만든 구조도 (made by me))


기획 시 고려할 점

1) 자주 사용되면서도 실시간으로 변경될 필요성이 적은 데이터, 정합성이 그렇게 중요하지 않은 정보를 캐싱 정보로 두는 것이 좋다. (자주 사용된다는 건 자주 불러와야 하는 것이기 때문에 캐싱이 없다면 서비스에 부하가 올 수도 있다)

eg. 게시글 좋아요 수, 사용자 프로필 사진

2) 개발에서 수정사항을 반영했는데, 내 화면에서 보이지 않는다면 보통 '캐시' 때문인 경우가 많았다. 반영이 안되어 있다면 캐시를 날리고 확인해보면 좋다. (인터넷 사용 기록 날리기 등)

3) 캐싱 데이터가 오래되면 정합성 문제가 발생할 수 있으므로, 적절한 만료 시간을 설정해 최신성을 유지하는 것이 좋다.


참고사항

API를 적용하면 실시간 정보를 불러오는 줄 알았으나, 경우에 따라 정보가 실시간이 아닐 수 있다. 그 원인 중 하나가 캐시 때문이었다.

eg. API 부하가 우려되거나 응답 속도를 높이기 위해 캐싱이 적용되어 있을 수 있다. 이때는 캐시가 만료되기 전까지는 최신 정보가 반영되지 않는다.

eg. 호출하고 있는 API가 DB의 정보를 실시간으로 반영하지 않는다면, 최신 정보가 반영되지 않는다.




5. 서버 증설과 부하 분산(Scaling & Load Balancing)  


서버 증설이란?

트래픽이 급증할 때 서버를 추가로 늘려 안정성 확보하는 작업

eg. 오토 스케일링(Auto Scaling): 사용량에 따라 자동으로 서버를 확장/축소


부하 분산이란?

여러 서버에 트래픽을 나눠 처리.

eg. 한 서버에 1,000명이 몰리는 대신, 10개의 서버에 나눠 100명씩 처리


기획 시 고려할 점

1) 블랙프라이데이와 같은 대규모 프로모션을 기획할 때 예상 트래픽을 기반으로 서버 확장 계획 준비한다.

eg. 작년 트래픽 데이터에 의하면 프로모션이 오픈하면 10배정도 트래픽이 몰린다. 데이터에 기반하여 프로모션 시작 전에 서버를 N배 증설하고, 부하 테스트를 통해 최대 트래픽을 시뮬레이션 할 수 있도록 한다.

eg. 브랜드의 인기 상품이 오픈한다거나 아이돌 콜라보 상품이 오픈할 때도 트래픽이 몰리는 경우도 많이 목격하였다. 트래픽이 몰릴 것임을 미리 공유하고 서버가 안정적으로 운영될 수 있도록 하는 것이 기획자가 필요한 부분이라고 생각한다.




| 결론

1) 안정적인 서비스를 위해 위의 내용들을 보통 개발자분들께서 챙겨주시긴 했지만, 기획에서도 알아두면 좋을 (어쩌면 꼭 알아두고 챙겨야 할) 부분들이 배치, 갱신, 색인, 캐싱, 서버 증설 등의 내용이었다.

2) 커머스 플랫폼에서는 운영팀에게 "왜 다르게 나오나요?", "반영이 안돼요!" 와 같은 질문을 많이 받는다. 보통 위의 경우에 의해서 안된 경우가 많다. 그렇기 때문에 미리 캐싱, 색인, 배치 등의 정책 정도는 알고 있는게 좋으며, 빠르게 반영 필요한 경우에는 특정 상품, 정보만 한번 색인 요청드리는 방식으로 운영하고 있다.

3) 부하로 인해 느린 서비스, 지면 간의 불일치하는 정보 등은 사용자 경험에도 좋지 않은 영향을 미치며 서비스를 신뢰도를 잃을 수 있다는 점을 기억하며 서비스를 운영할 수 있도록 하자.




| 실무에서 활용할 수 있는 체크리스트  

배치: 트래픽 낮은 시간대를 파악하여 배치 시점 계획

갱신 주기: 실시간/정기적 갱신 데이터 구분하기, 갱신 주기 확인하기

캐싱: 캐시로 관리할 정보 및 주기 확인하기

서버 증설: 이벤트 트래픽 예측하여 미리 서버 증설 요청드리기

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari