Chapter 4. 인프라 준비의 기초 지식

4.1 인프라를 준비할 때 무엇부터 결정할 것인가?

  인프라를 준비하기 위해서는 개발자로부터 기능적 요건, 액세스 수나 사용자 수 등의 목표수치를 전달받아 관련 행정기관이나 법률 등의 대응과 같은 것들을 고려하며 필요한 요구사항을 정리하는 단계가 꼭 필요하다. 이때, 예산이 매우 적은 경우에는 VPS(Virtual Private Server)와 같은 저렴한 서비스를 이용할 수도 있다. 성능과 관련된 수치는 선정 시기에 직접 사용해보지 않으면 알 수 없기 때문에 시작한 후에라도 유연하게 대응할 수 있는 클라우드를 이용하는 것이 좋다. 최근에는 비용 및 성능의 관점에서 물리적인 서버를 고집할 이유가 거의 없기 때문에 각각의 클라우드 서비스를 잘 비교하여 가장 필요한 서비스를 선택하도록 한다.

 

[IaaS형 클라우드 서비스]

서비스 이름	특징
Amazon Web Services(AWS)	IaaS형 클라우드 서비스의 선두주자 EC 사이트인 Amazon이 모체가 되어 제공하고 있다. 가상 서버 기능을 제공하는 EC2 이외에도 로드밸런서나 데이터베이스 등의 기능을 조합한 서비스를 다수 제공하고 있다. 세계 각지에 데이터 센터가 있다.
Google Cloud Platform(GCP)	검색엔진으로 유명한 Google이 제공하는 클라우드 서비스 가상 서버 기능을 제공하는 GCE 이외에도 AWS와 경쟁하기 위해 다양한 기능을 조합한 서비스를 다수 제공하고 있다. AWS와 비교하여 후발주자이기 때문에 앞으로의 보급에 기대하고 있으며, 세계 각지에 데이터 센터가 있다.

 

4.2 인터넷 회선의 용량 계산 / 4.3 서버 대수의 용량 계산 / 4.4 이용할 클라우드 기반 선정하기

  인프라 설계 및 선정 단계에서는 서비스의 개요나 예상되는 전체 사용자 수, DAU(Daily Active User : 하루 동안 서비스를 이용한 순수 이용자 수), 사용자별 액세스 수, 화면 바뀜과 화면당 액세스 수를 이용하여 각 페이지의 대략적인 데이터량을 추정하고, 이를 바탕으로 인터넷 회선에 필요한 용량을 계산하게 된다. 대략적으로 1Page View당 5초가 걸리는 사이트에 2시간 동안 20,000명이 방문하게 되면, 2시간 동안 80,000Page View가 발생하게 된다. 8만 뷰를 단순히 2시간(7,200초)으로 평균을 내게 되면 매 초당 약 12PV가 발생하게 되는데, 이는 최대 60개의 병렬 작업이 필요한 것으로 계산이 된다. 애플리케이션의 특성, 처리 효율에 따라 서버의 성능이 크게 달라지기는 하지만 일반적인 웹 사이트를 기준으로 CPU가 4개라면 50 병렬 처리가 가능한 것으로 보기 때문에 이 경우, 웹서버를 최소 2대, 또는 다중화로 그 이상을 구축하여야 하는 것이다.

  서버가 처리하여야 하는 병렬의 수가 증가하면, 서버뿐만 아니라 네트워크 기기에 대한 고려도 필요해진다. 클라우드 서비스는 특별히 고려하지 않아도 되거나 고려할 수 없는 환경도 존재하지만, 물리적인 환경이라면 상위 네트워크 기기에서 최대 병렬 수가 정해져 있기 때문에 미리 용량을 파악하여야 한다. 클라우드 서비스를 결정할 때에는 가상 서버 단위의 가용성과 데이터 지속성을 가장 중점으로 검토하여야 한다. 기기 측에 고장이 생겼을 때 이를 사용자가 직접 다른 기기로 이동시켜야 하는지, 서비스 측에서 서비스의 정지가 발생하지 않도록 가상 서버를 다른 기기로 옮겨주는 것인지에 따라 구성이나 운용이 크게 달라지기 때문이다. 또한 클라우드의 경우 OS의 실행 영역에 데이터의 지속성이 없는 경우도 있어 서버를 정지 또는 재기동하였을 경우 데이터가 사라질 수도 있다는 점을 유념해 두어야 한다.

 

4.5 인프라 구축 후 확인해야 하는 것

  인프라 구축이 끝났다면, 서버 구성이 의도대로 되어 있는지, 소프트웨어가 빠짐없이 설치되어 있으며, 설치하고자 했던 버전이 맞는지, 로그인하여 애플리케이션을 디플로이 할 수 있는지, 업데이트를 반영할 수 있는지 확인하여야 한다. 아직까지 서버의 구성을 테스트하는 툴은 없기 때문에 각 서버와 네트워크 기기에 로그인하여 구성도와 비교하며 의도대로 접속이 가능한지 확인한다.

  애플리케이션의 디플로이까지 모두 완료가 되었다면, 성능테스트와 장애 테스트를 진행하여 서비스의 가용성을 확인한다. 성능 테스트에서는 부하를 생성하는 툴과 부하를 확인할 수 있는 툴을 이용하여 예상했던 성능이 나오는지, 서비스의 최대 성능은 어느 정도 인지 확인한다. 일반적으로 부하를 생성하는 툴은 Apache Bench나 JMeter를 이용하게 되는데, 부하를 거는 쪽의 성능이 부족한 경우 적당한 부하를 걸지 못하기 때문에 부하를 생성하는 쪽의 서버도 충분한 성능을 가진 서버로 준비를 해야 한다.

  예상하는 성능이 나오는지에 대한 테스트는 부하량을 조금씩 조절하면서 예상하던 성능이 나오고 있는지, 예상 성능 처리에 이상은 없는지, 예상 성능으로 장시간 가동을 하여도 문제가 없는지 등을 확인하고, 특히 장시간 가동의 경우에는 해당 서비스의 피크타임 시간만큼 지속적으로 부하를 넣어 정상적으로 가동되는지를 확인한다. 최대 성능을 확인할 때에는 부하를 건 이후 오류가 일정 확률 이하로 발생하게 되는 최대 성능을 확인하고, 최대 성능에 근접하거나 조금 넘는 정도에서 시스템이 어떻게 손상되는지, 어느 부분이 보틀넥이 되는지를 검토하여 이후 모니터링/설비투자 포인트를 판단한다.

 

순서를 표기한 구성도의 예시

  장애 테스트의 경우에는 구성도를 그려 각각의 구성요소마다 장애가 발생하였을 경우를 모두 테스트하는 것이 효율적이다. 각 요소를 의도적으로 손상시킨 이후 시스템 동작에 어떤 영향을 주는지, 복구 순서는 예상대로 진행되는지를 확인하고, 백업으로 부터 복구도 예상 순서대로 수행이 가능한지를 점검한다. 

 

4.6 백업

  인프라가 의도대로 구축되어있는지 확인한 이후에는, 적절한 데이터가 적당한 타이밍에 정상적으로 저장되고 있는지 확인하여야 한다. 백업 대상인 데이터의 분류에 문제가 있어 백업에 누락이 발생할 경우 큰 문제가 발생할 수 있으므로 필요한 데이터가 빠짐없이 백업 대상으로 분류되었는지를 확인한다.

 

[백업에 관련해 확인할 내용]

대상 데이터	어느 서버의 어떤 데이터를 저장할 것인가
백업 타이밍	어느 타이밍에 백업을 할 것인가
백업 방법	어떻게 백업을 할 것인가
저장 장소	백업 데이터를 어디에 저장할 것인가
저장 세대의 수	백업 데이터를 몇 세대 동안 저장하고 관리할 것인가

  백업 타이밍이 의도한 것과 다른 경우, 정작 복원하려고 하는 중요한 데이터를 복원하지 못하는 사태가 발생 할 수 있으며, 백업의 방법이 잘못되면 다수의 파일 내용이 백업 처리 중 변경되거나 하는 사태가 발생하여 정합성이 결여된 데이터가 백업될 가능성이 있다. 이럴 경우 복원 자체가 불가능할 수 있으며, 그 경우 실질적으로 백업된 데이터가 없는 것과 마찬가지가 되므로 주의한다. 또한 저장장소가 원본과 같은 서버, 같은 네트워크, 같은 데이터 센터에 있을 경우 발생된 장애의 유형에 따라 백업 데이터를 잃을 수 있으므로 이것 또한 주의한다. 백업의 의미는 원본과 분리되어 있어 원본에 어떤 문제가 생긴 경우 이를 복원할 수 있다는 것이므로, 원본과 밀접하게 연동하고 있는 리플리케이션이나 RAID 등은 백업이라 할 수 없다(StandBy 서버도 마찬가지이다).

  마지막으로 저장 세대의 수는 백업을 몇 세대 까지 관리할 것인가 하는 것이다. 관리하는 백업의 세대수가 많을수록 더 과거의 데이터까지 보관할 수 있지만, 그만큼 데이터의 용량이 비대해 지기 때문에 이 점을 고려하여야 한다.