일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- AI Mathematics
- 문자열
- 프로그래머스
- 코테
- 알고리즘
- softeer
- Clean Code
- programmers
- Coursera
- IBM
- 데이터과학
- 티스토리챌린지
- string
- 코세라
- 소프티어
- Data Science
- Java
- 자바
- 파이썬
- 코딩테스트
- 깨끗한 코드
- 오블완
- data science methodology
- 클린코드
- 클린코드 파이썬
- 부스트캠프
- Boostcamp AI
- 데이터사이언스
- 데이터 사이언스
- Python
- Today
- Total
떼닝로그
[5장] 인프라를 지탱하는 응용 이론 본문
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 정리
- 오류 검출이란 데이터의 파손 여부를 확인하는 기법으로, 파손된 경우에는 데이터를 다시 읽어 재처리할 수 있음
'개발로그 > 그림으로 공부하는 IT 인프라 구조' 카테고리의 다른 글
[4장] 인프라를 지탱하는 기본 이론 (0) | 2022.11.08 |
---|---|
[3장] 3계층형 시스템을 살펴보자 (0) | 2022.11.08 |
[2장] 서버를 열어 보자 (1) | 2022.10.14 |
[1장] 인프라 아키텍처를 살펴보자 (0) | 2022.10.13 |