백엔드 개발의 성능 튜닝 시작

웹 서비스의 이용자가 늘어나면 반드시 직면하는 것이 「응답이 느린」「서버가 떨어진다」라고 하는 퍼포먼스 문제입니다. 프런트 엔드 최적화도 중요하지만 근본적인 데이터 처리를 담당하는 백엔드가 병목 현상이되는 경우는 적지 않습니다.

이 기사에서는 백엔드 성능 향상을 위해 처음으로 노력하는 엔지니어를 위해 실용적인 체크 포인트를 목록 형식으로 설명합니다.

퍼포먼스 튜닝은 암구름에 가도 효과가 나오지 않습니다. 우선은 다음 항목이 원인이 되어 있는지 확인합시다.

**N+1 문제가 발생하지 않았습니까? **
- O/R매퍼(ORM)를 사용하면 무의식적으로 발생하기 쉬운 것이 N+1 문제입니다. 리스트 데이터를 취득할 때, 관련하는 데이터를 1건씩 반복해 SQL을 발행하고 있지 않은지, 쿼리의 로그를 확인합시다.
** 색인이 제대로 붙여져 있습니까? **
- 데이터베이스 검색 속도에 가장 직결하는 것이 인덱스입니다. 검색 조건이나 정렬 조건에 자주 사용되는 열에는 적절한 인덱스(단일·복합)를 설정해 주세요.
** 캐시를 효과적으로 활용할 수 있습니까? **
- 자주 액세스되지만 드물게 업데이트되지 않는 데이터(마스터 데이터 등)는 Redis, Memcached 등을 사용하여 인메모리에 캐시함으로써 DB에 대한 부하를 극적으로 낮출 수 있습니다.
**외부 API에 대한 호출을 너무 기다리지 않았습니까? **
- 타사 API 또는 다른 마이크로서비스로의 통신이 동기화 처리가 되면 거기에서 처리가 차단됩니다. 가능하면 비동기 처리나 백그라운드 작업자에게 놓치는 설계를 고려해 봅시다.
** 메모리 누수가 발생하지 않았습니까? **
- 장기 실행 응용 프로그램에서 점차 성능이 저하되면 메모리 누수가 의심됩니다. 불필요한 객체에 대한 참조가 남아 있지 않거나 프로파일러를 사용하여 조사합니다.

튜닝에 있어서 제일 해서는 안 되는 것이 「추측으로 고치는 것」입니다. “여기가 느린 생각이 든다"라는 감은 종종 벗어납니다.

먼저 New Relic 및 Datadog와 같은 APM(Application Performance Monitoring) 도구를 도입하여 어떤 트랜잭션의 어떤 처리(SQL 실행 시간인지 외부 통신인지)에 시간이 걸리는지를 수치로 시각화합시다.

마지막으로 잊어서는 안되는 것은, 「모든 처리를 가장 빨리 할 필요는 없다」라고 하는 것입니다. 1일 1회만 실행되는 배치 처리의 몇 초를 깎기 위해 복잡한 캐쉬 기구를 넣는 것은, 메인터넌스 코스트의 관점에서 맞지 않는 경우가 많습니다.

사용자 체험에 직결하는 크리티컬한 엔드포인트를 파악하고 거기에 대해 집중적으로 리소스를 투하한다. 그것이 뛰어난 백엔드 엔지니어에게 첫걸음입니다. 매일의 개발로부터 「계측」을 의식해, 조금씩 개선을 거듭해 갑시다.