https://facebook.com/groups/graphql-kr logo
Join Slack
Powered by
This message was deleted.
# 잡담
s
This message was deleted.
h
firebase function에서 튀는건 cold start 문제가 아닐까요?
j
네 맞습니다. graphql 하나의 펑션으로 작성하고, 코드의 양이 커지다보니 코드가 올라가는데 시간이 걸리는 것 같아요. 근데 제가 람다같은걸 안써봐서 그러는데, 요청을 지속적으로 보내면 콜드스타트가 발생하지 않아야 하지 않나요? 가령 싱글 프로세스로 로드테스트를 해보면 중간에 하나가 튀곤 하네요.
h
어... 한번 웜업 된 뒤에는 일관적인 레이턴시를 보장해야 되는데요.
혹시 memory cache를 많이 사용하시나요?
j
네, 요청의 양이 적어서 우선순위가 뒤로 밀린건지는 모르겠지만, 요청이 중간에 튀는게 감이 잘 안잡히더라구요. 전체 코드를 다시 리로드 하는 것 같습니다.
캐시 없이 firestore를 직접 호출해서 쓰는데, 내부 로직이 메모리를 쓰진 않을 거라 예상하고 있어요.
h
중간에 함수 micro VM들이 죽으면 다시 시작하긴 할텐데.. 혹시 함수 내부에서 매번 리퀘스트마다 비싸게 재계산 하는 녀석은 없을까요? 이쪽 계열에서는 재사용가능한 녀석을 전역변수로 빼는 패턴을 선호하긴 합니다.
전체 코드를 다시 리로드하는 경우는 모든 microVM들이 죽었다(...)고 생각되는 케이스같은데
별도의 exception은 발생하지 않았나요?
j
음 근데 사실 Hello World만 응답으로 내려주는 펑션을 짜서 똑같이 테스트해볼때도, 중간에 하나씩 튀는걸 보긴 했습니다. 다만 코드의 양이 작아서 딜레이가 짧은 걸 봤었어요.
제 코드에선 튈때 10초가 걸리고, 헬로월드는 1초가 걸리는 차이 정도랄까요
그래서 최대한 최적화를 위해 웹팩으로도 말아보고 그런 시도를 해왔습니다.
h
어... 혹시 firebase function region은 서울인가요?
j
클러스터 자체가 도쿄였던거 같긴 한데요..
h
제 기억에 함수마다 리전을 설정하는걸로 기억하는데..
j
asia-northeast1 입니다. 서울리전이 나오기 전에 만들었던 것 같아요.
h
리전 문제는 아니겠네요
아 정말 궁금하네요 왜 레이턴시가 튀는지
도움되지 못해 죄송합니다 ㅠㅠ
j
아닙니다, 양질의 조언 잘 구했습니다. 말씀주신 방향으로도 디버깅을 해봐야겠어요!
h
지금 요청 100개를 동시에 보내면 모든 응답의 도착 시간이 다른가요?
j
제 로컬에서 측정하는거긴 하지만, 대부분의 리퀘스트는 비슷하게 측정되고 한두개만 튀긴 합니다.
나름 최적화를 시켰더니 10%에서 1%로 줄긴 했었습니다
h
아아 지금 말씀 주신건 웜업 된 이후죠?
웜업이후에도 1%정도가 튀는건 불안정하네요
j
아 100개를 동시에 보내진 않고, 블록킹 콜 100개를 순서대로 보냈습니다.
h
음 레이턴시가 튀는 녀석은 맨 처음 요청인가요? 아니면 요청 중간에 요청한 녀석인가요?
j
중간입니다
그래서 의아하더라구요
h
진짜 무섭네요
GCP버그같은데
모든 microVM이 죽는다는 것도 말이 되는 케이스는 아니라서요
j
제 코드는 아니더라도 같은 환경을 구축해본 뒤에 공유를 드리던가 해야겠네요
h
그러면 뒤에것도 느려야 하는데
j
노드는 10이었구요
h
음 구글 클라우드 함수가 노드버전 10이면 아마 베타긴 할텐데 설마...
j
..아.. 그걸 고쳐봐야겠네요
h
그거 요청 레이턴시 말고 다른 지표는 더 없나요? ㅋㅋ
h
아니네요. 노드 10이면 이제 베타에서 정식으로 넘어왔네요
12가 베타네...
j
익스프레스 미들웨어로 레이턴시 로그 찍어봐도 비슷했고
h
혹시 클라우드 펑션 외에 외부 서비스 레이턴시는 보장이 되는 상태인가요?
아웃바운드 네트워크를 통하는 녀석들이요
j
그 튀는 요청에는 무언가 코드를 다 로딩하는 로그가 찍히긴 했어요
음 slack api, sentry, kakao, fb, google, apple, android
이런 디펜던시가 있긴 했는데
디펜던시를 호출하지 않는 콜로 테스트해보긴 했었어요
h
아 외부서비스 영향은 아니라는 말씀이시군요.
h
그냥 요청 많이가서 인스턴스 확장되는 타이밍에 튀는거 아닌가요? 그럼 같은 테스트 시간 두고 테스트했을 때 일정하게 재현될 것 같은데
h
음 저는 그쪽에는 회의적인게
h
몇배수로 확장하는 식일테니 선형적이진 않을가ㅓ고
h
무료플랜을 사용하시더라도 microVM 엄청 많이 처음에 띄워서
TPS가 300이상 넘어가지 않는한
보기어렵지 않을까 싶어요
일단 AWS는 그런데 GCP는 좀 적게 띄우나 (..)?
h
TPS 적어도 일단 GraphQL 서버고 PQL 안쓰는 이상은 다른 api 서버보단 리소스 괴물같이 먹긴 하겠죠
스키마가 어마무시하게 크다거나
h
근데 지금 질문에서는 GraphQL 처리 외에도 hello-world 수준 애플리케이션에서도 발생한다고 하셔서요
h
엥 그런가요
gcp 질문이였군
j
네, 레이턴시의 차이는 없지만요
비슷한 환경을 구축해서 코드로 공유드리는게 좋을 것 같네요!
👍 1
h
일단 말씀주신 것 보면 GCP버그에 한표입니다 (..)
AWS Lambda에서는 본적없는 현상이에요
둘이 같은 Firecraker 쓸텐데
h
그 사실 재현되는 환경 만드시면 여기보단 GCP 지원팀에 직접 던지는게 빠를거에요.. .ㅋㅋㅋㅋ;
h
헐 근데 저도 지금 hello world 하나 만들어서 GCP에서 테스트해봤는데 재현되네요
이건 GCP 지원팀에 물어보는게 좋을듯하네요
TTFB받는데 갑자기 중간에 500ms 늘어나는 케이스가 있네요 10번 요청중에
j
헛 저도 같은 증상이었는데, 같이 고민해주셔서 감사합니다.
저는 그게 10s까지 가는게 고민이었어요
h
네... 아마 10s까지 간건 인스턴스 추가할당하는 시간이 맞는 것 같네요
j
제 코드의 크기에 따라 다르더라구요. 웹팩으로 실험을 좀 했었습니다.
h
근데... 저로서는 잘 이해가 안되네요. 이러면 너무 일관성을 못지키는 것 같은데
j
정 안되면 앱엔진으로 갈아탈까 고민하고 있었어요
h
이게 AWS Lambda처럼 켜놓을 인스턴스 숫자도 설정하는게 안되네요 콘솔에서는
Serverless로도 제어못하는지 알아보는걸 추천드립니다.
App Engine은 정말 추천드리지 않습니다. (...)
배포하는데 훨씬 오래걸리고... 테스트하기 어려울거에요.
와.. 심지어 GCP cloud function은 concurrency 예약도 안되네요...
에고.. 제가 GCP에서 제대로 해본적이 없어서.. 나중에 해결하시면 공유부탁드릴게요!
h
클라이언트 엔지니어로서는 Optimistic update pattern 을 추천드립니다. ㅋㅋㅋㅋㅋㅋㅋ;
j
넵 제가 아직 퇴근을 못하고 있어서 응답이 늦었습니다.
😭 1
optimistic update pattern은 제가 검색을 못하는건지 어떤 내용인지 감이 잘 안잡히네요
h
https://story.pxd.co.kr/1193 이 글이 좋아요
h
낙관적 업데이트는 일반적으로 클라에서 API 응답이 오지 않더라도 클라에서 선반영 하고 문제가 생기면 나중에 사용자한테 알려주는 UI 패턴이에요.
j
아 보통 비동기적인 프로세스를 태울때 쓰는 방법이군요
command의 경우엔 좋을 것 같네요
h
요즘은 널리 쓰이는 인지심리학적 해킹이죠. 사실 UI 자체가 transactional 해야 하는 케이스가 생각보다 없어서 별 문제 안될수도 있고
j
공유해주신 아티클은 양질의 내용 같네요. 시간내서 읽어보겠습니다
h
graphql client 는 기본적으로 이 패턴과 stale-while-revaildate를 기본으로 두고 있어서
잘 활용하면 응답 느린게 크게 문제 안될수도 있습니다 (더 유용한데 먼저 시간을 쓰실수도…)
j
제가 클라개발을 안하고 있어서 조심스럽긴 하네요.
h
네 뭐 사실 offline capability 같은거 고려하면 레이턴시가 불안정하다 못해 끊기는 경우까지 고려해야되는것도 있긴 해서요
물론 문제해결이 훨씬 복잡해지겠지만 ㅋㅋ
j
stale-while-revalidate 이라는 키워드도 오늘 얻어갑니다😄
h
복잡해진다기보단 사고방식이 바뀌죠 ㅋㅋㅋㅋ
뭐 앱개발하시는 분들이면 이미 익숙하실수도 있고
j
개인적으론 cqrs 같은 패턴이랑 비슷하게 느껴지네요
h
(이미 로컬에 db가 있을수도 잇꼬)
h
그렇게 생각할 수도 있겠네요 event driven하게 처리하는 서버랑 비슷하네요 ㅋㅋ
h
그거 자체가 cqrs의 특성인지는 저는 잘 모르겠는데
사실 graphql 은 스펙자체로 이미 쿼리랑 커맨드가 분리되어 있지만 아무도 event driven 하게 구성 안해요 (왜지)
아 3-factor app 은 좀 비슷하네요 이게 트렌드를 타는지ㅡㄴ 모르겠지만
j
여튼 여러모로 1. 클라우드 서비스에 대한 경험이 없고 2. 서버리스에 대한 경험이 없고 3. grapgql에 대한 경험이 없는 상황에서 4. node를 프로덕션 운영 경험이 없다보니.. 많은 삽질을 해오고 있습니다😭
h
아 ㅋㅋ 나머지 더 얘기할 주제 있으면 #잡담 에 꺼내시죠
j
시간이 많이 흘렀네요, 바쁘다보니 이 문제에 신경을 많이 안쓰다가 최근에 다시 찾다보니 제가 문제라고 생각하는 `10초의 cold start`는 거대한 로직의 graphql가 문제가 아니라, @google-cloud/firestore 에 접근하는 grpc에 대한 이슈더라구요. https://github.com/saasify-sh/google-cloud-grpc-issue https://github.com/googleapis/google-cloud-node/issues/2942 위 스레드를 다 읽진 않았지만, 관심있으신 분들을 위해 남겨놓습니다 🙂
아 그리고, App Engine 혹은 Cloud Run 으로 갈아타려고 합니다. (뭐가 됐건 gcp 위에 살아있는 서버를 띄워놓으려구요..)
👍 2
Open in Slack
PreviousNext
Powered by