Hacker News 의견

• 인프라 업그레이드와 동시에 발생한 사건에 대한 의견

  • VM에 추가 RAM 자원을 통한 인프라 업그레이드를 수행하는 동시에 사건이 발생한 것은 완전한 우연이었다고 함.
  • 이러한 "우연"은 자주 발생하며, 문제 해결 중에 자신의 존재를 의심하게 만든다고 언급.
  • 문제 해결 중에 패닉 상태가 되면, 다른 것을 망가뜨리는 핫픽스를 적용할 수 있으며, 이는 시스템 관리자와 개발자에게 잔인한 머피의 법칙이 될 수 있다고 경고.

• Kagi 상태 페이지에 대한 사용자의 경험

  • 사용자는 Kagi의 상태 페이지가 모든 것이 정상적으로 작동하는 것으로 표시되어 있어서 불안감을 느꼈다고 함.
  • 과거에 의존했던 서비스들은 상태 페이지를 즉시 업데이트하여 문제가 자신의 장치에 있는 것이 아니라는 것을 알 수 있었다고 비교.
  • Kagi를 계속 사용할 계획이지만, 사후 분석에서 언급한 것처럼 상태 페이지 코드를 다른 서비스/플랫폼으로 이동할 것을 희망한다고 언급.

• 개인적인 경험을 공유하는 댓글

  • 개인적으로 동일한 유형의 서비스 중단을 여러 번 경험했으며, 데이터베이스 연결 풀의 건강 상태에 대한 문제를 해결하려고 시도했다고 공유.
  • 데이터베이스의 일반적인 포화 지표(CPU%, IOPS 등)는 이러한 중단 동안 크게 변하지 않으며, 대신 락 경합이 문제의 원인일 수 있다고 지적.
  • Kagi가 사용하는 RDBMS에 대한 권장 사항으로, 글로벌 I/O 대기 시간, 락 획득 시간, 쿼리 실행 시간 등을 그래프로 나타내는 것이 좋다고 제안.

• 스타트업의 경험에 대한 댓글

  • 모든 스타트업이 어느 시점에서 이러한 문제를 겪게 된다고 언급.
  • 문제를 막을 수 있는 능력을 구축하기에 충분한 시간이나 자원이 없을 수도 있으며, 특정 문제가 발생할 것이라고 생각하지 못했을 수도 있다고 함.
  • 투명성과 학습이 중요하지만, 때로는 보상도 중요하다고 언급하며, Kagi가 서비스를 사용할 수 없었던 시간에 대한 검색 크레딧을 제공하는 것을 고려해야 한다고 제안.

• 내부 시스템에 대한 관찰 가능성에 대한 댓글

  • 문제를 더 빨리 인식해야 했다고 지적하며, 올바른 데이터독 대시보드와 스플렁크 쿼리가 문제를 훨씬 더 빨리 명확하게 해야 한다고 언급.
  • 더 나은 모니터링에 투자하여 학습 경험으로 삼아야 한다고 조언.

• Kagi의 신뢰성에 대한 유료 사용자의 의견

  • Kagi의 다운타임을 경험한 유료 사용자는 Google의 신뢰성을 당연하게 여겼다는 것을 깨달았다고 함.
  • 검색 엔진에 대한 접근이 중단되는 것은 큰 장애가 될 수 있다고 언급하며, Kagi를 사랑하지만 다운타임을 경험하는 것은 불쾌했다고 공유.
  • 이 경험이 Kagi를 더욱 강력하고 신뢰할 수 있는 서비스로 만들기를 희망한다고 언급.

• 서비스 중단을 초래한 스크래퍼에 대한 댓글

  • 한 사용자가 실행한 스크래퍼로 인해 서비스가 7시간 동안 중단되었다는 사실에 대해, 테스트 중에 "많은 검색이 발생하면 어떻게 될까?"라는 질문을 하지 않았는지 의문을 제기.

• Kagi 사용 경험과 사후 분석에 대한 댓글

  • 몇 주 동안 Kagi를 사용한 후, 지난주에 즉시 로드되지 않았을 때 무엇을 해야 할지 몰랐다고 공유.
  • 사후 분석이 나오기 전에 이미 사건을 잊어버렸다고 언급하며, 검색할 때 생각할 필요가 없는 팀에게 감사를 표함.

• GCP에서 사용한 단일 코어 데이터베이스에 대한 댓글

  • Kagi가 GCP에서 사용 가능한 가장 저렴한 단일 코어 데이터베이스를 사용해왔다는 사실에 대해 긍정적인 반응을 보임.
  • 읽기 부하의 급격한 증가를 처리하고 성능을 더 끌어올릴 수 있는 PolyScale과 같은 것을 고려해볼 것을 제안.

• 자동화된 스크래핑에 대한 댓글

  • 계정을 차단한 후 연락을 취한 사용자가 결과를 자동으로 스크래핑하는 데 계정을 사용했다고 주장했다고 언급.
  • 모든 들어오는 RPC / API / HTTP 요청, 특히 공개적인 것들에 대해 QPS(초당 쿼리 수) 제한을 설정할 것을 권장.