5P by neo 9달전 | favorite | 댓글 1개
  • Slack은 지난 1.5년간 중복성(Redundancy)을 늘리고 사이트 실패의 영향을 제한하기 위해 단일 구조에서 셀 기반 구조(Cellular Architecture)로 전환
  • 2021년 6월 네트워크 장애로 Slack 고객들에게 서비스 저하가 발생한 사건 이후 Slack 서비스의 복원력을 향상시키기 위한 필요성에 의해 주도
  • 셀룰러 구조는 각 서비스가 가용 영역(AZ)당 하나의 가상 서비스로 작동하게 해서 한 AZ에서의 실패가 다른 AZ에 영향을 미치지 않음
  • 문제가 있는 AZ에서 트래픽을 배수(Drain)하는 기능도 포함되어 있어, 이를 시스템의 나머지 부분에서 효과적으로 격리
  • 배수 메커니즘은 빠르고, 오류가 없으며, 점진적이고, 배수되는 AZ의 리소스에 독립적으로 설계
  • 셀룰러 구조로의 전환은 사일로잉(Siloing)이라는 전략을 포함, 서비스가 자신의 AZ 내에서만 트래픽을 수신하고 전송하도록 함. 이는 단일 AZ 내의 모든 실패를 포함시키는 데 도움이 됨
  • 트래픽 이동 메커니즘의 구현은 사용자의 쿼리를 핵심 서비스로 라우팅하는 시스템에 집중
  • 새로운 구조는 Envoy 기능인 가중치 클러스터와 RTDS를 통한 동적 가중치 할당을 활용하여 AZ 배수를 지원
  • 이 전환은 Slack의 운영 방식과 서비스 구축 방식을 변경하였으며, 트래픽 관리와 실패 완화에 대한 강력한 새로운 도구를 제공
  • 향후 블로그 게시물을 통해 기술 구현 세부사항에 대해 더 깊게 다루고 새로운 구조가 Slack의 운영에 어떤 영향을 미쳤는지 논의할 것
Hacker News 의견
  • Slack의 셀룰러 아키텍처로의 이전은 그들의 독특한 운영 및 모니터링 접근법 때문에 관심을 불러일으켰습니다.
  • 회사의 전략은 단일 AWS 가용성 영역(AZ)의 요청을 해결하고, 운영을 단순화하며 모니터링을 용이하게 하는 것입니다.
  • 이 접근법은 클러스터 간의 메트릭을 비교함으로써 단일 클러스터에서의 사건을 쉽게 탐지하고 완화할 수 있게 합니다.
  • 그러나, 이 전략은 대부분의 서비스가 여러 클러스터에서 실행되어야 하므로, 컴퓨트, 캐시 등에서 중복성이 발생합니다.
  • 일부 사용자들은 Slack의 API 요청 시스템의 효율성에 의문을 제기하며, 이는 서비스 백엔드로 수백 개의 RPC를 팬아웃할 수 있습니다.
  • AWS 가용성 영역 친화성을 사용하는 것과 상위 라우팅 지점에서 다운된 AZ를 단순히 드롭하는 것 사이의 차이에 대한 논쟁이 있습니다.
  • AWS USE1에서 모든 것을 실행하는 것의 중복성에 대한 우려가 제기되었으며, USE1과 관련된 문제가 여러 서비스에 영향을 미칠 수 있습니다.
  • 이 아키텍처에서 사용자 데이터가 어떻게 처리되는지, 특히 AZ 배수 시에 대해 의문이 제기되었습니다.
  • 일부 사용자들은 과거에 작업했던 유사한 아키텍처, 예를 들어 Metal Cell이라는 분산 운영 체제에 대해 회상합니다.
  • 새로운 사용자 요청이 도착하지 않더라도, 자원을 많이 사용하는 작업이 분리된 AZ에서 무한정 실행되는 가능성에 대한 문제에 대한 논의가 있습니다.
  • 사용자들은 현재 Slack이 어떤 프로그래밍 언어로 작성되었는지 궁금해하며, 여전히 Hack/PHP인지 묻습니다.
  • 일부 사용자들은 Slack의 성능에 대해 실망을 표현하며, 이를 Discord와 같은 다른 채팅 앱과 불리하게 비교합니다.