[웹 개발자를 위한 대규모 서비스를 지탱하는 기술]

목적

실제 대규모 서비스를 제공하고 있는 기업에서는 어떤 기술을 사용하는지에 대한 궁금증을 풀고자 함

목차

1. 독서 계기
2. 내용 정리
3. 후기

1. 독서 계기

이 책은 말 그대로 대규모 서비스를 운영하기 위해서는 어떠한 기술이 쓰이는지,

현재 내가 가진 지식이 정말 대규모 서비스를 운영하는데 도움이 될 수 있는지 여부가 궁금했다.

또한 책을 읽고서 나의 부족한 부분을 채워나가고 싶었다.

2. 내용정리

소규모 서비스로 시작한 하테나가 대규모 서비스를 운영하기 위해 시행착오를 겪은 노하우를 적어두었다.

주로 확장성, 다중화, 효율향상에 중점을 두었다.

• 메모리와 디스크

  대규모 데이터의 어려움은 메모리 내에서 계산할 수 없다는 점이다.
  메모리 내에서 계산할 수 없게 되면 디스크에 있는 데이터를 검색할 필요가 있다.
  하지만 디스크는 메모리보다 탐색속도가 10^5 ~ 10^6정도 느리다
  그러므로 어떻게 대처할 것인지를 잘 판단해야 한다




• 규모조정, 확장성

  웹 서비스에선 일반적으로 하드웨어 스펙을 올리는 스케일업보단 하드웨어를 나열해서 시스템 전체 성능을 올리는 스케일아웃이 주류이다.
  비용이 저렴하고 시스템 구성에 유연성이 존재하기 때문이다.




• 규모조정, CPU부하와 I/O부하

  CPU부하는 비교적 규모조정이 간단하다.
  같은 구성의 서버를 늘리고 로드밸런서로 분산시킨다.
  I/O부하는 규모조정이 어렵다.
  DB를 분산했을 경우 한 DB의 내용을 다른 DB에 어떻게 쓸 것인가에 대한 난제에 놓이며, 디스크 I/O가 많이 발생하면 서버가 금새 느려지는 본질적인 문제가 있다.




• 대규모 데이터 다루기

  어떻게 하면 메모리에서 처리를 마칠 수 있는가 ? - 디스크 seek 횟수 최소화 하기
  데이터량 증가에 강한 알고리즘 및 데이터구조 활용 - O(n) 또는 O(logn)의 시간복잡도를 가지는 알고리즘 선택
  데이터 압축 및 검색기술 활용




• OS캐시와 분산

  OS는 캐시 구조를 갖추고 있다
  프로세스는 디스크에 접근할 수 없기 때문에 디스크에서 읽은 데이터를 메모리상에 한번은 위치시키며 이것을 페이지라 한다.
  페이지가 존재하면 다른 프로세스도 남겨둔 페이지를 사용할 수 있으므로 디스크 I/O를 발생시킬 필요가 없다.




• I/O부하 줄이기

  이론적으론 디스크상의 데이터를 모두 메모리상에 올려두면 가능하다.
  하지만 경제적 비용과의 밸런스를 고려해야 하기 때문에 현실에선 불가능한다.
  I/O부하의 경우엔 단순히 서버 대수를 늘려서만은 부하를 줄일 수 없다.
  테이블 단위 분할 또는 테이블 데이터 단위로 DB서버를 분할한다.




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

  실제 서비스 중 I/O부하를 최소화 하기 위해 OS기동 후에 서버를 곧바로 투입하지 않는다.
  성능평가는 캐시가 최적화 되었을때 한다.
  데이터 규모에 맞게 탑재 메모리를 조정하며, 메모리 증설로 대응할 수 없을 경우 분산시킨다.




• 분산을 고려한 RDBMS운용

  OS캐시 활용 : 스미카 설계가 데이터 크기에 미치는 영향을 고려하며, 데이터량보다 물리 메모리가 크도록 유지한다.
  인덱싱 : 인덱싱을 통해 디스크 I/O횟수를 줄이자.
  확장을 전제로 한 설계 : DB를 레플리케이션을 통해 분산하고, 참조계열을 확장하고, 갱신계열은 확장하지 않는다.




• 용도 특화형 인덱싱

  데이터를 정기적으로 뽑아내고 데이터 구조를 구축한다
  검색용 역 인덱스나 키워드 링크용 Trie가 그 예시다.




• 데이터 압축

  I/O부하를 줄일 수 있는 좋은 방법이다.




• 알고리즘

  유한한 컴퓨터 자원으로 효율적인 데이터 처리를 위해선 적절한 알고리즘이 필요하다.
  데이터 규모가 커질수록 O(n)과 O(logn)의 차이는 극심해진다.
  자주 사용하는 서비스에 맞추어 데이터 구조를 선택할 필요가 있다.




• 대규모 데이터 검색 기술

  DB로 처리할 수 없는 경우엔 검색엔진을 직접 구현한다.
  직접 구현함으로써 세세한 요구에 대응할 수 있다.
  grep형(검색대상을 처음부터 전부 읽음), Suffix형(검색 가능한 형태로 검색 대상 데이터구조를 보유), 역 인덱스형(키워드를 key로, 키워드가 들어있는 문서를 value로 갖음)이 있다.
  제일 많이 쓰이는건 역 인덱스 형이다.




• 웹 서비스의 인프라에서 중요시 되는 부분

  저비용 고효율
  확장성, 응답성이 중요한 설계
  신속한 개발속도




• 클라우드 컴퓨팅 vs 자체구축 인프라

  클라우드 컴퓨팅의 최대 장점은 확장성이다.
  서비스가 어느정도 규모 이상에서는 자체구축으로 가는 편이 좋다.
  유연한 서버 구성, 서비스요청에 대한 유연한 대응, 병목현상 제어 등이 자체구축 인프라의 장점이다.




• 계층별 확장성

  웹서버 - 구성이 동일하고 상태를 갖지 않기 때문에 확장이 용이하다.
  DB, 파일 서버 - read의 분산은 비교적 용이하나, write의 분산은 확장이 어렵다.




• 튜닝

  튜닝을 위해 관리툴이 필요하다.
  부하 파악, 상태 감시를 통해 병목이나 이상현상을 파악할 수 있도록 한다.




• 다중성 확보

  웹서버 : 서버를 여러대 늘어 놓으며, 로드밸런서를 통해 장애극복, 정상복귀 작업을 수행한다.
  DB서버 : 마스터 슬레이브 구조로하여 슬레이브는 여러대를 놓고, 마스터의 경우는 멀티마스터 방식을 사용하여 상호간 레플리케이션을 진행한다.




• 시스템 안정화

  안정성과 자원효율, 안정성과 속도는 상반관계에 있다.
  애플리케이션/서비스 레벨에선 메모리 누수, 기능 추가, 사용자 액세스 패턴, 데이터량 증가, 외부연계 추가 등을 관리하여 안정성을 확보한다.
  하드웨어 레벨에서는 메모리, HDD, NIC 장애 등을 관리하여 안정성을 확보한다.




• 안정화 대책

  적절한 버퍼 유지 - 메모리 및 CPU는 부하는 한계의 7할 까지만 운용한다.
  기타 불안정 요소들을 제거한다.




• 가상화 기술

  확장성, 비용대비 성능, 고가용성의 장점 덕분에 사용한다.
  효율적인 가상화 서버 구축을 위해 CPU를 사용하는 OS끼리 붙이지 않고, CPU를 주로 사용하는 OS와 I/O를 주로 사용하는 OS를 붙인다.

3. 후기

점점 퍼즐조각이 맞춰지는 듯한 기분이다.

학부생때 배웠던 컴퓨터 기초 과목들을 어떤식으로 활용할 수 있고, 그것들이 큰 규모의 서비스에 어떠한 영향을 미치는지 알게되었다.

얕고 넓은 지식으로 개발자로서의 성장이 최근에 더뎌짐을 느꼈지만, 이 책을 통해 성장의 발판을 다시 마련할 수 있었다.

또한 지식의 깊이를 한 층 더 깊게 만들었다.

기초 과목들을 꾸준히 공부하고, 개발할 때 위의 노하우를 고려하여 좀 더 나은 개발자가 될 수 있도록 노력해야겠다.