GN⁺: 당신이 가진 시스템을 최대한 활용하라

• 글은 저자가 SaaS 애플리케이션에서 Postgres 성능을 관리하는 경험에 대해 논의하며, 데이터베이스가 부하를 감당하는 데 어려움을 겪었다.
• 저자의 팀은 데이터베이스가 너무 바쁠 때마다 더 큰 인스턴스로 교체하여 수직으로 확장하였다. 그러나 이미 가장 큰 인스턴스를 사용하고 있어 과부하 상태에 처할 지경에 이르렀다.
• 독립적인 데이터베이스 클러스터에 쓰기를 샤딩하는 것과, 모놀리스를 여러 연결된 서비스(마이크로서비스)로 분할하는 두 가지 가능한 해결책이 제안되었다.
• 두 해결책 모두 용량을 늘리고 장애 허용성 및 운영 복원력에 대한 흥미로운 옵션을 제공하지만, 복잡성을 크게 늘릴 것이다.
• 저자는 복잡성 증가의 실제 비용이 주의력이라고 주장하며, 이는 모든 후속 기술 결정을 복잡하게 만든다.
• 저자는 복잡성을 크게 늘리기 전에 일반적으로 작업량을 조정하거나 성능을 튜닝하거나 시스템을 어떤 방식으로 보완함으로써 기존 시스템에서 약간의 추가 성능을 "짜내는" 기회가 있다고 제안한다.
• 그들의 경우, 무거운 쿼리를 최적화하고 Postgres 설정을 튜닝하며, 일부 비용이 많이 드는 읽기 전용 쿼리를 복제 DB로 오프로드함으로써 데이터베이스의 최대 주간 CPU 사용량을 90%에서 30%로 줄였다.
• 저자는 복잡성이 필요하고 불가피하다는 점을 결론지었지만, 가능한 한 오랫동안 복잡성 증가를 미루고 먼저 기존 시스템에서 최대한 많은 성능을 짜내는 것이 바람직하다고 결론지었다.

[neo]

Hacker News 의견

• 기사는 현재 시스템의 잠재력을 극대화하는 것의 중요성을 강조하며, 교체나 업그레이드를 고려하기 전에 이를 강조한다.
• 팀들이 완벽하지 않더라도 현재 가지고 있는 것을 활용하고, 기존 자원으로 목표를 달성하는 방법을 찾아야 한다고 제안한다.
• 데이터베이스에서 조인을 사용하지 않도록 애플리케이션을 설계하는 아이디어에 대해 논의하며, 저장 공간은 저렴하고 모든 것이 비정규화되어 트랜잭션에서 업데이트되어야 한다고 제안한다.
• 핫 파티션을 방지하기 위해 UUID를 사용하는 것이 제안되며, 결국 실패할 수 있는 정수에 의존하는 대신 수평으로 확장될 수 있다.
• 한 팀이 하드웨어나 복잡성을 더 추가하는 대신 문제 해결 방식을 바꿈으로써 시스템 성능을 크게 향상시킨 성공 사례를 공유한다.
• 기사는 한 번에 모놀리스를 여러 연결된 서비스로 분할하는 것을 반대하며, 대신 가장 큰 영향을 미칠 분할을 식별하는 것을 제안한다.
• ORM 위에 구축된 웹 앱에서 쿼리를 최적화하는 것의 중요성을 강조하며, 종종 개선할 여지가 많다.
• 마이크로 서비스 시스템에서 작업하는 데 있어서의 정신적 부담과 복잡성에 대해 경고하며, 이들은 종종 다운타임과 혼란을 초래한다고 제안한다.
• 효율성(손실 최소화 및 복잡성 피하기)과 최적화(복잡성 추가 비용으로 전문 알고리즘 사용) 사이의 차이를 구분한다.
• 더 복잡한 인프라로의 이전에 대한 우려를 공유하며, 이것이 모두가 기대하는 만능 해결책이 아닐 수 있다고 제안한다.
• 특히 자원이 제한적이고 시스템이 매우 중요하지 않은 경우, 복잡성보다 단순성을 지지한다.
• 마지막으로, 기사는 테넌트(고객)별 샤딩을 확장성 문제에 대한 잠재적인 해결책으로 논의한다.