새로운 AAA: API, 인증, 가용성

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

짐작하셨겠지만, 네, 저도 포켓몬 고를 하는 그런 사람들 중 하나입니다. 아니면 요즘 흔히 그렇듯, 포켓몬 고를 하지 못하고 있죠. 문제는 그 때문에 막내도 게임을 못 한다는 겁니다. 알고 보니 저희 둘 다 구글 계정이 아니라 포켓몬 트레이너 클럽(PTC) 계정으로 플레이하고 있는데, 로그인이 되지 않거든요.

이 점은 중요합니다. 우리 둘은 ‘인증’이 되지 않아 로그인해서 게임을 할 수 없는 상황에 답답해하고 있지만, 남편은 Google 계정을 사용하기로 했고, 음, 같은 문제를 겪고 있지 않거든요.

그러다 보니 어떤 앱을 출시하든 모든 기업이 진지하게 받아들여야 할 몇 가지 기술적 문제를 파고들게 되었습니다. 그 핵심은 새로운 AAA, 즉 API, 인증(Authentication), 가용성(Availability)에 있습니다.

흥미롭게도 이 탐구는 제가 Pokémon Go에서 포켓몬 추적에 관한 Forbes 기사를 읽던 중 시작되었습니다. 네, Forbes입니다. 그만큼 큰 화제였죠. 어쨌든 그 기사를 계기로 또 다른 기사들을 연이어 읽게 되었는데, 그중 한 기사에서는 추적 기능이 (적어도 처음에는) 제대로 작동하지 않았던 이유가 게임 업데이트 과정에서 Niantic 서버로 보내는 추적 호출에 API 키가 실수로 누락되었기 때문이라고 추측했습니다.

실제로 그런지는 모르겠지만, 그런 실수라면 API가 작동하지 않는 것도 당연합니다. 하지만 계속 의문이 들었던 건, 제가 PTC 계정으로 로그인해서 플레이할 수 없는데도 왜 Google 계정으로 전환하면 아주 손쉽게 접속할 수 있었느냐는 점입니다.

API와 인증의 연관성

그래서 github를 뒤지고 Pokémon Go API를 샅샅이 살펴보게 됐습니다(저는 Java를 선호하지만 Python도 있으니 마음껏 써 보세요). 그러고 나서야 마침내 ‘아하!’ 하고 깨달았습니다. 그 저장소들에 있는 거의 모든 API 호출이 똑같은 예외를 처리하고 있었거든요. 바로 LoginFailedException입니다.

다시 말해, 근처의 포켓몬을 찾는 간단한 호출조차 LoginFailedException을 일으킬 수 있습니다.

사실 그리 놀라운 일은 아닙니다. 모놀리식 웹 애플리케이션은 흔히 세션을 통해 인증된 사용자를 추적하는데, 이는 대개 애플리케이션이 다른 작업을 수행하기 전에 확인하는 세션 ID나 기타 토큰이 담긴 쿠키를 사용한다는 뜻입니다(계속 읽고 계신 분들을 위해 덧붙이자면, 이를 상태 저장형 아키텍처라고 합니다). API도 크게 다르지 않습니다. 각 API 호출에는 호출하는 애플리케이션(사용자)이 애초에 해당 호출을 수행할 권한이 있는지 확인할 방법이 있어야 하기 때문입니다. 즉, 사용자가 “로그인”되어 있어야 합니다.

현재 API는 이를 위해 API 키를 사용하는 경우가 많습니다. 일반적으로 키를 사용자 프로필과 대조하여 호출이 승인되었는지 확인합니다. 상태 비저장 아키텍처에서는 모든 호출마다 이를 확인합니다. 이렇게 하는 데에는 여러 이유가 있으며, 그중 하나는 호출 속도를 제한할 수 있다는 점입니다. 이는 매우 중요합니다. Apigee의 2016년 API 현황 보고서에 따르면 API의 68%가 할당량 관리(속도 제한, 사용량 측정 등으로도 알려짐)를 활용하고 있었습니다. 이 기술을 구현하려면 먼저 지난 1분/1시간/1일 동안 호출이 몇 번 이루어졌는지 알아야 하므로, 이 정보는 안전한 곳에서 추적해야 합니다. 그래야 사용자가 이를 조작해 애플리케이션이 일정 시간 동안 더 많은 호출을 허용하도록 속일 수 없습니다.

다시 말해, API는 상태와 권한을 확인하고 경우에 따라 호출 속도 제한까지 적용해야 하므로 인증 인프라에 상당한 부담을 줄 수 있습니다. 처리해야 할 작업이 매우 많습니다.

하지만 여전히 전통적인 경우가 많은 우리의 앱 아키텍처 사고방식은 이러한 추가 호출이 용량에 미치는 영향을 고려하지 않습니다. 세션을 ‘새로 고침’하기 위해 주기적으로 수행하는 경우라도, 확인 및 권한 부여를 위한 추가 호출은 인증 인프라에 상당한 부담을 줍니다. 바로 로그인을 지원하는 그 인증 인프라 말입니다. 이는 사용자당 브라우저 연결 제한이 2개에서 8개로 늘어났을 때 겪었던 것과 같은 종류의 부담입니다. 이제 사용자 한 명이 애플리케이션에 액세스하는 데 8배의 리소스를 소비하게 된 것입니다. 마찬가지로 API 호출마다 권한 부여에 의존하는 앱의 용량 요구 사항을 고려할 때는 계산을 통해 개별 사용자가 리소스를 몇 배나 더 소비하게 될지 파악해야 합니다.

그렇게 하지 않으면, 과부하가 걸린 로그인 서비스가 아이들과 그토록 잡고 싶어 하는 피카츄 사이를 가로막게 되어, 결국 화가 난 8살 아이들(그리고 물론 화가 난 로리도)이 생겨납니다.

가용성 확보에 필수적인 ID 및 인증 확장

ID 및 액세스는 핵심 애플리케이션 서비스입니다. 지난 2년간 실시한 애플리케이션 제공 현황 설문조사에서 그 중요성이 커지고 있음을 확인했으며, 자세한 내용을 미리 밝힐 수는 없지만 2017년 데이터에서도 ID 페더레이션과 애플리케이션 액세스 제어 모두 증가세를 보이고 있습니다. 이는 애플리케이션뿐만 아니라 사물 때문이기도 합니다. 더 많은 사물과 사용자, 그리고 API를 사용해 백엔드 애플리케이션과 상호 작용하는 더 많은 앱을 지원하려면 ID 서비스 인프라 전반을 확장해야 할 필요성이 커지고 있습니다.

가용성은 흔히 다운타임만을 기준으로 측정됩니다. 서버가 가동 중이고 정상적으로 작동한다면 가용한 것으로 간주됩니다. 이는 내부에서 외부를 바라보는 관점입니다. 하지만 보안과 마찬가지로, 이러한 측정 방식을 뒤집어 외부에서 내부를 바라봐야 합니다. 용량도 중요하며, 단순히 ‘가동 중’이고 ‘가용한’ 것만으로는 충분하지 않습니다. 서비스를 이용하려는 모든 사람이 서비스를 이용할 수 있도록 ‘가동 중’이고 ‘가용한’ 상태여야 합니다. 즉, python 스크립트가 실행되는 속도만큼 빠르게 확장할 수 있어야 합니다.

이는 또한 API가 제공하는 기능을 실제로 구현하는 다양한 백엔드 서비스 간의 관계를 이해해야 한다는 의미이기도 합니다. ID 및 액세스 서비스는 실제 애플리케이션 자체만큼이나 가용성에 매우 중요합니다. 가용성도 보안과 마찬가지로 가장 취약한 연결 고리에 의해 좌우됩니다. 따라서 ID 서비스가 애플리케이션의 나머지 부분만큼 확장 가능하지 않다면(모델이 API 호출별 인증 방식인 경우에는 그보다 더 뛰어난 확장성이 필요합니다), 내부의 모든 대시보드가 “정상”을 나타내더라도 가용성이 심각한 문제라는 사실을 깨닫게 될 것입니다.

외부에서 보면 말 그대로도, 비유적으로도 ‘빨간불’이 켜진 상태이기 때문입니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물