인프라를 지탱하는 응용 이론 (캐시, 인터럽트, 폴링, I/O 크기, 저널링, 복제, 마스터-워커, 압축, 오류 검출 이란?)

캐시(Cache)

• 캐시란?
• 사용 예
• 캐시 요약

 

인터럽트(Interrupt)

• 인터럽트란?
• 사용 예
• 인터럽트 요약

 

폴링(Polling)

• 폴링이란?
• 사용 예
• 폴링 요약

 

I/O 크기

• I/O 크기란?
• 사용 예
• I/O 요약

 

저널링(Journaling)

• 저널링이란?
• 사용 예
• 저널링 요약

 

복제

• 복제란?
• 사용 예
• 복제 요약

 

마스터-워커

• 마스터-워커란?
• 사용 예
• 마스터-워커 요약

 

압축

• 압축이란?
• 사용 예
• 압축 요약

 

오류 검출

• 오류 검출이란?
• 사용 예
• 오류 검출 요약

 

---

캐시(Cache)

사용 빈도가 높은 데이터를 고속으로 액세스할 수 있는 임시 저장소

캐시는 빠른 성능을 제공하는 대신 비용이 비싸고 비싼만큼 사용할 수 있는 저장 공간이 작다.

 

 

캐시를 사용해야 되는 이유

처리 시간에 비해 데이터 접근 시간이 오래 걸릴 때

반복적으로 동일한 결과를 반환하는 경우

 

Long Tail 법칙

20%의 요구가 시스템 리소스의 대부분을 사용한다는 법칙

20% 기능을 Cache를 이용함으로써 리소스 사용량은 대폭 줄이고, 성능은 대폭 향상시킬 수 있다

 

 

캐시의 특징

일부 데이터를 데이터 출력 위치와 가까운 지점에서 일시적으로 저장

데이터 재사용을 전제

 

 

캐시의 분류

Local Cache

• 서버마다 캐시를 따로 저장
• 다른 서버의 캐시를 참조하기 어려움
• 서버 내에서 작동하기 때문에 속도가 빠름
• 로컬 서버 장비의 리소스를 이용
• 캐시 데이터가 변경되면 해당 서버를 제외한 모든 peer에 변경사항을 전달
• All-to-All Replication 방식이라 WAS 인스턴스가 늘어나고, 캐시 저장 데이터 크기가 커지면 성능 저하됌

 

Global Cache

• 여러 서버에서 캐시 서버에 접근하여 참조 가능
• 별도의 캐시 서버를 이용하기 때문에 서버 간 데이터 공유 쉬움
• 네트워크 트래픽을 사용해야 해서 로컬 캐시보다 느림
• 데이터를 분산하여 저장 가능
• Replication: 두 개 이상의 DBMS 시스템을 Master / Slave 로 나눠 동일한 데이터 저장하는 방식
• Sharding: 같은 테이블 스키마를 가진 데이터를 다수의 DBMS에 분산 저장하는 방식
• 캐시 데이터가 변경되면 캐시 서버 변경 외 추가 작업이 없음
• 서비스 확장으로 WAS 인스턴스가 늘어나고, Cache 데이터 크기가 커질수록 효과적

 

 

사용 예

브라우저 캐시

• 웹 브라우저가 접속한 페이지를 캐시하는 것
• 이를 통해 웹 서버 접속을 줄이고 브라우저 표시를 고속화할 수 있음
• 웹 서버 자체 부하를 줄이기 위해 웹 서버와 클라이언트 사이에 캐시 서버를 배치하기도 함

cf) 웹 캐시의 종류

Browser Caches	브라우저 또는 HTTP요청을 하는 Client Application 에 의해 내부 디스크에 캐시 Cache된 리소스를 공유하지 않는 한 개인에 한정된 Cache 브라우저의 Back버튼 또는 이미 방문한 페이지를 재방문하는 경우 극대화
Proxy Caches	Brower Cache와 동일한 원리로 동작하며 Client나 Server가 아닌 네트워크 상에서 동작
Gateway Caches	서버 앞 단에 설치되어 요청에 대한 캐시 및 효율적인 분배를 통해 가용성, 신뢰성, 성능 등을 향상

 

 

최근 캐시 서버를 서버 앞에 두는 대신에 CDN(Content Delivery Network)이라는 웹 서버가 아닌 다른 네트워크에 웹 콘텐츠 캐시를 배치하는 구조를 이용하기도 함  ex) aws Cloudfront

 

캐시 요약

캐시의 장점

• 데이터에 고속 엑세스
• 실제 데이터에 대한 엑세스 부하를 줄임

 

캐시를 사용하기에 적합한 시스템

• 참조 빈도가 높은 데이터
• 캐시의 데이터가 손실돼도 문제가 없는 시스템   ex) 읽기 전용

 

캐시를 사용하기에 부적합한 시스템

• 데이터 갱신 빈도가 높은 시스템
• 대량의 데이터에 액세스하는 시스템

 

---

인터럽트(Interrupt)

어떤 원인으로 인해 지금 하고 있는 일을 중단하고 급히 다른 일을 하는 것

CPU에 입출력 장치나 예외 상황이 발생하여 처리가 필요할 경우 CPU에 알려 그 상황을 처리할 수 있도록 하는 것

 

인터럽트를 사용해야되는 이유

대부분의 I/O 디바이스는 처리기(CPU)보다 느리다

처리기는 디바이스의 작업 완료를 위해 기다려야 한다면 처리기 성능 저하가 발생한다.

이를 해결하기 위해서 디바이스가 작업이 완료되면 처리기에게 인터럽트를 걸 수 있도록 허용 -> 처리기는 이 기간동안 다른 일을 할 수 있음

 

cf) 인터럽트 부류

프로그램	산술연산 오버플로, 0으로 나누기, 불법적인 기계 명령어 수행 시도 등의 조건에 의해 생성
타이머	처리기 내의 타이머에 의해 생성. 정규적으로 수행해야 할 때 사용
입출력	입출력 제어기에 의해 생성
하드웨어 실패	전원 결함 또는 메모리 패리티 에러와 같은 결함에 의해 생성

 

사용 예

NIC를 통해 네트워크 통신으로 데이터가 도착하면 인터럽트 처리하여 CPU를 사용하고 있던 프로세스 정보가 메모리에 저장된 후 일시적으로 CPU 자원을 사용하여 데이터를 수신

 

 

인터럽트 요약

어떤 일이 발생하면 연락하는 '이벤트 주도' 구조 (폴링과 차이점)

CPU가 정기적으로 폴링(Polling) 해서 입출력 장치 상태를 확인하는 방법도 있지만 비효율적이라 사용하지 않음

 

---

폴링(folling)

정기적으로 질의하여 상대가 어떤 상태인지 어떤 요구를 가지고 있는지 할 수 있는 방법

 

폴링의 특징

• 질의 방향이 단방향
• 질의는 일정 간격을 따라 정기적으로 발생
• 반복(루프)만 하면 되기에 프로그래밍이 쉬움
• 상대가 응답하는지 확인할 수 있음
• 모아서 일괄적으로 처리할 수 있음

 

 

사용 예

JDBC MBean 객체가 접속 풀의 "테스트 빈도"에서 설정한 값(초기값 120초)을 따라 미사용 접근을 사용해서 SQL 실행 접속 감시는 정기적인 폴링을 이용해서 구현한다. (?)

 

NTP 시간 동기도 정기적으로 실시하여 자신의 시간이 맞는지 확인하는 풀링 구현 중 하나

 

 

폴링 요약

정기적으로 질의하여 상태확인하는 방법

간격을 짧게 하면 리소스 사용량 증가하기에 적절한 간격 필요

 

폴링을 사용하기 적합한 처리

일정 간격으로 처리를 실행하면 좋은 처리

감시

 

폴링을 사용하기 부적합한 처리

상태가 아닌 입력 내용에 따라 실행 내용을 변경하는 처리 -> 인터럽트 사용

처리 우선순위를 정해야 하는 처리

 

---

I/O 크기

데이터를 주고 받을 때 사용되는 I/O의 크기를 의미

I/O 크기는 인프라 설계나 성능 튜닝에 있어 중요한 개념

 

예를 들어 설명을 하면

• 물건을 운반할 때는 상자에 넣으면 효율적으로 관리할 수 있다
• 운반하는 양에 따라 상자 크기를 선택하면 효율적으로 운반할 수 있다

 

사용 예

블록 크기 8KB 의 DB 파일을 ext3 파일 시스템에 저장한다고 가정.

ext3 파일 시스템의 블록 크기가 7KB라고 하면 OS 계층에서는 두 개 블록으로 분할.

8KB에 해당하는 데이터 1블록만 읽고 싶어도 7*2=14KB 를 읽어야 하기 때문에 비효율적

따라서, 데이터 파일의 블록 크기가 8KB 이면 파일 시스템의 블록 크기도 8KB로 하는 것이 효율적.

 

 

네트워크에서는 MTU를 예로 들 수 있음.

TCP/IP 프로토콜은 데이터 한 개를 작은 데이터 여러 개 묶음으로 잘라서 이 묶음으로 통신 상대와 주고 받음.

작은 데이터 묶음을 패킷이라고 하는데 패킷의 최대 크기를 MTU(Maximum transmission unit) 이라고 함. (최대 MTU 크기는 1,500)
MTU 값이 클수록 실어 나르는 데이터 크기가 커짐.

 

cf)

MTU 값이 크다면 라우터를 지나갈 때 마다 작은 조각으로 나뉘면서(단편화) 상대방에게 도달하는 시간이 더 걸린다

MTU 값이 작다면 실제 보내는 데이터 양보다 송수신 정보가 더 커질 수 있기에(오버헤드) 비효율적이다.

 

 

MTU 요약

큰 상자는 대량의 데이터를 빠르게 운반할 수 있으며(처리량 중시),

작은 상자는 소량의 데이터를 빠르게 운반할 수 있다.(지연시간 중시)

---

저널링(Journaling)

저널은 트랜잭션이나 매일 갱신되는 데이터 변경 이력을 가르킨다. 저널을 남겨두는 것을 저널링이라고 한다. (발자취를 기록해 두는 것)

cf) 트랜잭션: 쪼개질 수 없는 원자 업무처리의 단위

 

일종의 로깅 기법을 이용한 데이터 백업 체계

 

저널 특징

데이터 자체가 아닌 처리(트랜잭션) 내용을 기록

데이터 일관성이나 일치성이 확보되면 필요 없어짐

데이터 복구 시 롤백(Rollback), 롤포워드(Rollforward)에 이용

 

롤백	저널을 읽어서 실제 데이터 정보를 과거로 되돌리는 처리
롤포워드	저널을 읽어서 실제 데이터 정보를 앞으로 진행시키는 처리

 

사용 예

ext3 파일 시스템

기본 설정에서는 5초에 한번 기록되지만 데이터 파손이 허용되지 않는 경우에는 이 간격을 짧게 설정하는 것이 좋음.

 

저널링 요약

저널링 장점

시스템 장애 시 복구가 빠르다

데이터 복제보다도 적은 리소르를 소비해서 데이터를 보호할 수 있다

 

저널링이 적합한 시스템

데이터 갱신이 발생하는 시스템

• 트랜잭션 내용을 기록해 둠으로 써 데이터 안정성을 높일 수 있음

 

저널링이 부적합한 시스템

데이터 안정성보다 성능을 요구하는 시스템

• 저널링을 하면 기록 처리 시 오버헤드가 발생하기 때문

 

저널링 주의점

저널 데이터는 메모리의 버퍼에 저장되기에 디스크에 기록하지 않는다면 장애 시 잃을 수 있음

또한, 디스크 기록 빈도가 많다면 오버헤드가 증가하기에 시스템에 맞게 설정해야 함

 

저널은 트랜잭션 단위로 일치성을 보증하기 때문에 트랜잭션 도중에 장애 발생 시 종료되지 않은 트랜잭션은 파괴

트랜잭션이 길어지지 않도록 설계해야함

---

복제

복사본을 만드는 것. DB나 저장소 등에서 자주 사용되는 기술

 

복제의 특징

장애 시 데이터 손실을 예방할 수 있음

복제를 이용한 부하분산이 가능

사용자가 데이터를 액세스할 때 복제한 것이라는 것을 의식할 필요가 없다

복제 데이터를 캐시처럼 사용할 수 있다

 

사용 예

저장소 복제

MySQL 복제

 

 

복제 요약

복제가 적합한 시스템

• 데이터 손실을 허용하지 않고 장애 시 복구 속도가 빨라야 하는 시스템
• 데이터 참조와 갱신 부분이 나뉘어져 있으며, 참조가 많은 시스템 (부하 분산 가능)

 

 

복제가 부적합한 시스템

데이터 갱신이 많은 시스템

• 복제 대상 데이터가 많아지기에 오버헤드 증가

 

복제의 주의점

• 복제 위치가 많으면 갱신이 많은 시스템과 같이 복제 오버헤드 증가
• 실제 데이터와 복제 데이터를 완전히 일치시키고 싶으면 복제 데이터의 쓰기 완료 처리를 보장. (시스템 응답 악화 초래 가능)
• 시스템 유지관리나 장애 시에는 복제 데이터도 고려해야 하므로 설계나 운용 난이도 상ㅈ승
• 복제 데이터와 실제 데이터의 차이가 커지면 그 차이를 채우기 위한 시간이나 성능 고려

---

마스터-워커

상호 접속 관계의 일종으로 한 사람이 관리자가 되어 모든 것을 제어

반대는 Peer to Peer

 

사용 예

 

마스터-워커와 피어 투 피어의 장점만 조합해서 이용하는 경우도 있다

구체적인 예) 오라클 RAC

여러 대의 물리 서버가 클러스터 구성으로 연결, 리소스 단위로 관리 마스터가 달라짐.

특정 서버가 마스터가 되는 것이 아니라, 모두가 대등한 관계라서 특정 서버가 다운돼도 전체 가용성에는 영향 주지 않음

만약 물리 서버가 다운된다면 해당 서버가 마스터로 관리하고 있던 리소스는 다른 마스터 서버가 관리.

 

 

마스터-워커 요약

마스터-워커 장점

관리자가 한 명이기 때문에 구현이 쉽다

워커 간 처리를 동기화할 필요가 없기에 통신량이 줄어듬

 

마스터-워커 단점

마스터가 없어지면 관리를 할 수 없음(작업 인계 구조 필요)

마스터의 부하가 증가

 

 

---

압축

디지털 데이터 압축의 기본은 중복 패턴 인식과 그것을 변경하는 것

압축의 장점은 크기를 줄이는 것, 단점은 처리 시간이 걸린다는 것

압축한 데이터를 원래대로 복원할 수 있는 가역 압축과 이미지나 음성 데이터 등에 있는 사람이 인식할 수 없는 부분을 생략하는 비가역 압축이 있음.

 

사용 예

zip 파일

자바 클래스 파일 jar은 zip으로 압축되어 있는데, 항상 읽는 파일이 아니므로 애플리케이션 속도에 영향이 미미

docx, pptx 도 zip으로 압축되어 있음

 

 

cf) 문자열 압축방식 RLE(Run Length Encdoing) (aka. LZW 알고리즘)

abccddd -> abc2d3

nowletsgogogoletsgogogo -> now2(lets3(go))

nowletsgogogoletsgogogoandrunrunrun -> now2(lets3(go))and3(run)

 

 

cf) 허프만 부호화 

AAAAAAABBCCCDEEEEFFFFFFG 

A(7개)  F(6개)  E(4개)  C(3개)  B(2개)  D(1개)  G(1개)

 

압축 요약

압축은 불필요한 공간을 제거해서 데이터 크기를 줄이는 기술을 가르킴

크기를 작게 해서 데이터 처리나 교환 시 오버헤드를 줄일 수 있다는 장점이 있지만, 압축/해제 처리로 인한 리소스 사용이 있을 수 있음

 

 

---

오류 검출

데이터의 파손 여부를 확인하는 기법

 

오류가 일어나는 조건

• 통신 중에 데이터 파손
• 칩에서의 데이터 파손

 

 

사용 예

서버용 메모리에는 ECC메모리 라는 것이 있음. (반대는 REG 메모리)

이 메모리는 쓰리 처리 시 에 패리티 비트 계산해서 패리티 정보도 함께 기록

그리고 읽을 때는 다시 패리티 계산을 해서 오류가 없는지 검사

오류가 있으면 수정 가능한 경우에는 수정을, 불가능한 경우에는 오류만 검출해서 반환

 

 

패리티 피트

전송 과정에서 오류가 생겼는지 검사하는 용도.

1비트의 오류만 찾을 수 있음.

만약 2비트(짝수)가 오류가 난다면 정상으로 판별되기 때문에 취약점이 존재함

 

병렬 패리티를 이용하면 위치를 찾아 정정 가능

 

체크썸

네트워크를 통해 전달된 값이 변경되었는지 검사하는 값으로 무결성을 제공

수신측에서 전달받은 체크썸값과 실제로 받은 비트를 계산하여 비교.

 

 

CRC (cyclic redundancy check) 순환 중복 검사

패리티비트와 체크섬보다 높은 신뢰도를 확보

 

 

 

오류 검출 요약

오류 검출이란 데이터의 파손 여부를 확인하는 기법

파손된 경우 방법에 따라 데이터를 복구하거나 다시 읽어 재처리 가능