docs: update

Author: TreeStone94

_posts/architecture/2025-03-11-architecture.md

@@ -9,9 +9,9 @@ categories: [Blogging,architecture]
 
 ### 문제점: 제한된 API 처리 속도
 
-알림 시스템으로 발송 방식은 API로 요청을 받아 큐에 넣는 방식을 사용했습니다. 그러나 이 방식은 1000건의 알림 발송 시 초당 **50 TPS**로 처리 속도가 제한되는 한계가 있었습니다. 특히 메신저 서비스에서 대량의 알림 발송 요청이 들어올 경우, API 처리 병목 현상으로 인해 시스템 성능이 크게 저하되었습니다.
+알림 시스템으로 발송 방식은 API로 요청을 받아 큐에 넣는 방식을 사용했습니다. 그러나 이 방식은 1000건의 알림 발송 시 초당 **50 RPS**로 처리 속도가 제한되는 한계가 있었습니다. 특히 메신저 서비스에서 대량의 알림 발송 요청이 들어올 경우, API 처리 병목 현상으로 인해 시스템 성능이 크게 저하되었습니다.
 
-- **발송 TPS 확인 (키바나)**: 초당 요청수 지표
+- **발송 RPS 확인 (키바나)**: 초당 요청수 지표
 
   ![스크린샷 2024-09-05 오후 2.37.48.png](/assets/img/architecture/2025-03-11-architecture-01.png)
 
@@ -46,22 +46,19 @@ categories: [Blogging,architecture]
 
 더불어, 알림 시스템의 발송량이 **수백만 건 규모에 미치지 않으며**, **실시간 처리가 중요한 요구사항**임을 고려해 Kafka 대신 RabbitMQ로 전환하기로 결정하였습니다. 이를 통해 Kafka를 사용하는 기존 Golang 서버를 RabbitMQ로 통합하여 운영 효율성을 높이고자 합니다.
 
-### 성능 비교: 개선 전 vs 개선 후
+### 성능 비교: API vs RabbitMQ
 
-jmeter를 이용해서 개발기를 TPS가 얼마나 차이 나는지 측정해보았습니다.
+jmeter를 이용해서 개발기에서 API가 큐에 메시지를 넣는 처리량(RPS)을 측정해보았습니다. 이 측정은 큐에 넣는 처리량만을 비교한 것이며, 실제 운영 환경에서는 큐에 들어간 메시지를 소비하여 실제 발송까지 완료하는 데는 추가 시간이 소요됩니다.
+1000건에 대한 RPS
 
-1000건에 대한 TPS
-
-- 기존 API 발송 TPS
+- 기존 API 발송 RPS
 
 ![스크린샷 2024-12-04 오후 5.40.33.png](/assets/img/architecture/2025-03-11-architecture-06.png)
 
-- RabbitMQ 발송 TPS
+- RabbitMQ 발송 RPS
 
 ![스크린샷 2024-12-04 오후 5.41.06.png](/assets/img/architecture/2025-03-11-architecture-07.png)
 
-### 개선결과
-
-API 처리량(TPS)이 기존 **36**에서 **RabbitMQ를 활용한 비동기 처리 방식으로** **9259 TPS**까지 크게 향상되었습니다. 이는 약 **25,688% 증가**한 수치입니다.
+### 마치며
 
-데몬 서버가 증가한 RabbitMQ 메시지 처리 속도를 안정적으로 유지할 수 있도록 **Grafana를 활용한 지속적인 모니터링**을 진행할 계획입니다. 이를 통해 **메시지 소비 속도, 서버 리소스 사용량** 등을 실시간으로 분석하고 지속적인 개선을 통해 **최대 처리량을 유지하면서도 안정적인 운영이 가능하도록 최적화해 나갈 계획입니다.**
+**API 처리에서 RabbitMQ를 활용한 비동기 처리 방식으로** RPS가 향상되었다는걸 확인할 수 있었습니다. API 발송에서 RabbitMQ 발송 전환은 서비스팀과 협업화여 성공적으러 전환되었고 데몬 서버가 증가한 RabbitMQ 메시지 처리 속도를 안정적으로 유지할 수 있도록 **Grafana를 활용한 지속적인 모니터링**을 진행할 계획입니다. 이를 통해 **메시지 소비 속도, 서버 리소스 사용량** 등을 실시간으로 분석하고 지속적인 개선을 통해 **최대 처리량을 유지하면서도 안정적인 운영이 가능하도록 최적화해 나갈 계획입니다.**

_posts/db/2025-06-21-db.md

@@ -69,6 +69,8 @@ mongoDB 샤딩키를 ObjectId로 초기 구성부터 운영되고 있었습니
 > 2. 단점
 > - 범위 쿼리 비효율
 
+![mongodb-페이지-2.drawio (1).png](/assets/img/db/2025-06-21-db-09.png)
+hotspot 문제로 인하여 샤드에 평균 10만건이 insert 되고 있었습니다.
 ## 재구성
 
 주기마다 PM 작업이 있어 서비스 일시 중단 일정에 맞춰 Devops팀에 협업하여 mongoDB 샤딩키를 재구성하기로 하였습니다.
@@ -93,6 +95,8 @@ sh.shardCollection("users.data", { userId: "hashed" })
 ![스크린샷 2025-06-17 오후 3.26.31.png](/assets/img/db/2025-06-21-db-07.png)
 
 다행히 이슈없이 restore 및 샤딩키 재구성이 마무리 되었습니다. 그이후 모니터링을 통해 샤드들의 CPU 사용률은 10~20%으로 감소되어 성능이 많이 개선된걸 확인할 수 있었습니다.
+![스크린샷 2025-06-17 오후 3.26.31.png](/assets/img/db/2025-06-21-db-10.png)
+또한 10만 건의 알림 데이터가 특정 샤드로 집중되는 Hotspot 문제를 Hash 기반 샤딩으로 해결했습니다. 데이터를 해시 함수로 분산시켜 각 샤드당 800~1,000건씩 균등하게 처리되도록 개선한 결과, Insert 성능이 약 100배 향상되었습니다.   
 
 mongodb 구성할 때 사딩키의 중요성과 재구성할려면 많은 비용이 소모된다는걸 알게되었습니다. 모니터링하면서 서비스가 문제점이 없는지 계속 지켜볼 예정입니다.