[논문]안정적인 API 게이트웨이를 위한 스트림 기반 API 조합

조동일

doi:10.7472/jksii.2024.25.1.1

안정적인 API 게이트웨이를 위한 스트림 기반 API 조합
Stream-based API composition for stable API Gateway 원문보기

Journal of Internet Computing and Services = 인터넷정보학회논문지, v.25 no.1, 2024년, pp.1 - 8

조동일 (Division of R&D, TOMATOSYSTEM)

초록
AI-Helper

API 게이트웨이에서 API 조합은 클라이언트의 호출 횟수를 줄이고 오버페칭과 언더페칭을 방지할 수 있는 필수적인 기능이다. IMJ(In-Memory Join)로 동작하는 API 조합은 많은 자원을 소모하여 API 게이트웨이의 성능에 부담을 준다. 본 연구에서는 IMJ 방식의 API 조합의 문제를 개선하기 위해 조합할 데이터를 스트리밍으로 클라이언트에 전달하는 SAPIC(Stream-based API Composition)를 제안한다. SAPIC는 클라이언트 응답 메시지를 구성하는 각각의 MSA API를 호출하여 받은 응답 메시지를 즉시 클라이언트로 스트리밍하여 IMJ에 비해 API 게이트웨이의 자원 소모를 줄이고 빠른 응답시간을 제공할 수 있다. 대표적인 API 조합 기술인 GraphQL 비교실험결과 SAPIC는 GraphQL에 비해 약 21 ~ 70 % 낮은 최대 CPU 점유율과 약 16 ~ 74 % 낮은 최대 Heap 사용량 그리고 1 ~ 2.3 배의 높은 처리량을 기록하였다.

Abstract ▼ AI-Helper

In the API gateway, API composition is an essential function that can reduce the number of client calls and prevent over-fetching and under-fetching. API composition that operate with IMJ (In-Memory Join) consume a lot of resources, putting a burden on the performance of the API gateway. In this paper, to improve the problem of IMJ-style API composition, we propose SAPIC (Stream-based API Composition), which delivers the data to be composed to the client by streaming. SAPIC calls each MSA API that makes up the client response data and immediately streams the received response data to the client, reducing the resource consumption of the API gateway and providing faster response time compared to IMJ. As a result of a comparison experiment with GraphQL, a representative API combination technology, SAPIC recorded a maximum CPU occupancy rate of approximately 21 to 70 % lower, a maximum heap usage rate of approximately 16 to 74 % lower, and a throughput rate that was 1 to 2.3 times higher than GraphQL.

주제어

표/그림 (11)

그림 (그림 1) API 조합[5] (Figure 1) API Composition[5]
그림 (그림 2) SAPIC Components (Figure 2) SAPIC Components
그림 (그림 3) 라우팅 규칙 정의 (Figure 3) Routing Rule Definition
그림 (그림 4) Fetcher (Figure 4) Fetcher
그림 (그림 5) Composer (Figure 5) Composer
그림 (그림 6) 스트리밍 알고리즘 (Figure 6) Streaming Algorithm
표 (표 1) 구현환경 (Table 1) Implementation Environment
그림 (그림 7) 실험 환경 (Figure 7) Test Environment
그림 (그림 8) 데이터 건수 별 최대 CPU 사용량(%) (Figure 8) Max CPU usage(%) by number of data
그림 (그림 9) 데이터 건수 별 최대 Heap 사용량(Mb) (Figure 9) Max heap usage(Mb) by number of data
그림 (그림 10) 데이터 건수 별 초당 처리량 (Figure 10) Throughput per second by number of data

AI 본문요약
AI-Helper

문제 정의

본 연구에서는 (2) 서비스 모델을 대상으로 응답시간 및 API 게이트웨이의 자원소모를 줄이는 것을 목표로 한다.
본 연구에서는 API 조합의 이와 같은 문제를 해결하기 위해 SAPIC(Stream-based API Composition: 스트림 기반 API 조합)를 제안한다. SAPIC는 IMJ와 달리 각 API의 데이터를 스트림으로 처리하고 조합한다.
본 연구에서는 IMJ API 조합의 문제점을 개선하기 위해 조합할 데이터를 스트리밍으로 클라이언트에 전달하는 SAPIC를 제안하였다. SAPIC는 클라이언트 응답 메시지를 해석한 후 응답데이터를 구성하는 각각의 MSA API를 호출하고 즉시 응답메시지를 클라이언트로 스트리밍한다.

가설 설정

최근 웹 데이터는 JSON이나 XML과 같은 편리한 구조화된 형식으로 데이터를 노출하는 REST API를 통해 교환되고, 대부분의 경우 이러한 API의 구조화된 응답은 REST 스타일에 따라 일반적인 구문 형식을 따른다[15]. SAPIC는 클라이언트의 요청이 이런 구조화된 데이터 응답을 소모한다고 가정하고 대표적인 경량 데이터 교환형식인 JSON을 사용한다. JSON은 REST API에서 많이 사용되는 대표적인 데이터 교환형식으로 GraphQL에서도 주요 데이터 형식으로 지원한다.

제안 방법

SAPIC와 GraphQL의 공정한 비교평가를 위해 Spring Boot, Spring WebFlux 및 Java 버전은 동일한 버전을 사용했으며 성능에 영향을 줄 수 있는 로그는 OFF로 설정했다. GraphQL에서 API 게이트웨이와 GraphQL 구현체는 Spring Cloud Gateway Server와 graphql-java를 사용하였고 SAPIC는 직접 구현하였다.
SAPIC와 GraphQL의 공정한 비교평가를 위해 Spring Boot, Spring WebFlux 및 Java 버전은 동일한 버전을 사용했으며 성능에 영향을 줄 수 있는 로그는 OFF로 설정했다. GraphQL에서 API 게이트웨이와 GraphQL 구현체는 Spring Cloud Gateway Server와 graphql-java를 사용하였고 SAPIC는 직접 구현하였다.
본 연구에서는 IMJ의 위와 같은 문제를 해결하기 위해 SAPIC를 제안하고 IMJ와 비교평가를 통해 개선점과 한계를 도출한다.
GraphQL에서는 Schema 정의를 통해 MSA 애플리케이션에서 서비스하는 API의 집합을 사전 정의한다[11,12]. 클라이언트는 Schema를 질의하는 쿼리를 GraphQL 문법으로 작성하여 전송하면 GraphQL 서버는 쿼리의 결과 데이터를 구성할 각 요소 데이터를 조회하는 Fetcher를 실행한 후 결과를 질의문의 구조에 맞게 IMJ 방식으로 조합하여 클라이언트로 전송한다.
테스트케이스는 조합대상 MSA API 각각에서 응답하는 데이터의 건수를 10, 100, 200, 500, 1000으로 증가시키며 테스트하였고 매 케이스 마다 초당 처리량과 API 게이트웨이의 최대 CPU 및 Heap 사용량을 측정하였다.

데이터처리

SAPIC는 IMJ와 달리 각 API의 데이터를 스트림으로 처리하고 조합한다. 본 연구에서는 SAPIC를 구성하는 컴포넌트를 설계 및 구현하였고 실험을 통해 널리 사용되고 있는 대표적인 IMJ 방식의 GraphQL과 비교 평가하였다.
본 연구에서는 제안한 SAPIC를 구현하고 실험을 통해 GraphQL 기반 API 게이트웨이와 성능을 비교 평가하였다.

성능/효과

최대 Heap 사용량은 그림 9와 같이 SAPIC는 166 ~ 385 Mb를 GraphQL은 239 ~ 1,523 Mb를 기록하였다. 그래프에서 확인할 수 있듯이 SAPIC는 비교적 안정적인 Heap을 사용하는 반면 GraphQL은 데이터 건수가 증가함에 따라 Heap 사용량이 선형으로 증가하는 것을 확인할 수 있다.
그림 10에서 보여주는 초당 처리량은 SAPIC는 172 ~ 1073 건, GraphQL은 81 ~ 1064 건으로 SAPIC가 평균적으로 약 80 % 높은 처리량을 기록하였다.
API 게이트웨이는 MSA에 외부 API 클라이언트의 진입점에 해당하는 서비스를 구현한다. 다수의 서비스로 분리된 MSA의 특성으로 인해 API 게이트웨이의 API 조합은 클라이언트의 호출횟수를 줄이고 오버페칭과 언더페칭을 방지할 수 있는 필수적인 기능인데 현재까지 IMJ로 동작하는 API 조합은 높은 자원을 소모하여 API 게이트웨이의 성능에 큰 영향을 준다.
3 배의 높은 처리량을 기록하였다. 데이터양의 변화에 따른 본 테스트에서 SAPIC는 데이터 변화에도 비교적 균일한 CPU 및 Heap 사용량을 보인 반면 GraphQL은 특히 Heap 사용량에서 선형증가를 보여 API 게이트웨이의 성능을 저하시킬 수 있는 원인이 될 수 있었다.
또한 MSA API 호출의 결과 데이터는 GraphQL과 달리 엄격한 Schema 정의 없이 각 요소와 MSA API 매핑으로 정의되어 API 게이트웨이의 핵심 서비스와 확장 기능인 MSA API와의 직접적인 결합도를 낮춘다. 게이트웨이 계층은 서비스 별로 여러 인터페이스를 구현해야 하므로 복잡성이 증가한다[13,16].
본 연구에서 SAPIC의 검증을 위해 실시한 GraphQL과의 비교실험에서 SAPIC는 GraphQL에 비해 약 21 ~ 70 % 낮은 최대 CPU 점유율과 약 16 ~ 74 % 낮은 최대 Heap 사용량 그리고 1 ~ 2.3 배의 높은 처리량을 기록하였다. 데이터양의 변화에 따른 본 테스트에서 SAPIC는 데이터 변화에도 비교적 균일한 CPU 및 Heap 사용량을 보인 반면 GraphQL은 특히 Heap 사용량에서 선형증가를 보여 API 게이트웨이의 성능을 저하시킬 수 있는 원인이 될 수 있었다.

참고문헌 (17)

C Richardson, "Microservices Patterns," Manning,？pp.152-160, 253-291, 2018.
Q Xiong and W Li, "Design and Implementation of？Microservices Gateway Based on Spring Cloud？Zuul," 3rd International Conference on Computer？Information and Big Data Applications, pp.1-5, 2022.？https://ieeexplore.ieee.org/stamp/stamp.jsp?tp&arnumber9899125&isnumber9898665
X Gao, R Liu and X Lin, "API Gateway？Optimization Architecture Based on Heterogeneous？Hardware Acceleration," IEEE 3rd International？Conference on Information Technology and Big Data？and Artificial Intelligence, pp. 863-868, 2023.？https://doi.org/10.1109/ICIBA56860.2023.10165387
P D Francesco, P Lago and I Malavolta, "Architecting？with microservices: A systematic mapping study,"？Journal of Systems and Software, Vol.150, pp.77-97,？2019.？https://doi.org/10.1016/j.jss.2019.01.001

상세보기
Pattern: API Composition.？http://microservices.io/patterns/data/api-composition.html
S Newman, "Building Microservices: Designing？Fine-Grained Systems," pp.44-45, O'Reilly Media,？2021.
F M Imani, "Aggregator Backend API With？KrakenD," Proceeding International Applied Business？and Engineering Conference, Vol.2, pp.229-233,？2022.？https://abecindonesia.org/iabec/index.php/iabec/article/view/108
N Vohra and I B K Manuaba, "Implementation of？REST API vs GraphQL in Microservice Architecture,"？International Conference on Information Management？and Technology, pp.45-50, 2022.？https://doi.org/10.1109/ICIMTech55957.2022.9915098
M F Radhiyan, D Khairani and H B Suseno,？"Analysis and Design of Microservices Architecture？with GraphlQL as an API Gateway for Higher？Education Information System," International？Conference on Science and Technology, pp.1-7,？2022.？https://doi.org/10.1109/ICOSTECH54296.2022.9829090
G Brito and M T Valente, "REST vs GraphQL: A？Controlled Experiment," IEEE International？Conference on Software Architecture, pp.81-91,？2020.？https://doi.org/10.1109/ICSA47634.2020.00016
E Porcello, A Banks, "Learning GraphQL -？Declarative Data Fetching for Modern Web Apps,"？O'Reilly Media, pp2-5, 2018.
O Hartig and J Perez, "An initial analysis of？Facebook's GraphQL language," International？Workshop on Foundations of Data Management and？the Web, pp. 1-10, 2017.？https://ceur-ws.org/Vol-1912/paper11.pdf
D Malavalli and S Sathappan, "Scalable microservice？based architecture for enabling DMTF profiles,"？International Conference on Network and Service？Management, pp.428-432, 2015.？https://doi.org/10.1109/CNSM.2015.7367395
J Lin, L C Lin and S Huang, "Migrating web？applications to clouds with microservice architectures,"？International Conference on Applied System？Innovation, pp.1-4, 2016.？https://doi.org/10.1109/ICASI.2016.7539733
D Serrano, E Stroulia, D Lau and T Ng, "Linked？REST APIs: A Middleware for Semantic REST API？Integration," IEEE International Conference on Web？Services, pp.138-145, 2017.？https://doi.org/10.1109/ICWS.2017.26
W Scarborough, C Arnold and M Dahan, "Case？study: Microservice evolution and software lifecycle？of the xsede user portal api," in Proc. of Conference？on Diversity Big Data and Science at Scale, No.47,？pp.1-5, 2016.？https://doi.org/10.1145/2949550.2949655
Z Xianyu, S Yuehan, W Qianqian and X Yi, "An？API gateway design strategy optimized for？persistence and coupling Advances in Engineering？Software," Elsevier, Vol.148, 2020.？https://doi.org/10.1016/j.advengsoft.2020.102878

상세보기

표제어: PCR

동의어: Packet Collision Rate

용어 설명 출처 목록 (6)

용어 설명: PCR은 세균 특이성이 있는 primer를 이용하여 적은 수의 세균이 있을지라도 쉽게 검출할 수 있는 유용한 방법이며, 이를 이용하여 구강 내 치면세균막이나 타액에서 직접 세균을 검출할 수 있게 되었다[8].

내보내기 구분	파일저장 인쇄 메일전송
구성항목	기본정보 상세정보 관리번호, 논문명, 저널/프로시딩명, 저자 , 발행년, 권, 호, 시작페이지, 끝페이지, 발행기관 관리번호, 논문명, 대등논문명, 저자 , 저널/프로시딩명, 발행기관, 발행년, 발행언어, 권, 호, 시작페이지, 끝페이지, ISBN, ISSN, 주제분야, 키워드, 초록(한글), 초록(영문), 저자(소속기관)
저장형식	Text(ASCII format) Excel format RefWorks Direct Export RIS format (for Reference Manager, ProCite, EndNote), Scholar's Aids, Mendeley
메일정보	받는사람 (필수) @ 보내는사람 (선택) @ 제목 내용 KISTI 검색결과 이메일 서비스
안내	총 건의 자료가 검색되었습니다. 다운받으실 자료의 인덱스를 입력하세요. (1-10,000) 검색결과의 순서대로 최대 10,000건 까지 다운로드가 가능합니다. 데이타가 많을 경우 속도가 느려질 수 있습니다.(최대 2~3분 소요) 다운로드 파일은 UTF-8 형태로 저장됩니다. 파일의 내용이 제대로 보이지 않을실 때는 웹브라우저 상단의 보기 -> 인코딩 -> 자동선택 여부를 확인하십시오. ~ Text(ASCII format) Excel format

연합인증