그림으로 공부하는 IT 인프라 구조 정리

 

 

 

 

이번 인프라 미션을 진행하면서 멘토님의 책 추천 목록에 있는 그림으로 공부하는 IT 인프라 구조라는 책을 함께 읽으며 병행하게 되었다!

네트워크에 대한 지식이 부족하여 어려웠는데 

이번 미션 내용의 내용을 일부 책에서 설명해주는 부분도 있어서 함께 공부한게 좋은 선택인 것 같다😃 🙌! 

 

http://www.yes24.com/Product/Goods/95800974

그림으로 공부하는 IT 인프라 구조 - YES24

 

 

 

 

웹 데이터의 흐름 

출처 NEXTSTEP 프로젝트 공방

웹 서버 : 복수의 프로세스가 분담해서 병렬 처리

AP 서버 : 복수의 쓰레드가 병렬로 처리 

DB : 프로세스를 늘려서 병렬 처리 가능 

• 클라이언트 PC -> 웹 서버 
  • 웹 브라우저의 요청 
  • 이름 해석
  • 웹 서버 요청 접수 (정적 콘텐츠, 동적 콘텐츠 파악)
  • 필요한 경로로 데이터에 액세스 
• 웹 서버 -> AP 서버 
  • 웹 서버로부터 요청 도착
  • 쓰레드가 요청 처리 가능한지 DB 접속 필요한지 판단
  • DB 접속 필요하면 연결풀에 접근
  • DB 서버에 요청 
• AP 서버 -> DB 서버 -> AP 서버  
  • AP 서버로 부터 요청 
  • 프로세스가 요청 접수하고 캐시 여부 확인
  • 캐시 없으면 디스크에 엑세스 
  • 디스크가 데이터 반환
  • 데이처를 캐시 형태로 저장 
  • 결과를 AP에 반환
• AP 서버 -> 웹 서버 
  • DB로부터 데이터 받음
  • 쓰레드가 데이터로 계산 후 파일 데이터 생성
  • 결과를 웹서버로 반환
• 웹서버 -> 클라이언트 PC 
  • AP 서버로부터 데이터 도착
  • 프로세스는 받은 데이터를 그대로 반환
  • 결과를 웹 브라우저로 반환하여 화면 표시 

 

 

 

 

 

 

동기와 비동기 

• 동기
  • 요청하고 응답할 때까지 아무것도 하지 않고 기다림
  • 요청 업무가 끝났는지 여부를 확실하게 할 수 있음 
• 비동기 
  • 요청하고 응답이 올때까지 병렬로 다른일 처리
  • 요청이 끝났는지 별도의 방법을 이용해 확인 

 

 

 

 

큐 (FIFO : 선입선출)

• CPU 처리를 기다리고 있는 프로세스나 쓰레드 행렬
• 하드 디스크 등의 저장소 읽기 처리를 기다리고 있는 I/O 요구 행렬
• 네트워크 접속 성립을 기다리고 있는 접속 요구 행렬

 

 

 

배타적 제어 

• 공유자원 이용하고 있는 동안 다른 처리가 사용할 수 없도록 제어하여 불일치 방지
• 복수의 처리가 공유 자원(CPU, 메모리, 디스크)에 동시 액세스(주로 갱신)하면 불일치 발생하는데 이를 방지
  • DBMS의 래치(Latch) : CPU가 의미없는 일을 처리하면서 대기하는 방식 = spin lock(단시간의 락에서사용)
  • 슬립락(Sleep lock) : 장시간 락을 유지하도록 큐를 이용해서 관리(이경우 스위치가 발생할 수 있음)
  • 어댑티브락(Adaptive lock) : 상황에 따라서 스핀하다가 락을 확보하지 못하면 슬립

 

 

 

 

상태저장 / 상태 비저장

• 상태저장
  • 복잡한 처리 가능
  • 요청 최소화
  • 시스템 복잡성이 커짐
• 비상태저장
  • 매번 신규 요청 생성
  • 요청과 응답 구조 간단
  • 성능 안정성 측면에서 우수
  • HTTP 는 상태 비저장이지만 세션을 이용해서 상태 저장 구현

 

 

 

 

가변길이 / 고정길이 

• 가변길이
  • 데이터 크기를 절약하고 공간을 유용하게 활용 가능
  • 새로운 데이터를 추가하고 찾는 성능에서 불안정
• 고정길이
  • 쓸데없이 공간이 생김
  • 성능에서는 안정적 (NTFS 파일 시스템)

 

 

 

 

배열 / 연결리스트 + 해시테이블

• 배열
  • 순서를 가짐
  • 탐색 빠름
  • 데이터 추가 및 삭제가 느린 데이터 구조 
• 연결리스트
  • 다음 상자의 위치정보 가짐
  • 데이터 추가 및 삭제가 빠른 데이터 구조 
• 해시테이블
  • 연결리스트와 배열을 조합한 하이브리드형 데이터 구조
  • SQL 정보 관리 메모리, 동일 SQL이 대량으로 실행되는 OLTP 시스템 (소량의 데이터 많이 검색)

 

 

 

 

풀스캔 / 인덱스 스캔 

읽을 데이터가 일정량을 넘기면 인덱스 보다 풀스캔을 사용 

• 풀스캔
  • 시퀀셜 액세스와 Multiblock I/O 방식으로 디스크를 읽어 한블록에 속한 모든 레코드를 한번에 읽어들임
  • 대량조회 
    • 파티션 활용전략
    • 병렬처리 가능,
  •  테이블의 모든 블록을 처음부터 순서대로 읽어나가는 것 
• 인덱스 스캔
  • 랜덤 액세스와 SingleBlock I/O 방식으로 레코드 하나를 읽기위해 매번 I/O 발생
  • 최소한의 필요 블락만 읽으면 됨
    • 소량 검색을 빠르게 하는 OLTP
    • NL조인
  •  인덱스 갱신 때문에 불필요한 오버헤드 발생 가능 
  • 인덱스 스캔 -B트리 인덱스
    • 수직적 탐색 + 수평적 탐색
    • 루트, 브랜치(인덱스키와 자식 노드 정보로 구성된 페이지 단위), 리프 블록으로 이루어짐
    • 찾고자 하는 값보다 크거나 같은 값을 만나면 바로 직선 레코드가 가리키는 하위 노드로 이동
    • Inno DB의 경우 Secondary Index를 통해 알아낸 Primary Key로 한번 더 수직적 탐색 
    • 데이터블럭 + 로우번호 ROWID (블럭내 순번)
    • Inno DB의 경우 Primary Key가 ROWID 역할(Clustered Index(순차)로 Data Record의 물리적 위치를 알 수 있음)
    • 인덱스 튜닝
      • 인덱스 스캔 효율화
      • 랜덤 액세스 최소화
    •  인덱스 스캔 후 테이블 레코드 액세스 시 랜덤 I/O 횟수 줄이기
  • 해시테이블 
    • 등호 검색에 큰 강점을 보임
    • 해시 값은 고정 길이 데이터 이기 때문에 조합 표의 데이터 구조가 간단하여 검색이 빠름 

 

 

 

 

 

캐시 

• 일부 데이터를 데이터 출력 위치와 가까운 지점에 일시적으로 저장
• 데이터에 고속으로 액세스 가능 
• 데이터 재상용
• 실제 데이터에 대한 액세스 부하를 줄일 수 있음 
• 요즘은 캐시 서버를 서버 앞에 두는 대신 CDN(Content Delivery Network)라는 웹서버가 아닌 다른 네트워크에 웹 콘텐츠 캐시 하는 구조를 사용하기도 한다.
• 적합 +
  • 참조 빈도가 높은 데이터
  • 캐시의 데이터가 손실 되어도 문제없는 시스템
• 부적합 - 
  •  데이터 갱신 빈도가 높은 시스템(바로 액세스 하는 경우와 차이없음)
  • 대량의 데이터에 액세스 하는 시스템(캐시의 크기가 커진다)

 

 

 

 

끼어들기 / 폴링 

• 전화는 끼어들기, 정기적 메일 수신은 폴링 
• 끼어들기 
  • 지금 하는 일을 중단하고 급히 다른 일을 하는 것
  • 키보드 입력, 이더넷 프레임이 NIC에 도착할 때
  • (입출력장치 끼어들기 -> 하드웨어 끼어들기)
• 폴링 
  • 정기적으로 질의 하는 것 
  • 반복 루프만 하면 되기에 프로그래밍이 쉽고 상대가 응답하는지 확인 가능
  • 모아서 일괄적 처리 가능 (웹 로직의 서버 내부 감시기능)
  • 적합 + 
    • 일정 간격으로 처리를 실행하면 좋은 처리
    • 감시
  • 부적합 - 
    •  상태가 아닌 입력내용에 따라 실행 내용을 변경하는 처리
    • 처리 우선 순위를 정해야 하는 처리 
  • 네트워크를 경유한 폴링일 때 처리 지연 시간을 줄이기 위해 폴링 간격을 너무 짧게 설정하면 트래픽 양이 증가하고 서버의 리소스 소비도 늘어나므로 주의 

 

 

 

 

I/O 크기 

• 1회의 I/O에 필요한 사이즈 
• ex) 데이터베이스의 블록 크기(8KB)가 파일시스템의 블록 크기(7KB)와 차이가 나면 데이터베이스가 한블록 (8KB)를 읽으면 디스크에서 14KB(7*2KB)를 읽어서 그중 6KB는 사용하지 않는다.
• 데이터 베이스의 블록 크기를 파일 시스템 블록 크기의 배수로 설정하면 꽉 채워서 사용이 가능하다. 
• 입출력 시에 MTU(Maximum Transfer Unit)크기가 같다면
  • 그대로 송신
• 경로 도중에 있는 라우터의 MTU 크기가 작게 설정 시
  • 웹 서버가 송신하는 패킷이 경로 도중에 더 작게 분할 돼서 오버헤드 발생하고 성능저하가 발생 

 

 

 

 

 

저널링 / 섀도우 페이징 

• 저널링 
  • 트랜잭션이나 매일 갱신되는 데이터의 변경 이력 
  • 데이터 자체가 아닌 처리 내용을 기록하고 데이터 일관성이나 일치성의 확보되면 필요 없음
  • 데이터 복구 시 롤백, 롤포워드 에 이용
  • 리눅스의 et3, 오라클 DB의 REDO로그
  • 시스템 장애 시 복구가 빠르고 데이터 복제보다도 적은 리소스를 소비하여 데이터를 보호할 수 있음 
  • 적합 +
    • 데이터 갱신이 발생하는 시스템
  • 부적합 -
    • 데이터 안정성보다 성능을 요구하는 시스템 (저널링 기록처리시 오버헤드 발생하기 때문에)
    • 실제 데이터가 다른 장소에 있는 서버에서는 부적합 
  • 롤백과 롤포워드는 트랜잭션 단위로 실행 
    • 롤백 : 저널을 읽어서 실제 데이터 정보를 과거로 되돌리는 처리 
    • 롤포워드 : 저널을 읽어서 실제 데이터 정보를 앞으로 진행시키는 처리 
  • 저널은 트랜잭션 단위로 일치성을 보증하기 때문에 트랜잭션 도중에 장애가 발생하면 종료되지 않은 트랜잭션은 파괴 
• 섀도우 페이징 
  • 저널링과 같이 기록 도중 실패한 것인지 기록이 끝난 파일인지 판단하여 불일치 방지하도록 
  • 변경정보를 작성하지 않고 파일 갱신은 모두 신규영역에서 진행
  • 완료된 시점에 파일이 참조할 위치를 이전 영역에서 신규 영역으로 교체 
  • 데이터 변경 중에 장애가 발생해도 갱신이 진행된것을 다른 사람이 모른다 (All or Nothing, 원자성)

 

 

 

 

복제 

• 복사본을 만드는 것을 의미
• DB나 저장소 등에서 자주 사용되는 기술 
• 적합 + 
  • 데이터 손실을 허용하지 않고 장애 시 복구 속도가 빨라야 하는 시스템
  • 데이터 참조와 갱신 부분이 나뉘어져 있으며 참조가 많으 시스템
• 부적합 -
  •  데이터 갱신이 많은 시스템 (복제 대상 데이터가 많아 지기 때문에 오버헤드가 높아진다)

 

 

 

 

마스터 - 워커 

• 주종 관계로 한 쪽이 관리자가 되어 모든것을 제어하는 관계 <-> 피어투피어 : 상호 관리 관계 
• 장점 + 
  • 관리자가 한 명이기 때문에 구현이 쉬움
  • 워커간 처리르 동기화 할 필요 없어 통신량이 줄어듬
• 단점 - 
  • 마스터가 없어지면 관리할 수 없어 작업 인계 구조가 필요
  • 마스터의 부하가 높아짐

 

 

 

 

압축 

• 자신에게 필요없는 정보나 이미 알고있는 정보등의 필요없는 정보의 낭비를 막아 쓸데없는 공간을 줄이는 것 
• 중복패턴 인식-> 변경 
• 크기를 줄여 데이터 처리나 교환시 오버헤드를 줄일 수 있지만 압축/해체 처리로 리소스 부하가 높아지거나 처리 시간이 증가
• jar, zip
• 가역압축 
  • 원래 상테로 복구할 수 있는 압축
  • 이미 알고 있는 정보만을 제거 
• 비가역압축 
  • 원래 상태로 복구할 수 없는 압축
  • 압축률 높음
  • 최소 필요 정보만 남겨둔다. 

 

 

 

 

오류 검출 

• 오류를 검출 할 수 있음
• 추가 데이터를 부여해야 하므로 데이터 양이 증가하여 오류 여부를 알기 위한 계산으로 처리에 오버헤드 발생 가능
• 패리트 비트, TCP/IP 및 이더넷의 계층별 체크섬이나 CRC 오류 검출 구조(오류 검출 시 해당 데이터 제외)

 

 

 

 

네트워크 

• 계층구조로 이루어져 있어 자신이 담당하는 일만 책임 진다. 
• 대표적인 모델 OSI 7계층 모델

 

 

 

 

프로토콜 

• 사전에 정해놓은 순서
• 통신시에 이용하는 매체 혹은 언어 (계층간의 약속)
• 네트워크의 대표 프로토콜 IEEE, IETF 표준화 단체, 서버 내부의 프로토콜도 존재 
• TCP / IP 관련 프로토콜 
  • TCP/IP 프로토콜 스위트 :프로토콜 집합
  • TCP/IP 4계층 모델 예시 
    • 애플리 케이션 계층 (Layer 7)
      • 이미지 데이터 보냄
      • 송신은 다른계층에게 위임 (Layer 5+6+7)
    • 전송 계층 (Layer 4)
      • 애플리케이션계층이 의뢰한 데이터를 상대방에게 책임지고 전달
    • IP 계층 (Layer 3)
      • 데이터를 최종 위치까지 운반 
    • 링크 계층 (Layer 2)
      • 직접 연결돼 있는 주변장비에게도 보냄
  • 과정 
    • 커널에 TCP/IP 시스템 콜방식으로 통신 의뢰 (접속 대상 서버의 IP 주소와 TCP 포트 정보)
    • 의뢰받은 커널은 소켓을 생성 (접속 대상 서버와의 연결 생성)
    • 상대방 서버에서도 소켓 생성(TCP 소켓)
    • 상대 서버와의 사이에 가상 경로 (버추얼 서킷)생성
    • 데이터 기록 

• HTTP 
  • 요청
    • 서버에 던지는 명령
    • 헤더부분: 다양한 부가정보 및 세밀한 제어
    • 여러가지 명령만으로 구성된 매우 간단한 구조
    • 하위계층으로 명령보내거나 통신제어하지 않음
  • 응답
    • 요청에 대한 결과와 그에 대한 상태 정보 및 메세지 바디에 실제 데이터 저장 

 

 

 

 

 

 

 

출처 https://www.youtube.com/watch?v=OTwp3xtd4dg&ab_channel=CertBros

TCP / IP 관련 프로토콜① 애플리케이션 프로토콜 (Layer 7)

• 소켓에 기록된 데이터는 애플리케이션 자체가 원격지에 있는 다른 한쪽의 소켓으로 전달하므로 통신구조를 가지지 않고서도 서버 애플리 케이션과 통신
• Keep alive 기능을 통해서 단시간 동안 세션을 남겨두어 TCP의 3way-handshaking 등의 오버헤드를 방지할 수 있다 

 

TCP / IP 관련 프로토콜 ② 전송계층의 TCP 프로토콜 (Layer 4)

• TCP
  • 애플리케이션이 보낸 데이터를 그 형태 그대로 상대방에게 확실히 전달하는 것
  • 신뢰도 높은 데이터 전송 (IP는 상대 서버까지 전송하는 부분만 담당하여 데이터가 상대방에게 확실히 전달 됐는지 확인하는 기능이나 도착한 순서를 확인하는 기능은 없음)
  • 서버가 송신할 때와 서버가 수신한 수 애플리케이션에 전달할때 사용(end-to-end 신뢰성 담보)
  • 연결형 프로토콜
  • 헤더 20바이트 
  • 포트번호 이용해서 데이터 전송
  • 연결 생성
  • 데이터 보증과 재전송 제어
  • 흐름제어와 폭주 제어
  • 연결이라 불리는 가상 경로(버추얼 서킷)생성하는데 이는 애플리케이션측에게 통신한다는 신호 보내고 OK 받으면 처음 생성됨  

출처&nbsp;https://cabulous.medium.com/tcp-3-way-handshake-and-how-it-works-8c5f8d6ea11b

• TCP는 데이터를 세그먼트라고 하는 단위로 관리 (애플리케이션 데이터에 TCP시그먼트 헤더 부착)
• MSS(Maximum Segment Size)
  • 하나의 TCP 세그먼트로 전송할 수 있는 최대 크기
  • 이를 초과한 데이터는 자동으로 분할되어 복수의 TCP 세그먼트 생성 
• 과정 
  • 소켓이 기록된 데이터는 큐를 경유해서 커널 내 네트워크 처리부분에 전달 
  • 커널에 전달된 데이터는 소켓 버퍼 (메모리 영역)에서 처리 
  • 데이터에 TCP 헤더를 붙여서 TCP 세그먼트를 생성 (포트번호 신호 등 다양한 정보 포함)
  • IP 계층으로 이동 

 

출처&nbsp;https://www.gatevidyalay.com/tcp-retransmission-tcp-computer-networks/

• 3-handshaking 연결 생성 과정 
  • 요청 애플리케이션이 커널 내 TCP 계층에서 통신상대서버에게 가상 경로를
  • 열어 줄 것을 의뢰 
  • 통신 받는 측은 열어도 된다고 응답 
  • 요청 측이 마지막으로 확인했다는 응답을 보내면 가상 경로 생성 됨 (송신 측에서도 자동으로 포트번호 설정된 소켓이 열린다)

• 데이터 보증 과정 
  • 확인 응답과 재전송에 의해 구현
  • 순서 보증은 세그먼트에 시퀀스 번호를 붙여서 구현 
  • 수신 측에 TCP 세그먼트 도착 
  • 수신측은 송신 측에게 도착했다는 것 알림  + TCP 헤더에 ACK관련 정보 넣은 TCP 세그먼트 반환(다음에 필요한 TCP 세그먼트의 시퀀스 번호도 ACK번호로 전달)
  • 송신 측은 ACK가 돌아오는 것을 보고 전송한 세그먼트가 도착했다는 것을 확인

출처&nbsp;https://www.gatevidyalay.com/tcp-retransmission-tcp-computer-networks/

• TCP 재전송 제어 과정 
  • 일정시간 내에 ACK가 돌아오지 않으면 재전송 
  • 시퀀스의 TCP 세그먼트가 도중에 유실
  • ACK에서는 사라진 세그먼트를 다시 요청 
  • 시퀀스 세그먼트측에서 3회 중복되어 요청이 들어온 경우(중복 ACK) 재전송 (처음 요청 보낼 때에는 지연되어 도착순서가 바뀔 수 있기 때문에 바로 재전송하지 않음)
  • 추가로 SACK (selective ACK)옵션 사용시 도착하지 않은 TCP 세그먼트만 선택해서 재전송 가능 

출처&nbsp;https://jwprogramming.tistory.com/36

• 흐름제어와 폭주제어 
  • 윈도우 : 어느정도의 세그먼트 수를 ACK를 기다리지 않고 전송하는 개념
  • 윈도우 크기 : ACK를 기다리지 않고 전송 가능한 데이터 크기 
  • 수신측이 폭주 윈도우 크기를 조정해서 송신(폭주)윈도우와 수신 윈도우 중 작은 쪽을 송신 윈도우로 채택
  • 흐름제어 
    • 슬라이딩 윈도우
      • ACK가 오면 해당 TCP 세그먼트는 재전송 할 필요가 없기 때문에 송신용 소켓 버퍼에서 삭제하고 송신 윈도우를 다음으로 이동 
    • 수신용 소켓 버퍼가 넘쳐서 더이상 수신이 불가능하면 수신 윈도우 크기를작게 만들고 이를 소신 측에 알림 
    • 송신 측은 수신 윈도우 크기 이상의 데이터는 ACK 없이 보낼 수 없음 
  • 폭주제어 
    • 송신측(폭주윈도우) 윈도우 크기를 네트워크 폭주상태(혼잡상태)에 맞추어 변경 
    • 네트워크가 혼잡하면 폭주 윈도우의 크기를 작게해서 전송 데이터 양을 줄임 
    • 슬로우 스타트
      • 폭주 윈도우 크기는 통신 시작시 1세그먼트에 설정되고 문제없이 통신이 시작되어 수신측에 도달하면 ACK 반환시마다 폭주 윈도우 크기를 지수 함수 적으로 늘려나감 
    • 어느정도 까지 증가하면 그 이후는 1세그먼트씩 늘려나감 
    • 송신 중인 세그먼트가 실패(폭주를 감지)
    • 폭주 윈도우 크기를 작게해서 송신량 줄임 
    • 반복 

 

 

TCP / IP 관련 프로토콜 ③ 네트워크 계층의 IP 프로토콜 (Layer 3)

• IPv4(헤더 20바이트)의 사용율이 높다 
• 지정한 대상 서버까지 전달 받은 데이터를 전달 (단 IP에서는 반드시 전달 된다고 보장하지 않음 )
• IP 주소를 이용해서 최종 목적지에 데이터 전송 및 라우팅
• 과정  
  • 생성된TCP 세그먼트는 그대로 IP 처리에 돌입 
  • 최종 목적지가 적힌 IP 헤더(최종 목적지 서버의 IP 주소 기록)를 TCP 세그먼트에 추가해서 IP 패킷을 생성 
  • 대상서버까지 IP 패킷 형태로 네트워크를 경유해서 도달 
• 사설 네트워크와 IP 주소
  • IP 주소는 네트워크부와 호스트 부로 나뉨 
  • 어디까지가 네트워크 부인지 표시하기 위해 CIDR / 24 를 표기하여 사용
  • 네트워크 주소 : IP 주소중 호스트부의 비트가 모두 0인 것 
  • 브로드 캐스트 주소 : IP 주소중 비트가 모두 1인 것 
  • 사설 네트워크 : 개인적인 영역으로 원하는 대로 IP 설정 (RFC 1918범위 내에서 ), 인터넷상의 호스트 등과 통신 불가능
  • 공공 IP 주소 : 인터넷 상에서 통신이 가능한 IP 주소 
  • 공공 주소와 사설 주소가 모두 할당된 호스트를 준비하고 사설 주소만 있는 호스트는 해당 호스트를 경유해서 인터넷 세상과 통신 
• 라우팅 
  • 대상 서버가 다른 네트워크에 존재하는 경우 최종 목적지에 도착할 때까지 목적지를 알고 있는 라우터에게 전송을 부탁 
  • 외부와 접속하는 네트워크는 보통 기본 게이트웨이라는 라우터가 설치되어 있음 
  • 각 라우터는 라우팅 테이블을 기반으로 패킷을 전송
  • 도중에 있는 라우터가 잘못된 라우터 테이블을 가지고 있다면 목적지가 바뀔 수 있음 
  • 만약 잘못된 라우터 테이블을 가지고 있어 패킷이 라우터 간에 와복하게 되는 상태에 빠지는 것을 방지하기 위해 IP 헤더는 TTL(Time To Live)라는 생존 시간 정보를 가짐
  • 생존시간이 끝난 라우터는 패킷을 파기 (정상패킷이 파기되는 경우는 없다)

 

 

TCP / IP 관련 프로토콜 ④ 데이터 링크 계층의 이더넷 프로토콜 (Layer 2)

• 동일 네트워크 내의 네트워크 장비까지 전달받은 데이터를 운반
• 전기신호로 전송 
• IP는 IP 주소를 이용해서 여러 네트워크를 거쳐 데이터를 전송할 수 있지만 이더넷은 MAC 주소를 사용하여 동일 네트워크 내(자신이 포함된 링크 내)에서만 데이터 전송 가능
• 과정
  • IP 패킷(라우팅 테이블이 확인 되어 어떤 링크(NIC)가 패킷을 보낼지는 정해져 있다)에 이더넷 헤더와 풋터를 붙여 이더넷 프레임 생성(헤더에는 링크계층 주소인 MAC(동일 링크 내의 장비 MAC 주소(ARP테이블 참고)) 주소기록)
  • 목적지IP 주소에 따라 라우팅 테이블을 이용해서 어떤 NIC에 보낼지 결정
  • 송신 큐에 넣은 후 장치 드라이버 경유로 NIC에 전달
  • 커널 처리가 끝난 프레임은 버스를 통해서 NIC로 전달 
  • NIC에 연결된 장비로 프레임이 전송 
• MTU(Maximum Transfer Unit) : 해당 링크 층에서 하나의 프레임으로 전송할 수 있는 있는 최대 크기 
• TCP 의 MSS = MTU-(IP/TCP헤더)
• 송신측이 Path MTU Discovery 방법을 이용하여 송신 전에 경로상의 최소 MTU를 조사하여 미리 세그먼트 크기를 조정 -> IP 패킷의 최대크기를 MSS를 조정해서 맞춤
• 참고로 IPv6에서는 경로상의 패킷 분할 기능 폐지 
• 동일 네트워크 내의 데이터 전송에서 IP 를 통한 브로드 캐스트 주소 통신은 이더넷 상의 브로드캐스트 통신으로 (MAC 주소 FF-FF-FF-FF-FF-FF) 전송 
• VLAN
  • 브로드 캐스트 통신 등 전체에 데이터를 전송하는 경우는 불필요한 트래픽 증가 (네트워크를 적절하게 분할하는 것이 필요)
  • 네트워크 범위는 네트워크 스위치의 물리적 특성에 따라 좌우되므로 설정만으로 네트워크를 나눌 수 있는 구조가 필요(Virtual LAN) =  물리 구성에 의존하지 않고 가상적인 네트워크를 나누는 구조 
  • 태그 VLAN이 설정된 스위치는 다른 스위치에 프레임을 전송할 때 해당 프레임이 속한 VLAN을 가리키는 태그를 붙여 전송
  • 목적지 네트워크에 도착 시 태그를 제거하고 목적지 컴퓨터로 보낸다. 
  • 단 같은 L2 스위치에 접속된 컴퓨터들이라도 각기 다른 VLAN ID에 설정된 포트를 사용하고 있는 경우는 L3 스위치나 라우터 없이 서로 통신할 수 없음)

 

 

TCP / IP 관련 프로토콜 ⑤ 최종목적지의 수신 확인

• L2 스위치나 L3 스위치를 경유해서 최종 목적지인 서버에 이더넷 프레임이 도착 
• NIC로 프레임이 도착하면 NIC 수신 큐에 저장해서 OS 끼어들기나 OS 폴링을 통해 커널 내 프레임 복사 (버스를 통해 메모리로 전달)
• 이더넷 헤더와 푸터를 제거하고 IP 패킷 꺼냄
• IP 주소를 확인해서 자신에게 보낸 패킷이 맞는지 확인 
• 맞으면 IP 헤더를 제거하고 TCP 세그먼트 꺼냄 
• TCP 포트 번호를 확인해서 포트 번호에 대응하는 소켓에 데이터 전달 
• TCP 구성을 제거하고 안에있는 애플리케이션 데이터를 재구성
• 소켓을 통해 애플리 케이션에게 전달 

 

 

 

 

안정성, 고가용성

• 시스템 서비스가 가능한 한 멈추지 않도록 하는 것 
• 컴포넌트 이중화
  • 고장, 장애에 의한 정지가 발생하지 않을 것
  • 고장, 장애가 발생해도 복구할 수 있을 것
• 컴포넌트 감시 
  • 고장, 장애가 발생한 것을 검출할 수 있을 것
• 데이터 백업 
  • 고장, 장애가 발생해도 데이터가 보호될 것 

 

 

 

이중화

• 하나의 기능을 병렬로 여러개 나열해서 하나의 장애가 발생해도 다른 것을 이용해서 서비스를 계속할 수 있는 것
• 확장성, 부하분산 
• 부하분산 : 모두가 균등하게 부하를 감당 
• 내부적 생존 감시 : 장애가 발생한 부분이 있는지 정기적으로 확인하는 구조 
• 마스터결정 : 기능을 수행하는 대상이 존재하는지 판단하는 구조 
• 페일 오버 : 수행할 대상이 없는 경우 교체할 수 있는 구조 
• H/W 컴포넌트 계층
  • 전원이나 네트워크, 하드디스크 이중화 (신뢰도가 낮은 부분과 데이터 보호를 목적)
  • CPU와 메모리는 처리성능을 향상시키는 것이 목표(이중화 x )
  • 교체비용이 많이 들기 때문에 시스템 이중화가 더 싸고 효과적 (단일 호스트 장애 인지보다 시스템 서비스 장애를 인지 )
• 시스템 계층 
  • 여러 서버에서 동일한 처리를 실행하는 서버 이중화 
• 물리적 위치 계층 
  • 시스템을 서로 다른위치 (데이터 센터나클라우드)에서 운영하는 이중화 

 

 

이중화 ① 서버 내 이중화 

• 전원, 장치등의 이중화 
• 네트워크 인터페이스 이중화 (카드 이중화 및 포트 이중화) 
  • 하드웨어 또는 OS로 구현되며 액티브 스탠바이(마스터-워커)구조
  • 문제가 발생할 시 스탠바이가 액티브로 변경(페일오버(FailOver)
  • 리눅스의 Bonding
• 저장소 이중화 
  • HDD 이중화 (TCP/IP 프로토콜 상에 저장소 네트워크를 구축)
  • HDD 자체 이중화는 RAID를 통해서
    • 여러 HDD를 묶어서 그룹으로 만들고 이것을 논리적인 HDD로 인식하는 기술(안정성 확보(데이터 기록 이중화))
    • 성능향상(여러개의 HDD 병렬로 동작), 용량확장
  •  RAID5
    • 이중화 확보를 위해 패리티(오류수정부호)를 기록
    • 페리티를 하나의 HDD에 집중시키지 않고 분산
    • I/O 성능이 RAID10에비해 느림
  • RAID1
    • 이중화 없이 HDD에 기록
  • RAID10 
    • 복수의 HDD에 병렬로 이중기록을 하는 방식
    • 미러링때문에 HDD 전체 용량의 1/2밖에 사용 못함 
• 버스 이중화 : 버스를 페일오버

 

 

이중화 ② 웹 서버 이중화 

• 아파치에서는 어느 쪽이든 미리 여러개를 가동시켜 두어서 클라이언트 요청에 바르게 대응할 수 있는 구조
• ps-efL 명령어로 프로세스와 스레드의 상태 차이를 알 수 있음 (쓰레드 -> PID가 모두 일치, 프로세스 -> PID모두 다르다)
• 장애 발생 시 http상태 코드로 장애를 표시 (요청이 너무 많아 서버가 따라 갈 수 없는 상태의 경우 503 (웹 서버에 대한 요청은 큐에 쌓이지 않고 바로 에러로 반환))
  • DNS를 통한 이중화
    • 하나의 호스트명에 대해 복수의 IP주소를 반환
    • 질의에 대해 순서대로 IP주소를 반환 
  •  부하 분산 장치를 이용한 웹 서버 이중화  (로드 밸런서) 
    • 클라이언트 측에서 쿠키 사용을 허하면 두번째 이후 접속부터 HTTP 요청 헤더에 쿠키를 저장해서 접속
    • 부하분산 장치는 이 쿠키를 읽어서 같은 서버에 요청을 할당
    • 주의 
      • 프록시를 경유하면 프록시 서버의 IP 주소가 클라이언트 IP 주소가 돼서 요청이 한쪽으로 몰릴 수 있다. (각 AP 서버가 쿠키 덮어쓰기 하지 않는지 확인)
      • URL 부정 접속에 대한 대책을 검토 해두어야 한다
    • 장애 발생시 클라이언트 요청을 동적으로 다른 서버에 할당(페일오버)
    • 자바에서는 세션 정보 보호를 위한 구조가 존재

 

 

이중화 ③ AP 서버 이중화 

•  부하분산 장치 이용 혹은 서버 요청 이중화 기능으로 AP 서버 요청을 분산
• 세션 정보 이중화 
  • 실패 감지시 보조 세션이 승격되어 리다이렉션되고 세션정보를 복사
  • 세션정보가 저장돼 있는 서버(기본/보조)정보를 쿠키의 JSESSIONID에 추가해서 반환 

 

 

이중화 ④ DB 연결 이중화 

• AP 서버에는 DB서버에 접속 시에 사용할 연결을 사전에 여러개 생성해 두는 기능이 존재 (연결 풀링)
• 웹 로직이 감시에 두번 실패하면 일단 끊은 후 재접속
• 연결이 모두 사용 중일 때에는 설정 최댓값 까지 연결 수가 늘고 최댓값을 초과한 요구가 오면 일정 시간 대기
• 최솟값과 최댓값을 동일하게 설정하여 오버헤드를 가능한 경감
• 방화벽 유무를 확인하여 오랫동안 사용하지 않은 세션을 자동으로 제거하지 않는지 확인

 

이중화 ⑤ DB 서버 이중화 

• 액티브-스탠바이형의 클러스터(페일오버)
  • 장애 발생시 액티브는 서비스를 정지하거나 OS를 재시작하면서 스탠바이로 변경
  • 스탠바이는 이를 감지하여 액티브 상태로 서비스를 시작하며 각노드의 상태가 기록
  • 클러스터 소프트웨어는 등록된 서비스가 정상 작동하고 있는지 하트비트를 통해 정기적으로 확인
  • 이상 발생시 서비스를 정지하고 대기하고 있던 스탠바이 측 서비스를 시작하여 서비스 유지 
• 스플릿 브레인
  • 하트비트를 통해 상태를 인식할 수 없는 상태 
  • 투표장치에 먼저 스플릿 브레인 상태를 기록한 쪽의 데이터에 액세스 할 수 없도록 배타적 제어를 통해 데이터 이중 기록의 문제를 방지 
  • 오동작 할 가능성이 있으므로 반드시 중요한 데이터는 백업해두고 이중 안전 장치가 필요한 경우는 원격 복제 기능 등을 이용
• 액티브 액티브 
  •  Shared Everything 
    • 디스크, 데이터를 모든 노드가 공유
    • 장애 발생시 다른 노드로 쉽게 처리 지속 
    • 캐시전송 
  • Shared Nothing 
    • 각 노드 별로 디스크를 가지고 있어 데이터 분산
    • 노드를 배치하기 쉬움 (블랙박스화로 클라우드 상에서는 많이 사용됨)
    • 장애발생시 데이터 손실될 가능성이 있는데 이를 위해 데이터 보호 기능이 사용됨 (AP 서버 세션정보 이중화 처럼 복제 데이터 교환을 위해 네트워크 리소스와 디스크 용량을 소비한다는 단점이 있음)

 

 

이중화 ⑥ 네트워크 장비 이중화 

•  L2 스위치 이중화 
•  L3 스위치 이중화 (액티브-스탠바이)
•  네트워크 토폴로지 (복수의 경로(루프)를 통해 L2와 L3 이중화 조합)

 

 

이중화 ⑦ 사이트 이중화 

 

 

 

감시 

• 생존감시
  • ping 명령어 
• 로그감시
  • 중요하다고 인지하고 있는 로그 출력문을 미리 저장해두고 있다가 실제 로그 파일이 출려되는 내용을 저장해둔 것과 비교하여 일치하는 내용이 있으면 문제의 중요도에 따라 감시 서버에게 보고
  • syslog, SNMP, 메일 등
• 성능 감시
  • 디스크 사용률, 메모리 사용현황, 디스크 고갈 등의 리소스 상태 파아고가 네트워크 액세스 지연, 디스크 액세스 시간 등의 응답 상태를 파악하는 것
  • vmstat, sar 명령어
    •  CPU : CPU 사용률, CPU 대기행렬
    • 메모리 : 빈 메모리 양
    •  DISK : 남은 용량, 디스크 액세스 시간
    • 네트워크 : I/F 인바운드 /아웃바운드 대역 사용률, 패킷 손실
    •  HTTP(웹 서버 고유) : HTTP요청 응답 시간, 초당 HTTP 요청 처리수, 초당 HTTP세션 수 
    • JAVA(AP 서버 고유) : 메모리힙 크기, 가비지 컬렉션 횟수
    • DATABASE(DB 서버 고유) : 영역의 남은 용량, 캐시 사용률, SQL 응답
• SNMP 
  • 감시 전용 프로토콜
  • 네트워크 장비나 서버 가동상태, 서비스 가동상태, 시스템 리소스(시스템 성능), 네트워크 트래픽 감시
• 콘텐츠 감시
  • 웹 화면이 정상적으로 보여지는지 확인하기 위한 웹 시스템 특유의 감시 

 

 

 

백업 

• 데이터를 복제해서 별도 장소에 보관, 백업 취득 빈도나 시점은 복원을 고려해서 계획을 세워야 한다 
• RTO(Recovery Time Objective) : 복구 목표 시간
• RPO(Recocery Point Objective) : 복구 기준 시점
• 시스템 백업
  • OS나 미들웨어 등 일반 서버의 로컬 디스크 영역을 백업
  • 조기 구축 후, 일괄처리 적용시, 대규모 구성 변경시 적용 
  • OS 명령(tar, dump), 백업 소프트웨어를 이용하여 취득 
•  데이터 백업
  • 매일 변경되는 데이터가 손실되지 않도록 하는 것
  • 취득 빈도가 높다
  • 일치성 보장 기능이 필수 
  • 데이터 자체와 데이터 갱신 내역이 기록되어 있는 저널을 모두 취득 
  • 데이터는 기본적으로 서비스를 정지한 후 변경이 발생하지 않는 상태에서 취득 

 

 

 

응답과 처리량 

• 인프라 관점에서 응답(Response) 속도가 느린지, 처리량(Throughput)이 낮은지, 둘 다 해당하는지 확인 
• 응답 문제 
  • 어느 계층에서 응답 지연 문제가 발생하고 있는지 확인 
• 처리량 문제
  • 대량의 데이터를 교환하고 싶은데 영역이 부족한 경우에 발생

 

 

 

병목현상 

• 처리량을 제한하고 있는 요인 
•  CPU 병목 현상
  • 100%라고 나쁜 것이 아니라 효율적인 상태를 나타내는것
  • CPU를 이용하는 처리가 많아서 큐 대기행렬이 발생하고 있을 때(vmstat의 Run-Queue값이 증가한 상태)
    • CPU 코어 수를 늘리거나 수평분할에 따른 서브를 추가하여 병렬처리하도록 처리량 늘리기 (scale out)
  • CPU 응답이 느릴 때 (응답의 병목현상) 
    • CPU 클럭수 (초당 명령 처리 수)를 늘려처리능력을 향상시키기 (scale -up)
      • 클럭수를 늘리는 데에는 한계가 있고 public cloud를 사용할 때 cpu 클럭 수를 제어할 수 없는 단점이 있어 극적인 개선 효과는 기대하기 어려움
    • 처리를 분할하여 다수의 CPU 코어에게 병렬로 동시 처리 시키기 
      •  처리를 병렬화 할 수 있는 가가 중요한 문제 
  •  CPU 사용률이 오르지 않을 때 (네트워크 I/O 나 디스크 I/O 에서 막히는 경우 -> CPU의 문제보다 어플리케이션이 CPU, 메모리, I/O등의 하드웨어 리소스를 제대로 활용하지 못함)
    • 처리 다중화
      • 쓰레드를 여러개 가동하여 동기 I/O 명령을 쓰레드 단위로 병행해서 실행 -> I/O 부하와 CPU 사용률 증가
    • I/O 비동기화 
      • 프로세스가 I/O 처리 완료를 기다리지 않고 다음으로 넘어갈 수 있도록 설정 -> CPU 처리와 I/O 처리를 동시에 진행하여 사용상태 개선 
• 메모리 병목 현상
  • 영역 부족
    • 페이징(paging) 또는 스와핑(swapping)처리를 이용해서 빈 메모리 확보
  •  동일 데이터에 대한 병목현상
    • 메모리는 빠르지만 특정 영역을 복수의 프로세스가 공유하는 경우 빠른 쪽이 독점해서 관리하기 때문에 각각의 프로세스나 스레드가 경합하면서 CPU 리소스를 불필요하게 소비함 (비효율)
    • 복수의 프로세스나 스레드가 같은 메모리 영역을 참조하지 않도록 설정
    • 대기 행렬로 하면 해당 영역이 배열로 관리되어 관리영역이 데이터보다 커지기 때문에 이는 사용하지 않음 
• 디스크 I/O 병목현상
  • 디스크는 I/O는 느리다, I/O 효율을 높이거나 I/O를 줄여야 한다
  • 외부저장소 사용
    • 많은 디스크를 배치하고 캐시 전용 메모리 영역을 갖추고 있어 디스크 수에 따라 처리량이 증가하므로 유리)
  • 랜덤I/O
    • 디스크는 한 곳에 랜덤 액세스 하여 느림
    •  작은 파일에 액세스 하는 경우
      • 단일 디스크에 랜덤 I/O 하여 느림
      • 강한 기억 영역을 이용하여 디스크의 내용을 캐시하는 구조를 적용해서 효율화를 도모
  •   순차 I/O
    • 복수의 디스크에 순차적으로 액세스 병렬화 및 디스크 자체의 순차 특성을 이용, 빠름)
    • 큰 파일에 대한 일괄 읽기 처리가 발생시
    • 다수의 디스크에 대해 동시에 순차 액세스 하여 순차 및 병렬로 액세스
    • 고속 처리 

• 네트워크 I/O 병목현상 
  • 응답시간 오버헤드가 큼
  • 처리량을 개선하는 접근법이나 네트워크 I/O 자체가 발생하지 않도록 해야함
  • 통신 프로세스의 병목
    • 처리를 다중화 하여 병렬화 (통신대역 모두 사용)
  •  네트워크 경로 병목현상
    • IP 주소수가 부족한지, 경로와 트래픽 증감에 대해서도 검토 (게이트웨이)
• 애플리케이션 병목 현상
  • 데이터 갱신의 병목현상 (특정 데이터 의존 처리가 병목지점이 될때(배타적제어))
    • 값의 캐시화 (근본적인 해결책은 아님)
    • 병목지점 분할 (레코드를 두개로 나누어 한번에 두개의 처리를 진행)
  • 외부질의의 병목 현상
    • 외부 질의에 대한 병목 부분을 캐시 등 다른 방법을 통해 처리