첫 번째 사례에서는 ChatGPT를 활용해 간단한 서버리스 함수를 만들어 보았습니다. 이번에는 범위를 확장해 실제로 사용할 수 있는 백엔드를 설계해보려고 합니다. 물론, 개발 지식이 전혀 없다면 이해에 한계가 있을 수 있지만, 프론트엔드 개발자나 기본적인 개발 지식(API 등의 일반적인 용어 이해)을 가진 분이라면 충분히 도전해볼 수 있습니다.
이번 사례에서는 흔히 사용하는 API를 구축하는 아키텍처를 설계하고 시각화해보려 합니다. 설계 방식에 따라 복잡도가 달라지겠지만, 클라우드 내 서버리스 기능을 최대한 활용해 보았습니다. 도전🔥🔥
개요 및 목적
특정 IP에서만 요청할 수 있는 REST API 만들기
예시: api.example.com/requestUserInfo (이번 사례에서는 커스텀 도메인 적용 부분은 생략)
조건
실제 로직을 수행하는 서비스는 첫 사례에서 언급한 Cloud Function로 가정(다른 서비스여도 무방)
요구사항
API 호출을 도와주는 ❓[무언가]❓
특정 IP에서만 해당 API를 호출할 수 있게 하는 ❓[무언가]❓
접근 권한 부여 후, 우리의 Cloud Function을 호출하는 ❓[무언가]❓
개발 환경
클라우드 환경: Google Cloud Platform (GCP)
사용 기능: 일반적으로 알려진 기능 또는 잘 모르는 기능을 가정
결과물
각 질문마다 부분적인 아키텍처 다이어그램을 단계별로 그려보기
모든 요구사항을 담은 최종 아키텍처 다이어그램을 그려보기 (그리고, ChatGPT로 검토받기)
1. GCP에서 ‘API 만들기’를 시작하려면?
처음 시작하는 단계에서는 어떻게 접근해야 할지 막막함을 느낍니다. 구체적으로 무엇을 물어봐야 할지 잘 모르기 때문에 기본적인 질문부터 시작해보겠습니다.
Q: GCP에서 API를 만들기 위해 어떤 기능을 활용할 수 있어?
여러 추천된 방법 중 서버리스 개발이 가장 접근하기 쉬워 보여서 API Gateway, App Engine, 그리고 Cloud Function 중에서 선택해보았습니다. 첫 사례에서 이미 Cloud Function을 경험해보았기 때문에, 학습 목적으로는 제외하겠습니다. 남은 두 옵션을 살펴본 결과, 우리가 사용할 Cloud Function에 대한 정보가 포함된 것을 보니, API Gateway가 더 매력적으로 느껴집니다. 이를 사용해보기로 했습니다.
2. 그렇다면, API Gateway를 활용하여 어떻게 접근해야 할까?
Q: API Gateway를 사용하여 API를 만들 예정인데, 다음과 같은 조건을 충족해야 해.
특정 IP에서만 접근 가능
접근이 허용된 후, 특정 작업을 수행하는 Cloud Function(엔드포인트) 필요
1, 2, 3번 항목에서는 API Gateway 설정 방법을 설명해 줍니다. 특히, 2번 항목은 백엔드 서비스(즉, Cloud Functions)를 API Gateway와 연결해야 한다는 점을 강조하네요.
4번 항목은 "특정 IP에서만 접근이 가능하도록 설정하는 규칙"에 대한 정보를 제공합니다. VPC Service Controls 또는 Cloud Armor라는 기능을 사용하라고 권장하네요. Cloud Armor에 대한 설명이 우리의 요구사항에 더 잘 맞는 것 같아 이 방법으로 구조를 설계해 보려 합니다. 다만, 설명 중에 '로드 밸런서'라는 용어가 나오는데, 이 부분은 아직 잘 이해가 되지 않으므로 잠시 보류하고 다음 질문으로 넘어가겠습니다 😅
3. Cloud Armor와 API Gateway를 연결하려면?
Q: Cloud Armor와 API Gateway를 연결하려면 어떻게 해야해?
ChatGPT가 중요한 사실을 알려줍니다. 바로, API Gateway는 Cloud Armor와 직접 연결할 수 없다는 점❗
그렇다면 어떻게 연결해야 할까…? HTTP(S) 로드 밸런서를 사용하여 Cloud Armor와 API Gateway 사이를 연결해야 한다고 합니다. 그러면, Cloud Armor에 원하는 조건(예: IP 제한)을 설정하고 로드 밸런서에 연결하는 구조겠네요. 그런 다음 이 로드 밸런서를 API Gateway에 연결합니다.
4. 우리가 이해한 것이 맞는지 확인하기
Q1: 그렇다면 클라이언트가 HTTPS를 통해 REST API 요청을 전송할 때, 요청을 받는 주체는 로드 밸런서가 맞아?
로드 밸런서가 클라이언트로부터의 API 요청을 처리하는 주체라는 것이 맞네요! 추가로, 우리가 이전에 이해했던 것처럼 로드 밸런서가 요청을 API Gateway로 라우팅한다고 합니다. 우리가 이해한 흐름이 맞는 듯합니다!
Q2: 그렇다면 Cloud Armor는 API Gateway에 직접 연결된 것이 아니라 로드 밸런서에 연결되어 있고, 설정된 보안 정책에 따라 로드 밸런서가 API Gateway로 요청을 전달하는 구조인가?
정리해보면, 클라이언트에서 로드 밸런서로, 그리고 Cloud Armor를 거쳐 다시 로드 밸런서와 API Gateway를 통해 Cloud Function까지 요청이 진행되는 구조로 보입니다. 반대로 응답을 전송할 때는 이 경로가 역순이겠죠. 우리가 생각한 아키텍처 구조가 맞는지 다시 한번 확인볼까요?
Q3: 마지막으로, 클라이언트의 API 요청부터 로드 밸런서, Cloud Armor, API Gateway, 그리고 Cloud Function까지 이어지는 흐름을 단계별로 간단히 나열해줘.
이 흐름과 구조를 토대로 아키텍쳐 다이아그램 전체를 한번 그려보겠습니다.
5. 최종 아키텍쳐 다이아그램 그려보기
Q3: 너가 위에 알려준 구조의 흐름과 내가 첨부한 그림과 일치하는지 확인만 해줘 (설명하지 않아도 돼)
과연?
초반에 아무래도 로드 밸런서 쪽이 조금 헷갈렸으니, ChatGPT가 제대로 인식했는지 그림을 바꿔서 다시 한번 확인 요청합니다.
과연?
위에서 설명한 것과 같이 Cloud Armor는 API Gateway에 직접 연결해서는 안 되고 Load Balancer와 연결되어야 함을 알았습니다. 즉, Load Balancer는 API Gateway와 연결되어 마지막 백엔드 서비스로 전달하는 구조이군요👍
정리하며,
우리가 처음에 목표로 한 "특정 IP만 접속 가능한 API의 아키텍처를 그려보기"를 성공적으로 완료했습니다. 물론, 실제 구축 작업은 더 복잡하고 서비스 규모 및 성격에 따라 복잡도가 천차만별일 것입니다. 다만, 큰 맥락에서는 내용이 동일하기 때문에 이번 기회에 API가 어떻게 구성되어 있는지 확인할 수 있었습니다.
기본적인 구성은 위와 같지만, 입맛에 따라 다양한 구성을 추가할 수 있어요. 예를 들어, 깔끔한 API 주소를 제공하고 싶다면 IP 할당 후 커스텀 도메인을 적용할 수도 있고, 또한 API Key를 부여하여 해당 키를 보유한 클라이언트만 접속 가능하게끔도 가능합니다. 이러한 기능들도 ChatGPT를 통해 단계별 설명을 요청하고 그에 맞춰 설계 및 개발을 진행할 수 있습니다.
부족한 글을 읽어주셔서 감사드립니다 🙇
#9기풀스택#백엔드도전하기