[정리] IT 인프라 구조

---

이 포스팅은 2015년 10월 20일에 작성된 예전 블로그 글을 새로이 옮긴 것입니다. 참고바랍니다.

---

 

목차

 

 

참고도서
야마자키 야스시 외 3인. 『그림으로 공부하는 IT 인프라 구조』. 제이펍. 2015

 

1. 인프라 아키텍처

1.1 개념

인프라(infra)는 말 그대로 '기반 시설'을, 아키텍처는 '구조'를 의미한다.

즉, IT 인프라 아키텍처는 서버, 네트워크 등 하드웨어부터 소프트웨어까지 IT 운영에 필요한 제반 사항들을 말한다.

IT 업계에서 사용되는 인프라 아키텍처는 크게 구성 방식에 따라 '집약형'과 '분할형'으로 나뉘며,

'분할형'은 다시 '수직 분할', '수평 분할', '지리 분할'로 나뉜다.

 

1.2 집약형과 분할형 아키텍처

1.2.1 집약형 아키텍처

하나의 대형 컴퓨터로 모든 처리를 하는 방식.

'범용 장비', '호스트', '메인 프레임' 등으로 불린다.

 

장점

• 한 대의 대형 컴퓨터만 있으면 되므로 구성이 간단하다.
• 대형 컴퓨터의 리소스 관리나 이중화에 의해 안정성이 높고 고성능이다.

 

단점

• 대형 컴퓨터의 도입 비용과 유지 비용이 크다.
• 확장성에 한계가 있다.

 

1.2.2 분할형 아키텍처

여러 대의 소형 컴퓨터를 조합해서 하나의 시스템을 구축하는 구조이다.

'오픈 시스템', '분산 시스템' 등으로 불리며, 분할형 아키텍처에서 이용되는 컴퓨터를 '서버'라고 한다.

 

장점

• 낮은 비용으로 시스템을 구축할 수 있다.
• 서버 대수를 늘릴 수 있어서 확장성이 높다.

 

단점

• 대수가 늘어나면 관리 구조가 복잡해진다.
• 한 대가 망가지면 영향 범위를 최소화하기 위한 구조를 검토해야 한다.

 

1.3 수직 분할형 아키텍처

분할형에서는 서버 분할 방식으로 고려해야 한다.

서버별로 다른 역할을 담당하는 방식이 '수직 분햘형 아키텍처'이다.

 

1.3.1 클라이언트-서버형(C/S) 아키텍처

업무 애플리케이션, 미들웨어, 데이터베이스 등의 소프트웨어를 '물리 서버' 상에서 운영하고, 이들 소프트웨어에 '클라이언트' 또는 '단말'이라 불리는 소형 컴퓨터가 접속해서 이용하는 형태.

 

장점

• 클라이언트 측에서 많은 처리를 할 수 있어서 소수의 서버로 다수의 클라이언트를 처리할 수 있다.

 

단점

• 클라이언트 측의 소프트웨어 정기 업데이트가 필요하다.
• 서버 확장성에 한계가 발생할 수 있다.

 

1.3.2 3계층형 아키텍처

클라이언트-서버형을 발전시킨 것으로, '프레젠테이션 계층', '애플리케이션 계층', '데이터 계층'의 3층 구조로 분할되어 있다. 대부분의 인터넷/모바일 등 대부분의 시스템에서 3계층 구조를 채용하고 있다.

 

프레젠테이션 계층

• 사용자 입력을 받는다.
• 웹 브라우저 화면을 표시한다.

 

애플리케이션 계층

• 사용자 요청(request)에 따라 업무 처리를 한다.

 

데이터 계층

• 애플리케이션 계층의 요청에 따라 데이터 입출력을 한다.

 

장점

• 서버 부하 집중 개선
• 클라이언트 단말의 정기 업데이트가 불필요
• '처리 반환'에 의한 서버 부하 저감

 

단점

• 구조가 클라이언트-서버 구성보다 복잡하다.

 

1.4 수평 분할형 아키텍처

수직 분할형 아키텍처가 서버별로 다른 역할을 하도록 구성한 것이라면, 수평 분할형 아키텍처는 용도가 같은 서버를 늘려 안정성 및 성능을 향상시키기 위한 구조이다.

대부분의 시스템에서는 수직 분할형과 수평 분할형을 함께 사용한다.

 

1.4.1 단순 수평 분할형 아키텍처

'sharding(샤딩)', 'partitioning(파티셔닝)'등으로 불린다.

같은 기능을 가진 복수의(독립된) 시스템으로 단순히 분할한 구조이다.

 

장점

• 수평으로 서버를 늘리기 때문에 확장성이 향상된다.
• 분할한 시스템이 독립적으로 운영되므로 서로 영향을 주지 않는다.

 

단점

• 데이터를 일원화해서 볼 수 없다.
• 애플리케이션 업데이트는 양쪽을 동시에 해 주어야 한다.
• 처리량이 균등하게 분할돼 있지 않으면 서버별 처리량에 치우침이 생긴다.

 

1.4.2 공유형 아키텍처

단순 수평 분할형과는 달리, 3계층 중 '데이터 계층'이 서로 동기화가 되어 어느 쪽에서든 데이터를 참조할 수 있다.

 

장점

• 수평으로 서버를 늘리기 때문에 확장성이 향상된다.
• 분할한 시스템이 서로 다른 시스템의 데이터를 참조할 수 있다.

 

단점

• 분할한 시스템 간 독립성이 낮아진다.
• 공유한 계층의 확장성이 낮아진다.

 

1.5 지리 분할형 아키텍처

업무 연속성 및 시스템 가용성을 높이기 위해 지리적으로 분할한 아키텍처를 말한다.

 

1.5.1 스탠바이형 아키텍처

'HA(High Availability, 고가용성) 구성', '액티브-스탠바이 구성' 등으로 불린다.

물리 서버를 최소 두 대를 준비하여 한 대에 장애가 발생하면 그 즉시 가동중인 소프트웨어를 다른 한 대로 옮겨서 운영하는 방식이다.

이때 소프트웨어 재시작을 자동으로 하는 구조를 '페일오버(failover)'라고 한다. 단, 페일오버 대상 서버가 놀고 있는 상태가 되기 때문에 리소스 측면에서 낭비가 발생한다.

 

1.5.2 재해 대책형 아키텍처

특정 데이터 센터(사이트)에 있는 상용 환경에 고장이 발생하면 다른 사이트에 있는 재해 대책 환경에서 업무 처리를 재개하는 것을 말한다. 단, 애플리케이션 최신화와 데이터 최신화가 문제가 될 수 있다.

 

1.5.3 클라우드형 아키텍처

3계층형 시스템의 일부 또는 전부가 클라우드 서비스 제공자가 보유하고 있는 물리 서버에서 동작한다.

 

SaaS(Software as s Service) 모델

• 서버, 애플리케이션을 포함한 업무 시스템을 클라우드 서비스 회사에서 제공.

 

PaaS(Platform as a Service), IaaS(Infrastructure as a Service), DBaaS(Database as a Service) 모델

• 일반적인 3계층형 시스템을 구성하는 서버의 일부 혹은 전부를 클라우드 상의 리소스로 대체.

---

 

2. 서버를 열어 보자

(생략)

---

 

3. 3계층형 시스템

 

3.1 3계층형 시스템의 구성도

3계층 시스템은 웹 서버 <-> AP 서버 <-> DB 서버로 구성되어 있고, 세 대의 서버는 스위치를 경유해서 연결되어 있다.

3계층형 시스템에 대한 보다 자세한 사항은 '제이펍' 사이트에서 다운로드 가능.
http://jpub.tistory.com/503

 

3.2 주요 개념 설명

 

3.2.1 프로세스와 스레드

프로세스 및 스레드는 프로그램 실행 파일 자체가 아니라 OS 상에서 실행돼서 어느 정도 독립성을 가지고 동작하는 것이다.

 

프로세스

• 전용 메모리 공간을 이용해서 동작한다.

 

장점

• 개별 처리 독립성이 높다.

 

단점

• 생성 시 CPU 부하가 높다.

 

스레드

• 다른 스레드와 메모리 공간을 공유한다.

 

장점

• 생성 시 부하가 낮다.

 

단점

• 메모리 공간을 공유하기 때문에, 의도하지 않는 데이터 읽기/쓰기가 발생할 수 있다.

 

3.2.2 OS 커널

OS의 본질은 커널이다.
커널의 역할은 크게 여섯 가지로 나눌 수 있다.

1. 시스템 콜 인터페이스
2. 프로세스 관리
3. 메모리 관리
4. 네트워크 스택
5. 파일 시스템 관리
6. 장치 드라이버

 

시스템 콜 인터페이스

AP가 OS를 통해서 어떤 처리를 하고 싶을 때 시스템 콜(디스크 I/O, 네트워크 I/O 등)을 이용하여 커널에 명령을 내린다. 이때 명령이 인터페이스를 통해서 전달된다.

 

프로세스 관리

프로세스의 처리 우선순위를 결정하는 등 CPU 코어를 고려하여 프로세스를 관리한다.

 

메모리 관리

물리 메모리 공간의 최대치를 고려하여, 프로세스가 이용하는 독립 메모리 공간을 확보하는 등 메모리 영역을 관리한다.

 

네트워크 스택

차후 네트워크 부분에서 설명.

 

파일 시스템 관리

파일 시스템용 인터페이스를 제공한다.
파일 시스템은 OS 기능의 하나로서 물리 디스크에 제공된 데이터를 관리하는 기능이다.

 

장치 드라이버

디스크나 NIC 등의 물리 장치용 인터페이스를 제공한다.

 

3.2 웹 데이터 흐름

웹 데이터 흐름의 본질은 '요청 기반으로 어떠한 처리를 하고 필요에 따라 해당 요청을 삼자에게 할당하는 것'이다.

 

3.3.1 클라이언트 PC부터 웹 서버까지

1. 웹 브라우저가 요청을 보낸다.
2. 이름 해석 후 해당 웹 서버에 요청을 보낸다.
3. 웹 서버가 요청을 접수한다.
4. 웹 서버가 정적 콘텐츠인지 동적 콘텐츠인지 판단한다.
5. 전자일때는 물리 디스크에서 내용을 취득하고, 후자일때는 AP 서버에 요청을 보낸다.

 

3.3.2 웹 서버부터 AP 서버까지

1. 웹 서버로부터 요청이 도착한다.
2. 스레드가 요청을 받으면 자신이 계산할 수 있는지, 아니면 DB 접속이 필요한지를 판단한다.
3. DB 접속이 필요하면 연결 풀(connection pool)에 액세스한다.
4. DB 서버에 요청을 보낸다.

 

3.3.3 AP 서버부터 DB 서버까지

1. AP 서버로부터 요청이 도착한다.
2. 프로세스가 요청을 접수하고 캐시가 존재하는지 확인한다.
3. 캐시에 없으면 디스크에 액세스한다.
4. 디스크가 데이터를 반환한다.
5. 데이터를 캐시 형태로 저장한다.
6. 결과를 AP 서버에 반환한다.

 

3.3.4 AP 서버부터 웹 서버까지

1. DB 서버로부터 데이터가 도착한다.
2. 스레드가 데이터를 가지고 계산 등을 한 후에 파일 데이터를 생성한다.
3. 결과를 웹 서버로 반환한다.

 

3.3.5 웹 서버부터 클라이언트 PC까지

1. AP 서버로부터 데이터가 도착한다.
2. 프로세스는 받은 데이터를 그대로 반환한다.
3. 결과가 웹 브라우저로 반환되고 화면에 표시된다.

---

 

4. 인프라 기본 이론

 

4.1 직렬/병렬

직렬 처리로 속도를 올리는 데는 한계가 있다.

병렬화를 통해 속도는 빨라지지 않지만, 단위 시간당 처리량을 늘릴 수 있다.

• 병렬 처리에는 합류점, 직렬화 구간, 분기점이 병목 지점이 되기 쉽다.
• 병렬화할 때는 일을 분담해서 처리를 한 후 다시 집약할 때 오버헤드가 걸린다. 그러므로 이 오버헤드를 감안하더라도 효과가 있을 경우에 병렬화를 한다.

 

직렬 장점

• 구조가 간단해서 설계나 구현 난이도가 낮다.

 

직렬 단점

• 복수의 리소스(컴퓨터나 프로세서 등)를 유용하게 이용할 수 없다.

 

병렬 장점

• 복수의 리소스를 유용하게 이용할 수 있으며, 직렬에 비해 동일 시간당 처리할 수 있는 양이 증가한다. 또한, 일부가 고장 나더라도 처리를 계속할 수 있다.

 

병렬 단점

• 처리 분기나 합류를 위한 오버헤드가 발생한다. 배타 제어 등을 고려해야 하고 구조가 복잡해서 설계나 구현 난이도가 높다.

 

4.2 동기/비동기

 

동기

다른 사람에게 일을 부탁한 후 끝날 때까지 아무것도 하지 않고 기다리기 때문에 그 사이에 다른 것을 할 수 없다. 하지만 의뢰한 것이 끝났는지 여부를 확실하게 확인할 수 있다.

 

장점

• 의뢰한 처리가 끝났는지 여부를 쉽게 확인할 수 있어서 구조가 간단하다.
• 구현 난이도가 낮다.

 

단점

• 의뢰한 처리가 끝나기까지 기다려야 하기 때문에 대기 시간을 활용할 수 없다.

 

비동기

끝날 때까지 기다리지 않기 때문에 병렬로 다른 일을 할 수 있다. 하지만 의뢰한 일이 끝났는지 여부를 확인하고 싶으면 별도의 방법을 이용해야 한다.

 

장점

• 의뢰한 처리가 진행되고 있는 동안 시간을 효율적으로 사용해서 병렬 처리를 할 수 있다.

 

비동기 단점

• 의뢰한 처리가 끝났는지 확인하지 않으면 모르기 때문에 불필요한 확인 처리가 늘어난다. - 구조가 복잡해서 구현 난이도가 높다.

 

4.3 큐(queue)

큐(대기 행렬)에서는 줄을 설 때는 가장 마지막에 서고, 처리는 선두부터 순서대로 된다. 먼저 들어온 데이터가 먼저 나가는 큐 동작을 FIFO(First In First Out) 방식이라고 한다.

 

사용되는 곳

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

 

4.4 배타적 제어

복수의 처리가 공유 자원(CPU, 메모리, 디스크 등)에 동시에 액세스(주로 갱신)하면 불일치가 발생할 수 있기 때문에 배타적 제어로 보호해 주어야 한다.

배타적 제어에서는 특정 처리가 공유 자원을 이용하고 있는 동안 다른 처리가 이용할 수 없계 해서 불일치가 발생하지 않도록 한다.

 

배타적 제어를 사용하는 경우 장점

• 공유 데이터의 일관성을 유지할 수 있다.

 

배타적 제어를 사용하는 경우 단점

• 병렬 처리가 안 된다.

 

배타적 제어를 사용하지 않는 경우 장점

• 병렬로 빠르게 처리할 수 있다.

 

배타적 제어를 사용하지 않는 경우 단점

• 데이터 불일치가 발생할 가능성이 있다.

 

4.5 상태 저장/상태 비저장

 

상태 저장(stateful)

상태를 고려하기 때문에 복잡한 처리가 가능하지만, 시스템 복잡성이 커진다.

 

장점

• 자신의 상태를 이해하기 때문에 요청 내용을 최소화할 수 있다

 

상태 비저장(stateless)

상태를 고려하지 않기 때문에 간단하며, 성능이나 안정성 측면에서 우수하다.

 

장점

• 요청과 그에 대한 응답 구조가 간단하다는 것이다.

 

프로세스 상태 전이(프로세스 처리는 상태 저장 방식)

1. 애플리케이션을 실행하면 프로세스가 생성된다. (프로세스 실행 개시)
2. 실행 큐라 불리는 순서 대기 행렬에 줄을 선다. (실행 가능 상태)
3. 차례가 돌아오면 '실행 상태'로 전이하고 애플리케이션이 처리한다.
4. 디스크 액세스 등 I/O 대기가 발생하는 처리를 실행한 경우 '대기 상태'로 전이한다.
5. 이 세 가지 상태를 전이하면서 처리가 전부 끝나면 '종료 상태'가 된다.

 

4.6 가변 길이/고정 길이

 

가변 길이(variable-length)

공간을 유용하게 활용할 수 있지만 성능 면에서 불안정하다.

 

고정 길이(fixed-length)

쓸데없는 공간이 생기지만 성능 면에서는 안정적이다.

 

4.7 데이터 구조(배열과 연결 리스트)

 

배열

데이터를 빈틈없이 순서대로 나열한 데이터 구조.

 

장점

• N번째 요소 탐색이 빠르다.

 

단점

• 데이터 추가, 삭제가 느리다.

 

연결 리스트

• 데이터를 선으로 연결한 데이터 구조.

 

장점

• 데이터 추가, 삭제가 빠르다.

 

단점

• N번째 요소 탐색이 느리다.

 

해시 테이블

배열과 연결 리스트의 상호 장점만 조합해서 약점을 보완한 데이터 구조.
큐(queue)나 스택(stack) 등의 데이터 구조도 배열이나 연결 리스트로 구현돼 있다.

 

4.8 탐색 알고리즘(해시/트리 등)

필요한 때에 필요한 데이터를 빠르게 찾기 위해서 데이터를 정리해 둘 필요가 있다.

데이터를 찾을 때의 데이터 구조와 데이터 저장 방식(메모리, HDD, SSD 등) 특성에 따라 적합한 데이터 정리 방법이 달라진다.

데이터 정리 방법을 '데이터 구조', 처리 순서를 '알고리즘'이라고 한다.

처리 상대에 맞추어 데이터 구조를 정리할 필요가 있기 때문에 '알고리즘과 데이터 구조'는 자주 함께 다루어진다.

---

 

5. 인프라 응용 이론

 

5.1 캐시(cache)

 

5.1.1 캐시란?

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

데이터 재사용을 전제로 한다.

데이터가 실제 데이터와 캐시라는 이중 구조로 저장되기 때문에 리소스 소비가 늘어난다.

설계 시에는 어떤 데이터를 캐시하는 것이 효과적인지를 검토해야 한다.

시스템 가동 직후 등에는 캐시에 데이터가 없기 때문에 원하는 성능이 나오지 않을 수 있다.
캐시의 데이터가 손실되는 경우를 대비해서 복구 순서를 설계 시에 확립해야 한다.

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

 

적합한 시스템

• 참조 빈도가 높은 데이터
• 캐시의 데이터가 손실돼도 문제가 없는 시스템

 

부적합한 시스템

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

 

5.2 끼어들기(interrupt)

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

 

5.3 폴링(polling)

질의 방향이 단방향이다.

질의는 일정 간격을 따라 정기적으로 발생한다.

반복(루프)만 하면 되기에 프로그래밍이 쉽다.

상대가 응답하는지 확인할 수 있다.

모아서 일괄적으로 처리할 수 있다.

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

 

적합한 처리

• 일정 간격으로 처리를 실행하는 좋은 처리
• 감시

 

부적합한 처리

• 상태가 아닌 입력 내용에 따라 실행 내용을 변경하는 처리
• 처리 우선순위를 정해야 하는 처리

 

5.4 핑퐁(pingpong)

예를 들어, 물건을 상자에 넣어서 나를 때 적절한 크기의 상자를 사용하면 쉽게 나를 수 있다. 그런데 상자가 너무 작아서 짐을 운반하기 위해 몇 번이고 왕복해야 하는 상황을 '핑퐁'이라 한다.

 

처리량 중시

큰 상자는 대량의 데이터를 빠르게 운반할 수 있다.(오라클의 'db file scattered read')

 

지연 시간 중시

작은 상자는 소량의 데이터를 빠르게 운반할 수 있다.(오라클의 'db file sequential read')

 

5.5 저널링(journal)

저널은 트랜잭션이나 매일 갱신되는 데이터의 변경 이력을 가리킨다. 저널을 남겨두는 것을 저널링이라 한다.(오라클의 Redo Log Buffer)

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

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

데이터 복구 시 롤백(rollback), 롤포워드(rollforward)에 이용된다.

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

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

 

적합한 시스템

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

 

부적합한 시스템

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

 

5.6 복제(replication)

장애시 데이터 손시을 예방할 수 있다.

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

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

백업과 달리 실제 데이터가 복제 데이터와 실시간으로 동기화된다.

복제 위치가 많으면 갱신이 많은 시스템과 같이 복제 오버헤드가 높아진다.

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

시스템 유지관리나 장애 시에는 복제 데이터도 고려해야 하기 때문에 설계나 운용 난이도가 높아질 수 있다.

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

 

적합한 시스템

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

 

부적합한 시스템

• 데이터 갱신이 많은 시스템

 

5.7 마스터-슬레이브(master-slave)

마스터-슬레이브는 상호 접속 관계의 일종으로, 한 사람이 관리자가 돼서 모든 것을 제어한다.

마스터-슬레이브의 반대가 피어 투 피어(peer-to-peer)

마스터-슬레이브와 피어 투 피어의 장점만 조합해서 이용하는 경우가 오라클의 RAC이다.

 

장점

• 관리자가 한 명이기 때문에 구현이 쉽다.
• 슬레이브 간 처리를 동기화할 필요가 없기 때문에 통신량이 줄어든다.

 

단점

• 마스터가 없어지면 관리를 할 수 없다(작업 인계 구조가 필요).
• 마스터의 부하가 높아진다.

 

5.8 압축

압축의 기본은 '중복 패턴 인식'과 그것을 '변경'하는 것

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

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

 

5.9 오류 체크/오류 수정

오류 체크: 디지털 데이터의 오류를 스스로 확인하고, 파손되었을 때 이를 감지하는 것을 의미한다.

오류 수정: 자동으로 복구하는 것을 가리킨다.

오류 검출은 주로 패리티 비트(parity bit)를 사용한다.

 

장점

• 상위 계층에서의 오류 관리 없이 데이터 일치성을 일정 수준 보장할 수 있다.

 

단점

• 체크 기능에 의한 리소스 부하 상승, 알고리즘의 복잡화 등.

---

 

6. 시스템을 연결하는 네트워크 구조

 

6.2 계층 구조(계층 모델)

데이터나 기능 호출 흐름에 따라 계층 간 역할이 나누어진다.

계층 모델의 대표적인 예가 'OSI 7계층 모델'이다. OSI 자체는 현재 사용되고 있지 않지만, 이 계층 구조 개념은 다양한 분야에서 공통적으로 참조할 수 있는 '참조 모델'로 현재도 사용되고 있다.

• 애플리케이션 계층(application layer): 애플리케이션 처리
• 프레젠테이션 계층(presentation layer): 데이터 표현 방법
• 세션 계층(session layer): 통신 시작과 종료 순서
• 전송 계층(transport layer): 네트워크의 통신관리
• 네트워크 계층(network layer): 네트워크 통신 경로 선택
• 데이터 링크 계층(data link layer): 직접 좁속돼 있는 기기 간 처리
• 물리 계층(physical layer); 전기적인 접속

시스템을 구성하는 서버 역시 계층 구조로 되어 있다.

• 자바 애플리케이션
• 애플리케이션 서버
• Java VM
• 커널
• 하드웨어

 

6.3 프로토콜(protocol)

컴퓨터가 서로 소통하기 위해 정한 규약을 가리킨다.

'통신 매체가 되는 통신 프로토콜'과 '의미를 전달하는 통신 프로토콜'로 나눌 수 있다.

 

6.4 TCP/IP를 이용하고 있는 현재의 네트워크

인터넷을 포함해서 현재 네트워크를 지탱하는 것은 TCP/IP 및 관련 프로토콜(TCP/IP protocl suite)이다.

OSI 참조 모델에서는 7계층으로 분할했지만, TCP/IP에서는 반드시 이 7계층이 분명하게 나누어지는 것은 아니다. TCP/IP 4계층 모델 등으로 불리며, OSI 7계층의 1

2계층을 모아서 링크 계층, 5

7계층을 모아서 애플리케이션으로 취급하기도 한다.

 

HTTP 통신의 경우

• HTTP(애플리케이션 계층)
• TCP(전송 계층)
• IP(IP 계층)
• 이너넷(링크 계층)

 

TCP/IP는 4계층을 숫자로 부를 때는 OSI 참조 모델의 7계층 방식으로 부르는 경우가 많다.

• 링크 계층(이더넷 계층): 레이어2, L2
• IP계층: 레이어3, L3
• 전송 계층(TCP 계층): 레리어4, L4
• 애플리케이션 계층: 애플리케이션 레이어, L7

 

6.5 [레이어7] 애플리케이션 계층의 프로토콜 HTTP

애플리케이션이 없으면 통신이 시작되지 않는다.

애플리케이션이 사용하는 프로토콜을 모두 애플리케이션 계층 프로토콜이라 부른다.

애플리케이션 계층 프로토콜은 자신이 통신을 하는 것이 아니라 통신 자체는 모두 OS, 즉 TCP/IP에 맡긴다.

브라우저에 URL을 입력해서 요청이 웹 서버에 도달하면 응답으로 HTML 파일이 반환된다. 브라우저는 이 파일을 해석해서 파일 내에 추가 이미지나 스크립트 등이 포함돼 있으면 다시 웹 서버에 이들을 요청한다.

 

6.5.1 요청(request)과 응답(response)

요청: 서버에 던지는 명령. 헤더 부분에는 다양한 부가 정보가 들어가며 세밀한 제어를 위해 사용(GET, POST).

응답: 요청에 대한 결과와 그에 대한 상태 정보를 가지고 있다. 또한, 메시지 바디에 실제 데이터를 저장한다.

 

6.6 [레이어4] 전송 계층 프로토콜 TCP

TCP의 역할은 애플리케이션이 보낸 데이터를 그 형태 그대로 상대방에게 확실하게 전달하는 것이다.

TCP가 담당하는 것은 어디까지나 서버가 송신할 때와 서버가 수신할 후 애플리케이션에게 전달할 때로, 상대 서버까지 전송하는 부분은 하위 계층인 IP에 모두 위임한다.

 

6.6.1 TCP의 기능(서비스)

• 포트 번호를 이용해서 데이터 전송
• 연결 생성
• 데이터 보증과 재전송 제어
• 흐름 제어와 폭주 제어.

 

6.6.2 커널 공간의 TCP 처리 흐름

1. 소켓에 기록된 데이터는 큐를 경유해서 커널 내 네트워크 처리 부분에 전달된다.
2. 커널에 전달된 데이터는 '소켓 버퍼'라는 메모리 영역에서 처리된다.
3. 데이터에 TCP 헤더를 붙여서 TCP 세그먼트를 생성한다. TCP 헤더에는 목적 애플리케이션 포트 번호 신호를 포함해 TCP 기능에 필요한 다양한 정보가 기록된다.
4. 하나의 TCP 세그먼트로 전송할 수 있는 최대 크기를 MSS라고 한다. MSS를 초과한 데이터는 자동적으로 분할돼서 복수의 TCP 세그먼트가 생성된다.

 

6.6.4 TCP 연결 생성(TCP/IP의 3-way handshaking)

1. 클라이언트는 서버 측 OS에게 가상 경로를 열도록 의뢰한다.
2. 서버 측에서 리슨하고 있는 포트 번호로 통신 요구가 온다. 서버는 문제가 없으면 열어도 된다는 응답을 한다.
3. 클라이언트 측도 확인했다는 메시지를 보내며, 이때 처음으로 통신용 가상 경로가 열린다.

 

6.6.5 데이터 보증과 재전송 제어

연결이 생성된 후에야 데이터 송수신이 시작되는데, TCP에는 데이터가 확실히 전달되도록 보증하는 기능이 있다.

데이터 손실 방지: 확인 응답과 재전송에 의해 구현된다(ACK).

데이터 순서 보증: 각 TCP 세그먼트에 시퀀스(sequence) 번호를 붙여서 구현한다.

 

6.6.6 흐름 제어와 폭주

데이터를 보내고 ACK를 기다리는 처리를 반복(동기 처리)하다 보면 시간이 많이 걸린다.

TCP는 어느 정도의 세그먼트 수라면 ACK를 기라디지 않고 전송하는 윈도우라는 개념을 가지고 있으며, ACK를 기다리지 않고 전송가능한 데이터 크기를 윈도우 크기라고 한다.

 

6.7 [레이어3] 네트워크 계층의 프로토콜 IP

TCP 세그먼트가 만들어지면 다음은 IP 처리가 시작된다.

 

6.7.1 IP의 역할

-IP 주소를 이용해서 최종 목적지에 데이터 전송
-라우팅(routing)

 

6.7.2 커널 공간의 IP 처리 흐름

TCP 세그먼트에 IP 헤더를 붙여서 IP 패킷을 생성한다. 대상 서버까지는 이 IP 패킷 형태로 네트워크를 경유해서 도달한다. IP 헤더에는 최종 목적지 서버의 IP 주소가 기록된다.

 

6.7.3 IP 주소를 이용한 최종 목적지로의 데이터 전송

IP 주소는 32비트로 표현된 숫자 집합이다. 사람이 읽기 쉽도록 8비트 단위로 마침표를 찍어서 표현한다.

IP 주소는 네트워크부와 호스트부로 나뉜다. 네트워크부는 어떤 네트워크인지를 가리키고, 호스트부는 해당 네트워크 내에 있는 컴퓨터(소유자)를 가리킨다.

네트워크부를 구분하기 위해 '/24'와 같은 CIDR(사이더) 표기를 사용한다. 또는 서브넷 마스크(subnet mask)라고 해서 255.255.255.0과 같이 표현하기도 한다.

IP 주소 중 호스트부의 비트가 모두 0인 것을 네트워크 주소, 모두 1인 것을 브로드캐스트(broadcast) 주소라고 한다.

 

6.8 [레이어2] 데이터 링크 계층의 프로토콜 이너뎃

IP 패킷이 만들어지면 계속해서 링크 계층의 처리가 시작된다.

이더넷을 포함한 링크 계층 프로토콜의 역할은 '동일 네트워크 내(링크 내) 데이터 전송'이다.

이더넷은 동일 네트워크 내, 즉 자신이 포함된 링크 내에서만 데이터를 전송할 수 있다. 이때 사용되는 주소가 MAC(맥) 주소다.

 

6.8.2 커널 공간의 이더넷 처리 흐름

1. IP 패킷에 이더넷 헤더와 푸터를 붙여서 이더넷 프레임을 만든다. 헤더에는 링크 계층 주소인 MAC 주소가 기록돼 있다. 목적지 IP 주소에 따라 라우팅 테이블을 이용해서 어떤 NIC에서 보내야 할지를 결정한다.
2. 송신 큐에 넣은 후 장치 드라이버 경유로 NIC에 전달한다.
3. 커널 처리를 끝낸 프레임은 버스를 통해서 NIC로 보낸다.
4. NIC에 연결된 장비로 프레임이 전송된다.

---

 

7. 무정지를 위한 인프라 구조

 

7.1 안정성 및 이중화

안정성, 고가용성: 시스템 서비스가 가능한 한 멈추지 않도록 하는 것.

이중화: 하나의 기능을 병렬로 여러 개 나열해서 하나에 장애가 발생해도 다른 것을 이용해서 서비스를 계속 할 수 있는 것을 가리킨다.

 

7.2 서버 내 이중화

 

7.2.1 전원, 장치 등의 이중화

 

7.2.2 네트워크 인터페이스 이중화

PCI 카드 이중화 및 포트 이중화로 카드 장애 및 포트 장애에 대응.

네트워크 인터페이스 이중화는 하드웨어 또는 OS로 구현한다.

리눅스 OS의 본딩(bonding) 구조. 본딩의 액티브-스탠바이 구성은 '액티브-백업'이라고 한다.

본딩이 이중화된 네트워크 인터페이스를 감시하는 방버에는 두 가지가 있다.

• MII 감시(Media Independent Interface, 대부분 선호)
• ARP 감시

 

7.3 저장소 이중화

 

7.3.1 HDD 이중화

컨트롤러에는 CPU나 캐시가 있어서 HDD I/O 제어를 한다.

최근에는 서버와 저장소 사이를 파이버 채널(FC)로 연결한 SAN(Storage Area Network) 네트워크 구성이 사용된다. SAN에서는 IP대신 WWN(World Wide Name) 주소를 이용해서 데이터를 전송한다.

HDD를 서로 연결하는 내부 버스는 최근 SAS(Serial Attached SCSI) 방식을 사용한다.

HDD 자체 이중화는 RAID를 사용한다.

 

RAID의 장점

• 안정성 확보
• 성능 향상
• 용량 확장

 

RAID 구성 패턴

• RAID0: 이중화 없이 HDD에 기록
• RAID1: 일반적으로 OS 디스크 이중화에 사용.
• RAID1+0: 복수의 HDD에 병렬로 이중 기록. 안정성과 성능을 균형 있게 구성. 그러나 미러링을 하기 때문에 HDD 전체 용량의 1/2 용량밖에 사용할 수 없다.
• RAID5: 이중화 확보를 위해 패리티 오류 수정 부호 기록. 패리티를 하나의 HDD에 집중시키지 않고 분산하는 것이 특징. 이중화 부분이 적고 (HDD 수 - 1) / HDD 수만큼의 용량을 사용할 수 있다. 그러나 패리티 연산이 이루어지기 때문에 I/O 성능이 RAID1+0에 비해 느리다.

 

7.4 웹 서버 이중화

 

7.4.1 웹 서버의 서버 이중화(소프트웨어 관점)

클라이언트 관점에서는 서버 측이 프로세스로 가동되고 있는지, 스레드로 가동되고 있는지를 의식할 필요는 없다.

아파치(Apache HTTP Server)에서는 어느 쪽이든 미리 여러 개를 가동시켜 두어서 클라이언트 요청에 빠르게 대응할 수 있는 구성을 가지고 있다. 프로세스/스레드 중 하나에 장애가 발생해도 다른 프로세스/스레드가 가동되고 있기 때문에 웹 서버의 서비스 전체가 정지되는 일은 없다.

 

7.4.2 서버 이중화(웹 서버 자체)

DNS를 이용해서 하나의 호스트명에 대해 복수의 IP 주소를 반환(DNS round robin).

 

부하분산 장치를 이용한 웹 서버 이중화.

• 부하분산 장치가 이전에 어느 웹 서버에 요청을 할당했는지를 쿠키에 저장한다. 이 쿠키를 읽어서 같은 서버에 요청을 할당한다.
• 이를 통해 세션 상태를 저장할 수 있는데, 부하분산 장치는 임시 대응 관리표로 세션 테이블을 만든다.
• 세션 상태 저장을 실현하는 기능을 부하분산 장치에서는 '퍼시스턴스(persistence, 지속성)'이라고 한다.
  • 소스 IP 주소: 클라이언트 IP 주소를 기반으로 요청을 할당할 웹 서버를 결정.
  • 쿠키: HTTP 헤더 내에 접속한 웹 서버 정보를 저장.
  • URL: URL구조 내에 접속한 웹 서버 정보를 저장.
• 부하분산 장치의 할당 알고리즘
  • 라운드 로빈(round robin): 서버의 IP 주소에 순서대로 요청을 할당.
  • 최소 연결(least connection): 현재 활성 세션 수보다 세션 수가 가장 적은 서버의 IP 주소에 요청을 할당.
  • 응답 시간(response time): 서버의 CPU 사용률이나 응답 시간 등을 고려해서 가장 부하가 적은 서버의 IP 주소에 요청을 할당.

 

7.5 AP 서버 이중화

 

7.5.1 서버 이중화

웹 서버와 같이 부하분산 장치를 이용하거나, AP 서버가 가진 웹 서버 요청 이중화 기능을 이용해서 AP 서버 요청을 분산.

서버 내 이중화, 즉 하나의 AP 서버 내에 복수의 AP 서버가 존재하는 형태로, 복수의 JVM이 하나의 AP 서버에서 동작한다.

 

7.5.2 DB 연결 이중화

AP 서버가 DB 서버에 접속하는 경우의 이중화.

AP 서버에는 DB 서버에 접속 시에 사용할 연결(connection)을 사전에 여러 개 생성해 둔다(연결 풀링, connection pooling).

 

7.6 DB 서버 이중화

 

7.6.1 서버 이중화(액티브-스탠바이)

액티브-스탠바이형의 클러스터(cluster) 구성(HA 구성). 일반적으로 클러스터 소프트웨어로 구현한다.

클러스터의 노드나 서비스 관계는 마스터-슬레이브 개념을 기반으로 한다.
서버가 정상 동작하는지 확인하기 위한 구조로 '하트비트(heartbeat)'나 '투표 장치(voting)' 같은 기능이 존재한다.

액티브-스탠바이 구성은 서비스를 병렬로 실행할 수 없고 데이터 일관성을 중시하는 서비스/시스템에 적합하다.

 

장애 발생시

• 클러스터 소프트웨어는 등록된 서비스가 정상 동작하고 있는지 정기적으로 확인한다. 이상이 발생하면 서비스를 정지하고 대기하고 있던 스탠바이 측 서비스를 시작해서 서비스를 유지시킨다(페일오버).
• 클러스터 소프트웨어는 '하트비트'를 통해 상호 간의 상태를 확인한다. 하트비트를 통해 상태를 인식할 수 없게 되면, 페일 오버 실시 여부를 판단할 수 없다(스플릿 브레인, split-brain).
• 스플릿 브레인 시, 투표 장치에 대한 투표 결과를 가지고 클러스터 소프트웨어가 살아 남을 노드를 선택한다(배타적 제어로 데이터 이중 기록 등의 문제 방지). 투표 장치는 하트비트 기능을 보완한다.

 

7.6.2 서버 이중화(액티브-액티브)

• 쉐어드 에브리씽형(shared everything): Oracle RAC, IBM DB2 puerScale. 디스크, 데이터를 모든 노드가 공유한다. 장애가 발생해도 다른 노드로 쉽게 처리를 계속할 수 있다.
  • 캐시 퓨전(cache fusion): 캐시의 데이터를 네트워크 경유로 받아서 디스크 액세스를 줄이고 데이터 취득을 고속화한다.
• 쉐어드 낫씽형(shared nothing): Oracle MySQLCluster 등. 각 노드별로 디스크를 가지고 잇어서 데이터가 분산된다. 노드를 배치하기 쉽다.

 

7.7 네트워크 장비 이중화

 

7.7.1 L2 스위치 이중화

L2 스위치 A와 L2 스위치 B를 서로 캐스케이드(cascade)해서 패킷이 흐르도록 한다.

최근에는 트렁크 포트를 사용하여 포트를 복수의 VLAN에 소속시켜 사용한다.

 

7.7.2 L3 스위치 이중화

기본적으로 액티브-스탠바이.

L3 스위치는 스위치 기능과 간이 라우터 기능을 동시에 갖추고 있는 장비이다.

L3 스위치의 액티브-스탠바이를 실현하는 프로토콜인 Virtual Router Redundancy Protocol(VRRP)가 있다.

 

VRRP

• 어느 쪽 장비가 기본(마스터 라우터)인지를 정한다.
• 정기적인 하트비트(advertisement)를 보내서 생존 감시를 한다.
• 보조(백업 라우터) 장비가 애드버타이즈먼트를 일정 시간 수신하지 못하면 마스터 라우터 역할을 인계한다.

 

7.7.3 네트워크 토폴로지

L2 스위치와 L2 스위치를 조합하는 구성을 말한다.

복수의 경로가 존재하는 네트워크 구성을 '루프(loop)'라고 하는데, 이는 안정성 측면에서 좋지 않다.

이를 해결하기 위한 수단으로 스패닝 트리 프로토콜(Spanning Tree Protocol, STP)를 사용한다.

STP를 이용하여 논리적으로 포트를 절단(블로킹 포트)할 수 있다.

장애 시에는 STP에 의한 재계산이 이루어지며, 논리적으로 절단돼 있는 포트를 개통해서 통신이 가능해진다.

STP의 단점은 계산에 걸리는 시간인데, 현재는 RSTP(Rapid-STP)가 사용돼서 페일오버 시간은 거의 제로에 가깝다.

 

7.8 사이트 이중화

 

7.8.2 웹사이트 이중화

글로벌 서버 부하분산(GSLB): 화재 등 재해에 대한 대책으로 원격지 데이터 센터와 연계하는 기술.

DNS가 반환하는 IP 주소를 동적으로 변경한다.

원격지에 데이터를 전송할 때 중요한 것은 동기/비동기 여부다.

 

7.9 감시

 

7.9.1 감시란?

시스템 컴포넌트가 정상 동작하는지 확인하는 것.

• 생존 감시
• 로그(에러) 감시
• 성능 감시

 

7.9.2 생존 감시

예) ping 명령을 정기적으로 실행해서 서버 이터페이스에 대한 통신을 확인.

 

7.9.3 로그 감시

OS나 미들웨어가 출력하는 로그 파일에는 시스템 유지를 위한 중요 정보가 포함돼 있다.

로그 내용을 선별해서 중요한 로그 정보이면 감시 서버에 경고 메시지를 보낸다.

 

7.9.4 성능 감시

디스크 사용률, 메모리 사용 현황, 디스크 고갈 등의 리소스 상태 파악

네트워크 액세스 지연, 디스크 액세스 시간 등의 응답 상태 파악.

 

7.9.5 SNMP

SNMP는 네트워크 장비와 서버를 일괄 감시해서 관리할 수 있다.

• 네트워크 장비나 서버 가동 상태
• 서비스 가동 상태
• 시스템 리소스(시스템 성능)
• 네트워크 트래픽

 

7.9.6 콘텐츠 감시

웹 시스템 특유의 감시. 부하분산 장치가 담당한다.

부하분산 장치에 감시 대상 URL을 등록하고, HTTP의 GET 요청을 해서 정상 여부를 판단한다.

 

7.10 백업

 

7.10.1 백업이란?

이중화와 다른 점은 데이터를 복제해서 별도 장소에 보관한다는 점이다.

 

복구 지표를 정해서 백업을 설계한다.

• RTO(Recovery Time Objective): 복구 목표 시간
• RPO(Recovery Point Objective): 복구 기준 시점

 

시스템에서 백업해야 하는 대상.

• 시스템 백업(OS나 미들웨어 등의 백업)
• 데이터 백업(데이터베이스나 사용자 파일)

 

7.10.2 시스템 백업

 

다음과 같은 시점에 실시.

• 초기 구축 후
• 일괄 처리 적용 시
• 대규모 구성 변경 시

 

취득 방법

• OS 명령(tar, dump 등)
• 백업 소프트웨어

 

7.10.3 데이터 백업

시스템 백업과 달리 매일 변경되는 데이터가 손실되지 않도록 하는 것으로, 취득 빈도가 높다.

데이터베이스 백업은 데이터 자체와 데이터 갱신 내역이 기록돼 있는 저널(journal)을 모두 취득하도록 하고 있다.

데이터는 기본적으로 서비스를 정지할 수 변경이 발생하지 않는 상태에서 취득한다.