[DevOps/Kubernetes] 시스템 운용의 기초 지식

시스템은 개발만 하면 끝나는 그런 것이 아니다. 시스템 릴리즈 후에도 리소스 감시나 데이터의 백업, 장애 감시, 복구 대응 등 사용자가 쾌적하게 시스템을 이용할 수 있도록 시스템을 운용해야 한다.

시스템 개발 및 구축은 프로젝트가 발족한 후부터 실제 릴리즈를 향해 가는 작업이 메인이 되지만, 시스템 운용은 실제 릴리즈 이후 시스템이 사용자에게 서비스를 완전히 종료할 때까지 계속되는 작업이다. 시스템을 장기 가동하는 경우 운용의 좋고 나쁨이 시스템의 서비스 레벨을 정한다고 해도 과언이 아니다. 또한 온프레미스 환경과 클라우드 환경에서는 시스템 운용의 개념이나 수행해야 할 작업이 다르다. 

---

가용성 관리

시스템에 있어서 가용성이란 시스템을 계속해서 가동시킬 수 있는 능력을 말한다. 가용성이 높은 시스템을 만들기 위한 대표적인 기술 요소로 다중화가 있다. 시스템의 다중화란 만일 장애가 발생해도 시스템 전체가 정지되지 않도록 하는 기술 요소를 말한다.

콜드 스탠바이 방식

구성이나 설정이 똑같은 서버나 네트워크 기기를 미리 백업 기기로서 마련해 두고, 실제 환경과 가까운 장소에 설치하여 전원을 꺼 둔다.
만일 실제 환경에서 작동하는 기기에 장애가 발생하면 백업 기기에 전원을 넣고, 실제 환경의 기기와 통째로 교체한다. 전원을 꺼 둔 채로 대기시키기 때문에 콜드 스탠바이라고 부른다.
이 방식은 소규모 온프레미스 환경 등에서 자주 채택하는 방식이다. 콜드 스탠바이에서 중요한 것은 실제 환경 기기와 백업 기기는 완전히 똑같이 설정해 둘 필요가 있다는 점이다. 장애가 발생했을 때 기기를 통째로 바꾸기 때문에 OS나 미들웨어의 설정, 애플리케이션의 버전 등이 다르면 올바르게 작동하지 않게 될 우려가 있다. 또한 단일 기기의 교환뿐만 아니라 서버나 네트워크와 같은 시스템을 통째로 교환하는 경우도 있다.

전원을 꺼두는 스탠바이 기기는 장애가 발생하면 액티브 기기와 교체한다.

핫 스탠바이 방식

동일한 구성의 서버를 2대 동시에 가동시키고, 만일 메인 서버에서 장애가 발생했을 때는 대기중인 다른 서버가 대신 처리를 이어받는 구성을 핫 스탠바이라고 한다. 둘 다 가동 중인 상태이므로 데이터의 갱신이 실시간으로 일어난다. 또한 장애 발생 시의 전환 시간도 짧아진다.
장애가 발생한 서버나 네트워크 기기를 시스템에서 자동으로 떼어내고 예비 기기로 전환하는 것을 페일오버(failover)라고 한다. 페일오버에는 액티브 기기의 서버의 IP 주소를 이어받는 것과 서버의 버전 정보를 이어받는 것이 있다.

액티브 기기에서 장애가 발생하면 자동으로 스탠바이 기기로 교체한다.

헬스 체크

장애 시에 신속하게 전환을 하기 위해 액티브 기기에서 장애가 발생한 것을 감지하는 장치를 헬스 체크라고 한다. 이것은 서버가 건강한지 아닌지를 정기적으로 체크하는 것이다. 헬스 체크는 서버에 대해 일정 간격으로 어떤 응답 요청을 보내 응답이 돌아오는지 아닌지로 정상 가동을 판단한다.
헬스 체크의 요청으로는 다음과 같은 것이 있다. 레이어가 높으면 높을수록 정확한 헬스 체크를 할 수 있지만, 그만큼 서버에 대한 부하도 높아진다.

ICMP 감시 (레이어 3)	ping 등의 응답을 확인
포트 감시 (레이어 4)	웹 서비스의 경우는 80번 포트로부터 응답이 있는지 확인
서비스 감시 (레이어 7)	HTTP 통신을 확인하는 경우 특정 페이지가 올바르게 표시되는지 확인

로드 밸런싱 (load balancing)

다중화 구성을 하면 시스템의 가용성은 향상되지만 대기 서버를 이용하지 않고 그저 보유만 해 두는 것은 낭비이다. 시스템의 가용성 향상과 처리 속도 향상을 동시에 수행하는 기술 요소로 부하분산이 있다.
부하분산은 서버의 처리를 여러 기기로 나눔으로써 특정 기기에 부하가 집중되는 것을 막을 수 있다. 부하분산은 웹 애플리케이션 서버와 같이 트래픽이 집중되는 곳에서 주로 이용하고 있다.
로드 밸런싱은 로드 밸런서라는 전용 기기를 사용하여 알고리즘에 기초하여 요청의 처리를 분산시킨다. 요청을 균등하게 할당하는 알고리즘(라운드 로빈)이나 요청의 내용별로 할당처를 정하는 알고리즘 등 다양한 알고리즘이 있다. 부하분산에서는 서버의 헬스 체크를 하여 장애가 있는 서버에는 요청을 할당하지 않기 때문에 시스템의 가용성과 처리 속도가 향상된다.
그런데 로드 밸런서 자신이 단일 장애점(SPOF)이 되어 있기 때문에 이것도 다중화해 두어야 시스템의 가용성을 향상시킬 수 있다. SPOF란 한 장소에 장애가 발생하면 시스템을 이용할 수 없게 되는 부분을 말한다.

로드 밸런서가 장애를 일으키면 시스템 전체를 이용할 수 없게 되므로 주의해야 한다.

주요 메이저 퍼블릭 클라우드에서는 로드 밸런서 기능을 서비스로서 제공하고 있다. 예를 들어 GCP는 'Cloud Load Balancing' 이라는 서비스를 제공하고 있다. Cloud Load Balancing은 여러 지역이나 영역을 걸쳐 부하분산을 함으로써 독립된 고장 영역(Failure zone)에 걸친 다중화를 구현할 수 있다.

---

수용성 (Capacity) 관리

수용성 관리란 시스템이 제공하는 서비스의 수요를 예측, 감시, 평가하고 수요를 만족시키기위해 필요한 최적의 시스템 리소를 제공할 수 있도록 관리하는 것을 말한다. 일반적으로 서비스의 수요에는 변동이 있기 때문에 그에 따라 시스템을 구성하는 서버들의 CPU나 메모리와 같은 리소스와 네트워크 대역 등을 필요할 때 필요한 양만큼만 제공하는 것이 바람직한 시스템이라고 할 수 있다.
지금까지의 온프레미스 환경에서는 시스템을 설계할 때 서비스의 수요를 미리 가늠하여 그에 맞춰 시스템 리소스를 마련해 두는 것이 일반적이었다. 하지만 비지니스 관점에서 서비스의 수요를 정확히 예측하는 것은 상당히 어려운 일이다. 특히 불특정 다수의 사람이 이용하는 컨슈머용 서비스 등은 급격한 부하 증가(스파이크 액세스)가 발생하면 리소스 부족이 원인으로 서비스가 정지되어 버릴 우려가 있다.
클라우드를 사용한 시스템에서는 이용한 리소스의 양과 시간에 따라 요금이 부과되므로 필요한 리소를 시스템의 부하에 따라 동적으로 변경할 수 있다. 예를 들어 서비스 시작 시는 초과 사양으로 리소르를 할당해 두고, 부하를 감시하면서 적정한 리소스로 다운그레이드하거나 급격한 부하 증가를 감지하면 자동으로 시스템 리소스 할당을 증가시킬 수 있다.
또한 시스템을 운용하면 다양한 데이터가 발생하고 축적된다. 이러한 데이터는 프로그램이 종료되어도 스토리지와 같은 기억장치에 저장된다. 이를 영구 데이터라고 하며, 시스템의 가동 시간에 따라 증가 및 변경되어 같다는 특징이 있다. 일반적으로 스토리지의 저장 영역에는 한계가 있으며 장애 등으로 데이터가 소멸될 가능성도 있기 때문에 이러한 영구 데이터를 적절히 관리할 필요가 있다.
영구 데이터의 관리에서 빼놓을 수 없는 것이 데이터의 백업과 복구이다. 시스템에서 다루는 데이터 안에는 기밀 정보도 포함되므로 보안 대책도 세울 필요가 있다. 클라우드의 경우는 장기간의 백업에 적합한 저가의 스토리지 서비스가 제공되므로 이것을 이용한다. 또한 재해에 대비하여 다른 고장 영역(리전)에 보관하는 경우도 있다.
그 다음 로그의 수집이 있다. 시스템 로그나 애플리케이션 로그는 각 서버상에 저장하는 경우도 있지만 분산 환경에서는 전용 로그 수집 서버 또는 로그 집약 서비스를 사용하는 것이 일반적이다. 또한 시스템에 따라서는 사용자 인증 시의 액세스 로그 등이 보안 감시 로그로서 장기 보관이 의무화되는 경우도 있다. Unix 계열 OS의 경우 syslogd라는 데몬을 사용하여 커널이나 애플리케이션의 로그를 관리한다. 로그 수집용 미들웨어로는 Treasure Data가 개발하는 오픈소스의 Fluentd가 유명하다.

www.fluentd.org/

Fluentd | Open Source Data Collector

---

시스템 감시

시스템이 릴리즈된 후는 이용자가 시스템을 쾌적하게 이용할 수 있도록 시스템을 운용해야 한다. 시스템 운용의 큰 목적은 시스템을 안정적으로 가동시키는 것이다. 안정적으로 가동하기 위해서는 먼저 시스템을 구성하는 서버들과 네트워크 기기의 상태를 항시 감시하고 적절히 관리할 필요가 있다.

머신의 활동 감시

시스템을 구성하는 머신이 문제없이 가동되고 있는지 아닌지를 감시하고, 하드웨어 장애나 네트워크 장애 등이 발생하지 않은지를 확인한다. 클라우드를 사용하여 시스템을 구축한 경우는 클라우드 서비스 자체가 정지되지 않았는지를 클라스터의 외부 환경에서 감시할 필요도 있다.

서비스의 가동 감시

서비스가 문제없이 가동되고 있는지를 감시한다. 만일 서비스가 올바르게 가동되고 있지 않은 경우는 로그를 확인하고 프로세스를 재시작하는 등 필요한 대처를 한다.

서버/네트워크의 리소스 감시

수용성 관리를 바탕으로 서버의 CPU, 메로리, 스토리지와 같은 리소스의 사용량이나 네트워크의 대역을 감시하고 병목 현상이 일어날 것 같은 부분이 없는지 확인한다. 또한 일별, 주별 등 단기적인 리소스의 증감뿐만 아니라 중장기적인 관점에서 증감을 감시하고, 시스템 부하에 따라 기기나 회선의 증강을 검토할 필요가 있다.
클라우드 시스템의 경우는 리소스의 사용량에 따라 요금이 정해지므로 사용되지 않고 남아있는 리소스가 없는지를 감시함으로써 운용 코스트를 절감할 수 있다.

잡 감시

업무 시스템은 영업시간 중의 온라인 처리뿐만 아니라 집계 처리, 장표 인쇄 처리 등과 같은 배치 처리등고 병행하여 수행한다. 이 때문에 잡을 적절히 감시하는 것이 필요하다.
보통 이러한 감시는 시스템 감시 전용 툴을 사용하여 수행한다. 감시 툴은 시스템의 감시 대상인 서버나 기기의 상태를 감시하고, 미리 설정한 한계 값을 초과한 경우에 정애진 액션을 실행하는 기능을 갖고 있다. 또한 서버의 상태를 그래프나 맵 등으로 가시화하는 GUI도 제공하며, 시스템 장애 시에 관리자에게 메일을 송신하는 경고 기능도 갖고 있다. 감시 대상인 서버에 에이전트를 설치하여 감시하는 것도 있는가 하면 에이전트 없이 감시 가능한 것도 있다.
클라우드에는 가상 인스턴스나 스토리지 등을 감지하는 전용 서비스가 마련되어 있다. 하지만 이것은 클라우드 서비스 안에서만 감시하는 것이 대부분으로, 온프레미스와 클라우드가 연계하면서 처리하는 경우나 특별한 운용 요구사항이 있는 경우 등에서 별도 운용을 위한 시스템을 구축할 필요가 있다. 이런 경우는 시스템 감시를 위한 SaaS 서비스 등을 이용하면 좋다.

장애 대응

장애 대응이란 오류의 원인을 제거하고 시스템을 정상 상태로 되돌리는 것을 말한다. 서버 감시의 상태 변화에 의해 장애가 감지되는 것이 바람직하지만 엔드 유저의 문의로 장애가 발각되는 경우도 있다.
먼저 일차 대응으로 오류의 원인 및 복구 방법을 알고 있을 때에는 미리 정해진 절차를 밟아 복구 대책을 수행한다. 예를 들어 서비스가 정지된 경우는 재시작을 하거나 장애가 발생한 서버를 전체 구성에서 분리시켜 대체 기기로 교체하는 등의 처리를 말한다. 만일 데이터가 손실된 경우라면 백업이나 저널 파일을 바탕으로 복구할 필요가 있다.

클라우드든 온프레미스든 장애 복구의 절차는 가능한 한 자동화해야 한다.

원인이 불분명한 경우는 원인 조사에 필요한 로그 등을 취득하면서 엔드 유저의 시스템 이용에 영향이 가지 않도록 오류가 발생한 부분을 분리시키는 처리를 한다.
일차 대처가 끝나고 엔트 유저가 시스템을 정상으로 이용할 수 있게 되면 장애가 왜 발생했는지 그 원인을 조사한다. 원인 조사에서는 애플리케이션, 미들웨어, 서버, 네트워크 기기가 출력하는 로그 파일의 해석이 중요하다. 분산 환경에서 인프라 장애가 일어난 경우 단일 노드의 로그만 봐서는 원인을 규명하기가 어렵기 때문에 관련된 노드나 네트워크 기기의 로그도 같이 조사한다. 더욱이 장애 발생 전의 리소스 상황을 분석하는 것도 중요하다.
마지막으로 장애의 발생 원인을 규명했다면 똑같은 장애가 발생하지 않도록 영구 대책을 세운다. 또한 고부하로 인한 리소스 부족이 원인으로 시스템 장애가 발생한 경우는 리소스의 양을 증가시키도록 구성을 검토하고, 리소스의 증감 감시를 강화한다. 시스템 운용 멤버와의 연계 부족 등 휴먼 에러의 경우는 요원 배치나 절차도 포함한 기술 이외의 대책도 세울 필요가 있다. 단, 장애 발생의 빈도나 시스템의 미션 크리티컬 정도에 따라 어느 선까지 영구 대책을 세울지 정할 필요가 있다. 클라우드의 경우 시스템 장애가 발생한다는 것을 전제로 전체 아키텍처를 정해 간다.

---

퍼포먼스 튜닝

서비스가 릴리즈되면 서버의 감시 결과를 바탕으로 퍼포먼스 튜닝을 한다. 퍼포먼스 튜닝이란 시스템의 처리 중 병목이 일어나는 장소를 찾아내고 최적의 작동이 되도록 각종 파라미터를 조정하는 작업을 말한다.
퍼포먼스 튜닝을 할 때 중요한 것은 처리 속도의 계측이다. 처리를 실행하는 시간을 측정함으로써 어디가 병목이 되는지를 판단할 수 있다. 예를 들어 '웹 애플리케이션이 좀처럼 표시되지 않는다'는 경우, 웹 프론트 서버에서 처리에 시간이 걸리고 있는지 아니면 백엔드 층의 DB에서 데이터 검색이 시간이 걸리고 있는지 혹은 네트워크 대역에 여유가 없는지 등을 원인으로 생각할 수 있다. 병목 부분을 조삼으로써 처리에 시간이 걸리는 부분을 특정할 수 있다. 병목 위치를 특정했다면 처리의 지연을 없애기 위해 구체적으로 하드웨어나 리소스를 증강하거나 OS 등의 파라미터의 설정을 변경해서 최적화시킨다.

또한 병목은 인프라 레이어에서 발생하는 경우도 있지만, 애플리케이션 레이어에서 발생하는 경우도 있다. 예를 들어 애플리케이션의 처리로 인해 쓸데없이 요청이 여러 번 올라가는 경우도 있으며, 데이터베이스의 구조로 인해 필요 이상의 처리 시간이 걸리는 경우도 있다. 클라우드의 경우는 여러 개의 서비스를 조합하여 시스템을 구성하기 때문에 이용중인 서비스의 설정을 확인하거나 전체 처리 방식을 재검토한다.