[TechNews] 유용한 개발 관련 아티클 및 영상 #33

 

1. 유용한 개발 관련 아티클 및 영상 #33

---

valve handbook

• 놀랄 정도로 뛰어난 사람들이 자신들의 최상의 결과물을 수많은 사람들에게 걸리적거리는 장애물 없이 전달할 수 있는 그런 환경
• 하지만 제일 중요한 것은, 우리는 우리의 제품을 사랑하는 열정적인 사람들이 모인 회사다 채용은 밸브에서 하는 최고 중에 최고로 중요한 일이다
• 밸브는 수평구조이기 때문에, 사람들은 누가 시켜서 프로젝트에 참여하지 않는다. 대신에 자신에게 직접 질문들을 던지고 자신이 일할 프로젝트를 스스로 선택한다.
• 당신은 회사 내에서 당신이 할 수 있는 가장 가치있는 일을 하라고 채용된 것이다.
• 당신이 하는 결정에 누군가 좌지우지 할 권한을 가지고 있다고 절대 생각하지 마라. 그런 권한은 그들에게 없다. 하지만 소중한 그들의 경험, 당신에 없는 정보들, 새로운 관점에는 귀를 기울여라.
• 대부분의 경우 야근이 일정기간 이상 지속된다는 것은 계획이나 커뮤니케이션에 치명적인 오류가 있다는 것을 말한다.
• 일, 삶, 그리고 다른 중요한 것들 사이의 밸런스를 잘 맞추고 살면서 오래 오래 다니기를 원하기 때문이다. 만일 당신이 너무 오래 일하고 있거나, 전반적으로 밸런스가 무너지고 있다고 느끼면 도와줄 만한 사람에게 반드시 이야기를 해라.
• 당신이 프로그래머로 채용되었다면, 이제는 다양한 분야의 전문가가 섞인 그룹들에 둘러 쌓여 있을 것이다 - 기획, 법무, 재무, 심리학까지. 이런 사람들은 대부분 당신과 같은 방안에 매일 앉아있을 것이고, 그렇기 대문에 당신이 배울 수 있는 기회는 무궁무진하다.

 

출처: valve handbook

 

 

 

The New MySQL Thread Pool

• 문제점
  • MySQL Enterprise의 Thread Pool을 사용하면, 대규모 온라인 트랜젝션이 발생하는 시스템의 처리량을 높여 성능을 높일 수 있음
  • 기본적으로 one-thread-per-connection 모델을 사용하는데, 여기서는 사용자가 서버에 연결하면 해당 연결을 위한 전용 OS 스레드가 생성됨
  • 사용자가 많아디면 더 많은 OS 쓰레드가 생성되고 병렬로 실행되는데, 쓰레드 추가가 비효율적인 한계에 도달하게 되며, 연결 수가 증가함에 따라 MySQL의 전반적인 성능이 저하됨
  • 스레드는 대기하거나 OS 스케줄러가 제공하는 시간 조각을 모두 사용할 때까지 명령을 실행하는데, 스레드가 대기해야 할 수 있는 것에는 뮤텍스, 데이터베이스 객체 잠금, IO의 세 가지가 있음
• 쓰레드 풀
  • MySQL 스레드 풀은 사용자 연결과 스레드를 분리하는 기능을 도입했고, 이전과 달리 각 사용자 연결에는 더 이상 전용 OS 스레드가 할당되지 않음
  • 대신 스레드 풀은 스레드 그룹으로 구성되며, 사용자 연결은 라운드 로빈 방식으로 스레드 그룹에 할당됨. 그리고 각 스레드 그룹은 사용자 연결의 하위 집합을 관리힘
  • 각 스레드 그룹 내에는 해당 스레드 그룹에 할당된 사용자 연결에서 받은 쿼리를 실행하는 하나 이상의 스레드가 존재함
• 최대 트랜잭션 제한
  • 스레드 풀은 사용자 연결 수가 증가함에 따라 성능 저하를 방지하도록 특별히 설계되었는데, 스레드 풀에 '최대 트랜잭션 제한' 기능이 도입되어 동시에 실행할 수 있는 트랜잭션 수를 제한할 수 있음
  • 부하가 많은 시스템에서 동시 트랜잭션 수를 제한하면 동시 데이터 잠금 수를 제한하고 교착 상태 발생을 줄여 서버의 전체 처리량을 향상시킬 수 있음

 

 

출처: https://dev.mysql.com/blog-archive/the-new-mysql-thread-pool/

 

 

 

허튼짓은 그만: Kafka Streams를 활용한 실시간 이상 로그인 감지 시스템 도입하기

• 개요
  • 이상 로그인을 감지하기 위해 실시간 로그인 정보를 활용하여 데이터를 집계하고 분석해야 함
  • 로그인 이력 정보는 로그인 처리 후 Kafka를 통해 이벤트를 발행 및 후처리로 RDB에 저장하고 있고, 로그인 이력 정보를 실시간으로 집계하기 위해서는 초당 수백 건으로 들어오는 데이터와 연관 있는 특정 기간의 데이터들을 집계하여 패턴을 분석해야함
  • RDB를 조회하는 배치를 개발하는 모델도 있었지만, 부하와 실시간 처리의 보장이 어려워 제외되었고, Kafka 메시지를 활용하여 데이터를 처리하기로 결정했음
• Kafka Streams
  • Kafka 클러스터에서 데이터를 처리하고 분석하기 위한 클라이언트 라이브러리
  • 애플리케이션에서 데이터를 읽고 쓸 수 있으며, 스트림 처리를 위한 고수준 API를 제공.
  • 장점
    • Kafka cluster와 함께 확장되므로 처리량을 쉽게 조정 가능
    • Kafka cluster와 연동되어 데이터 손실 없이 안정적 내결함성 제공
    • Java 라이브러리로 구현
    • Exactly-once를 보장
  • 단점
    • 일부 복잡한 처리 작업에는 기능이 제한적
    • Kafka 컨슈머 그룹을 사용하여 데이터를 처리하여 컨슈머 그룹의 부하나 지연이 Kafka Streams 애플리케이션의 처리 속도에 영향을 줌

 

 

 

출처: https://medium.com/musinsa-tech/허튼짓은-그만-kafka-streams를-활용한-실시간-이상-로그인-감지-시스템-도입하기-d05768b78c86

 

 

 

Bending pause times to your will with Generational ZGC

• Reduced tail latencies
  • GRPC와 DGS 프레임워크 모두에서 GC 일시 중지가 꼬리 지연(latency)의 주요 원인이였음
  • 요청이 타임아웃되어 취소되면, reliability 기능(예: 재시도, 폴백)이 실행되어 전체 서비스 트래픽이 해당 비율만큼 추가로 증가함
  • GC 일시 중지를 줄여 이러한 요청 취소를 감소시키고, 결과적으로 서비스 트래픽도 그만큼 줄어듦
  • 또한 일시 정지 노이즈를 제거하면 노이즈에 숨겨져 있던 지연의 실제 원인을 파악할 수 있음
• Efficiency
  • 측정 시에 매우 유망함에도 불구하고, ZGC를 채택하면 어느 정도의 트레이드 오프가 있을 것이라고 예상했음
  • 그러나 실제로 그러한 트레이드오프가 없었고, 특정 CPU 사용률 목표를 기준으로 할 때, ZGC는 G1GC와 비교했을 때 평균 및 P99 지연 시간을 개선하면서도 동일하거나 더 나은 CPU 사용률을 보여주었음
• Operational simplicity
  • 효율성을 위해 외부 서비스 호출을 피하고자 주기적으로 많은 양의 힙 내 데이터를 새로고침하는 여러 프레임워크를 사용하고 있었음
  • 이러한 주기적인 힙 내 데이터 새로고침은 G1에게 예기치 못한 상황을 초래하여 기본 일시 중지 시간 목표를 훨씬 초과하는 일시 중지 시간 이상치를 발생시키기도 함
  • 이는 이전에 non-generational ZGC를 채택하지 않은 주요 이유였는데, generational ZGC를 사용했을 때 거의 10%의 개선을 이루었음
• … 그 외에도 여러가지 ZGC를 통해 여러 가지 장점들을 누릴 수 있었음

 

 

출처: https://netflixtechblog.com/bending-pause-times-to-your-will-with-generational-zgc-256629c9386b