새로운 AAA: API, 인증 및 가용성
네, 제가 포켓몬 고를 하는 사람 중 하나라는 걸 알아챘을지도 몰라요. 아니면 요즘 자주 그렇듯이 포켓몬 고를 하지 않는 것. 안타까운 점은, 우리 막내가 플레이를 하지 못한다는 뜻이기도 하다는 겁니다. 알고 보니 우리 둘 다 Google 계정이 아니라 포켓몬 트레이너 클럽(PTC) 계정으로 플레이하고 있었고, 그래서 게임에 접속할 수 없었습니다.
그것은 중요한데, 우리 둘 다 "인증"하고 로그인해서 플레이할 수 없다는 사실에 좌절감을 느끼는 반면, 남편은 자신의 Google 계정을 사용하기로 했고, 글쎄요, 남편은 똑같은 문제를 겪지 않고 있습니다.
그래서 저는 모든 회사가 앱을 출시하든 상관없이 실제로 공감할 만한 몇 가지 기술적 우려 사항을 파헤쳐보게 되었습니다. 그러한 우려는 새로운 AAA(API, 인증 및 가용성)와 관련이 있습니다.
흥미롭게도, 이 탐구는 제가 포브스에서 포켓몬 고에서 포켓몬을 추적하는 것에 관한 기사를 읽던 때부터 시작되었습니다. 네, 포브스예요. 그만큼 큰 거죠. 어쨌든 그로 인해 또 다른 기사가 나왔고, 또 다른 기사에서는 추적이 (적어도 초기에는) 망가진 이유가 게임 업데이트로 인해 Niantic 서버로의 추적 호출에서 API 키가 실수로 누락되었기 때문이라는 추측이 나왔습니다.
이것이 사실이든 아니든, 이런 실수는 실제로 API를 손상시킬 것입니다. 하지만 제가 계속 생각한 것은 PTC 계정에 로그인해서 플레이할 수 없다면 Google 계정으로 전환하면 아주 쉽게 플레이할 수 있는 게 왜냐는 것이었습니다 .
API 인증 연결
글쎄요, 그래서 저는 github을 뒤지고 Pokémon Go API를 뒤적거렸습니다(저는 Java를 더 선호하지만, Python 도 있으니까 마음껏 사용하세요). 그러다가 마침내 '아하'라는 생각이 들었습니다. 보시다시피, 해당 저장소의 모든 API 호출은 동일한 예외를 처리합니다. 로그인 실패 예외 .
즉, 근처의 포켓몬을 찾기 위한 간단한 호출조차도 LoginFailedException 이 발생할 수 있습니다.
사실 그다지 놀라운 일은 아닙니다. 모놀리식 웹 애플리케이션은 종종 세션을 통해 인증된 사용자를 추적하는데, 이는 종종 애플리케이션이 다른 작업을 하기 전에 세션 ID나 다른 토큰이 포함된 쿠키를 확인하는 것을 의미합니다(이를 따라가는 사람들을 위해 설명하자면, 이것은 상태 기반 아키텍처입니다). API는 크게 다르지 않습니다. 각 API 호출은 호출 애플리케이션(사용자)이 실제로 호출을 할 권한이 있는지 확인할 방법이 있어야 합니다. 사용자는 "로그인"해야 합니다.
현재 API는 이를 달성하기 위해 API 키를 사용하는 경우가 많습니다. 일반적으로 키는 통화가 승인되었는지 확인하기 위해 사용자 프로필과 대조됩니다. 모든 호출( 무상태 아키텍처에서). 이러한 결정에는 통화 속도 제한 기능을 포함하여 다양한 이유가 있습니다. 이건 정말 큰 일이에요. Apigee의 2016년 API 현황 보고서에 따르면, API의 68%가 할당량 관리(요금 제한, 측정 등이라고도 함)를 활용하고 있습니다. 이러한 기술적 트릭을 수행하려면 먼저 지난 분/시간/일에 얼마나 많은 호출이 이루어졌는지 알아야 하며, 따라서 이를 안전한 곳에 추적해야 합니다(사용자가 이를 조작하여 특정 기간 동안 더 많은 호출을 허용하도록 애플리케이션을 속일 수 없음).
다시 말해, API는 상태와 권한을 검증하고, 잠재적으로 속도 제한을 적용해야 하기 때문에 인증 인프라에 큰 부담이 될 수 있습니다. 정말 많은 작업이죠.
하지만 우리의 여전히 전통적인 앱 아키텍처 사고방식은 이러한 추가 호출이 용량에 미치는 영향을 고려하지 않습니다. 세션을 "새로 고침"하기 위해 주기적으로 수행하더라도 확인 및 승인을 위한 이러한 추가 호출은 인증 인프라에 상당한 부담을 줄 것입니다. 로그인을 지원하는 것과 동일한 인증 인프라입니다. 이는 사용자당 연결 수에 대한 브라우저 제한이 2에서 8로 늘어났을 때 보았던 것과 같은 종류의 스트레스입니다. 이제 한 명의 사용자가 애플리케이션에 액세스하는 데 8배의 리소스를 소비하고 있습니다. 마찬가지로, API 호출별 권한 부여에 의존하는 앱에 필요한 용량을 고려할 때, 개별 사용자가 얼마나 많은 X를 더 소비할지 계산을 해야 합니다.
그렇지 않으면, 화가 난 8살짜리 아이들(그리고 로리스도)이 로그인 서비스에 과부하가 걸려서 자신들이 꼭 잡고 싶어하는 피카츄를 잡을 수 없게 됩니다.
확장 ID 및 가용성을 위한 중요 사항
신원과 액세스는 중요한 앱 서비스 입니다. 지난 2년 동안 진행한 애플리케이션 제공 현황 설문 조사에서 이러한 기능의 중요성이 높아지는 것을 확인했으며, 너무 많은 것을 밝히지는 않겠지만, 2017년 ID 페더레이션과 애플리케이션 액세스 제어에 대한 데이터에서도 이미 증가가 확인되고 있습니다. 앱 때문만은 아닙니다. 사물 때문 이기도 하며, 백엔드 애플리케이션과 상호 작용하기 위해 API를 사용하는 더 많은 사물, 더 많은 사용자, 더 많은 앱을 지원하기 위해 전체 ID 서비스 인프라를 확장해야 할 필요성이 커지고 있기 때문입니다.
가용성은 종종 가동 중지 시간 측정에만 근거합니다. 서버가 정상적으로 작동 중이라면 사용 가능합니다. 안에서 바깥으로 보는 관점이에요. 하지만 보안과 마찬가지로 우리는 그 측정 방식을 바꾸어 외부에서 내부로 볼 필요가 있습니다. 용량이 중요하며, 단순히 "가동 중"이고 "사용 가능"하다는 것만으로는 충분하지 않습니다. 서비스는 그것을 사용하고자 하는 모든 사람이 사용할 수 있도록 "가동"되어야 합니다. 즉, Python 스크립트를 실행하는 한 빠르게 확장할 수 있다는 뜻입니다.
또한 이는 API가 제공하는 기능을 실제로 구현하는 다양한 백엔드 서비스 간의 관계를 이해하는 것을 의미합니다. 가용성을 위해서는 ID 및 액세스 서비스가 실제 애플리케이션 자체만큼 중요합니다. 보안과 마찬가지로 가용성도 가장 약한 부분에 따라 결정됩니다. ID 서비스가 나머지 애플리케이션만큼 확장성이 좋지 않거나(또는 모델이 API 호출 인증인 경우 확장성이 더 좋지 않은 경우) 대시보드가 모두 내부적으로 "녹색"으로 표시되더라도 가용성이 심각한 문제임을 알게 될 것입니다.
왜냐하면 밖에서 보면 우리는 "빨간색"을 보고 있기 때문입니다. 문자적으로나 비유적으로나.