성능
이라는 개념을 공부하기 전에, 왜 이 개념과 관련 도구들이 필요하게 되었는지 궁금했다.
나는 아직 사용자 1000만 명 이상의 대규모 서비스를 개발한 경험이 없지만, 지금까지의 경험을 바탕으로 생각해보면 다음과 같다.
서비스 사용자가 증가할수록 트래픽 양도 함께 늘어나며, 서버가 이를 감당할 수 있는지 성능 테스트를 통해 확인하고 그에 맞게 대응하고 보완해야 한다.
성능 테스트는 다양한 상황에서 시스템의 안정성과 효율성을 확인하는 데 중요한 역할을 한다. 내가 생각하는 성능 테스트의 활용 사례는 다음과 같다:
서비스를 출시하기 전, 예상되는 트래픽의 양을 서버가 감당할 수 있는지 성능 테스트로 파악한다. 일반적으로 예상 사용자 수의 3배로 부하 테스트를 수행해 예기치 않은 트래픽 급증에도 대비할 수 있도록 한다.
기존 서비스를 운영하면서 선착순 이벤트 등으로 갑자기 트래픽이 몰릴 때 발생하는 병목 지점을 성능 테스트(예: 스파이크 테스트)를 통해 식별한다.
멀티스레드 환경에서 비즈니스 로직을 비동기 방식으로 처리할 때, 논블로킹 방식 등을 고려하여 성능을 개선하기 위해 응답 속도와 TPS(초당 트랜잭션 수)를 성능 테스트로 측정한다.
아래는 최근 내가 공부한 성능 개념과 주요 병목 지점, 그리고 성능 테스트에 대한 내용을 정리한 내용이다.
최근 내가 하고 있는 일이 너무 많아서 머릿속이 복잡해졌다. 그래서 생각을 정리하고자 2024년 3분기 회고 글을 작성하게 되었다.
지금 내가 생활할 수 있는 기반을 제공하는 회사가 무엇보다 중요하다고 생각한다. 그만큼 회사에 대한 애정을 갖고, 주어진 기간 안에 업무를 집중하여 정확하게 처리해야 한다고 믿고 있다.
최근에는 코드와 설계에 관심을 갖고, 관련 기술들을 공식문서/책/영상 등으로 공부하고, 예제를 만들어서 실험을 해본 뒤에 적용하는 식으로 진행하고 있다.
또한 기존 서비스의 백엔드 코드를 리팩터링하면서 유지보수하기 쉽게 개선하고 있다. 최근 읽고 있는 좋은 코드, 나쁜 코드
와 이전에 읽은 내 코드가 그렇게 이상한가요?
가 많은 도움을 주었다.
리팩터링에는 정답이 없다고 생각하지만, 적어도 팀원이나 제3자가 이전보다 쉽게 이해할 수 있도록 만드는 것이 중요하다고 본다.
비록 지금 회사에서 오래 일하지는 않았지만, 주도적인 자세가 중요하다는 점을 많이 깨닫고 있다.
https://leetcode.com/problems/ransom-note/
주어진 ransomNote가 magazine의 글자를 이용하여 만들어질 수 있는지 확인하는 문제이다.
매거진에 있는 각 문자는 한 번만 사용할 수 있기 때문에
ransomNote의 각 문자를 magazine에서 충분히 가져올 수 있는지 검사하는 것이 핵심이다.
https://leetcode.com/problems/implement-queue-using-stacks/description/
두 개의 스택을 사용해 큐(FIFO)를 구현하는 문제였다.
스택의 기본 연산만 사용하여 큐를 구현하라는 것이다.
큐에서의 주요 연산인 push(), pop(), peek(), empty()를 구현해야 한다.
실제 운영 환경에서는 ddl-auto
설정을 validate
또는 none
으로 사용하는 것이 일반적입니다. validate
는 Hibernate가 엔티티와 데이터베이스 스키마 간의 일관성을 검증하지만, 스키마를 변경하지 않습니다. 반면, 현재 개발 환경에서는 update
로 설정하여 엔티티의 변경 사항을 자동으로 스키마에 반영하고 있습니다.
하지만 이 update
방식에는 치명적인 단점이 있습니다. 엔티티에 새로운 필드를 추가하면 해당 필드가 자동으로 스키마에 반영되지만, 기존 데이터는 이 필드에 값이 없으므로 NULL 값이 들어가게 됩니다. 이로 인해 데이터 무결성 문제가 발생할 수 있습니다. 또한, 외래 키나 제약 조건이 변경될 경우 참조 무결성이 깨져 운영 환경에서 심각한 데이터 손실 및 오류를 초래할 위험이 있습니다.
이러한 문제는 운영 환경에서 더욱 심각해집니다. 로컬 개발 환경이나 테스트 서버에서는 ddl-auto
설정을 create
, create-drop
, update
로 설정하여 엔티티 구조 변경 시 스키마를 자동으로 반영할 수 있지만, 프로덕션 환경에서는 이러한 설정을 사용할 수 없습니다. 프로덕션 서버에서 테이블을 DROP하는 것은 실제 사용자 데이터가 손실될 수 있기 때문에 불가능합니다.
기존 테이블에 새로운 컬럼을 추가하거나 수정할 때는 ALTER TABLE
명령어를 사용합니다. 또한, 새로운 필드에 초기값을 설정해야 하는 경우 데이터 마이그레이션 스크립트를 작성하여 기존 데이터를 새로운 스키마에 맞게 변환해야 합니다.
ALTER TABLE member ADD COLUMN cellphone VARCHAR(255) NOT NULL;
Flyway
와 같은 마이그레이션 도구를 활용해 이러한 문제를 해결하는 것이 효과적 입니다.