Search
📚

대규모 서비스를 지탱하는 기술

이 책을 읽게된 이유, 그리고 나의 고민

신세계아이앤씨에 신입으로 입사해서, 이마트 POS서버 파트로 배정받았을 때 가장 힘들었던 것은 전반적인 서버 인프라에 대해 이해하는 것이었다. Spring과 Java 등 어플리케이션과 관련된 사항은 인턴 교육을 통해 (조금이나마) 익혔으나, 서버 인프라와 관련된 지식은 거의 만무하다고 할 수 있었다. (학부생 때 배웠던 이론 지식은 별 소득이 없던 인턴 생활과 취준 생활동안 거의 휘발되었으니 논외..) 인턴 교육시에도 클라이언트 개발에 대한 교육을 받았고, 입사하면 당연히 클라이언트개발을 하리라 생각했던 내가 서버 담당자가 되다니.. 신입 온보딩 교육에서 담당님들이 나누시던 대화가 마치 암호처럼 들렸던 기억이 난다.
내가 입사했을 당시, 이마트 POS의 중앙서버는 대규모 데이터 처리를 위해 기존 서버를 AP 및 DB서버로 분산하여 인프라를 확장하던 단계였다. Active-Stand by, HA, RAC, Load Balancing, L4 Switch 등.. 회의에 들어갔더니 처음 듣는 단어들이 쏟아졌다. 모르는 단어가 등장할 때 마다 열심히 받아쓰기를 해서 구글에 검색해가며 공부했다. 연초와 연말과 같이 유통업 특성 상 트래픽이 폭발적으로 증가하는 특정 시기가 되면 OS/DB 사용률을 체크하고 장애에 대비하곤 했는데, 지금 돌이켜생각해보면 담당님들이 하는 작업을 곁눈질로 보고 배워 처리했던 것 같다. 연차가 쌓이고, 서버 업무를 한 지 꽤 시간이 흐른 지금은 인프라와 ‘대규모 서비스를 지탱하는 기술’에 대해 어느정도는 이해하고 있지만, 그것이 깔끔히 정리되어 존재한다기 보다는 마치 생존 능력(?)처럼 체화되어 머릿속에 산재되어 있는 것 같다는 생각이 들었다.
이직을 준비하고, 입사일이 조금 남은 지금 웹서비스를 위한 전반적인 기초 지식을 탄탄히하고 대규모 서비스에 대비하는 방법을 익혀두기위해 이 책을 읽어나가기로 했다. 이 책은 일본의 ‘하테나’라는 웹 서비스의 서비스 규모가 커짐에 따라, 대규모 서비스를 처리하기 위해 겪었던 고충과 그를 해결하기 위한 고민, 그리고 해결을 위한 인프라 확장 방법론들을 자세히 기술한 책이다. 이 책을 통해 메모리나 디스크, CPU, I/O부하 처리, OS, 하드웨어, 네트워크 등 등 웹 서비스 개발자들이 대규모 데이터를 처리하기 위해 반드시 알아야할 필수 기술에 대한 토대를 다질 수 있었다. 더불어, 첫 직장에 입사하기 전에, 실무에서 인프라를 관리하기 전에 봤더라면 인프라 관련 지식을 수직으로 키울 수 있었을지도 모른다는 생각이 들었다.
이 전에 읽었던 개발 서적을 Chapter 별로 요약 정리했던 것과 다르게, 이 책은 Chapter에 상관없이 필요한 핵심 내용만 요약하려고 한다.

소규모 서비스와 대규모 서비스의 차이

확장성 확보, 부하 분산 필요

•
대량의 액세스가 있는 서비스에서 부하를 처리하는 방법
◦
스케일 아웃 : 서버를 횡으로 전개, 즉 서버의 역할을 분담하거나 대수를 늘림으로써 시스템의 전체적인 처리 능력을 높여서 부하를 분산하는 방법. (전략의 기초, 트렌드!)
▪
저가의 하드웨어를 횡으로 나열해서 확장성을 확보
▪
비용이 절감되는 반면, 다양한 문제가 발생
•
사용자의 요청을 어떻게 분배할 것인가? → 로드밸런서를 사용해서 해결
•
데이터 동기화는 어떻게 할 것인가?
•
네트워크 통신의 지연시간을 어떻게 생각해볼 수 있을까?
◦
스케일 업 : 하드웨어의 성능을 높여 처리능력을 끌어올리는 방법

다중성 확보

•
시스템은 다중성을 지닌 구성이 필요하다.
◦
특정 서버가 고장나거나 성능이 저하되더라도 서비스를 계속할 수 있는 구성으로 할 필요가 있다.
•
스케일아웃을 해서 서버 대수가 늘어나면, 서버의 고장률도 필연적으로 올라가게 된다.
•
웹 서비스는 언제 어떠한 경우라도 고장에 대해 견고해야한다.

효율적 운용 필요

•
다수의 서버가 어떤 상황에 있는지 파악하고, 대규모 시스템을 건강한 상태로 유지하기 위한 효율적 운용을 수행해야 한다.

개발자 수, 개발 방법의 변화

•
개발 표준화는 어떻게 할 것인가?
•
소스코드 관리는 어떤 버전 관리 시스템을 통해 할 것인가?
•
팀 매니지먼트가 필요해진다.

대규모 데이터 처리의 어려운 점

메모리 내에서 계산할 수 없다.

•
규모가 커지면 데이터가 너무 많아서 메모리 내에서 계산할 수 없으므로, 디스크에 두고 특정 데이터를 검색하게 된다.
◦
데이터 건수가 많으면 그만큼 입력 데이터 건수가 늘어나므로 계산량이 많아진다.
◦
가장 문제가 되는 것은, ‘디스크를 읽고 있다’라는 점이다.
◦
메모리 내에서 계산할 수 있다면, 아무리 무식한 방법으로 하더라도 계산은 빨리 이루어져 200초나 기다리는 일은 없게 된다.
•
디스크는 메모리에 비해 상당히 느리므로 I/O에 시간이 소요된다.
•
메모리와 디스크의 속도차 - 메모리는 디스크에 비해 10^5 ~ 10^6배 이상 고속이다.

디스크는 왜 늦을까?

•
디스크는 원반의 회전 등의 물리적인 동작을 통해 데이터를 읽어낸다. → 물리적인 구조가 탐색 속도에 영향을 준다.
◦
❹ 부근에 데이터가 1바이트 저장되어 있다.
◦
그림의 좌측에 자기를 읽어들이는 ‘헤드’가 있다. 이 헤드가 달라붙는지 아닌지에 따라 자기를 읽어내 데이터를 읽어내는 구조로 되어있다.
▪
읽어야할 데이터가 원반 안쪽 ❸에 놓여있다면, ❹에서 ❸부근으로 데이터 헤드를 옮기는 작업이 필요하다.
▪
여기서 데이터를 읽어들일 때 ❺와 같이 회전하고 있다고 하면, 원반 상태의 ❸위치가 이미 헤드보다 조금 앞으로 가버려서 원하는 위치를 읽기 위해 원반을 한 바퀴 더 돌려야 한다.
•
디스크에서는 헤드의 이동(❹)과 원반의 회전(❺)이라는 두 가지 물리적인 이동이 필요하지만, 오늘날의 기술로도 원반의 회전속도를 빛의 속도까지 근접시킬 수는 없다.
◦
디스크에서는 ❹,❺ 각각 밀리초(10^-3초) 단위, 합해서 수 밀리초나 걸린다.
◦
메모리는 1회 탐색할 때 마이크로초면 되지만, 디스크는 수 밀리초가 걸린다.
•
❻과 같이 데이터가 뿔뿔이 흩어져서 배치되어 있고, 이분탐색 등 여기저기에서 찾아야하는 알고리즘을 사용한다면, 디스크는 계속 회전할 수 밖에 없다. 또한, 경우에 따라서는 헤드도 이동해야한다.
◦
결과적으로는 상당한 시간이 걸린다.
•
그러나, 데이터가 메모리상에 있다면 탐색할 때 물리적인 동작 없이 실제 데이터 탐색 시의 오버헤드가 거의 없으므로 빠르다.
•
탐색에 사용되는 것이 CPU의 캐시에 올리기 쉬운 알고리즘이나 데이터 구조라면, 메모리 내용이 CPU캐시에 올라가므로 더욱 빨라져 나노초(10^-9) 단위로 처리할 수 있다.

OS 레벨에서의 연구

•
디스크는 느리지만, OS는 이것을 어느 정도 커버하는 작용을 한다.
•
❼과 같이 OS는 연속된 데이터를 같은 위치에 쌓는다. → 데이터를 읽을 때 1바이트씩 읽는 것이 아니라 4KB 정도를 한꺼번에 읽도록 한다.
◦
1번의 디스크 회전으로 읽는 데이터 수를 많게 한다. → 디스크의 회전 횟수를 최소화할 수 있게 된다.
◦
그렇지만 결국 회전 1회당 밀리초 단위이므로 메모리와의 속도차를 피할 수 있는 것은 아니다.

전송속도, 버스의 속도차

•
메모리나 디스크 모두 CPU와 버스로 연결되어 있다.
•
전송속도란? 찾은 데이터를 디스크에서 메모리로 보내거나, 메모리에서 CPU로 보내는 등 컴퓨터 내부에서 전송하기 위한 속도이다.
•
메모리와 CPU는 상당히 빠른 버스로 연결되어 있으므로 7.5GB/초 정도 나오지만, 디스크는 58MB/초 정도밖에 나오지 않는다.

규모조정의 요소

규모조정, 확장성

•
스케일아웃 vs 스케일업
◦
스케일 아웃 전략이 주류
◦
웹 서비스에 적합한 형태, 비용 저렴, 시스템 구성에 유연성이 있기 때문에
•
스케일아웃은 하드웨어를 나열해서 성능을 높임
◦
하드웨어를 횡으로 전개해서 확장성을 확보
◦
CPU부하의 확장성을 확보하기는 쉽다.

규모조정의 요소

•
CPU 부하
◦
애플리케이션에서 계산을 수행하고 있을 때
▪
HTTP 요청을 받아 DB에 질의하고, DB로부터 응답받은 데이터를 가공해서 HTML로 클라이언트에 반환할때는 CPU 부하만 소요된다. → AP서버
•
I/O 부하
◦
DB서버 측면에서는 I/O부하가 걸린다.

웹 애플리케이션과 부하의 관계

•
웹 애플리케이션에 , 라는 요청 → ❸DB에 도달해서 I/O 발생 → I/O가 발생해 되돌아온 콘텐츠를 변경 → 클라이언트로 응답
•
기본적으로 AP서버에는 I/O부하가 걸리지 않고, DB측에 I/O부하가 걸린다.
◦
AP서버는 CPU부하만 걸리므로 분산이 간단하다.
▪
데이터를 분산해서 갖고 있는 것이 아니므로, ❷’❷”와 동일한 호스트가 동일하게 작업을 처리하기만 하면 분산 가능
▪
서버 대수를 늘리기만 하면 간단히 확장
▪
요청을 균등하게 분산하는 것은 로드밸런서라는 장치 사용
◦
I/O부하는 단순히 서버를 늘려서 분산이 불가능하다.
▪
❸이 지닌 데이터와 ❸’의 데이터를 어떻게 동기화 할 것인가? 라는 문제가 생김
▪
❸의 DB에 쓰인 내용을 어떻게 ❸’에 쓸 것인가? → 쓰기는 간단히 분산할 수가 없다.
▪
❸❸’의 DB에서는 디스크를 많이 사용하므로 디스크 I/O를 많이 발생시키는 구성으로 되어있으면 속도차 문제가 생긴다.
▪
데이터가 커지면 커질수록 메모리에서 처리 못하고 디스크상에서 처리할 수 밖에 없는 요건이 늘어난다.
→ 대규모 환경에서는 I/O부하를 부담하고 있는 서버는 애초에 분산시키기 어려운데다가, 디스크 I/O가 많이 발생하면 서버가 금세 느려지는 본질적인 문제 발생

대규모 데이터를 다루기 위한 기초 지식

대규모 데이터를 다루는 세 가지 급소 - 프로그램을 작성할 때의 요령

•
어떻게 하면 메모리에서 처리를 마칠 수 있을까?
◦
메모리에서 처리를 마쳐야 하는 이유 : 디스크 seek 횟수가 확장성, 성능에 영향을 크게 주기 때문!
◦
디스크 seek 횟수를 최소화한다는 의미로 메모리를 활용하자
•
데이터량 증가에 강한 알고리즘을 사용하자
◦
선형검색 → 이분검색
◦
O(n) → O(log n)
•
데이터 압축, 정보 검색 기술을 활용하자
◦
압축해서 데이터량을 줄인다 → 디스크를 읽어내는 seek 횟수도 적어진다 (디스크 읽는 횟수 최소화)
▪
메모리에 캐싱하기 쉬워진다.
▪
데이터가 크면 메모리에서 넘치거나 디스크에 저장해도 읽어내기에 시간이 걸리므로 압축이 중요해진다.
◦
검색은 확장성 면에서 DB에만 맡겨서 해결할 수 없을 때, 특정 용도에 특화된 검색엔진 등을 만들어서 해당 검색 시스템을 웹 애플리케이션에서 이용하는 형태로 전환 → 속도 확보 가능

대규모 데이터를 다루기 전 3대 전제지식 - 프로그램 개발의 한층 아래 기초

•
OS캐시
•
분산을 고려한 RDBMS
•
알고리즘과 데이터구조

OS의 캐시구조

OS의 캐시 구조를 알고 애플리케이션 작성하기 - 페이지 캐시

•
OS에는 디스크 내의 데이터에 빠르게 액세스할 수 있도록 하는 구조가 갖춰져있다.
•
OS는 메모리를 이용해서 디스크 액세스를 줄인다.
◦
OS는 캐시 구조를 갖추고 있다.
▪
페이지 캐시, 파일 캐시, 버퍼 캐시
•
Linux의 페이징 구조
◦
OS는 ‘가상 메모리 구조’를 갖추고 있다.
▪
가상 메모리 구조는 논리적인 선형 어드레스를 물리적인 물리 어드레스로 변환하는 것
▪
선형 어드레스 (0xbffff444) → 페이징 구조 → 물리 어드레스 (0x00002123)

가상 메모리 구조

•
가상 메모리 구조가 존재하는 가장 큰 이유는 물리적인 하드웨어를 OS에서 추상화하기 위해서이다.
•
가상메모리 구조
◦
메모리에는 ❶과 같은 주소(=어드레스)가 붙어있다. ❶에는 0x00002123이라는 32(bit)주소가 붙어있다. 그러나 ❶의 어드레스를 직접 프로그램에서 사용하게 되면 여러 곤란한 일이 일어난다.
◦
따라서, 프로세스에서 메모리를 필요로하게 되면 OS가  메모리에서 비어있는 곳을 찾는다.
◦
 메모리는 OS가 관리하고 있으며, 비어있는 곳을 반환할 때 ❶의 0x00002123과는 다른 어드레스 ❷를 반환한다.
▪
개별 프로세스에서는 메모리의 어느 부분을 사용하는지 관여하지 않고, ‘반드시 특정 번지부터 시작’ 또는 ‘0x000부터 시작’하는 것으로 정해져있으면 다루기 쉽기 때문이다.
▪
OS는 메모리를 확보할 때에도, 디스크를 모아 읽는 것 처럼 메모리 1바이트씩 액세스하는 것이 아니라 적당히 4KB 정도를 블록으로 확보해 프로세스에 넘긴다. 여기서 1개의 블록을 ‘페이지'라고 한다.
→ OS는 메모리를 직접 프로세스로 넘기는 것이 아니라, 일단 커널 내에서 메모리를 추상화하고 있다
가상메모리는 프로세스에서 메모리를 다루게 쉽게 하는 이점을 제공한다.

Linux의 페이지 캐시 원리

•
OS는 확보한 페이지를 메모리상에 계속 확보해두는 기능을 갖고 있다.
•
페이지 캐시
◦
OS는 우선 디스크로부터 4KB 크기의 블록을 읽어낸다. (❶)
◦
읽어낸 것은 한 번은 메모리상에 위치시켜야한다. 읽어낸 블록을 메모리에 쓴다. (❷)
▪
프로세스는 디스크에 직접 액세스할 수 없기 때문이다. 프로세스가 액세스 할 수 있는 것은 (가상)메모리다.
◦
그리고나서 OS는 그 메모리의 가상 어드레스를 프로세스에게 알려준다. (❸)
◦
그러면 프로세스 이 해당 메모리인 ❸에 액세스하게 된다.
◦
데이터 읽기를 마친 프로세스이 ‘이번 디스크 읽기는 끝나고 데이터는 전부 처리했으므로 더 이상 불필요’하게 됐어도, ❸을 해제하지 않고 남겨둔다.
◦
다음에 다른 프로세스가 같은 디스크인 그
◦
❶에 액세스할 때에는 남겨두었던 페이지를 사용할 수 있으므로 디스크를 읽으러 갈 필요가 없게 된다.
→ 커널이 한 번 할당한 메모리를 해제하지 않고 계속 남겨두는 것이 페이지 캐시이다. (❺)
•
페이지 캐시의 친숙한 효과
◦
Linux에서는 디스크에 데이터를 읽으러 가면 꼭 한 번은 메모리로 가서 데이터가 반드시 캐싱된다. 따라서, 두 번째 이후의 액세스가 빨라진다. (OS는 대개 비슷한 구조를 가지고 있다.)
◦
OS를 계속 가동시켜 두면 메모리가 허락하는 한 디스크상의 데이터를 계속 캐싱하게 된다. → OS를 계속 가동시켜 두면 빨라진다.

Linux는 페이지 단위로 디스크를 캐싱한다.

•
페이지 = 가상 메모리의 최소 단위
•
디스크상에 4GB 정도의 메우 큰 파일이 있고, 메모리 여유분은 2GB밖에 없다고 가정한다.
◦
2GB 중 500MB 정도를 OS가 프로세스에 할당했다.
◦
메모리 여유분 1.5GB이 있을 때, 4GB 파일을 캐싱할 수 있을까?
◦
OS는 디스크상에 배치되어 있는 4KB 블록만을 캐싱하므로 특정 파일의 일부분만, 읽어낸 부분만을 캐싱할 수 있다.
•
메모리 여유분이 1.5GB있고 파일을 4GB 전부 읽게 되면 어떻게 될까?
◦
LRU (Least Recently Used) : 가장 오래된 것을 파기하고 가장 새로운 것을 남겨놓는 형태로 되어있으므로, 최근에 읽은 부분이 태시에 남고 과거에 읽은 부분이 파기되어 간다.
◦
따라서 DB도 계속 구동시키면 캐시가 점점 최적화되어가므로, 기동시킨 직후보다 점점 뒤로 갈수록 부하, I/O가 내려가는 특성을 보인다.
•
어떻게 캐싱될까?
◦
Linux는 파일을 i노드 번호로 식별하며, 해당 파일의 i노드 번호와 해당 파일의 어느 위치부터 시작할지를 나타내는 오프셋, 이 두가지 값을 키로 캐싱한다. → 파일의 일부를 캐싱할 수 있다.
◦
파일이 아무리 크더라도 이 키로부터 해당 페이지를 찾을 때의 데이터 구조는 최적화되어 있다. OS 내부에서 사용되고 있는 데이터 구조는 Radix Tree라고 하며, 파일이 아무리 커지더라도 캐시 탐색속도가 떨어지지 않도록 개발된 데이터 구조이다.

메모리가 비어있으면 캐싱

•
Linux는 메모리가 비어있으면 전부 캐싱한다.
◦
제한이 없다. (전부 캐시에 올라간다.)

메모리를 늘려서 I/O 부하 줄이기

•
메모리를 늘리면 캐시에 사용할 수 있는 용량이 늘어난다. → 보다 많은 데이터를 캐싱할 수 있다. → 많이 캐싱되면 디스크를 읽는 횟수가 줄어든다.

I/O 부하를 줄이는 방법

캐시를 전제로 한 I/O 줄이는 방법

•
데이터 규모에 비해 물리 메모리가 크면 전부 캐싱할 수 있으므로 이점을 생각한다.
◦
다루고자 하는 데이터의 크기에 주목한다.
◦
압축해서 저장하면 캐싱할 수 있는 비율이 상당히 늘어나게 된다.
•
경제적인 비용과의 밸런스를 고려한다.
◦
일반적인 서버 메모리 가격을 생각해서, 효율적인 압축 알고리즘 vs 서버 확장 선택한다.

복수 서버로 확장시키기 - 캐시로 해결될 수 없는 규모인 경우

•
데이터가 전부 캐싱되기 어려운 대규모인 경우
◦
복수 서버로 확장한다.
◦
AP서버 복수 확장 - CPU 부하를 낮추고 분산시킨다.
◦
DB서버 복수 확장 - 캐시 용량을 늘리고자 할 때, 효율을 늘리고자 할 때 (국소성을 고려)

단순히 대수만 늘려서는 확장성을 확보할 수 없다.

•
데이터를 복사해서 대수를 늘리게 되면, 부족한 캐시용량에 대한 부분도 동일하게 늘려가게 된다.
◦
곧 다시 병목현상이 발생한다.
◦
검은 부분에 액세스한 순간에 느려지는 것은 변함이 없다.

국소성을 살리는 분산

국소성을 고려한 분산이란?

•
데이터에 대한 액세스 패턴을 고려해서 분산시키는 것을 국소성을 고려한 분산이라고 한다.
◦
액세스 패턴 A 일때는 로 액세스가 많이 오고, 액세스 패턴 B 일때는 로 오는 것처럼, 데이터로 액세스하는 경향에 대한 처리방식에 따라 특정한 방향으로 치우치는 경우가 자주 있다.
◦
서버 ❶과 서버❷ 양측에 별다른 액세스 패턴을 고려하지 않고 분배한 경우, 로의 액세스는 여전히 계속되므로, 서버 ❶이 데이터영역 도 캐싱해야 할 필요가 있다.
◦
그러나, 그림처럼 액세스 패턴을 고려해서 분배한 경우는  부분은 더 이상 액세스되지 않으므로 그만큼 캐시 영역을 다른 곳으로 돌릴 수 있다.
•
캐싱할 수 없는 부분이 사라진다. → 메모리는 디스크보다 10^6배나 빠르므로 효율적이다.

파티셔닝

•
파티셔닝이란? 한 대 였던 DB 서버를 여러 대의 서버로 분할하는 방법
•
테이블 단위 분할
•
테이블 데이터 분할
◦
테이블 하나를 여러 개의 작은 테이블로 분할한다.

요청 패턴을 ‘섬’으로 분할

•
용도별로 시스템을 섬으로 나누는 방법
•
캐싱하기 쉬운 요청, 캐싱하기 어려운 요청을 처리하는 섬을 나눈다.
◦
전자는 국소성으로 인해 안정되고, 높은 캐시 적중률을 낼 수 있게 된다.
◦
후자의 요청이 전자의 캐시를 어지럽히므로 섬으로 나누는 경우에 비해 전체적으로는 캐시 효율이 떨어진다.

페이지 캐시를 고려한 운용의 기본 규칙

•
OS 기동 직후에 서버를 투입하지 않는다.
◦
갑자기 배치하면 캐시가 없으므로 오직 디스크 액세스만 발생하게 된다.
◦
OS를 시작해서 기동하면 자주 사용하는 DB의 파일을 한 번 cat해준다. → 전부 메모리에 올라간다. → 로드밸런서에 편입시킨다.
•
성능 평가는 캐시가 최적화되었을 때 실시한다.

계층과 확장성

계층별 확장성

•
AP서버
◦
상태를 가지고 있지 않으므로 요청별로 다른 AP서버로 날려보내도 처리상 문제가 발생하지 않는다.
◦
로드밸런서에 새로운 서버를 추가해가면 점점 확장되어 간다.
◦
대수만 늘리면 얼마든지 확장되는 구성으로 되어있다.
•
DB서버/파일서버
◦
분산, 확장성 확보가 매우 어렵다
◦
read를 분산하는 것은 비교적 용이
◦
write를 분산하는 것은 매우 어렵다.

부하를 측정하기 위한 항목

•
Load Average
◦
부하를 볼 때, 가장 먼저 볼 항목
◦
Load Average란?
▪
Linux 커널 내 프로세스 중, 동작할 수 있는 상태이지만 아직 CPU가 할당되지 않아서 대기상태에 있는 프로세스의 평균수이다.
◦
Load Average가 1이라고 하면, 5분 동안에 평균 1개의 프로세스가 대기 상태로 되어있다는 것을 의미한다.
◦
CPU가 깔끔하게 할당되면 이 값이 0에 가까워지고, CPU 코어 수 이하이면 양호한 편이다.
•
메모리 관련
◦
사용자 공간이 소비되고 있는 메모리
◦
공유되고 있는 메모리
◦
커널이 사용하고 있는 버퍼 메모리

다중성 확보

AP서버 다중성 확보

•
로드밸런서로 페일오버, 페일백하여 고장난 서버를 자동으로 분리하고, 서버가 복구되면 원상태로 복귀시키는 작업을 수행한다.
•
로드밸런서는 서버에 대해 주기적으로 헬스체크를 하고 있으며, AP서버나 DB 서버가 살아있는지 여부를 판정하고 있다.
◦
1,2대 정지하도라도 충분히 처리할 수 있도록 해둔다.

DB서버 다중성 확보

•
서버를 여러 대 나열하여 1, 2대 정지하더라도 충분한 처리능력이 있도록 해둔다
•
마스터의 다중화도 수행한다.
•
멀티마스터 구성
◦
쌍방으로 레플리케이션, 서로가 서로의 슬레이브가 되는 상태
◦
한쪽에 쓰기작업을 하면 다른 한쪽으로 전달하고, 반대쪽에 쓰더라도 다른 쪽으로 전달하는 양방향 래플리케이션 방법
▪
밀리초 단위로 보면 데이터가 일치하지 않는 상태가 항상 존재
→ 마스터간 동기화가 완벽하게 되지 않는 리스크에 대해서는 어느 정도 받아들임으로써 성능을 중시하는 경우가 많다. (수동 복구)

멀티 마스터

•
멀티마스터는 최근 수년 내 MySQL 서버 구축에 있어서 주류
•
상호간 VRRP라는 프로토콜로 감시 → 한쪽이 분리된 것을 알게되면 다른 한쪽이 Active 마스터로 승격
•
멀티마스터 구성에서 서버는 기본적으로 2대, Active - StandBy 구성
•
항상 Active쪽만 쓰기작업을 하는 구성
•
Active인 서버가 다운되면 Standby였던 쪽이 Active로 승격해서 새로운 마스터가 되고, 다운된 서버는 수작업으로 복구시켜서 다시 Standby로 되돌리던가, 다시 원래의 Active/Standby 구성으로 되돌린다.
•
외부에서 어느 쪽 서버가 Active인지를 판단하기 위해서 Virtual IP, 이른바 가상 IP주소(VIP)를 사용하고 있다.
•
Active쪽에 원래 할당되어 있는 IP주소(실제 IP주소)와는 별도로 서비스용 가상 IP주소를 부여하고 있다.
◦
두 서버에 ‘0.1’, ‘0.2’라는 주소가 부여되었다고 하면, 새롭게 ‘0.3’이라는 가상 IP주소를 Active쪽에 할당한다.
◦
Active쪽이 0.1이었다고 하면 Active쪽에는 0.1과 0.3 두 주소로 액세스할 수 있다.
◦
AP서버에서는 0.3을 서비스에 사용하도록 하고 있으며, 분리되는 타이밍에 새로운 Active 쪽에 0.3을 재부여한다.
→ AP서버에서 보면 항상 0.3으로 액세스함으로써 Active 마스터로 액세스할 수 가 있으므로 마스터 전환이 AP서버 입장에서는 은폐되어 있다.

가상화 기술

가상화 기술의 도입

•
목적
◦
확장성
▪
오버헤드의 최소화
◦
비용대비 성능
▪
리소스 사용률 향상
▪
운용의 유연함(환경의 단순화)
◦
고가용성
▪
환경의 격리

가상화 서버 구축 정책

•
가상화 기술을 도입하는 가장 기본적인 목적은 하드웨어의 이용 효율 향상이다.
•
남아있는 리소스를 사용하는 게스트 OS를 투입한다.
◦
CPU리소스가 남아있으면 웹서버, I/O리소스가 남아있으면 DB서버, 메모리 용량이 남아있으면 캐시 서버를 투입한다.
◦
리소스 소비경향이 비슷하고 부하가 높은 용도의 게스트 OS끼리는 리소스를 서로 점유하려고 하므로 같이 두는것은 피하도록 한다.

가상화로 얻은 장점 정리

•
물리적인 리소스 제약에서 해방됨으로써 동적으로 변경할 수 있다.
•
게스트 OS의 마이그레이션이나 복제가 용이해졌다.
→ 서버 증설이 용이해지고 확장성을 확보할 수 있게 되었다.
•
소프트웨어 레벨에서 호스트 리소스를 강력하게 제어할 수 있고, 비정상 동작 시 문제를 국소화시키고 호스트를 쉽게 제어할 수 있게 된다.
•
효율이 향상되고 시스템을 전체적으로 안정화할 수 있게 되었다.

작업큐(Job-Queue) 시스템

•
어느 정도 양이 있는 비동기 처리를 안정적으로 수행하려면 작업큐(Job-Queue)와 워커(Worker)를 세트로 한 작업큐 시스템을 사용하는 것이 일반적이다.
•
작업큐시스템에서는 작업큐에 실행하고자 하는 처리(작업)를 등록하고, 워커가 큐에서 작업을 추출해서 실제로 처리한다.
◦
클라이언트 (웹 애플리케이션)
▪
작업을 투입한다. 작업을 투입한 다음 처리를 계속 진행할 수 있다.
◦
작업큐
▪
작업을 쌓는다.
◦
워커
▪
작업큐를 참조하고 미실행된 작업을 추출해서 작업을 실행한다.