애플리케이션 복원력이란 무엇인가요?

애플리케이션은 고객 트랜잭션 처리 및 공급망 관리부터 직원 협업 지원 및 실시간 데이터 분석에 이르기까지 현대 비즈니스의 거의 모든 측면을 지원합니다.

이러한 애플리케이션이 실패하면 심각한 영향이 발생할 수 있습니다. 다운타임(애플리케이션이 사용할 수 없거나 제대로 작동하지 않는 기간)은 평판을 손상시키고, 사용자 경험을 저하시키고, 상당한 재정적 손실을 초래할 수 있습니다.

실제로 현재 98%의 조직이 다운타임 비용이 시간당 10만 달러를 초과하고 있으며 1/3은 100만 달러에서 5백만 달러 사이의 손실을 예상하고 있다고 보고합니다.

조직은 복원력 있는 애플리케이션을 설계하고 구현함으로써 이러한 중단 사고를 방지하고 완화할 수 있습니다.

애플리케이션 복원력은 다음의 두 가지 핵심 원칙에 기반합니다.

• 내결함성: 일부 애플리케이션에 장애가 발생해도 애플리케이션이 계속 작동할 수 있는 기능입니다.

• 고가용성: 100%에 가까운 시간 동안 액세스할 수 있고 신뢰할 수 있는 시스템 기능입니다. 

복원력이 뛰어난 애플리케이션은 애플리케이션 아키텍처의 취약점을 줄이고 운영 효율성을 개선하며 예상치 못한 장애가 발생하더라도 일관된 사용자 경험을 보장할 수 있습니다.

복원력이 뛰어난 애플리케이션을 만들고 배포하기 위해 개발자와 IT 팀은 애플리케이션의 라이프사이클 전반에 걸쳐 여러 가지의 툴과 관행을 사용할 수 있습니다.

복원력 있는 애플리케이션의 일반적인 구성 요소는 다음과 같습니다.

• 이중화
• 로드 밸런싱
• 장애 격리
• 관측 가능성
• 자동화
• 우아한 성능 저하
• 확장성

이중화는 중요한 시스템의 백업 버전을 보유하는 것을 의미합니다. 시스템에 장애가 발생하면 백업이 작동하여 시스템이 계속 작동하도록 합니다.

예를 들어, 결제 처리 서비스에는 서로 다른 서버에서 실행되는 서비스의 여러 복사본이 있을 수 있습니다. 한 서버가 작동을 멈추면 다른 서버의 복사본이 자동으로 워크로드를 인계받을 수 있으므로 고객이 문제를 알아차리지 못합니다.

조직은 종종 다음과 같은 주요 영역에 이중화를 구축합니다.

• 데이터베이스: 하나의 시스템에 장애가 발생하더라도 손실되지 않도록 여러 데이터 복사본을 서로 다른 위치에 저장합니다.

• 데이터 센터: 여러 물리적 사이트에 걸쳐 애플리케이션을 호스팅하여 한 위치가 작동을 멈추더라도 운영을 계속할 수 있도록 합니다.

• 클라우드 환경: Amazon Web Services(AWS), Microsoft Azure, IBM® Cloud와 같은 제공업체 또는 리전에 애플리케이션을 배포하여 단일 장애 지점을 제거합니다.

• 네트워크 연결: 여러 인터넷 또는 통신 제공업체를 활용하여 중단 중에도 연결성을 유지합니다.

로드 밸런싱은 애플리케이션 가용성을 최적화하기 위해 네트워크 트래픽을 여러 서버에 효율적으로 분산하는 작업입니다. 개별 구성 요소에 장애가 발생하거나 과부하가 걸리는 경우에도 시스템이 성능과 가용성을 유지할 수 있으므로, 애플리케이션 복원력에 매우 중요합니다.

예를 들어, 한 서버가 응답하지 않는 경우 로드 밸런서가 자동으로 트래픽을 다른 정상 서버로 리디렉션하여 애플리케이션을 온라인 상태로 유지할 수 있습니다.

장애 격리는 분산 시스템 내에 중요한 구성 요소를 격리하여 국부적인 문제가 시스템 전체의 중단으로 이어지는 것을 방지하는 설계 관행입니다.

격리는 마이크로서비스 아키텍처에서 특히 중요합니다. 마이크로서비스 아키텍처에서는 한 서비스의 장애가 제대로 격리되지 않으면 다른 많은 종속성에 빠르게 영향을 미칠 수 있습니다.

서비스 메시는 오류를 격리하는 데 특히 유용합니다. 이러한 인프라 계층은 분산 애플리케이션의 마이크로서비스 간 통신을 관리하는 데 도움이 되며 다음의 기능을 제공합니다.

• 자동 재시도: 일시적 문제(예: 짧은 네트워크 결함)로 인해 요청이 실패하면 메시가 즉시 포기하는 대신 자동으로 다시 시도합니다.

• 회로 차단: 메시는 서비스 상태를 모니터링하고 문제가 있는 서비스에 대한 요청을 일시적으로 중단하여, 시스템 전체의 작동 중단을 방지하는 동시에 복구 시간을 제공합니다.

• 분산 추적: 메시는 서로 다른 서비스 간에 이동하는 요청을 추적하여, 팀이 속도 저하를 발견하고 문제가 발생하는 위치를 정확히 찾아낼 수 있도록 돕습니다.

이러한 기능이 함께 작용하면 한 서비스의 오류가 다른 서비스로 확산되지 않도록 방지할 수 있습니다. 예를 들어, 전자 상거래 사이트에서 제품 추천 엔진에 장애가 발생했다고 가정해 보겠습니다. 서비스 메시는 이 장애를 감지하고, 요청이 손상된 서비스에 도달하지 못하도록 막고, 그에 따라 트래픽을 다시 라우팅할 수 있습니다. 그러면 사용자는 중단 없이 계속 탐색하고 구매할 수 있습니다.

관측 가능성을 통해 팀은 지표(응답 시간과 같은 성능 지표), 로그(오류 또는 충돌과 같은 이벤트 기록), 추적(요청이 시스템을 통과하는 전체 여정)이라는 세 가지 주요 데이터 유형을 사용하여 시스템 상태를 실시간으로 모니터링할 수 있습니다.

팀은 이러한 신호를 캡처하고 분석함으로써 이상 징후를 감지하고 문제를 신속하게 진단하여 다운타임을 줄일 수 있습니다. 예를 들어, 고객이 웹페이지가 느리게 로드된다고 보고하는 경우 관측 가능성 툴은 엔지니어가 지연을 일으킨 서비스에 대한 요청을 추적하여 더 많은 사용자에게 영향을 미치기 전에 문제를 해결하도록 도울 수 있습니다.

자동화는 시스템이 수동 개입 없이도 문제에 대응할 수 있도록 함으로써 애플리케이션 복원력에 중요한 역할을 합니다.

예를 들어, 관측 가능성 툴은 문제를 감지하고 이중화는 백업 리소스를 제공합니다. 자동화는 이러한 기능을 연결하여 복구 프로세스를 조율합니다. 자동화는 복구 시간을 크게 줄여 몇 시간이 소요되던 수동 문제 해결을 몇 초의 자동 응답으로 전환할 수 있습니다.

애플리케이션 복원력의 몇 가지 주요 자동화된 대응은 다음과 같습니다.

• 스크립트화된 장애 조치: 장애가 발생한 시스템의 작업을 이중화 계획을 통해 식별된 백업 시스템으로 자동 전송하는 미리 결정된 작업 시퀀스입니다. 예를 들어, 기본 데이터베이스가 갑자기 작동을 멈추면 시스템은 백업 데이터베이스로 자동 전환하고 몇 초 내에 모든 트래픽을 해당 데이터베이스로 리디렉션합니다.

• 리소스 재프로비저닝: 구성 요소에 장애가 발생하면 새 인스턴스를 자동으로 프로비저닝하거나 리소스를 재할당합니다(예: 인력 개입 없이 새 가상 머신을 생성하여 손상된 가상 머신 교체).

• 자가 치료 워크플로: 모니터링 알림과 복구 작업을 조정하여 사람의 개입 없이 서비스를 복구합니다. 예를 들어, 앱이 너무 많은 메모리를 사용하기 시작하면 사용자가 속도 저하를 느끼기 전에 시스템이 자동으로 앱을 다시 시작합니다.

컨테이너화된 애플리케이션을 관리하기 위한 오픈 소스 시스템인 Kubernetes와 같은 툴은 자동화를 통해 복원력 구성 요소를 서로 연결하는 방식을 보여줍니다. Kubernetes는 기본 제공되는 상태 검사를 통해 장애를 감지하고, 정상 노드 전반에서 워크로드 일정을 조정하고, 자동화된 워크플로를 통해 서비스 연속성을 유지할 수 있습니다.

우아한 성능 저하(graceful degradation)란 스트레스가 발생하는 동안 핵심 기능은 유지하고 불필요한 기능을 제거하는 작업을 말합니다. 예를 들어, 블랙 프라이데이 트래픽이 급증하는 동안 소매업체는 장바구니와 결제 기능을 유지하기 위해 고객 후기 및 위시리스트를 일시적으로 비활성화할 수 있습니다.

확장가능한 애플리케이션은 워크로드 수요에 따라 리소스를 자동으로 조정할 수 있습니다. 이 기능은 트래픽이 변동하는 경우에도 성능과 가용성을 보장하는 데 도움이 됩니다.

확장성은 다양한 방법으로 달성할 수 있습니다. 예를 들어, 클라우드 기반 플랫폼은 내장된 로드 밸런서, 자동 확장, 다중 지역 복제와 같은 기능을 통해 확장성을 제공합니다. 즉, 여러 지리적 위치에 걸쳐 데이터와 서비스를 복사하여 성능과 안정성을 개선합니다. 이러한 기능은 서비스가 트래픽을 지능적으로 분산하고, 가동 시간을 유지하고, 변화하는 상황에 대응하여 복구 시간을 최소화할 수 있습니다.

예를 들어, 클라우드 호스팅 스트리밍 플랫폼은 일반적으로 100개의 서버에서 작동할 수 있습니다. 하지만 라이브 글로벌 이벤트 중에는 여러 지역에 걸쳐 10,000개의 서버로 자동 확장되어 수백만 명의 동시 시청자에게 원활한 재생을 제공할 수 있습니다.

소프트웨어 애플리케이션이 비즈니스 운영과 소비자의 일상 생활 모두에 필수적인 요소로 자리잡으면서 이러한 애플리케이션은 예상치 못한 중단을 견디고 거의 모든 조건에서 기능을 유지하는 것이 매우 중요합니다.

특히 다음의 네 가지 요인으로 인해 애플리케이션 복원력이 더욱 주목받고 있습니다.

• 높은 소비자 기대치
• 다운타임 비용
• 아키텍처 복잡성
• 규제 압력

고객은 디지털 서비스가 항상 작동하기를 기대합니다. Google에 따르면 방문자의 53%는 로드하는 데 3초 이상 걸리는 모바일 페이지를 포기합니다.

뱅킹 앱, 전자 상거래 플랫폼, 의료 포털 등에서 다운타임은 고객 이탈, 소셜 미디어 반발, 지속적인 브랜드 손상을 유발할 수 있습니다. 애플리케이션 가용성은 기술적 지표가 아닌 기본적인 비즈니스 요구 사항입니다.

애플리케이션 중단은 모든 규모의 조직에 비용을 초래할 수 있습니다. 소매 브랜드가 트래픽이 많은 판매 이벤트를 시작했지만, 추가 수요로 인해 결제 서비스에 장애가 발생하는 일반적인 시나리오를 생각해 보세요. 몇 분 안에 수천 건의 트랜잭션이 중단되고, 고객은 좌절감을 느끼고, 회사는 수익을 잃습니다.

매출 손실 외에도 중단은 문제 해결 비용 및 서비스 수준 계약(SLA) 위반부터 규제 위반, 고객 보상, 장기적인 브랜드 손상에 이르기까지 수많은 2차 비용을 초래할 수 있습니다.

최근 세간의 이목을 끈 여러 인시던트는 그 영향이 얼마나 중대한지를 잘 보여줍니다.

• 교통: 2016년 데이터 센터 중단으로 2,000편의 항공편이 중단되었으며, 한 주요 항공사는 1억 5천만 달러의 손실을 입었다고 보고했습니다.

• 전자 상거래: 2018년 성수기 세일 기간에 기술적 장애로 인해 온라인 소매업체는 7,200만~9,900만 달러의 수익 손실을 입었습니다.

• 소셜 미디어: 2021년 한 인터넷 대기업은 6시간의 서비스 중단으로 약 1억 달러의 광고 수익 손실을 입었습니다.
  

최신 애플리케이션 아키텍처에는 마이크로서비스, 멀티클라우드 환경, 코드 라이브러리 등 많은 움직이는 요소들이 있습니다. 이러한 모듈식 구성 요소는 확장성을 향상시키는 동시에 잠재적인 실패 지점의 수도 증가시킵니다.  

복원력 있는 설계 및 구현이 없으면 사소한 문제도 증폭될 수 있습니다. 단일 마이크로서비스 장애는 수십 개의 종속성에 영향을 미칠 수 있습니다. 예를 들어, 제품 정보를 저장하는 데이터베이스 서비스가 작동을 멈추면 검색, 추천 또는 결제와 같은 다른 기능이 중단될 수 있습니다.

또한 클라우드 지역 간의 네트워크 중단이 발생하면 서비스가 파편화되고 데이터 불일치가 발생할 수 있습니다. 구성 요소가 완전히 작동을 멈추는 마이크로서비스 장애와 달리, 이러한 연결 문제는 애플리케이션의 다른 부분이 계속 실행되지만 서로 통신할 수 없는 '분할 뇌' 시나리오를 생성합니다.

예를 들어, 금융 거래 앱의 주문 시스템이 실시간 가격 데이터와 연결이 끊어지면 사용자에게 잘못된 견적이 표시되거나 거래가 실패할 수 있습니다.

애플리케이션 프로그래밍 인터페이스(API) 중단이 발생하면 중요한 기능이 손상될 수 있습니다. 마이크로서비스 장애는 조직이 제어하는 내부 구성 요소에 영향을 미치는 반면, API 중단은 애플리케이션이 의존하지만 직접 수정할 수는 없는 타사 서비스와 관련이 있습니다. 예를 들어, 배달 앱의 매핑 서비스가 중단되면 핵심 애플리케이션이 계속 실행되더라도 사용자는 운전자를 추적할 수 없고 운전자는 경로를 찾을 수 없어 경험이 중단됩니다.

특정 부문 및 위치에서 규제 기관은 데이터 가용성, 앱 복구 기능, 데이터 손실 완화, 가동 시간에 대한 엄격한 요구 사항을 설정했습니다. 이러한 요구 사항은 애플리케이션 복원력을 기술적 목표에서 규정 준수 문제로 격상시킵니다.

일부 데이터 보호 및 개인정보 보호 법에는 이제 보안 의무와 함께 가용성 표준이 포함됩니다. 예를 들어, 일반 데이터 보호 규정 (GDPR)은 개인 데이터를 보호하고 액세스 가능한 상태로 유지하도록 요구합니다. 시스템 장애 발생 시 조직은 손실된 데이터를 복구해야 합니다.

특히 규제가 심한 산업은 가장 엄격한 표준에 직면해 있습니다. 

사베인즈-옥슬리(SOX) 법이 재해 복구 계획을 명시적으로 의무화하고 있지는 않지만, 많은 조직들이 이 법을 준수하고 규정 준수를 입증하는 데 도움이 되는 백업 시스템과 공식적인 복구 절차를 유지 관리하고 있습니다.

또한 금융 기관은 비즈니스 연속성 계획 및 복구 시간 목표에 대한 자세한 지침을 제공하는 연방 금융기관 심사위원회(FFIEC)와 같은 기관의 분야별 규정 및 권장 사항을 준수해야 합니다.

건강 보험 양도 및 책임에 관한 법률(HIPAA)에 따라 적용 대상 기관은 전자 보호 건강 정보(ePHI)의 가용성과 무결성을 보장하기 위해 관리적, 물리적, 기술적 보호 장치를 구현해야 합니다. HIPAA는 연중무휴 24시간 액세스를 의무화하지는 않지만, 의료 기관은 치료를 위해 필요한 경우 환자 데이터에 대한 액세스를 유지해야 합니다.

HIPAA 보안 규칙은 데이터 백업 계획, 재해 복구 절차, 긴급 모드 운영을 요구하기 때문에 많은 조직이 고급 장애 조치 및 데이터 복제 전략에 투자하고 있습니다.

시스템이 실제 장애에 견딜 수 있도록 조직은 지속적인 측정과 사전 예방적 테스트를 함께 사용하여 애플리케이션 복원력을 검증합니다. 이러한 접근 방식 통해 팀은 성능을 모니터링하고, 취약점을 식별하고, 애플리케이션이 빠르고 효과적으로 복구될 수 있는지 확인할 수 있습니다.

특히 DevOps 팀은 복원력 관행을 지속적 통합/지속적 전달 파이프라인(CI/CD 파이프라인)에 자주 통합합니다. 이를 통해 장애 조치 절차 테스트를 자동화하고, 구성 변경 사항을 검증하고, 불안정한 배포를 롤백하여 문제를 조기에 포착하고, 중단이 사용자에게 영향을 미치는 것을 방지할 수 있습니다.

조직은 애플리케이션 복원력 평가를 위해 다음과 같은 몇 가지 주요 지표를 사용합니다. 

보다 현실적인 관점을 확보하기 위해 테스트를 활용하는 조직이 점점 늘어나고 있습니다. 지표가 기반을 제공할 수 있는 경우 조직은 테스트를 통해 이론적 준비 상태에서 입증된 복원력으로 전환할 수 있습니다. 

인공 지능(AI)과 머신 러닝(ML)은 복원력에 대한 조직의 접근 방식을 바꾸고 있습니다. 이러한 기술들은 다운타임 방지하기 위한 새롭고 강력한 툴을 제공하지만, 고유한 문제도 수반합니다.

가장 큰 문제 중 하나는 AI 워크로드가 리소스를 많이 사용한다는 점입니다. 많은 모델은 그래픽 처리 장치(GPU)에 의존하는데, 이는 비용이 많이 들고 클라우드 리전 전체에서 복제하기 어렵습니다. 이로 인해 복원력의 필수 요소인 이중화를 달성하기가 더 어려워집니다.

AI 시스템은 예상치 못한 방식으로 실패할 수도 있습니다. 시간이 지남에 따라 정확도가 떨어질 수 있는데, 이는 모델 드리프트라고 하는 문제입니다. 또는 시스템을 속이도록 설계된 악성 데이터인 적대적 입력을 접할 수도 있습니다. 이러한 유형의 장애는 예측 및 격리하기가 더 어려울 수 있습니다.

또한 리소스 제약이나 지연 시간으로 인해 클라우드 환경에서 흔히 발생하는 AI 기능의 속도 저하 또는 작동 중지 문제가 발생해도 나머지 애플리케이션은 여전히 안정적으로 작동해야 하므로 우아한 성능 저하 전략에 대한 압박이 가중됩니다.

동시에 AI는 복원력 강화에 대한 중요한 사용 사례도 있습니다.

• 예측 분석은 과거 패턴과 추세를 분석하여 미래의 실패를 예측합니다. 이를 통해 팀은 온도 및 오류율 추세를 기반으로 며칠 전에 디스크 오류를 예측하는 등 문제가 발생하기 전에 하드웨어를 사전에 교체하거나 리소스를 조정할 수 있습니다.

• 지능형 문제 해결은 AI를 사용하여 보다 현명한 복구 결정을 내립니다. 기존의 자동화 시스템은 단순히 장애가 발생한 서비스를 다시 시작할 수 있지만, AI 기반 문제 해결은 패턴을 분석하여, 부하가 적은 지역으로 트래픽을 다시 라우팅하거나 예측된 수요에 따라 리소스를 확장하는 등 최적의 복구 전략을 선택할 수 있습니다.

• 이상 징후 탐지를 통해 AI는 규칙 기반 모니터링이 놓칠 수 있는 미묘한 실시간 이상 징후(예: 개별 지표가 정상으로 보일 때에도 새로운 문제를 표시하는 비정상적 지표 조합)를 식별할 수 있습니다.

• AI 기반 테스트를 통해 DevOps 팀은 AI를 사용하여 소프트웨어 개발 프로세스 초기 단계에서 더 복잡한 오류 시나리오를 시뮬레이션할 수 있습니다.

요컨대, AI는 새로운 복잡성을 야기하지만, 클라우드 네이티브 환경과 DevOps 파이프라인에 통합되는 경우에는 더 빠른 복구, 더 지능적인 모니터링, 그리고 전반적으로 더 복원력 있는 애플리케이션을 구현할 수 있습니다.