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

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

---

CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기

• “쿠키런: 킹덤”은 메인 데이터베이스로 CockroachDB를 사용하는데, 전통적인 RDBMS처럼 ACID 특성을 가지고 있으며, SQL 기반의 트랜잭션 처리가 완벽하게 작동하는 분산 데이터베이스임
• CockroachDB 클러스터는 기본적으로 Raft 기반의 합의 알고리즘을 사용하고, 가장 높은 수준의 트랜잭션 일관성을 목표로 설정되어 있음
• DB 스케일업 작업 전에 안전장치를 설정하기 위한 작업을 하던 중 의도치 않은 설정 이슈로 인해 절반 이상의 노드들이 비일관성을 탐지하고 에러가 발생하면서 클러스터에서 제외되기 시작하여 다운되었음
• CockroachDB 엔지니어 팀은 진단을 완려하고 난 후 복구가 불가능하다는 결론을 내렸음. 마지막 백업본으로 데이터베이스를 복구하고 서비스를 재개하는 것을 추천했음
• 하지만 “쿠키런: 킹덤”은 Snapshot과 Journal을 사용해 데이터를 커밋 하는 Event Sourcing 기반의 아키텍처를 사용했고, 복구가 가능하다고 판단하여 내부를 뜯어가며 복구에 성공했음

출처: https://tech.devsisters.com/posts/bit-level-database-hacking/

 

 

 

JetBrains IDE의 전체 줄 코드 완성 신규 기능 추가

• JetBrains IDE는 AI 기반이며 로컬에서 처리되는 전체 줄 코드 완성 기능을 2024.1 버전에 추가했음
• AI Assistant와 마찬가지로 모두 작업 속도를 높이는 데 목표를 두고 있음
• 해당 기능은 IDE 버전을 올리고, 설정 화면에서 on 시킬 수 있음
• 참고로 해당 기능은 인터넷 통신을 사용하지 않으며, 학습을 위한 데이터로 수집되지 않아 안전함

 

 

 

출처: https://blog.jetbrains.com/ko/blog/2024/04/05/full-line-code-completion-in-jetbrains-ides-all-you-need-to-know/

 

 

 

 

JPA가 아닌 JOOQ를 활용한 경험

JOOQ(쥬크)는 DB 접근 기술 중 하나로, JPA 대신 선택할 수 있는 도구임

• JOOQ의 장점
  • 낮은 학습 곡선(N+1 문제, 영속성 컨텍스트, 프록시 등을 고려하지 않아도 됨)
  • BULK INSERT, FROM 절 서브쿼리, 옵티마이저 & 인덱스 힌트 모두 JOOQ에서 사용 가능함
  • "상용 DB에서 돈을 받아서 오픈소스DB에는 오픈소스를 유지할 수 있게 한다."는 철학으로 지속 관리됨
• JOOQ의 단점
  • JOOQ는 컴파일 타임 code-generation 도구라서 초기 세팅에 비용이 많이 들음
  • 상업용 DB에서 쓰려면 돈을 내야함

 

출처: https://sightstudio.tistory.com/73

 

 

 

localhost의 동작 원리

• localhost는 부팅과 동시에 os의 기본 로컬 라우팅 테이블에 등록되며, Loopback NI(네트워크 인터페이스)를 통해 네트워크 계층을 거치지 않음
• 네트워크 통신을 위해서는 wifi, lan card와 같은 장비들이 필요한데, OS가 이를 인지하고 NI를 생성함. 이를 통해 OS는 어떤 NI로 데이터를 보낼지 IP 주소를 바탕으로 판단함( 네트워크 라우팅 테이블 )
  • 192.168.0.0/16 대역으로 나가려면 NI2 번
  • 127.0.0.0/8 대역으로 나가려면 NI0 번
  • 0.0.0.0/0 그외 모든 대역은 NI1 번
• 이를 통해 로컬 네트워크와 인터넷을 구분 할 수도 있고, 여러가지 조합이 가능한데, localhost를 위해 Loopback NI가 존재함(위 예시의 N10)
• Loopback NI는 모든 PC에 OS만 설치하면 기본으로 제공 하는 가상의 장치로, WIFI나 LAN 없어도 존재하며, IP주소 중 127.0.0.0/8 범위의 요청을 담당
• localhost에 대한 전체적인 패킷의 흐름을 살펴보면 다음과 같음
  • 브라우저에서 localhost 앱으로 데이터 전송을 시도하면, TCP/IP 스택을 통해 패킷으로 나가려고 시도함
  • TCP/IP 스택에서 IP주소를 보고 루프백 NI로 감
  • 목적지 주소 127.0.0.1을 확인했으니, 패킷을 외부로 보내지 않고 로컬로 다시 보냄
  • 패킷은 다시 TCP/IP 스택 계층으로 전달되고, 로컬의 올바른 포트로 전달됨
  • 앱은 이 요청을 수신하고, 적절한 응답을 생성하여 다시 루프백 인터페이스로 보냄
  • 응답 패킷도 동일한 과정을 거쳐 결국, 최종적으로 요청을 시작했던 브라우저로 전달됨

 

출처: https://velog.io/@480/localhost-의-동작-원리