떼닝로그

[5장] 인프라를 지탱하는 응용 이론 본문

개발로그/그림으로 공부하는 IT 인프라 구조

[5장] 인프라를 지탱하는 응용 이론

떼닝 2022. 11. 14. 01:46

5.1 캐시

5.1.1 캐시란?

- 캐시(cache)는 일부 데이터를 데이터 출력 위치와 가까운 지점에 일시적으로 저장

- 데이터 저장을 전제로

5.1.2 어디에 사용되나?

- 아래 그림의 브라우저 캐시는 웹 브라우저가 접속한 페이지를 캐시하는 것. 이를 통해 웹 서버 접속을 줄이고 브라우저 표시 고속화 가능

- 웹 서버 자체의 부하를 줄이기 위해 웹 서버와 클라이언트 사이에 캐시 서버를 배치하는 방법을 나타내고 있는 것이 아래 그림

5.1.3 정리

- 캐시의 장점은 데이터에 고속으로 액세스할 수 있고, 실제 데이터에 대한 액세스 부하를 줄일 수 있다는 것

- 캐시는 참조 빈도가 높은 데이터캐시의 데이터가 손실되어도 문제가 없는 시스템에 적합

- 데이터 갱신 빈도가 높은 시스템, 대량의 데이터에 액세스하는 시스템에는 부적합

- 캐시 사용 시 주의해야 할 점

  - 데이터가 실제 데이터와 캐시라는 이중 구조로 저장되기 때문에 리소스 소비가 늘어난다. 설계 시에는 어떤 데이터를 캐시하는 것이 효과적인지를 검토해야

  - 시스템 가동 직후 등에는 캐시에 데이터가 없기 때문에 원하는 성능이 나오지 않을 수 있음.

  - 캐시 계층이 늘어나기 때문에 시스템 성능 문제나 데이터 불일치 문제가 발생한 경우는 문제 발생을 야기한 용의자가 늘어남

  - 캐시의 데이터가 손실되는 경우를 대비해서 복구 순서를 설계 시에 확립해야 한다

  - 갱신 데이터(쓰기 데이터)를 캐시할 때 캐시가 여러 개 있으면 갱신된 최신 데이터를 서로 뺏으려는 상태가 발생하지 않도록 주의해야 함

5.2 끼어들기

5.2.1 끼어들기란?

- 어떤 원인으로 인해 지금 하고 있는 일을 중단하고 급히 다른 일을 하는 것을 '끼어들기'. 급한 일을 먼저 하도록 CPU에 알리는 역할

5.2.2 자세히 보자

- CPU에서 애플리케이션 프로세스나 스레드 처리를 하고 있더라도 키보드로 정보가 입력되면 끼어들기가 발생해서 CPU가 짧은 순간 다른 처리를 한 후 다시 원래 처리를 진행

- 키보드 입력 등의 특정 이벤트가 발생했을 때 CPU에 이것을 알려 해당 이벤트에 대응하는 처리를 끝낸 후 원래 하던 처리를 계속하는 것

5.2.3 어디에 사용되나?

- 네트워크 통신으로 데이터가 도착하면 끼어들기로 처리된다.

- 프로세스나 스레드가 허가되지 않은 메모리 위치에 액세스하려고 하면 조각화(Segmentation) 위반이라고 불리는 예외가 발생하여 OS에 의해 프로세스가 강제 종료되는데, 이것도 끼어들기의 일종으로 '예외'나 '소프트웨어 끼어들기' 등으로 불림

5.2.4 정리

- 끼어들기어떤 일이 발생하면 연락하는 '이벤트 주도' 구조

- 폴링 간격이 길면 디스크 I/O가 완료되었더라도 금방 알아차리지 못하고, 간격이 짧으면 폴링을 자주 하기 때문에 CPU 많이 사용하게 됨

- 폴링 대신 끼어들기를 이용하여 제어하는 것이 더 효율적.

5.3 폴링

5.3.1 폴링이란?

- 폴링(Polling)정기적으로 질의하는 것. 정기적으로 질의함으로써 상대가 어떤 상태인지, 어떤 요구를 가지고 있는지 등을 알 수 있음

- 폴링의 질의 방향은 단방향이고, 질의는 일정 간격을 따라 정기적으로 발생

- 폴링은 반복(루프)만 하면 되기에 프로그래밍이 쉽고, 상대가 응답하는지 확인할 수 있고, 모아서 일괄적으로 처리할 수 있다는 장점 가짐

- 폴링과 반대되는 것이 요구가 있을 때만 처리하는 구조인 이벤트 주도 또는 끼어들기 방식

5.3.2 어디에 사용되나?

- 웹로직(WebLogic) 서버의 내부 감시 기능, 정기적으로 실시하여 자신의 시간이 맞는지 확인하는 구조인 NTP(시간 동기)처리에서 사용

5.3.3 정리

- 폴링은 일정 간격으로 처리를 실행하면 좋은 처리감시 처리에 적합

- 상태가 아닌 입력 내용에 따라 실행 내용을 변경하는 처리, 처리 우선순위를 정해야 하는 처리에서는 폴링이 부적합

  - 네트워크를 경유한 폴링일 때는 처리 지연 시간을 줄이기 위해 폴링 간격을 너무 짧게 잡으면 트래픽 양이 증가하므로 주의가 필요하고, 서버의 리소스 소비도 늘어나게 된다

5.4 I/O의 크기

5.4.1 I/O 크기란?

- I/O 크기1회의 I/O에 필요한 사이즈, 즉 데이터를 주고 받을 때 사용되는 I/O의 크기. 인프라 설계나 성능 튜닝에서 중요한 개념

- 물건을 운반할 때 상자에 넣으면, 운반하는 양에 따라 상자 크기를 선택하면 효율적으로 운반/관리할 수 있다는 것이 I/O 크기의 특징

5.4.2 어디에 사용되나?

오라클 DB 예

- 오라클 DB가 데이터 파일을 읽기/쓰기하는 최소 단위를 데이터 블록, 그 크기를 블록 크기

- 블록 크기가 8KB라고 가정하면, 1바이트의 데이터를 읽는 경우에도 8KB를 읽음. 블록 크기가 32KB이면 1바이트 데이터를 읽어도 32KB를 읽어야 함

- I/O 크기가 작을 때는 블록 크기를 작게, I/O 크기가 크면 블록 크기를 크게 해야 I/O 효율이 좋아짐. 양쪽 모두일 경우 중간 크기 취해야

- DB 블록 크기를 파일 시스템 블록 크기의 배수로 설정하면 꽉 채워서 사용할 수 있음

- DB 블록 크기보다 파일 시스템 블록 크기가 크면 DB에서 1블록만 읽고 싶어도 더 큰 용량만큼 읽어야 하기 때문에 비효율적

네트워크 예

- 웹 브라우저가 데이터를 전송할 때는 OS의 소켓이라는 구조를 사용하게 된다

- 웹 브라우저가 송신하는 경우 소켓의 송신 버퍼를 사용하는데, 이 버퍼가 차면 OS에 의해 TCP 세그먼트라는 상자로 분할되고, TCP 헤더, IP 헤더, MAC 헤더라는 편지 수신자 같은 정보를 붙여서 이더넷 프레임이라는 상자에 넣어 전송한다

- 송신 버퍼가 TCP 세그먼트로 분할될 때 MSS(Maximum Segment Size)를 초과하지 않는 범위에서 분할된다

- IP 소켓의 최대 크기를 MTU(Maximum Transfer Unit)이라고 한다.

- 입출력 시에 MTU 크기가 같다면 그대로 송신되지만, 경로 도중에 있는 라우터의 MTU 크기가 작게 설정되어 있으면 웹 서버가 송신하는 패킷이 경로 도중에 더 작게 분할되어 오버헤드가 발생하고, 이는 성능 저하로 연결될 수 있음

- 대량의 데이터를 송신하기 위해 처리량을 올리고 싶은 경우소켓 버퍼 크기를 크게 하거나 MTU를 크게 해서 튜닝을 하기도 함

5.4.3 정리

- 큰 상자는 대량의 데이터를 빠르게 운반할 수 있으며(처리량 중시), 작은 상자는 소량의 데이터를 빠르게 운반할 수 있음(지연 시간 중시)

5.5 저널링

5.5.1 저널링이란?

- 저널(Journal)트랜잭션이나 매일 갱신되는 데이터의 변경 이력. 저널을 남겨 두는 것을 저널링(Journaling)

- 언제, 어디서, 무엇을 했는지 상세하게 기록함으로써 시스템 장애가 발생했을 때 어디까지 정상 처리됐는지, 그리고 어디부터 재실행하면 좋을지 알 수 있게 하는 기능

- 데이터 자체가 아닌 처리(트랜잭션) 내용을 기록하며, 데이터 일관성이나 일치성이 확보될 경우 필요가 없어지며, 데이터 복구 시 롤백(Rollback), 롤포워드(Rollforward)에 이용

5.5.2 어디에 사용되나?

- 데이터를 처리하는 기능의 대부분은 저널링이 구현되어 있음

리눅스의 ext3 파일 시스템

오라클DB

5.5.3 정리

- 저널링을 이용하게 될 경우 시스템 장애 시 복구가 빠르고, 데이터 복제보다도 적은 리소스를 소비하여 데이터를 보호할 수 있다.

- 데이터 갱신이 발생하는 시스템에 적합, 데이터 안정성보다 성능을 요구하는 시스템에 부적합.

- 저널링의 주의점

  - 저널 데이터는 메모리의 버퍼에 일단 저장된다. 이 정보가 디스크에 기록되지 않으면 장애 시에 잃을 수 있다. 이 때문에 시스템 요건에 따라 버퍼의 디스크 기록 시점을 검토, 조정해야 한다. 하지만 기록 빈도가 많으면 오버헤드도 높아지기 때문에 절충해서 검토해야

  - 저널은 트랜잭션 단위로 일치성을 보증하기 때문에 트랜잭션 도중에 장애가 발생하면 종료되지 않은 트랜잭션은 파괴된다. 하나의 트랜잭션 단위가 크면 트랜잭션 도중에 장애가 발생할 가능성이 높기 때문에 트랜잭션이 길어지지 않도록 설계해야

5.6 복제

5.6.1 복제란?

- 복제(Replication)는 DB나 저장소 등에서 자주 사용하는 기술. 복사본을 만드는 것으로, 원래 데이터가 없어져도 다른 것으로 대체 가능

- 복제를 이용함으로써 장애 시 데이터 손실을 예방할 수 있고, 부하분산이 가능

- 사용자가 데이터에 액세스할 때 복제한 것이라는 의식할 필요가 없고, 복제 데이터를 캐시처럼 사용할 수 있다는 것이 장점

5.6.2 어디에 사용되나?

- 블록 단위로 증감 데이터만 복제 위치에 반영해서 데이터 전송량을 줄인다.

- 복제 전송량은 실제 갱신 데이터 양에 비례

- 데이터 보호를 최우선으로 할 때는 쓰기 처리 시 데이터가 복제되기까지 기다리는 모드가 있는데, 기다리는 것이 동기, 기다리지 않는 것이 비동기

- 복제를 통해 데이터의 최종 복사본이 다른 곳에 생성되며, 이 복사본을 캐시처럼 사용할 수도 있음

- 두 곳에 동일한 데이터가 존재하므로 클라이언트는 가까운 곳에 있는 복사본을 읽을 수도 있으며, 한쪽 서버의 부하가 높다면 다른 쪽에 있는 부하가 낮은 서버에서 복사본을 읽을 수도 있음

5.6.3 정리

- 데이터 손실을 허용하지 않고 장애 시 복구 속도가 빨라야 하는 시스템, 데이터 참조와 갱신 부분이 나뉘어져 있으며 참조가 많은 시스템에서는 복제가 적합

- 데이터 갱신이 많은 시스템에서는 복제가 부적합

- 복제할 때의 주의 사항

  - 복제 위치가 많으면 갱신이 많은 시스템과 같이 복제 오버헤드가 높아지게 됨

  - 실제 데이터와 복제 데이터를 완전히 일치시키고 싶으면 복제 데이터의 쓰기 완료 처리를 보장해야 한다. 이 경우 시스템 응답이 악화

  - 시스템 유지관리나 장애 시에는 복제 데이터도 고려해야 하므로 설계나 운용 난이도가 높아질 수 있음

  - 복제 데이터와 실제 데이터의 차이가 커지면차이를 채우기 위한 시간이나 성능도 고려해야

5.7 마스터-워커

5.7.1 마스터-워커란?

- 마스터-워커(Master-Worker)는 주종 관계를 가리킴. 명령하는 쪽과 명령을 받는 쪽한 명이 관리자가 되어 다른 모든 것을 제어

- 마스터-워커의 반대는 상호 관리 의미에서의 피어 투 피어(Peer-to-Peer, P2P) 관계

- 유한한 리소스를 관리할 때는 어떤 한 사람이 관리하는 것이 효율적

- 같은 리소스를 여러 사람이 분담해서 관리할 때는 '누가', '어디까지' 감시하고 있는가에 대한 정보를 알 필요가 있음. 하지만 관리 정보를 매번 상호 통신으로 교환하면 부하가 높아지므로 비효율적

- 관리 대상 리소스를 공유하고 있지 않을 경우에는 마스터가 필요 없고 피어 투 피어 관리가 효율적

5.7.2 어디에 사용되나?

오라클 Real Application Clusters(RAC)

- RAC에서는 여러 대의 물리 서버가 클러스터 구성으로 연결되어 있음. 모두가 대등한 관계이기 때문에 특정 서버가 다운되더라도 데이터베이스 전체 가용성에는 영향을 주지 않음

- 위 그림에서와 같이 데이터베이스의 데이터는 리소스 단위로 관리 마스터가 달라지게 됨.

- 분담해서 관리하고 있기 때문에 서버가 다운되더라도 다른 서버로의 작업 인계가 단시간 내에 가능해지게 됨

5.7.3 정리

- 마스터-워커는 관리자가 한 명이기 때문에 구현이 쉽고, 워커 간 처리를 동기화할 필요가 없기 때문에 통신량이 줄어든다는 장점이 있음

- 마스터가 없어지면 관리를 할 수 없고(작업 인계 구조가 필요), 마스터의 부하가 높아진다는 것이 단점

5.8 압축

5.8.1 압축이란?

- 디지털 데이터에서의 쓸데없는 공간을 줄이기 위해 압축 사용

5.8.2 자세히 보자

- 디지털 데이터에서 교환하는 '정보'의 낭비를 막으면 압축을 할 수 있음 (?? 뭔소리람)

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

- 같은 패턴이 많을수록 압축률이 높아짐.

- 압축을 하는 것의 장점은 데이터 크기를 줄이는 것이고, 단점은 처리 시간이 걸린다는 것. 데이터 크기와 시간이 상충되기 때문에 자주 변경되지 않는 데이터에 효과적.

- 네트워크 경유의 데이터 전송 등 I/O 속도가 느린 환경에서는 미리 압축해서 전송하면 전체적인 처리 시간을 줄일 수 있음

가역 압축과 비가역 압축

- 압축한 데이터를 실제 사용할 때는 원래 상태로 되돌려야 함

- 가역 압축은 대부분의 압축 기술에서 사용하는 것. 원래 상태로 복구 가능. '이미 알고 있는 정보'를 제거

- 원래 상태로 복구할 수 없는 대신 압축률이 높은 방식인 비가역 압축은 '자신에게 필요 없는 정보'를 제거, 즉 최소 필요 정보만 남겨둠

5.8.3 어디에 사용되나?

5.8.4 정리

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

- 크기를 작게 해서 데이터 처리나 교환 시 오버헤드를 줄일 수 있다는 장점이 있으나, 압축/해제 처리로 인해 리소스 부하가 높아지거나 처리 시간이 증가

5.9 오류 검출

5.9.1 오류 검출이란?

- 의도하지 않은 때에 데이터가 망가지는 것을 방지하기 위해 오류 검출이라고 불리는 구조 사용

5.9.2 자세히 보자

1. 통신 중에 데이터 파손

  - 대부분의 통신 방식에서는 전기 신호를 이용해서 데이터를 교환하고 있는데, 경로 도중 낙뢰 등으로 전기적인 잡음 등이 발생하면 데이터 파손될 수 있음

2. 칩(chip)에서의 데이터 파손

  - 메모리의 데이터도 전기적으로 저장되기 때문에 통신 중인 데이터 파손처럼 전기적인 영향으로 값이 바뀌는 경우가 있음

5.9.3 오류를 검출하려면

오류 검출

- 패리티 비트(Parity Bit)라는 이중화 비트를 부여하는 패리티 체크 방식을 이용.

- 오류 검출의 장점은 오류를 알 수 있다는 것...!

- 수정까지 하지 않더라도 오류를 검출할 수 있음. 하지만 추가 데이터를 부여해야 하므로 데이터 양이 증가하며, 오류 여부를 알기 위한 계산이 필요해서 처리에 오버헤드가 발생할 수 있음

5.9.4 어디에 사용되나?

5.9.5 정리

- 오류 검출이란 데이터의 파손 여부를 확인하는 기법으로, 파손된 경우에는 데이터를 다시 읽어 재처리할 수 있음

Comments