개발공부 기록지

OS 캐쉬 구조

메모리, 디스크, OS 캐쉬 구조

• 메모리는 디스크보다 만배에서 십만배 이상빠르다
• 메모리를 이용해서 디스크 엑세스를 줄이고자 함
  • OS 는 캐쉬 구조를 가지고 있다.

페이징 구조

• 가상 메모리 구조의 기반
• 논리적인 선형 어드레스(0xbffff444)를 물리적인 물리 어드레스(0x00002123)로 변환 

가상 메모리, 스왑

• 가상 메모리
  • OS는 가상 메모리 구조를 가지고 있다.
  • 가상 메모리 구조는 논리적인 선형 어드레스를 물리적인 물리 어드레스로 변환하는 것
• 스왑
  • 가상 메모리를 응용한 기능 중 하나. 물리 메모리가 부족할 때 2차 기억장치(디스크)를 메모리로 간주해서 외형상의 메모리 부족을 해소하는 원리

가상 메모리 구조

가상 메모리가 존재하는 이유?   

프로세스에서 메모리를 필요로 하게되면, 메모리의 어느 부분이 아니라 특정 번지를 가져온다.

이때, 물리적인 하드웨어를 OS 에서 추상화하기 위해 존재한다.

가상 메모리

- OS 는 메모리를 직접 프로세스로 넘기는 것이 아니라 커널 내에서 메모리를 추상화하고 있다.

이것이 가상메모리이다.

Linux 의 페이지 캐시 원리

커널이 한 번 할당한 메모리를 해제하지 않고 계속 남겨두는 것이 페이지 캐시의 기본

• 페이지 캐시의 친숙한 효과  : 디스크에서 데이터를 읽으러 가면 꼭 한번은 메모리로 가서 데이터가 반드시 캐싱 → 두 번째 이후의 액세스가 빨라짐

< 과정 >

디스크의 내용을 일단 메모리에 읽어들인다.(페이지가 작성된다)

→ 작성된 페이지는 파디되지 않고 남는다.(페이지 캐시)

→ 예외의 경우를 제외하고 모든 I/O에 투과적으로 작용 (페이지 캐시의 친숙한 효과)

     - 디스크의 캐시를 담당하는 곳(VFS)

VFS( Virtual File System)

- 파일 시스템 위에 있는 추상화 레이어

- 페이지 캐시의 구조를 가짐 

- 역할 : 파일시스템 구현의 추상화와 성능에 관련된 페이지 캐시부분

*추상화 : 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려 내는 것을 말한다.

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

페이지? 가상 메모리의 최소단위

OS 는 디스크를 블록(페이지) 단위로 캐싱,

 파일 단위로 캐싱 하지 않는다.

    - 파일 단위로 캐싱한다고 하면 파일 1개 단위로 캐싱하고 있다는 이미지이기 때문

LRU (Least Recently Used)

가장 오래된 것을 파기하고 가장 새로운 것을 남겨놓은 형식

캐싱이 되는 방식

해당 파일의 i 노드 번호, 어느 위치 부터 시작 할지를 나타내는 오프셋 이 두 가지 값을 키로 캐싱

메모리가 비어 있으면 캐싱

Linux 는 비어있는 메모리 공간에 계속해서 디스크 내용을 캐싱한다.

프로세스에서 메모리를 요청하면 -> 오래된 캐시를 버리고 프로세스에 메모리를 확보

즉, 캐시 이외의 메모리가 필요해지면 오래된 캐시가 파기가 된다.

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

메모리가 늘린다 ▶  캐시에 사용할 수 있는 용량이 증가  ▶  많은 데이터를 캐싱  ▶  디스크를 읽는 횟수가 줄어든다.

I/O 부하를 줄이는 방법

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

(데이터의 크기에 주목) 데이터 규모 < 물리 메모리 → 전부 캐싱 가능 

경제적 비용과 밸랜스 고려 → 물리 메모리를 증가시킬 것인지 소프트웨어로 메모리 사용을 줄인 것인지 결정 필요

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

• CPU 부하분산에는 단순히 서버를 늘린다.
• I/O 분산에는 국소성을 고려한다.

예를 들어 AP 서버를 늘리는 것과 DB 서버를 늘리는 것은 다르다.

• AP 서버를 늘리는 이유 : CPU 부하를 낮추고 분산시키기 위함
• DB 서버를 늘리는 이유
  • 반드시 부하 때문은아님  → 캐시 용량증가 혹은 효율을 높이고자 할 때 인 경우가 많다.

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

캐시 용량을 늘려야하는데 대수를 늘리면

→ 부족한 부분까지 동일하게 늘어남

→ 캐싱할 수 없는 비율은 변함 없이 그대로 유지됨

→ 다시 병목이 된다.

해결방법

• 메모리 증설 
  • I/O 바운드한 서버에서는 처리할 데이터 량에 비례해서 메모리를 증설하는 것이 I/O 부하를 경감시키는데 효과적
• 메모리 증설을 할 수 없는 경우
  • 데이터를 분할해서 각각의 서버에 위치시키는 것을 검토 (서버 증설)
    • 대수를 늘린 만큼 I/O 횟수가 줄어듬
    • 캐시에 올릴 데이터의 비율이 늘어남 → 전송량 향상을 기대할 수 있음 

* I/O 바운드인 서버가 높은 I/O 부하로 인해 전송량이 제대로 나오지 않을 경우 → 페이지 캐시가 최적화되기 이전인지 이후인지 확인 필요

국소성을 살리는 분산

국소성(locality) 을 고려한 분산이란

데이터에 대한 액세스 패턴을 고려해서 분산시키는 것 = 국소성을 고려한 분산

( 데이터를 그대로 복제하는 것은 국소성을 고려한 분산이 아님)

위와 같이 분배하면 서버 1 이 데이터영역 2 를 캐싱해야 할 필요가 없다.

액세스 패턴 A 는 서버 1 의 데이터영역 1 에만 엑세스하면된다.

국소성을 고려한 분산의 결과

메모리에 올라간 데이터량 증가 -> 데이터 엑세스 속도 향상

파티셔닝

• 테이블 단위 분할
  • 테이블 종류 : entry, bookmark, tag, keyword
    • entry, bookmark : 같이 액세스하는 경우가 많으므로 같은 서버에 위치
    • tag, keyword : 많은 데이터를 가지고 있는 테이블을 같은 서버에 위치
    • 테이블 요청에 맞게 서버에  보내면 된다.
• 테이블 데이터 분할
  • 테이블 하나를 여러 개의 작은 테이블로 분할
    • (ex) id 의 첫문자 기준 파티셔닝 : (a~c) (d~f) ,...
  • 문제점 : 분할의 입도를 크거나 작게 조절할 때 데이터를 한 번 병합해야 한다

요청 패턴을 '섬(islands)'으로 분할

• 용도 별로 시스템을 섬으로 나누는 방법
  • 캐시하기 쉬운 요청 :  국소성으로 인해 안정되고 높은 캐시 적중률
  • 캐시하기 어려운 요청 : 캐시하기 쉬운 요청의 캐시를 어지럽히므로 섬으로 나누는 경우에 비해 전체적으로 캐시 효울이 떨어짐

(예시) 일반적인 요청 , 봇/feed, 이미지 API 등

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

• OS 기동 후에 서버를 곧바로 투입하지 않는다 
  • (이유) 아직 캐시가 쌓여 있지 않기 때문
•  성능평가는 캐시가 최적화되었을 때 해야 한다.

요약

분석은 국소성을 고려해서 실시해야 한다.

데이터 규모에 맞게 탑재 메모리를 조정한다.

        메모리 증설로 대응할 수 없다면 분산을 고려한다.

부하분산 학습에 있어서 기초지식으로 OS 의 동작원리를 아는 것이 중요하다.

OS 동작원리

• OS 캐시 
• 멀티스레드 멀티 프로세스
• 가상메모리 구조
• 파일시스템

등을 통해서 알게되는 OS의 장단점을 고려하여 시스템 전체를 최적화 할 수 있다.

대규모 데이터로의 쿼리

데이터가 많으면 쿼리를 처리하는데 시간이 걸린다. -> 직감으로는 알겠으나 왜 그런지를 이해해두는 것이 중요

많은 시행착오를 통해 대규모 데이터를 다루는 감각이 필요하다.

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

메모리 내에서 계산할 수 없다 -> 메모리보다 처리속도가 느린 디스크에 있는 데이터를 검색

디스크는 느리므로 I/O 에 시간이 걸린다.

* 메모리는 디스크보다 10만~ 100만배 이상 빠르다.

디스크는 왜 늦을까?

물리적인 동작을 수반  - 원반의 회전, 헤드의 이동

물리적인 구조에 따른 탐색속도 저하  - 원하는 위치에 있는 데이터를 찾기 위해 회전 필요

메모리보다 많이 늦은 전송속도(버스의 속도차)

• 탐색속도에 영향을 주는 요인
  • 헤드의 이동과 원반의 회전이 필요
  • 디스크에 배치되었는 데이터들의 위치 ( 뿔뿔이 흩어져 있으면 찾기위해 많은 회전과 이동이 필요)

메모리 - 1회 탐색시 마이크로초, 물리적인 동작 필요없음

▶▶ 메모리와 디스크 속도차를 생각하고 애플리케이션을 만드는 것이 중요

규모조정의 요소

메모리와 디스크의 속도차와 같은 사항들이 시스템 전체의 확장성 전략에 어떤 영향을 주는가를 알아보는 장

스케일업 과 스케일아웃

• 스케일 업 : 고가의 빠른 하드웨어를 사서 구매하여 성능을 향상시키는 방식
• 스케일 아웃 : 일반적인 하드웨어를 나열하여 성능을 향상시키는 방식
  • 주로사용하는 방식
  • 이유
    • 저렴하다
    • 웹 서비스에 적합한 구조다
    • 시스템 구성에 유연하다.

CPU 부하와 I/O 부하

• CPU 부하 : 스케일 아웃을 이용하여 부하 완화 가능
  • AP 서버, 웹 이 해당
  • 같은 구성의 서버를 늘리고 로드밸랜서를 이용하여 분산
• I/O 부하 : 확장을 하여 분산으로 완화하기 어렵다
  • DB 가 해당
  • 스케일 아웃을 하면 어떻게 데이터를 동기화하고 안정성을 유지할 것인지 고민이 필요

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

프로그램을 작성할 때의 요령

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

- 디스크 seek 횟수 최소화

- 국소성을 활용한 분산 실형

2. 데이터량 증가에 강한 알고리즘 사용

- 이분 검색

-

3. 데이터 압축혹은 검색기술과 같은 테크닉을 활용

대규모 데이터를 다루기 전 3 대 전제 지식

1. OS 캐시

2. 분산을 고려한 RDBMS 운용

3. 알고리즘과 데이터 구조

대규모 서비스에만 있는 문제 혹은 어려움

1. 확장성 확보 와 부하 분산 필요
   
   • 스케일 아웃  - 서버의 역할을 분담하거나 서버 대수를 늘림으로 써 시스템의 처리 능력을 높이는 방법
     • 장점 : 비용 절감
     • 단점
       • 요청 분배는 어떻게 할 것인가?
       • 데이터 동기화는 어떻게?
       • 통신 지연시간은 어떻게?
2. 다중성 확보  - 특정 서버가 고장나거나 성능이 저하되어도 서비스를 계속 할 수 있는 구성
3. 효율적인 운용 필요 - 대규모 시스템을 건강한 상태로 얼마나 유지할 수 있을 것인가?에 대한 운용

대규모 데이터량에 대한 대처

데이터 처리 과정

     디스크 > 메모리 > 캐시 메모리 > CPU

 데이터 처리량이 많아지면?

    저속의 디스크로 I/O 이 많이 발생

→ 디스크 I/O 에 대기에 들어선 프로그램은 읽기가 완료될때 까지 다음 처리 불가

→ 시스템 전체의 성능이 저하

대규모 데이터 처리시 고민해야할 것들

• 어떻게 하면 데이터를 적게 가져갈 수 있을까?
• 여러 서버로 분산시킬 수 있을까?
• 필요한 데이터를 최소한의 횟수로 읽어 들일 수 있을까?
• 등등