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

 

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

---

스티브잡스가 말하는 망해가는 조직의 특징

• 펩시에서 매출에 도움이 되는 사업팀과 마케팅팀 사람들이 승진하고 회사를 운영하게 되었음
• IBM이나 제록스에서도 비슷한 상황이 있었는데, 결국 개발팀은 의사 결정에서 배제되었음
• 그렇게 회사는 좋은 제품을 만드는 의미를 잃고, 시장에서 독점적인 지위를 결국 잃었음
• 그렇게 고객을 위하려는 마음이 없어지고 결국 시장의 일부가 되었음

 

출처: https://mania.kr/g2/bbs/board.php?bo_table=freetalk&wr_id=4898457

 

 

Elasticsearch 병렬 테스트를 향한 여정

• 스레드 락을 이용하기
  • 각각 다른 모듈에서 수행되는 테스트는 저마다 Gradle Test Executor를 사용함
  • 모듈 간의 테스트에서 결합으로 인해 사용할 수 없었음
• 분산락 활용하기
  • 여러 프로세스에서 공유하는 값을 RDB를 이용하기를 시도했음
  • 하지만 다음과 같은 문제가 발생하였음
    • ElasticsearchContainerExtension에 DB 관련 의존성이 추가됨
    • 인덱스 유무를 확인하는 과정에서 락을 얻고 반납하는 과정이 추가되어 동시 처리 성능이 저하됨
    • 여러 모듈에서 하나의 인덱스에 동시에 테스트를 진행할 때 인덱스 내 문서에 대해서도 격리가 필요함
• 네임스페이스 전략 이용하기
  • 테스트 프로세스마다 사용하는 인덱스를 따로 가지게 하는 방법
  • 한 번만 인덱스를 생성하고 여러 프로세스가 같은 인덱스를 공유하는 대신, 각각의 프로세스가 사용할 인덱스를 따로 생성하는 것
  • 네임스페이스 전략은 락을 사용하는 방법에 비해 다음과 같은 장점이 있음
    • ES 만으로 문제를 해결할 수 있음 (분산락을 위한 공유 의존성이 필요 없음)
    • 락을 점유하고 반납하는 오버헤드가 없음
    • 각 네임스페이스로 격리되어 인덱스에 대한 동시성 문제가 발생하지 않음

 

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

 

 

 

개밥먹기 : 제품의 성패를 가장 빨리 아는 방법

• 개밥먹기는 제품이 사용자 입장에서 어떤 효용을 주는지, 사용하는 과정에서 불편한 것은 없는지 경험하는 과정임
• 여기서 중요한 것은 실제 사용자의 관점에서, 제품을 사용하고 팬이 되는지를 보는 것임
• 해당 출처는 개밥을 만드는 회사에서, 맛있는 개밥을 만들기 위해 직접 개밥을 먹는 것에서 유래함

 

 

출처: https://qshop.ai/blog/team-qshop/개밥먹기-제품의-성패를-가장-빨리-아는-방법/

 

 

 

 

CLOSE_WAIT & TIME_WAIT 최종 분석

• CLOSE_WAIT로 인한 서버 행업 현상
  • 부하가 높으면 응답이 느려지는건 당연하지만, 테스트가 끝나도 행업 상태에서 복구되지 않았음
  • ESTABLISHED 한 개를 제외한 나머지 모두가 CLOSE_WAIT 상태였음
  • 서버가 먼저 FIN을 보내 클라이언트가 CLOSE_WAIT 상태에 빠질 수 있음
    • 서버가 close()를 먼저 호출하여 클라이언트가 CLOSE_WAIT으로 바뀜
    • 각각 양쪽의 서버/클라이언트를 실행하면 클라이언트가 CLOSE_WAIT 상태에 빠지고, 행업되어 있는 동안에는 이 상태가 사라지지 않음
  • 커널 옵션으로 타임아웃 조절이 가능한 FIN_WAIT이나 재사용이 가능한 TIME_WAIT과 달리, CLOSE_WAIT는 포트를 잡고 있는 프로세스의 종료 또는 네트워크 재시작 외에는 제거할 방법이 없음
• TIME_WAIT
  • TIME_WAIT 상태가 늘어나면 서버의 소켓이 고갈되어 커넥션 타임아웃이 발생한다고 함
  • TIME_WAIT은 TCP 상태의 가장 마지막 단계이며, Active Close(먼저 close()를 요청한 곳)에서 최종적으로 남게 되며, 2*MSL(Maximum Segment Lifetime)동안 유지됨
  • 이 단순한 과정이 매번 어렵게 느껴지는 이유는 대부분은 고급언어로 소켓을 랩핑해서 사용하기 때문임
  • 반드시 TIME_WAIT이 일정 시간 남아 있어서 패킷의 오동작을 막아야 함

 

 

출처: https://tech.kakao.com/posts/321

 

 

 

Java 21 Virtual Threads - Dude, Where’s My Lock?

• 문제 상황
  • 자바 21의 가상 스레드, 스프링 부트3, 톰캣으로 API를 제공하는 서비스에서 API 서빙을 멈춤
  • 모니터링 결과, closeWait 상태의 소켓이 영구적으로 증가하였음
• 문제 진단
  • 소켓이 closeWait 상태로 남았다는 것은 remote peer가 소켓 close를 했지만, local의 instance는 close에 실패했음을 의미함
  • 쓰레드 덤프 결과, 명확한 activity 없이 완벽하게 유휴 상태의 JVM으로 남아있었고, 이는 jstack으로 만들어진 쓰레드 덤프에서는 가상 스레드의 호출 스택이 남지 않았기 때문임
  • 이를 위해 jstack 대신 jcmd Thread.dump_to_file 명령어를 사영하였고, 다음과 같은 “blank” 형태로 남는 가상 스레드가 있음을 확인하였음 #119821 "" virtual
  • 내부적으로 톰캣 부분을 VirtualThreadExecutor로 전환했는데, Tomcat이 새롭게 들어오는 요청에 대해 가상 스래드 워크를 생성했지만 이를 마운트시킬 OS 쓰레드가 없었던 것임
• 왜 톰캣이 멈추었는가?
  • 내부의 synchronized 블록이나 메서드를 만나면 VT가 OS 스레드에 pinned 되는데, 이로 인한 문제였음
  • 톰캣은 새로운 소켓 요청을 accept하고, 가상 스레드 기반으로 요청을 생성하고, 요청 처리를 위해 executor로 request/thread를 전달함
  • 하지만 VT는 스케줄될 수 없는데, OS 쓰레드가 모두 pinned 되어 놓아지지 않기 때문임
  • 그리고 이는 내부의 ReentrantLockDeadlock 때문이였음

 

출처: https://netflixtechblog.com/java-21-virtual-threads-dude-wheres-my-lock-3052540e231d