[ 9장 웹크롤러 ] 웹페이지의 내용을 수집해야 한다 이때 예의있게 수집해야 하는 것이 포인트다 즉 한 번 요청한 대상에 대해 되도록 다시 요청하지 않는다 해당 페이지 URL을 해시 등으로 변환한 값을 내부적으로 지니게 한 뒤에 포함여부를 조사하여 (해시 연산) 이미 방문했는지 여부를 알아낸다 그리고 DFS로 접근하면 안됀다! 깊이가 무한히 반복되는 덫 사이트가 있을 수 있다! 이런곳에 접근하면 크롤러가 빠져나올 수 없다... 너비 우선 탐색으로 접근하자 [ 나온 키워드들 ] 웹크롤러와 웹스크래핑 웹크롤러는 페이지를 계속 탐색해 나가면서 indexing을 해나간다 (주로 검색 엔진에 사용) 웹스크래핑은 계속 탐색해나가지는 않으면서 컨텐츠 내용을 수집한다 출처: https://www.baeldung.com..

얼마전 대규모 스터디에서 가상 노드 공간 변화의 비에 대해 공부한 적이 있었다 이론에 따르면 가상 노드의 갯수를 늘릴 수록 데이터가 더욱 더 고르게 분포된다는 것이었다 이 이론을 보면서 느낌이 왔다, 간단한 수학으로 어느 정도 고르게 분포가 되는지를 알아낼 수 있다는 것을... 즉, 나는 이 비율을 숫자로 계산을 하고 싶다 실제로 증명을 해보니 어려운 수학은 들어가지 않았다 자 같이 증명해보자 > n이 1일때 1+1/1 = 2 책에서는 2라고 나온다! 가상노드가 세 개일 경우 (n이 4일때) 1 + 1/4 = 5/4 = 125% 역시 책에서 나온 것과 일치한다 (증명완료)

요새 가상 면접 사례로 배우는 대규모 시스템 설계 기초 스터디를 하고 있다 배운 점이 많아서 정리를 해보았다! 1장 사용자 수에 따른 규모 확장성 수평적 확장을 하는 이유는 수직적 확장에는 한계가 있기 때문이다 성능 (CPU, Memory) 장애시 대응 문제 DB의 수평적 확장은 특별히 샤딩이라 한다 아래와 같은 문제들이 생긴다 재샤딩(resharding) DB 추가 불균형으로 샤드 키 재분배가 필요할때 유명인사(celebrity) 문제 조인 비정규화로 하여 하나의 테이블에서 질의가 수행될 수 있도록 한다 메시지 큐 서비스 또는 서버 간 결합이 느슨해짐, 규모 확장성을 보장 2장: 개략적인 규모 추정 Log Scale L1, L2 캐시 접근 1ns 뮤텍스 락 락/언락 100ns RAM 접근 100ns i..

좋은 테스트란 무엇일까? 우아한테크코스에 있던 "A군"의 말이 생각난다... "최근 구조 하나를 바꿨어. 신규 기능을 하나 추가할 때마다, 코드가 n제곱씩 늘어나더라고? 그래서 각이다 싶어 상태패턴을 도입했지... 그랬더니 테스트가 60개 깨지네?" 무언가가 잘못됐다고 생각했다... 이 불편함의 근원에 대해 성실하게 조사해봤었어야 했는데 당시에는 무척 바빠서 그러지 못했다 그로부터 1년 가까이 지난 후 시간이 있을 때마다 테스트에 관한 책을 조금씩 읽어봤다 저자가 수학이란 학문을 좋아하는 것 같다 책에서 그런 느낌을 물씬 받았다 어떤 공리와 비슷한 것들을 정의해 놓고 그 위에 이론과 생각을 차곡차곡 쌓아나간다... 다행히 이론적이기만 한 책이 아니라 실용적인 관점에서 접근한 책이다 이게 가장 중요하다고 ..

예를 들어 회원의 정보를 반환할 때, 해당 회원에 대한 상품 목록이 필요하다면 회원 서비스는 주문 서비스에 요청을 해야한다 Http Client 정보를 가져오는 것(GET)은 Http Client를 이용하며 크게 3가지 있다 - RestTemplate - FeignClient - WebClient 이 세가지는 다른 곳에도 많은 설명이 있기에 간단히만 짚고 넘어가자 RestTemplate 전통적인 Http Client, Deprecated 한다는 얘기가 있으나, 취소된 것으로 보인다 (토비님 영상[ https://youtu.be/S4W3cJOuLrU ]) FeignClient 넷플릭스에서 만든것이고 인터페이스로 보다 더 쉽게 사용할 수 있다 WebClient 앞선 두개와 달리 비동기 요청이 가능하다. We..

설정 정보 반영하는 방법 세 가지 1. 서버 재기동 2. Actuator Refresh 3. Spring Cloud Bus 1 -> 2로 가면서 동적으로 설정 정보 변경이 가능하나 각 서비스에 대해 해줘야 한다 3은 일괄 적용 가능 Cloud Bus 개념 클라우드 버스 자체는 애플리케이션들 사이의 상태 변화를 감지하고 이벤트를 전파해서 전체 시스템 간의 상호작용과 동기화를 하는 것을 뜻한다 수단은 메시지 브로커(RabbitMQ, Apache Kafka)(AMQP)를 사용해서 이벤트를 송수신한다 강의에서는 설정 정보를 애플리케이션들에 일괄 반영(broadcast)하기 위해 사용했다 Erlang, Rabbit MQ 설치 역시나... 한번에 되지 않았다 Rabbit 이전 버전 installer 를 못찾아서 결..

yaml 등 환경 설정 정보를 각각의 Micro Service가 아닌 외부에서 관리한다 또한 재기동하지 않고 동적으로 환경 설정 정보를 반영할 수 있다 재미있게도 Config server는 spring.cloud.config.server.git.url을 넣지 않으면 기동이 되지 않는다. (.git디렉터리 존재해야 하고 그 안에 remote 등의 정보도 있어야함... 즉 완전한 .git이 필요하다) 상대, 절대 주소 spring: application.name: config-service cloud.config.server: # git.uri: 'file://${user.dir}/../../../../leedowon-msa-spring-cloud-configuration' // 상대주소, ..의 의미를 인..

JWT.IO JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. jwt.io 내용 로그인 하면 User 서비스에서 인증 토큰(JWT)을 발급한다 권한이 필요한 API 요청은 API Gateway의 토큰을 해석하는 필터가 처리한다 인증이 이루어지는 순서는 아래와 같다 - 로그인 시도: AuthenticationFilter.attemptAuthentication - 시큐리티의 유저 정보로 변환: UserDetailsService의 구현체.loadUserByUsername - 인증 성공 후처리: AuthenticationFilter.successfulAu..

Section 3. E-commerce 애플리케이션 서버 종류 (마이크로서비스의 약어로 MS를 사용) Eureka Server: (Registry Service) MS 등록 / 검색 API Gateway Server: (Routing Service) MS 부하 분산 / 서비스 라우팅 Config Server: (Configuration Service) MS 설정 정보를 동적으로 변경 Queuing System: MS 간 메시지 발행 및 구독 (ex. kafka) Section 4. Users Microservice-part1 Greeting 출력 2가지 방법 Environment env.getProperty("greeting.message") ?: "No Message" Bean + Value @Comp..

section 0. Microservice와 Spring Cloud의 소개 MSA 이걸 도대체 왜 할까? DB에 트랜잭션 잠금 등으로 시스템이 전면 마비가 되어버린다... 리뷰로 DDOS 공격 받듯이 요청이 왔는데... 주문이 마비 되어 버린다.. ㅠㅠ 일반적으로 Scale Out보다는 Scale Up이 더 저렴하다 MSA... 어떻게든 전면마비, 성능 문제, 확장 문제로부터 자유로워지고자 만들어진 시스템 ... section 1. Service Discovery Service Discovery: 서비스를 찾아서 탐색한다. 예) localhost:8001, 8002 등 각각 다른 서비스를 등록 localhost:8001 -> localhost/order 등 Discovery Service - Eureka..