API 관리 플랫폼의 보안은 어떻게 이루어지나요?
API 호출에 대한 제어를 위해 OAuth, JWT, ODIC와 같은 보안 프레임워크와 연계하여 API 무단 호출을 방지하는 것이 기본적인 보안 방법입니다. 추가적으로 고객사 요건에 따라 SQL Injection 등과 같은 공격에 대비하기 위한 Validation을 추가하거나 호출하는 IP를 기반으로 API 호출을 차단하는 등 기능도 추가할 수도 있습니다.
오픈 이노베이션 관점에서 비즈니스 API 활용 방법은 없을까요?
이미 많은 기업들이 오픈 이노베이션 관점에서 비즈니스 API를 활용하여 새로운 상품이나 비즈니스 모델을 출시하고 있습니다. 빅데이터, AI, IoT 등 최근의 기술들은 클라우드와 같은 인프라 상에서 API를 활용하여 통합되고 있으므로, 이를 도메인 지식과 결합하여 혁신적이고 파괴적인 아이디어들을 실제 구현하는 사례가 국내에서도 많이 확산되고 있는 상황입니다.
API관리 플랫폼을 도입하는데 고려해야 할 점은 무엇인가요?
플랫폼 도입에 있어서 보안, SLA, 라이프사이클 및 버전 관리, consumer portal 등 다양한 기술적 고려 사항이 있습니다.
API가 늘어 남에 따라 일반적으로 전사적 관리가 필요할 것으로 보이는데 어떤 롤의 인원이 주도적으로 관리해야 할까요?
API의 전사적 관리 시에는 API 관리 ownership 및 해당 KPI를 가진 조직과 전담 인원을 배치되는 것이 이상적일 것 같습니다. 개별 고객의 상황에 따라 아키텍트 팀이나 디지털 혁신팀 등의 다양한 조직이 관리 주체가 되고 있는 것으로 보입니다.
API를 병합 할 경우 어떤 task가 수행되어야 하나요?
기본적으로는 consumer에게 제공할 데이터 양식이 결정되어야 하며 따라서 기존의 System API를 어떤 전략으로 aggregation할 것인지가 결정될 것 같고, 한 단계 더 나아가서 민감 정보에 따른 암/복호화 및 마스킹 등과 같은 세부 처리에 대한 결정이 필요합니다. 실제 구현에 있어서는 난이도에 따라 스크립팅과 같은 개발 요건도 포함될 수 있습니다.
Micro Gateway와 API Connect를 구별해 볼 수 있습니까?
Micro Gateway는 주로 마이크로서비스 아키텍처 내에서 가볍고, 개발자 친화적으로 사용하겠다는 목적을 지향하고 있습니다. 사실 광범위하게 사용되는 term은 아니라고 보여지고, 현재의 기술 동향 또한 Micro Gateway와 서비스 메시와 같은 개념의 경계가 사라져가는 경향이 있습니다. IBM에서는 Istio와 같은 서비스 메시에 API Connect를 결합하여 사용하는 아키텍처를 microservice 내의 API Gateway 아키텍처로 제시하고 있습니다.
API 관리 플렛폼을 적용하는데 필요한 사전 항목은 무엇인가요?
사전 항목은 H/W, S/W 적인 부분과 더불어 꽤 많은 항목을 검토해야 합니다. 당연한 얘기겠으나, 대상 (예: 외부/내부/파트너..) 과 목적 (예: 채널 확대/수익 증대 )이 분명해야 세부 사항으로 어떤 API를 가지고 먼저 시작할 수 있는지가 나올 것 같구요. 어떤 목표냐에 따라서 기간과 비용도 고려 사항이 됩니다.
미세먼지 측정과 같은 실시간 API도 지원 가능한가요?
기술적인 spec만 맞는다면 어떠한 API 유형과도 연계가 가능합니다. 최근은 Web API (REST/JSON, SOAP/XML)가 주로 논의의 대상입니다.
클라우드를 이용해서 쿠버네티스로 환경 설정이 수월하게 가능할까요?
IBM 솔루션을 기준으로 말씀드리자면, on/off premise 상의 쿠버네티스 서비스 상에서 API gateway 및 관련 구성 요소를 쉽게 올려서 사용할 수 있도록 제공하고 있습니다. 현재 클라우드 네이티브 app의 활용에 따라 PaaS 서비스의 활용이 확산되면서 이러한 Use case가 더욱 증가할 것으로 보고 있습니다.
API 게이트웨이 전 단계 데브 포털 단계까지 이력관리 및 개발에 참여 가능할 수 있도록 오픈이 가능할까요?
API 관리 내에서는 API의 제공자와 소비자로 대별되는 양 측이 존재하게 됩니다. API의 제공자는 당연히 API를 만드는 개발자이고, 소비자는 그 API를 사용하여 app을 만드는 개발자입니다. 따라서 Developer portal은 소비자로써의 app 개발자가 쉽게 자신이 사용할 API를 찾아서 구독하고, API를 제공하는 개발자와 소통하는 장소입니다. 언급하셨던 이력 관리, 버전 관리는 API 제공자 측에서 수행됩니다.
API 관리 주체가 개발자가 되어야 하나요 아니면 Dev Opt에서 관리되어야 할까요?
API 관리의 주체는 기본적으로는 API 제공자 기관에서 수행하게 됩니다. 개발이든, 운영이든 제공자 기관 내에서 유관 부서와 협의가 가능하고 (보안, IT 인프라, IT 운영, 현업 등), 활성화에 대한 KPI를 가져가는 조직에서 ownership을 가져가는 것이 적절하다고 봅니다.
eAI와 차별점은 무엇이며 누릴 수 있는 이점은 무엇인가요?
기업 내부 통합보다 외부 연계에 focus하는 부분과 소비자 (개발자) 포탈이라는 채널을 통한 socialization, 다양한 프로토콜 처리 및 변환보다는 표준 웹 API 기반 처리라는 점을 차별점으로 볼 수 있습니다.
회사 내에서도 다양한 Application간의 Interface가 구성되어 있습니다. 이 부분을 API를 활용하여 전환하는 것도 의미가 있다고 볼수 있는지요?
API를 활용한 통합은 Open API와 같은 외부 노출과 더불어, 내부 도메인 간 연계에서도 활용되고 있습니다. 특히 내부 app들을 현대화하기 위한 initiative에 있어 마이크로서비스 아키텍처를 도입하는 경우 API 관리 솔루션 및 API Gateway를 통하여 integration을 관리하는 경우가 일반적입니다. 이러한 API 활용의 의미는 보다 신속하고 표준화된 인터페이스를 통하여 쉽게 application 간의 연계 및 제어 구현이 가능하다는 점으로 볼 수 있을 것 같습니다.
API Batch 처리 시 성능을 올릴 수 있는 방법은 무엇일까요?
API Gateway 레벨에서 압축이나 chunk 등의 조정을 하거나 스케줄링 처리를 할 수는 있겠지만, 기본적으로는 백엔드 서비스에서 처리 성능을 고려한 프로그래밍이 선행되어야 합니다.
웨비나에서 언급되었던 Micro service 는 새로운 개념인것 같은데요? 기존에도 이런 개념의 서비스가 있었는지요?
마이크로서비스는 최근 3-4년 정도에 확산되기 시작한 application 아키텍처 스타일입니다. 기존 SOA의 사상하고 유사한 부분이 있습니다만, 신속하게 신 제품을 출시하고 피드백을 통한 지속적인 변경이라는 점에 있어서 재사용성이나 내부 서비스 통합에 초점을 맞췄던 SOA하고는 또 다른 개념입니다.
블록체인 기반의 금융서비스가 확산되려면 API 관리의 주안점을 어디에 두어야 할까요?
블록체인 기반의 서비스가 확산되려면, 기본적으로는 금융 블록체인 내 가입된 피어들이 늘어나서 사용자가 어떤 금융 기관을 사용하더라도 블록체인 기반 서비스를 활용할 수 있도록 해야 합니다. 기존과 유사하게 보안, 응답 시간, 기관별 호출 성공/실패 등은 여전히 주요한 metric이 될 것 같고, 이에 추가하여 여러 가지 변수들이 있겠으나, on/off premise 피어 증가 시 Gateway의 추가, 글로벌 로드 밸런싱 등 환경에 대한 추가 관리 포인트와 더불어 호출된 스마트 계약 실행 대비 블록에 commit된 건의 비교도 필요할 것으로 보입니다.