[대규모 서비스를 지탱하는 기술] 현대 웹 서비스 구축에 필요한 실전 기술

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

작업 큐 시스템

---

웹 서비스와 요청

웹 서비스에서는 기본적으로 요청이 동기적으로 실행된다. 즉 요청에 기인하는 모든 처리가 끝난 다음에 응답이 반환된다.

• 따라서 계속 성장해가는 웹 서비스에서는 데이터가 서서히 축적되면서 데이터를 추가하고 갱신하는 처리가 점점 무거워진다.
• 양호했던 성능도 시간이 지남에 따라 악화되고 서비스 사용자 경험에 영향을 주는 경우가 발생한다.

이런 경우에 작업 큐 시스템을 사용함으로써 나중으로 미뤄도 되는 처리를 비동기로 실행할 수 있고 사용자 경험도 개선할 수 있다.

 

작업 큐 시스템 입문

어느 정도 양이 있는 비동기 처리를 안정적으로 수행하려면 작업 큐와 워커를 세트로 한 작업 큐 시스템을 사용하는 것이 일반적이다.

• 작업큐 시스템에서는 작업 큐에 실행하고자 하는 처리를 등록하고, 워커가 큐에서 작업을 추출해서 실제로 처리한다.
• 작업큐를 통해서 일시적으로 대량의 처리가 등록되었을 때 부하의 변동을 흡수할 수가 있다.
• 워커는 항상 실행해둠으로써 작업을 처리할 때 초기화 오버헤드를 거의 없앨 수 있다.

 

스토리지 선택

---

웹 애플리케이션과 스토리지

스토리지란 애플리케이션 데이터를 영속적으로 혹은 일시적으로 저장하기 위한 기능이라고 할 수 있다.

데이터는 여러 가지 종류가 있다.

• 본질적으로 없어질 수 없는 원본 데이터
• 원본 데이터를 가공함으로써 생성된 액세스 랭킹이나 검색용 인덱스 데이터 등 재생성 가능한 가공 데이터
• 캐시와 같이 사라져도 성능상의 문제 이외에는 다른 문제가 없는 데이터

각 데이터의 특성에 따라 고려할 수 있다.

• 특히 원본 데이터는 가장 중요해서 서비스의 근본적인 신뢰성과 관계되어 있으므로 그에 상응하는 비용을 들여서 최상급 신뢰성을 확보해야 한다.
• 반면, 캐시와 같은 데이터의 신뢰성은 그다지 중요시되지 않고 성능을 높이거나 비용을 줄일 필요가 있다.

 

적절한 스토리지 선택의 어려움

스토리지를 잘못 선택한 채로 서비스를 시작하게 되면 나중에 알아차리더라도 스토리지 변경은 보통 방법으로는 뜻대로 이룰 수 없다. 특히 서비스를 시작한 후에 순조롭게 인기를 얻어가면서 자주 이용하게 된 서비스의 경우, 저장된 데이터량도 커지고 서비스 정지의 영향도 커서 더욱더 어려워진다.

 

스토리지 선택의 전제가 되는 조건

스토리지를 선택할 때에는 애플리케이션에서의 액세스 패턴을 이해하는 것이 중요하다.

액세스 패턴으로는

• 평균 크기
• 최대 크기
• 신규 추가 빈도
• 갱신 빈도
• 삭제 빈도
• 참조 빈도

 

스토리지의 종류

RDBMS

• 테이블 형태로 데이터를 저장하고 대부분은 SQL 언어로 데이터 조작을 수행하는 시스템.
• 다양한 데이터를 저장한다거나 강력한 질의를 할 수 있어서 가장 범용적이 높은 스토리지이다.
• MySQL 
  • MySQL의 아키텍처는 SQL을 해석해서 실행하는 MySQL 엔진과 실제 데이터를 보관하는 스토리지 엔진으로 분리되어 있다.
  MyISAM vs InnoDB
  • MyISAM은 insert 조작을 빠르게 할 수 있고, 시작 및 정지가 빠르며 테이블 이동이나 이름 변경을 파일 시스템 조작으로 직접 할 수 있는 등 DB 운용은 용이하다
  • 반면에 DB 프로세스가 비정상 종료하면 테이블이 파손될 가능성이 높다거나 트랜잭션 기능이 없고 update, delete, insert가 테이블 락으로 되어 있어서 갱신이 많은 용도로는 성능적으로 불리하다는 등 몇 가지 단점도 존재한다.
  • InnoDB는 트랜잭션을 지원하며, 비정상 종료 시 복구 기능이 있고, 데이터 갱신이 로우 락으로 되어 있는 등 장점이 있다.
  • 다만 데이터량에 따라서는 시작, 정지가 수 분 정도 걸린다거나 테이블 조작을 모두 DB를 경유해서 수행해야 하는 등의 단점도 존재한다.

 

분산 key-value 스토어

key-value 스토어는 key와 value 쌍을 저장하기 위한 심플한 스토리지.

분산 key-value 스토어는 key-value 스토어에 네트워크를 지원함으로써 다수의 서버로 확장시키는 기능을 지닌 것.

key-value 스토어는 RDBMS에 비해 기능적으로 부족하지만, 성능이 10~100배 이상이라는 게 특징이다.

 

memcached

• 파일 시스템을 사용하지 않고 메모리 상에서 동작하므로 매우 빠르게 동작.
• 메모리 상에서 동작하기 때문에 재시작할 때 데이터가 모두 사라져 버린다. (휘발성)
• 이러한 특성을 가장 잘 활용할 수 있는 데이터는 캐시 데이터이다.
• RDBMS에서 읽어 들인 데이터를 일시적으로 저장해 두고 또다시 참조할 때는 먼저 memcached를 참조해서 찾지 못한 경우에만 RDBMS를 참조하는 방법이 있다.
• 캐시로 한정할 경우에는 서버에는 메모리만 충분히 탑재해두면 되며, CPU나 I/O 성능은 그다지 요구되지 않는다.

 

분산 파일 시스템

파일 시스템의 특성상 보통은 어느 정도 이상의 크기의 데이터를 저장하는 데 적합하다.

캐시 시스템

---

웹 애플리케이션의 부하와 프락시/캐시 시스템

웹 애플리케이션의 부하가 증가해서 시스템 용량이 부족해졌을 때는 AP 서버나 DB 서버를 증설함으로써 대응할 수도 있지만, HTTP 레벨의 캐싱을 수행하는 HTTP 가속기를 사용함으로써 낮은 비용으로 효과가 높은 대책을 세울 수 있다.

HTTP 액세스를 고속화하는 HTTP 가속기 종류

포워드 프록시

• 클라이언트가 외부 서버에 액세스 할 때 사이에 두는 프록시

리버스 프록시

• 외부의 클라이언트가 내부 서버에 액세스 할 때 사이에 두는 프록시.

프록시에서는 요청에 대한 응답을 캐싱해둠으로써 다음에 같은 요청이 전달됐을 때 캐싱해둔 응답을 반환할 수 있다.

이에 따라 대역이나 서버 리소스를 소비하지 않고 빠르게 요청을 처리할 수 있다.

 

기본적인 구성

리버시 프록시와 AP 서버 2대로 이루어진 구성에서 캐시 서버를 도입할 경우, 리버시 프록시와 AP 서버 사이에 배치한다.

이에 따라 리버스 프록시에서 AP 서버로 전송되고 있던 요청 중 일부를 캐시 서버에서 처리할 수 있게 되어 시스템 전체 성능을 향상할 수가 있다.

 

효과

• AP 서버로 전송되는 요청수를 줄일 수 있으므로 AP 서버의 대수 증가를 억제, 감소할 수 있다.
• 액세스 집중 시에는 방대한 요청으로 인해 시스템 전체의 수용능력을 넘어서는 것을 막는 효과를 기대할 수 있다. 이를 위해 액세스가 집중된 콘텐츠를 캐시 서버에서 캐싱한다.

 

2단 구성 캐시 서버

• 이미지 파일 등 크기가 큰 파일을 캐싱하게 되면서 캐시 서버의 부하가 높아지면 1대나 2대 정도로는 용량이 턱없이 부족해질 경우가 있다. 이런 경우 캐싱 서버를 2단으로 구성함으로써 보다 확장성이 높은 캐시 서버군을 구성할 수 있다.

 

COSS 크기 결정방법

히트율을 높이기 위해서는 충분한 캐시 용량을 준비해둘 필요가 있다.

다만 캐시 용량은 크면 클수록 좋은 것이 아니고 과부족이 없는 상태가 최적이다.

만약 캐시 용량이 너무 크면

• 초기 시작 시에 COSS 파일 생성에 시간이 걸린다.
• 서버 재시작 등으로 메모리가 초기화된 후에 디스크 상의 파일이 메모리에 올라가고 캐시 서버의 성능이 안정되기까지 시간이 걸린다.
• 디스크 용량을 압박한다.

반대로 캐시 용량이 너무 적으면

• 필요한 오브젝트가 저장되지 못해서 캐시 히트율이 떨어진다.

최적의 용량은

• 1초당 저장된 오브젝트 * 오브젝트의 평균 크기 * 오브젝트의 평균 유효시간로 계산되는 크기가 된다.

 

주의사항

캐시 서버의 효율을 올릴수록 필연적으로 캐시 서버에 장애가 발생했을 때의 영향이 커진다.

• 그래서 1대가 고장 나더라도 문제가 없을 정도의 서버를 준비하는 것이 정석이다.

또한 수리된 서버나 새로운 서버를 로드밸런서에 추가할 때 성능이 단번에 떨어져 버리는 경우가 있다.

• 재시작되거나 새로 구성한 캐시 서버가 요청을 처리하기 위한 충분한 준비가 되어 있지 않기 때문.
• 이상적으로는 사전에 평상시에 접수되는 요청을 보내서 워밍업을 해둘 필요가 있다.
• 혹은 로드밸런서에 추가할 때 트래픽 비율을 조정해서 통상 운용 시에 비해 적은 트래픽부터 흘려보내기 시작하는 게 좋다.

 

계산 클러스터

---

대량 로그 데이터의 병렬 처리

대량의 로그에 대해 통계 처리나 분석을 하려고 하면 엄청나게 큰 계산 리소스를 필요로 한다.

• 이와 같은 처리를 빠르게 수행하기 위해서는 병렬 처리가 가능한 계산 클러스터가 필요하다.
• 대표적으로 Hadoop을 들 수 있다.