지밍이 블로그

http://learnbranch.urigit.com/?demo

http://rogerdudler.github.io/git-guide/index.ko.html

http://git-scm.com/book/ko/v1

git

Git은 커밋을 가능한 자유롭게 하고자하여 커밋할 때마다 디렉토리 전체를 복사하지 않음

각 저장소의 이전 버전과 다음 버전의 변경내역("delta")를 저장

대부분의 커밋이 그 커밋위의 부모 커밋을 가리키고 있게 됨

저장소 복제("clone")을 하려면, 모든 delta를 풀어야 함

=> " resolving deltas "

git commit

git branch 

: 하나의 커밋과 그 부모 커밋들을 포함하는 작업 내역

특정 커밋에 대한 reference로 branch를 많이 만들어도 메모리나 디스크 공간에 부담이 되지 않음.

작업내역을 쌓아놓기보다는 잦은 branch 수행으로 작은 단위로 나누는 것이 좋음

git branch newImage

git commit

 : 제어가 master에 있는 상태에서 commit을 수행하여 master branch가 수행됨

다시 돌아가서..

git checkout newImage; git commit

* checkout (이동)

git merge(합치기)

: 여러 브랜치에서 새로 개발한 내용을 합치는 작업

두 개의 부모를 가리키는 특별한 커밋을 만들어냄

=> 두 개의 부모를 가리킴? 한 부모의 모든 작업내역과 나머지 부모의 모든 작업내역, 

그리고 그 두 부모의 모든 부모들의 작업 내역을 포함한다는 의미

master가 제어를 가진 상태에서 

git merge bugFix master (bugFix에 master를 합쳐라/연결하라)

 : master가 두 부모가 있는 커밋을 가리키고 있음

여기서 master에 bugFix를 연결하라/합쳐라

git merge master bugFix

: 모든 커밋의 색이 같아졌으며, 이는 두 브랜치가 모두 저장소의 모든 작업을 포함하고 있음을 의미

bugFix가 이미 master의 부모쪽에 있었기 때문에, 

아주 간단하게 bugFix를 master가 붙어있는 커밋으로 이동시킬 수 있음

git branch bugFix

git checkout bugFix

git commit

git checkout master; git commit

git merge bugFix master

git rebase

: 브랜치끼리의 작업을 접목하는 두번째 방법으로, 기본적으로 커밋들을 모아서 복사한 뒤 다른 곳에 떨궈 놓는 것

커밋들의 흐름을 보기 좋게 한줄로 만들 수 있음. 커밋과 로그이력이 한결 깨끗해 짐

bufFix 브랜치에서의 작업을 master 브랜치 위로 직접 옮기기 (마치 순서대로 개발한 것 처럼)

bugFix가 선택된 상황에서, 

git rebase master

C3는 어딘가 그대로 남아있고 복사본이 생기게 됨

이때 master branch와의 병합을 원하므로, master로 이동 후 

git rebase bugFix

master가 bugFix의 부모로 위치해 있었기 때문에, 더 앞쪽의 커밋을 가리키게만 바꿔주면 손쉽게 위처럼 설정이 가능

git branch bugFix

git checkout bugFix; git commit

git checkout master; git commit

git checkout bugFix

git rebase master

git 작업돌리기

- 개별 파일이나 묶음을 스테이징하기

- 실제 변경을 복구

변경내용 되돌리기

git reset

git revert

git reset은 이전 커밋을 가리키도록 하여 작업을 되돌리는 방법으로 히스토리 변경이라고도 함

git reset HEAD~1

히스토리를 변경하는 git reset은 각자 작업하는 로컬 브랜치에서는 유용하지만,

여러사람이 공유하는 리모트 브랜치에는 적합하지 않음

변경분을 되돌리고, 되돌린 내용을 다른 사람과 공유하는 작업이 필요함

git revert

clz :  0의 갯수를 셈

일반적으로 clz을 하면 0의 갯수를 세서 시프트 하려고 사용함

그러면 원하는 값을 얻을 수 있도록 리눅스는... 그렇게 사용함

가령.. 

way의 갯수가 4개라 값이 3일때, 

현재 way의 값을 알고싶을때, 

이때 clz를 해서 14만큼 시프트연산을 수행하면 내가 원하는 값인 3이 나오게 됨

a = 0b 0000 0000 0000 0011이다.

b = 14

a << b = 0b 1100 0000 0000 0000

[서평/짧은서평] 

"모바일트렌드 2016"  모바일, 온디맨드의 중심에 서다

커넥팅랩 지음, 미래의 창 출판

http://book.naver.com/bookdb/book_detail.nhn?bid=9705742

(본 글은 서평이벤트에 참여하여 작성하였습니다.)

"모바일 트렌드 2016" 이라는 책을 서평이벤트 신청을 통해 증정받게 되었다.

이 책은 모바일과 관련된 비지니스 트렌드의 변화를 중점적으로 소개하는 책으로 

"모바일트렌드"라는 이름으로 출간된 세번째 책이다.

"모바일트렌드 2014"부터 매년마다 출간되어 이번까지 총 3권의 책이 출간되었다.

모바일트렌드 2014 : 이제 모든 비지니스는 모바일로 통한다.

모바일트렌드 2015 : 모바일 혁명이 이끄는 옴니채널의 시대가 온다.

모바일트렌드 2016 : 모바일, 온디맨드의 중심에 서다.

이 책의 제목처럼 실생활에서의 정말 많은 일들이 손안에서 이루어지고 있다.

삶의 질을 풍요롭게하는 IoT부터 편리한 모바일 결제까지 다 알수도 없는 많은 모바일 기반의 서비스들이 출범되고 있으며

이제는 모바일 환경없이는 생활할 수 없는 지경에 이르렀다.

이 책의 구성은, 모바일 트렌드 2015의 리뷰를 시작으로

커머스, SNS, 미디어, 결제, 모바일 전문은행, 스마트폰 시장 그리고 이머징 디바이스와 온디맨드라는 주제로 되어있다.

2016년에 기대되는 온디맨드의 개념과 기존 옴니채널과의 차이점에 대해 설명하고

모바일 환경이 만들어내는 변화와 가치를 각 주제로 풀어나가며

기존의 시장과 새로운 시장을 더불어 설명하고 그 전망을 이야기 하고있다.

너무나 많은 기술의 변화로 급변하는 IT 업계에서 트렌드에 대해 아는 것은 매우 중요한 일이다.

대부분의 사람들이 뉴스나 SNS를 통해 정보를 습득한다.

그 중 경우에 따라서는, 트렌드에 대한 정보를 어쩌면 단편적으로 얻고있을 수 있다. 본인이 그랬기 때문이다.

이 책을 읽은 후 가장 만족스러웠던 점은,

여지껏 머릿속에서 흩어져있던 것들이 연결이 되었다는 것이다.

책을 읽는 내내 집중할 수 있었고 단편적으로 알고있던 내용이나 용어들을 

배경의 흐름에 맞춰 정리할 수 있는 계기가 된 것 같다.

또 한가지 만족스러운 점은 많은 IT 융합 기술을 모바일이라는 범주로 엮어 설명해내고 있다는 것이다.

근래에는 의사, 변호사 공부를 하던 사람들도 IT 융합에 대한 공부를 많이 하고 있다고 하는데, 

이런 사람들을 포함하여 IT 종사자는 아니지만 관심이 있는 많은 사람들이

IT 기술의 트렌드 변화와 전망을 체계적으로 이해하는데 적합한 책이라고 생각한다.

만약 나처럼 총 정리가 필요한 사람이나 IT 기술의 트렌드를 궁금해하는 사람이 있다면,

나는 그들에게 이 책을 "한페이지 혹은 한 문장마다 정리가 되는 책"이라고 추천할 수 있을 것 같다.

(그리고 형광펜도 함께 추천할 것 같다.ㅎㅎㅎ)

놀이기구를 타는 것 처럼 재밌기도 하지만 굉장히 빠르기도하고 그래서 무섭기도 한 IT 분야를,

놀이동산에서 정신없이 놀고 온후에도 집에와서 세세하게 되짚어보며 일기를 잘 쓸 수 있게하는 그런 책 인것같다.

.

.

.

p.s. 얼마전에는 온오프믹스를 통해 이벤트 강연도 있던거 같았다. 

비록 신청마감되어 참석하지는 못하였다.

내년에도 이 책의 시리즈가 나온다면 꼭 읽고싶고, 이벤트도 미리 신청하여 꼭 참석하고 싶다.

# NUMA

# CPU(x86) Ring Level 

CPU 권한레벨, privilege level (= protection rings)

- Ring 0 : 커널, Ring 3 : 유저

- guest OS : R1 or R2

- guest OS에서 H/W로의 명령을 VMM에서 Binary Translations 기술로 가로채고 에뮬레이션

    => Intel-VT, AMD-V에서 지원

#####  네트워크 다중화

# 1. 링크의 다중화와 리눅스 Bonding Driver

<Bonding Driver>

a.  중요파라미터 

- MII(Media Independent Interface) 감시 : NIC Link Pown 발생시 고장으로 간주, 저비용과 단시간으로 구현가능

- ARP(Address Resolution Protocol) 감시 : 고장을 간과할 가능성은 낮으나 ARP 요청을 송신하지 않으면 잘못된 진단으로 판단

b. Bonding Driver 동작모드

#2. 스위치 다중화

: Bonding 드라이버를 사용하여도 동일한 스위치에 접속하여 있다면 스위치 장애에는 대응하기가 어려움

# 3. 스위치 증설 + more

- Boding, Trunking, Link Aggregation, 802.3ad, ARP 사용

- Looping으로 인한 Broadcast Storm 발생

=> STP 사용

##### RSTP 

: Rapid Spanning Tree Protocol

- 스위치 상호간에 BPDU(Bridge Protocol Data Unit)패킷을 교환하여 우선순위 정보 등의 교환과 장애 검출 수행

- RSTP가 동작하는 브릿지에서는 BPDU를 교환하여 상위 브릿질즐 판별(Root Bridge)

=> 우선순위 검사

1. Root 브릿지라고 인식되어있는 브릿지의 브릿지 ID

2. 루트브릿지로의 경로비용

3. 브릿지의 브릿지 ID

4. 상대 브릿지가 BPDU를 송신한 포트의 포트 ID

5. 상대 브릿지로부터 BPDU를 수신한 포트의 포트 ID

* 브릿지 ID (8bytes) : 사용자가 설정한 우선순위 값(상위 2bytes) + MAC(6bytes)

- RSTP에서 port의 역할

: 모든 브릿지의 초기화 과정에서 브릿지 각 포트에 대하여 RSTP상의 역할을 결정

1. 루트포트 : 브릿지 각 포트 중 가장 상위 브릿지와 연결되어 있는 포트

2. Designated port : 하위 브릿지 연결 포트

3. Alternate Port : root port외에 상위 브릿지에 연결되어있는 port

4. Backup port : 다른 designated port로부터 자기자신이 보낸 BPDU를 수신한 port

5. Disable port

<RSTP의 동작>

1. VLAN 도입 : 논리적 네트워크 분할(브로드캐스트 도메인 분할)

- Static VLAN

- Dynamic VLAN

- MAC기반 VLAN : 빈번한 변경이 없는 서버팜에선 상관 없음

- Port기반 VLAN, Tag기반 VLAN  : but, 일반적으로 서버팜에선 빈번한 변화도 고려해야 함

a. Port VLAN : 스위치의 port마다 VLAN ID 할당

- 간단한 구성

- 트래픽과 관계없이 여러포트가 소비됨

=> 대량의 데이터를 다룰 때 서버는 동일한 스위치에서 연결하여 제어되어야 함

b. 태그 VLAN : VLAN ID를 포함한 식별정보(tag)

여러개의 스위치를 걸쳐서 VLAN 그룹을 나눌 수 있음

=> VLAN 테깅 기능을 가지는 장비를 사용해야함 (VLAN 태그를 인식하지 못하면 패킷을 버리기 떄문)

2. 서버팜에서 활용

<모두 다중화>

- WAN 스위치는 각 4개 포트만 이용하고 낭비가 심함

- 대체장비가 WAN쪽 스위치로는 연결되지 않음

물리적 구조의 이유로 활용이 적음

- LVS만 구성이 특수함(NIC가 4개 필요)

* 모두 다중화에서 동일한 스위치에 모두 구성으로 변화    

<동일한 스위치에 모두 구성>

- but, 브로드캐스트/멀티캐스트 frame이 모든 포트로 포워딩 됨!!

* VLAN 등장 

< Port VLAN >

- VLAN을 WAN구간과 LAN구간으로 나누어 분류했지만, Load Balancer는 NIC가 4개여야하며, 

장애에 대비해 대체장비에도 4개의 NIC를 구성해야함

* VLAN을 태깅 기반으로 구성

< Tag VLAN>

3. 물리적 구성의 단순화

: 논리적으로 구성할 VLAN 환경에서도 VLAN 구성에 따른 병목현상이 있을 수 있으므로 애초부터 물리적 구성을 잘해야함

4. 성능튜닝

I/O <-> OS

"top", "ps", "sar" 명령어

<병목 규명을 위한 작업>

- Load Average 확인 : top, uptime 명령어

- CPU, I/O 중 병목원인 조사

CPU : ps, strace, oprofile

I/O : sar, vmstat

5. 프로세스 상태변화

a. Process discripter 상태

b. Load Average로 환산되는 대기상태

* 프로세스 수행 상태 변화

TASK_RUNNING이면서 실행 중

TASK_RUNNING

TASK_INTERRUPTIBLE

TASK_UNINTERRUPTIBLE

(TASK_RUNNING, TASK_UNINTERRUPTIBLE. 이 두 상태만 Load Average 계산에 포함)

즉, CPU를 사용하고자 해도 다른 프로세스가 CPU를 사용하고 있어서 기다리고 있는 프로세스

계속해서 ㄱ처리하고자 해도 디스크 입출력이 끝날때까지 기다려야하는 프로세스

c. Load Average를 계산하는 커널코드 확인

- kernel/timer.c, calc_load()

: avenrun 전역변수에 "count_active_tasks()" 값을 저장

- kernel/sched.c, nr_active()

: for_each_online_cpu() // cpu 별로 계산할 때 사용하는 매크로

- cpu_rq()    // cpu에 엮여있는 runqueue얻는 매크로

=> CPU의 runqueue를 차례로 확인

- cpu_rq(i) -> nr_running

cpu_rq(i) - nr_uninterruptible

즉, averun값은 Load Average 값

> cat /proc/loadavg

=> averun 배열의 값을 정형화해서 출력 (TASK_RUNNING, TASK_UNINTERRUPTIBLE 합산)

6. CPU 사용률과 I/O 대기율

a. 원인 찾는 방법

- sar(System Activity Reporter)로 CPU사용률, I/O 대기률 확인 : "%user", "%systemz)

sysstat 패키지에 포함

- 시스템(커널) 모드, 유저모드

- I/O 바운드인 경우의 sar : "%iowait"

7. multi CPU와 CPU 사용률

sar -P ALL | head -l3

(-P : 프로세서별로 조회, 이 설정이 없으면 합계로 나옴)

8. CPU 사용률이 계산되는 원리

a. Timer interrupt로 커널 내부에서 수행

b. CPU 용으로 준비된 전용공간인 cpu_usage_stat구조체에 계산 결과 저장

CPU마다 별도의 공간에 데이터를 저장하므로 sar등에서 CPU별 정보를 얻을 수 있다.

* Process Accounting

: 프로세스 전환을 위해 각 프로세스가 생성된 후부터 CPU 시간을 이용한 정보

c. Process Accounting을 CPU별로 합산해서 단위시간으로 나누어 CPU사용률을 계산

9. Process Accounting 커널코드

a. include/kernel-stat.h

- cpu_usage_stat : 계산된 CPU별 정보를 저장하는 구조체

- kernel_stat : DECLARE_PER_CPU() 매크로

b. kernel/timer.c, update_process_times()

: 실제 process accounting 처리

(1) current 매크로로 현재 프로세스의 프로세스 디스크립터 얻기

(2) user_tick 값을 보고 처리를 분기

(3) 최근 시간이 kernel mode였는지 user mode였는지에 따라 각각 account_system_time(), account_user_time()을 호출 (kernel/sched.C)

(4) CPU 용으로 cpustat 구조체를 얻음

(5) cpu_add 매크로로 현 프로세스의 uptime(cpu소비시간)을 계산

(6) cpu_stat의 nicert user값에 cputime64_add 매크로로 동일한 경과시간을 갱신

(7) id/e, 시스템모드로 계산하고 있는 시간, I/O를 기다리는 시간

=> cpu_usage_stat 항목 갱신

10. Thread, Process

*Apache의 경우 MPM으로

- prefork하면 멀티쓰레드

- worker하면 멀티쓰레드+ 멀티프로세스

멀티프로세스 : 각각 독립적인 메모리 공간,

멀티스레드 : 프로세스 별로 메모리 공간을 공유. 메모리 공간 전환이 낮아지므로 전환 비용도 줄어듬

a. 커널 내부에서의 프로세스와 스레드

: 커널 내부에서는 스레드 하나에 프로세스 디스크립터 하나가 할당되며, 스레드와 프로세스가 동일한 로직으로 스케쥴링 됨

스레드를 LWP(Light Weight Process)라고 함

- "ps" 명령으로 멀티스레드를 확인할 때 -L 옵션이 필요

ps -elf | grep (CMD|mysql)

- PID는 프로세스별로 같고 스레드 ID인 LWP는 다름

- 단일 프로ㅔ스에 복수 스레드 동작

- "NLWP" Number of LWP의 약자인 명령어로 스레드 갯수 출력

b. LinuxThreadset

- NPTL, Native POSIX Thread Library

- LinuxThread

=> 리눅스의 여러가지 멀티스레드 구현형태

c. ps, sar, vmstat

(1) ps : Report Process Status

<항목>

- %CPU : PS 명령 수행하는 프로세스의 CPU 사용률

- %MEM : 메모리 백분률 환산 값

- VSZ, RSS : 각 해당 프로세스가 확보하고 있는 가상 메모리 영역과 물리 메모리 영역의 크기

- STAT : 프로세스 상태

- TIME : CPU 사용기간

- VSZ : Virtual Set Size

- RSS : Resident Set size

- Virtual Memory

- Paging

* 실제 매핑(실제 물리메모리와의 매핑)은 실제 쓰기 작업시에 이루어짐

< 가상메모리 구조 도입의 장점 >

- 메모리 over-wrapping 가능

- 흝어져있는 물리메모리 공간들을 가상의 연속된 공간으로 사용가능

- 물리메모리 부족 시, 우선순위에서 밀린 순으로 메모리 매핑을 해제하여 2차 기억장치로 swapping을 수행

-서로 다른 프로세스가 창조하는 가상메모리 영역을 동일한 물리메모리에 대응

=> 두개의 프로세스가 메모리 공유 (ef. IPC 공유메모리..)

(2) TIME은 CPU 사용시간

: 프로세스 디스크립터에 기록된 CPU 사용시간

(3) Blocking / Busy Loop 차이를 "ps"명령어로 확인

"ps"를 실행

- STATE 필드가 R(running)이면서, CPU사용 시간인 TIME필드가 계속 증가하면, Busy Loop상태

- STATE 필드가 S(TASK_INTERUPTIBLE)이면서 CPU사용시간이 증가하지 않으면, Blocking된 상태

(4) sar (System Activity Reporter)

: OS가 보고하는 각종 지표/정보

- sysstat 패키지에 포함

- 사용방법 : 

과거의 동계데이터조회(default)

현재 데이터 주기적 확인

- sar에는 sadc라는 백그라운드 프로그램이 포함

- sysstat패키지 설치시 자동으로 sadc가 커널로부터 레포트를 수집하여 저장함

(sar명령어를 옵션없이 사용하면 sadc가 수집한 cpu사용률의 과저 통계를 참고할 수 있음, default는 0:00부터의 데이터)

- 어제 이전의 데이터 조회 : -f옵션 사용. "/var/log/sa" directory에 log파일 저장

- 주기적으로 현재 데이터 조회 : "sar 1 1000", 1초 간격으로 1000회

- cpu 사용률 확인 : "sar -u"

* user/system/iowait/idle 값이 중요

- 로드에버리지 확인 : "sar -q", 실행큐에 쌓여있는 프로세스 수 등등

- 메모리 사용량 확인 : "sar -r", 물리메모리 이용현황

<항목>

kbmemfree 

kbmemused

memused  : 물리메모리 사용률

kbbuffers  : 커널 내 버퍼로 사용되고 있는 물리 메모리량

kbcached  : 커널내에서 캐시메모리로 사용중인 물리 메모리량

kbswpfree

kbswpused

- "sar -w과 조합하여 스왑이 발생한 경우, 해당 시간대의 메모리 사용량 확인

(5) I/O 부하경감과 페이지 캐시

- 4KB의 페이지 단위

- 캐시메모리, 페이지캐시

!! 리눅스의 페이지 캐싱 동작은 

가능한 남아있는 페이지를 페이지 캐시로 활용하고 함 !!

=> 시간이 지남에 따라 kbmemfree가 줄어느는데, 이는 위와같은 이유로 kbcache가 증가하기 떄문이다.

(6) 페이지 캐시에 의한 I/O부하의 경감 효과

: 디스크 액세스를 줄이기 위해 캐시를 효율적으로 잘 사용해야 함

- 메모리 증설

- 메모리 증설이 어렵다면,

데이터를 분할해서 각각의 서버에 위치시키도록 하는법을 검토

(7) 페이지 캐시는 한 번의 read에서 시작

"sar -w" 스왑 발생 상황 확인

pswpin/s : 스왑인 상황

pswout/s : 스왑아웃 상황

(8) vmstat : 가상메모리 관련 정보, report Virtual Memory Statics

ex. vmstat 1 1000

- bi : 블록디바이스에서 수신한(in) 블럭

- bo : 블록디바이스에서 송신한 블럭(out)

cf. 

- character device : 바이트 단위 I/O

- Block device : 블록단위 I/O

(9) OS 튜닝 

: 부하의 원인을 알고 이를 제거하는 작업 

a. 최근의 OS나 미들웨어

b. 메모리 증설과 캐시영역 확보

- 데이터량이 너무 많은지 체크

- 애플리케이션들에서의 처리 알고리즘 변경

(10) 아파치 튜닝

a. 병렬처리의 구현모델

- 프로세스를 여러개 생성하여 처리하는 멀티프로세스 모델

- 멀티쓰레드 모델

- 입출력을 감시해서 이벤트가 발생하는 타이머에 처리를 전환하는 시그널스레드로 이벤트 모델

b. MPM, multi-processing Module

: 아파치에서 병렬처리를 수행하는 코어 부분

<구현모듈>

- prefork : 멀티프로세스 모델, 안전지향, 후방호환성이 높은 MPM

- worker : 멀티프로세스 + 멀티스레드, 확장성이 높은 MPM

c. worker 모델이 메모리 효율이 좋음

- copy on write

- context switching의 차이

: 메모리전환이 없으면 TLB를 그래도 유지

* TLB : 메모리의 가상 주소를 물리주소로 변환하는 처리를 가속화 하기위한 캐시로 CPU내부의 구조.

context switcing 발생 시 TLB 초기화 됨 (비용이 큼)

d. 아파치에서 하나의 클라이언트 요청에 대해 하나의 프로세스or스레드가 응답

=> 스레드건 프로세스건 갯수가 중요

(11) httpd.conf

a. MaxClient : 동시에 접속 가능한 client 수

b. Server Limit Thread  or Process 수 (고려사항)

- 서버가 탑재되어있는 물리 메모리 용량 : "free"로 하드웨어 스팩확인

- 프로세스 하나당 평균 메모리 소비량 : "ps", "top" 명령어, "proc" 파일( /proc/<PID>/stams)

ex. 

<가정>

- 메모리 4GB

- httpd 프로세스 하나당 100MB의 메모리를 사용

- OS가 512MB 사용

-> 4GB - 512MB = 3.5GB를 httpd에 할당

-> 3,500 / 100 = 35개

-> MAX client의 갯수는 35개

c. copy-on-write

: 부모자식 프로세스 간 메모리 공유

- fork 는 비용이 많이 듬

- 가상공간을 각각 만들지만 물리 공간을 하나로 공유

=> 시간이 지날수록 단편화에 의해서 공유률이 저하됨

d. MaxRequestsPerChild

(12) MySQL 튜닝

a. 서버측

- mysqld 파라미터 튜닝

: 메모리, 디스크 I/O 관련 파라미터

(디스크 I/O와 관련한 커널파라미터, 적절한 f/s선택과 mount 옵션들)

- 파티셔닝

: 데이터를 primary key등을 기반을 분할하여 DB서버와 나누기

(데이터를 작게 유지할 수 있고, 캐시에 올리기 쉬워지고, 액세스 분산의 효과가 있음

but, SQL레벨에서의 쿼리가 복잡하며 애플리케이션 측의 부담이 증가)

b. 서버측 이외

- 데이블설계(인덱스, 의도적 비정규화)

- SQL 최적화 (인덱스사용, 테이블결합 순서 및 방법 조정)

c. 주변 시스템 튜닝

- 클라이언트와 DB 서버사이에 memcached같은 캐시서버 놓기

(13) 메모리 관련 파라미터 튜닝 (MySQL)

튜닝의 포인트

참고로 특정 DB 서버(실메모리 4기가)의 실제 설정값

a. 버퍼의 종류 

- global buffer : mysql에서 내부적으로 하나만 확보되는 버퍼

- thread buffer : 커넥션(스레드)별로 확보되는 버퍼

b. 지나친 할당 주의

: 버퍼에 많은 메모리를 할당하면 좋지만 over되면 swapping되므로 성능저하

tip! 

MyISAM 테이블은 MySQL레벨의 파라미터 튜닝보다는, MyISAM의 데이터파일이 OS의 디스크캐시에 오르도록 조정하는 게 좋음

c. 메모리 관련 파라미터

- innodb_buffer_pool_size

: InnoDB 데이터나 인덱스를 캐시하기 위한 메모리 영역(G-buffer)

- innodb_addtitinal_mem_pool_size

: InnoDB의 내부데이터 등을 저장하기 위한 메모리 영역

(크게는 안해도 됨, 어차피 부족하면 에러나서 그때 수정하면 됨)

- innodb_log_buffer_size

: InnoDB의 갱신로그를 기록하는 메모리 영역

(버퍼는 트랜젝션이 commit되거나, 매초 disk로 flush 되므로 다른 파라미터를 더 크게 하는게 좋음)

- innodb_log_file_size

: 갱신로그를 기록하는 디스크상의 파일 (튜닝에 있어서 중요!!)

1MB < innodb_log_file_size < MAX_innodb_log_file < 4GB(32비트 기준) 

MAX_innodb_log_size = innodb_buffer_pool_size / innodb_log_files_in_group

innodb_log_file_size가 클수록 crash recovery 시간이 오래걸림

- sort_buffer_size : ORDER BY나 GROUP BY에 사용되는 메모리 영역(T-buffer)

- read_rnd_buffer_size : 정렬부에 레코드를 읽을 때 사용되는 메모리 영역

=> 디스크 I/O가 줄어들기 때문에 ORDER BY의 성능을 증가시킴(T-buffer)

- join_buffer_size : 인덱스를 사용하지 않는 테이블 결합시 사용되는 메모리영역

=> 매 초에 인덱스를 사용하지 않는 결합은 피해야함

(즉, 크기를 크게하지 말자)

- read_buffer_size : MyISAM의 키(index)를 메모 상에 캐시하는 영역

=> global buffer로 클수록 좋음. MyISAM을 많이 사용하면 크게!

- myisam_sort_buffer_size : MyISAM REPAIR TABLE, CREATE INDEX, ALTER INDEX의 경우 인덱스 정렬에 사용하는 메모리 영역

=> 통상 DML쿼리에서 사용되는 것이 아니므로 크게는 안해도됨

(14) Nagios

: 이상, 에러감시

- ping

- TCP 접속에 의한 각종 서비스 감시

- SNMP에 의한 호스트 상태 감시

<응용>

- 가동률 측정

- 독자적인 플러그인(MySQL리플리카 감시)

MySQL 프로세스 수 감시, memcached  감시 등

<구현방법>

- NRPE(Nagios Remote Plugin Executor)를 이용한 방법

- SNMP 이용방법

- 독자플러그인 이용방법

(15) Ganglia  서버 리소스 모니터링

- CPU 사용률

- 메모리 사용률

- Load Average

- 네트워크 트래픽

(16) Puppet 서버 관리 툴

- 신규서버 투입

- 기존 서버 설정 변경

(17) daemontools

: 데몬 가동 관리

background로 실행안됨. foregound로 전한하기 위한 daemontools에 포함된 fghack을 사용

(18) PXE, initramfs

: 네트워크 부트 동작

*initpramfs

: 커널이 루트 파일시스템을 마운트하고 init을 실행하기 전에 커널의 외부에서 밖에 수행할 수 없는 초기화를 하기 위한 도구

- 커널이 루트 파일 시스템을 마운트 할 때 필요한 드라이버 모듈을 커널에 로드해줌

- 필요한 파일을 모아서 cpio로 정의 후 gzip으로 압축한 파일

- 부트로더가 커널을 메모리에 읽을 때 커널과 함께 메모리에 로드됨

- Diskless system

- NFS나 메모리 파일시스템에 루트 파일시스템을 두고 diskless system 구현이 가능 (서버고장발생 감소)

* PXE(Pre-eXecution Enjoinment)

- BIOS 초기화, 확장 BIOS 스캔 후 PXE BIOS 등록

- PXE라 부팅 바이오스로 선택, 제어권이 넘어옴

- PXE BIOS가 DHCP를 사용하여 IP통신 준비, 파일버서구조와 부트로더 파일명을 얻어옴

- 파일서버로 부트로더를 얻어서 실행한 후 제어권을 넘김

- 부트로더 실행, 파일서버로부터 부트로더 자신의 설정 파일 얻기

(파일 서버의 주소는 PXE BIOS로부터 부트로더로 통지)

- 부트로더는 실행할 커널과 설정파일에 지정되어있다면 initramfs의 파일을 파일서버로부터 얻어서 메모리상에 올린 후 커널에 제어권을 넘김

note. PXE BIOS가 서버로부터 파일을 얻기위해 TFTP사용

=> Trivial File Transper Protocol, UDP 기반

<필요항목>

- PXE를 지원하는 NIC, DHCP서버, TFTP서버

- PXE에 맞는 부트로더, 커널, initramfs라는 루트파일시스템을 초기화하는 시스템, 루트파일시스템 

(19) 원격관리

관리회선

시리얼콘솔

IPMI, Intelligent Platform Management Interface

=> 하드웨어 구현(free 버전도 있음)

Magic SysRq

WatchDog 타이머

Kdump

...

(20) 웹서버 로그관리

- Syslog : 유닉스 계열 OS에서 로그 수집

- Syslog-ng

[서버/인프라를 지탱하는 기술]

# RAID

#1. 스토리지 서버의 동기화

#2. DRBD : Distributed Block Device

- 큰 용량의 데이터를 복제 시 부하가 발생하는데 이를 해결하기 위해 등장

- HA, HA cluster 구성 시 유용한 블록디바이스를 제공하는 SW

- 네트워클 이용한 RAID1(미러링)

- Active/Backup 구성(default)

- 커널/유저 모듈

- 커널모듈 : 디바이스 드라이버

- user모듈 : 제어프로그램

# NFS 서버 장애 극복 시 주의점

- NFS 서버가 죽고 새로운 NFS 서버가 마운트

- NFS 클라이언트는 이 사실을 모름

< 해결방법 >

1. /var/liv/nfs  => nfs 접속정보 동기화 (미러링)

cf. 배포판에 따라서 export fs 명령

2. nfsd 파일시스템 이용 (nfs 서버 다중화를 위한 리눅스 고유 기능)

* 100% 안전 보장을 위해서 백업은 필수

[서버/인프라를 지탱하는 기술]

# 1. 주소변환 라이브러리를 이용한 다중화와 문제점

/etc/resolv.conf

a. 주소변환 라이브러리의 문제점

: 질의가 타임아웃이 되면, 다음 네임서버로 질의

b. 대기시간의 문제 => 성능저하

c. 영향력이 큰 DNS 장애

: DNS 서버의 장애는 영향을 밈치는 범위가 큼

 but, 장애 발생지점 찾기가 어려움

# 2. 서버팜에서의 DNS 다중화

: DNS 클라이언트의 주소변환 라이브러리가 DNS버서의 이상을 검출하려면, Time-out을 기다려야 함

=> 비효율적. 서버팜에서 DNS를 다중화하여 DNS 서버측에 무정지 할 수 있는 대책을 마련하자! 

=> VRRP, Load Balancer

a. VRRP로 DNS 다중화

b. DNS 서버의 부하분산

- Active/Backup

- Active/Active

[서버/인프라를 지탱하는 기술]

# 스토리지 서버의 필요성

: 웹서버에 요구되는 기능이 많아지므로 일반적으로 대용량 스토리지 서버에 파일을 저장하고 웹서버에서 'NFS' 마운트를 사용하여 구성

but, 

1. 스토리지 서버는 단일 장애점이 되기 쉬움

mount 옵션 : soft, hard(default), intr

2. 병목이 되기 쉬움

NFS 서버의 분할을 수행하여 병목을 해결하려고 해도 파일 동기화가 문제

# 이상적인 스토리지 서버

: HTTP를 스토리지 프로토콜로 이용. "write"만 NFS 이용(마스터서버)

- 경량  web server 사용

- CGI나 SSI 등의 동적페이지 생성 기능은 불필요

- 고속으로 정적파일전송하기가 중요

- thttpd를 이용해 HTTP를 지원 => 성능향상

스토리지 서버의 메모리에 캐싱된 데이터를 오직 전송하기만 하면 됨.

(스토리지 서버 I/O부하 줄임)

- NFS보다 "서버<->클라이언트"의 결합이 느슨하여 Application에서 자유로운 timeout 설정이 가능하며, 

스토리지 서버 장애에 대해 어느정도 도움을 줄 수 있음

cf) 

a. khttpd : 리눅스 커널 모듈로 구현된 웹서버

- 커널 공간에서 동작, 성능 높음

- 불안정...

b. thttpd / libhttpd : 작고 가벼움을 목표로하는 웹서버 software

[서버/인프라를 지탱하는 기술]

### MySQL Replication

# 싱글 Master, 멀티 Slave

cf) Write Cache, RAID구성을 함께

but, BBU(Battery Backup Unit)이 함께 탑재해야 Write Unit이 유효할 수 있음

# 비동기 데이터 복제, SQL문 단위로 수행

# replication 원리

- I/O Thread, SQL Thread

- Binary Log, Relay Log

- Position 정보

1. I/O Thread, SQL Thread

- I/O Thread, SQL Thread : 마스터에서 얻은 데이터를 Relay Log에 기록

- SQL Thread : Relay Log를 읽어서 실행만 수행

=> thread 분리 : 리플리케이션 지연 줄이기

2. Binary Log, Relay Log

- Binary Log : 데이터를 갱신하는 처리만 기록

데이터를 참조하는 쿼리는 기록되지 않음

replication 외에도 full-backup에서 갱신된 내용만 보관할 때 사용

text 형식이 아니고 Binary 형식이므로 에디터로는 볼 수 없고 mysqlbinlog 명령어 사용

- Relay Log : Slave의 I/O Thread가 마스터로부터 갱신로그(갱신관련 쿼리를 기록한 데이터)를 수신해서 슬레이브에 저장

바이너리 로그와 내용은 동일함

but, 필요없어지면 SQL Thread에 의해 자동 삭제

- Position 정보 : 리플리케이션의 완료된 위치 정보

master.info

"SHOW SLAVE STATUS" 

# my.conf

[mysqld]

server.id, log-bin, log-bin-index, relay-log, relay-log-index, log-slave-updates 

# replication용 사용자 생성

"REPLICATION SLAVE" 권한

Grant Replication slave on *.* to repl'192.168.31.0/255/255/255/0' identified by 'password';

# replication을 위해 필요한 데이터

=> full-dump + position정보

1. mysqld 중지

2. MYSAM이나 InnoDB의 데이터 파일이 있는 MySQL 데이터 디렉토리를 그대로 tar로 복사.

LVM 사용중이면 해당 snapshot 기능 이용

(position 정보도 잊지말기)

3. mysqld를 중지할 수 없을 때

갱신 관련 쿼리를 막은 상태에서 Full-dump를 수행

"SHOW MASTER STATUS" 결과를 메모

# MySQL Slave + 내부 load-balancer

- 조작쿼리(insert, delete, update)는 Master로

- 조회쿼리(select)는 slave로 하여 부하분산

* 여러 slave 부하분산

1. application으로 부하분산 (ex. 계층을 분산하는 O/R mapper)

2. 로드밸런서

# 내부 로드밸런서 구축

* 내부 밸런서의 주의사항, 분산 방법(lvs_method)을 'NAT'가 아닌 'DSR'로 설정해야 함

[서버/인프라를 지탱하는 기술]