Google 어시스턴트 eBay 앱: Graph로 구동되는 대화형 커머스

• Machine Learning

편집자 주: 이 프레젠테이션은 Ajinkya Kale과 Anuj Vatsa가 2017년 10월 GraphConnect New York에서 진행했어요.

프레젠테이션 요약

Google Assistant용 eBay 앱은 Knowledge Graph로 구동되는 챗봇으로, 대화형 상거래를 지원해요. eBay 팀은 시스템을 만들면서 챗봇이 사용자에게 어떤 Next Question을 해야 하는지 결정하는 방법에 대해 고민했죠.

Natural Language Understanding(NLU)는 쿼리를 구성 요소 부분으로 나누는 데 사용돼요. 쿼리 유형으로부터 학습한 내용을 캡처하고 Transfer Learning을 통해 Knowledge Graph를 더욱 풍부하게 만들죠. 그들은 그래프가 미래의 AI라고 믿고 있어요. eBay의 경우 Neo4j는 Database 그 이상이에요. Knowledge Graph에서 Machine Learning을 강화하거든요.

eBay는 Google Cloud Platform 위에 Dockerized 시스템을 사용해서 배포하고 있어요. 원래 eBay는 하나의 컨테이너에서 모놀리식 Scala 서비스와 Neo4j라는 두 가지 서비스를 실행했는데요. 팀은 Microservice로 이전하고 Docker 모범 사례를 준수하기로 결정했어요.

한 가지 과제는 Data Model의 크기였어요. eBay는 Kubernetes의 알파 기능인 StatefulSet을 활용해서 앱 크기 조정을 통해 한 로케일(미국 eBay)에서 트래픽 증가를 지원하고 이를 추가 로케일(eBay Australia)로 확장할 수 있었죠.

전체 프레젠테이션: Google Assistant용 eBay 앱: 그래프 기반 대화형 상거래

오늘 이야기할 내용은 eBay의 가상 쇼핑 도우미에서 AI 기술의 백엔드로 Neo4j를 사용하는 것이에요.

아진키아 케일: 저는 Knowledge Graph와 관련된 연구 활동을 주도하고 있고, eBay의 신제품 개발 그룹에 소속되어 있어요. 저희는 최첨단 기술과 eBay 노력의 인공 지능 측면에 중점을 두고 있죠.

eBay는 약 1억 6천만 명의 활성 구매자와 약 110억 달러의 모바일 매출을 보유하고 있어요.

이베이에는 10억 개가 넘는 실시간 목록이 있다는 사실! eBay하면 중고 물품을 떠올리는 분들이 많지만, 실제로 eBay에서 판매되는 품목의 81%는 새 제품이라고 해요. 그리고 매주 모바일을 통해 거의 1,300만 개의 목록이 추가된다고 하니 정말 놀랍죠?

각 나라, 각 사이트마다 우선순위가 다르다는 점도 흥미로운데요. 영국에서는 3초마다 메이크업 제품이 하나씩 팔리고, 호주에서는 26초마다 결혼 관련 용품이 구매된다고 합니다.

Google 어시스턴트용 eBay 앱

Google Assistant용 eBay 앱은 Knowledge Graph를 기반으로 하는 챗봇이에요. 이 앱은 개인 쇼핑 도우미 역할을 하죠. 원래는 Facebook Messenger 플랫폼 내에서 쇼핑 도우미로 만들어졌지만, 지금은 Google Assistant에서만 사용할 수 있어요 (Facebook Messenger ShopBot은 종료되었답니다).

저희는 일반 검색과 Natural Language Search 간의 간극을 좁히기 위해 이 앱을 만들었어요. "아이언맨을 좋아하는 11살 아이에게 선물을 주고 싶어"와 같은 검색어를 입력하면 대부분의 다른 검색 엔진은 제대로 결과를 보여주지 못하죠. 일반 검색 엔진에서 자연어를 지원하는 검색 엔진으로 넘어가는 건 정말 어려운 문제거든요.

Google Assistant용 eBay 앱은 Natural Language Understanding (NLU)를 지원합니다.

대화형 상거래란 무엇입니까?

대화형 상거래는 기본적으로 매장에서 판매원과 대화하는 것처럼 에이전트와 상호 작용하는 시스템이에요.

예를 들어 운동화를 사러 가게에 가서 "신발을 찾고 있어요"라고 말하면, 판매원이 "그럼 그 신발은 무엇에 쓰실 건가요?"라고 물을 수 있겠죠. 그리고 신발의 용도를 말하면, 선호하는 브랜드, 색상, 사이즈 등을 물어볼 거예요.

이런 종류의 다중 회전 상호 작용은 일반 검색 엔진으로는 구현하기 정말 어렵답니다.

다음 질문을 알아내기

시스템을 만들면서 저희는 이런 질문을 던졌어요. "사용자가 플랫폼에서 항목을 검색하려고 할 때, 어떤 질문을 하는 게 가장 좋을까?". Api.ai, wit.ai 등 많은 봇 프레임워크가 있지만, 모두 규칙 엔진 기반이에요. 규칙을 입력하면 시스템은 그 규칙대로 작동하죠. 마치 "if-then-else" 구문과 거의 같아요.

eBay는 정말 다양한 상품을 제공하잖아요. 20,000개 이상의 제품 카테고리, 브랜드, 색상, 기타 속성 등 150,000개 이상의 속성을 가지고 있어요. 10억 개 이상의 재고 항목이 있는 eBay처럼 거대한 카탈로그를 규칙 엔진으로 지원하는 건 사실상 불가능하죠.

저희는 누군가에게 신발에 대해 이야기할 때, 그 사람이 다음으로 나이키나 아디다스 같은 브랜드를 떠올리는 인간 고유의 사고방식을 인코딩하고 확장할 수 있는 솔루션이 필요했어요. 사람들은 자연스럽게 그렇게 생각하잖아요. 어릴 때부터 쌓아온 지식 덕분이죠.

단순히 규칙을 인코딩하는 것보다는, 사용자가 찾고 있는 특정 의도를 고려했을 때 어떤 질문을 하는 것이 가장 좋을지 확률적으로 추론하는 문제에 더 가깝다고 판단했어요.

eBay에는 약 1,600만 명의 활성 구매자가 있어요. 검색 가능한 거의 모든 제품이 검색되었고, 사용 가능한 거의 모든 속성이 사용되었죠.

eBay의 핵심 사용자 행동 데이터를 바탕으로 확률 그래프를 만들어서 다음에 어떤 질문을 할지 대화를 유도할 수 있었어요. 바로 이런 곳에서 Graph Database가 활용되고 있는 거죠.

흥미로운 점은 Peter Norvig의 논문에서 Deep Learning이나 Machine Learning 시대에도 데이터가 얼마나 중요한지를 이야기한다는 거예요. 아무리 놀라운 알고리즘이 있어도 데이터가 없으면 할 수 있는 게 별로 없으니까요.

저희가 겪었던 가장 큰 어려움은 Machine Learning이나 Deep Learning을 통해 Natural Language Generation이 어떻게 구동될 수 있는지에 대한 많은 연구와 논문이 있었지만, 실제로 Deep Learning 기반의 대화 시스템을 상용화한 사례가 없었다는 점이었어요.

그래서 저희는 과거 사용자 행동 데이터를 활용해서 다음 사용자에게 적용하는 협업적 접근 방식을 기반으로 전문가 시스템을 구축했어요.

Natural Language Understanding을 사용한 Query 분석

이 다이어그램은 저희가 구축한 Natural Language Understanding 시스템을 보여주고 있어요.

지금 바로 Google Assistance에서 eBay 앱을 사용해 볼 수 있어요. 예를 들어 이런 Query를 입력하는 거죠.

"남편이 검은색 가죽 정장 구두를 새로 사야 하는데 80달러 미만으로 사고 싶어요. 뭐가 있나요?"

저희는 사용자 의도를 더 깊이 이해하기 위해 Query를 여러 구성 요소로 나눠요. Query에서 성별을 감지하는데, 실제 구매자의 성별을 사용할 수는 없죠. Query에서 성별을 확인해야 해요. 이 경우 여성이 남편을 찾고 있으니 성별이 남성인 것으로 감지되는 거예요.

여기서 의도는 욕구, 즉 쇼핑 의도를 의미해요. 그리고 아이템 조건이 있죠. eBay에서는 새 제품뿐만 아니라 중고 제품도 살 수 있는데, 이 분은 새 제품을 찾는 것 같아요. "검은색 가죽 정장 구두"는 찾고 있는 제품의 특징이고요. 그리고 재고를 필터링할 때 적용해야 하는 가격 같은 제약 조건도 있답니다.

아래는 eBay 앱 아래에 있는 그래프의 간단한 예시예요.

만약 쿼리가 신발에 관한 것이라면, 먼저 사용자가 찾는 성별이 무엇인지 데이터 마이닝을 하죠.

여성 신발은 남성 신발과 비교했을 때, 다음에 질문해야 할 속성이 달라요. 여성은 남성보다 브랜드에 더 관심이 많을 거고, 남성은 색상(거의 항상 갈색!)에 더 관심이 있을 수 있겠죠.

이런 확률을 기반으로 추론 방법을 결정하고, 기본적으로 현재 컨텍스트만 필요한 Markov 체인으로 변환해서 다음 질문을 던지는 거예요.

학습 전수 (Transfer Learning)

NLU는 쿼리에 대한 자연어 이해를 처리하고, 전자상거래 이해를 수행하는 부분이에요.

만약 누군가 "가지 폼포지트를 찾고 있어요"라고 말하면, 무슨 뜻인지 전혀 알 수 없죠. 하지만 과거 사용자 행동 데이터가 워낙 많기 때문에, 운동화 전문가라면 올바른 항목을 클릭했을 거예요.

해당 항목의 속성을 통해, 누군가 "가지 폼포사이트(Eggplant Foamposite)"라고 말하면 해당 제품은 운동화 카테고리에 있어야 하고, 제품 브랜드는 나이키이고, 주로 농구화로 사용되며, 제품 출시 날짜가 언제인지, 색상은 대부분 보라색이고 소재는 폼포짓(Foamposite)이라는 것을 알 수 있어요.

하지만 이 과정에는 정말 훌륭하고 독특한 점이 하나 더 있어요. 이 쿼리를 통해 "가지"가 "보라색"에 해당한다는 Knowledge Graph를 확인할 수 있다는 거죠! 과거 사용자 행동 데이터가 많지 않은 경우에도 적용할 수 있다는 점이 정말 멋지죠?

그래서 누군가가 "가지 아이폰 케이스를 찾고 있어요"라고 말한다면, 그 사람은 대부분 케이스에 있는 가지 사진을 찾는 게 아닐 거예요. 아마 보라색 케이스를 찾고 있을 가능성이 높죠.

이전 쿼리에서 Nike가 모든 가지 폼포지트에 보라색이라는 태그를 붙였다는 것을 알게 되었고, Knowledge Graph를 통해 가지가 보라색과 연관되어 있다는 사실을 학습했죠. 이제 누군가가 "가지 아이폰 케이스"라고 말할 때 무슨 뜻인지 전혀 알 수 없는 상황에서 이를 사용할 수 있게 되는 거예요.

이러한 유형의 전송은 정말 훌륭하고, 우리가 구축한 확률적 Knowledge Graph가 있기 때문에 가능한 거죠.

eBay ShopKnowledge의 아키텍처 개요

다음은 시스템 아키텍처의 개요예요.

우리는 전자상거래 데이터뿐만 아니라 Wikipedia, Wikidata, Freebase 및 DBpedia와 같은 다른 데이터 소스에서 제공되는 세계 지식 데이터를 포함하는 방대한 데이터 세트를 가지고 있어요.

Apache Airflow 스케줄러를 사용하여 이 데이터를 결합하고, Google Cloud 및 Spark를 통해 데이터를 Knowledge Graph 형식으로 가져오죠. 그런 다음 데이터는 결국 그래프로 모델링되어 에 저장돼요.

데이터베이스 그 이상

기술적으로 그래프는 대부분의 Graph Database 사용자와 마찬가지로 단순한 데이터베이스가 아니에요. BI나 분석 용도도 아니고요. 우리에게는 Machine Learning Knowledge Graph의 캐시로 사용되는 저장소인 거죠.

데이터가 Knowledge Graph Database 시스템으로 이동하면 이에 대한 그래프 추론을 수행하여 쿼리 이해, 항목 추출, 가격 예측 및 추세 결정을 강화해요.

이전 예에서는 추론이 어떻게 작동하는지 살펴봤죠. 그래프 구조에 데이터가 있으면 Google Cloud Platform 위에 Dockerized 시스템을 사용하여 배포해요. 배포 구조와 서비스에 대해서는 이 블로그의 뒷부분에서 설명할게요.

다음은 현재 Knowledge Graph에 있는 내용을 높은 수준으로 요약한 거예요.

우리는 약 5억 개의 nodes를 보유하고 있으며 현재는 약 200억 개의 relationships를 갖고 있어요. 우리는 전자상거래 데이터를 Wikidata와 결합하여 제품이 출시된 시기, 사람들이 따르는 다른 트렌드 등 더 많은 세계적 지식을 강화했죠. 상황은 계속 변하기 때문에 Knowledge Graph에 더 많은 지식을 추가해야 해요.

Machine Learning 측면도 있어요. 앞서 언급했듯이 우리는 그래프를 데이터베이스로만 사용하지 않고 확률적 그래픽 모델을 저장하고 런타임 시스템의 캐시로 사용해요.

우리는 그 위에 몇 가지 지도 모델을 구현했어요. 예를 들어, 겨울 재킷에 대해 이야기하고 있다면 eBay에 겨울 재킷 카테고리가 있기 때문에 스포츠 재킷을 원하지 않을 거예요. 실제로 겨울 재킷 카테고리에서 속성을 가져오기 위해 분류를 만들고 싶죠. 이는 그래프에도 존재하는 지도 모델이에요.

우리는 레이블 전파에 몇 가지 준지도 방식을 사용해요. 우리는 추세에 대한 그래프를 선별하는 전체 팀을 보유하고 있죠. 그래프가 너무 크기 때문에 그래프의 각 node를 관리하고 추세를 표시할 수 없어요. 추세를 사용하여 그래프의 하위 집합을 모델링한 다음 레이블 전파를 사용하여 이를 전체 그래프에 퍼뜨린답니다.

사용 사례: 가치는 무엇입니까?

최근 Google 어시스턴트에서 제공되었으며 시도해 볼 수 있는 멋진 사용 사례 중 하나는 'What Is It Worth?'예요. “eBay에 얘기하고 싶어요”라고 말한 다음, 가지고 있는 품목의 가치가 얼마인지 알아보거나 출시 예정인 최신 제품의 가격을 확인할 수 있죠.

"iPhone 8의 가격은 얼마입니까?"라고 말할 수 있어요. 또는 "내 주변에 이 낡은 백팩이 있어요. 이 특별한 모델이에요. 이 특별한 색상이에요. 뭘 살 수 있나요?"라고 말할 수도 있고요. 이는 Knowledge Graph를 통해서도 제공되는 기능이에요.

Neo4j: 데이터 조인의 종말

왜 Neo4j일까요?

처음에 관계형 데이터 세트를 좀 써봤는데, 데이터 세트가 많아질수록 JOIN이 계속 늘어나는 걸 금방 알게 됐어요. 그래서 "이제 JOIN은 잊어버리자. 전부 그래프에 넣어버리자! 새 데이터세트 추가하는 데 일주일에서 2주나 걸리던 파이프라인을 확 줄여보자!"라고 결심했죠. 덕분에 다시는 JOIN 때문에 골치 아플 일 없게 됐어요.

Neo4j는 이미 성능이 검증된 솔루션이에요. 프로덕션 지원도 훌륭하고, 툴링 시스템도 잘 갖춰져 있죠. 특히 대화형 브라우저와 시각화 기능 덕분에 실험하기가 정말 편했어요. 그리고 Graph Database 위에 그래프 알고리즘을 제공하는 유일한 솔루션이기도 하고요.

그래프는 AI의 미래입니다

저는 Emil의 의견처럼 그래프 기술이 인공지능의 미래라고 생각해요.

eBay의 AI 팀에 합류하기 전에 검색 관련 경험을 많이 쌓았는데요. 검색 시스템은 보통 자동 완성 시스템, 검색어 추천 시스템, 아이템 추천 시스템이 필요하잖아요? 이 모든 걸 그래프로 만들 수 있어요.

이걸 Machine Learning 모델 캐시라고 생각하면, 다른 시스템이 백엔드 인덱싱을 수행할 수 있어요. 모든 비즈니스 로직과 창의적인 부분은 추론을 담당하는 그래프에 넣고, 가져와야 할 항목만 백엔드 인덱싱 저장소로 보내는 거죠.

Neo4j 컨테이너화

지난 1년 반 동안 Neo4j를 사용하면서 어떤 발전을 이뤘는지, 그리고 Neo4j Database를 컨테이너화한 방법, Kubernetes를 사용해서 Google Cloud에 대규모 데이터 모델을 배포한 방법에 대한 주요 내용을 공유할게요.

신제품 개발팀에서 프로토타입을 많이 만들었는데, Neo4j가 우리 상황에 딱 맞아서 사용하기 시작했어요. 클라우드에 배포하는 것도 중요한 부분이었고요.

우리 기술 스택에는 Docker가 있고, Kubernetes를 사용하고, 백엔드에 다중 언어 서비스가 있어요. Scala, Java, Go로 작성된 서비스들이 있는데, 이 모든 게 문제없이 잘 돌아가도록 하고 싶었죠.

Docker와 Kubernetes가 필요한 이유

그렇다면 왜 Docker를 사용하기로 결정했을까요? Docker는 클라우드 환경에서 가벼운 컨테이너를 통해 애플리케이션을 구축, 제공 및 실행할 수 있는 아주 쉬운 방법을 제공해줬어요. 그리고 트래픽 양에 따라 컨테이너를 확장하거나 축소할 수 있는 최고의 오케스트레이션 레이어이기 때문에 Kubernetes를 사용하게 된 거죠.

초기 프로토타입을 만들 때는 거대한 모놀리식 Python 서비스를 사용하고 있었고, 단일 Python 서비스로 실행되는 다양한 모듈이 많았어요. 거대한 Python 코드 베이스를 가지고 있었는데, 그 중 하나가 Knowledge Graph 모듈이었죠.

컨테이너 관점에서 보면 Python 서비스와 Graph Database라는 두 가지 프로세스가 있었어요. 처음에는 모델이 꽤 작았기 때문에 어느 시점에는 Graph Database가 실제로 시스템의 로컬 호스트였죠.

거대한 Python 서비스의 문제는 많은 분들이 경험하셨겠지만, 전역 인터프리터 잠금 문제에 직면했다는 거예요. 이는 초당 몇 개의 요청만 처리할 수 있다는 의미이므로 더 많은 사용자에게 서비스를 제공하기 위해 더 많은 Pod를 생성했죠.

그래서 다시 돌아가서 모든 서비스를 개별 마이크로서비스로 분할해야 한다고 생각했어요.

데이터 과학 팀이 그래프 모델을 구축한 후, 그래프 모델을 기본 Docker 이미지로 만들었어요. 이를 Docker 이미지용 GitHub라고 생각할 수 있는 Google Cloud 저장소에 저장했죠.

서비스 배포 시, 이 Docker 파일이 배포되어야 하는 현재 기본 이미지를 참조하도록 했어요. 데이터를 다운로드하고 Graph Database를 생성한 다음, API 및 기타 모든 사용 사례를 제공하기 위해 데이터베이스 위에 Scala 서비스를 작성했죠.

이런 방식으로 그래프는 여전히 시스템의 로컬 호스트였고, Scala 서비스와 Graph Database라는 두 개의 프로세스가 실행되었어요.

이것은 몇 가지 면에서 우리를 제한했어요. 첫째, 모델이 거대해지면 모델 배포로 인해 병목 현상이 발생했죠. 둘째, 이러한 모델을 푸시하고 다운로드하는 데 많은 시간이 걸렸어요. 우리는 이 모든 경우에 효과가 있는 솔루션을 원했답니다.

이전 버전의 그래프에서는 여전히 Cypher 쿼리를 사용했고, 몇 초 정도의 지연 시간이 있었어요. 하지만 절차(procedures)로 전환하면서 지연 시간을 100밀리초 미만으로 줄였죠. 절차로의 전환은 기존 방식보다 25배나 개선된 결과였답니다.

Docker 원칙 준수

Docker 원칙 중 하나는 단일 컨테이너 내에서 여러 프로세스를 실행하면 안 된다는 건데, 이전에는 그렇게 하고 있었어요.

Scala 서비스와 Neo4j를 컨테이너 내의 프로세스로 실행하고 있었는데, 이 방식에서 벗어나고 싶었어요. Pod를 다시 시작해야 할 때 문제가 생겼거든요. 모델을 다운로드한 다음 Pod를 다시 시작해야 해서 병목 현상이 발생하곤 했죠 (아래 제한 사항 목록을 참고해주세요).

멀티테라바이트 모델 처리

시간이 지나면서 우리 모델이 수 테라바이트에 달하는 요구 사항이 생겼어요. 동시에 다른 지역에서도 서비스를 출시할 계획도 있었죠.

Google Assistant용 eBay 앱의 첫 번째 버전은 미국 전용이었지만, 이제는 호주 데이터 세트에도 제공되고 있답니다.

우리의 요구 사항 중 하나는 배포 시간을 최소화하는 것이었어요. 또한 이전 데이터 세트에서 새 데이터 세트로의 전환이 아주 매끄럽게 진행되기를 바랐죠. 최종 사용자는 우리가 새로운 데이터로 전환했다는 사실조차 알아채지 못해야 했으니까요.

그래서 컨테이너화된 솔루션을 선택하게 된 거예요. 많은 사람들이 자체 VM을 생성하고 VM을 모아서 서비스의 부하를 분산한다는 점을 고려했죠. 우리도 그렇게 할 수 있었지만, 이는 Kubernetes의 장점을 모두 포기하고 모든 로드 밸런싱과 로직 확장을 우리 스스로 처리해야 한다는 의미였어요.

자체 VM 생성이 이미 시도되고 검증된 모델임에도 불구하고, 우리는 Neo4j Graph Database를 컨테이너화하기로 결정했답니다.

대부분의 Kubernetes 앱은 기본적으로 상태 비저장(stateless)이에요. 즉, 스토리지가 없다는 뜻이죠. Kubernetes 앱에 스토리지를 제공하는 방법은 영구 볼륨(Persistent Volume)을 사용하는 거예요. 영구 볼륨을 사용하고 Pod가 매번 데이터를 복사하지 않도록 하려면 StatefulSet이라는 Kubernetes의 알파 기능을 활용할 수 있어요.

StatefulSet은 Pod를 시작할 때 이 Pod와 연결된 데이터가 모든 롤아웃에서 일정하게 유지되도록 보장해줘요. 데이터 전환을 처음 수행할 때만 데이터를 복사하고, Pod가 다시 시작되거나 하드웨어 오류가 발생하는 경우 연속적인 다음 Pod 초기화 시에는 데이터를 복사할 필요가 없죠. 이는 우리가 여러 개의 중복 사본을 피할 수 있다는 의미였어요.

Kubernetes를 통한 확장

우리는 이러한 기본 Docker 이미지에 모델을 "굽곤" 했다는 점을 기억하세요. Docker 이미지에 굽는 대신 Google 영구 디스크(PD)에 모델을 굽기 시작했어요. 배포 중에 해당 PD가 로컬 PD에 복사되는데, 이게 처음 발생하는 일이죠.

그런 다음 Kubernetes 서비스 정의를 통해 아래와 같이 Scala 서비스에서 Pod로 트래픽을 쉽게 라우팅할 수 있어요.

위의 예시에는 두 개의 Pod가 있고, Kubernetes 서비스 정의는 Pod가 언제 나타나는지 알고 로드 밸런싱을 수행해서 각 Pod로 트래픽을 라우팅해요. 트래픽이 증가하면 배포 스크립트를 2개에서 x개 Pod 수로 변경하기만 하면 Kubernetes가 확장을 처리해 준답니다.

위 다이어그램은 Neo4j US와 통신하는 Scala 서비스를 보여주는데요. 요구 사항 중 하나는 여러 로캘도 지원하는 것이었어요. 이 모델을 사용해서 우리는 로케일에 따라 Scala 서비스가 다양한 Kubernetes 서비스 정의를 라우팅하도록 작업할 수도 있었죠. 각 배포는 개별적이에요.

데이터사이언스팀에서 새로운 데이터가 나오면, 새로운 오리지널 PD를 만드는 전 과정을 거치게 돼요. 전환을 수행하면 StatefulSets는 순서대로 Pod를 종료하고 순서대로 초기화하죠.

테스트에서 포착하지 못한 데이터 손상이나 문제가 있는 경우 StatefulSet이 다음 작업을 수행하기 전에 Pod N이 작동 중인지 확인하므로 해당 특정 Pod를 중지할 수 있고 롤아웃도 중지돼요.

우리는 지금도 지속적으로 발전하고 있어요. 이건 정말 새로운 기능이었고, 제가 말했듯이 우리가 사용한 것 중 일부는 알파 기능이었답니다. 우리는 여전히 Kubernetes 팀과 협력하고 있으며 개선할 수 있는 방법을 찾기 위해 노력하고 있어요.

이 방법의 제한 사항 중 하나는 Pod를 처음 생성할 때 멀티 테라바이트 모델이기 때문에 초기화 단계에 많은 시간이 걸린다는 거예요. 데이터 복사로 인해 Pod 중 하나를 가동하는 데 몇 시간이 걸리죠. 배포 시간이 몇 시간이 아닌 몇 분 안에 완료되는 단계에 도달할 수 있기를 바라고 있어요.

Dave의 강연에서 영감을 받으셨나요? 등록하려면 아래를 클릭하세요! GraphConnect 2018이 9월 20~21일에 뉴욕 타임스퀘어에서 열리는데, 전 세계 최고의 그래프 전문가들과 소통할 수 있는 기회예요.

• Docker
• Ebay Shopbot
• Google Cloud Platform
• GraphConnect
• Kubernetes
• Machine Learning
• Natural Language Understanding
• Spark

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지