PRDEN

1. 용도 특화형 인덱싱 대규모 데이터를 다룰 경우 RDBMS로는 한계가 있다. 따라서 배치 처리로 RDBMS에서 데이터를 추출해서 별도의 인덱스 서버와 같은 것을 만들고 이 인덱스 서버에 웹 애플리케이션에서 RPC(Remote Procedure Call) 등으로 액세스 하는 방법을 사용한다. 1) RPC와 웹 API 위 그림에서 DB에서 정기적으로 corn 등으로 데이터를 추출해 2의 인덱스 서버로 넘긴다. 인덱스로는 2에서 검색용 역 인덱스를 만들어준다. 그러면 AP서버에서는 인덱스를 가지고 있는 2인덱스 서버에 RPC로 액세스 한다. 요즘은 RPC보다 웹 API라고(JSON이랑 http로 처리) 부른다. AP서버에 인덱스를 직접 저장하지 않는 이유는 AP서버에 충분한 메모리가 탐재되어있지 않는 경우..

앞서 설명한 바와 같이 분산을 할 때는 데이터 규모에 맞게 탑재 메모리를 조정하고, 메모리 증설로도 대응할 수 없을 경우 분산해야 한다. 앞으로는 DB레이어에서 MySQL운용, 스케일 아웃 전략에 대해 공부해보자 (OS 캐시, 인덱스를 적절하게 설정하기, 확장을 전제로 한 시스템 설계 순으로 공부한다. 1. OS 캐시 활용 전체 데이터 크기에 주의해서 데이터량 < 물리 메모리를 유지해야 한다. 메모리가 부족할 경우에 증설을 하고 스키마 설계가 데이터 크기에 미치는 영향을 고려해야 한다. 그냥 아무 생각 없이 create table로 스키마 설정하면 안 돼. 최소 정수 int형은 32비트 = 4바이트, 문자열은 8비트=1바이트 같은 기본적인 수치는 기억하자. 2. 인덱스의 중요성 MySQL의 인덱스는 기본..

1. OS 캐시의 구조 메모리를 이용해서 디스크 액세스를 최대한 줄여야 한다. 이를 위해 OS 캐시를 이용. 예를 들어 리눅스 페이지 캐시를 살펴보자 '프로세스 1'은 데이터를 읽어오기 위해 직접 디스크에 액세스 할 수 없고 가상 메모리에 접근해서 데이터를 읽어와야 한다. OS가 읽어온 블록을 메모리에 쓰고 OS는 그 메모리 주소를 프로세스 1에게 전달한다. 그러면 '프로세스 1'이 그 데이터에 접근할 수 있는 것이다. 반면, '프로세스 2'가 동일한 데이터에 접근하기 위해서 위와 같은 작업을 반복하는 것이 아니라 커널은 한 번 할당한 메모리를 해제하지 않고 남겨두기 때문에 '프로세스 1'이 데이터를 읽어올 때 남겨둔 페이지를 사용하면 된다. 이 개념이 페이지 캐시인 것이다. (파일 캐시가 아니고 페이지..

1. 프로그램을 작성할 때의 요령 1) 메모리에서 최대한 처리를 마쳐서 디스트 Seek횟수를 최소화한다. 2) 데이터량 증가에 강한 알고리즘을 사용해라. ex) 선형 탐색이 아닌 Log Order알고리즘을 적용하는 방법 3) 데이터 압축이나 검색 기술을 활용한다. 데이터 압축을 통해 데이터량을 줄일 수 있다면 근본적으로 seek횟수를 줄일 수 있으며, 특정용도에 특화된 검색엔진을 만들어 웹 애플리케이션에서 이용하는 형태로 전환하면 속도를 제대로 확보할 수 있다. 2. 프로그램 개발의 근간이 되는 기초(3가지) 1) OS캐시 : OS가 캐시를 통해 대규모 데이터를 효율적으로 처리, OS 캐시만으로 처리할 수 없게 되었을 때 분산을 해야 하는 것 2) 분산을 고려한 RDBMS 운용 3) 알고리즘과 데이터 구조

1. CPU 부하 해결방법 : AP서버는 CPU 부하만 걸리므로 2', 2''등 과 같이 서버(동일한 구성을 갖는 서버) 대수만 늘려서 확장한 뒤 요청을 균등하게 분산하는 로드밸런서라는 장치를 달아주면 해결 가능. *AP서버 = CPU바운드한 서버 2. I/O 부하 : 한편, I/O부하는 해결하기 까다롭다. DB를 3, 3'로 놓았을 때 2에서 3으로 쓰기(insert)가 발생하면 3이 지닌 데이터와 3'이 지닌 데이터를 어떻게 동기화할 것인가에 대한 문제가 발생하기 때문이다. *DB서버:데이터를 디스크로부터 검색하는일 주로 함. =I/O바운드한 서버 3. DB 확장성 확보의 어려움 : DB에서는 디스크를 많이 사용하므로 디스트 I/O를 많이 발생시키는 구성으로 되어있으면 속도차 문제가 생긴다. 게다가 ..

1. 메모리 내에서 계산할 수 없다. 1. 탐색 속도(메모리 vs 디스크) - 메모리 내에서 계산할 수 없기 때문에 디스크에 두고 특정 데이터를 검색해야 한다. 하지만, 디스트는 느리므로 I/O에 시간이 걸린다. ※ 메모리 내의 특정 번지에 있는 데이터를 찾는 데이터 탐색 속도 vs 디스크의 특정 원반 내에 있는 데이터를 찾는 속도 : 메모리는 디스크보다 약 10의 5승배 이상 빠르다. *디스크의 탐색 속도가 느린 이유 : 물리적인 동작인 원반의 회전을 통해 데이터를 찾기 때문에 수 밀리 초가 걸리는 것이다. 반면 메모리는 물리적인 동작 없이 실제 데이터 탐색의 오버헤드가 거의 없어 1회 탐색 시 마이크로초면 충분하다. 더욱이, 탐색에 사용되는 것이 CPU의 캐시에 올리기 쉬운 알고리즘이나 데이터 구조일..

1. 대량의 액세스가 있는 서비스에서 서버 1대로 처리할 수 없는 부하를 처리하는 방법 1) Scale-out : 저가의 하드웨어를 횡으로 나열해서 확장성 확보하는 전략 ※ scale-out 전략 도입 시 발생 가능한 문제 : 로드밸런서 사용에 따른 데이터 동기화 처리 문제, 네트워크 통신의 지연시간 발생 문제 2) Scale-up : 하드웨어의 성능을 높여 처리능력을 끌어올리는 방법 2. 다중성 확보 - 특정 서버가 고장 나거나 성능이 저하될 때 서비스를 계속할 수 있도록 구성해야 함. 3. 서버가 100대일 경우 - 어떤 서버가 무슨 역할을 하는지 파악 어렵다. - 뿐만 아니라 각 서버가 어떤 상황에 처해있는지 이를 테면 해당 서버에 대한 부하가 괜찮은지, 디스크 용량이 충분한지, 보안 설정에 미비한..

1. 책에서 다루는 주요 내용 : 1) 대규모 데이터를 다뤄야 하는 웹 서비스 개발자들이 알아두어야 할 메모라나 디스크 2) CPU와 I/O 부하 3) DB분산 등의 서버 및 하드웨어에 대한 기초지식과 대규모 데이터에 적합한 알고리즘 4) 데이터 구조, 인덱싱, 네트워크 등 1. 대규모 웹 서비스 = 거대한 데이터를 처리하는 웹 서비스 - 이 책은 크게 3 분야로 나뉜다. 1) 제2~제5장 :(운영체제) 데이터가 많을 때 어떻게 처리해야 하는지, 확장성 문제가 발생하지 않도록 코드를 어떻게 작성해야 하는지 ex) 대규모 데이터란, 대규모 데이터 처리의 바탕인 OS캐시, MYSQL을 대규모 환경에서 운용 시 주의해야 할 점, 대규모 데이터를 다루는 애플리케이션 개발 시 핵심이 되는 내용 2) 제6~제10장..