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

 

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

---

Kubernetes Is Great On-premise(쿠버네티스는 온프레미스에 적합하다) 

• 쿠버네티스는 온프레미스 데이터 센터용 도구에서 탄생했음
• 쿠버네티스는 Google의 Borg와 Omega의 아이디어에서 탄생함
• 쿠버네티스가 온프레미스에서 유용한 이유
  • Fault Tolerance(결함 발생 시에 다른 서버로 이전)
  • Density(리소스 사용률 최적화)
• 쿠버네티스가 온프레미스에서 갖는 한계
  • 확장 기능이 제한적(클러스터에서 최대 5000개 노드까지만 확장 가능)
  • 쿠버네티스 API는 복잡하고 서버에 있는 것을 관리하기 위해 다른 도구(Terraform, ansinble 등)를 배워야 함

 

 

출처: https://codeengineered.com/blog/2024/k8s-great-on-prem/?fbclid=IwAR1-KbEjeFNivrE9pONmoW0po16V0hviUXvxkee425yOgS_JpSz-qa4DEBw

 

 

 

잘못 설계된 자바 equals 메서드 설계 예시(java.net.URL)

java.net.URL 객체를 비교하면 같은 IP 주소로 해석될 때는 true, 아닐 때는 false가 나온다. 문제는 이 결과가 네트워크 상태에 따라 달라진다는 것이다.

• 동작이 일관되지 않다. 네트워크가 정상이면 두 URL이 같고 문제가 있으면 다르다. 주어진 호스트의 IP 주소는 시간과 네트워크 상황에 따라 다르다. 어떤 네트워크에선 두 URL이 같을 수 있지만 다른 네트워크에선 다를 수 있다.
• 일반적으로 equals, hashCode 처리는 빠를 거라 예상하지만 네트워크 처리는 느리다. URL이 어떤 리스트 내부에 있는지 확인하는 경우, 이런 작업을 할 때 각 요소(URL)에 대해 네트워크 호출이 필요할 것이다. 따라서 예상되는 속도보다 느리게 동작한다. 안드로이드 같은 일부 플랫폼에선 메인 쓰레드에서 네트워크 작업이 금지된다. 이런 환경에선 URL을 Set에 추가하는 기본 조작도 쓰레드를 나눠서 해야 한다
• 동작 자체에 문제가 있다. 같은 IP 주소를 갖는다고 같은 컨텐츠를 나타내는 건 아니다. 가상 호스팅을 한다면 관련 없는 사이트가 같은 IP 주소를 공유할 수도 있다.

 

출처: 이펙티브 코틀린

 

 

 

 

GitHub, Slack, Salesforce 등 10개 이상의 서비스 장애 보고서를 분석하여 도출된 5가지 주요 교훈

• 순환 의존성의 덫
  • 서비스 인프라는 서로 얽혀 있는 경우가 많음
  • 장애 복구 툴도 이러한 인프라에 의존할 때가 있는데, 이 경우 장애 복구 툴이 작동하지 않을 수 있음
• 자동화의 배신
  • 인프라 관리의 자동화는 효율적인 운영을 위해 중요한 역할을 하지만, 장애 시 상황을 악화시킬 수도 있음
  • 자동화 스크립트를 신중하게 작성하고, 장애 시 자동화를 긴급 중단할 수 있는 기능을 마련해보는 것이 좋음
• 항상 디비가 문제다
  • 많은 장애의 원인은 데이터베이스였음, 비싼 쿼리가 주는 부하를 버티지 못하고 쓰러지는 경우가 많았음
  • 데이터베이스 as a service의 비용에는 운영 및 장애 대응 비용이 포함되어 있으므로 가능하면 사용하는 것이 운영에 유리함
  • 데이터베이스 장애에 대비하여 데이터베이스 복원 작업을 정기적으로 테스트해야 함
• 배포는 조금씩 천천히
  • 서비스 안정화와 빠른 배포는 결국 맞바꿔야 함
  • 대부분의 서비스 장애는 변경된 코드나 환경 설정이 별다른 검증 없이 모든 프로덕션 서비스에 빠르게 배포될 때 발생했음
  • 서비스가 요구하는 안정성에 따라 canary, gradual rollout 등 배포 속도에 브레이크를 조금 거는 매커니즘이 필요함
• 장애 대응 플레이북
  • 서비스 장애 시뮬레이션을 하고 복구 우선순위를 미리 정하는 등 매뉴얼을 작성하고, 장애 시 panic mode/code red가 발동해 자동화를 정지시키는 인프라 투자는 (당연하게도) 더 좋은 장애 대응으로 이어짐
  • 서비스 장애는 결코 좋은 순간은 아니지만, 필연적이므로, 불현실적인 100% 업타임을 기대하기 보다는 미리 장예를 예상하고, 예방하고, 장애 발생 시 신속하게 복구할 수 있는 체계를 마련해야 함

 

출처: https://www.linkedin.com/posts/danielylee_대규모-서비스를-개발-조직들이-공개적으로-발표한-서비스-부검-보고는-세계적인-activity-7164679513895895040-vmtf?utm_source=share&utm_medium=member_desktop

 

 

 

LinkedIn의 400만 TPS 대용량 프로필 조회 API 처리 일지

1. 초기에는 모든 데이터를 Oracle Database에 저장하고 Memcached를 활용해 캐시 레이어를 구축했음
2. 서비스 규모가 커짐에 따라 Oracle Database의 라이선스 비용, 확장성 제한, 유지보수 어려움 등의 단점이 드러났고, Memcached 클러스터 역시 투자 대비 성능이 만족스럽지 못했음
3. 2010년 초, 당시 유행하던 NoSQL 흐름에 따라 Expresso NoSQL Database를 자체 개발하여 사용했고, 별도의 캐싱 레이어 없이도 범위성과 성능 요구 사항을 모두 충족시킬 수 있었음
4. 하지만 프로필 조회 횟수가 초당 100만 번을 넘어설때 쯤 또다시 성능 문제가 발생하기 시작했고, 다시 한 번 캐시 레이어 도입을 고려했음
5. 이미 여러 서비스에서 Couchbase를 사용하여 성능을 개선한 성공 사례를 가지고 있었고, Expresso에 Couchbase 기반 캐싱 레이어를 포함하는 시스템 설계에 도전했음
6. 기존 시스템에 내포된 커스텀 캐싱 솔루션으로 인해 여러 어려움을 겪었음. Couchbase 시스템의 효과적인 모니터링, 무효한 캐시 데이터 제거를 위한 System Change Number (SCN) 저장 등 시스템에 많은 새로운 요소들이 필요했음
7. Expresso와 Couchbase를 함께 사용한 결과, 프로필 조회 서비스는 99백분위수 기준 성능이 60% 이상 개선되었으며, 99% 이상의 캐시 히트 비율 덕분에 전체 서비스 비용이 10% 절감되었음

 

출처: https://www.linkedin.com/posts/danielylee_지금-사용하고-계신-linkedin에서는-약-10억-명에-가까운-사용자-프로필이-activity-7165878143772209152-YLgw?utm_source=share&utm_medium=member_desktop

 

 

 

백악관, 'C'와 'C++' 사용 중단 촉구

• 바이든 행정부가 버퍼 오버플로 및 기타 메모리 액세스 취약성을 유발하는 프로그래밍 언어에서 벗어날 것을 촉구했음
• 마이크소프트와 구글의 최근 연구에 따르면 전체 보안 취약점의 약 70%가 메모리 안전 문제로 인해 발생하는 것으로 나타났음
• 메모리 안전 취약점이 있는 프로그래밍 언어의 두 가지 예로 C와 C++를 제시했고, 안전하다고 판단되는 프로그래밍 언어의 예로는 러스트를 언급했음
• 사이버 보안의 책임을 개인과 소규모 기업에서 "끊임없이 진화하는 위협을 관리할 능력이 있는" 대기업, 기술 기업, 미국 정부로 전환하자는 목표임

출처: https://www.ciokorea.com/news/327256