방출시 부하 대책

이 글은 델리콤 애드벤트 캘린더 2014-애드벤타 22일째 되는 글이다.
21일째는 우치takao.uchikawa씨'스마트폰 탈출 게임 만드는 법'.입니다.

자기 소개

cimone라고 불려요.
PHP, 자바, 펄 등으로 포털을 만들었다.
드림에 와서 루비라고 썼는데 지금 PM하고 있어요.
요즘은 가끔 서버에 들어가서 명령을 조금 내린다.
드림낚시부 이부장입니다.
지역 여행, 바다뱀, 바다사자, 바다사자, 던지기, 해은, 캐릭터 배분 등 다양한 낚시를 시도해 낚시의 즐거움을 만끽한다.

글을 짓다

잊어버리는 자신을 위해 응용 프로그램이 발표될 때의 부하 대책을 기억 범위 내에서 정리한다.
별말씀을요. 같은 발행 시 부하 대책으로 낚은 물고기를 사진으로 찍어 발행하는 경우 물고기에 대한 부하 대책 방법을 소개합니다.

낚았을 때.

물고기에 대한 부담을 줄이기 위해 이렇게 호스를 물고기의 입에 꽂아 바닷물을 바다로 보낸다.사진을 찍을 수 있도록 산소를 제공하다.

그리고 사진 찍어요.

물고기가 잠잠해지면 사진을 찍어 빨리 풀어준다.

이제 본론.

이런 상황에서 로컬 응용의 개발은 마지막 단계를 맞이했고 마지막 완성 기간에 부하 테스트를 통해 서버 측의 문제를 두드러지고 개선했다.
실제 일은 몇 사람이 하기 때문에 세부 사항을 모르는 경우가 많다.

컨디션

Rails4.0(2014년 1월경)

Mysql

Amazon EC2(JMeter 활동용)

등등, 일반적인 rails 환경.

사용된 도구

JMeter

NewRelic

절차.

부하 테스트용 환경 구축

JMeter의 테스트 방안 만들기

rails에 New Relic 설정 추가

테스트용 데이터로 스크립트 제작 데이터 생성

Amazon 서버에 JMeter

설정

로드 테스트 실행

테스트 결과 확인

병목의 확정 및 수정

6~8 반복.

부하 테스트용 환경 구축

사전에 본격적인 환경을 조성하는 것이 좋을지 모르지만, 돈이 들기 때문에 축소판으로 구축해야 한다.

JMeter의 테스트 시나리오 만들기

자동제작이 가능한 방법도 있지만 서버에 API만 설치되어 있으니 하나씩 설정해 주세요.
부하 테스트 여러 가지 - JMeter의 사용 방법 -
이 점은 매우 참고 가치가 있다.많이 힘들었다면서요?
시나리오는 겟 액션, 업데이트 방법, 새 사용자 데이터의 세 가지 시점에서 진행된다.

폴더 아래

스크립트를 시작하는 게 이런 느낌이에요.
getter.sh

#! /bin/sh 

FILENAME=`basename $0`
BASENAME=${FILENAME%.*}

JMETER_PATH=../../../vendor/apache-jmeter-2.10/bin/jmeter

JMX_PATH=./jmx/${BASENAME}.jmx
JTL_PATH=./${BASENAME}.jtl

DOMAIN=localhost
PORT=3000
CLIENTS=20
LOOPS=10

${JMETER_PATH} -n -t ${JMX_PATH} -l ${JTL_PATH} -JDOMAIN=${DOMAIN} -JPORT=${PORT} -JCLIENTS=${CLIENTS} -JLOOPS=${LOOPS}

GUI를 사용하여 jmx를 조작합니다.파일 자체가 xml인 것 같습니다.

rails에 New Relic 설정 추가

New Relic 웹 사이트에 sign up, gem, newrelic 를 추가합니다.yml를 config에 넣기만 하면 되는 간단한 디자인입니다.

테스트 데이터 생성 스크립트에서 데이터 만들기

사용자 데이터와 관련된 100만 명의 데이터를 만들어 주십시오.

AmazonEC2에서 JMeter 설정

응용 프로그램은 데이터 센터의 클라우드 환경을 사용하지만 JMeter는 일시적으로 사용하기 때문에 서비스와 분리하여 EC2에 설정한다.

부하 테스트 실행

라인이 너무 많아서 그런지 out of memory에서 여러 번 멈췄어요.
규격상 여지를 두는 것이 좋다.

테스트 결과 확인

JMeter도 충분해 New Relic에서도 통계 보고서를 볼 수 있다.
신경 쓰이는 부분이 있으면 뉴릴리스에서 흐릿한 이미지를 넣은 부분을 클릭하면 자세히 볼 수 있다.

병목의 특정과 수정

색인을 잊어버리는 등은 상술한 방법을 통해 충분히 발견할 수 있다.
수정 후 다시 테스트를 진행합니다.
어떤 것들은 응용 프로그램의 스크립트에 처리 속도를 측정하는 코드를 넣어 병목을 탐색한다.
참조: Ruby를 이용한 처리 시간 측정 방법

홀린 곳

N+1 질문
상상을 초월하면 반응이 악화된다.
NewRelic에서는 뷰의 일부로 측정되기 때문에 질의가 고속으로 처리되므로 결정하기 어렵습니다.
만약 조회가 헛되이 많이 발행되었다면 의심할 여지가 있다.
처음부터 bullet을 넣으라고 하면 돼...
테스트 데이터가 이상해요.
통상적으로 생성되지 않는 양의 사용자 보유 단원의 데이터를 만들어 잠시 눈치채지 못하고 과잉 부하 대책을 취했다.

마지막으로

어떻게든 개선하기 어려운 상황에서 기획과 상의해 규격을 바꾸는 경우도 있다.
예를 들어 모든 사용자의 보유 단원수 상한선이 1000개라면 300개가 있으면 되지 않겠는가?잠깐만요.

반성점

대본에서 새어나오는 API가 여럿 있었는데 부하가 많이 들지 않는다고 생각하고 간과했다가 발표 후 위험한 장면이 있었다.폐회사의 슈퍼DBA를 한순간에 고쳤다.
이럴 때는 발매 전에 따라잡았지만 부하 대책은 좀 일찍 하게 해주세요!담당 엔지니어가 그렇게 말했기 때문에 서버비가 들더라도 일찍 시작하고 싶었다.
적시니까 이번엔 여기 있어!
이 기사를 쓸 때 평론 등 많은 사람의 협조를 받았다.감사합니다.
내일은 드림 기술의 미래를 여는 남자tomofusa.