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

 

 

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

---

How PayPal Serves 350 Billion Daily Requests with JunoDB

• PayPal의 JunoDB는 99.9999%의 가용성(99.9999%)을 갖는 데이터베이스임
• Juno DB란?
  • 분산 ke-value 저장소로, Go 언어의 동시성을 활용하여 수십만 개의 연결을 효율적으로 처리함
  • 매일 약 3,500억 건의 요청을 처리하며 로그인, 위험 관리, 거래 처리와 같은 중요한 기능을 담당함
  • 주로 주 데이터 소스 데이터베이스의 부하를 줄이기 위해 캐싱에 JunoDB를 사용함
• Juno DB의 주요 우선순위
  • Scalability
    • MSA 구조로 가면서 DB에 대한 연결 수가 증가하였고, 2가지 방식으로 이를 해결함
    • 클라이언트 연결이 한계에 도달하면 프록시를 추가하여 더 많은 연결을 지원(지연 시간과의 trade-off 영역)
    • 효율적인 데이터 크기와 처리르 위해 consistent-hashing 기반 파티셔닝을 지원함
  • Availability
    • 글로벌 결제 플랫폼의 중단을 막기 위해 복제 및 장애 조치 전략에 의존함
    • 클러스터 간 복제가 진행됨
    • 데이터 센터 간 복제는 서로 다른 데이터 센터에 있는 각 클러스터의 프록시 간에 데이터를 비동기적으로 복제하는 방식으로 구현
  • Performance
    • 한 자릿수 밀리초 단위의 응답 시간을 유지하면서 뛰어난 사용자 경험을 제공함
  • Security
    • 신뢰할 수 있는 결제 처리 업체로서, 전송 중인 데이터와 저장 중인 데이터를 모두 보호하도록 설계됨

 

출처: https://blog.bytebytego.com/p/how-paypal-serves-350-billion-daily

 

 

 

통합된 데이터 처리를 위한 오픈소스(Alloy)

• https://github.com/grafana/alloy
• 몇 주전 GrafanaCON에서 공개된 텔레메트리 데이터 통합도구
• 자체 기능 구현 보다는, (사실상 표준인) 프로메테우스와 오픈텔레메트리 플러그인들을 내장하여 제공하는 형태(그라파나의 ‘빅 텐트’ 전략?)
• 텔레메트리 데이터 전송을 위해 서버에 설치되는 프로그램을 알로이 하나로 통합(일부지만)
• 예를 들어 서버 메트릭 수집을 위해 node-exporter, prometheus(or OTel)을 설치했다면, Alloy 하나만 설치하고 Alloy에 내장된 exporter, prometheus 컴포넌트를 사용하는 방식

 

 

출처: https://www.facebook.com/groups/k8skr/permalink/3836500403298271

 

 

 

 

JPA에서 아이디를 자동증가 값으로 사용 시 하이버네이트의 @NaturalId 사용해 보기

• 일반적으로 auto_increment 되는 대체키를 id로 삼고, 기본키로 사용함
• 대체키로 운영하다 보면 운영 환경과 테스트 환경에서 ID가 불일치하는 문제가 발생함
• 이를 위해 자연키를 추가하고 해당 자연키로 데이터를 조회하면 운영과 개발 환경의 id 불일치 문제를 해결할 수 있음
• 하지만 그러면 한 트랜잭션 내에서 캐싱된 값을 가져올 수 없는데, 이를 위해 @NaturalId를 사용할 수 있음

 

출처: https://techblog.woowahan.com/17221/

 

 

 

개발자가 테스트를 보는 세 가지 관점

• TDD 개발 방법론에 관하여
  • TDD는 지금 짜야 할 코드가 정확하게 무엇인지를 규정하는 일에 가까움
  • TDD는 테스트 작성을 통해 ‘짜야 할 프로그램'이라는 문제 영역을 정확하고 체계적으로 구성해 나가는 개발 방식이라고 할 수 있음
  • 여기서 테스트는 전통적인 역할을 넘어서서 점진적인 설계를 하는 수단으로 쓰여 개발의 중심이 되기 때문에, ‘테스트 주도’라고 표현할 수 있는 것임
• 개발자가 테스트를 바라 보는 세 가지 관점
  • 자동화를 통한 효과적인 테스트에 초점을 맞추는 관점(자동화 테스트)
    • 자신의 작업 환경에 맞는 방법을 익히면 반복적인 수작업을 줄일 수 있어 생산성이 향상됨
    • 상대적으로 익히는 데 큰 어려움이 없고 투자한 만큼 효과를 바로 얻을 수 있음
    • 다만, 자동화 테스트를 하다 보면 프로그램을 테스트하기 어렵게 작성한 점을 발견할 수 있음
    • 테스트에 대한 새로운 인식이 생기면 두 번째 관점으로 제시한 내용에 공감할 가능성이 높음
  • 테스트를 넘어서 효과적인 개발 방법으로 확장한 관점 (일명 TDD)
    • TDD는 저에게 프로그래밍 영역을 벗어나서 응용할 수 있는 ‘시간을 극도로 효율적으로 쓰는 일’을 알려 줄 수 있음
    • 그리고 TDD는 충동적으로 하고 싶은 대로 프로그램을 짜거나 호기심에 이끌려 코드를 남발하던 습관을 이겨내고, 지금 당장 꼭 필요한 코드가 무엇인지부터 생각하고 정의하게 만드는 스펙 정의에 가까움
    • 결국 프로그래밍을 하기 전에 ‘정확하게 무엇을 짤 것인지' 생각하고 정교하게 기록하는 훈련은 문제 정의를 연습하는 탁월한 방법이 됨
  • 팀 입장에서 장기적 생산성과 변화에 대한 유연성 확보까지 고려한 관점
    • TDD를 개인 차원에서 익힌 사람이라면 팀 차원에서의 효과를 생각해 볼 수 있음
    • 켄트 벡은 자신의 글에서 테스트를 ‘통제력(controllability)을 유지하는 설계를 위한 도구’로 설명함
    • TDD를 경제성의 관점에서 해석한 것이로, 테스트를 소프트웨어 설계가 지향해야 하는 장기적 생산성 그리고 변화에 대한 유연성을 확보하기 위해 투자하는 활동으로 바라볼 수 있음
    • 테스트를 활용하여 설계의 목표를 달성하는 일은 결국 직업 일상에서 적절한 균형점을 잘 유지하는 일임을 보여 주는 듯함
• 정원 관리와 프로그래밍
  • 프로그래밍은 자신이 짠 코드를 다듬고 계속해서 잘 쓰이게 하는 정원 관리와 유사함
  • 정원 관리가 정원이 있는 집에 사는 대가로 치러야 하는 일상의 노력이듯이 코드를 장기적으로 사용하려면 매번 기능을 추가하는 일과 별개의 노력을 들여야 함(리팩터링)
  • 누적되는 코드에 대해 미래에 발생할 수정을 쉽게 하기 위해 쌓아두는 테스트를 회귀 테스트라고 부르는데, 그 효과는 굉장함

 

출처: https://yozm.wishket.com/magazine/detail/2068/

 

 

 

아키텍처 패턴에 대한 인식의 변화, 언제부터 도메인(모델)을 레이어로 구분했는가?

• 아키텍처 패턴의 진화
  • 스프링의 기원이되는 Expert One-on-One J2EE Design and Development을 보면 애플리케이션 아키텍처와 DB 레이어로만 구분함
  • 점차 DAO가 존재하는 계층이 데이터 액세스 레이어로 존재감이 드러나기 시작했고, 여기에 DB외의 외부 시스템과의 연결이나 서버 환경에서 존재하는 메인 비즈니스에 독립적인 코드를 몰아 넣으면서 인프라스트럭처 레이어라고 서서히 부르기 시작한 것으로 보임
  • 그러다 web(ui) - business(service) - data access(infra)의 3계층으로 서버가 분해되는게 자연스럽던 흐름에 언젠가에 도메인 모델 패턴을 따르는 오브젝트를 레이어로 슬쩍 끼어들기 시작한 것 같음
  • 2002년에 나온 PoEAA의 Service Layer 패턴 그림을 보면 아키텍처를 원형으로 그려놨는데, 서비스 계층 안에 도메인 모델이 나오고 그 안에 데이터 소스 계층이 나오고 중심에 DB가 나옴. 아직 도메인 (모델) 계층이라고 부르지는 않았음
  • DDD(2004) 책에서 MDD를 하려면 도메인을 레이어로 격리해야 한다고 하면서 도메인 레이어가 분리된 아키텍처를 확연하게 그렸음.
  • 그리고 역시 그 즈음에 도메인 레이어가 포함된 4 계층 레이어 아키텍처 이야기가 c2.com에서 있었고, 그 토론 과정에서 생각을 정리한 Cockburn이 헥사고날 아키텍처를 제안함(2005)
• 파생된 도메인 계층에 관하여
  • 하지만 여전히 J2EE쪽 특히 하이버네이트의 개빈 킹 등은 도메인 모델은 모든 계층에서 사용하는 전 계층에서 사용되는 개념이지 계층은 아니라는 구조를 계속 이야기 하고 있었음
  • Layered Architecture(POSA의 layers architectural pattern)의 원칙은 바로 아래 레이어에만 의존해야 한다는 원칙을 본 어떤 개발자들은 4 레이어 구조에서 애플리케이션(서비스) 레이어만이 도메인 레이어를 알아야 하며, 이걸 UI레이어로 올릴 때는 DTO로 바꿔서 보내야한다를 주장하기도 했음
  • OSIV 논쟁과 결합하면서 도메인 모델의 기능을 컨트롤러에서 사용하게 되면 어쩌냐면서도 계속해서 노쟁이 이어짐

 

출처: https://www.facebook.com/1070166746/posts/10227299635691229/?mibextid=oFDknk&rdid=nOKPBTWGEBwbEjsO

 

 

 

가상 스레드의 도입에 따른 Thread Local의 한계와 Scoped Value의 도입

• 가상 스레드의 도입에 따른 Thread Local의 한계
  • 단일 스레드에서 데이터를 공유하기 위해 ThreadLocal이 사용되었음
  • ThreadLocal은 제한된 수의 스레드 및 변경 가능한 데이터라는 점에서 효과적인 해결책이였음
  • 하지만 가상 스레드의 도입으로 몇 백만 개의 스레드가 존재할 수 있고, 가상 스레드마다 스레드 로컬이 복제되면 메모리 관점에서 비효율적임
  • 또한 이들은 변경 가능하다는 점에서 수 백만의 스레드가 존재하는 상황에서 디버깅을 어렵게 만듬
• Scoped Value를 통한 문제 해결
  • 자바는 1회 저장 가능하고 주어진 실행 기간 동안에만 조회할 수 있는 ScopedValue 라는 기술을 도입하고 있음
  • 이를 통해 안전하고 효과적으로 인자로 파라미터를 전달할 필요 없이 데이터를 공유하는 방법을 개선하고자 함
  • 해당 기능은 자바 22에서 Second Preview 기능이며, 조만간 정식 출시될 것으로 보임

 

출처: https://medium.com/@lavneesh.chandna/scoped-values-demystified-rethinking-threadlocal-in-the-age-of-virtualthread-43fc1a33f879