스터디 진행 일시

날짜 : 7월 04일 (금요일) 시간 : 오후 6시 ~ 9시 (3시간) 장소 : 강남 (오프라인)

🔧 금주 스터디 일정

• 개발 책 10장 - 알림 시스템 설계
• RDS 스케일 다운 어떤 기준으로 할까?
• 라이브 코테 진행

📖 개발 책 10장

• 10장
  • 10장은 알림 시스템 설계에 관한 이야기를 다룬다.
  • 알림 시스템은 단순히 모바일 푸시 알림에 한정되지 않는다
  • 알림을 전달하는 채널(수단)은 많지만, 이 책에선 3가지 채널(모바일, SNS, 이메 일)을 다룬다.
  • 알림을 처리할 때, 배치 / 실시간 / 연성 실시간 3가지의 종류가 있다.
    • 배치 : 배치 단위로 데이터를 한번에 처리
    • 연성 실시간 (soft real-time) : 가능한 알림을 빨리 전달하되, 시스템에 높은 부하가 갈렸을 때 약간의 지연을 허용하는 시스템
    • 실시간 (real-time) : 데이터가 도착하자마자 조건 확인 및 알림 처리
  • 알림 시스템 설계 시, 실시간성을 고려하는 이유는 무엇일까?
    • 로그인 실패 5회 또는 다른 지역에서 로그인 발생 시 -> 즉시 알림(보안 알림)
    • 특정 임계값을 넘는 순간 -> 즉시 알림
  • 알림 매커니즘은 어떻게 될까?
    • iOS 푸시 알림
      • 알림 제공자(Provider) : 알림을 만들어 보내는 주체가 메시지 내용을 만들고 이 알림을 Apple의 푸시 서버(APNS)에 전달하다.
      • APNS(Apple Push Notification) : APNS는 Apple이 운영하는 공식 푸시 알림 전송 서버다. 모든 iOS 푸시 알림은 이 APNS를 거쳐서 아이폰에 도착하게 된 다. 일종의 우체국이다.
      • 기기는 사전에 APNS에 등록되어 디바이스 토큰이라는 고유 ID를 가지고 해당 기 기로 푸시 알림을 전송한다.
  • 안드로이드
    • 안드로이드 푸시 알림도 비슷한 절차로 전송한다. 대신 APNS 대신 FCM(Firebase Cloud Messageing)을 사용한다는 점만 다르다.
  • 이메일
    • 이메일은 단순히 “보내는 역할”만 하는게 아니라 전송 후의 데이터까지 분석할 수 있다.
    • 예를 들어 이메일이 받는 사람의 스팸함이 아닌, 받은 편지함으로 도착할도록 최적하는 플랫폼을 이용할 수 있다.
    • 이메일은 푸시 알림과 다르게 풀링 기반으로 동작하기 때문에 메일 서버에 접속 해서 새 메일이 있는지 주기적으로 확인하는 방식이라 푸시 방식보다는 느리다.

📖 RDS 스케일 다운은 어떤 기준으로 할까?

🙌 준호님의 작은 세미나 🙌

• RDS 스케일 다운을 왜 해야할까 ?
  • RDS는 너무 비싸서 줄여도 될때 줄이는게 좋다
• 스케일 다운을 위한 기준
  • CPU 사용률 30% 미만
  • 메모리 여유 (FreebleMemory)가 높음
  • 커넥션 연결 수가 여유가 많음
  • 성능 지연 - 슬로우 쿼리 없음
  • DB Load - vCPU 수보다 낮음

이제 이 기준에 대해 하나씩 알아보자.

• CPU 사용률은 RDS의 instance가 얼마나 많은 CPU 자원을 점유하여 작업을 처리 하는 지에 대한 지표이다.
• 메모리는 db.r5.xlarge를 예로 메모리 64GiB(약 68.7GB)로 들어보자. 메모리를 확인 해보면 대부분 자동으로 캐시, 쿼리 버퍼, 세션 캐시등으로 사용하기 위해 선 점유 를 하기 때문에 남는 GB는 대략 15GB가 남는다.
  • 사용 중인 메모리 => 64GiB - 15GiB = 53GiB
  • 사용률 (53/64) * 100 = 82.8%
• 이는 정상적인 상황인데, 만약에 20GiB이상 남는다면 스케일 다운하는 것이 좋고, 남는 GiB가 거의 없다면 스케일 업을 준비하는 것이 좋다.
• 주의할 점으로는 스케일 다운을 판단하는데 도움을 주는 메트릭이지만, 메모리만을 보고 판단하면 절대 안되고 CPU + 메모리 + QPS 등 여러 지표를 복합적으로 봐야한 다.

• 커넥션 연결 수는 RDS 인스턴스 간에 연결된 MySQL/TCP 세션의 개수를 실시간으로 나타내는 지표이다. 해당 지표를 통해 max_connections에 가까운 수치를 사용하는지 , 커넥션이 많이 남아도는지 등을 파악해서 DB 스케일 다운 여부를 판단 할 수 있다 .
  
  
  

  AWS 커넥션수 공식 문서
  
  • (64GiB) 68719476736 byte / 12582880 = 5461(커넥션)
  • 하드웨어가 감당하는 커넥션의 갯수이지만, 실제 설정된 커넥션은 다르기 때문에 DB에 접속해서 명령어를 통해 max connection을 확인해야 한다.
  • 그리고 CloudWatch와 같은 모니터링 시스템에서 얼마나 많은 커넥션을 사용하는지 확인한다.
• 슬로우 쿼리 여부를 지표로 삼는 것은 사실 애매할 수 있다. 원래 개발부터 감내하 고 4~5초 이상 걸리는 쿼리를 만들었던가, 아니면 시간이 지나면서 성능 개선이 안 된 쿼리들이 있을 수 있어서 그런 쿼리들을 대상으로 보면 안된다.
  • 슬로우 쿼리는 AWS console보다는 Datadog를 활용해서 슬로우 쿼리를 보는 것을 추천한다.
  • 쿼리 중 사용량이 높은 쿼리를 위주로 과부하로 성능이 밀리는 것을 판단하자.
• DB Load는 동시 실행중인 세션 수를 의미하는 절대 수치이다. 맥수 값은 정해져 있 지 않으나 현재 vCPU(인스턴스)에 따라 상대적으로 판단해야 하는 지표이다.
  • DBLoadCPU 지표가 높다면 DB 인스턴스가 CPU 바운드 작업이 많이 처리 중인다.
  • DBLoadNonCPU 지표가 계속 높다면 I/O 병목 현상이나 락 경쟁이 벌어지고 있어서 튜닝 해야할 수 있다.
  • DBLoad는 쿼리 실행 수가 많거나 느린 쿼리가 쌓이면 증가한다.

💻 라이브 코테

• 문제 : https://leetcode.com/problems/pascals-triangle/description/
  • 제한 시간 내 최대한 풀어풀기.