컴퓨터 서적 치곤 굉장히 가볍고, 얇다.(330여쪽의 분량) 전혀 부담이 되지 않는 두깨다. 적절히 삽화가 삽입되어 있어서 읽기에 크게 지루하지 않고 이해를 돕는다. 부담스럽지 않을 정도의 예시가 나와있어서 이해하는데 큰 문제가 없다. 가볍게 들고다니면서 읽을 수 있다 ㅋㅋ (물론 그런적은 손에 뽑을 정도 였지만^^;) 책 서두의 지은이의 말에 나와있다. 웹엔지니어, 웹서비스운
"인프라의 기본 리뷰" 내용보기
 컴퓨터 서적 치곤 굉장히 가볍고, 얇다.(330여쪽의 분량) 전혀 부담이 되지 않는 두깨다. 적절히 삽화가 삽입되어 있어서 읽기에 크게 지루하지 않고 이해를 돕는다. 부담스럽지 않을 정도의 예시가 나와있어서 이해하는데 큰 문제가 없다. 가볍게 들고다니면서 읽을 수 있다 ㅋㅋ (물론 그런적은 손에 뽑을 정도 였지만^^;)  책 서두의 지은이의 말에 나와있다. 웹엔지니어, 웹서비스운용, 웹관련 일을 하게 될 사람 이다. 그러나 잊지말하야 할 점이 있다. 이 책의 제목을 보면 알겠지만 기본 에 대해 나와있는 내용으로 깊은 내용을 다루지는 않는 다는 점이다.  이 책의 수준과 배경지식이 책의 수준윗 단락인 대상독자에서 다루었듯이 이 책의 수준은 [기본]이다. 즉 이미 웹서비스를 운영하고 있는 사람들이나 웹인프라가 어떻게 돌아가는지 아는 사람이 이 책을 구입한다면 실망할 지도 모른다. 어디까지나 기본지식이다! 그런 점에서 이책은 나름의 독자선정이 있고 가치가 있다. 나는 개발분야에서 활동했고, 개발에 필요한 간단한 서버구축을 한 정도의 사람으로써 이 책에서 건질 내용이 많았다. 가령 서버스펙(성능)을 결정할 때 그냥 고르는 줄 알았는데, 처리량/대역폭/확장성/다중화/예산 등등 다양한 고려사항이 있다는 것부터 시작하여 서버성능지표, 장애극복, 스케일 업/다운, 클라우드 등..내가 이 책에서 건질만한 내용은 많았다. 정말 처음시작하는 사람이라면 큰 도움이 되겠지만, 이미 이 분야에 있던 사람이라면 그저 '껌' 수준의 이야기만 나열하는 것이 될수 있으니 선정에 주의하길 바란다. 이 책은 기본서로 아주 깊은 내용을 바란다면 실망할것이다^^;  이 책을 읽기위해 필요한 배경지식아무리 기본이라고 해도 배경지식없이 이 책을 읽기엔 힘들 것이다. 적어도 아래와 같은 지식을 갖추면 이 책을 읽는데 무리가 없을 것 같다. 물론 아래 지식들이 없다 하더라도 책 읽는데에 크게 문제가 되지도 않고, 오히려 책 읽으면서 궁금한 사항들을 정리하면서 가면 웹 전반에 대해 공부할 수 있는 좋은 기회가 될 것이다.
리눅스를 써본적이 없다면  책에서 다루는 내용인프라(환경) 구축부터 시작하여 안정적인 서비스, 원할한 서비스 운영이 이 책의 전반적인 내용으로, 앞부분에서 이론과 구축으로 시작하여 뒷부분으로 갈수록 부하분산, 성능향상 등 안정성/성능에 초점을 맞춘다. 목차는 다음과 같다. (간략히 정리한 것)Chapter 1 웹 서비스에서 인프라의 역할 Chapter 2 인프라 기술의 기초 지식 Chapter 3 웹 서비스 서버 구성의 모범 사례 Chapter 4 인프라 준비의 기초 지식 Chapter 5 웹 서비스 운용 1 : 시스템 감시의 기본 Chapter 6 웹 서비스 운용 2 : 상태 모니터링 Chapter 7 웹 서비스 튜닝 1 : 보틀넥을 찾는 방법 Chapter 8 웹 서비스 튜닝 2 : 튜닝 레시피총 8장으로 구성되어 있으며 앞 부분은 이론, 뒷 부분은 실습(?) 구성이다. 1장~5장: 이론 5장까지는 인프라의 기본, 이론지식들을 다룬다. 이론이라고 그냥 넘어가지 말자. 대부분의 사람들이 실무를 강조한다며 바로 명령어 실행하고, 성능향상하고 이런 거에 관심이 많은데 이론 무시하지 말자. 이책을 읽으면서 뒤에 실습보단 앞에 이론에서 얻는 지식이 더 많았다. 6장~8장: 실습 앞의 5장까지와는 분위기가 사뭇다르다. 6장부터는 설정파일 셋팅, 모니터링 등.. 리눅스명령어가 나오기 시작하며(리눅스 대표적인 명령어 vi, cat, grep 등 간단한 명령어들) 캡쳐화면이 많이 나오기 시작한다 ㅋㅋㅋ 특히, Cacti를 이용한 모니터링 캡쳐화면과 설명이 과할 정도(..)로 나온다.  책 총평좋았던 점내가 이 책을 통해 얻은 지식들은 다음과 같다.
아쉬웠던 점 일본 서적의 특징인 것 같은데, 대표적인 것을 냅두고 자기내들 제품을 예시로 드는 경우가 많다. 이 책에서도 그런점을 볼수 있는데, 라우터 하면 딱 Cisco 제품이 떠오르는데, 이책에서는 야마하 라우터(-_-)를 다루고 있다..야마하에서 라우터도 만드는지 처음 알았다;;  참고서적 및 다른 책들 이야기이 책 외에도 서버 성능과 구축에 관한 책들이 많은데, 이책으로 기본기를 다졌다면 아래의 책들을 보는 것도 괜찮을 것 같다.
위 3책의 공통점은 일본 번역서라는 거다-_- 그리고 첫번째와 두번째 책은 이 책과 비슷한 입문서다. 이 책과 비슷한 컨셉과 내용으로 나온 책이다. 첫번째와 두번째 책은 이 책과는 달리 하드웨어에 초점을 맞추었다.
헉, 웹사이트 최적화 기법 책은 절판이다...예전에 구입을 해놨지만 이렇게 좋은 책이 절판이라니..ㅠㅠ 이 책을 고르시는 분들께 한마디인프라(환경)에 대해 처음 공부한다면 추천한다. 입문자 수준에서 이론과 튜닝지식이 나와있다. 이 책이 인프라 구축과 서버 퍼포먼스 향상이라는 큰 주제를 시작할 발판이 될 것이다.
|
요즘은 IT나 너무나 일상화 되서인지, 그 내용이 방대할 수도 있으나. IT 전반에 걸친 지식을 알려주는 책이 없다. 구글이나, 네이버 등 포털내의 IT사전이나 지식검색 등을 통해서 파악 할 수있으나, 아무래도 단편적이기 쉽다. 이 책은 일본 협업의 IT종사자가 개인의 경험을 바탕으로 작성한 글이다. 고객들과 실사용자들은 사실 IT인프라에는 별관심이 없다. 그러나 그 뒷단에서
"그럭저럭 읽을만한 책입니다.!" 내용보기
|
요즘은 IT나 너무나 일상화 되서인지, 그 내용이 방대할 수도 있으나. IT 전반에 걸친 지식을 알려주는 책이 없다.
구글이나, 네이버 등 포털내의 IT사전이나 지식검색 등을 통해서 파악 할 수있으나, 아무래도 단편적이기 쉽다.
이 책은 일본 협업의 IT종사자가 개인의 경험을 바탕으로 작성한 글이다. 고객들과 실사용 자들은 사실 IT인프라에는 별관심이 없다.
그러나 그 뒷단에서 돌아가는 인프라 없이 서비스는 구현되지 않는다. 실제 서비스가 어떠한 환경에서 구현되는지 관심이 있는 독자라면 한번쯤은 읽어볼만 하다.
그러나 최신 내용을 반영하고 있지는 않으니, 너무 기대는 하지 않토록...~
|
1) 웹 서비스에서 인프라의 역할1. 웹 서비스 구축에 관련된 인프라 영역요건 정의 -＞ 설계 -＞ 조달 -＞ 구축 -＞ 운용인프라의 기술 계층 구조7 : 애플리케이션 계층 (HTTP, FTP..)4 : 전송 계층 (TCP, UDP)3 : 네트워크 계층 (IP, ICMP)2 : 데이터링크 계층 (Ethernet)1 : 물리 계층 (RJ-45)Infrastructure as a Service (IaaS) : 하드웨어, 네트워크, 코로케이션 (Amazon Web Servi
"웹 엔지니어가 알아야 할 인프라의 기본 - 한빛미디어" 내용보기
|
1) 웹 서비스에서 인프라의 역할 1. 웹 서비스 구축에 관련된 인프라 영역 요건 정의 -＞ 설계 -＞ 조달 -＞ 구축 -＞ 운용 인프라의 기술 계층 구조 7 : 애플리케이션 계층 (HTTP, FTP..) 4 : 전송 계층 (TCP, UDP) 3 : 네트워크 계층 (IP, ICMP) 2 : 데이터링크 계층 (Ethernet) 1 : 물리 계층 (RJ-45) Infrastructure as a Service (IaaS) : 하드웨어, 네트워크, 코로케이션 (Amazon Web Services, Google Cloud Platform, Softlayer) Platform as a Service (PaaS) : 애플리케이션 실행환경, 미들웨어, OS, 하드웨어, 네트워크, 코로케이션 (Heroku, Google App Engine, Engine Yard) 3. 인프라의 설계 3-1. 기능적 요건 - 네트워크 이중화, 4000 접속이 가능한 SSL 오프로딩 기능, VRRP(Virtual Router Redundancy Protocol)에 따라 Active-Standby 구성이 가능한 로드밸런서, 1Gbps 48포트, 10Gbps 2포트, L2 스위치, 동시접속 80,000 세션에 대응하고 접속 소스당 사용량 제한이 가능한 방화벽, 로드밸런서 하위 웹서버 4대, 내부 네트워크는 외부 통신용과 서버 간의 통신용으로 분할 3-2. 비기능적 요건 - 가용성 (가동율, 목표 복구 시간, 재해 대책), 성능/확장성 (성능 목표, 확장성), 운용/유지보수성 (운용 시간, 백업, 운용 감시, 정기 보수), 이행성 (이행 방식의 규정, 이행 스케쥴, 설비/데이터), 보안(가이드라인, 네트워크 레벨 제어, DoS공격 대책, 정보 유츌 대책, 사고 발생 시의 대응), 시스템 환경/생태 환경 (적합 규격, 기기 설치 규격, 환경 관리) RAS : Reliability(신뢰성), Availability(가용성), Serviceability(유지보수성) - ISO/IEC27002 RASIS : RAS + Integrity(무결성), Security(안전성) CIA : Confidentiality(기밀성), Integrity(무결성), Availability(가용성) 4. RAS 검토 가동률 = MTBF / (MTBF + MTTR) MTBF = 누적 사용 시간 / 고장 횟수 (장애 발생 간격, Mean Time Between Failures) MTTR = 누적 수리 시간 / 고장 횟수 (평균 복구 시간, Mean Time To Repair) 연간으로 환산한 초 수와 가동률로부터 정지 시간을 산출 86,400초(24시간) X 365일 X 0.01% (가동률 99,99%) = 3153.6초 MTTR이 4분인 경우 (MTBF 28일) 99.99% = 60 X 24 X MTBF / (60 X 24 X MTBF + 4) MTTR이 18인 경우 (MTBF 125일) 99.99% = 60 X 24 X MTBF / (60 X 24 X MTBF + 18) 가동률을 높이는 방법 요소 각각의 가동률을 높인다 (서버용 부품 사용, 부품을 이중화, 요소 각가의 가동률 확인) 요소를 조합해 전체의 가동률을 높인다 (다중화 기술을 이용하여 가동률 높임) 적절한 프로비저닝으로 부하 문제를 피한다 (스케일업(서버 성능을 높이는 것), 스케일아웃(서버 수 늘리는 것)) 다중화 구성 요소 Active-Active Active-Standby (Hot Standby (즉시), Warm Standby (나름 준비 필요), Cold Standby (정지)) 문서 작성 도구 Sphinx : sphinx-doc.org Graphviz : www.graphviz.org Blockdiag : blockdiag.com Cacoo : cacoo.com 5) 웹 서비스 운용 1 : 시스템 감시의 기본 2 . 시스템 감시의 구현 감시툴 - Nagios : 감시 기능에 특화 - Zabbix : 감시 기능 외에 그래프화 기능도 있음 모니터링툴 - Cacti : 사용자 관리 기능이 있음. 풀형 데이터 수집 - Nackerel : SaaS형 서비스 감시도 가능 - Monit : 간단함. 사용자 관리 기능 없음. 풀형 데이터 수집 - GrowthForecast : 간단함. 사용자 관리 기능 없음. 푸시형 데이터 수집 시스템 감시 (Nagios: NRPE, Zabbix: Zabbix Agent) - 외형 감시 - 내부 감시 - 서비스 가동 상황 감시(액티브 체크, 패시스 체크(SNMP Trap)), 시스템 리소스 감시 감시 항목을 결정하기 위한 현재 상태 확인 방법 - 방화벽 설정 확인 iptable -nv -L ss -lnp ip6table -nv -L - 프로세스 확인 ps aufx | grep -w 1380 | grep -v grep yum whatprovides /usr/libexec/postfix/master 현재 상태 확인 결과로부터 감시 항목 만들기 a. 실행 프로세스 수를 확인 - I/O 확인 : 서비스/관리 네트워크 입출력, 서비스/관리 파일 입출력 b. 외형 감시의 주요 항목 - HTTP 응답 코드, 내용, 응답시간, 크기 - HTTPS 응답 코드, 내용, 응답시간, 크기 - POP, SMTP, FTP.. 동작여부, 메일 송수신, 파일 PUT/GET 등 - HTTP 시나리오 c. 내부 감시의 주요 항목 - CPU 사용률, 평균 부하, 디스크별 사용률, 디스크별 I/O 요구량, 디스크별 대기 시간, 네트워크 인터페이스별 트레픽 IN/OUT, 로컬에서의 HTTP 접속, 서비스에 사용할 프로세스의 감시, 시스템적으로 사용할 프로세스의 감시 3. 장애가 발생했을 경우의 대응 방법 a. 경보 b. 현상 확인 c. 1차 대응 script -q -C "ssh www.example.com" www.example.com.20151123_09:20:30.log lssh 파일명 #!/bin/bash NOW=$(date +%Y%m%d_%H%M%S) exec script -q -C "ssh $1" $1.$NOW.log chmod a+x lssh ./lssh localhsot export PS1="\D{%Y/%m/%d %H:%M:%S} $PS1" export HISTTIMEFORMAT='%Y-%m-%d %T' 상황 확인용 명령어 일람 w ss -lnp ps aufx df -h top -b -d 1 -n 1 top -b -d 1 -n 1 -a dstat -taf 1 10 mysqladmin processlist -verbose 로그 확인툴 fluentd d. 경보 현상 및 다른 항목 확인하기 e. 사후 작업 f. 수습 6) 웹 서비스 운용 2 6.4. 실시간 모니터링 방법 - 툴 : dstat, top, iostat (yum install dstat, yum install sysstat) dstat - option : -t (일시), -l (평균부하), -m (메모리), -a (cpu, disk, network, paging, system), -f (디바이스별 표시), --output (csv), 1 (1초마다) - dstat -tlaf --output stat.csv 1 3600 iostat - option : -t (일시), -x (확장 상태), -n (NFS상태), 1 (1초마다) - iostat -txn 1 6.5 트러블 대응에 사용하는 모니터링 툴 - tcpdump : 네트웍크 상태 파악 ( tcpdump -i eth0 -n port 80, tcpdump -i lo -n port 3306 ) - strace, lsof : 프로세스 동작 확인 ( ps aufx | grep http[d] | head -3, strace-f -p 5377, lsof -p 5377 ) : 설치 ( yum install strace, yum install lsof ) 7) 웹 서비스 튜닝 1 : 보틀넥을 찾는 방법 7.4 보틀넥을 찾는 방법 - 로그 - Apache에서 보틀넥 찾기 httpd.conf : LogFormat "%h %l %u %t \"%r\" %＞s %b \"%{Referer}i\" \"%{User-Agent}i\" %D"combined (%D로 총 소요시간) - MySQL에서 보틀넥 찾기 slow-query-log=NO slow-query-log-file=mysqld-slow.log long-query-time=10 (show global variables like 'long_query_time'; set global long_query_time=1; show global variables like 'long_query_time';) - mysqldumpslow ( mysqldumpslow -t 3 -s t mysqld-slow.log ) -s ORDER :al (평균 lock시간), ar (평균 송신 행의 수), at (평균 SQL 실행 시간), c (SQL 실행 횟수), l (lock 시간), r (송신 행의 수), t ( SQL 실행 시간) -h HOSTNAME : 조사 대상의 호스트 이름을 지정 -t NUM : 정렬한 결과의 상위에서 NUM 갯수만큼 표시 7.6 보틀넥을 찾는 방법 - 애플리케이션 코드 - XDebug : 애플리케이션 프로파일러 툴 ( sudo yum install php-pecl-xdebug, php.ini ([xdebug] xdebug.profiler_enable=1 ) - KCachegrind, webgrind ls /tmp/cachegrind.out.* 8) 웹 서비스 튜닝 2 : 튜닝 레시피 8.1 포인트별 튜닝 레시피 - 요청 횟수와 데이터 전송량을 줄이는 방법 a) 요청횟수 줄이는 방법 - 파일 결합 : CSS와 JavaScript의 파일 결합 - CSS Sprite : 이미지를 하나로 집약 - 패턴 이미지는 CSS로 구현 - HTTP KeepAlive 유효화 b) 데이터 전송량 줄이는 방법 - CSS나 JavaScript를 minify - 이미지 압축률을 높인다 - 이미지 크기를 작게 한다 - 데이터를 압축하여 전송 - 정적 파일을 브라우저에서 캐시 - CDN 사용 Grunt툴 사용하여 minify화 (http://gruntjs.com) - CSS 결합/minify ( grunt-contrib-cssmin https://github.com/gruntjs/grunt-contrib-cssmin ) - JavaScript 결합 ( grunt-contrib-concat https://github.com/gruntjs/grunt-contrib-concat ) - JavaScript minify ( grunt-contrib-uglify https://github.com/gruntjs/grunt-contrib-uglify ) - CSS Sprite 작성 ( grunt-spritesmith https://github.com/Ensighten/grunt-spritesmith ) Grunt 설치 및 활용 - package.json { "name": "myproject", "version": "0.0.1" } - 필요 라이브러리 설치 yum install npm ImageMagick GraphicsMagick cairo-devel libjpeg-turbo-devel npm install grunt＜cli grunt-contrib-concat grunt-contrib-uglify grunt-contrib-cssmin grunt-spritesmith --save-dev - Gruntfile.js module.exports = function(grunt) { grunt.initConfig({ pkg: grunt.file.readJSON('package.json'), cssmin: { compress: { files: { 'dest/min.css': ['css/*.css'] } } }, concat: { files: { src: 'js/*.js', dest: 'tmp/all.js' } }, uglify: { dest: { files: { 'dest/min.js': 'tmp/all.js' } } }, sprite: { all: { src: 'img/*.png', destImg: 'dest/sprite.png', destCSS: 'dest/sprite.css' } } }); grunt.loadNpmTasks('grunt-contrib-cssmin'); grunt.loadNpmTasks('grunt-contrib-concat'); grunt.loadNpmTasks('grunt-contrib-uglify'); grunt.loadNpmTasks('grunt-spritesmith'); grunt.registerTask('default', ['sprite', 'cssmin', 'concat', 'uglify']); }; - node-modules/.bin/grunt (실행) OS의 CPU 사용률 낮추기 lowait 낮추기 - iotop로 I/O 체크 ( yum install iotop, iotop -P ) - ps로 status D 프로세스 확인 OS의 네트워크 사용량 낮추기 (백업) rsync -az /data/backup/ remote.example.com:/data/backup/web/ tar zcfp - -C /data/backup . | ssh remote.example.com "cat - | tar zxf - -C /data/backup/web" tar cfp - -C /data/backup -I pigz . | ssh remote.example.com "cat - | tar xf - -C /data/backup/web -I pigz" Apache의 CPU 사용률 낮추기 pgrep -P 'cat /var/run/httpd/httpd.pid' | while read echo 'ulimit -n 65535' | tee -a /etc/sysconfig/httpd Apache의 메모리 사용량 낮추기 cow.py #!/usr/bin/env python import sys import re for pid in sys.argv[1:]: mem = {'Rss:': 0, 'Shared_Clean:': 0, 'Shared_Dirty:': 0} for line in open('/proc/%s/smaps' % pid, 'r'): line = line.rstrip('\n') parts = re.split('\s+', line) for k, v in mem.iteritems(): if k in parts: val = int(parts[1]) if parts[2] == 'kB': val = val * 1000 elif parts[2] == 'mB': val = val * 1000000 mem[k] = v + val shared_ratio = (mem['Shared_Clean:'] + mem['Shared_Dirty:']) * 100.0 / mem['Rss:'] print 'PID %s shared %.2f%%' % (pid, shared_ratio) ps aufx | grep http[d] ./cow.py 'pgrep -U apache' Apache의 디스크 I/O 사용량 낮추기 httpd.conf (이미지와 같은 정적 파일 로그 출력하지 않도록 수정) SetEnvIfNoCase Request_URI "\.(gif|jpeg|jpg|png|js|css|swf|ico)$" nolog CustomLog logs/access_log combined env=!nolog BufferedLogs On (주의 필요) 애플리케이션 서버의 CPU 사용률 낮추기 Gargbage collector 조정 바이트코드 캐시 이용 (5.4 이전 : apc (Alternative PHP Cache), 5.5 이후 : OPCache) yum install php-pecl-apc php -i | grep apc.enabled 8.2 SQL 튜닝에서의 고속화 SQL 튜닝 툴 EXPLAIN, PROFILING EXPLAIN : SQL 앞에 EXPLAIN을 붙여 실행 계획 확인 - possible_keys, key로 인덱스 확인 - rows 행수 검사는 낮아야 한다 - Extra항목에 Using filesort가 없어야 한다 PROFILING SET PROFILING=1; SQL 실행 SHOW PROFILES; SHOW PROFILE FOR QUERY 1; 8.4 [DB] 스케일 아웃 구현의 예 HAProxy, Keepalived (LVS) |
엔지니어가 굳이 아니더라도 "굳이" 알아야 하는 기본만을 담은 책이라는 생각이 들었습니다."인프라"를 반드시 공부해야 하는 사람이 아닐지라도 "인프라"는 이제 모두가 알아야 하는 기본지식이 아닌가 라는 생각도 들었죠.IT와 비즈니스의 콜라보레이션(또는 협업)이 필수가 되는 이 시대를 살아가야 하는 우리에게 이 책은 IT 책임에도 불구하고모두에게 교양서적에 더 가깝지도 모르
"IT 서적이기보단 교양서적에 가까운 정통 인프라 기본서적입니다!" 내용보기
|
엔지니어가 굳이 아니더라도 "굳이" 알아야 하는 기본만을 담은 책이라는 생각이 들었습니다. "인프라"를 반드시 공부해야 하는 사람이 아닐지라도 "인프라"는 이제 모두가 알아야 하는 기본지식이 아닌가 라는 생각도 들었죠. IT와 비즈니스의 콜라보레이션(또는 협업)이 필수가 되는 이 시대를 살아가야 하는 우리에게 이 책은 IT 책임에도 불구하고 모두에게 교양서적에 더 가깝지도 모르겠다는 생각이 들었습니다. 또한, 굳이 인프라를 공부해야 할까? 라는 사람들에게 좋은 명분(?)이 될 것 같다..라는 생각으로 이 책을 읽기 시작했습니다.^^ 이 책의 목차는 간단하게 살펴보면 다음과 같습니다. Chapter 1. 웹 서비스에서 인프라의 역할 Chapter 2. 인프라 기술의 기초 지식 Chapter 3. 웹 서비스 서버 구성의 모범 사례 Chapter 4. 인프라 준비의 기초지식 Chapter 5. 웹 서비스 운용 1: 시스템 감사의 기본 Chapter 6. 웹 서비스 운용 2: 상태 모니터링 Chapter 7. 웹 서비스 튜닝 1: 보틀넥을 찾는 방법 Chapter 8. 웹 서비스 튜닝 2: 튜닝 레시피 #1. 책을 읽기 전엔 지은이가 어떤 사람인지.. 먼저 살펴보게 됩니다.
책에 서두에 지은이는 운영, 개발을 거쳐 인프라 엔지니어시군요....(역시 내용에 깊이가 느껴진 이유가 있었어요..) 옮긴이는 테크니컬 마케팅 이라는 조금은 생소한 업무를 담당하면서도 번역을 하셨다니 노고에 박수를 드립니다.. 다양한 개발업무의 경험을 토대로 마케팅의 시각을 입혀 기본에 충실한 서적으로 재탄생하게 된 "인프라의 기본" 이 책이 어떠한 내용일지 참 궁금했습니다. (책을 읽은 지금 생각해보면 기존 IT 책 답지 않은 세세하고 친절한 기본기의 설명과 많은 실제 캡쳐화면으로 독자의 이해를 돕고자 한 것이 모두 이러한 업무경험에서 나온게 아니었을까 라는 생각도 살짝 하게 되네요) #2. 저보다 먼저 읽은 사람은 어떤 도움이 되었을지 궁금하네요... 더군다나 IT 입장에서는 이렇게 삶의 중요한 부분으로 젖어든 웹 서비스에 대해 항상 서비스 이용에 불편함이 없도록 관리하는 게 굉장히 중요한 업무가 되었죠. 100% 안전하게, 효율적으로 서비스가 구현될 수 있다면, 노심초사 IT를 지키고 있는 많은 사람들의 노고가 없을텐데요 불완전하고 항상 급변하는 IT 환경을 지키는 많은 관계자 분들을 위해 도움이 되는 좋은 책임엔 틀림없군요. IT는 중요한 만큼 비즈니스 담당자 뿐만 아니라 관련된 모든 분들이 힘을 합쳐서 지켜야 하겠죠? 실제 운용까진 아닐지라도, 전체적인 흐름과 IT 환경 구축과 운영에 대한 기본지식만 갖추기만 해도 여러분은 모두 좀 더 나은 IT 환경을 위한 번뜩이는 아이디어가 샘솟는 "능력자"가 될 수 있을 거에요~! #3. 스마트&심플한 도해는 책의 이해를 돕는 동시에 실무적은 느낌도 전달해주는 것 같아요.. 엔지니어를 대상으로 한다고 너무 "실무적"이라 이해가 어렵거나 복잡하지 않았습니다. 그리고, 특정 기업에만 해당하는 내용으로 치우치지 않고 어떤 기업에든 해당할 수 있는 내용으로 구성해서 좋았습니다. 네트워크망의 구성이나 인프라의 표현에 있어 너무 전문적인 약어나 이모티콘의 사용을 줄이고 직관적인 단어와 심플한 표현방법은 누가봐도 이해하기 쉽다고 생각하여 매끄럽게 책을 읽어나가는 데 전혀 무리가 없었습니다. 가끔 회사에서 감사를 받거나, 외부에 공시자료를 제출할 때 네트워크망 구성도나 서버구성도가 전문적인 약어로 표현되고, 가뜩이나 복잡한 망을 더 복잡하게 만드는 영어표현으로 인해 너무 어렵다는 의견도 있었는데... 회사의 자료들도 담당자 뿐만 아니라 누구나 알 수 있게 만들 필요도 있을 거란 생각도 들었습니다. #4. 사실적인 캡쳐화면과 상세한 설명(지시선)은 간접적으로 실무환경을 느끼게 해주네요... 무의미하게 "아..이런게 있구나.." 그런가보다..라고 지나칠 수 있는 그림들이지만, 어떤 의미인지 직관적으로 알 수 있도록 친절한 지시선과 세부설명으로 유의미한 사실로 전달해주는 것은 역자의 "친절함"을 보여주는 단적인 예라고 생각합니다. 실제적인 운영에 대한 이해를 통해 운영을 위해 어떤 툴을 사용하고, 어떻게 활용하는지 알 수 있어 좋았습니다. 사실 이 부분에서 조금 "기본"이라는 게 어떤 누구에게는 기본이지만, 또 어떤 누구에게는 기본을 넘어서지 않을까 라는 우려가 드는 부분이기도 합니다.^^ (조금 Depth가 있는 부분은 살짝 넘기시고 먼저 전체적인 느낌을 파악하는 게 좋지 않을까 하는 개인적인 의견입니다.) #5. 이 책을 집어들었을 때 이 부분이 가장 궁금했었어요..장애대응! #5. 장애는 평소 모니터링을 통해 100% 관리되어지기 힘들다 보니, 언제든 트러블슈팅(문제해결)을 위한 준비를 통해 대응할 수 있도록 노력해야 하겠죠. 그런 면에서 운영은 장애대응을 예방하기 위한 방법이라고도 생각합니다. 그런 면에서 정제된 운영방법 뿐만 아니라 문제가 생겼을 때 대응할 수 있는 방법도 구체적으로 제시하게 있네요... 역시 지은이가 숙련된 인프라 운영 경험을 보유하고 있어서인지 잘 정돈되고 깊이있는 노하우가 느껴집니다. 뒷 부분의 트러블슈팅부터 웹서비스 튜닝부분은 그런만큼 조금 깊이가 있지만 굉장히 도움이 될 거라고 생각합니다. #End.. 지은이의 말을 빌어 "지식의 양을 늘리기 위하여 두뇌와 시간을 들여야 하는 기존의 방식을 바꿔야 한다" 라는 말이 인상깊게 기억이 나네요. 이 책을 읽으며 시원하게 느꼈던 이유는 평소 인프라에 대한 갈증이 있었기 때문이 아닐까 하고 생각이 되고, 시간이 어떻게 흐른지도 모르도록 몰입할 수 있었던 이유는 이런 갈증을 완벽하게 채워주기 적합한 책이라서 일까 라는 생각이 들었습니다. 두뇌를 써야하는 어려움도 책을 읽는 시간이 무디게 간다는 생각이 안 들었던 "참 재밌었던 책"이었습니다. 전체를 쭉 재미있게 읽었지만, 앞으로 틈나는 데로 어려웠던 부분은 다시 읽고, 현재 하고 있는 일과 연관지어서 다시 쭉 읽어봐야겠네요.^^ 감사합니다. |
1) 웹 서비스에서 인프라의 역할1. 웹 서비스 구축에 관련된 인프라 영역요건 정의 -＞ 설계 -＞ 조달 -＞ 구축 -＞ 운용인프라의 기술 계층 구조7 : 애플리케이션 계층 (HTTP, FTP..)4 : 전송 계층 (TCP, UDP)3 : 네트워크 계층 (IP, ICMP)2 : 데이터링크 계층 (Ethernet)1 : 물리 계층 (RJ-45)Infrastructure as a Service (IaaS) : 하드웨어, 네트워크, 코로케이션 (Amazon Web Servi
"웹 엔지니어가 알아야 할 인프라의 기본 - 한빛미디어" 내용보기
|
1) 웹 서비스에서 인프라의 역할 1. 웹 서비스 구축에 관련된 인프라 영역 요건 정의 -＞ 설계 -＞ 조달 -＞ 구축 -＞ 운용 인프라의 기술 계층 구조 7 : 애플리케이션 계층 (HTTP, FTP..) 4 : 전송 계층 (TCP, UDP) 3 : 네트워크 계층 (IP, ICMP) 2 : 데이터링크 계층 (Ethernet) 1 : 물리 계층 (RJ-45) Infrastructure as a Service (IaaS) : 하드웨어, 네트워크, 코로케이션 (Amazon Web Services, Google Cloud Platform, Softlayer) Platform as a Service (PaaS) : 애플리케이션 실행환경, 미들웨어, OS, 하드웨어, 네트워크, 코로케이션 (Heroku, Google App Engine, Engine Yard) 3. 인프라의 설계 3-1. 기능적 요건 - 네트워크 이중화, 4000 접속이 가능한 SSL 오프로딩 기능, VRRP(Virtual Router Redundancy Protocol)에 따라 Active-Standby 구성이 가능한 로드밸런서, 1Gbps 48포트, 10Gbps 2포트, L2 스위치, 동시접속 80,000 세션에 대응하고 접속 소스당 사용량 제한이 가능한 방화벽, 로드밸런서 하위 웹서버 4대, 내부 네트워크는 외부 통신용과 서버 간의 통신용으로 분할 3-2. 비기능적 요건 - 가용성 (가동율, 목표 복구 시간, 재해 대책), 성능/확장성 (성능 목표, 확장성), 운용/유지보수성 (운용 시간, 백업, 운용 감시, 정기 보수), 이행성 (이행 방식의 규정, 이행 스케쥴, 설비/데이터), 보안(가이드라인, 네트워크 레벨 제어, DoS공격 대책, 정보 유츌 대책, 사고 발생 시의 대응), 시스템 환경/생태 환경 (적합 규격, 기기 설치 규격, 환경 관리) RAS : Reliability(신뢰성), Availability(가용성), Serviceability(유지보수성) - ISO/IEC27002 RASIS : RAS + Integrity(무결성), Security(안전성) CIA : Confidentiality(기밀성), Integrity(무결성), Availability(가용성) 4. RAS 검토 가동률 = MTBF / (MTBF + MTTR) MTBF = 누적 사용 시간 / 고장 횟수 (장애 발생 간격, Mean Time Between Failures) MTTR = 누적 수리 시간 / 고장 횟수 (평균 복구 시간, Mean Time To Repair) 연간으로 환산한 초 수와 가동률로부터 정지 시간을 산출 86,400초(24시간) X 365일 X 0.01% (가동률 99,99%) = 3153.6초 MTTR이 4분인 경우 (MTBF 28일) 99.99% = 60 X 24 X MTBF / (60 X 24 X MTBF + 4) MTTR이 18인 경우 (MTBF 125일) 99.99% = 60 X 24 X MTBF / (60 X 24 X MTBF + 18) 가동률을 높이는 방법 요소 각각의 가동률을 높인다 (서버용 부품 사용, 부품을 이중화, 요소 각가의 가동률 확인) 요소를 조합해 전체의 가동률을 높인다 (다중화 기술을 이용하여 가동률 높임) 적절한 프로비저닝으로 부하 문제를 피한다 (스케일업(서버 성능을 높이는 것), 스케일아웃(서버 수 늘리는 것)) 다중화 구성 요소 Active-Active Active-Standby (Hot Standby (즉시), Warm Standby (나름 준비 필요), Cold Standby (정지)) 문서 작성 도구 Sphinx : sphinx-doc.org Graphviz : www.graphviz.org Blockdiag : blockdiag.com Cacoo : cacoo.com 5) 웹 서비스 운용 1 : 시스템 감시의 기본 2 . 시스템 감시의 구현 감시툴 - Nagios : 감시 기능에 특화 - Zabbix : 감시 기능 외에 그래프화 기능도 있음 모니터링툴 - Cacti : 사용자 관리 기능이 있음. 풀형 데이터 수집 - Nackerel : SaaS형 서비스 감시도 가능 - Monit : 간단함. 사용자 관리 기능 없음. 풀형 데이터 수집 - GrowthForecast : 간단함. 사용자 관리 기능 없음. 푸시형 데이터 수집 시스템 감시 (Nagios: NRPE, Zabbix: Zabbix Agent) - 외형 감시 - 내부 감시 - 서비스 가동 상황 감시(액티브 체크, 패시스 체크(SNMP Trap)), 시스템 리소스 감시 감시 항목을 결정하기 위한 현재 상태 확인 방법 - 방화벽 설정 확인 iptable -nv -L ss -lnp ip6table -nv -L - 프로세스 확인 ps aufx | grep -w 1380 | grep -v grep yum whatprovides /usr/libexec/postfix/master 현재 상태 확인 결과로부터 감시 항목 만들기 a. 실행 프로세스 수를 확인 - I/O 확인 : 서비스/관리 네트워크 입출력, 서비스/관리 파일 입출력 b. 외형 감시의 주요 항목 - HTTP 응답 코드, 내용, 응답시간, 크기 - HTTPS 응답 코드, 내용, 응답시간, 크기 - POP, SMTP, FTP.. 동작여부, 메일 송수신, 파일 PUT/GET 등 - HTTP 시나리오 c. 내부 감시의 주요 항목 - CPU 사용률, 평균 부하, 디스크별 사용률, 디스크별 I/O 요구량, 디스크별 대기 시간, 네트워크 인터페이스별 트레픽 IN/OUT, 로컬에서의 HTTP 접속, 서비스에 사용할 프로세스의 감시, 시스템적으로 사용할 프로세스의 감시 |
1) 웹 서비스에서 인프라의 역할1. 웹 서비스 구축에 관련된 인프라 영역요건 정의 -＞ 설계 -＞ 조달 -＞ 구축 -＞ 운용인프라의 기술 계층 구조7 : 애플리케이션 계층 (HTTP, FTP..)4 : 전송 계층 (TCP, UDP)3 : 네트워크 계층 (IP, ICMP)2 : 데이터링크 계층 (Ethernet)1 : 물리 계층 (RJ-45)Infrastructure as a Service (IaaS) : 하드웨어, 네트워크, 코로케이션 (Amazon Web Servi
"웹 엔지니어가 알아야 할 인프라의 기본 - 한빛미디어" 내용보기
|
1) 웹 서비스에서 인프라의 역할 1. 웹 서비스 구축에 관련된 인프라 영역 요건 정의 -＞ 설계 -＞ 조달 -＞ 구축 -＞ 운용 인프라의 기술 계층 구조 7 : 애플리케이션 계층 (HTTP, FTP..) 4 : 전송 계층 (TCP, UDP) 3 : 네트워크 계층 (IP, ICMP) 2 : 데이터링크 계층 (Ethernet) 1 : 물리 계층 (RJ-45) Infrastructure as a Service (IaaS) : 하드웨어, 네트워크, 코로케이션 (Amazon Web Services, Google Cloud Platform, Softlayer) Platform as a Service (PaaS) : 애플리케이션 실행환경, 미들웨어, OS, 하드웨어, 네트워크, 코로케이션 (Heroku, Google App Engine, Engine Yard) 3. 인프라의 설계 3-1. 기능적 요건 - 네트워크 이중화, 4000 접속이 가능한 SSL 오프로딩 기능, VRRP(Virtual Router Redundancy Protocol)에 따라 Active-Standby 구성이 가능한 로드밸런서, 1Gbps 48포트, 10Gbps 2포트, L2 스위치, 동시접속 80,000 세션에 대응하고 접속 소스당 사용량 제한이 가능한 방화벽, 로드밸런서 하위 웹서버 4대, 내부 네트워크는 외부 통신용과 서버 간의 통신용으로 분할 3-2. 비기능적 요건 - 가용성 (가동율, 목표 복구 시간, 재해 대책), 성능/확장성 (성능 목표, 확장성), 운용/유지보수성 (운용 시간, 백업, 운용 감시, 정기 보수), 이행성 (이행 방식의 규정, 이행 스케쥴, 설비/데이터), 보안(가이드라인, 네트워크 레벨 제어, DoS공격 대책, 정보 유츌 대책, 사고 발생 시의 대응), 시스템 환경/생태 환경 (적합 규격, 기기 설치 규격, 환경 관리) RAS : Reliability(신뢰성), Availability(가용성), Serviceability(유지보수성) - ISO/IEC27002 RASIS : RAS + Integrity(무결성), Security(안전성) CIA : Confidentiality(기밀성), Integrity(무결성), Availability(가용성) 4. RAS 검토 가동률 = MTBF / (MTBF + MTTR) MTBF = 누적 사용 시간 / 고장 횟수 (장애 발생 간격, Mean Time Between Failures) MTTR = 누적 수리 시간 / 고장 횟수 (평균 복구 시간, Mean Time To Repair) 연간으로 환산한 초 수와 가동률로부터 정지 시간을 산출 86,400초(24시간) X 365일 X 0.01% (가동률 99,99%) = 3153.6초 MTTR이 4분인 경우 (MTBF 28일) 99.99% = 60 X 24 X MTBF / (60 X 24 X MTBF + 4) MTTR이 18인 경우 (MTBF 125일) 99.99% = 60 X 24 X MTBF / (60 X 24 X MTBF + 18) 가동률을 높이는 방법 요소 각각의 가동률을 높인다 (서버용 부품 사용, 부품을 이중화, 요소 각가의 가동률 확인) 요소를 조합해 전체의 가동률을 높인다 (다중화 기술을 이용하여 가동률 높임) 적절한 프로비저닝으로 부하 문제를 피한다 (스케일업(서버 성능을 높이는 것), 스케일아웃(서버 수 늘리는 것)) 다중화 구성 요소 Active-Active Active-Standby (Hot Standby (즉시), Warm Standby (나름 준비 필요), Cold Standby (정지)) 문서 작성 도구 Sphinx : sphinx-doc.org Graphviz : www.graphviz.org Blockdiag : blockdiag.com Cacoo : cacoo.com 5) 웹 서비스 운용 1 : 시스템 감시의 기본 2 . 시스템 감시의 구현 감시툴 - Nagios : 감시 기능에 특화 - Zabbix : 감시 기능 외에 그래프화 기능도 있음 모니터링툴 - Cacti : 사용자 관리 기능이 있음. 풀형 데이터 수집 - Nackerel : SaaS형 서비스 감시도 가능 - Monit : 간단함. 사용자 관리 기능 없음. 풀형 데이터 수집 - GrowthForecast : 간단함. 사용자 관리 기능 없음. 푸시형 데이터 수집 시스템 감시 (Nagios: NRPE, Zabbix: Zabbix Agent) - 외형 감시 - 내부 감시 - 서비스 가동 상황 감시(액티브 체크, 패시스 체크(SNMP Trap)), 시스템 리소스 감시 감시 항목을 결정하기 위한 현재 상태 확인 방법 - 방화벽 설정 확인 iptable -nv -L ss -lnp ip6table -nv -L - 프로세스 확인 ps aufx | grep -w 1380 | grep -v grep yum whatprovides /usr/libexec/postfix/master 현재 상태 확인 결과로부터 감시 항목 만들기 a. 실행 프로세스 수를 확인 - I/O 확인 : 서비스/관리 네트워크 입출력, 서비스/관리 파일 입출력 b. 외형 감시의 주요 항목 - HTTP 응답 코드, 내용, 응답시간, 크기 - HTTPS 응답 코드, 내용, 응답시간, 크기 - POP, SMTP, FTP.. 동작여부, 메일 송수신, 파일 PUT/GET 등 - HTTP 시나리오 c. 내부 감시의 주요 항목 - CPU 사용률, 평균 부하, 디스크별 사용률, 디스크별 I/O 요구량, 디스크별 대기 시간, 네트워크 인터페이스별 트레픽 IN/OUT, 로컬에서의 HTTP 접속, 서비스에 사용할 프로세스의 감시, 시스템적으로 사용할 프로세스의 감시 3. 장애가 발생했을 경우의 대응 방법 a. 경보 b. 현상 확인 c. 1차 대응 script -q -C "ssh www.example.com" www.example.com.20151123_09:20:30.log lssh 파일명 #!/bin/bash NOW=$(date +%Y%m%d_%H%M%S) exec script -q -C "ssh $1" $1.$NOW.log chmod a+x lssh ./lssh localhsot export PS1="\D{%Y/%m/%d %H:%M:%S} $PS1" export HISTTIMEFORMAT='%Y-%m-%d %T' 상황 확인용 명령어 일람 w ss -lnp ps aufx df -h top -b -d 1 -n 1 top -b -d 1 -n 1 -a dstat -taf 1 10 mysqladmin processlist -verbose 로그 확인툴 fluentd d. 경보 현상 및 다른 항목 확인하기 e. 사후 작업 f. 수습 6) 웹 서비스 운용 2 6.4. 실시간 모니터링 방법 - 툴 : dstat, top, iostat (yum install dstat, yum install sysstat) dstat - option : -t (일시), -l (평균부하), -m (메모리), -a (cpu, disk, network, paging, system), -f (디바이스별 표시), --output (csv), 1 (1초마다) - dstat -tlaf --output stat.csv 1 3600 iostat - option : -t (일시), -x (확장 상태), -n (NFS상태), 1 (1초마다) - iostat -txn 1 6.5 트러블 대응에 사용하는 모니터링 툴 - tcpdump : 네트웍크 상태 파악 ( tcpdump -i eth0 -n port 80, tcpdump -i lo -n port 3306 ) - strace, lsof : 프로세스 동작 확인 ( ps aufx | grep http[d] | head -3, strace-f -p 5377, lsof -p 5377 ) : 설치 ( yum install strace, yum install lsof ) 7) 웹 서비스 튜닝 1 : 보틀넥을 찾는 방법 7.4 보틀넥을 찾는 방법 - 로그 - Apache에서 보틀넥 찾기 httpd.conf : LogFormat "%h %l %u %t \"%r\" %＞s %b \"%{Referer}i\" \"%{User-Agent}i\" %D"combined (%D로 총 소요시간) - MySQL에서 보틀넥 찾기 slow-query-log=NO slow-query-log-file=mysqld-slow.log long-query-time=10 (show global variables like 'long_query_time'; set global long_query_time=1; show global variables like 'long_query_time';) - mysqldumpslow ( mysqldumpslow -t 3 -s t mysqld-slow.log ) -s ORDER :al (평균 lock시간), ar (평균 송신 행의 수), at (평균 SQL 실행 시간), c (SQL 실행 횟수), l (lock 시간), r (송신 행의 수), t ( SQL 실행 시간) -h HOSTNAME : 조사 대상의 호스트 이름을 지정 -t NUM : 정렬한 결과의 상위에서 NUM 갯수만큼 표시 7.6 보틀넥을 찾는 방법 - 애플리케이션 코드 - XDebug : 애플리케이션 프로파일러 툴 ( sudo yum install php-pecl-xdebug, php.ini ([xdebug] xdebug.profiler_enable=1 ) - KCachegrind, webgrind ls /tmp/cachegrind.out.* 8) 웹 서비스 튜닝 2 : 튜닝 레시피 8.1 포인트별 튜닝 레시피 - 요청 횟수와 데이터 전송량을 줄이는 방법 a) 요청횟수 줄이는 방법 - 파일 결합 : CSS와 JavaScript의 파일 결합 - CSS Sprite : 이미지를 하나로 집약 - 패턴 이미지는 CSS로 구현 - HTTP KeepAlive 유효화 b) 데이터 전송량 줄이는 방법 - CSS나 JavaScript를 minify - 이미지 압축률을 높인다 - 이미지 크기를 작게 한다 - 데이터를 압축하여 전송 - 정적 파일을 브라우저에서 캐시 - CDN 사용 Grunt툴 사용하여 minify화 (http://gruntjs.com) - CSS 결합/minify ( grunt-contrib-cssmin https://github.com/gruntjs/grunt-contrib-cssmin ) - JavaScript 결합 ( grunt-contrib-concat https://github.com/gruntjs/grunt-contrib-concat ) - JavaScript minify ( grunt-contrib-uglify https://github.com/gruntjs/grunt-contrib-uglify ) - CSS Sprite 작성 ( grunt-spritesmith https://github.com/Ensighten/grunt-spritesmith ) Grunt 설치 및 활용 - package.json { "name": "myproject", "version": "0.0.1" } - 필요 라이브러리 설치 yum install npm ImageMagick GraphicsMagick cairo-devel libjpeg-turbo-devel npm install grunt＜cli grunt-contrib-concat grunt-contrib-uglify grunt-contrib-cssmin grunt-spritesmith --save-dev grunt.loadNpmTasks('grunt-contrib-cssmin'); grunt.loadNpmTasks('grunt-contrib-concat'); grunt.loadNpmTasks('grunt-contrib-uglify'); grunt.loadNpmTasks('grunt-spritesmith'); grunt.registerTask('default', ['sprite', 'cssmin', 'concat', 'uglify']); }; - node-modules/.bin/grunt (실행) OS의 CPU 사용률 낮추기 lowait 낮추기 - iotop로 I/O 체크 ( yum install iotop, iotop -P ) - ps로 status D 프로세스 확인 OS의 네트워크 사용량 낮추기 (백업) rsync -az /data/backup/ remote.example.com:/data/backup/web/ tar zcfp - -C /data/backup . | ssh remote.example.com "cat - | tar zxf - -C /data/backup/web" tar cfp - -C /data/backup -I pigz . | ssh remote.example.com "cat - | tar xf - -C /data/backup/web -I pigz" Apache의 CPU 사용률 낮추기 pgrep -P 'cat /var/run/httpd/httpd.pid' | while read echo 'ulimit -n 65535' | tee -a /etc/sysconfig/httpd Apache의 메모리 사용량 낮추기 Apache의 디스크 I/O 사용량 낮추기 httpd.conf (이미지와 같은 정적 파일 로그 출력하지 않도록 수정) SetEnvIfNoCase Request_URI "\.(gif|jpeg|jpg|png|js|css|swf|ico)$" nolog CustomLog logs/access_log combined env=!nolog BufferedLogs On (주의 필요) 애플리케이션 서버의 CPU 사용률 낮추기 Gargbage collector 조정 바이트코드 캐시 이용 (5.4 이전 : apc (Alternative PHP Cache), 5.5 이후 : OPCache) yum install php-pecl-apc php -i | grep apc.enabled 8.2 SQL 튜닝에서의 고속화 SQL 튜닝 툴 EXPLAIN, PROFILING EXPLAIN : SQL 앞에 EXPLAIN을 붙여 실행 계획 확인 - possible_keys, key로 인덱스 확인 - rows 행수 검사는 낮아야 한다 - Extra항목에 Using filesort가 없어야 한다 PROFILING SET PROFILING=1; SQL 실행 SHOW PROFILES; SHOW PROFILE FOR QUERY 1; 8.4 [DB] 스케일 아웃 구현의 예 HAProxy, Keepalived (LVS) |