AI 애플리케이션: 고급 아키텍처 조언(AKA AAAA!)

놀라다! 이것은 제가 최근 마무리한 웹 개발자용 AI 시리즈에 대한 보너스 블로그 게시물입니다. 아직 해당 시리즈를 읽지 않으셨다면 꼭 읽어보시길 권합니다. 확인 해봐 .

이 게시물에서는 기존 프로젝트 아키텍처를 살펴보고 애플리케이션 개발자와 최종 사용자 모두를 위해 이를 개선할 수 있는 방법을 살펴보겠습니다.

몇 가지 일반적인 개념에 대해 논의하고 예시에서는 특정 Akamai 제품을 사용해 보겠습니다.

기본 애플리케이션 아키텍처

기존 애플리케이션은 매우 기본적입니다. 사용자가 두 명의 상대를 제출하면 애플리케이션은 누가 싸움에서 이길 것인지에 대한 AI 생성 응답을 다시 스트리밍합니다.

아키텍처도 간단합니다.

1. 클라이언트가 서버에 요청을 보냅니다.

   
   

2. 서버는 프롬프트를 구성하고 프롬프트를 OpenAI에 전달합니다.

   
   

3. OpenAI는 스트리밍 응답을 서버에 반환합니다.

   
   

4. 서버는 필요한 조정을 수행하고 스트리밍 응답을 클라이언트에 전달합니다.

저는 Akamai의 클라우드 컴퓨팅 서비스(이전에는 리노드 ) 그러나 이는 실제로 모든 호스팅 서비스에서 동일합니다.

🤵는 고급 레스토랑의 서버처럼 보이고, 👁️‍🗨️은 "눈" 또는 AI입니다. ㅋㅋㅋ

기술적으로는 잘 작동하지만 특히 사용자가 중복 요청을 할 때 몇 가지 문제가 있습니다. 서버에 응답을 저장하고 고유한 요청에 대해서만 OpenAI로 이동하는 것이 더 빠르고 비용 효율적일 수 있습니다.

이는 모든 단일 요청이 비결정적일 필요가 없다고 가정합니다(동일한 입력이 다른 출력을 생성함). 동일한 입력이 동일한 출력을 생성하는 것이 괜찮다고 가정해 보겠습니다. 결국, 싸움에서 누가 이길지에 대한 예측은 바뀌지 않을 것입니다.

데이터베이스 아키텍처 추가

OpenAI의 응답을 저장하려는 경우 두 상대를 사용하여 빠르고 쉽게 조회할 수 있는 일종의 데이터베이스에 이를 저장할 실용적인 장소가 있습니다. 이렇게 하면 요청이 있을 때 먼저 데이터베이스를 확인할 수 있습니다.

1. 클라이언트가 서버에 요청을 보냅니다.

   
   

2. 서버는 사용자의 입력과 일치하는 데이터베이스의 기존 항목을 확인합니다.

   
   

3. 이전 레코드가 존재하는 경우 서버는 해당 데이터로 응답하고 요청이 완료됩니다. 다음 단계를 건너뛰세요.

   
   

4. 그렇지 않은 경우 서버는 이전 흐름의 3단계를 따릅니다.

   
   

5. 응답을 닫기 전에 서버는 OpenAI 결과를 데이터베이스에 저장합니다.

점선은 선택적 요청을 나타내며 💽 종류는 하드 디스크처럼 보입니다.

이 설정을 사용하면 모든 중복 요청이 데이터베이스에서 처리됩니다. 일부 OpenAI 요청을 선택 사항으로 만들면 사용자가 경험하는 지연 시간을 잠재적으로 줄일 수 있을 뿐만 아니라 API 요청 수를 줄여 비용도 절약할 수 있습니다.

특히 서버와 데이터베이스가 동일한 지역에 존재하는 경우 이는 좋은 시작입니다. OpenAI 서버로 이동하는 것보다 응답 시간이 훨씬 빠릅니다.

그러나 우리 애플리케이션이 대중화되면서 전 세계에서 사용자를 확보하게 될 수도 있습니다. 더 빠른 데이터베이스 조회는 좋지만 병목 현상이 비행 시간으로 인한 지연이면 어떻게 될까요?

우리는 사물을 사용자에게 더 가까이 옮김으로써 이러한 우려를 해결할 수 있습니다.

엣지 컴퓨팅 도입

아직 '에지'라는 용어가 익숙하지 않다면 이 부분이 헷갈릴 수도 있지만, 간단하게 설명해보도록 하겠습니다. 엣지란 콘텐츠가 사용자에게 최대한 가까이 있다는 의미입니다. 어떤 사람들에게는 IoT 장치나 휴대폰 기지국을 의미할 수도 있지만 웹의 경우 표준적인 예는 다음과 같습니다. 콘텐츠 전달 네트워크(CDN) .

자세한 내용은 생략하겠지만 CDN은 네트워크에서 가장 가까운 노드의 사용자 요청에 응답할 수 있는 전 세계적으로 분산된 컴퓨터의 네트워크입니다( 내가 예전에 썼던 것 ). 전통적으로 정적 자산용으로 설계되었지만 최근에는 엣지 컴퓨팅( 또 제가 예전에 쓴 글도 있어요 ).

엣지 컴퓨팅을 사용하면 많은 백엔드 로직을 사용자에게 매우 가까이 이동할 수 있으며 컴퓨팅이 멈추지 않습니다. 대부분의 엣지 컴퓨팅 제공업체는 동일한 엣지 노드에 일종의 최종적으로 일관된 키-값 저장소도 제공합니다.

이것이 우리 애플리케이션에 어떤 영향을 미칠 수 있습니까?

1. 클라이언트가 백엔드에 요청을 보냅니다.

   
   

2. 엣지 컴퓨팅 네트워크는 요청을 가장 가까운 엣지 노드로 라우팅합니다.

   
   

3. 에지 노드는 사용자 입력과 일치하는 키-값 저장소의 기존 항목을 확인합니다.

   
   

4. 이전 레코드가 존재하는 경우 에지 노드는 해당 데이터로 응답하고 요청이 완료됩니다. 다음 단계를 건너뛰세요.

   
   

5. 그렇지 않은 경우 에지 노드는 요청을 원본 서버로 전달하고, 원본 서버는 이를 OpenAI 및 yadda yadda yadda에 전달합니다.

   
   

6. 응답을 닫기 전에 서버는 OpenAI 결과를 엣지 키-값 저장소에 저장합니다.

엣지 노드는 파란색 상자로 엣지가 있으므로 🔪로 표시되고, EdgeWorker는 🧑‍🏭로 표시되는 Akamai의 엣지 컴퓨팅 제품이며, EdgeKV는 🔑🤑🏪로 표시되는 Akamai의 키-값 저장소입니다. 엣지박스는 물리적인 거리를 표현하기 위해 클라우드의 원본 서버보다 클라이언트에 더 가깝습니다.

여기서는 원본 서버가 꼭 필요하지 않을 수도 있지만 있을 가능성이 더 높다고 생각합니다. 데이터, 컴퓨팅 및 논리 흐름을 위해 이는 이전 아키텍처와 대부분 동일합니다. 주요 차이점은 이전에 저장된 결과가 이제 사용자에게 매우 가까이 존재하며 거의 즉시 반환될 수 있다는 것입니다.

(참고: 데이터가 에지에서 캐시되지만 응답은 여전히 동적으로 구성됩니다. 동적 응답이 필요하지 않은 경우 원본 서버 앞에서 CDN을 사용하고 올바른 HTTP 헤더를 설정하는 것이 더 간단할 수 있습니다. 응답을 캐시하세요. 미묘한 차이가 많이 있어서 더 말씀드릴 수 있지만…글쎄, 피곤해서 별로 말하고 싶지 않습니다. 궁금한 점이 있으면 언제든지 문의하세요.)

이제 우리는 요리를 하고 있어요! 모든 중복 요청은 거의 즉시 응답되며 불필요한 API 요청도 절약됩니다.

이는 텍스트 응답의 아키텍처를 정렬하지만 AI가 생성한 이미지도 있습니다.

해당 이미지를 캐시하세요

오늘 우리가 마지막으로 고려할 것은 이미지입니다. 이미지를 다룰 때 전달과 저장에 대해 생각해야 합니다. OpenAI 직원들이 자체 솔루션을 갖고 있다고 확신하지만 일부 조직에서는 보안, 규정 준수 또는 안정성을 이유로 전체 인프라를 소유하기를 원합니다. 일부는 OpenAI를 사용하는 대신 자체 이미지 생성 서비스를 실행할 수도 있습니다.

현재 워크플로에서 사용자는 궁극적으로 OpenAI로 향하는 요청을 합니다. OpenAI는 이미지를 생성하지만 반환하지는 않습니다. 대신 OpenAI 인프라에서 호스팅되는 이미지의 URL이 포함된 JSON 응답을 반환합니다.

이 응답으로 URL을 사용하여 <img> 태그를 페이지에 추가할 수 있으며, 이는 실제 이미지에 대한 또 다른 요청을 시작합니다.

자체 인프라에서 이미지를 호스팅하려면 이미지를 저장할 장소가 필요합니다. 원본 서버의 디스크에 이미지를 쓸 수 있지만 그렇게 하면 디스크 공간이 빨리 소모될 수 있고 서버를 업그레이드해야 하므로 비용이 많이 들 수 있습니다.

객체 스토리지 훨씬 저렴한 솔루션입니다( 나는 이것에 대해서도 썼다. ). 이미지에 OpenAI URL을 사용하는 대신 이를 자체 객체 스토리지 인스턴스에 업로드하고 해당 URL을 대신 사용할 수 있습니다.

그러면 스토리지 문제가 해결되지만 객체 스토리지 버킷은 일반적으로 단일 지역에 배포됩니다. 이는 데이터베이스에 텍스트를 저장할 때 발생했던 문제를 반영합니다. 단일 지역이 사용자로부터 멀리 떨어져 있을 수 있으며 이로 인해 많은 지연 시간이 발생할 수 있습니다.

이미 엣지를 도입했으므로 정적 자산에만 CDN 기능을 추가하는 것은 매우 간단합니다(솔직히 모든 사이트에는 CDN이 있어야 합니다). 일단 구성되면 CDN은 초기 요청 시 개체 스토리지에서 이미지를 가져오고 동일한 지역의 방문자가 향후 요청할 때 이를 캐시합니다.

이미지 흐름은 다음과 같습니다.

1. 클라이언트는 상대를 기반으로 이미지를 생성하라는 요청을 보냅니다.

   
   

2. Edge 컴퓨팅은 해당 요청에 대한 이미지 데이터가 이미 존재하는지 확인합니다. 그렇다면 URL을 반환합니다.

   
   

3. 이미지는 URL과 함께 페이지에 추가되고 브라우저는 이미지를 요청합니다.

   
   

4. 이미지가 이전에 CDN에 캐시된 경우 브라우저는 해당 이미지를 거의 즉시 로드합니다. 이것이 흐름의 끝입니다.

   
   

5. 이미지가 이전에 캐시되지 않은 경우 CDN은 개체 스토리지 위치에서 이미지를 가져오고 향후 요청을 위해 이미지의 복사본을 캐시한 다음 이미지를 클라이언트에 반환합니다. 이것은 흐름의 또 다른 끝입니다.

   
   

6. 이미지 데이터가 엣지 키-값 저장소에 없으면 이미지 생성 요청이 서버로 전달되고 OpenAI에서 이미지를 생성하고 URL 정보를 반환합니다. 서버는 객체 스토리지 버킷에 이미지를 저장하는 작업을 시작하고, 이미지 데이터를 엣지 키-값 저장소에 저장하고, 이미지 데이터를 엣지 컴퓨팅에 반환합니다.

   
   

7. 새 이미지 데이터를 사용하여 클라이언트는 새 요청을 생성하고 위의 5단계부터 계속되는 이미지를 만듭니다.

콘텐츠 전달 네트워크는 배달 트럭(🚚)과 네트워크 신호(📶)로 표시되며, 개체 저장소는 상자 안의 양말(🧦📦) 또는 저장소에 있는 개체로 표시됩니다. 이 캡션은 분명하다고 생각하기 때문에 아마도 필요하지 않을 것입니다. 하지만 저는 제 이모티콘 게임이 너무 자랑스럽고 검증이 필요합니다. 나를 기쁘게 해주셔서 감사합니다. 계속하세요.

이 마지막 아키텍처는 확실히 조금 더 복잡하지만 애플리케이션이 심각한 트래픽을 처리하려는 경우 고려해 볼 가치가 있습니다.

짜잔

바로! 이러한 모든 변경 사항을 적용하여 고유한 요청에 대해 AI 생성 텍스트와 이미지를 생성하고 중복 요청에 대해 엣지에서 캐시된 콘텐츠를 제공했습니다. 그 결과 응답 시간이 빨라지고 사용자 경험이 훨씬 향상되었습니다(API 호출 감소).

저는 이러한 아키텍처 다이어그램을 의도적으로 다양한 데이터베이스, 엣지 컴퓨팅, 개체 스토리지 및 CDN 공급자에 적용할 수 있도록 유지했습니다. 나는 내 콘텐츠가 광범위하게 적용되는 것을 좋아합니다. 그러나 엣지 통합은 단순한 성능 그 이상이라는 점을 언급할 가치가 있습니다. 활성화할 수 있는 정말 멋진 보안 기능도 많이 있습니다.

예를 들어 Akamai 네트워크에서는 다음과 같은 항목에 액세스할 수 있습니다. 웹 애플리케이션 방화벽(WAF) , 분산 서비스 거부(DDoS) 보호 , 지능형 봇 감지 , 그리고 더. 하지만 이는 오늘 게시물의 범위를 넘어서는 것입니다.

그래서 지금은 읽어주셔서 큰 “감사합니다”라는 말을 전하고 싶습니다. 당신이 뭔가를 배웠기를 바랍니다. 언제나처럼 의견, 질문, 우려 사항이 있으면 언제든지 연락해 주세요.

읽어주셔서 정말 감사합니다. 이 기사가 마음에 들었고 저를 지지하고 싶다면 가장 좋은 방법은 다음과 같습니다. 공유하다 , 내 뉴스레터에 가입하세요 , 그리고 트위터에서 나를 팔로우하세요 .

원래 게시 날짜 austingil.com .