개발공부 기록지

목차

• 작업큐 시스템
  • 작업큐 시스템 입문
  • 하테나에서의 작업큐 시스템
  • 로그 분석
• 스토리지 선택
  • 웹 애플리케이션과 스토리지
  • 스토리지 선택의 전제가 되는 조건
  • RDBMS
  • 분산 key-value 스토어
  • 분산 파일시스템
  • 스토리지의 선택전략
• 캐시 시스템
• 계산 클러스터
  • MapReduce
  • Hadoop

작업큐(Job-Queue) 시스템

작업큐 시스템의 필요성

웹 서비스에는 기본적으로 요청이 동기적으로 실행된다.

따라서, 계속 성장해가는 웹 서비스에서는 데이터가 누적되면서 데이터를 추가하고 갱신하는 처리가 점점 무거워진다.

이 때문에, 양호했던 성능도 시간이 지남에 따라 악화되고 서비스 사용자 경험에 영향을 주게 된다.

→ 작업큐 시스템을 이용하여 나중으로 미루어도 되는 작업을 비동기로 실행 가능

→  사용자 경험개선 가능

(하테나  경우)

사용자가 URL을 북마크했을 때의 처리를 작업큐 시스템에서 처리

작업큐 시스템 입문

가장 간단하게 비동기화하는 방법

• 비동기화하고자 하는 처리를 독립된 스크립트로 해서 해당 스크립트를 애플리케이션 내부에서 호출하는 방법
  • 단점
    • 스크립트 시작과 초기화의 오버헤드가 크다.
    • 대량의 비동기 처리를 실행시키려 하면 그 수만큼의 프로세스를 실행해야 한다.
  • 프로토타입이나 소규모 애플리케이션에만 적용하는 것을 추천

많은 양의 비동기 처리를 안정적으로 하는 방법

• 작업큐(job-queue)와 워커(worker)를 세트로 한 작업큐 시스템을 사용
  • 작업큐에 실행하고자하는 처리를 등록 ▶ 워커가 큐에서 작업을 추출하여 처리

클라이언트 ( 웹 애플리케이셔) - 작업을 투입. 작업을 투입한 다음 처리를 계속 진행할 수 있다.

작업큐 - 작업을 쌓는다.

워커 - 작업큐를 참조, 미실행된 작업을 추출해서 작업을 실행

하테나에서의 작업큐 시스템

Perl로 구현된 시스템

TheSchwartz - 작업큐

• MySQL과 같은 RDBMS를 사용하는 작업큐 시스템 
• 비동기로만 가능

Gearman - TheSchwartz 보다 가벼운 작업큐

• RDBMS 가 아닌 독자적인 데몬을 사용해서 작업의 정보를 메모리에 저장
• 동기적으로 순번대로 처리
• 동기적으로 병렬로 처리
• 비동기적으로 백드라운드로 처리

WorkerManager에 의한 워커 관리

• 워커 프로세스를 좀더 세세하게 제어하기 위한 시스템 (하테나에서 개발)
• TheSchwartz 와 Gearman을 래핑해서 최소한의 변경으로 양쪽에 대응
• 설정파일로 워커 클래스 정의. 설정파일만 수정해서 워커로서 사용할 클래스를 변경 가능
• 워커 프로세스의 라이프사이클 관리. 프로세스 관리. 데몬화 수행
• 워커 프로세스의 프로세스 개수 관리. 프로세스 개수를 관리하고 병행처리가 가능한 작업수를 제어
• 로그 출력. 작업을 처리한 타임스탬프 등을 로그에 기록

로그분석

처리시간과 지연시간을 측정함으로써 투입된 작업 종류와 양에 대해 워커의 처리능력이 충분한지여부 확인 가능하다.

(예) 지연시간이 길어지는 경우 ▶ 아무리 비동기 처리라고 하더라도 사용자 경험상 문제가 되는 경우 발생

→ 이 경우 워커의 튜닝과 보강을 생각해야 할 시점

스토리지 선택

웹 애플리케이션에 있어서 "증가하는 데이터를 어떻게 저장할까?" 라는 문제는 영원한 과제다.

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

스토리지?

애플리케이션 데이터를 영속적으로 혹은 일시적으로 저장하기 위한 기능

원본데이터

애플리케이션에 업로드된 사진, 블로그 본문과 같이 영속적으로 저장되어야 하는 데이터

가장 중요해서 서비스의 근본적인 신뢰성과 관계있다 → 비용을 들여서라도 최상급 신뢰성 확보

캐시

액세스 랭킹이나 검색용 인덱스 데이터와 같이 재생성 가능한 가공데이터

신뢰서은 그다지 중요하지 않음 → 비용을 줄일 필요 있음

애플리케이션에 필요한 데이터의 예

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

적절한(저장하고자 하는 데이터의 특성에 맞는) 스토리지 선택의 중요성

• 비용과 성능, 안정성의 균형을 높은 차원으로 달성하기 위한 열쇠
• 스토리지를 잘못 선택한 채로 서비스를 시작하게 되면 나중에 알아차리더라도 스토리 변경은 보통 방법으로는 뜻대로 이룰 수 없다.
• 가능한 한 특성에 맞는 스토리지를 선택하여 하나의 스토리지를 오래도록 사용하는 것이 바람직하다.

하지만,  서비스 성장을 예측하는 것은 어려우며 기술도 진화해가므로 스토리지 설계를 전혀 갱신하지 않고 가는 것은 어렵다.

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

애플리케이션에서의 액세스 패턴을 이해하기 위한 지표

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

추가) 크기에 요구되는 신뢰성, 허용할 수 있는 장애 레벨, 사용할 수 있는 하드웨어나 쓸 수 있는 예산 도 중요한 포인트

RDBMS

RDBMS(Realtional Database Management System) 

• 표 형식으로 데이터를 저장하고 대부분은 SQL 언어로 데이터 조작을 수행하는 시스템
• 다양한 데이터를 저장한다거나 강력한 질의를 할 수 있어서 범용성이 높은 스토리지

MySQL

• 특징: SQL을 해석해서 실행하는 기능 블록과 실제로 데이터를 보관하는 기능 블록이 분리되어 있음

스토리지 엔진

MyISAM

• 1 개의 테이블이 실제 파일 시스템 상에 3개의 파일(정의, 인덱스, 데이터)로 표현
• 장점
  • 시작과 정지가 빠름
  • 테이블 이동이나 이름변경을 직접 가능
• 단점
  • DB 프로세스가 비정상 종료하면 테이블이 파손될 가능성 높음
  • 트랜잭션 기능이 없음
  • update, delete, insert가 테이블 락으로 되어 있어 갱신이 많은 용도로는 성능적으로 불리

InnoDB

• 스토리지 엔진 전체에서 사전에 정의한 소수의 파일에 데이터를 저장.
• 장점
  • 트랙잭션 지원
  • 비정상 종료시 복구기능 존재
  • 데이터 갯인이 로우 락(Row Lock)으로 되어 있음
• 단점
  • 데이터량에 따라 시작, 정지가 수 분 정도 걸린다.
  • 테이블 조작을 모두 DB를 경유해서 수행해야 한다.

정리

• 추가처리만 한다 → MyISAM가 적합한 스토리지 엔진
• 갱신빈도가 높고 트랜잭션이 필요하다 → InnoDB가 적합한 스토리지지 엔진

분산 key-value 스토어

• key-value 스토어 : key와 value 쌍을 저장하기 위한 심플한 스토리지
• 분산 key-value 스토어 : key-value 스토어에 네트워크를 지원함으로써 다수의 서버로 확장시키는 기능을 지닌 스토리지

memcached (key-value 스토어)

• 메모리 상에서 동작
• 서버 증감의 영향을 받지 않음
• 분산 알고리즘을 클라이언트 라이브러리로 구현
• 원본 데이터 및 가공 데이터 저장에는 부적합
• RDBMS 등에서 읽어들인 데이터를 일시적으로 저장해 두어 참조하는 용으로 적합

    → memcached 의 특성을 가장 잘 활용할 수 있는 데이터는 캐시 데이터

    → 캐시로 한정할 경우 서버에는 메모리만 충분히 탑재해두면 된다.

TokyoTyrant (key-value 스토어)

• 로컬에서 동작하는 key-value 스토어인 TokyoCabinet에 네트워크를 지원하도록한 구현
• 다중성을 높이기 위한 레플리케이션 기능을 내장
• 성능면에서는 디스크 액세스가 발생하여 memcached 보다는 약간 떨어진다. 하지만 RDBMS 와 비교하면 상당히 빠름

분산 파일시스템

어느 정도 이상인 크기의 데이터를 저장하는데 적합

작은 데이터가 대량으로 존재하는 용도에는 부적합?

MogileFS

용도

• 비교적 작은 대량의 파일을 다룰 목적으로 Perl로 구현된 분산 파일시스템 (수KB ~ 수십MB의 이미지 파일)
• 이미지 파일과 같이 추가된 다음 갱신되지 않고 참조하기만 하는 용도에 적합(업로드 이미지 파일을 접수받는 웹 앱)

특징

• 스토리 서버 상에서 개개의 파일은 실제 파일 시스템 상에서도 하나의 파일로 저장 
• 통상 하나의 파일은 3중으로 다중화되어 일부 스토리지 서버가 고장나서 데이터가 손실되더라도 시스템 전체로서는 계속 정상적으로 동작할 수 있도록 설계되어 있다.
• 파일을 참조할 때 WebDAV 프로토콜로 얻게되므로, 애플리케이션 측에 구현 필요
• 미디어 위주의 서비스에서 수십TB 영역이 필요한 미디어 파일을 위한 스토리지로서 충분히 대응할 수 있는 확장성
• 파일 저장소와 파일을 특정 짓기 위한 키와 대응관계는 메타데이터로 RDBMS에 저장

*WebDAV 서버: HTTP를 기반으로한 프로토콜로 애플리케이션 계층에서 구현되는 경우가 많아서 NFS(커널계층에 구현) 보다 안정적인 시스템을 구축 가능

그 밖의 스토리지

NFS 계열 분산 파일시스템

• NFS 는 특정 서버의 파일시스템을 다른 서버에서 마운트해서 해당 서버의 로컬 파일시스템과 마찬가지로 조작할 수 있도록 하는 기술.

DRBD(Distributed Replicated Block Device)

• 네트워크 계층에서 RAID라고 할 수 있는 기술, 블록 디바이스 레벨에서 분산, 다중화 할 수 있는 기술

HDFS(Hadoop Distributed file system)

• Hadoop 용으로 설계된 분산 파일시스템

스토리지의 선택전략

캐시 시스템

웹 애플리케이션의 부하가 서서히 증가해서 시스템 용량이 부족한 경우

1. AP 서버 증설
2. DB 서버 증설
3. HTTP 레벨의 캐싱을 수행하는 HTTP 가속기를 사용( 낮은 비용 으로 효과가 높은 대책)

HTTP 가속기

• 포워드 프록시 - 클라이언트가 외부 서버에 액세스할 때 그 사이에 두는 프록시
• 리버스 프록시 - 외부 클라이언트가 내부 서버에 액세스할 때 그 사이에 두는 프록시
• 프록시 : 요청에 대한 응답을 캐싱해두어 같은 요청이 전달됐을 때 캐싱해둔 응답을 반환

리버스 프록시 캐시 서버

구현 툴

• Squid
• nginx
• pound
• Varnish

계산 클러스터

대량으로 쌓인 로그 데이터의 처리(ex 120gb) ▶ HDD에서 읽어 들이는데만 5 시간 이상

→빠르게 수행하기 위해서 병렬처리가 가능한 계산 클러스터 필요

MapReduce의 계산모델

Hadoop 이라는 MapReduce의 오픈소스

MapReduce - 2004년 Google 에서 발표한 계산 모델

방식

- key 와 value 쌍의 리스트를 입력 데이터로 해서 최종적으로 value의 리스트를 출력

- map 단계와 reduce 단계로 구성

계산모델 사진

• Map 단계
  1. 먼저 마스터 노드에서 입력 데이터를 잘게 분할해서 각 노드로 분산
  2. 각 노드에서는 분할된 입력 데이터를 계산하고 계산결과를 key 와 value 쌍으로 구성된 중간 데이터로 출력
     • Map 단계의 처리 예시 : (k1, v1) → list(k2, v2)
• Reduce 단계
  1. Map 단계에서의 출력 데이터를 key(k2) 별로 정리해서 key(k2)와 key에 대응하는 값의 리스트( list(v2) ) 로 재구성
  2. 각각의 key를 각 노드로 분산 ( shuffle phase)
  3. 각 노드에 있는 key(k2)와 key에 대응하는 값의 리스트( list(v2) )를 입력 데이터로 해서 각 리스트( list(v3) )를 최종적인 출력 데이터로 처리를 수행
     • Reduce 단계의 처리 예시 : ( k2, list(v2) ) →  ( k2, list(v3) )
• 최종
  • 각 노드에서  값의 리스트 list(v3) 를 집약하면 계산이 완료

응용범위

• 로그 분석, 검색엔진의 인덱스 생성

MapReduce 계산모델

• Map과 Reduce라는 두가지 처리를 수행하는 함수를 준비하는 것만으로 대량의 데이터를 빠르게 처리 가능
• 대량의 입력 데이터를 읽어들이는 부분이 성능의 병목이 되는 경우 많다.
  • 분산 파일시스템과 병용하는 것이 중요
    • DVD 1 장 분량의 데이터에 대한 grep 을 2초 만에 끝낼 수 있는 성능을 구현 가능

Hadoop

Hadoop은 Apache 프로젝트 중 하나로 MapRedue의 오픈소스 구현 중 하나(java 로 구현)

로그 분석 작업을 실행 할때 유용하다고 함.

예) 47GB의 데이터를 4303개의 Map 태스크로 분할해서 실행하고 1 개의 Reduce 태스크로 집약하여 처리 가능

목차

• 네트워크 분기점
  • 1 Gbps의 한계
  • 500 호스트의 한계
  • 글로벌화, CDN
• 한층 높은 단계로

네트워크 분기점

1 Gbps의 한계 - PC 라우터의 한계

리눅스 커널을 사용하면 대략 30만 패킷/초가 한계

평큔 패킷 길이가 300 바이트면 대략 1 Gbps 

한계

• 커널의 성능  = 30만 패킷/초
• Gigabit Ethernet 레벨 = 1 Gbps

대책

• PC 라우터를 여러 대 병렬화
• 박스형 라우터(Cisco 라우터) 사용 - 비싼 가격

500 호스트의 한계 - 1 서브넷, ARP 테이블에서의 한계

500 호스트의 한계는 스위치의 ARP 테이블 (Address Resolution Protocol table)과 관련된 한계

*ARP 테이블?  IP 주소(호스트 주소와 서브넷 주소)와 MAC 주소 간 관계를 나타내는 테이블로 스위치가 이 테이블을 지니고 있음

1 서브넷에 배치 할 수 있는 호스트수 = 약 500

브로드캐스팅 통신에 의존한 처리가 많아지면(트래픽) → CPU 부하가 수십%까지 상승  →  패킷 손실 발생

*브로드캐스팅: 네트워크 상의 모든 장치에 데이터 패킷을 전송하는 통신 방법

• 브로드캐스트 트래픽이 많아지면 네트워크 장비나 서버의 CPU에 상당한 부하를 줄 수 있고, 이는 처리 능력의 한계로 인해 CPU 사용률이 상승하게 됩니다. CPU 부하가 과도하게 높아지면 패킷 처리가 지연되거나 제대로 이루어지지 않아 패킷 손실이 발생

네트워크 구조 계층화

앞에서 언급된 한계에 대한 대책으로 네트워크를 3단계로 구성하고 있다.

1. Access 계층(액세스 영역): 서버의 엔드포인트에 접근을 제공하는 계층 
2. Distrution 계층 : 트래픽을 각 서브넷에 전송하는 계층
3. Core 계층 혹은 OSPF(Open Shortest Path First) 영역 : 트래픽의 큰 흐름을 담당하는 계층

이 3단 구조로, 가장 작은 서브넷 Access 계층에서 100대 200대 로 억제하고 디스트리뷰션을 1000대 정도 코어 전체로는 10,000대 단위를 다룰 수 있다는 계층구조를 설계한다.

글로벌화, CDN

세계 각지에서 HTTP로 데이터를 가져가려고 한다면 하나의 나라에 위치하고 있는 데이터 센터에서 전송을 한다는 것은 비현실적이다.

이에 대한 대안으로 CDN(Content Delivery Network) 가 있다.

CDN 전문 업체 중 하나가 Amazon Cloudfront 이다.

CDN 의 작동원리

세계 각지에 서버를 두고 데이터를 캐싱해서 사용자가 가지고 가려고 할때 사용자와 가장 가까운 서버로 엑세스해서 접근할 수 있게 해주는 원리

Amazon Cloudfront 작동 원리

1. 사용자가 웹사이트나 어플리케이션을 요청할 때 가장 가까운 CloudFront 엣지 로케이션으로 요청이 전송됨.
2. 요청받은 콘텐츠가 해당 엣지 로케이션에 캐시되어 있지 않은 경우, CloudFront는 원본 서버(예: Amazon S3 버킷 또는 EC2 인스턴스)로부터 콘텐츠를 가져와 사용자에게 전달.
3. 콘텐츠는 최적화된 네트워크 경로를 통해 사용자에게 전달( 로딩 시간 단축)
4. 콘텐츠가 업데이트 되었을 경우, 새 콘텐츠로 캐시를 갱신하고, 필요시 무효화 처리를 통해 최신 콘텐츠가 사용자에게 제공됨.

한층 높은 단계로

10Gbps 이상의 세계

• AS(Autonomous system) 번호 보유
• IX(Internet exchange) 에 접속해서 트래픽 교환
• BGP(Boader Gateway Protoclo)로 라우팅 제어

목차

• 가상화 기술
  • 소단원
  • 소단원
  • 소단원
• 하드웨어와 효율향상
  • 소단원

가상화 기술

가상화 기술의 목적

• 확장성 - 오버헤드 최소화
• 비용대비 성능 - 리소스 사용률 향상, 운영의 유연함(환경의 단순화)
• 고가용성 - 환경의 격리

가상화 기술의 효용

• IPMI(Intelligent Platform Management Interface)를 대체하는 하이퍼바이저
  
  • IPMI : 벤더 서버에 있는 리모트 관리기능
  • 하이퍼바이저 : 호스트 OS, 서버 상에 최초로 기동하는 OS
• 하드웨어 간 차이 흡수( → 환경 추상화)
  • 새로운 하드드웨어나 오래된 하드웨어로도 차분에 신경 쓰지 않고 사용 가능
• 준 가상화(ParaVirtualization) 사용 - Xen 에 특화된 내용
• 리소스 소비 제어
  • 과부하 경고
  • 부하 조정

가상화 서버 구축정책

가상화 기술을 도입하는 가장 기본적인 목적은 하드웨어의 이용효율 향상

방법

- 남아있는 리소스를 주로 이용하는 게스트 OS를 투입

• CPU 리소스가 남아있다 ▶ 웹 서버 
• I/O 리소스가 남아있다  ▶ 캐시 서버

주의할 점

• 같이 두는 것을 피하는 형태의 조합
  • 리소스 소비경향이 비슷하고 부하가 높은 용도의 게스트 OS 끼리(각가의 웹 서버끼리 등)는 리소스를 서로 점유하려고 하기 때문
• 중앙 스토리지는 사용하지 않는다.
  • 고가의 스토리지를 사용하지 않으면 충분한 안정성 확보 불가.

구체적인 게스트OS 구성예시 그림

가상화로 얻은 장점 

물리적인 리소스 제약에서 해방

• 리소스를 동적으로 변경
• VM(게스트 OS)의 마이그레이션이나 복제 용이

→ 서버 증설이 용이  → 더 나은 확장성 확보

소프트웨어 레벨의 강력한 호스트 제어

• 비정상 동작 시 문제 국소화
• 호스트 제어가 용이

→ 하드웨어와 운용 비용 저하 → 비용대비 성능 향상, 고가용성으로 발전

가상화 도입 시 주의할 점

• 성능상 오버헤드 존재
• 가상화 기술이 병목현상의 원인이 될 수도 있다.
• PC 라우터에서는 가상화를 사용하기 때문에 성능이 떨어지는 경우 존재

하드웨어와 효율향상

저가 하드웨어의 유용한 이용 방침

• 최소한의 관리기능
• 많은 코어CPU
• 대량의 메모리
• flexible 한 I/O 성능
  • Diskless
  • 하드웨어 RAID-10
  • SSD RAID-10
• 관리용 하드콘솔 불필요
  • IPMI 기능 →Intel AMT

SSD

하테네에서는 주로 다수의 DB 슬레이브 서버에 사용 I/O  때문

액세스 성능

• 양호한 랜덤액세스 성능
• 메모리 > SSD > HDD RAID-0/10 > HDD RAID-1

목차

• 다중성 확보
  • AP 서버
  • DB 서버
  • 스토리지 서버
• 시스템 안정화
  • 시스템의 불안정 요인
• 시스템 안정화 대책

다중성 확보

AP 서버

서버가 멈추면 이에 대한 대응으로 로드밸런서로 페일오버(failover, 장애극복) 페일백(failback, 정상복귀) 하여 고장난 서버를 자동적으로 분리하고 서버가 복귀 되면 원상태로 복귀시키는 작업을 수행하고 있다. 

페일오버(failover, 장애극복) 페일백(failback, 정상복귀) 방식 그림

위의 그림처럼, 서버가 10대 정도 있으면 1, 2대 서버가 정지하더라도 서버에 큰 영향을 주지 않아 운영하는데 수고를 줄일 수 있다.

DB 서버

DB 서버도 마찬가지로 서버를 여러대 나열해서 1, 2대 정지하더라도 충분한 처리능력이 있도록 해두는 것이 중요

다중화 ( 24시간 365일 100% 가동률) 을 위해서 멀티 마스터 방법을 사용

멀티 마스터?

- 쌍방으로 레플리케이션, 즉 서로가 서로의 슬레이브가 되는 상태로 해두고 한쪽에 쓰기작업을 하면 다른 한쪽으로 전달하고 반대쪽에 쓰더라고 다른쪽으로 전달하는 양방향 레플리케이션 방법

MySQL의 경우

한쪽에서 쓰기 작업을 수행하면 데이터가 반대쪽으로 전달되기까지 약간의 지연이 발생

→ 특정 시점에서는 데이터가 완전히 일치하지 않는 경우가 존재

→ 이 시점에 한쪽 서버가 분리되어 다운되면, AP 서버가 특정 데이터를 쓰려고 시도했을 때 이 데이터가 실제로는 쓰이지 않는 모순된 상황이 발생

▶ 해결방안

• 엔터프라이즈에서는 이를 대처하기 위해 레플리케이션을 동기적으로 처리
• 웹 서비스에서는 동기가 맞지 않는 리스크를 어느 정도 받아들임으로써 성능을 중시

멀티 마스터

MySQL 서버 구축에서 주류

페일오버(장애 극복)에 대한 구체적인 동작

- 상호간에 VRRP(Virtual Router Redundancy Protocol)라는 프로토콜로 감시.

- VRRP에 의해 한쪽이 분리된 것을 알게 되면 자신이 Active 마스터로 승격

멀티 마스터 구성  =  기본적으로 서버 2대 + Active/Standby 구성 → 항상 Active 쪽만 쓰기작업을 한다.

방식

Active 인 서버가 다운되면 Standby 였던 쪽이 Active로 승격해서 새로운 마스터가 된다.

다운된 서버는 수작업으로 복구 후

→ Active 역할을 맡았던 서버를 계속 Active로 유지하고 복구된 서버를 Standby로 설정 

→ 문제가 있던 서버를 다시 Active로 설정하고 기존의 Standby 서버를 다시 Standby로 설정

이 방식은 전환 타이밍에 따라 동기가 맞지 않은 위험이 남아 있음

→ 현 상황에서는 깨긋이 받아들이고(시스템이나 네트워크에서 발생할 수 있는 어떤 이슈나 문제를 인정하고) 수동으로 복구

참고

DB 서버 (슬레이브방식)

• 서버를 여러 대를 나열한다.
• 서버 1, 2대 정지하더라도 충분히 처리할 수 있도록 해둔다.

스토리지 서버

이미지 파일과 같은 미디어 파일을 저장하기 위해서 분산 스토리지 서버로 MogileFS가 있다.

분산 파일 시스템을 사용

- 확장성 : 대량의 파일의 보존 가능

- 다중성 : 일부 서버가 다운되더라도 전체 장애가 되지 않음

MogileFS

- 파일은 파일로 저장

- 파일이 어디에 위치해 있는지를 나타내는 메타 정보를 별도로 관리하는 방법

시스템 안정화

시스템 안정화와 상반관계

* 안정성 ↔ 자원효율

  한계에 이를 때까지 CPU 사용 - 자원 효율 향상 - 비용절감

    하지만 서버 1대가 다운 → 전체 처리능력 초과 → 장애

* 안정성 ↔ 속도

  한계에 이를 때까지 메모리를 튜닝 - 속도 향상

    하지만 메모리소비가 늘어난다 → 성능 저하 →  장애 

시스템의 불안정 요인

전형적인 요인들

◆ 애플리케이션/서비스 레벨 → 부하 증가

1. 기능추가, 메모리 누수
   • 새로운 기능을 추가했는데 그 기능이 예상보다 무거워서 전체적인 부하가 늘어나 서비스가 다운
   • 메모리 누수는 완전히 배제하기 어려운 문제 - 버퍼가 너무 작으면 시간이 지남에 따라 버퍼를 다 사용해서 스왑을 사용하기 시작해서 부하가 증가
2. 지뢰
   • 특정 URL이 읽히면(지뢰를 밟으면) 아무리 시간이 지나도 응답이 오지 않아서 마치 지뢰처럼 장애의 원인이 되는 현상
3. 사용자의 액세스 패턴 :
   • 인기많은 사이트에 링크를 걸어두면 그 사이트 사용자가 집중적으로 접속해서 다운되는 경우와 같은 사용자의 패턴
4. 데이터량 증가
5. 외부연계 추가
   • Amazon API 와 연결된 서비스가 있을때 Amazon이 다운되면 해당 서비스도 다운

◆ 하드웨어 → 처리능력 저하

1. 메모리, HDD 장애, NIC(Network Interface Card) 장애

시스템 안정화 대책

적절한 여유(버퍼) 유지

• 메모리량, CPU 부하 → 한계의 7할 운용

불안정 요인 제거

• SQL 부하의 상한선을 미리 정함
• 메모리 누수를 줄임
• 이상 동작시 자율제어
  • 자동 DOS 판정
  • 자동 재시작 (AP 서버, 호스트 OS)
  • 자동 쿼리제거

목차

• 계층과 확장성
• 부하파악, 튜닝
  • 부하파악 : 가시화
  • 부하를 측정하기 위한 항목 : Load Average, 메모리 관련, CPU 관련
  • 용도에 맞는 튜닝 - 사용자용 서버, 봇용 서버
  • 튜닝 및 확장성 확보

계층과 확장성

확장성에대한 요구

• 서버 1대로 작동하는 서비스가 다수
  • 하테나 표준 서버 (4 core CPU, 8 GB 메모리) 예시
    • 피크 시 성능은 수천 요청/ 분 → 월 100 만 page view 처리 가능
  • 고성능 서버 (4 core CPU 2개, 32 GB 메모리)
    • 피크 시 : 월 200 만 page view 처리가능
• 하테나에서 수억 page view / 월
  • 대규모 서비스는 서버 1대로는 동작할 수 없다.

계층별 확장성

• AP 서버 ▶ 비교적 간단하게 확장가능
  • 구성이 동일하고 상태를 갖지 않기 때문
• DB / 파일 서버 ▶ 분산, 확장성 확보가 어려움
  • read 분산 : 비교적 용이  ▶ 메모리를 많이 탑재, 기타
  • write 분산 : 매우 어려움

→ AP 서버 와  데이터 소스를(DB / 파일 서버) 구분해서 확장을 고려해야 한다.

부하 파악,  튜닝

부하파악 - 가시화

어떻게 서버를 확장할 것인지를 검토하기 위해서는 먼저 서버 부하를 파악할 수 있어야 한다.

서버군을 관리하고 각각의 부하를 적절하게 그래프화하는 것이 중요

하테나 북마크 예시

부하를 측정하기 위한 항목 - Load Average,  CPU 관련, 메모리 관련

가장먼저 Load Average 확인

*Load Average ?
     프로세스가 언제든지 동작할 수 있는 상태이지만, 아직 실제 CPU가 할당되지 않아서 대기상태에 있는 프로세스의 수의 평균치
    (ex) 5분 동안 Load Average가 1이면 => 5분동안 평균 1개의 프로세스가 대기상태로 되어 있다는 의미, 이때 CPU의 코어 수 이하이면 부하가 양호한 편 (보통 CPU의 코어 수 이하에서 절반 정도로 맞춰지도록 제어함)

메모리 사용처 확인

 사용자 공간이 소비되고 있는 메모리나 공유되고 있는 메모리, 그리고 커널이 사용하고 있는 버퍼의 메모리

이런 항목을 통해 ▶ " 이런 거동을 하고 있으니 이런 동작을 보이고 있어" 와 같이 파악 ▶ 서버의 성능을 더 끌어내 고성능 시스템을 실현

용도에 맞는 튜닝 - 사용자용 서버, 봇용 서버

서버 분리

• 봇용 : 응답시간이 중요하지 않음 → 요청 처리 수를 최대화시키는 방향으로 튜닝 가능
• 사용자용 : 응답시간 중요 → 처리대기 프로세스를 쌓아두지 않고 양호한 응답을 유지하는 방향으로 튜닝 가능

봇과 사용자를 분리하여 AP 서버의 튜닝 정책을 변경해서

• 효율을 중시할지
• 응답시간을 중시할지
• 리소스를 최대한 사용하는 것을 중시할지

결정하여 운영방향을 나눌 수 있다.

DB 도 사용자용과 봇용으로 나눠서 응답을 중요시할지, 리소스를 소진하는 것을 중요시할지 나누어서 운영할 수 있다.

튜닝 및 확장성 확보

튜닝

• 부하파악, 상태 감시 : 서버관리툴
• 부하를 가시화해서 병목이나 이상현상을 파악할 수 있도록 한다.
  • 여러 서버의 그래프를 겹쳐봄으로써 병목이나 이상현상 파악가능
• OS의 동작원리를 알고 서버 성능을 올바르게 끌어내기 

확장성 확보

• 로드밸랜서이용
• 파티셔닝(DB분할)