[대규모 서비스를 지탱하는 기술] 독서후기

✍️ 서평

---

대규모 서비스를 지탱하는 기술이란 책은 2011년 발행본으로 오래된 책이라 지금 현재 기술에 맞지 않는 부분도 있었고, 일반적이지 않게 변화된 지식도 있었다. 하지만 하테나 대규모 서비스를 어떤 식으로 관리하고 있었는지에 대해 살펴보기 좋았다.

주로 부하관리와 확장성에 대한 내용이 많았다. 하테나에 대한 예시와 반복적인 이야기로 내용을 더 이해하고 기억하기 쉽게 쓴 글이었다. 추가로 운영체제나 서버 및 인프라에 대한 최신에 나온 다른 책도 복습할 겸 읽어보는 것이 좋겠다는 생각이 들었다.

 

👀 도서내용 정리

---

도서의 모든 내용을 정리하지 못했지만 기억하고 싶고 가져가야 할 부분을 위주로 정리했다.

대규모 데이터 규모의 처리의 어려움

• 기가 바이트 이상의 같은 대규모 데이터는 처리하는데 많은 시간이 걸린다.
• 대규모 데이터는 메모리 내 계산이 어려워 디스크를 두고 특정 데이터를 검색하게 된다.

메모리와 디스크

• 메모리보다 디스크는 물리적 동작이 수반되므로 탐색속도가 느리다. 디스크의 물리적 구조상 헤드의 이동, 원반의 회전이 수반되기 때문이다. 
• 메모리상의 데이터가 CPU 캐시에 올리기 쉬운 알고리즘이나 데이터 구조라면 탐색속도는 더 빨라진다.
• OS는 연속된 데이터를 같은 위치에 쌓아 디스크 탐색속도의 구조적 문제를 해결한다.
• 아래 사진에서도 볼 수 있지만 디스크보다 메모리, 캐시를 이용한 탐색속도가 빠른 것을 볼 수 있다. 하지만 가격도 그만큼 많이 발생하기 때문에 서비스나 회사 사정에 따라 확장성을 고려하는 것이 필요하다.

 

Linux 체제에서의 부하확인하기

• AP서버인지 DB서버의 부하인지에 따라 대응방식이 다르기 때문에 어디서 부하가 발생하는지 파악할 필요가 있다.
• Load average를 확인한다.
  Load average란, 1분, 5분, 15분을 평균으로 처리를 대기하는 정도를 나타낸 수치이다.
  코어를 기준으로 이상적인 수치 차이가 발생한다.
  일반적으로 싱글코어에서 1.00일 때, 100%로 사용되는 것으로 볼 수 있다. 0.70 기준으로 확장성을 고려하는 것이 좋다. 1.00을 넘어서는 수치는 부하가 발생해 대기 중인 프로세스가 있는 것으로 보면 된다.
  멀티 코어 기준으로 듀얼코어는 2.00이 100%로 사용되고 있는 상태이다.
  하드웨어가 일정 주기로 CPU에 보내는 Timer Interrupt마다 load average가 계산된다.
  
• 지금 호스팅 중인 서버의 load average를 확인해봤다.
  현재 1분동안 기준으로 부하가 약간 발생하고 있고 15분을 기준으로 해도 확장성을 고려해야 할 시점인 것을 알 수 있었다. 추가로 CPU, I/O 중 병목 원인을 알기 위해서는 sar 명령어를 이용해서 구체적인 리소스 위치를 확인한다. 다른 부분도 더 알아봐야겠지만 논제에서 벗어나므로 이 포스팅에서는 이 정도로 마무리해야겠다.

AP서버 부하

• AP서버 부하는 즉 CPU 부하를 의미하고 서버를 확장한 뒤 로드밸런서로 해결한다.
• 동일한 구조를 가지는 서버를 증가시키고, 로드밸런서로 요청을 균등하게 배분한다. (스케일아웃 방식)
• 부하를 발생시키는 프로그램 = 바운드한 프로그램

DB서버 부하

• AP서버의 부하와는 달리 DB서버를 무작성 여러 개 만든다고 해서 해결될 수 있는 문제가 아니다.
  복수 서버를 둔다고 가정했을 때, 메모리가 캐싱할 수 없는 비율이 그대로면 그만큼의 부하 이슈가 그대로 남을 수 있다.
• 1) 메모리에서 처리하고, 디스크 seek 최소화, 국소성을 활용한 분산한다.
  2) 적합한 알고리즘을 이용한다.
  3) 데이터 압축과 정보검색기술(용도에 특화된 검색엔진)을 이용한다.
• OS 캐시로 디스크 캐싱으로 탐색속도를 빠르게 하고, 오래된 캐시는 LRU에 따라 파기되게 한다.
  물리 메모리가 큰 경우 전부 캐싱, 메모리가 비싸기 때문에 확장성에 고려가 필요하다.
• 또는, 데이터를 적절하게 분할하는 파티셔닝이 필요하다. 하지만 파티셔닝은 가장 마지막에 고려될 요소이다. 왜냐하면 파티셔닝으로 인해 대수가 증가하게 되면 고장률 또한 증가한다. 그리고 운용이 어려워 복구시간이 증가하고, 경제적 비용도 추가로 발생하기 때문이다.
  1) 테이블의 크기나 액세스를 고려한 분할
  2) 용도에 따라 봇을 담당하는 DB와 기본 DB를 나눠서 관리할 필요가 있다.
• 인덱스의 필요성과 탐색횟수 개선
  MySQL의 B+트리 테이블구조는 최적화된 데이터 구조이다.
  이분트리와 비교했을 때, 포인터값만 가지며, 맨 마지막 leaf node에만 실제값을 갖는 구조이기 때문이다.
• 레플리케이션
  슬레이브 - 마스터 구조로 되어 있을 때, 마스터에 갱신쿼리로 입력된 내용은 슬레이브로 폴링(polling)되어 갱신된다. 즉 같은 DB 정보를 공유하게 되는 것이다. 탐색쿼리는 슬레이브를 이용한다.
  멀티 마스터 기능으로 상호간 레플리케이션이 이뤄지게 하는 방법도 있다. DB서버를 VRRP(Virtual Router Redundancy Procotol)로 Active 또는 Standby 상태로 전환하는 것이다.
  갱신이 많은 경우, 마스터 확장은 어렵기 때문에 테이블 분할이나, 디스크 분할, 또는 key-value 스토어를 이용해 확장을 할 수 있다. 참고로 90%의 웹 애플리케이션에서 대부분은 참조쿼리를 이용한다.

시스템 불안정 요인

• 기능추가로 인한 부하증가
• 메모리 누수
• 무한루프나 비정상적인 메모리를 소비하게 되는 코드
• 사용자의 액세스 패턴
• 데이터량의 증가
• 외부연계 API의 영향
• 하드웨어 불안정성으로 인한 처리능력 저하

 

 

대규모 서비스를 지탱하는 기술 - 교보문고