[대규모 서비스를 지탱하는 기술] 메모리와 디스크

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

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

---

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

• 데이터가 너무 많아서 메모리 내에서 계산할 수 없게 되면 디스크에 있는 데이터를 검색하게 된다.
• 하지만 디스크는 메모리에 비해 상당히 느리며, I/O에 시간이 걸린다.

 

메모리 vs 디스크의 속도 차

탐색 속도

• 메모리는 전기적인 부품으로 물리적 구조는 탐색 속도와 그다지 관계없다. (데이터가 메모리상에 있다면 탐색할 때 물리적인 동작 없이 실제 데이터 탐색 시의 오버헤드가 거의 없으므로 빠른 것이다.)
• 반면에 디스크는 헤드의 이동과 원반의 회전이라는 두 가지 물리적인 동작을 수반하고 있다. 이러한 물리적인 구조가 탐색 속도에 영향을 준다.

 

OS 레벨에서의 디스크의 탐색 속도 개선 사항

• 디스크는 느리지만 OS는 이러한 점을 어느 정도 커버하는 작용을 한다.
• OS는 연속된 데이터를 같은 위치에 쌓고, 데이터를 읽을 때 1바이트씩 읽는 것이 아니라 4KB 정도를 한꺼번에 읽도록 한다.
• 이렇게 해서 비슷한 데이터를 비슷한 곳에 두어 1번의 디스크 회전으로 읽는 데이터의 수를 많게 해서 디스크의 회전 횟수를 최소화할 수 있게 한다.

 

전송 속도

• 전송 속도는 찾은 위의 탐색을 통해 찾은 데이터를 디스크에서 메모리로 보내거나 메모리에서 CPU로 보내는 등 컴퓨터 내부에서 전송하기 위한 속도를 의미한다.
• 메모리나 디스크 모두 CPU와 버스로 연결되어 있다. 이 버스의 속도에서도 상당한 차이가 있다.
• 메모리와 CPU는 상당히 빠른 버스로 연결되어 있는 반면에, 디스크는 메모리나 CPU에 비해 많이 느리다.

 

SSD vs 메모리

• 최근 SSD는 물리적인 회전이 아니므로 탐색은 빠르지만 버스 속도가 병목이 되거나 그밖에 구조에 기인하는 면이 있어서 역시나 메모리만큼의 속도는 나오지 않는다.

 

이와 같이 현대의 컴퓨터에서는 메모리와 디스크 속도차를 생각하고 애플리케이션을 만들어야 한다. 이는 확장성을 생각할 때 매우 본질적이면서도 어려운 부분이다.

병목 규명작업의 기본적인 흐름

---

병목을 규명하기 위한 작업은 크게 다음과 같다.

• Load Average 확인
• CPU, I/O 중 병목 원인 조사.

Load Average 확인

• Load Average는 시스템 전체의 부하 상황을 나타내는 지표다.
• 다만 Load Average만으로는 병목의 원일이 어딘지를 판단할 수 없다. Load Average 값을 시초로 해서 병목지점에 대한 조사를 시작한다.
• Load Average는 낮은데 시스템의 전송량이 오르지 않을 경우도 가끔 있는데 이럴 경우는 소프트웨어의 설정이나 오류, 네트워크, 원격 호스트 측에 원인이 없는지 등을 살펴본다.

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

• Load Average가 높은 경우 다음으로 CPU와 I/O 어느 쪽에 원인이 있는지를 조사한다.

CPU 부하가 높은 경우 다음과 같은 흐름을 따라 조사해간다.

• 사용자 프로그램의 처리가 병목인지, 시스템 프로그램이 원인인지를 확인한다. (top or sar로 확인)
• 또한 ps로 볼 수 있는 프로세스의 상태나 CPU 사용시간 등을 보면서 원인이 되고 있는 프로세스를 찾는다.
• 프로세스를 찾은 후 보다 상세하게 조사할 경우는 strace로 추적하거나 oprofile로 프로파일러를 해서 병목지점을 좁혀간다.

일반적으로 CPU에 부하가 걸리고 있는 것은 다음 상황 중 하나이다.

• 디스크나 메모리 용량 등 그 밖의 부분에서는 병목이 되지 않는, 이상적인 상태
• ⇒ 전자의 상황에다 시스템의 전송량에 문제가 있다면 서버 증설이나 프로그램의 로직이나 알고리즘을 개선해서 대응
• 프로그램이 폭주해서 CPU에 필요 이상의 부하가 걸리는 경우
• ⇒ 오류를 제거해서 프로그램이 폭주하지 않도록 대처.

I/O 부하가 높은 경우

• 프로그램으로부터 입출력이 많아서 부하가 높거나 스왑이 발생해서 디스크 액세스가 발생하고 있는 상황 중 하나일 경우가 대부분이다.
• sar이나 vmstat로 스왑의 발생상황을 확인해서 문제를 가려낸다.

스왑이 발생하고 있을 경우

• 특정 프로세스가 극단적으로 메모리를 소비하고 있지 않은지를 ps로 확인할 수 있다.
• 프로그램의 오류로 메모리를 지나치게 사용하고 있는 경우에는 프로그램을 개선한다.
• 탑재된 메모리가 부족한 경우에는 메모리를 증설하고, 메모리를 증설할 수 없는 경우는 분산을 검토한다.

스왑이 발생하지 않고 디스크로의 입출력이 빈번하게 발생하고 있는 상황은 캐시에 필요한 메모리가 부족한 경우를 생각해볼 수 있다.

• 메모리 증설로 캐시영역을 확대시킬 수 있는 경우는 메모리를 증설한다.
• 메모리 증설로 대응할 수 없는 경우는 데이터 분산이나 캐시 서버 도입 등을 검토한다.

OS 튜닝이란

• 튜닝이란 병목이 발견되면 이를 제거하는 작업이다.
• 애초에 본래 하드웨어나 소프트웨어가 지니고 있는 성능 이상의 성능을 내는 것은 아무리 노력해도 불가능한 것이다.
• 할 수 있는 것은 하드웨어/소프트웨어가 본래 지닌 성능을 충분히 발휘할 수 있도록 문제가 될 만한 부분이 있다면 제거하는 것이다.

 

규모 조정의 요소

---

규모조정, 확장성

웹 서비스에서는 고가의 빠른 하드웨어를 사서 성능을 높이는 스케일업 전략보다도 저가이면서 일반적인 성능의 하드웨어를 많이 나열해서 시스템 전체 성능을 올리는 스케일아웃 전략이 주류이다.

• 스케일 아웃 전략이 더 나은 이유는 웹 서비스에 적합한 형태이고 비용이 저렴하다는 점과 시스템 구성에 유연성이 있다는 점이 포인트다.

 

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

웹 3계층 구조에는 프록시, AP 서버, DB가 있다.

AP 확장성

• AP서버는 CPU 부하만 걸리므로 분산이 간단한다. 왜냐하면 기본적으로 데이터를 분산해서 갖고 있는 것이 아니므로 동일한 호스트가 동일하게 작업을 처리하기만 하면 분산할 수 있다. 따라서 대수를 늘리기만 하면 간단히 확장해갈 수 있다.
• 요청을 균등하게 분산하는 것은 로드밸런서라는 장치가 해준다.

DB 확장성

• 반면 I/O 부하에는 어려움이 있다.
• DB를 분산하면 쓰기 작업이 발생하였을 때 데이터를 어떻게 동기화할 것인가라는 문제가 생긴다.

 

DB 확장성 확보의 어려움

DB에서 디스크를 많이 사용하는 경우, 디스크 I/O를 많이 발생시키는 구성으로 되어있으면 속도차 문제가 생긴다.
게다가 데이터가 커지면 커질수록 메모리에서 처리 못하고 디스크상에서 처리할 수밖에 없는 요건이 늘어난다.

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

---

대규모 데이터를 다루기 위한 프로그램을 작성할 때의 요령

어떻게 하면 메모리에서 처리를 마칠 수 있을까?

• 메모리에서 처리를 마쳐야 하는 이유는 앞서 설명한 대로 디스크 seek 횟수가 확장성, 성능에 크게 영향을 주기 때문이다. 디스크 seek 횟수를 최소화한다는 의미로 메모리를 활용하고자 한다.
• 또한 국소성을 활용한 분산을 실현할 수 있다.

데이터량 증가에 강한 알고리즘을 사용하는 것

• 레코드 1,000만 건이 있을 때 단순히 선형탐색으로 하면 1,000만 번 계산을 수행해야 하는데, Log Order인 알고리즘을 적용하면 수십 번 만에 마칠 수 있다는 기본적인 예가 있다. 이렇게 알고리즘의 기초적인 부분을 제대로 활용하자는 것이다.

데이터 압축이나 검색기술과 같은 테크닉이 활용될 수 있는 국면이 있다.

• 압축해서 데이터량을 줄일 수 있다면 읽어내는 seek 횟수도 적어지게 되므로 디스크 읽는 횟수를 최소화할 수 있다는 것이다. 또한 메모리에 캐싱하기 쉬워진다.
• 데이터가 크면 메모리에서 넘치거나 디스크에 저장해도 읽어내기에 시간이 걸리므로 압축이 중요해진다.