Chapter 1. 웹서비스에서 인프라의 역할

1.1 웹 서비스 구축에 관련된 인프라 영역 / 1.2 인프라 요건 정의에서 운용까지의 주의점

  애플리케이션 엔지니어가 인프라 영역까지 준비하기엔, 인프라 영역은 대상이 많고 취급 분야가 다양하다. 만들고자 하는 웹 서비스에 따라 결정되는 인프라는 조금씩 다르지만, 일반적인 웹 서비스 구축 시 다루게 되는 작업 과정과 영역, 기술 영역은 아래 표와 같다. 사실 인프라란, 애플리케이션을 처리하는 단계를 칭하는 것이 아닌 계층을 다루는 분야이지만 현업에서는 운용부터 처리단계까지 모두 포함하는 경우가 많다.

  인프라는 시스템을 기반으로 하며, 애플리케이션의 성능을 결정하는 중요한 요소가 된다. 따라서 서비스의 확장성을 염두에 두고 구성을 할 필요가 있다. 인프라를 설계/구축하는 경우 확장성, 다중화, 규모를 미리예상하고 예산을 배정, 작업 과정과 기간을 감안하며 타당한 구성을 만들어가는 능력이 필요하다. 예측한 내용을 바탕으로 닥쳐오는 어려움을 유연하게 헤쳐가며 프로젝트를 진행시킬 수 있어야 하는 것이다. 신규 웹 서비스의 경우, 확정되지 않는 변수가 많은 상태에서 시작되기 때문에 서비스 성장 동태에 따라 형태를 조금씩 변경할 필요가 있다.

 

[인프라 구축 작업 과정]

요건 정의

설계

조달

구축

운용

[웹 시스템 계층 구조]

계층(레이어)	내용
애플리케이션	독자 개발 된 제품 또는 WordPress 등의 오픈소스 애플리케이션
애플리케이션 실행환경	django(Python), Spring Framework(Java) 등의 프로그래밍 언어/실행환경/프레임워크
미들웨어	Apache, NginX, Tomcat, PostgreSQL, MySQL 등의 소프트웨어
OS	Linux, Windows 등의 OS
하드웨어	PowerEdge, Cisco, BIG-IP 등의 서버 기기/네트워크 기기
네트워크	인터넷 접속 회선 등의 네트워크 환경
코로케이션	데이터 센터, 공조, 렉, 전원 등의 물리적인 저장소

  여기서, 코로케이션~하드웨어까지를 제공해주는 클라우드 서비스가 IaaS(Infrastructure as a Service), 코로케이션~애플리케이션 실행환경까지를 제공해주는 서비스가 PaaS(Platform as a Service)이며 각각 대표 서비스로 AWS(Iaas), Google App Engine(PaaS)가 있다.

 

[인프라의 기술요소]

기술 요소	대표적인 제품과 사업자
OS	CentOS, Red Hat, Ubuntu, Windows
서버기기	DELL, HP, Fujitsu
스토리지	EqualLogic, Fusion-io, Amazon S3, Amazon EBS
데이터 센터	Sakura Internet, NIFTY
도메인 취득	onamae.com, muumuu-domain.com, whois.co.kr
DNS	BIND, unbound, Amazon Route53
네트워크 기기	Cisco, Juniper, Allied Telesis
네트워크 기술	Router, Firewall, NAT
SSL 인증서	Versign(Symantec), GeoTrust, CyberTrust

 

1.3 인프라 설계 시의 주의점

  인프라 설계만으로 서비스의 성능과 가용성을 높이는 것은 어렵다. 구체적으로 비용이 비싸지며, 납기 기한이 길어지게 된다. 이를 방지하기 위해서는 서비스를 구성하기 전, 설계 단계 이전에 인프라 컨설팅 후 요건을 구체화할 필요가 있으며 이는 기능적 요건과 비기능적 요건 두 종류로 나누어 설계를 진행하게 된다. 비 기능적 요건은 서비스의 성능이 어느 정도 인가를 말하고, 기능정 요건은 비 기능적 요건을 구현하기 위한 기능과 스펙을 말한다.  인프라 엔지니어의 역량은 "비 기능적 요건을 얼마나 빠짐없이 구체화할 수 있으며, 예산과 기간 및 작업 과정의 제약 속에서 얼마만큼 구현할 수 있는가"를 통해 발휘된다.

 

[기능적 요건-성능을 구현하기 위한 기능과 스펙-의 예시]

• 네트워크는 이중화
• 2048bit 인증서로 동시에 4,000 접속이 가능한 SSL 오프로딩 기능이 있고, VRRP(Virtual router Redundancy Protocol)에 따라 Active-Standby 구성이 가능한 로드밸런서
• 1 Gbps가 48 포트이고 10 Gbps가 2 포트이며 스태킹 구성이 가능한 L2 스위치
• 동시 접속 수 80,000 세션에 대응하며 접속 소스당 사용량 제한이 가능한 방화벽
• 로드밸런서 하위에 웹 서버 4대를 배치
• 내부 네트워크는 외부 통신용과 서버 간의 통신용으로 분할

 

  인프라의 비 기능적 요건 정의의 경우 엔지니어 각자의 노하우에 따라 방향이 달라지지만, 요건의 정의에 누락이 발생하면 이후 큰 걸림돌이 되기 때문에 이 시점에 최대한 빠짐없이 필요한 것을 정의하는 것이 중요하다. (본 도서에서는 일본의 정보처리 추진기구에서 공개한 요구 수준을 가지고 예시를 들었다.) 또한, 인프라를 설계할 때에는 성장 및 철수도 염두하여야 한다. 요건이 과다하면 쓸데없는 투자가 될지 모르고, 반대로 부족하다면 기회 손실이 발생하기 때문에 어느 정도 확장의 가능성을 염두에 두고 설계를 하는 것이 좋다.

 

[비 기능적 요건의 예시]

항목	내용 예
가용성	가동률, 목표 복구 시간, 재해 대책
성능/확장성	성능 목표, 확장성
운용/유지 보수성	운용 시간, 백업, 운용 감시, 정기 보수
이행성	이행 방식의 규정, 이행 스케줄, 설비/데이터
보안	만족해야 하는 가이드라인, 네트워크 레벨 제어, DoS 공격 대책, 정보 유출 대책, 사고 발생 시의 대응
시스템 환경/생태 환경	적합 규격, 기기 설치 규격, 환경관리

 

1.4 RAS 검토하기

  프로젝트를 진행할 때에는 품질과 비용, 납기 세 가지의 균형을 맞추며 리스크와 현실 사이에서 적절한 타협을 할 줄 알아야 한다. 이렇게 구현되는 인프라는 신뢰성을 가져야 하며, 이는 RAS(Reliability:신뢰성, Availability:가용성, Serviceability:유지보수성) 지표를 통해 검토가 가능하다. RAS 검토 시에는 장애 발생 간격(Mean Time Between Failures), 평균 복구 시간(Mean Time To Repair)을 이용하여 가동률을 계산하여 시스템 전체의 신뢰도를 측정하게 된다.

• 가동률 = MTBT / ( MTBF+MTTR)
• MTBF(장애 발생 간격) = 누적 사용 시간 / 고장 횟수
• MTTR(평균 복구 시간) = 누적 수리 시간 / 고장 횟수

 가동률을 높이기 위해서는 ①요소 각각의 가동률을 높이고, ②요소를 조합해 전체의 가동률을 높이며, ③적절한 프로비저닝으로 부하 문제를 피하는 것이 중요하다. 정리하자면, 가동률을 높이기 위해서는 MTBF를 얼마나 긴가(오래 사용하였을 때 고장이 얼마나 나느냐) 또는  MTTR이 얼마나 짧나(고장이 나도 복구가 얼마나 빠르게 되느냐)가 가장 중요하다는 것이다.

  가동률을 높이기 위한 가장 기본적인 방법은 다중화이다. 다중화가 된 시스템의 경우에는 장애 시 복구 시간(MTTR)이 짧아지며 0이 되기도 한다. 이때, 단일 장애 포인트(SPOF, Single Point Of Failure)를 없애지 못한다면 기동 시간 비 고장 비율을 적게(MBTF를 길게)하거나 수리 시간을 짧게(MTTR을 짧게)하는 방향으로 조정하여 인프라를 설계한다.

  다중화를 하게 되면 서비스 제공을 위해 필요한 장비의 최소 대수가 N일 때, 평상시 운영되는 최소 대수가 N+1이 된다. 대부분의 현장에서는 비용 대비 효과를 고려하여 N+2가 필요한 환경이라도 리스크를 감수하고 비용 절약을 목적으로 N+1 구성을 고집하기도 한다. (참고로 해당 구성에서 장애 대응의 범위는, N+1 구성이 N이 된 후 다시 N+1로 복귀하는 것까지이다.)

 

1) 다중화란, 시스템의 어느 구성 요소에서 장애가 발생한 경우 다른 구성 요소가 그 처리르 넘겨 받아 시스템 전체의 가용성을 높이는 것을 말한다. 2) 단일 장애 포인트는 시스템의 구성 요소 중 다중화 되어있지 않은 단일 구성 요소를 말하며 해당 구성 요소에 장애가 발생 하였을 때 처리를 넘겨 받지 못하는 구간을 칭한다.

1. 요소 각각의 가동률을 높게 한다

  - 서버용 부품을 사용한다. 좋은 하드웨어를 사용함으로써 서비스가 오래 기동 된 채 유지되더라도 장애가 자주 발생하지 않도록(MTBF가 길어지도록) 하고, 서버 전용 장소, 데이터 센터에 서버를 설치하여 진동이나 먼지 등에 의한 성능 감소를 줄인다.

  - 부품을 이중화한다. 부품이 동시에 고장 나는 경우가 발생하지 않는 한, 서비스가 중지되지 않음으로 MTBF가 길어질 수 있다. 또한 부품의 고장을 조기에 발견하여 서버가 완전히 정지되기 전 적절히 대응하는 것도 중요하다.

 

2. 요소를 조합해 서비스의 가동률을 높게 한다

  - 요소 각각에 대한 가동률을 높이는 것은 한계가 있기 때문에, 다중화를 통해 가동률을 높일 수 있다. 다중화 구성은 다중화 요소를 모두 이용 가능한 Active-Active 구조와 적절한 조치를 취하기 전에는 사용할 수 없는 Active-StandBy 구조가 있다. 기술적으로는 A-A 구조가 가장 가동률이 높지만 비용 또는 기술적 불가능에 의해 A-S 구조를 사용하여야 한다면 아래 3가지 중 가장 이상적인 방법으로 서비스를 구축한다.

 

Hot StandBy	StandBy 측은 기동 후 즉시 이용 가능한 구성
Warm StandBy	StandBy 측은 기동 후 이용 가능하게 하기 위해 몇 가지 준비가 필요한 구성
Cold StandBy	StandBy 측을 완전히 정지 시켜 두는 구성

3. 적절한 프로비저닝*으로 부하 문제를 피한다 (* : 사용자 수 등을 예측하여 적절히 리소스를 준비하는 것)

  - 부하에 대응하기 위해 서버 등 각 요소의 성능을 향상하는Scale-Up, 서버 등 각 요소의 수를 늘리는 Scale-Out을 적절히 사용한다. Scale-Up의 경우 어느 정도의 규모까지는 성능 향상에 좋은 방법이지만 일정 범위를 넘어서는 순간 비용 대비 효과가 나빠지기 때문에 웹 서버의 경우 Scale-Out이 가능하도록 구축하는 것이 좋다. Scale-Out이 가능하기 위해서는 서버와 최종 사용자가 직접 연결되어 있지 않아야 하며, Scale-Out을 통해 부하 이슈를 피하고자 한다면 해당 구간이 문제가 되는 보틀넥 구간이 맞는지 정확한 확인이 필요하다.

 

1.5 장애 발생 시의 대응 방법

  장애가 발생하면 대응 및 검토해야 하는 것들이 아주 많기 때문에, 장애에 대한 초기 조치 방법, 조치에 소요되는 시간 등을 수립 해 두면 이 원활한 대응에 도움을 준다. 대규모 재해가 발생하는 경우에는 아래와 같은 내용을 미리 검토해 두어 시스템을 준비해 둔다면 서비스 가동률을 높일 수 있다. 이때, 시스템의 성격을 정확히 파악해 두어야 효율성 있는 서비스를 제공할 수 있다.

 

대응범위   - 데이터만이라도 지킬 것인가   - 시스템의 일부만이라도 계속 가동하게 할 것인가   - 시스템을 완전하게 계속 가동하도록 할 것인가 전환방법   - 자동   - 수동