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

 

 

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

---

Spring Framework 6.2.0-M1: all the little things(비교작 작지만 요구가 많았던 개선 사항)

• property placeholders에 대한 개선
  • property placeholder는 Environment의 속성을 임의의 문자열로 대체하는 방법임
  • Environment의 customer.name이 "John Smith"로 설정되어 있다면 "Customer ${customer.name}"는 "Customer: John Smith"로 치환됨
  • Spring 6.2.0-M1에서는 구성 가능한 이스케이프 문자(기본적으로 백슬래시)를 사용하여 플레이스홀더를 이스케이프 처리할 수 있음, "Customer \${customer.name}"은 이제 "Customer ${customer.name}"으로 치환됨
• fallback bean에 대한 구현
  • Fallback bean은 해당 유형의 빈이 존재하지 않을 경우 사용할 수 있음
  • Fallback bean 구현을 위해 @Fallback 애노테이션을 사용할 수 있음
• Bean의 백그라운드 초기화
  • 새롭게 추가되는 @Bean의 bootstrap 속성을 사용하면 백그라운드로 초기화 할 수 있음
• TaskDecorator이 scheduled tasks를 지원함
  • 예약 작업을 위해 TaskDecorator를 사용할 수 있음
• MockMvc를 위한 AssertJ 기능을 지원함
  • MockMvc에 대한 Assertion을 확장된 AssertJ를 통해 처리할 수 있음
• 기타 등등
  • 이것들 외에도 그 동안 백로그로 존재하던 100개가 넘는 이슈들이 개선되었음

 

출처: https://github.com/spring-projects/spring-framework/releases/tag/v6.2.0-M1

 

 

 

레디스에서의 만료된 키 삭제

• passive 방식
  • 클라이언트가 키에 접근하고자 할 때 키가 만료됐다면 메모리에서 수동으로 삭제함
  • 사용자가 접근할 때만 수동으로 삭제되므로 passive 방식의 만료라 함
  • 사용자가 다시 접근하지 않는 만료된 키가 존재하는 경우에 이 방식으로 충분하지 않음
• active 방식
  • TTL 값이 있는 키 중 20개를 무작위로 뽑고, 만료된 키를 모두 메모리에서 삭제함
  • 만약 25% 이상의 키가 삭제됐다면 다시 20개의 키를 무작위로 뽑고, 아니라면 뽑아놓은 20개의 키 집합에서 다시 확인함
  • 해당 작업은 1초에 10번씩 수행됨

 

출처: https://twitter.com/John_Grib/status/1778256977317294256

 

 

 

Pull Request로 협업하는 또 다른 방식, Stacked Diffs(PR)

• 기존 PR 및 코드리뷰 방식의 문제점
  • PR에 대한 코드리뷰는 오랜 시간이 걸릴 수 있으므로 다음 작업을 이어서 하는 데 어려움이 생길 수 있음
  • mian 브랜치에서 브랜치를 만들어서 작업할 수도 있지만, 보통은 앞의 PR에서 이어서 작업해야 하기 때문임
  • 코드 리뷰가 잘 되기 위해서는 변경사항을 작게 만드는 것이 좋기 때문에 이런 경우는 PR이 계속 이어짐
• Stacked PR 이란
  • 각 PR이 이어져서 쌓이는(stacked) 방식으로 Facebook에서 많이 사용
  • 다소 거창하게 말한 것 같지만, 비슷한 맥락의 작업이라면 PR을 생성할 때 매번 현재 Feature Branch를 기준으로 생성하는 것임
  • Stacked PR이 간단해 보이지만 첫번째 PR이 수정이 되거나 하면 다른 PR들도 리베이스를 해주어기 하므로 손이 많이 가는데, 이를 해결하게 해주는 Graphite 등의 도구들도 함께 사용할 수 있음

 

출처:

https://careerly.co.kr/comments/103008

https://sungjk.github.io/2024/03/17/stacked-diffs.html

 

 

 

레딧의 아키텍처: 진화하는 여정

(Upgrade to paid Reddit's Architecture: The Evolutionary Journey)

• 초기의 레딧
  • Reddit은 원래 Lisp로 작성되었지만 테스트된 라이브러리 부족으로, 2005년 12월에 Python으로 재작성됨
  • 처음에는 web.py라는 웹 프레임워크를 사용했고, 2009년 후반에 Pylons를 사용하기 시작했음
• 레딧의 핵심 아키텍처
  • CDN: CDN은 도메인과 경로를 기반으로 특정 요청이 라우팅되는 방식을 파악하기 위해 엣지에서 많은 의사 결정 로직을 처리함
  • FE-App: jQuery에서 타입스크립트를 사용하여 UI를 재설계하기 시작했고, Node.js 기반 프레임워크로 전환했음
  • R2 모놀리스: Python 기반 최초의 모놀리식 애플리케이션으로, 검색 등과 같은 기능으로 구성됨
  • AWS: 2009년에 마지막 물리적 서버를 폐기하고 전체 웹사이트를 AWS로 이전함, 꽤 오랫동안 썸네일 호스팅과 로그 저장에 S3를 사용하고 있었음
• R2 Deep Dive
  • 확장성을 위해 동일한 애플리케이션 코드가 여러 서버에 배포되고 실행됨
  • 로드 밸런서는 맨 앞에 위치하여 요청을 적절한 서버 풀로 라우팅하는 작업을 수행함
  • 사용자 투표나 링크 제출과 같이 비용이 많이 드는 작업은 Rabbit MQ를 통해 비동기 작업 대기열로 연기됨
  • 핵심 데이터 모델을 위해 Postgres를 사용하고, DB 부하를 줄이기 위해 멤캐시 클러스터를 배치하고, 복원력과 가용성 특성으로 인해 새로운 기능에 Cassandra를 상당히 많이 사용함

 

 

출처: https://blog.bytebytego.com/p/reddits-architecture-the-evolutionary