IT 관리 / 개발자 / 애플리케이션

확장형 시스템에서 성능을 저하시키는 9가지 문제

Andrew C. Oliver | InfoWorld 2017.07.31
복잡한 시스템을 기어 다니게 만드는 방법은 무궁무진하다. 그래서 다음의 9가지 문제를 해결하고 나면, 10번째 문제가 바로 등장하게 될 것이다.

규모가 있는 시스템을 조금이라도 구현해 본 경험이 있다면, 몇 가지 설계 문제가 다른 것들에 비해 훨씬 더 고약하다는 것을 알 것이다. 잘 짜인 코드를 작성하는 것과 시스템에 성능을 저하하는 설계 오류가 끼어들지 못하게 하는 것은 전혀 별개의 일이다.

다음은 시스템을 헛수고하게 만들거나, 등을 돌리게 만드는 9가지 흔한 문제, 실제로는 잘못된 설계 상의 선택이다. 하지만 다른 잘못된 의사결정들과는 달리, 이런 문제들은 되돌릴 수 있다.

1. N+1 쿼리
하나의 쿼리에서 어떤 고객의 모든 주문을 선택(SELECT)한다는 것은 주문에 대한 매 쿼리에서 개개 주문의 라인 항목(Line Item)을 선택하는 과정을 반복한다는 것으로, 이는 데이터베이스에 대한 n+1회의 방문을 의미한다. 외부 조인(Outer Join)을 사용한 단 한 번의 빅쿼리(Big Query)가 더 효율적일 것이다. 한 번에 더 적은 수를 끌어와야 한다면, 페이징의 한 형태를 사용할 수 있다.

자동으로 채워지는 캐시를 사용하는 개발자들은 실수로 n+1 문제를 작성하곤 한다. OEM(Oracle Enterprise Monitor) 같은 데이터베이스 감시 도구나 와일리 인트로스코프 같은 APM 도구를 사용하거나 단순한 쿼리 로그 작성으로 이런 상황을 알아낼 수 있다. CTE를 사용하는 대신에 플랫 테이블(Flat Table)에 저장된 트리를 탐색(Crawl)하려는 사람처럼 이 문제에 대한 더욱 악화된 버전도 있다. NoSQL 데이터베이스에서도 이 문제에 상응하는 버전이 있기 때문에 누구도 안전하지 않다.

2. 페이지 또는 레코드 잠금
필자는 DB2와 SQL 서버를 싫어했다. 지금도 이들의 기본 잠금 모델을 혐오한다. 플랫폼에 따라서, DB2는 업데이트를 위해 한 “페이지” 분의 레코드를 잠그는데, 본의 아니게 하려는 작업과 전혀 관련이 없는 레코드들을 잠그는 결과를 초래한다. 행 잠금(Row Lock)은 더 흔하다. 실제로는 다른 어떤 것에도 영향을 주지 않고 하나의 행에 대해 사소한 업데이트를 하고 있는 트랜잭션이 더 오랫동안 실행되고 있다. 다른 모든 쿼리들은 차단(Block)된다.

그러는 동안, 이런 트랜잭션들은 잠금도 더 오랫동안 유지하게 되어, 연속적인 성능 문제를 야기한다. 이 두 가지 데이터베이스 중 어느 한 가지를 사용하고 있다면, 스냅샷 격리(Snapshot Isolation)를 활성화하고 이를 반영한 설계를 하기 바란다. 오라클은 스냅샷 격리의 한 형태를 기본으로 사용하고 있다. 편집증 수준의 일관성을 목표로 구성할 수 있는 NoSQL 데이터베이스들도 존재한다. 사고가 발생하기 전에 해당 데이터베이스의 잠금 모델을 제대로 파악해 두는 것이 좋다.

3. 쓰레드 동기화(Thread synchronization)
이 문제에는 여러 가지 형태가 있다. 때로는 라이브러리에 숨겨져 있기도 하다. 몇 년 전 XML 파서(Parser)들은 모든 메소드(Method)를 동기화시키는 오래된 자바 “해시테이블(Hashtable)” 컬렉션을 사용하던 빈 활성화 프레임워크(Bean Activation Framework)라는 자바 라이브러리를 사용해서 마임(MIME) 타입을 검증하곤 했다. 이는 XML 파싱을 하는 모든 쓰레드가 결국에는 같은 위치에 큐(Queue)되어, 엄청난 동시성 병목현상을 야기하고 말았다.

쓰레드 덤프(Dump)를 읽음으로써 이 문제를 알아낼 수 있다. 최근 많은 개발자들이 쓰레드 작업을 대신 처리해주는 도구를 사용하는데 익숙해져 버렸다. 뭔가 제대로 동작하지 않을 때까지는 문제가 없다. 모두 동시성을 이해하고 있어야 한다.

4. 데이터베이스 시퀀스(Sequence)
단지 고유 ID가 필요할 뿐이라면, 시퀀스를 사용하지 말라. 개개의 ID가 예를 들면, 정말로 순차적일 필요가 있을 경우에만, 시퀀스를 사용하라. 시퀀스는 어떻게 구현되어 있을까? 쓰레드 잠금(Thread Lock). 모든 것이 해당 시퀀스 블록에 해당된다는 의미이다.

그 대안으로 시큐어랜덤(SecureRandom) 알고리즘을 사용하는 무작위로 생성된 UUID를 사용하라. 이론적으로는 중복된 ID를 얻을 수 있지만, 수조 개의 열을 생성한 다음에도 여전히 운석에 머리를 맞을 확률이 더 높다.

5. 커넥션 열기(Connection Open)
데이터베이스, HTTP 또는 무엇이건 그런 것들을 풀로 만들어라. 그리고 대형 시스템에서는 그것들을 갑자기 한번에 열려 하지 말라. 왜냐하면, 데이터베이스는 그러라고 설계된 것이 아니기 때문이다!

6. 스와핑(Swapping)
사용하고 싶어하는 것보다 더 많은 메모리가 필요하다. 어떤 형태건 스왑을 사용하고 있다면, 잘못된 것이다. 필자는 시스템이 소프트웨어를 조용히 죽이는 것보다는 차라리 다운돼서 멈추기를 바랐기 때문에 사용하는 리눅스에서 어떤 스왑도 활성화시키지 않았다.

7. 입출력(I/O) 동기화
대부분의 캐싱 소프트웨어는 데이터가 최소한 두 대의 기기 상에 있는 메모리에 씌어지고 디스크가 따라오기를 기다리는 대신 작업을 진행해 나가는 “나중 쓰기(Write Behind)”를 하기 위한 기능을 가지고 있다. 이는 읽기/쓰기 급증을 완화시켜 준다. 결국, 쓰기 처리속도가 충분히 빠르다면 나중 쓰기 캐시가 폭발하기 전에 따라잡기 위해서 쓰기를 차단해야만 할 것이다.

입출력 동기화는 다른 곳에서도 역시 존재한다. 로그 파일이나 뭔가를 유지해야 하는 모든 곳에서. 몇몇 소프트웨어는 여전히 fsync 함수를 많이 호출하는데, 이는 사용자가 자신의 확장성 있는 고급 분산 소프트웨어에 원하는 것이 아니다. 적어도 그다지 도움이 되지는 않는다.

8. 프로세스 생성(Spawning)
일부 소프트웨어 패키지는 특히, 유닉스 운영체제 상에서 여전히 각각의 프로세스가 단일 쓰레드를 가지고 있는 프로세스와 하위 프로세스를 중심으로 설계되어 있다. 사용자는 이런 프로세스들을 풀로 만들어서 재사용하거나 다른 조치를 취할 수 있지만 절대로 훌륭한 설계가 아니다.

각각의 프로세스와 자식 프로세스(Child Process)는 각자의 메모리 공간을 할당 받는다. 때로는 사용자가 공유 메모리라는 끔찍한 생각을 할당할 수 있다. 최신 소프트웨어는 여러 개의 쓰레드를 관리하는 프로세스를 가지고 있다. 이는 각각의 코어가 여러 개의 쓰레드를 동시에 처리할 수 있는 최신의 멀티코어 CPU에서 훨씬 더 잘 확장된다.

9. 네트워크 경합(Contention)
분산 파일시스템과 인메모리 컴퓨팅을 위한 스파크(Spark)가 모든 서버 노드들이 함께 작업하도록 만들어서 삶을 아주 즐겁게 만들어 줄 것이라고 하지 않았는가? 실제로는, NIC 카드와 스위치를 비롯해서 대역폭을 제한하고 있는 다른 것들을 여전히 가지고 있다. NIC을 본딩(Bonding)할 수 있으며, 스위치는 초당 특정 개수의 패킷으로 속도가 정해져 있다. 이는 예를 들면, 20개의 포트 모두에서 1Gbps를 전달하지 못하는 기가비트 스위치와는 다른 의미이다. 버스트(Burst) 모드로 데이터를 전달하고 있는 노드를 많이 가지고 있다는 것은 멋진 일이다. 그런데 이런 노드들이 각자의 NIC, 사용자의 실제 네트워크 대역폭 또는 스위치의 실제 가용 처리 속도에 대해 병목을 만들고 있지는 않은가?

바라건대, 코딩을 하고 시스템 아키텍처 일을 하고 있다면, 이런 함정들을 피하고 있다는 의미이다. 아니면, 예전에 잘 나가던 사람들 중 몇몇이 업계를 떠나서 술집을 열었다는 것을 명심하라.  editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.