2018.06.04

멀쩡한 코드가 프로덕션만 가면 느려지는 5가지 이유와 해결 방법

Andrew C. Oliver | InfoWorld
애정을 담아 공들여 만든 애플리케이션이 배치 이후 느리게 실행되고 있다면, 개발 장비에서는 잘 작동하던 코드가 프로덕션 환경에서는 완전히 망가지는 5가지 일반적인 이유가 있다.

물론 소프트웨어가 프로덕션 환경에서 잘 동작하지 않는 데는 다른 이유들도 있다. 하지만 개발자들이 “내 장비에서는 잘 동작했다”고 항변하다가 규모가 커지면 규모만큼이나 큰 책임이 따른다는 것을 뒤늦게 깨닫는 경우, 이 5가지가 필자가 본 가장 중요한 이유들이다.

Image Credit : GettyImagesBank

원인 1. 한 개의 커다란 쓰레드가 있다
Node.js 같은 일부 최신 프레임워크는 개발자 대신 쓰레드를 처리해준다. 작업을 처리하러 가기 위해 적절한 시점에 올바른 논블로킹(Nonblocking) 입출력 호출을 수행하고 코드의 주요 부분이 수많은 까다로운 작업을 처리하도록 하는 것은 개발자의 몫이다. 이렇게 하지 못하면, 시스템의 실제 쓰레드를 고갈될 수 있다.

이런 문제가 있다면, 몇 가지 의문을 가져야 한다. 가장 기본적인 의문은 Node.js에서 실행중인 어떤 자바스크립트 내부에서 주요 알고리즘을 수행하고 있는 경우, Node.js 그리고 자바스크립트가 여기서 사용하기에 적합한 기술인가? 반드시 사용해야 한다면, Node.js가 동시성(Concurrency)을 어떻게 처리하는지 그리고 이벤트 루프 차단(Blocking)을 회피하는 방법에 대해 공부해야 한다. 대신 워커풀(Workerpool)에 작업을 제출하는 방법을 배워야 한다. 더 나가서는 쓰레드에 대해 배워야만 할 수도 있다.

원인 2. 사용 중인 데이터베이스가 정말 XX같다
데이터베이스가 망가질 수 있는 이유는 아주 많다. 첫 번째 그리고 가장 명백한 이유는 인덱스 부재다. SQL 데이터베이스를 사용하는 경우, 인덱스 동작 원리를 알아야만 한다. 3개의 키/값 쌍(Key/Value Pair)이 있는 where 절이 있고 서로 다른 값을 사용해서 반복해서 그 절을 실행하고 있다면, 그것이 인덱스이다. 다음 예제는 3개의 인덱스를 가질 수 있다.

select … from customer c where c.firstname = :fname and c.lastname = :lname and c.state = :state

그리고 그런 데는 이유가 있을 것이다. 그렇지만, 이는 여전히 인덱스 병합을 야기한다. 3개의 검색을 병합해야만 한다는 의미이다. 그 대신 하나의 인덱스에 3개 필드 모두를 포함하는 인덱스를 생각해보자. 이 모든 것에는 위험 부담이 있다. 인덱스는 삽입과 업데이트 속도를 저하시키는 경향이 있다.

또 다른 흔한 이유는 스키마(Schema)의 총체적 설계 오류이다. 필자는 고객이 스키마를 마치 RDBMS용 스키마처럼 설계했던 대규모 몽고DB 프로젝트에 참여한 적이 있다.

몽고DB는 전화번호 검색 같은 단순한 작업을 하기 위해 테이블을 조인(Join)하도록 설계되지 않았기 때문에 아무 것도 적절하게 실행되지 않았다. 몽고DB는 그런 사항을 고객 문서(Document)에 속성으로 저장하도록 설계되었다. 스키마 설계가 잘못되면, 그런 스키마 상에서는 애플리케이션이 제대로 실행될 수 없다.

최신 애플리케이션에서는 개발자의 선호도가 데이터베이스 선정에 큰 영향을 미치지만, 모든 애플리케이션이 모든 유형의 데이터베이스에서 훌륭한 성능을 발휘하는 것은 아니다:

- 계층형 쿼리(Hierarchical Query)를 하고 있거나 두 행간의 관계를 찾으려 하는 경우, RDBMS를 사용해서는 안 된다.
- 기본적으로 키-밸류 스토어(Key-Value Store)에 대한 테이블을 재구현하고 있는 것이라면, 바로 멈춰라.
- 대부분이 FoaF(Friend-of-a-Friend: 웹을 사용하여 사람들 간의 정보를 연계하는 기술) 쿼리라면, 그래프(Graph)가 필요할 수 있다.
- Foo% 검색 같은 조건 필드명을 가진 쿼리를 많이 하고 있다면, 그 대신 (최소한 이 부분에 대해서는) 아파치 솔라(Solr) 같은 인덱스를 사용하라(맞다, 필자 회사의 제품이다).

덜 명백하기는 하지만 데이터베이스가 손상되는 또 다른 이유는 한 번에 너무 많은 접속을 열려 했기 때문이다. 예를 들어, 100개의 접속을 여는 하나의 데이터베이스 접속 풀을 로컬에 가지고 있는데, 각각 100개씩의 접속을 열고 있는 모두 15대의 애플리케이션 서버를 보유하고 있다면, 이는 한꺼번에 1,500개의 접속이 열려야만 한다는 것을 의미한다. 제대로 동작할 리가 없다. 한번에 조금씩만 처리해야 한다. 운영 팀 직원들은 이 사실과 주어진 시간에 애플리케이션 서버로 전달되는 트래픽 양을 제한하는 방법을 알고 있어야 한다(“핫”보다는 “웜” 기동 방법).

성능 문제가 데이터베이스인 경우, 데이터베이스 감시 도구를 사용하거나 쿼리 응답 시간을 로깅함으로써, 또는 데이터베이스가 그 모든 접속을 처리할 수 없었다고 말해준 DBA의 말을 경청함으로써 문제를 찾을 수 있을 것이다.

코드 작성 대상 데이터베이스 그리고 해당 데이터베이스가 좋아하는 스키마와 프랙티스를 파악하라. 작업에 어울리는 데이터베이스 또는 데이터베이스들을 선택하라.

원인 3. 메모리 크기를 제대로 조정하지 않았다
대부분의 최신 비즈니스 소프트웨어는 일종의 스택 기반 가상머신 상에서 실행된다. VM웨어나 도커가 아니라, JVM(Java Virtual Machine) 같은 것을 말하는 것이다. VM의 내부 작동에 대한 세부 설명은 넘어가고, 거의 모든 VM은 힙(Heap)이라 부르는 특정 양의 전용 메모리를 사용을 요구한다. VM들은 쓰레드를 실행할 때마다 다른 유형의 메모리도 사용한다. 힙 메모리가 부족하게 되면, 메모리 관리에 훨씬 더 많은 시간을 소비하게 되어, 애플리케이션 속도가 늦어진 것처럼 보이게 된다(마침내는 동작을 멈춘다).

JVM에서, 사용자는 가비지 컬렉션(Garbage-Collection) 로깅을 활성화할 수 있으며, 이는 몇 개의 컬렉션이 실행되고 있는지를 보여준다. 그저 힙 크기를 늘일 수도 있지만, 신중하게 해야 한다.

많은 사람들이 힙이 유일한 메모리 유형이라고 생각하고 있지만, JVM의 –xss 스택 크기 조절 옵션도 있다. 각 쓰레드는 특정 양의 스택 메모리를 할당 받는다. 만약,

System Memory – (heap + otherstuff + (numthreads * numstack)) i<= 0

인 경우 사용자가 또 다른 쓰레드를 가지려 하면, 특별한 종류의 메모리 부족 예외가 발생한다. 실행 중인 라이브러리 종류에 따라 확장되지 않는 쓰레드 풀(Thread Pool)이거나 확장되지 않는 접속 풀(Connection Pool)일 수 있다. 2가지 모두 속도저하처럼 보일 것이다. 좋은 소식은 이런 상황이 어떤 로그에서나 캡처된다는 것이다.

원인 4. 쓰레드 풀 또는 접속 풀의 크기를 잘못 설정했다
1,000명의 동시 사용자 그리고 풀에 5개의 데이터베이스 접속이 있다면, 해당 풀에 대한 대기 조건이 발생할 수 있다. 거기에 더해 100개의 HTTP 쓰레드와 TCP 백로그(TCP Backlog, 대기 접속 큐의 최대 길이) 설정 값이 5라면, 105명의 사람들이 접속을 시도한 다음에는 “접속 거부” 메시지를 보게 될 것이다. 그렇지만, 이에 앞서 속도가 매우 저하될 것이다. 게다가, 몇몇 소프트웨어는 “허용” 쓰레드 개수를 가지고 있으며, 이는 기본적으로 “전화를 받아서 그것을 다른 쓰레드 중 하나로 넘기는 것”이다. 대개는 1개 또는 어쩌면 2개의 쓰레드가 있다.

이런 숫자들이 무엇이 되어야 하는지에 대한 엄격한 규칙은 없지만, 비율에 대해서는 합리적이어야 한다. 다른 제약사항에 직면할 수도 있기 때문에 이렇게 할 때는 원인 3도 명심하라.

원인 5. 최대값(limits)과 파일 핸들 개수를 잘못 설정했다
대부분의 운영체제는 쓰레드 개수와 운영체제 사용자가 열 수 있는 파일 개수에 대한 한계가 있다. 이런 한도로 운영하는 경우, 망가지기에 앞서 속도가 떨어질 것이다. 이런 현상은 로그에서 볼 수 있으며, 어떤 파일 록(Lock)과 핸들이 사용 중인지를 보여주는 도구가 있다.  editor@itworld.co.kr


2018.06.04

멀쩡한 코드가 프로덕션만 가면 느려지는 5가지 이유와 해결 방법

Andrew C. Oliver | InfoWorld
애정을 담아 공들여 만든 애플리케이션이 배치 이후 느리게 실행되고 있다면, 개발 장비에서는 잘 작동하던 코드가 프로덕션 환경에서는 완전히 망가지는 5가지 일반적인 이유가 있다.

물론 소프트웨어가 프로덕션 환경에서 잘 동작하지 않는 데는 다른 이유들도 있다. 하지만 개발자들이 “내 장비에서는 잘 동작했다”고 항변하다가 규모가 커지면 규모만큼이나 큰 책임이 따른다는 것을 뒤늦게 깨닫는 경우, 이 5가지가 필자가 본 가장 중요한 이유들이다.

Image Credit : GettyImagesBank

원인 1. 한 개의 커다란 쓰레드가 있다
Node.js 같은 일부 최신 프레임워크는 개발자 대신 쓰레드를 처리해준다. 작업을 처리하러 가기 위해 적절한 시점에 올바른 논블로킹(Nonblocking) 입출력 호출을 수행하고 코드의 주요 부분이 수많은 까다로운 작업을 처리하도록 하는 것은 개발자의 몫이다. 이렇게 하지 못하면, 시스템의 실제 쓰레드를 고갈될 수 있다.

이런 문제가 있다면, 몇 가지 의문을 가져야 한다. 가장 기본적인 의문은 Node.js에서 실행중인 어떤 자바스크립트 내부에서 주요 알고리즘을 수행하고 있는 경우, Node.js 그리고 자바스크립트가 여기서 사용하기에 적합한 기술인가? 반드시 사용해야 한다면, Node.js가 동시성(Concurrency)을 어떻게 처리하는지 그리고 이벤트 루프 차단(Blocking)을 회피하는 방법에 대해 공부해야 한다. 대신 워커풀(Workerpool)에 작업을 제출하는 방법을 배워야 한다. 더 나가서는 쓰레드에 대해 배워야만 할 수도 있다.

원인 2. 사용 중인 데이터베이스가 정말 XX같다
데이터베이스가 망가질 수 있는 이유는 아주 많다. 첫 번째 그리고 가장 명백한 이유는 인덱스 부재다. SQL 데이터베이스를 사용하는 경우, 인덱스 동작 원리를 알아야만 한다. 3개의 키/값 쌍(Key/Value Pair)이 있는 where 절이 있고 서로 다른 값을 사용해서 반복해서 그 절을 실행하고 있다면, 그것이 인덱스이다. 다음 예제는 3개의 인덱스를 가질 수 있다.

select … from customer c where c.firstname = :fname and c.lastname = :lname and c.state = :state

그리고 그런 데는 이유가 있을 것이다. 그렇지만, 이는 여전히 인덱스 병합을 야기한다. 3개의 검색을 병합해야만 한다는 의미이다. 그 대신 하나의 인덱스에 3개 필드 모두를 포함하는 인덱스를 생각해보자. 이 모든 것에는 위험 부담이 있다. 인덱스는 삽입과 업데이트 속도를 저하시키는 경향이 있다.

또 다른 흔한 이유는 스키마(Schema)의 총체적 설계 오류이다. 필자는 고객이 스키마를 마치 RDBMS용 스키마처럼 설계했던 대규모 몽고DB 프로젝트에 참여한 적이 있다.

몽고DB는 전화번호 검색 같은 단순한 작업을 하기 위해 테이블을 조인(Join)하도록 설계되지 않았기 때문에 아무 것도 적절하게 실행되지 않았다. 몽고DB는 그런 사항을 고객 문서(Document)에 속성으로 저장하도록 설계되었다. 스키마 설계가 잘못되면, 그런 스키마 상에서는 애플리케이션이 제대로 실행될 수 없다.

최신 애플리케이션에서는 개발자의 선호도가 데이터베이스 선정에 큰 영향을 미치지만, 모든 애플리케이션이 모든 유형의 데이터베이스에서 훌륭한 성능을 발휘하는 것은 아니다:

- 계층형 쿼리(Hierarchical Query)를 하고 있거나 두 행간의 관계를 찾으려 하는 경우, RDBMS를 사용해서는 안 된다.
- 기본적으로 키-밸류 스토어(Key-Value Store)에 대한 테이블을 재구현하고 있는 것이라면, 바로 멈춰라.
- 대부분이 FoaF(Friend-of-a-Friend: 웹을 사용하여 사람들 간의 정보를 연계하는 기술) 쿼리라면, 그래프(Graph)가 필요할 수 있다.
- Foo% 검색 같은 조건 필드명을 가진 쿼리를 많이 하고 있다면, 그 대신 (최소한 이 부분에 대해서는) 아파치 솔라(Solr) 같은 인덱스를 사용하라(맞다, 필자 회사의 제품이다).

덜 명백하기는 하지만 데이터베이스가 손상되는 또 다른 이유는 한 번에 너무 많은 접속을 열려 했기 때문이다. 예를 들어, 100개의 접속을 여는 하나의 데이터베이스 접속 풀을 로컬에 가지고 있는데, 각각 100개씩의 접속을 열고 있는 모두 15대의 애플리케이션 서버를 보유하고 있다면, 이는 한꺼번에 1,500개의 접속이 열려야만 한다는 것을 의미한다. 제대로 동작할 리가 없다. 한번에 조금씩만 처리해야 한다. 운영 팀 직원들은 이 사실과 주어진 시간에 애플리케이션 서버로 전달되는 트래픽 양을 제한하는 방법을 알고 있어야 한다(“핫”보다는 “웜” 기동 방법).

성능 문제가 데이터베이스인 경우, 데이터베이스 감시 도구를 사용하거나 쿼리 응답 시간을 로깅함으로써, 또는 데이터베이스가 그 모든 접속을 처리할 수 없었다고 말해준 DBA의 말을 경청함으로써 문제를 찾을 수 있을 것이다.

코드 작성 대상 데이터베이스 그리고 해당 데이터베이스가 좋아하는 스키마와 프랙티스를 파악하라. 작업에 어울리는 데이터베이스 또는 데이터베이스들을 선택하라.

원인 3. 메모리 크기를 제대로 조정하지 않았다
대부분의 최신 비즈니스 소프트웨어는 일종의 스택 기반 가상머신 상에서 실행된다. VM웨어나 도커가 아니라, JVM(Java Virtual Machine) 같은 것을 말하는 것이다. VM의 내부 작동에 대한 세부 설명은 넘어가고, 거의 모든 VM은 힙(Heap)이라 부르는 특정 양의 전용 메모리를 사용을 요구한다. VM들은 쓰레드를 실행할 때마다 다른 유형의 메모리도 사용한다. 힙 메모리가 부족하게 되면, 메모리 관리에 훨씬 더 많은 시간을 소비하게 되어, 애플리케이션 속도가 늦어진 것처럼 보이게 된다(마침내는 동작을 멈춘다).

JVM에서, 사용자는 가비지 컬렉션(Garbage-Collection) 로깅을 활성화할 수 있으며, 이는 몇 개의 컬렉션이 실행되고 있는지를 보여준다. 그저 힙 크기를 늘일 수도 있지만, 신중하게 해야 한다.

많은 사람들이 힙이 유일한 메모리 유형이라고 생각하고 있지만, JVM의 –xss 스택 크기 조절 옵션도 있다. 각 쓰레드는 특정 양의 스택 메모리를 할당 받는다. 만약,

System Memory – (heap + otherstuff + (numthreads * numstack)) i<= 0

인 경우 사용자가 또 다른 쓰레드를 가지려 하면, 특별한 종류의 메모리 부족 예외가 발생한다. 실행 중인 라이브러리 종류에 따라 확장되지 않는 쓰레드 풀(Thread Pool)이거나 확장되지 않는 접속 풀(Connection Pool)일 수 있다. 2가지 모두 속도저하처럼 보일 것이다. 좋은 소식은 이런 상황이 어떤 로그에서나 캡처된다는 것이다.

원인 4. 쓰레드 풀 또는 접속 풀의 크기를 잘못 설정했다
1,000명의 동시 사용자 그리고 풀에 5개의 데이터베이스 접속이 있다면, 해당 풀에 대한 대기 조건이 발생할 수 있다. 거기에 더해 100개의 HTTP 쓰레드와 TCP 백로그(TCP Backlog, 대기 접속 큐의 최대 길이) 설정 값이 5라면, 105명의 사람들이 접속을 시도한 다음에는 “접속 거부” 메시지를 보게 될 것이다. 그렇지만, 이에 앞서 속도가 매우 저하될 것이다. 게다가, 몇몇 소프트웨어는 “허용” 쓰레드 개수를 가지고 있으며, 이는 기본적으로 “전화를 받아서 그것을 다른 쓰레드 중 하나로 넘기는 것”이다. 대개는 1개 또는 어쩌면 2개의 쓰레드가 있다.

이런 숫자들이 무엇이 되어야 하는지에 대한 엄격한 규칙은 없지만, 비율에 대해서는 합리적이어야 한다. 다른 제약사항에 직면할 수도 있기 때문에 이렇게 할 때는 원인 3도 명심하라.

원인 5. 최대값(limits)과 파일 핸들 개수를 잘못 설정했다
대부분의 운영체제는 쓰레드 개수와 운영체제 사용자가 열 수 있는 파일 개수에 대한 한계가 있다. 이런 한도로 운영하는 경우, 망가지기에 앞서 속도가 떨어질 것이다. 이런 현상은 로그에서 볼 수 있으며, 어떤 파일 록(Lock)과 핸들이 사용 중인지를 보여주는 도구가 있다.  editor@itworld.co.kr


X