물론 소프트웨어가 프로덕션 환경에서 잘 동작하지 않는 데는 다른 이유들도 있다. 하지만 개발자들이 “내 장비에서는 잘 동작했다”고 항변하다가 규모가 커지면 규모만큼이나 큰 책임이 따른다는 것을 뒤늦게 깨닫는 경우, 이 5가지가 필자가 본 가장 중요한 이유들이다.
원인 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
Sponsored
Surfshark
“유료 VPN, 분명한 가치 있다” VPN 선택 가이드
ⓒ Surfshark VPN(가상 사설 네트워크, Virtual Private Network)은 인터넷 사용자에게 개인 정보 보호와 보안을 제공하는 중요한 도구로 널리 인정받고 있다. VPN은 공공 와이파이 환경에서도 데이터를 안전하게 전송할 수 있고, 개인 정보를 보호하는 데 도움을 준다. VPN 서비스의 수요가 증가하는 것도 같은 이유에서다. 동시에 유료와 무료 중 어떤 VPN을 선택해야 할지 많은 관심을 가지고 살펴보는 사용자가 많다. 가장 먼저 사용자의 관심을 끄는 것은 별도의 예산 부담이 없는 무료 VPN이지만, 그만큼의 한계도 있다. 무료 VPN, 정말 괜찮을까? 무료 VPN 서비스는 편리하고 경제적 부담도 없지만 고려할 점이 아예 없는 것은 아니다. 보안 우려 대부분의 무료 VPN 서비스는 유료 서비스에 비해 보안 수준이 낮을 수 있다. 일부 무료 VPN은 사용자 데이터를 수집해 광고주나 서드파티 업체에 판매하는 경우도 있다. 이러한 상황에서 개인 정보가 유출될 우려가 있다. 속도와 대역폭 제한 무료 VPN 서비스는 종종 속도와 대역폭에 제한을 생긴다. 따라서 사용자는 느린 인터넷 속도를 경험할 수 있으며, 높은 대역폭이 필요한 작업을 수행하는 데 제약을 받을 수 있다. 서비스 제한 무료 VPN 서비스는 종종 서버 위치가 적거나 특정 서비스 또는 웹사이트에 액세스하지 못하는 경우가 생긴다. 또한 사용자 수가 늘어나 서버 부하가 증가하면 서비스의 안정성이 저하될 수 있다. 광고 및 추적 위험 일부 무료 VPN은 광고를 삽입하거나 사용자의 온라인 활동을 추적하여 광고주에게 판매할 수 있다. 이 경우 사용자가 광고를 보아야 하거나 개인 정보를 노출해야 할 수도 있다. 제한된 기능 무료 VPN은 유료 버전에 비해 기능이 제한될 수 있다. 예를 들어, 특정 프로토콜이나 고급 보안 기능을 지원하지 않는 경우가 그렇다. 유료 VPN의 필요성 최근 유행하는 로맨스 스캠은 인터넷 사기의 일종으로, 온라인 데이트나 소셜 미디어를 통해 가짜 프로필을 만들어 상대를 속이는 행위다. 이러한 상황에서 VPN은 사용자가 안전한 연결을 유지하고 사기 행위를 방지하는 데 도움이 된다. VPN을 통해 사용자는 상대방의 신원을 확인하고 의심스러운 활동을 감지할 수 있다. 서프샤크 VPN은 구독 요금제 가입 후 7일간의 무료 체험을 제공하고 있다. ⓒ Surfshark 그 외에도 유료 VPN만의 강점을 적극 이용해야 하는 이유는 다음 3가지로 요약할 수 있다. 보안 강화 해외 여행객이 증가함에 따라 공공 와이파이를 사용하는 경우가 늘어나고 있다. 그러나 공공 와이파이는 보안이 취약해 개인 정보를 노출할 위험이 있다. 따라서 VPN을 사용하여 데이터를 암호화하고 개인 정보를 보호하는 것이 중요하다. 서프샤크 VPN은 사용자의 개인 정보를 안전하게 유지하고 해킹을 방지하는 데 유용하다. 개인정보 보호 인터넷 사용자의 검색 기록과 콘텐츠 소비 패턴은 플랫폼에 의해 추적될 수 있다. VPN을 사용하면 사용자의 IP 주소와 로그를 숨길 수 있으며, 개인 정보를 보호할 수 있다. 또한 VPN은 사용자의 위치를 숨기고 인터넷 활동을 익명으로 유지하는 데 도움이 된다. 지역 제한 해제 해외 여행 중에도 한국에서 송금이 필요한 경우가 생길 수 있다. 그러나 IP가 해외 주소이므로 은행 앱에 접근하는 것이 제한될 수 있다. VPN을 사용하면 지역 제한을 해제해 해외에서도 한국 인터넷 서비스를 이용할 수 있다. 따라서 해외에서도 안전하고 편리하게 인터넷을 이용할 수 있다. 빠르고 안전한 유료 VPN, 서프샤크 VPN ⓒ Surfshark 뛰어난 보안 서프샤크 VPN은 강력한 암호화 기술을 사용하여 사용자의 인터넷 연결을 안전하게 보호한다. 이는 사용자의 개인 정보와 데이터를 보호하고 외부 공격으로부터 사용자를 보호하는 데 도움이 된다. 다양한 서버 위치 서프샤크 VPN은 전 세계 곳곳에 여러 서버가 위치하고 있어, 사용자가 지역 제한된 콘텐츠에 액세스할 수 있다. 해외에서도 로컬 콘텐츠에 손쉽게 접근할 수 있음은 물론이다. 속도와 대역폭 서프샤크 VPN은 빠른 속도와 무제한 대역폭을 제공하여 사용자가 원활한 인터넷 경험을 누릴 수 있도록 지원한다. 온라인 게임, 스트리밍, 다운로드 등 대역폭이 필요한 활동에 이상적이다. 다양한 플랫폼 지원 서프샤크 VPN은 다양한 플랫폼 및 디바이스에서 사용할 수 있다. 윈도우, 맥OS, iOS, 안드로이드 등 다양한 운영체제 및 디바이스에서 호환되어 사용자가 어디서나 안전한 인터넷을 즐길 수 있다. 디바이스 무제한 연결 서프샤크 VPN은 무제한 연결을 제공하여 사용자가 필요할 때 언제든지 디바이스의 갯수에 상관없이 VPN을 사용할 수 있다.