[인프라] 웹서비스 구축과 관련된 인프라 영역

1. 웹서비스에서의 인프라 범위

웹서비스를 운용하기 위해서는 애플리케이션뿐만 아니라 인프라 영역의 준비도 필수적입니다. 애플리케이션 엔지니어가 인프라 영역까지 준비하고 관리하는 것은 너무 힘든일입니다. 이유는 취급하는 대상이 너무 많기 때문입니다. 기후나 주요역까지의 거리와 같은 지리적 제약, 네트워크의 기술적인 문제뿐 아니라 배선과 물리적인 거리 등의 물리적 제약, 그리고 하드웨어의 크기, 전원 용량, OS, 미들웨어 등 취급하는 대상이 너무도 다양합니다.

만들고자 하는 웹 서비스에 따라서 달라지겠지만, 일반적인 웹서비스 구축 시에 코로케이션부터 미들웨어까지의 계층까지 다루게 되기도 합니다.

다음은 웹 시스템(웹 서비스)의 계층 구조를 나타낸 표입니다.

계층(레이어)	내용
애플리케이션	독자 개발 및 Movable Type 등의 제품, WordPress 등의 오픈 소스 애플리케이션
애플리케이션 실행 환경	Ruby on Rails(Ruby), Play Framework(Java), Symfony(PHP), django(Python) 등의 프로그래밍 언어/실행 환경/프레임워크
미들웨어	Apache, nginx, Tomcat, unicorn, PostgreSQL, MySQL 등의 소프트웨어
OS	Linux, Windows 등의 OS
하드웨어	PowerEndge, ProLiant, FortiGate, Cisco, BIG-IP 등의 서버 기기/네트워크 기기
네트워크	인터넷 접속회선 등의 네트워크 환경
코로케이션	데이터 센터, 공조, 랙 전원 등의 물리적인 저장소

작업 과정으로는 인프라 구축을 위한 요건 정의에서부터 운용까지의 단계를 다룹니다.

[요건 정의] → [설계] → [조달] → [구축] → [운용]

2. 웹서비스 구축에 관련된 인프라 기술 요소

인터넷은 수많은 기술과 규격으로 구성되어 있습니다. 따라서 코로케이션부터 미들웨어까지의 계층을 모두 다루기 위해서는 방대한 지식이 필요합니다. 게다가 각각의 계층과 규격을 관리하는 단체도 있기때문에 그 단체에 대해 파악하고 규격을 조정하는 과정을 거쳐야 한다는 것 역시 쉽지 않은 일입니다.

웹 서비스를 위해 필요한 인프라의 기술 요소와 제품의 예는 아래와 같습니다.

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

3. 인프라 기술의 계층 구조

인프라 기술은 계층 구조로 되어 있습니다. 계층화하여 규약(프로토콜)을 만듦으로써 계층간의 결합을 느슨하게 하였기 때문에 교환이 가능한 구조가 됩니다. 예를 들면, 스마트폰으로 웹 사이트를 접속할 때 통신사의 휴대전화망을 경유하든, 가정의 무선 랜을 경유하든 그 방법에 상관없이 브라우저는 똑같이 원하는 사이트에 접근할 수 있습니다. 

클라우드 서비스에 대하여

클라우드 서비스는 이러한 계층 구조를 이용해서 특정 계층까지 패키징하여 제공하고 있습니다.

서버나 네트워크와 같은 인프라 부분을 인터넷 경유로 이용할 수 있는 Infrastructure as a Service(이하 IaaS), 인프라 부분은 크게 신경 쓰지 않고 준비된 개발 환경을 인터넷 경유로 이용할 수 있는 Platform as a Service(이하 PaaS) 등이 있습니다.

앞서 언급한 시스템 스택 중 코로케이션부터 하드웨어까지 제공해주는 것이 IaaS, 코로케이션부터 애플리케이션 실행 환경까지 제공해 주는 것이 PaaS입니다.

애플리케이션

애플리케이션 실행환경

미들웨어

OS

하드웨어

네트워크

코로케이션

IaaS

애플리케이션

애플리케이션 실행환경

미들웨어

OS

하드웨어

네트워크

코로케이션

PaaS

대표적인 IaaS로는 Amazon Web Service(AWS), Google Cloud Platform, Azure 등이 있으며, 대표적인 PaaS로는 Heroku, Google App Engine 등이 있습니다. 최근에는 IaaS와 PaaS를 모두 제공하는 사업자가 증가하고 있습니다. Amazon은 IaaS로 Amazon Elastic Compute Cloud(이하 Amazon EC2)를 제공하면서 Amazon Relational Database Service(이하 Amazon RDS)와 같은 PaaS도 제공하고 있습니다.

Google은 PaaS인 Google App Engine을 오랫동안 제공해 왔지만 2013년부터 Google Compute Engine(이하 GCE)이라고 하는 IaaS를 제공하고 있습니다.

4. 인프라 설계 시의 주의점

시스템의 신뢰성을 종합적으로 고려한 'RAS' 및 'RASIS'라는 지표가 있습니다. 아래는 RAS의 의미입니다. 그리고 RASIS는 이것에 "Integrity : 무결성"과 "Security : 안전성"이 추가됩니다.

Reliability : 신뢰성

Availability : 가용성

Serviceability : 유지 보수성

또한 비슷한 개념으로, 정보 보안에는 'CIA'라는 지표가 있습니다. 이것은 Availability, Integrity에  Confidentiality를 추가한 3요소를 유지하는 것입니다.

RAS를 검토할 때는 아래와 같은 지표를 사용합니다.

 - 가동률

 - 장애 발생 간격(Mean Time Between Failures = MTBF)

 - 평균 복구 시간(Mean Time To Repair = MTTR)

일반적으로 시스템에 발생한 문제를 '장애'라고 합니다. 보통 계획 단계에서의 가동률은 MTBF / (MTBF + MTTR)로 계산하며, MTBF와 MTTR의 계산식은 아래와 같습니다.

가동률 = MTBF / (MTBF + MTTR)

MTBF = 누적 사용 시간 / 고장 횟수

MTTR = 누적 수리 시간 / 고장 횟수

가동률을 높이는 방법

가동률을 높이기 위해서는 ①요소 각각의 가동률을 높이고, ②요소를 조합해 전체의 가동률을 높이며, ③적절한 프로비저닝으로 부하 문제를 피하는 것이 중요합니다.

가동률을 높이기 위해서는 MTBF를 길게 하거나, MTTR을 짧게하는 것이 중요합니다. 그 방법으로는 다중화가 있으며 이에 의해 MTTR이 짧아지기도 하고 '0'이 되기도 합니다. 단일장애포인트(SPOF, Single Point Of Failure)를 없애거나, SPOF가 남아있는 경우에는 MTBF를 길게, MTTR을 짧게 하는 방향으로 조정합니다.

다중화란, 시스템의 어느 구성 요소에서 장애가 발생한 경우에 다른 구성 요소가 그 처리를 넘겨받아 시스템 전체의 가용성을 높이도록 하는 것을 말합니다. 단일 장애 포인트는 시스템의 구성 요소 중 다중화되어 있지 않은 단일 구성 요소를 말합니다.

서비스 제공을 위해 필요한 장비의 최소 대수를 N이라고 하면, 평상시의 최소 대수는 N+1이 됩니다. 이것을 흔히 N+1 구성이라고 합니다. 예를 들어, 웹 서버가 2대는 있어야 일상적인 부하를 견딜 수 있는 경우라면 평상시에 3대 정도는 준비해 둘 필요가 있습니다.

실제로는 N+1 구성에서 이상 발생시 곧바로 추가 여분이 필요한 상황이 되기 때문에, MTTR이 길어질 것이 분명할 때는 N+2 구성을 취해야 할 필요가 있는 경우도 있습니다. 하지만 비용대비 효과를 고려하여 리스크를 감수하고라도 비용을 절약할 목적으로 N+1 구성을 고집하는 경우도 많습니다.

N+1이 N이 된다음 다시 N+1이 될때까지가 '장애 대응'입니다.

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

서버용 부품을 사용하기: 서버용 부품을 사용해 MTBF를 길게 하는 것이 중요합니다. CPU, 메모리, 하드디스크, SSD 등에는 서버용 제품이 따로 있습니다. 전용 장소(데이터 센터)에 서버를 설치하는 것도 효과적입니다. 이렇게 하면 진동이나 먼지 등에 의한 성능 감소를 줄일 수 있으므로 MTBF가 길어집니다.

부품을 이중화하기: 부품을 이중화하면 동시에 고장이 나지 않는 한 서비스가 중지되지 않습니다. 서버의 부품 단위 다중화에는 디스크의 RAID 구성, 전원 장치의 이중화 등이 있습니다.

요소 각각의 가동률 확인하기: 가돌률은 필요한 요소 중에서 가장 가동률이 낮은 요소의 가동률로 결정됩니다. 웹서비스의 경우라면 서버뿐만 아니라 데이터 센터, 인터넷 회선, DNS 등에 대해서도 대략적으로 한번 확인해 두는 것이 좋습니다.

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

요소 각각에 대한 가동률을 높이는 것에는 한계가 있기 때문에 다중화 기술을 이용하여 가동률을 높이는 것이 실력을 발휘할 수 있는 방법입니다. 다중화 구성에는 다중화된 요소를 모두 이용할 수 있는 'Active-Active'와 다중화된 요소 중 한쪽은 이용할 수 없는 'Active-Standby'의 두 종류가 있습니다. 'Active-Standby'는 Standby의 방식에 따라 다시 세 장류로 나뉩니다.

아래는 Active-Standby 다중화 구성의 예입니다.

Hot Standby	Standby 측은 기동 후 즉시 이용 가능한 구성
Warm Standby	Standby 측은 기동 후 이용 가능하게 하기 위해서 나름대로의 준비가 필요한 구성
Cold Standby	Standby 측을 정지시켜 두는 구성

Warm Standby의 사례로는 예전의 PostSQL과 같이 '데이터 파일은 동기화하고 있지만, 이를 이용 가능하도록 하기 위해서는 데이터 리스토어에 대한 처리가 필요한 구성'을 들 수 있습니다.

기술적으로 가능하다면 Active-Active가 가장 가동률이 높아집니다. 데이터를 저장하지 않는 Sateless 방식의 요소라면 Active-Active를 비교적 쉽게 구현할 수 있습니다. 대표적인 예로, 웹 서버에서 로컬 스토리지나 임시 파일 등을 이용하지 않는 경우에는 매우 간단하게 구현할 수 있습니다.

기본적으로는 Active-Active가 가능하도록 최대한 Stateless로 해야합니다. 다만, 데이터베이스 서버나 파일 서버 등 데이터를 저장하는 부분을 Active-Active로 하면 대개는 데이터 정합성 유지를 위해 동기화가 필요하기 때문에 동작이 느려지므로 주의해야 합니다.

3) 적절한 프로비저닝으로 부하 문제를 피한다.

적절한 프로비저닝(Provisioning)으로 부하 문제를 피하는 방법에 대하여 프로비저닝은 사용자 수 등을 예측하여 적절하게 리소스를 준비하는 것을 말합니다. 웹을 사용하지 않는 시스템의 대부분은 사용자 수 등을 미리 예측할 수 있지만, 웹을 사용하는 일반적은 B2C 서비스는 부하를 예측하기가 어렵니다.

특히 최근에는 트위터 등의 소셜 미디어에 의해서 순식간에 확산되고, 잠깐 동안만 주목을 끄는 경우가 많습니다. 이들은 부하가 극단적으로 변하기 때문에 예측에 어려움이 있지만, 예산 안에서의 최대한 대응이 필요합니다.

스케일 업과 스케일 아웃

부하에 대응 하는 방법으로는 스케일 업과 스케일 아웃이라는 것이 있습니다. 스케일 업은 서버 등 각 요소의 성능을 향사시키는 방법이며, 스케일 아웃은 서버 등 각 요소의 수를 늘리는 방법입니다.

어느 정도의 규모까지는 스케일 업이 좋지만, 이는 일정 범위를 넘어서는 순간 비용대비 효과가 나빠집니다. 따라서 웹 서버 등은 스케일 아웃이 가능하도록 하는 것이 일반적입니다. 최근에는 클라우드 기반을 이용함으로써 오토 스케일 등의 자동 스케일링을 설정하는 것이 가능합니다. 그러나 오토 스케일을 사용하더라도 부하의 증가 속도를 스케일링 속도가 따라잡지 못할 수도 있습니다. 스케일링의 시작부터 완료까지는 시간의 지연이 생긴다는 것을 잊지 않아야 합니다.

특정 이슈가 'Yahoo!'와 같은 포털 사이트에서 다루어진 경우라면 1.5~2시간 정도 액세스가 계속되기 때문에 스케일링의 효과가 있지만, TV에서 다루어진 경우에는 등장으로부터 30분 정도, 트위터에서 유명인이 언급한 경우에는 15분정도 만에 가라앉기 때문에 오토 스케일로 대응하는 것은 적절하지 않습니다. 따라서 부하의 증가를 미리 예상하고 있는 경우에는 사전에 대처해 두지 않으면 아무것도 하지 않은 것과 마찬가지가 됩니다.

부하의 관점에서도 최소한으로 준비해 두지 않으면 안 되는 것이 N+1 구성, 조금 더 안심할 수 있는 것은 N+2 구성 입니다. 이는 스케일링의 속도와 여유 용량으로 판단할 수 있습니다. 

스케일 아웃이 가능한 구성에는 구체적으로 두 가지 요소가 있는데, 하나는 기능적으로 스케일 아웃이 가능한 구성입니다. 이때는 서버와 최종 사용자가 직접 연결되어 있어서 처음부터 스케일 아웃을 할 수 없도록 구성해서는 안됩니다. 또 하나는 수를 늘리는 것이지만 사용자 수와 액세스 수에 대해 스케일 팩터가 되어 있는 구성이어야 합니다.

예를 들어 웹서버가 보틀넷이 아닌데도 웹서버를 늘리는 것은 의미가 없습니다.

고장 발생시의 대응 방법

AWS와 같은 Infrastructure as Code 계열(API 등을 이용해 프로그램이나 코드에 따라 인프라를 자동적으로 조정하는 것)의 클라우드 서비스라면 자동화가 되어 있을 경우 15분 정도에 복구가 완료되도록 만들 수 있겠지만, 예상 외의 상황이 발생하여 자동적으로 복구를 할 수 없는 사태가 발생한 경우에는 어떻게 처리할 것인지 잘 검토할 필요가 있습니다.

해결 방법으로는 Heart Beats와 같이 24시간 365일 체제를 가진 모니터링 서비스 사업자에게 위탁하는 것도 검토할 수 있는 부분 중 하나입니다.