개발자 / 애플리케이션

“네트워크가 다운되어도 돌아가는” 복원성 좋은 애플리케이션을 위한 최신 레시피

Andrew C. Oliver | InfoWorld 2020.02.24
쿠버네티스, 도커, 마이크로서비스는 이제 새로운 애플리케이션 소프트웨어를 만드는 표준이다. 새로운 애플리케이션에서는 일반적으로 프론트엔드와 모바일 애플리케이션의 백엔드로 가는 요청 계층 사이에 API가 있다. 그러나 그 이후 요청은 백엔드로 가기 위해 10년 전과 다를 바 없이 여러 겹의 두꺼운 방화벽을 거쳐 일종의 애플리케이션 서버와 데이터베이스에 연결된다.
 
ⓒ GettyImagesBank

그런데 아마존발 인터넷 중단이 다시 발생하거나, 다른 원인으로 AWS가 마비되면 어떻게 될까? 전통적인 방법으로 구축된 모바일 앱 또는 인트라넷은 다운되고 400 오류와 500 오류가 발생하게 된다. 네트워크를 통해 스프레드시트 파일을 푸시하는 정도의 작업만 하고 있다면 큰 문제는 되지 않으니 걱정할 필요 없다. 그러나 예를 들어 심장병 환자에게 약을 제공하는 약국이거나 슈퍼볼 선데이에 배달해야 하는 피자 업소 입장에서는 심각한 문제가 아닐 수 없다.

다행히 애플리케이션 복원성과 고가용성 분야에서 여러 변화가 일어나면서 새로운 접근 방법이 나왔고 새로운 혁신도 목전에 두고 있다.
 

복원력 높은 클라이언트 애플리케이션

높은 복원력을 위한 접근 방법 중 하나는 애플리케이션 서버와 데이터베이스를 통째로 모든 위치에 두는 것이며 많은 기업이 실제로 이렇게 하고 있다. 또 다른 방법은 애플리케이션과 모바일 애플리케이션의 복원력을 높이는 것이다. 이 말은 백엔드 데이터베이스나 애플리케이션 서버가 없더라도 애플리케이션이 (서비스 수준을 낮춰서라도) 기능할 수 있어야 한다는 의미다.

예를 들어 CVS나 월그린(Walgreens)과 같은 약국 체인은 고객이 두 곳의 약국에서 나눠 약을 구매하는 경우에도 약물 상호작용이나 과용 위험을 감지할 수 있다. 제대로 설계만 된다면 이런 매장 내 애플리케이션은 네트워크 다운 시에도 실행할 수 있다. “네트워크 다운” 상황에서 특정 약물은 공급할 수 없지만 심장약은 가능하다. 다만 약사는 약물의 작용과 복용에 대해 환자에게 더 구체적인 주의사항을 전달해야 한다.

이를 위해서는 일반적으로 로컬화된 데이터베이스와 백엔드 데이터베이스에 대한 일종의 엣지 동기화 게이트웨이가 필요하다. 그냥 원격 API를 호출할 수는 없으므로 프론트엔드에 로컬 프록시로 원격 API를 구현해야 한다. 이를 적절히 하기 위해서는 먼저 “네트워크 장애” 시나리오를 코딩해야 한다. 생각보다는 쉬울 수 있다. 적어도 초기에는 백엔드에 대한 참조 없이 모바일 앱을 쓸 수 있기 때문이다. 미리 밝히자면, 필자가 일하는 오픈소스 NoSQL 데이터베이스 업체인 카우치베이스(Couchbase)에서도 싱크게이트웨이(Sync Gateway)란 솔루션을 만든다.

모바일 애플리케이션에만 해당하는 이야기가 아니다. 씩(thick) 클라이언트 애플리케이션(예를 들어 자바의 스윙 또는 마이크로소프트의 WPF나 UWP) 역시 이 기법을 사용할 수 있다. 웹과 모바일 디바이스의 엣지에도 여전히 씩 클라이언트는 쓸모가 있다. 즐겨 사용하는 피자 배달 체인점을 생각해 보자. 모든 매장마다 DBA를 둘 수는 없을 것이다(DBA를 겸하는 배달 기사가 있다면 좋겠지만). 웹 앱을 운영하기 위해 파파존스나 피자헛의 모든 매장에 애플리케이션 서버가 필요할까?

물론 장소에 따라 원격 위치에 앱 서버를 둘 수도 있다. 지역의 클라우드 영역이 이러한 경우에 해당한다. 물론 관점에 따라 데이터베이스도 함께 배치해서 복제해야 한다고 주장할 수도 있다. 크루즈선 또는 원격 실험실은 다양한 지연 문제로 인해 애플리케이션 서버나 데이터베이스를 현장에 둘 수 있다. 이것과 똑같은 일반적인 원칙을 적용할 수 있다(단, 로컬 데이터베이스가 있다면 동기화 게이트웨이 대신 WAN 복제를 사용할 수 있다). 또한 클라우드로 직접 연결할 수 없다면 결국 배치 작업을 하게 될 수도 있다.
 

복원력 높은 서버 애플리케이션

필자는 그리 오래되지 않은 과거에 확장성 및 성능 컨설턴트로 일한 적이 있다. 당시 가장 먼저 한 일은 “로컬 호스트”에 대한 모든 원격 호출을 제거하는 것이었다. 이 작업은 천천히 했다. 시간당 300달러 작업을 할 때는 1시간 안에 문제를 해결하지 않도록 주의해야 하기 때문이다. 두 번째 일은 상위 항목에 도달하고 하위 항목(n+1)을 레이지 로드(lazy load)한 모든 쿼리를 전환하는 것이고, 세 번째는 캐시를 고치는 일이었다.

아키텍처가 좀 더 서비스 지향적이고 마이크로서비스 기반으로 바뀌면서 또 다른 문제가 발생했다. 서비스의 사용률이 균일하지 않고 들쭉날쭉하다는 것. 쓰래싱(thrashing)의 원인은 가끔 서버 자체인 경우도 있지만 대부분 데이터베이스에 있다. 또한 공격이 원인인 경우도 있다. 해변에서 공들여 예쁜 모래성을 만들면 몰려들어 부수는 아이들이 항상 있는 것과 마찬가지다. 이를 피하기 위해서는 여러 계층의 보호가 필요하다. 펜스를 치고 해자를 두르고 악어를 풀어놓는다고 생각하면 된다.
또 다른 형태의 쓰래싱은 n+1의 서비스 버전 문제다. 서비스에서 get과 put 작업을 많이 한다면 다수의 개별적인 호출로 이어질 가능성이 높다. 이러한 호출을 수집해야 하는데, 그 역할을 할 클라이언트를 만드는 것은 좋은 생각이지만, 무엇이든(예를 들어 모래성을 실수로 걷어차지 않도록 하는 일) 클라이언트에 의존하는 것은 좋지 않은 생각이다. 

첫 번째 보호책은 메시지 기반의 비동기 반응형 프로그래밍 스타일을 사용하는 것이다. 한 지점에서 다음 지점으로 REST 호출을 하는 대신 큐에 호출을 넣고, 다른 요소들이 이 호출에 “반응”하도록 한다. 기본적으로 상태 변경을 이리저리 돌리는 것이다. 과거의 엔터프라이즈 서비스 버스 접근 방법과 비슷하다.

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.