What Does It Take to Deliver a Successful API?

현재의 비즈니스 환경은 매우 소비자 주도적입니다. 이러한 상황에서 조직의 최우선 과제는 고객에게 가치를 제공하는 것이며, 가장 중요한 목표는 고객의 업무를 보다 편리하고 효율적으로 개선하는 일입니다. 결국 고객의 업무 효율과 편의를 개선해주는 요소가 “무엇인지”를 파악할 수 있어야 하는데, 여기에는 수많은 시행착오가 따릅니다. 또한 지속적으로 시스템과 기능을 개발하고 이와 관련된 새로운 실험을 반복하여 그 결과물이 실제로 고객에게 유의미한 가치를 제공하는지 확인해야 합니다. 이를 실현하기 위한 노력의 일환으로 조직들은 보다 분산 및 구성이 가능한(compose-able) 엔터프라이즈 아키텍처(enterprise architecture)를 추구하고 있습니다. 이미 익숙한 개념인 마이크로서비스(microservices) 역시 같은 원리로 큰 인기를 끌고 있습니다. 마이크로서비스는 모놀리스(monolith)에 크게 의존하던 전통적인 비즈니스를 훨씬 더 작은 독립적인 단위로 분산시켜 주어, 시스템에 새로운 기능을 보다 빠르게 도입하면서도 시스템의 다른 부분에는 가해지는 영향은 제한할 수 있게 지원합니다. 이렇게 구축된 플랫폼에서는 고객에게 실질적인 가치를 제공하는 것이 “무엇인지”를 과거에 비해 훨씬 빠르고 쉽게 발견할 수 있습니다.

비즈니스의 민첩성과 효율성을 개선해주는 것이 마이크로서비스라면, 마이크로서비스의 가치를 소비자와 고객에게 제공하는 것은 바로 API입니다. API는 고객과 마이크로서비스 사이의 엣지(edge)에 존재하며 둘 사이를 연결함으로써 훌륭한 사용자 경험을 제공할 수 있게 지원합니다. 본 게시물에서는 성공적인 API 시스템을 제공하기 위해 아키텍트(architects), CxO 및 기타 의사결정자들이 고려해야 하는 점에 대해 살펴보겠습니다. 특히 성공적인 API 생태계를 제공하는 데 있어 필수적인 다음과 같은 요소에 대해 다루어 보겠습니다:

• API에 적합한 제공 모델
• API 거버넌스
• API의 컴포저빌리티
• API 보안
• API의 확장
• API의 가용성
• API를 통한 인사이트

전통적인 API 제공 모델 뒤집기

소비자에게 API를 제공하는 조직/엔터프라이즈라면 아래의 API 제공 모델이 익숙하게 느껴질 것입니다:

전통적인 API 제공 모델

전통적인 모델에서는 포털(portal)을 사용하여 API를 설계, 구현 및 문서화하고, 퍼블리싱(publishing)을 통해 게이트웨이(gateway) 및 개발자 포털에 배포했습니다. 이후 API는 애플리케이션 개발자들이 발견하고 사용할 수 있게 됩니다. 지금까지는 이 모델에 문제가 없었지만, 최근에 와서는 고객에게 가치를 제공하는 프로세스의 민첩성을 저해하는 병목의 원인으로 지적 받고 있습니다. 마이크로서비스 제공에 사용되는 프로세스는 이에 비해 훨씬 효율적이고, 자동화가 용이하며, 장애가 발생한 경우 복구하기 쉽습니다. API에도 이와 같은 모델이 도입되어야 하는데, 이를 위해서는 개발 및 배포 프로세스를 위와 같은 상의하달식(top-down) 접근방식에서 하의상달식(bottom-up) 접근방식으로 전환해야 합니다. 이를 도식화하면 다음과 같습니다:

API 제공을 위한 하의상달식 접근방식

코드 배포와 마찬가지로, API에도 처음부터 CI/CD가 가능해야 합니다. API 개발자들도 포털 및 프로덕션 게이트웨이에 배포하기 전, 결과물에 만족할 때까지 API를 구축, 배포 및 테스트할 수 있어야 하고, API 코드에 대한 버전 관리와 SCM(Github, 깃허브)을 통한 관리를 할 수 있어야 합니다. 젠킨스(Jenkins), 트래비스(Travis) CI 등의 빌드 자동화 툴을 사용하여 API를 각각의 환경에 자동 배포할 수 있어야 하며, API에 대해 CI/CD를 지원하고 마치 애플리케이션 소스코드처럼 관리하게 해주는 적합한 툴을 개발자가 초반부터 활용할 수 있어야 합니다.

API 거버넌스

하의상달식 API 제공 모델을 도입할 때 가장 큰 장애물은 API 거버넌스가 부족하다는 문제입니다. API 프로덕트 매니저들은 퍼블리시되는 API에 대한 권한과 거버넌스를 잃게 될 것이라 걱정하는데, 이는 진지한 고민이 필요한 매우 중요한 문제입니다. 조직은 퍼블리시되는 API가 적합한 스탠다드 및 모범관행(best practice)을 준수하고, 적합한 방식으로 보호되도록 할 책임이 있습니다. 그렇지 못할 경우 조직은 부정적인 영향을 피할 수 없을 것입니다. 그렇다면 어떻게 해야 API를 민첩하게 제공하는 동시에 적절한 API 거버넌스를 수행할 수 있을까요?

API 거버넌스는 필수요소로, API를 위한 강력한 라이프사이클 관리 기능을 가진 컨트롤 플레인(control plane)을 통해 제공됩니다.

바로 여기서 API를 위한 우수한 ‘컨트롤 플레인(control plane)’의 역할이 강조될 수 있습니다. API 컨트롤 플레인은 뛰어난 API 라이프사이클 관리 기능을 지원하여 API가 포털에 퍼블리시되고 CI/CD를 통해 상위 환경으로 전달되기 전에 API 프로덕트 매니저들이 API를 검토하고 그 결과물에 동의할 기회를 제공합니다. 이에 반드시 필요한 역량을 몇 가지 언급하자면 컨피겨러블 워크플로우(configurable workflow)를 통해 API의 디자인을 승인할 여지, 모범관행 및 보안에 사용된 스키마(schema)를 검증할 여지 등이 있습니다.

컴포저빌리티(composability)

API는 이질적인 마이크로서비스를 통합해주는, 통일된 인터페이스입니다

API는 더 이상 HTTP(에 국한된) 마이크로서비스를 위한 단순한 인터페이스에 불과하지 않습니다. 모던한 엔터프라이즈 아키텍처는 여러 종류의 마이크로서비스로 구성되어 있습니다. AWS 람다(Lambda) 등과 같이 서버리스(serverless) 기능으로 gRPC 및 웹소켓(WebSockets)에 노출된 마이크로서비스를 개발하는 팀을 조직 내에 꾸릴 수도 있습니다. 하지만 이러한 서비스가 필요한 애플리케이션에는 해당 서비스에 접근할 수 있는, 이해하기 쉽고 통일된(unified) 인터페이스가 제공되어야 합니다. 애플리케이션에는 서비스에 대한 접근권한을 제공하는 단일한 인증 엔드포인트(unique authentication endpoint), 일관된 문서의 단일한 출처가 되는 일관된 인터페이스 등이 필요합니다. 이러한 요소는 API 레이어에 의해 애플리케이션에 주어지는 것이 아닙니다. 다시 말해 API는 여러 서비스에 대한 단순한 대리인(proxy)이 아니라는 이야기입니다. 오히려 여러 마이크로서비스들의 미세한 차이를 해결해주는 단위로, 이들을 노출 가능하고 통일된 인터페이스로 구성(compose)해주어 애플리케이션이 이를 사용할 수 있도록 돕는 역할을 합니다.

API 보안

API의 성공에 힘입어, 다수의 조직이 자사의 비즈니스 역량을 퍼블릭 API의 형태로 노출하기 시작했습니다. 많은 경우 처음에는 사내용으로 API를 사용하다가 외부에서도 사용할 수 있게 확대하고 있습니다. 지난 수 년간 API 도입은 빠르게 증가하고 API는 엄청난 인기를 끌어왔습니다. 자연히 API를 악용하여 민감한 정보를 빼내거나 다른 방식으로 조직에 피해를 끼치려는 세력도 커졌습니다. 따라서 API의 보안에 대해 각별한 주의가 필요하며 API 보안에 높은 우선순위를 부여해야 합니다. API를 처음 배포하는 경우에도 이를 민감한 사안으로 다루어 소 잃고 외양간 고치는 일은 피해야 하겠습니다.

API 보안에 OAuth2.0 기반의 인증 및 권한(authorization)의 형태로만 접근하는 경우가 대부분인데, OAuth2.0가 사실상 API 보안의 스탠다드로 자리잡은 것은 맞지만 API의 보안은 인증 및 권한의 범위를 넘어서는 문제입니다. API 보안은 다음의 세 가지 측면에서 바라볼 수 있습니다:

1. 악성 컨텐츠 및 DOS 공격의 예방
2. 인증 및 권한 승인
3. 이상 탐지를 위한 지속적인 패턴 학습을 통한 보안

API 보안의 3대 요소

악성 컨텐츠 및 DOS 공격

API 요청을 보내는 클라이언트(해커)는 보내는 메시지를 완벽히 제어할 수 있습니다. 이러한 메시지가 여러 레이어의 서비스를 거치게 될 수도 있고, 악성인 경우에는 시스템 깊숙이 피해를 끼칠 수 있습니다. 주입 공격 (SQL injection) 을 위한 메시지나 대량의 서버 자원을 소모하는 용량이 큰 메시지일 수도 있고, XML 폭탄을 포함한 메시지 등도 있습니다. 또한 악성 클라이언트 앱은 수없이 많은 API 요청을 보내 실제 유저를 위한 서버 자원을 고갈시킬 수도 있습니다(DOS 공격). API에 대한 이러한 유형의 공격을 방지하기 위한 대안으로 웹 애플리케이션 방화벽이나 API 게이트웨이가 있습니다. 메시지의 내용을 검사하여 사전 정의된 스키마 또는 규칙(패턴)을 바탕으로 검증함으로써 정의된 범주에 속하는 메시지만 받게 해주거나, 클라이언트 요청 속도를 제한하여 매우 짧은 시간 안에 과도한 양의 메시지가 전송되면 이를 방지하여 잠재적인 DOS 공격으로부터 보호해줍니다.

API 게이트웨이나 웹 애플리케이션 방화벽 모두 이러한 유형의 공격을 막을 수 있는 기술이지만, 전술한 목적을 위해서는 웹 애플리케이션 방화벽이 보다 적합합니다. 일반적으로 API 게이트웨이는 이러한 시스템에서 훨씬 많은 일을 담당하고 있는 반면, 웹 애플리케이션 방화벽은 이러한 보안 영역에 특화되어 있기 때문입니다. 보안은 특수한 솔루션이 필요한 문제이고, 연구와 혁신을 전담하는 자원이 필요한 영역입니다. 새로운 취약성이 발견될 때마다 업데이트를 위한 패치가 출시되는 보안 게이트웨이와 같이 해당 영역에 특화되고 전문화된 시스템이 필요합니다. 알리사 나이트(Alissa Knight)가 쓴 본 게시물을 보면 각 솔루션의 담당 영역이 상세하게 비교되어 있고, 엔터프라이즈 아키텍처에서는 왜 두 가지를 모두 적용하는 것이 좋은지 소개되어 있습니다.

ID 검증 및 권한승인

ID 검증 및 접근 제어는 API 관련 업무를 하는 사람이라면 익숙한 내용일 것입니다. OAuth2.0 액세스 토큰, API 키, 기본 인증(BA, basic authentication) 헤더, 클라이언트 인증서 등 유효한 신원증명(credential)을 바탕으로 API 자원에 접근을 부여하는 등의 방법을 사용할 수 있습니다. 또한 제시된 신원증명이 요청되는 자원에 대한 접근 권한을 보유하고 있는지 확인하는 작업도 수반됩니다. 하지만 신원의 유효성만을 바탕으로 자원에 대한 포괄적인 접근을 허용해서는 안 됩니다. 추가적인 접근이 요청될 때 확인 절차가 이루어지거나 최소한 조건이 설정되어 있는 시스템이 필요합니다. 예를 들어, 온라인 스토어의 경우 유효한 ID와 암호를 입력하는 유저라면 누구나 제품 상세설명을 읽을 수 있어야 합니다. 하지만 그 정보를 업데이트할 권한은 관리자에게만 허용되어야 합니다. 접근권한 통제는 때때로 역할 기반 제어를 능가합니다. 날짜와 시간에 따라(주중 오전 8시에서 오후 5시 사이에만 접근 허용), 또는 요청 쿼터에 따라 접근을 제어하는 시스템도 있습니다.

API 게이트웨이는 이러한 인증 및 권한승인에 특화되어 있습니다. 이러한 요구사항을 표준 명세(specification)나 프로토콜로 추상화하여 클라이언트 애플리케이션이 OAuth2.0 등의 메커니즘을 통해 이와 상호작용할 수 있게 해줍니다. 대부분의 API 게이트웨이 솔루션은 유저 컨텍스트를 다운스트림(백엔드) API로 전달할 수도 있습니다. 이러한 인증 및 권한 승인 기능이 API 게이트웨이 수준에서 끝나기 때문에, 다운스트림 API는 이러한 요청을 하는 유저에 대한 맥락을 알 수 없습니다. 하지만 다운스트림 API도 로직을 실행하기 위해 API에 접근하는 유저의 정보를 알아야 할 때도 있습니다. 따라서 이러한 경우, API 게이트웨이가 하위 API에 유저 컨텍스트를 제공해야 합니다.

이상 탐지용 패턴 식별을 위한 지속적인 학습

유출된 신원은 추적하기가 어렵습니다. 만약 API 키나 액세스 토큰이 유출되었다면, 방화벽이나 ID 검증 레이어만으로 누군가 유출된 신원을 사용하고 있다는 점을 감지할 수는 없습니다. 이러한 연유에서 API 키나 기본 인증 신원증명에 비해 OAuth2.0가 훨씬 안전합니다. OAuth2.0 액세스 토큰은 만료기간이 (비교적) 짧고, 해킹된 경우에도 토큰 만료 시점까지만 사용 가능하기 때문입니다. 유출된 신원 또는 신원의 부적절한 사용을 탐지하려면 유저의 접근 패턴을 관찰해야 합니다. 만약 토큰이 한 국가의 사용자에 의해 사용되었는데, 몇 분 후에 다른 국가에서 다시 사용되었다면 유출되었을 확률이 높기 때문에 시스템이 이러한 시나리오를 탐지하고 의심스러운 세션을 차단하거나 MFA(다중 인증) 등을 통해 추가적인 인증을 요구할 것입니다.

API 게이트웨이만으로 이러한 유형의 공격으로부터 시스템을 보호할 수는 없습니다. API 게이트웨이는 보통 서로 다른 네트워크에 걸쳐 클러스터로 모여 있고, 서로 간에 유저 상태나 접근 이력을 반드시 공유하지는 않기 때문입니다. 하지만 API 게이트웨이를 일종의 머신러닝이나 패턴 분석 솔루션이 포함된 데이터 애널리틱스 솔루션과 함께 사용할 수 있는데, 이러한 시스템은 유저의 접근 이력과 패턴을 추적하고 이상이 탐지되면 API 게이트웨이에 이를 알립니다. 이후 게이트웨이는 유저 요청 검증에 적절한 조치를 취할 수 있습니다.

스케일

API의 자동 확장(auto-scaling)

많은 조직들이 클라우드로 인프라를 이전하고 있습니다. 공짜로 되는 것은 아닙니다. 엔터프라이즈 IT 대부분을 AWS, 구글, 애저 등의 써드파티 IaaS 제공업체에서 운영하는 데에는 상당한 비용이 듭니다. 모든 IaaS 기업은 종량제 과금 방식을 이용합니다. 따라서 서버의 오버 프로비저닝(over-provisioning)은 최소화하는 동시에 시스템 운영에 필요한 최적량의 자원만을 소비할 수 있어야 합니다. 전통적인 엔터프라이즈 IT의 경우, 첨두 부하(peak load)에도 대응할 수 있도록 시스템 자원 계획을 세워야 할 것입니다. 만약 시스템의 평균 부하에 대응하는 데 서버 10개가 필요하다면 안전하게 20개의 서버를 운영할 것입니다. 여기서 사내 인프라를 사용한다면 이것이 문제되지 않지만 써드파티 IaaS 제공업체의 인프라에 의존하면 거의 사용하지 않는 인프라를 위해 비용을 지출하게 됩니다. 이 문제를 해결하려면 수요에 따라 신속하게 API(및 API 게이트웨이)를 확장 및 축소할 수 있어야 합니다. 오토 스케일링(autoscaling)은 클라우드 네이티브(cloud-native)한 엔터프라이즈 아키텍처의 주요 특징 중 하나이기도 하고, 거의 모든 IaaS 제공업체가 오토 스케일링을 위한 수단을 제공합니다. 하지만 오토 스케일링이 효과적으로 이루어지기 위해서는 소프트웨어 역시 빠르게 확장 및 축소가 가능해야 합니다. 소프트웨어 스케일링 시에는 다음과 같은 사항을 고려해야 합니다:

• 부팅 지연
• 여타 시스템에 대한 종속성
• 상태 복제

프로세스 구동에 걸리는 시간이 짧을수록 시스템의 스케일링이 수월합니다. 만약 구동하는데 30초 이상 걸리는 프로세스라면, 해당 프로세스가 정상적으로 운영 가능하기 최소 30초 전에 시스템 스케일링을 시작해야 합니다. 부팅 시간이 긴 만큼 더 일찍 스케일링 과정을 시작해야 하는 것입니다. 또한 단 하나의 프로세스를 대상으로만 스케일링하는 것이 불가능한 경우도 있습니다. API 및 API 게이트웨이가 기능 수행을 위해 다른 지원 프로세스에 의존할 수도 있기 때문입니다. 즉, 이러한 지원 프로세스의 확대/축소 역시 고려해야 한다는 의미입니다. API 및 API 게이트웨이가 독립적일수록 시스템의 스케일링이 쉬워집니다. 만약 API 및 API 게이트웨이가 내/외부적으로 상태를 유지하는 경우라면 API 스케일링 시 시스템의 상태를 복제해야 할 수도 있습니다. 스테이트리스(stateless) 시스템은 스테이트풀(stateful) 시스템에 비해 스케일링이 훨씬 용이합니다. 결론적으로, 부팅이 빠르고 독립적이며 상태가 없는 API가 오토 스케일링 시스템에는 가장 이상적인 것입니다.

가용성

오늘날, 시스템 가용성의 중요성은 절대적으로 높아지고 있습니다. 비즈니스는 더 이상 다운타임으로 인한 영향을 감수할 수 없을 수준에 와있습니다. 따라서 우리의 목표는 API의 100% 가용성이 되어야 하지만, 이는 쉬운 일이 아닙니다. 이 전에 언급한 스케일링 관련된 문제는 해결되었다고 가정하면, 이제는 회복탄력성(resiliency)에 집중해야 할 때입니다. 모두가 강건한 시스템을 구축하는 데 온 힘을 쏟지만, 무엇인가는 언젠가 고장이 날 것이라는 사실을 인정해야 합니다. 따라서 고장 발생 시 어떠한 일이 일어나고, 어떻게 복구할 것이며, API를 위해 어떠한 백업 시스템을 마련하느냐에 대해서 반드시 생각해야 합니다. 스케일에 대한 이전 섹션에서 논의된 모든 요소가 회복탄력적인 시스템 구축에 필요하고, 그 외에도 다름과 같은 고려사항이 있습니다:

• 고장 발생 시 얼마나 빠르게 복구가 가능한지
• 시스템의 높은 가용성(데이터 센터 가용성, 지역 내 가용성 및 IaaS 제공업체 가용성)

시스템의 복구는 생각만큼 간단한 작업이 아닙니다. 그리고 종속성이 많을수록 고장으로부터 시스템을 복구하는 일은 어려워집니다. 이 경우 컨테이너와 쿠버네티스(Kubernetes) 등의 플랫폼이 구원의 손길이 될 수 있습니다. 이러한 플랫폼에는 자동 힐링(auto-healing) 기능이 있어 시스템에 필요한 강건성을 제공합니다. 물론 그 자체로 복잡하고 제약도 있지만, API에 제공하는 강건성과 관리의 편리함을 생각하면 충분히 사용할 가치가 있습니다. 스케일링의 경우와 마찬가지로, API 시스템의 복구에 중요하게 고려되어야 하는 요소에는 API의 부팅 시간, 독립성, 상태의 유/무 등이 있습니다. API가 보다 클라우드 네이티브할수록 고장 시 복구가 간편합니다.

가용성이 높다는 것의 의미는 모두가 잘 알고 있을 것입니다. 쉽게 말하면 시스템에 각 서버, 프로세스, 파일 시스템, 데이터베이스 등을 위한 백업이 존재한다는 것입니다. 데이터센터나 한 지역 전체가 다운된다면 어떠한 일이 벌어질까요? 온프레미스(on-premise) 인프라를 사용한다면 물리적으로 다른 장소에 백업 인프라가 필요합니다. 그리고 API는 두 장소에서 모두 배포되어야 합니다. 이를 위해서는 API 개발자의 업무를 늘리지 않으면서도 여러 데이터센터에서 API를 쉽게 배포할 수 있는 시스템 및 프로세스를 구축해야 합니다. 그리고 이 과정에 최대한 많은 자동화를 적용하여 효율적으로 진행해야 합니다. IaaS 제공업체의 인프라에 의존하는 경우에도 마찬가지입니다. 가용성 영역(zone), 그리고 업무부담을 최소한만 늘리면서 다수의 가용성 영역에 데이터를 쉽게 복제할 수 있는 방법이 무엇인지 생각해보아야 합니다.

최근에는 클라우드 서비스 기업의 가용성에 대한 많은 의문이 제기되어 왔습니다. 만약 IaaS 제공업체의 특정한 서비스에 아주 단시간만이라도 전 세계적으로 장애가 발생한다면 어떻게 될까요? 다른 IaaS 제공업체로 전환할 수 있는 백업을 운영하고 있을 정도로 회복탄력적인 시스템을 구축해 두었나요? 예를 들어, 만약 AWS RDS 서비스에 짧은 시간만이라도 특정한 지역에서 장애가 발생했다면 어떻게 될까요? 전환을 위해 애저에 백업을 운영하시겠습니까? 실제로 다양한 지역의 IaaS 제공 업체에 걸쳐 API를 성공적으로 배포해둔 고객을 본 적도 있는데, 발생 확률이 낮은 문제에 대해 값비싼 비용을 지불하고 있다고 생각할 수 있습니다. 물론 신중한 고려와 설계가 이루어지지 않았다면 그럴 수 있습니다. 여기서 중요한 것은 IaaS 제공업체에 걸쳐 분산되고 확장 가능한 시스템을 구축하고 시스템 부하를 인프라 전체에 걸쳐 분산시키는 것입니다. 이러한 방식으로 사용한만큼만 지불하고 필요할 때에만 확장이 가능한 프로비전을 확보할 수 있습니다.

인사이트

API를 위한 3가지 유형의 인사이트

API는 오늘날 많은 디지털 엔터프라이즈에 있어 경제/매출의 원동력입니다. 이와 같이 API가 어떻게 작동하는지, 무엇이 가능하고 불가능한지를 파악하고 정확한 방향 전환을 위한 양질의 데이터를 확보하는 일은 API를 다룸에 있어 필수적입니다. API 기반의 인사이트는 다음과 같이 3가지 유형으로 구분할 수 있습니다:

• 운영 상의 인사이트
• 오류 진단
• 비즈니스 인사이트

운영 상의 인사이트

모니터링으로도 알려져 있는 운영 상의 인사이트를 확보하는 일은 API의 무결성을 유지하여 비즈니스가 매끄럽게 진행되도록 하는 데 매우 중요합니다. API를 위한 모니터링 시스템은 많은 경우, 문제가 발생하기 전에 관련 정보를 제공해줍니다. 반면 모니터링 시스템이 없으면 문제가 발생하고 나서야 대개 고객이 제기하는 불만을 통해 문제가 생겼다는 사실을 인지하는 경우가 많습니다. 두 말 할 필요도 없이, 발생 이전에 문제를 파악할 수 있다면 이에 대응하는 일도 수월하고 그로 인한 압박도 적을 것입니다. 가장 좋은 점은 이러한 고장이 고객에 미칠 수 있는 영향을 상쇄할 조치를 취할 수 있고, 그 결과 고객은 문제가 있었다는 사실을 절대 알 수 없다는 것입니다.

예를 들어 특정한 서비스/API의 메모리가 부족해지기 시작한 상황을 가정해보겠습니다. 우수한 모니터링 시스템이 있다면 API의 메모리 사용량이 증가하고 있다는 사실을 감지하여 일정한 상한선을 넘으면 경고를 보낼 것입니다. 이로써 시스템 관리자에게는 고객이 이 문제로 인해 불편을 경험하기 전에 이를 예방하기 위한 즉각적인 조치를 취할 여지가 생깁니다. 이러한 상황에서 전형적인 대처 방법은 몇 가지 백업 프로세스를 시작하는 것입니다. 하지만 문제의 근본원인을 파악하지 못했기 때문에 일정 시간이 지나면 백업 프로세스의 메모리도 부족해질 것입니다. 하지만 백업 프로세스가 있기에 문제가 있는 기존의 프로세스를 계속해서 구동하고 백업 프로세스가 고객 요청에 대응하도록 하면서, 근본원인을 밝혀낼 때까지 이를 반복할 수 있습니다. 문제점이 내포된 프로세스를 구동한다 할지라도, 이 문제로 인해 영향을 받은 고객은 단 한 명도 없을 것이고, 이는 비즈니스 관점에서는 대단한 성과라 할 수 있습니다.

오류 진단

사고가 발생한 뒤 운영 상의 모니터링이나 고객 불만을 통해 이를 일단 인지했다면, 다음 수순은 근본원인을 파악하여 해결하는 것입니다. 근본원인 파악에서 오류 진단은 매우 중요한 역할을 합니다. 진단을 위해 데이터에 접근하는 속도, 용이성, 그리고 고장에 대해 수집할 수 있는 데이터의 양 모두가 고려 및 구현되어야 하는 중요한 요소입니다. 사고의 원인을 파악할 때에는 먼저 시스템 로그부터 살펴봅니다. 이와 같이 API 및 서비스로부터 모든 런타임 로그를 수집하고, 쉽고 빠른 검색을 위해 인덱스 작업을 해야 합니다. 또한 특정한 시간대에 발생한 시스템 이벤트의 로그를 확보할 수 있는 역량도 중요합니다. 사고에 대한 로그를 확보했다면, 로그를 분석하는 과정에서 디스크 공간 부족 등의 원인이 밝혀질 수도 있습니다. 하지만 로그는 원인에 대한 힌트만을 제공하고 그 실체를 드러내는 데에는 도움이 되지 않는 경우도 있습니다. 이러한 상황에서는 추가적인 로그, 추적, 메모리 덤프 확보, 네트워크(TCP) 덤프 확보 등의 작업이 필요합니다. 또한 트러블슈팅 과정에서 고객에 대한 영향이 전혀 없거나 최소한만 가해지는 시스템을 구축하기 위해 노력해야 합니다. 이러한 시스템에서는 문제가 있는 노드들을 고객 트래픽을 받지 않거나 소수만을 받는 별도의 클러스터로 격리하여 이에 국한하여 트러블슈팅을 하는 방법도 자주 사용되고 있습니다.

비즈니스 인사이트

앞서 언급했듯이, API는 오늘날 수많은 디지털 엔터프라이즈에 있어 주된 매출 동력입니다. 따라서 API의 사용과 도입을 통해 비즈니스의 성공 및 성장을 평가하려는 움직임은 자연스러운 것이라 할 수 있습니다. 또한 API를 비즈니스 전략의 구심점으로 삼는 것도 충분히 가능한 일입니다. 이를 위해서는 API가 목표한 비즈니스 가치와 성장을 제공할 수 있어야 합니다. 그러려면 API가 비즈니스에 미치는 영향을 측정해야 합니다. 조직의 사업목표 달성과 관련된 API의 모든 데이터를 포착해주는 시스템이 필요합니다. 월별 신규 API 소비자, API로 개발된 신규 앱, 응답시간 개선율, 특정 지역에서의 유저 성장(해당 지역에 대한 마케팅 캠페인 이후) 등의 지표를 평가할 수 있습니다. API는 조직의 디지털 서비스에 대한 진입로와도 같기 때문에 비즈니스 KPI를 위해 활용하고 측정해야 할 유용한 요소입니다.

요약 정리

본 게시물의 요지를 다음과 같이 요약할 수 있습니다:

• 우리의 최우선 과제는 고객에게 가치를 제공하는 것입니다. 마이크로서비스 기반의 아키텍처를 구축하여 보다 빠르게 안정적인 소프트웨어를 제공하여 더 나은 가치를 고객에게 전달할 수 있습니다.
• API는 엔터프라이즈 아키텍처에서 디지털 경험을 구현해주는 가장 핵심적인 레이어입니다.
• 모던 API는 하의상달식으로 개발되어 API 개발자와 CI/CD 프로세스의 중요성이 부각됩니다.
• API 거버넌스는 API가 적절하게 제공되고 적합한 API가 제공되도록 하는 데 중추적인 역할을 합니다.
• API는 구성 가능(composable)해야 합니다. 조직은 이종의 서비스를 API로 구성할 역량을 보유하고 있어야 합니다.
• API 보안의 3대 요소는 컨텐츠 검사, 신원 검증 및 권한승인, 그리고 이상 탐지를 위한 패턴 분석입니다.
• API는 클라우드 네이티브 시대의 요구에 부응하기 위해 확장이 가능해야 합니다.
• 99%의 가용성은 더 이상 유효하지 않습니다. 고객들은 100% 가용성을 요구하고 있습니다.
• API 인사이트는 디지털 엔터프라이즈의 지속가능성과 성장에 필수적입니다.