곽철용 짤만 4번은 봄...
- Multi-Tenancy: 싱글 클러스터 도는 머신에서 에서 여러개의 네임스페이스를 이용하여 자원을 유동적으로 공유하는 방식.
- Bare-metal: GCP나 AKS처럼 별도의 전용 가상화/오케스트레이션 서비스를 사용하지 않고 직접 서버에 구현하는 방식.
- 하나의 머신/클러스터 안에서 여러 서비스를 돌리다보니 특정 서비스에서 자원이 남을 경우 다른 서비스로 자원을 재분배할 수 있음. 스케일 업/다운이 쉽다는 것. → 공개할 Docker-swarm이 오히려 여기에 적합할 수 있음.
느낀점:
- 네이버에서도 Naver Container Cluster(NCC)를 운영중. 다중 서버를 운영하는 입장에서 오케스트레이터 사실상 필연적. + NCC도 nginx대신 traefik사용!! + helm그래서 이번주 목요일 발표 내용 중요!
- 2016 년 docker swarm → 2018년 k8으로 재전환: 아마도 생태계 문제 또는 이전 버전에서의 버그
- k8/DS에서 IP를 사용하지 않고 dns를 통한 별도 호스트명으로 접근하는데, 네이버에서는 ACL 이슈로 real IP 사용. 이 과정에서 각종 헬퍼를 작성해서 사용한 것으로 보임.
- 네이버에서도 팀별 k8s이해도가 다르다보니 필요한 리소스 요청들을 제때에 하지 못하고 있음. 교육이 제일 큰 문제. 이건 목요일에 재언급 예정.
다중 웹뷰: 미리 다른 웹뷰를 열어놓아서 스와이프시 다른 웹뷰를 보여주는 방식. 다른 페이지로 넘어갈때 랙이 줄어든다
- 조심해야하는 것: 동일한 css를 매번 parsing, 서드파티 광고로 인한 트래픽
- 성능지표를 재정립하는 것이 쓸모있음: W3C navigation timing API를 바탕으로 네이버만의 기준을 만들었음.
느낀 점:
- 준비해놓은 내용을 읽기만하고 별로 새로운 insight가 없음...초반에 다중웹뷰에 대한 이야기를 몇분간 하다가 사실상 SEO보는 방법 이야기로 넘어가버림.
- 주로 whale브라우저 분석툴을 가지고 최적화를 진행하는데, whale이 어디까지나 크로미움 기반의 다른 브라우저라는 것을 염두에 두면 별로 의미 없을 듯. 툴 자체의 애널리틱스 등 간섭이 있을 것이기 때문에
- blameless, fact based Post-mortem이 핵심: 기준포맷 필요
- 장애 히스토리 아카이빙
- 비상상황 대응플랜 정의
- 같은 오류에 대한 누적 오류가 얼마나 되는지 확인 → sentry quota 확보로 해결
- github issue 로 버그 보고 → jira에 태스크 등록후 대응 태그 추가 → 완료후 issue close
- 경보 피로 줄이기
- 장애 대응용 DV가 필요하며 팀원이 모두 대시보드에 접근할 수 있어야함
느낀 점:
- 원인 파악하기 전까지 시간을 벌 수 있는 자동 대응시스템이 있어야 됨. 프론트에서는 어떻게 대응할 것인가? 특정 버전에 자동 롤백 적용?
- 기술적으로는 강연에 어울리지 않는 기초적인 내용이었지만, 체계적인 장애 대응에 대해서는 생각해 볼 점이 있음. 특히 lvup.gg는 장애 대응이 아직까지도 체계적이지 못함.
- transaction이 요구되지 않는 작업에 한하여 네이버도 몽고디비가 빠르고 scalable하다고 여긴다.
- 통합검색 1초 rule
- index속도 올리기
- 컬렉션당 인덱스 수를 줄여야 함.
- index prefix를 이용해서 index를 compound index 형태로 묶어버려야 함.(만들때 인덱스 방향도 제시) 대신 항상 주요 index에 대한 query가 공급이 되어야만 나머지 index도 공급이 됨.
mydb.createIndex({ aaa: 1, bbb: 1, ccc: 1})→.find({ bbb: 'xxx', ccc: '000' })작동 안함.find({ aaa: 'ooo' })작동 함. - compound index 형태로 묶어버리면 소팅할 때에도 항상 순서대로 소팅이 되어야 함. 인덱스의 소팅이 모두 같은 방향으로 이루어져야 함.(인덱스를 만들때도 마찬가지)
- 하나의 컬렉션을 여러 컬렉션으로 나누자
- thread를 이용해 document upsert하면 속도는 빠르지만, transaction 처리가 필요할 경우 사용 불가
- 몽고db 4.0 업데이트 꼭할 것
- 느려질때 explain을 이용해서 태스크를 체크할 것(당연한 이야기)
- 혹시 인덱스가 안 먹는 이유는 query planner 때문. 무조건 101개 까지 가장 좋은 결과가 나오는 query shape를 캐싱함. → 쓸모 없는 인덱스를 지워야 함
느낀 점:
- 이것도 거의 매뉴얼에 있는 내용 다시 읽는 수준. 그래도 인덱스를 자주 사용하지 않기 때문에 개념정리 정도로 생각하면 의미는 있었음.
영양가가 너무 없어서 듣다가 중간에 빠져나옴. 거의 프론트 입문서 내지는 2019년 프론트 현황 리뷰 수준.
- java에 비하여 디버그가 어렵다고 하는데 debug breakpoint나 inspector 강제 모드 설정 가능한데?
- pinpoint - APM = Application Performance Management
- 원래 java용 apm이었다가 요청으로 javascript 지원하게됨.
- anon function:메서드 명 대신 줄번호 표시 기능 구현 예정 + 주요 라이브러리 몽키패칭 아직 전부 이루어지지 않았음. JS에서는 아직 사용 어려울수도 있음.
- 핀포인트 자바스크립트 api는 올해 12월 말쯤에 공개를 목표로 하고 있음.
- 몽고db사용해도 사용할 수 있음(몽고코어를 래핑하고 있음)
- 성능 저하에 대한 QNA: 핀포인트 사용시 성능 10프로정도 저하 예상한다고 답변.
느낀점:
- js는 sentry 사용해도 되는데 지금 상황에서 pinpoint를 사용해야할 이유? 물론 UI관점에서는 pinpoint가 더 나은점도 있지만 api도 아직 풀리지 않았고, 툴의 효용성이 검증되지 않음.