[CI/CD 프로젝트] API gateway의 도입 배경과 역할

MSA Architecture

Gartner가 소개한 MSA 아키텍처의 컴포넌트이다.

MSA 아키텍처를 보면 모두 APIgateway가 들어가 있는 것을 볼 수 있다.

Why APIgateway

APIgateway 는 proxy를 해주는 역할이다. 하지만 왜 굳이 단일 장애 지점(SPOF)의 위험이 있는데도 APIgateway를 사용할까?

1. 추상화 : 다수의 백엔드를 숨기고 한개의 endpoint로 통일한다.
2. 종속성 제거 : api definition을 json형태로 통일하여 프론트/백엔드에 대한 종속성 제거한다.
3. 공통기능 : 인증, cache, CORS 등 공통적으로 제공해야하는 기능을 한 군데에서 처리하며 개발 생산성 향상한다.
4. 모니터링 : 마이크로서비스 아키텍처의 가시성과 관리 용이성을 높인다.

위와 같이 이유로 APIgateway를 사용한다. 아래 주제별로 깊게 내용을 다뤄본다.

추상화 & 종속성 제거

자세한 구현 전 상위 레벨에서 구현을 먼저 생각하는 것

• 과정의 추상화 : 자세한 단계를 고려하지 않고 상위 수준에서 수행 흐름만 먼저 설게
• 데이터 추상화 : 데이터 구조를 대표할 수 있는 표현으로 대체하는 것

APIgateway는 이와 같이 과정의 추상화를 통해서 아키텍처에 대한 이해도를 높이고, 구현을 단순화할 수 있다.

• 과정의 추상화

MSA 아키텍처 채택 시, 다양한 기기의 사용으로 프론트/백엔드의 종류가 다양해진다.
따라서 이에 대한 복잡도가 증가하고, N:N 종속성이 발생하게 된다. 예를 들어, 모바일에서 보이는 컨텐츠를 수정하기 위해 백엔드 수정 시 PC프론트가 안보이게 되는 종속성이 발생할 수 있다.

이러한 경우 관리의 어려움이 있을 수 있어, 다양한 Endpoint로 직접 호출하는 대신, 아래와 같이 APIgateway로 Endpoint를 추상화하는 것이 필요하다.

이렇게 변경되면, client는 한 endpoint로만 호출하게 되어 관리가 용이해진다.

• 데이터의 추상화

통일된 api definition을 통해 개발자들은 API 정의와 자신의 코드를 보고 무엇이 잘못된 것인지 확인할 수 있게 된다. 보통 APIgateway는 대시보드를 통해 API를 관리하여 정형화된 기준을 통해 API 정의서를 만들어낸다. 따라서 확인해야하는 key가 명확해져 프론트/백엔드 개발자는 불필요한 소통 없이 api definition을 통해서 개발을 진행하게 되어 생산성을 높일 수 있다.

공통기능

• 로그인 기능 구현

API Gateway는 클라이언트와 백엔드 서비스 간의 안전한 통신을 보장하기 위해 인증(Authentication)과 인가(Authorization) 기능을 제공한다. API Gateway는 정책, API 정의서를 기반으로 클라이언트의 권한을 평가하고 적절한 액세스 제어를 해준다.

이러한 보안 기능을 통해 API Gateway는 백엔드 서비스와 데이터를 안전하게 보호하고 승인되지 않은 접근을 차단할 수 있다. 이러한 APIgateway의 기능을 활용하여 복잡하게 구현이 필요한 로그인 기능을 간단하게 구현할 수 있다.

1. 로그인 : 클라이언트 애플리케이션이 API Gateway를 통해 로그인 API에 POST 요청을 보냅니다. 이 요청에는 사용자 ID와 비밀번호가 포함된다.
2. API Gateway 처리: API Gateway는 요청을 수신하고, 인증 및 권한 부여를 수행한다(key create).
3. 이렇게 전달받은 인증토큰을 DB에 저장하고, client에 리턴하게 된다.
4. client는 이 인증토큰을 가지고 로그인을 시도한다.
5. apigateway DB에 저장된 토큰을 가지고 호출하고 있으므로 호출이 인가된다.

• CORS

교차출처 리소스에 대한 정책으로 해당 내용에 대한 설정을 백엔드가 아닌 APIgateway에서 설정할 수 있다. 이렇게 각자 백엔드에서 구현해야하는 기능을 APIgateway에서 공통으로 구현하면서 유지보수를 용이하게 만들어준다.

• cache

캐싱은 자주 요청되는 데이터를 보관하여 백엔드 서비스에 대한 중복 요청을 줄이고 응답 시간을 단축할 수 있다. API Gateway는 API 정의서에서 캐시 설정을 함으로써 어떤 데이터를 캐시할지, 얼마나 오래 유지할지 등을 제어할 수 있다.

모니터링 기능

API Gateway는 MSA아키텍처에서 단일 진입점으로, 로깅, 모니터링 및 분석 기능을 제공하여 효과적인 운영 관리를 가능하게 해준다. 응답을 위해서 필수적으로 APIgateway로 트래픽이 들어와야하기 때문에 Troubleshooting 구간의 기준이 된다. 단일진입점으로, 로그기능이 있어 원인 파악에 대한 접근이 용이하여 보다 쉽게 해결과 디버깅을 진행할 수 있다.로깅 기능은 API Gateway를 통과하는 모든 요청과 응답을 기록하고 오류에 대한 메세지를 보여 준다. 이러한 기능을 통해 API 사용 패턴, 지연 시간, 오류 빈도 등을 용이하게 파악할 수 있다.

Ingress와 Apigateway

listen path를 읽고 proxy를 하는 것은 두 가지 모두 동일하다. 그럼 어떤 내용이 차이점이 있을 지 확인해본다.

• Ingress: Ingress는 Kubernetes 클러스터 내부의 서비스에 대한 외부 접근을 관리하는 역할을 합니다. 주로 HTTP(S) 트래픽을 처리한다.
  • 주요 기능:
    • 라우팅: URL 경로 또는 호스트 이름에 기반하여 트래픽을 특정 서비스로 라우팅한다.
    • TLS 종료: HTTPS 요청의 TLS 암호화를 종료하고 내부 서비스와의 통신은 HTTP로 진행할 수 있다.
    • 로드 밸런싱: 여러 Pod에 대한 로드 밸런싱을 지원한다.
• API Gateway (내부 중계): API Gateway는 다양한 백엔드 서비스에 대한 API 요청을 관리하고 중개하는 역할을 합니다. 클라이언트와 서버 사이에서 요청을 처리한다. (내부 처리)
  • 주요 기능:
    • API 라우팅: 요청을 다양한 서비스에 라우팅한다.
    • 인증 및 권한 부여: 클라이언트의 인증과 권한 부여를 처리하여 보안을 강화한다.
    • 모니터링 및 로깅: API 호출에 대한 로그와 메트릭을 수집하여 모니터링할 수 있다.
    • 요청 변환: 요청 및 응답 형식을 변환하는 기능을 제공한다.

Apigateway 설치

여기서는 따로 k8s로 배포하지 않고, 서버로 배포하였다.

따라서 서버는 dsbd, gateway, pump 3ea와 redis, mongodb를 배포하는 서버 1ea 총 4대가 필요하다.

• Dashboard 설치

vi /etc/yum.repos.d/tyk_tyk-dashboard.repo

[tyk_tyk-dashboard]
name=tyk_tyk-dashboard
baseurl=https://packagecloud.io/tyk/tyk-dashboard/amazon/2023/$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/tyk/tyk-dashboard/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

• 설치

sudo yum -q makecache -y --disablerepo='*' --enablerepo='tyk_tyk-dashboard'
yum install tyk-dashboard-5.3.7-1

• file handle 설정

vi /etc/sysctl.conf

fs.file-max=160000 # OS 전체에서 읽을 수 있는 파일 수 

systemctl edit tyk-dashboard

[Service]
LimitNOFILE=80000  # tyk dashboard가 열 수 있는 파일 수 

• tyk dashboard 시작

systemctl start tyk-dashboard    
systemctl enable tyk-dashboard # 서버가 켜지면 같이 tyk-dashboard 프로세스가 올라오도록 설정

• gateway 설치

vi /etc/yum.repos.d/tyk_tyk-gateway.repo

[tyk_tyk-gateway]
name=tyk_tyk-gateway
baseurl=https://packagecloud.io/tyk/tyk-gateway/amazon/2023/$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey= https://packagecloud.io/tyk/tyk-gateway/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

• 설치

sudo yum -q makecache -y --disablerepo='*' --enablerepo='tyk_tyk-dashboard'
yum install tyk-gateway-5.3.7-1.x86_64

• file handle 설정

vi /etc/sysctl.conf

fs.file-max=160000 # OS 전체에서 읽을 수 있는 파일 수 

systemctl edit tyk-gateway

[Service]
LimitNOFILE=80000  # tyk-gateway가 열 수 있는 파일

• tyk gateway 시작

systemctl start tyk-gateway
systemctl enable tyk-gateway # 서버가 켜지면 같이 tyk-dashboard 프로세스가 올라오도록 설정

• pump 설치

vi /etc/yum.repos.d/tyk_tyk-pump.repo

[tyk_tyk-pump]
name=tyk_tyk-pump
baseurl=https://packagecloud.io/tyk/tyk-pump/amazon/2023/$basearch
repo_gpgcheck=1
gpgcheck= 0
enabled=1
gpgkey=https://packagecloud.io/tyk/tyk-pump/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

• 설치

sudo yum -q makecache -y --disablerepo='*' --enablerepo='tyk_tyk-dashboard'
yum install tyk-pump-1.9.0-1

• file handle 설정

vi /etc/sysctl.conf

fs.file-max=160000 # OS 전체에서 읽을 수 있는 파일 수 

systemctl edit tyk-pump

[Service]
LimitNOFILE=80000  # tyk-gateway가 열 수 있는 파일

• tyk pump 시작

systemctl start tyk-pump
systemctl enable tyk-pumy # 서버가 켜지면 같이 tyk-pump 프로세스가 올라오도록 설정

• mongodb설치

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-mongodb bitnami/mongodb

• redis설치

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-redis bitnami/redis

• config파일 수정

kubectl get svc # mongodb, redis 접근 주소 확인

# 각 서버에서 mongodb와 redis로 연결될 수 있도록 value값을 수정한다.
vi /opt/tyk-dashboard/tyk_analytics.conf
vi /opt/tyk-gateway/tyk.conf
vi /opt/tyk-pump/pump.conf 

• 대시보드 접속 확인(초기 비번: conf 파일 secret 참고)
• API 생성

API 를 생성하여 tyk의 proxy가 어떻게 동작하는지 확인한다.

• upstream URL에는 tyk가 proxy할 target url을 입력한다. 이번 테스트에는 dashboard서버에서 healthcheck하는 url로의 proxy가 될 수 있도록 한다. 이때 dashboard로 도달하려면 3000번 포트를 입력해줘야한다. (ex, http://{{dashboard ip}}:3000 )

• custom domain에는 tyk gateway로 접근할 수 있는 url을 입력한다.
  ALB를 입력할 수 있고, ip로 입력해도 무방하다.

• Listen Path 설정

이 값은 고유한 값으로 설정되어야하고, gateway로 접근이 되면 이 listen path를 보고 proxy를 진행한다. 여기서는 /test_health_check/ 로 설정한다.

• Ratelimit 설정

공통 기능으로, backend단을 보호하기 위해 과도한 트래픽 발생 시 apigateway에서 조절해주는 설정이 있다. 이것은 무제한으로 두고 넘어간다.

 

• Authentication

인가된 사람만 호출할 수 있도록 만들려면, Authentication을 사용한다. 이번에도 무인증인 Keyless로 두고 넘어간다.

• cache 설정

많은 호출을 하고, 동일한 값을 리턴하는 경우 cache 적용을 통해 뒷단의 부하를 방지해줄 수 있다.

• CORS 설정

단순 health check 를 하는 호출로, 브라우저를 사용하지 않기 때문에 CORS를 사용하지 않고 넘어간다.

• API등록이 완료되었다. 이제 gateway에서 curl로 호출해본다.

curl -iv http://{customdomain}:8080/test_health_check/hello

대시보드의 healthcheck가 정상적으로 수행되었다.

• 테스트한 내용은 아래와 같이 tyk gateway를 통해 target : dashboard의 healthcheck를 진행하였다.