전체 글 (77) 썸네일형 리스트형 로그에 클래스, 메소드명 자동 출력하기 언어: JAVALogging Framework: logback팀 컨벤션 혹은 원활할 디버깅을 위해 로그에 클래스명과 메소드명을 출력하는 경우가 있다.가장 쉬운 방법은 로그에 하드코딩으로 집어넣는 방법일 것이다.log.info("[Class][Method] Message occurred.")하지만 클래스, 메소드명이 바뀔 때마다 수동으로 챙겨줘야하는 불편함이 있다.그래서 클래스, 메소드명을 자동으로 출력할 수 있는 2가지 방법을 소개한다.log.info("method called");2024-06-22 18:07:53.409 INFO 7905 --- [ main] d.h.s.methodlog.MethodLogService : [MethodLogService][log] method called① 애노테이션으.. [정리] 그림으로 배우는 리눅스 구조 추천한다! 그림도 많아서 리눅스의 전체적인 흐름을 이해하는데 어렵지 않았다.-리눅스는 커널이라는 핵심 프로그램과 그 외로 나뉜다.커널이 하는 일접근제어, 명령 순서 제어, 자원 배분, 공유프로세스가 저장 장치에 직접 접근하면 명령 순서 같은 게 깨질 수 있음. 그래서 커널을 통해 간접 접근 하도록 한다.프로세스 스케줄링메모리 관리장치 접근cpu 모드 2가지커널 모드: 명령을 실행하는 데 아무 제약이 없다사용자 모드: 명령 실행에 제약이 걸린다.시스템 콜시스템콜을 호출하면 사용자 모드에서 커널 모드로 변경이 돼 호출 처리가 된다.OS 라이브러리OS 가 미리 공통된 기능을 묶어 라이브러리를 제공한다.표준 C 라이브러리 (libc)ISO(국제 표준화 기구)에서 정한 표준 라이브러리가 있다.리눅스는 GNU 프로.. [아호코라식 (Aho-corasick) 알고리즘] 논문 이해하기 (2) - 데이터 구축 이전 글에서는 아호코라식 알고리즘의 검색 과정에 대해서 알아보았다. [아호코라식 (Aho-corasick) 알고리즘] 논문 이해하기 (1) - 검색 과정 아호코라식 알고리즘은 문자열을 검색하는 알고리즘이다. 검색할 단어가 10개 일 때 검색 대상 문자열도 일일이 10번 탐색하는 게 아니라 찾을 검색어가 아무리 많아도 한 번만 탐색하여 결과를 elsboo.tistory.com 이번 글에서는 아호코라식이 구성하는 세 개 함수 goto(), output() , failure() 의 데이터를 구축하는 법에 대해 알아보자 함수 데이터는 어떻게 만들까? goto() 검색 대상 단어들 [he, she, his, hers] 을 Trie 자료구조로 표현하는 게 목표이다. 문자 하나를 간선(-), 문자의 state 를 정.. [아호코라식 (Aho-corasick) 알고리즘] 논문 이해하기 (1) - 검색 과정 아호코라식 알고리즘은 문자열을 검색하는 알고리즘이다. 검색할 단어가 10개 일 때 검색 대상 문자열도 일일이 10번 탐색하는 게 아니라 찾을 검색어가 아무리 많아도 한 번만 탐색하여 결과를 얻을 수 있다. 시간복잡도가 O(n + m + z) 로 제곱이나 log 가 붙는게 아닌 선형적으로 증가하므로 속도가 빠른 검색 알고리즘에 속한다. n : 텍스트의 길이 m : 모든 패턴의 총 길이 z : 텍스트 내에서 발견된 패턴의 총 출현 횟수 ※ 용어 정리 - 텍스트, 패턴 필자는 논문이나 구글링을 할 때 많이 출현하는 용어 텍스트와 패턴의 의미가 헷갈렸었다. 💡 텍스트 → 검색 대상 문자열 or 단어들 패턴 → 검색어 로 이해하면 쉽다. 예를 들면 텍스트와 패턴이 아래와 같을 때, 💡 텍스트: [사과, 오렌지, .. [9] 커스텀 플러그인을 이용한 ES 커스터마이징과 실전 운영 (끝) 플러그인을 elasticsearch-plugin install 로 설치하면 플러그인.zip 파일을 풀어 plugins/[플러그인명] 디렉토리에 생성한다. 플러그인 최소 3요소 본체 jar 파일 plugin-descriptor.properties elasticsearch.version : 마이너까지 일치해야 한다. plugin-security.policy : 플러그인이 요구하는 추가적인 권한 (이외 다른 파일은 메인 플러그인과 의존 관계 파일이다) 플러그인 개발 시 유의 사항 버전에 종속적이라 버전 올리면 호환되게 맞춰야 한다. 플러그인 문서는 적은 편이라 ES 코드 읽으면서 개발해야 한다. 라이선스 유의해햐 한다. X-pack 유료 플러그인 코드를 복붙해서 쓰면 위반이다 플러그인 제작 아래처럼 동작하는 .. [8] 엘라스틱서치의 내부 동작 상세 알아두면 검색 성능은 높여야 하는데 당장 확장할 리소스가 없을 때 써먹을 수 있다. 데이터 분산 처리 과정 쓰기 요청이 들어왔을 때 동작과 동시성 제어 쓰기 전체 흐름 조정 단계(coordination stage) → 프라이머리 샤드 단계(primary stage) → 복제 단계(replica stage) 쓰기 요청이 들어오면 라우팅을 통해 인덱스의 몇 번 샤드로 작업을 보낼 지 정하고 (조정 단계), 노드가 프라이머리 샤드한테 작업을 넘겨주고 (프라이머리 샤드 단계), 프라이머리 샤드는 요청이 문제가 없는 지 검증하고 로컬에 요청한 쓰기 작업 수행하고 작업 완료되면 레플리카 (in-sync 복제본) 샤드에 병렬로 요청을 넘긴다 복제받을 레플리카 샤드 목록은 마스터 노드에서 관리하고 있고 in-sync .. [7] 운영 도중 발생하는 장애 대응 장애 탐지를 위한 지표 수집 및 모니터링 지표 수집 메트릭비트: 여러 서비스의 메트릭 데이터를 주기적으로 수집해 ES, logstash, kafka 등으로 넘김) 각 노드마다 메트릭비트 있는 것보다 한 클러스터에 한 메트릭비트로 수집하는것을 공식문서에서는 추천한다. ※ 메트릭비트 설치는 책 참고 모니터링용 클러스터 구축 모니터링용 ES 와 키바나를 별도로 구성한다. 메트릭비트 + 키바나 그 다음에 보안 적용을 위해 elasticsearch-xpack, kibana-xpack 어쩌고 하는데 잘 모르겠다.. 메트릭비트 + 키바나 조합 사용하면 키바나에 자동으로 모니터링 대시보드가 생성되는 것 같다. 키바나 얼럿이나 웹훅은 유료 버전이다. 메트릭비트 + 그라파나 -얼럿이나 웹훅 무료로 사용 가능 -지표는 메트.. [6] 클러스터 운영 클러스터 설정 GET _cluster/settings -persistent: 클러스터를 full restart 전체 재시작해도 유지된다. path.data 내 파일로 저장됨 -transient: 전체 재시작하면 내용이 사라진다. -설정 적용 우선순위: transient > persistent > config/elasticsearch.yml -지정한 설정 제거하려면 null 로 지정해주기 -공식 가이드는 transient 는 사라져서 추천 안 함 _cat API ‘compact and aligned text’ ** GET _cat/health?v ** GET _cat/health?format=json [ { "epoch" : "1701005989", "timestamp" : "13:39:49", "clu.. [5] 서비스 환경에 클러스터 구성 노드 설정과 노드 역할 노드 역할 https://www.elastic.co/guide/en/elasticsearch/reference/7.17/modules-node.html -master-eligible node(마스터 후보 노드) : 마스터 후보 중에서 선거를 통해 마스터 노드가 선출된다. 클러스터 관리, 인덱스 생성/삭제, 어떤 샤드를 어떤 노드에 할당한 것인지 정한다. -coordinating node(조정 노드): 노드는 기본적으로 조정 역할을 수행한다. mode.roles:[] 를 empty 로 두면 조정 역할만 수행한다. (1단계 scatter: 요청을 데이터 노드로 분산시키고, 2단계 gather: 결과 모으기) -remote_cluster_client: 다른 클러스터에 클라이언트로 붙을 .. [4] 데이터 다루기 색인 API PUT [인덱스명]/_doc 덮어쓰기 허용 PUT [인덱스명]/_create 덮어쓰기 금지 refresh 검색 가능하게 만들기 true: 색인 직후 refresh 하고 응답을 반환한다. → 단점: 너무 작은 세그먼트를 많이 생성해 성능 저하와 병합 부하 커짐 wait_for: index.refresh_interval (기본값 1초)만큼 기다린다. refresh 대기하는 문서가 index.max_refresh_listeners 값(기본값 1000) 이상이면 바로 refresh 한다. false: refresh 하지 않는다 조회 API GET [인덱스명]/_doc/[_id] , GET [인덱스명]/_source/[_id] refresh 기다릴 필요 없이 바로 확인할 수 있다! 업데이트 API d.. [ElasticSearch] synonym_graph 의 start_offset, end_offset, position, position_length 이해하기 엘라스틱서치의 _analyze 는 analyzer 분석 결과를 확인할 수 있는 API 이다. explain:true 옵션을 주면 토큰들의 위치 관계를 파악할 수 있는데, 특히 synonym_graph 토큰 필터가 적용된 analyzer 에서는 동의어가 포함된 토큰 관계를 이해하는데 유용하다. explain:true 에 포함된 필드 중 start_offset, end_offset, position, position_length 를 분석해 토큰들 간의 연결 관계를 파악하는 법을 확인보려한다. 이 블로그 글은 ES 공식 문서 초반 부분에 대한 자세한 설명이 될 것이다. In order to properly handle multi-word synonyms this token filter creates a gra.. [3] 인덱스 설계 23.11.6 [[대규모 음악 데이터 검색 기능을 위한 Elasticsearch 구성 및 속도 개선 방법]] 인덱스 설정 number_of_shards -한 번 지정하면 reindex 하지 않는 한 설정 바꾸기 어렵기 때문에 신중하게 설계해야 한다. 클러스터에 샤드 수가 너무 많으면 → 색인 성능이 감소한다. 인덱스 당 샤드 수를 너무 작게 하면 → 장애 상황 등에서 샤드 복구에 많은 시간이 소요되고 클러스터 안정성이 떨어진다. -기본값이 7 버전 미만은 5였는데 7부터 1로 변경됐다. number_of_replicas -인덱스 생성 후에도 동적으로 변경 가능하다 http://localhost:9200/_settings { "index" : { "number_of_replicas" : 0 } } 리플리카.. [2] 엘라스틱서치 기본 동작과 구조 23.11.3 코디네이터 노드 역할 클라 요청을 받아서 데이터 노드에 요청을 분배하고 클라에게 응답을 돌려준다. 루씬 flush 시스템의 페이지 캐시에 데이터를 쓴다. 이 때부터 세그먼트가 되며 검색가능한 상태가 된다. https://ddongwon.tistory.com/56 page cache 우리가 컴퓨터를 사용할 때, CPU는 사용을 적게 할수록 성능이 좋아진다.(발열관련 문제) 하지만, 메모리는 사용을 적게 하거나 빵빵하게 사용한다고 해서 컴퓨터 성능에 영향을 주지 않는다. 이런 특징을 이용해서 메인 메모리(램)의 남는 공간을 활용해 페이지 캐시(page cache)라는 메모리 공간을 마련해 놓는다. 이 공간은 파일 I/O의 성능을 향상시키기 위해 사용되는 것으로, 사용된 파일의 내용을 저장해 놓.. [11] 33~34 사례 연구: 비디오 판매 23.11.4 [33] 사례 연구: 비디오 판매 개인과 기업에게 판매한다. 개인은 구매자인 동시에 시청자이고, 스트리밍 혹은 영구 소지할 수 있다. 기업은 구매자와 시청자가 다르고, 스트리밍만 된다. 액터 기준으로 경계가 나뉨 -한 액터 기능이 변경되도 다른 액터에게 영향 없도록 -제작자, 관리자, 구매자, 시청자 -카탈로그 조회(View Catalog) 는 추상 클래스이다. 비슷한 기능이라서. 구매자, 시청자 단에서 각각 구현해줌. 컴포넌트 아키텍처 -검정 화살표: 상속관계 / 빈 화살표: 제어 흐름. 고수준을 향해 있다. -컨트롤러로 입력이 들어오면 interactions 에 의해 데이터가 만들어지고, 그 이후에 Presenters 가 결과 포맷 변경하고 Views 가 화면에 표시한다. -Catalo.. [10] 30~32 세부사항 23.10.29 [30] 데이터베이스는 세부사항이다 DB는 그저 매커니즘에 불과하며 디스크 표면과 RAM 사이에서 데이터를 이리저리 옮길 때 사용할 뿐이다. 실제로 비트를 담는 거대한 그릇이며, 데이터를 장기적으로 저장하는 공간에 지나지 않는다. 그러므로 세부사항인 DB 를 아키텍처 중심에 두어서는 안되며, 즉 테이블과 행이 객체 형태로 시스템 여기저기에서 돌아다니게 허용하면 안된다. ※ DB 가 널리 사용되는 이유 디스크에 있는 데이터를 접근하는 건 너무 느리기 때문에, 시간 지연을 완화하기 위해 색인, 캐시, 쿼리 계획 최적화 같은 것들이 필요해졌는데 그럴러면 원천 데이터가 있는 곳이 필요했다. 그래서 문서 기반의 파일 시스템, 내용 기반의 DB 시스템이 출현했다. 파일 시스템은 파일을 편리하게 저장.. [9] 27~29 서비스 기반 아키텍처 vs. 컴포넌트 기반 아키텍처 23.10.23 [27] ‘크고 작은 모든' 서비스들 서비스 기반 아키텍처 vs. 컴포넌트 기반 아키텍처 서비스 아키텍처의 통설 및 이의 통설 1) 서비스 사이의 결합이 철저하게 분리된다. 이의 제기) 결합 분리의 오류 어느 정도 일리는 있지만 서비스 단위로 다른 프로세서에서 실행되고, 다른 서비스 변수에 직접 접근할 수 없고, 인터페이스는 잘 정의되어있어야 한다. 꼭 그런 것만은 아니다 서비스들이 한 장비 내에 존재한다면 네트워크 상의 공유 자원 때문에 결합될 가능성이 여전히 존재한다. 서비스는 분리해도 DB 를 공유하면 DB 데이터가 변경됐을 때 관련된 모든 서비스들이 변경돼야 한다. 통설 2) 개발 및 배포 독립성을 지원한다. 이의 제기) 개발 및 배포 독립성의 오류 어느 정도 일리가 있지만 대규모.. [8] 24~26 경계 23.10.10 [24] 부분적 경계 완벽한 경계를 만들기엔 비용과 노력이 너무 많이 들므로(쌍방향 바운더리 인터페이스, input/output 데이터 구조, 컴포넌트 격리), 부분적 경계를 활용해 볼 수도 있다. 부분적 경계 구현 방법 3가지 1. 마지막 단계를 건너뛰기 마지막 단계: 다중 컴포넌트로 각각 배포하는 것 같음 독립적으로 컴파일하고 배포할 수 있는 컴포넌트 만드는 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 둔다. 컴파일이랑 배포도 단일 컴포넌트로 한다. 그래도 완벽한 경계를 만들 때만큼의 코드량과 설계 비용은 많이 들지만, 버전 번호나 배포 관리 부담이 없는 차이가 있다. 사례) Fitnesse 만들 때 초기 전략으로 웹 컴포넌트를 분리했으나 한 번에 다운로드하는게 목적이기도 .. [7] 20~23 업무규칙 & 아키텍처 23.09.23 [20] 업무 규칙 애플리케이션 = 업무 규칙 + 플러그인 업무 규칙 = 엔티티 + 유스케이스 업무 규칙이란? 사업적으로 수익을 얻거나 비용을 줄일 수 있게 하는 규칙. 컴퓨터상으로 어떻게 구현하는지 또는 규칙을 자동화하는 시스템과는 상관없다. ex. 대출에 N% 의 이자를 부과한다. 업무 규칙은 대출 잔액, 이자율, 지급 일정 같은 핵심 데이터와 본질적으로 결합되어 있기 때문에 엔티티라는 객체 형태로 관리하기 좋다. 엔티티 : 컴퓨터 시스템 내부의 객체로서, 핵심 업무 데이터 기반으로 동작하는 조그만 핵심 업무 규칙을 구체화한다. -순전히 업무에 대한 것이어야 한다. -이런 핵심적인 개념 구현하는 소프트웨어는 한 데 모으고, 세부 규칙(DB, 사용자 인터페이스, 서드 파티 프레임워크) .. [6] 17~19 경계 23.09.19 [17] 경계: 선 긋기 소프트웨어 아키텍쳐는 선, 즉 경계를 긋는 기술이다. 아키텍트의 목표는 시스템을 만들고 유지하는데 드는 인적 자원을 최소화하는 것인데, 너무 경계를 일찍 그어버리면 오히려 더 들 수 있다. 일찍 경계를 긋는다는 것: 시스템의 업무 요구 사항, 즉 유즈 케이스와 관련 없은 프레임워크, DB, 웹 서버 등 세부사항을 미리 결정하는 것 나쁜 사례 자사 제품을 웹 버전으로 변환하는 프로젝트 착수. 서버 팜(여러개 서버)을 예상하고 GUI, 미들웨어, DB 가 각각 다른 서버에 있을 것이라 생각하고 개발함. 티어 간 통신이 필요하기 때문에 필드 하나만 추가하려고 해도 통신하기 위해 양방향 4개의 메시지와 8개의 핸들러를 수정해야했음. (변경이 어려움) 그런데 정작 배포하는.. [5] 15~16 아키텍처와 독립성 2023.09.15 아키텍처란? 소프트웨어 아키텍트가 하는 일 프로그래머이다. 설계만 하는 사람이 아니라 계속 개발하면서 팀원들이 좋은 방향으로 설계할 수 있도록 이끌어준다. 그 모양은 컴포넌트를 어떻게 분할하고 배치하고 서로 의사소통하는 방식에 의해 결정된다. 시스템의 동작 여부와는 관련없다. 좋지 않은 아키텍처로도 돌아가게 만들 수는 있기 때문이다. 좋은 아키텍처를 만드려는 궁극적인 목표는 시스템 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하기 위함이다. 그러려면 시스템을 쉽게 이해하고 개발하고 유지보수하고 배포할 수 있어햐한다. 이런 일을 용이하게 만들기 위해서는 가능한 많은 선택지를 오래 남겨두는 전략을 따라야 한다. 개발 팀 규모에 따라 아키텍팅도 다르다. 팀이 5명 정도로 작.. 우아콘 2023 리뷰 및 후기 https://woowacon.com/presentations WOOWACON 2023 한 번의 배달을 위해 필요한 모든 기술들 woowacon.com 2023년 11월 15일 수요일, 우아콘 2023에 참가하여 백엔드 기술에 대한 다양한 이야기들을 들었다. 내가 들은 세션들은 주로 점점 증가하는 대규모 트래픽에 대응하기 위해 이러이런것을 했어요를 소개하는 내용이었다. 세션을 진행한 팀은 다르지만 조회와 처리 이벤트를 분산하기 위해 CQRS 를 적용했다는 점, 이벤트 순서가 꼬이거나 발행을 실패했을 때를 대비하기 위해 Transaction outbox pattern 를 적용했다는 점을 공통으로 적용하고 있었다. 올해 '데이터 중심 애플리케이션 설계' 책을 힘겹게 정리해가면서 완독했지만 주로 이론적인 내용.. [4] 12~14 컴포넌트 컴포넌트의 역사 : 내가 생각했을 땐 분리의 역사 소프트웨어 개발 초창기에는 어떤 메모리 주소에 프로그램을 로드할 건지도 일일히 정해줘야 했었다. 라이브러리 함수도 직접 애플리케이션 코드에 포함해서 단일 프로그램으로 컴파일해야 했다. 그러다가 프로그램 사이즈도 너무 커지고 컴파일에도 오래 걸리니 앺 코드와 라이브러리 코드를 메모리 상에서 분리했다. 메모리 주소 몇 이상은 라이브러리 같은 규칙을 정하고 말이다. 그러면 라이브러리 따로 개별적으로 컴파일할 수 있었지만, 앺 코드가 너무 커지면서 라이브러리 밑에 집어넣는 비효율이 발생했다. 메모리 주소를 고정이 아닌 재배치를 하는게 해결책이었다. 그 기능을 로더가 해준다. 앺과 라이브러리를 로드할 위치를 로더에게 전달해주면 그에 맞게 컴파일러를 수정한다. 로더.. [3] 8~11장 SOLID SRP(Single Response Principle) 어떻게 하라고? 변경을 요청하는 주체(액터)가 다르면, 코드를 분리해라 왜? 액터가 다른데 같은 코드를 썼다간 다른 팀 모르게 수정될 가능성이 있음 코드 병합할 때 어려움 OCP(Open Closed Principle) 어떻게 하라고? 기능을 확장할 때는 코드 수정이 아니라 코드를 추가하는 방향으로 간다. 왜? 변경을 쉽게 처리하되 시스템이 너무 많은 영향 받게 하지 않기 위해 LSP(Liskov Substitute Principle) 어떻게 하라고? 다형성 개발할 때 부모 기능 잘 지켜라 완벽하게 이해하는 LSP (리스코프 치환 원칙) 왜? 변화에 쉽게 하기 위해 ISP(Interface Segregation Principle) 어떻게 하라고? 인.. [2] 3~6장 패러다임 개요 (구조적, 객체지향, 함수형 프로그래밍) 언어의 역사 1945년: 앨런 튜링이 바이너리 언어로 반복분, 분기문, 할당, 서브루틴, 스택 을 활용해 사람이 식별가능한 형태로 프로그램을 코드로 작성 1940년대 후반:“언어” 어셈블리 처음 등장. 바이너리 코드로 짜야했던 프로그래머의 고된일이 줄어듦. 1951년: 최초의 컴파일러 A0 등장. by 그레이스 호퍼 패러다임이란 프로그래밍을 하는 방법. 언제 어떤 프로그래밍 구조를 사용해야 하는지 결정한다. 세 가지 패러다임을 알려주겠다. 구조적 프로그래밍 프로그래밍의 역사 다익스트라는 네덜란드 최초의 프로그래머라는 직업을 가진 사람이다. 다익스트라는 어려운 프로그래밍을 해결하기 위해 증명이라는 수학적인 원리를 적용했다. “프로그래머" 는 입증된 구조를 이용하고, 이 구조를 코드와 결합시켜 코드가 올바름.. [1] 1~2 장 설계와 아키텍처란? 설계와 아키텍처의 차이? 설계와 아키텍처의 차이는 없다. 고수준과 저수준의 차이라고도 말하지만 어차피 고수준의 결정사항과 저수준의 세부사항은 이어져 있는 전체 설계의 구성요소일 뿐이다. 좋은 소프트웨어 설계의 목표? 필요한 시스템을 만들고 유지보수에 투입되는 인력을 최소화한다. 목표를 이루기 위해선 "코드는 나중에 정리하면 돼. 당장 출시가 먼저야"라는 거짓말에 홀리지 않는다. 왜? 개발 비용이 증가되는 주 요인이 변경 사항의 범위와 형태이기 때문이다. 아키텍처가 후순위가 되면 시스템 개발 비용이 더 많이 들고, 변경이 점점 어려워진다. 사례) 어떤 회사의 직원 수는 늘어나는데 생상선은 줄어듦. 결국 경영 관점에선 인건비는 늘어나고 사정이 악화되고 있었음. 왜? 코드 품질보다 시장 출시를 더 우선시 했기.. [12] 데이터 시스템의 미래 (끝) 지금까지 책의 내용은 현재 존재하는 것을 설명했다면 이번 장은 미래에는 어떻게 돼야 하는지 설명한다. 지금까지 설명했던 아이디어들을 함께 모아 그걸 기반으로 미래를 고찰한다. 데이터 통합 파생 데이터 시스템과의 결합 전문 검색 색인 같은 복잡한 검색 기능이 필요하면 전문적인 정보 탐색 도구가 필요하고, 이 시스템에 사본을 유지해야 한다. 데이터 사본을 여러 저장소 시스템에 유지해야할 때 입력과 출력을 분명히 해야한다. 어디서 처음 기록하는제, 원본 출처, 올바른 형식으로 어떻게 넣는지 등 ex. CDC 를 활용하면 색인은 전적으로 DB 에서 파생되므로 일관성이 보장된다. 근데 앺이 색인, DB에 직접 기록하게 하면 둘의 동기화가 깨질 수 있다. → 파생 데이터 시스템은 이벤트 로그를 기반으로 갱신하면 결.. [11] 스트림 처리 일괄 처리의 한계 및 스트림이 필요한 이유 일괄 처리는 사전에 입력을 유한한 크기로 한정한다. 데이터는 끊임없이 많기 때문에 일 단위 나 일정 기간씩 청크를 나눈다. 문제는 하루가 지나야 반영된다는 것이다. 대신 스트림은 고정된 시간 조각의 개념을 버리고 이벤트가 발생할 때마다 처리한다. 스트림 표현/저장/전송 하기 이벤트 스트림 생김새 하나의 레코드를 이벤트라고 한다. 작고 독립된 불변 객체이며 타임스탭프를 포함한다. 텍스트 문자열 or JSON or 이진 형태 등으로 부호화된다. 이벤트 전송 컨슈머 쪽에서 폴링하며 새 이벤트를 직접 가져올 수도 있지만 오버헤드가 커지기 때문에 프로듀서가 알려주는 편이 낫다. 메시징 시스템 이벤트 알림 전달 목적으로 개발된 발행/구독 모델 여러 프로듀서가 같은 토픽으로.. 에버노트에서 업노트로 갈아탄 이유 필자는 에버노트를 5년 넘게 사용한 헤비유저다. 연 마다 자동결제가 되는데 금액을 보고 깜짝 놀랐다. 에버노트가 너무 좋아서 지금까지 썼다기 보단 마땅한 대체제를 찾지 못해서 쓰고 있었던 건데 오우 1년에 99000원을 내자니 순간 돈이 너무 아깝게 느껴졌다. 이게 트리거가 되어 노트 앱을 탐색해보았고 업노트를 알게 되었다. 2달 안에 환불 신청해서 에버노트 환불받음ㅎ 잘가~~ 외관 외관은 에버노트와 비슷하다! 맨 왼쪽은 카테고리, 가운데엔 노트 목록, 오른쪽엔 노트 내용이 위치한다. 장점1) 마이그레이션 빠름 업노트로 갈아탈 수 있게 해준 최고의 장점이다. 노션은 마이그레이션 하다 중도 포기했지만, 업노트는 4000 개를 8시간 만에 이틀에 걸쳐 완료할 수 있었다. 장점2) 한 노트에 여러 카테고리 지.. [10] 일괄 처리 시스템을 세 가지 유형으로 나눌 수 있다. 서비스 (온라인) - 클라이언트로부터 요청이 들어오면 실시간으로 응답해야 함. 성능 지표: 응답 시간 일괄 처리 시스템 (오프라인) - 정해진 시간에 매우 큰 입력 데이터를 받아 처리하고 결과 데이터를 생성함. 성능 지표: 처리량 (10장) 스트림 처리 (준실시간) - 입력 이벤트가 발생한 직후 데이터를 받아 처리하고 생성함. (11장) 맵리듀스 2번 일괄 처리 알고리즘 "구글을 대규모로 확장 가능하게 만든 알고리즘" 하둡, 카우치DB, 몽고DB 에서 구현됨 더 자세하게 알아보기 전에, 일괄 처리의 아이디어를 준 유닉스 시스템부터 살펴보자 유닉스 철학 유닉스의 데이터 처리 방식 로그 파일 분석 명령어 공백 분리 7번째 문자열을 정렬 → 중복 제거→ 내림 차순 정.. [9] 일관성과 합의 일관성과 합의: 분산 시스템에서 결함이 나더라도 올바르게 동작하게 할 방법들 내결함성을 지닌 시스템을 구축하는 좋은 방법: 문제를 추상화해라! 트랜잭션 추상화: 트랜잭션이라는 개념으로 인해 원자성, 격리성, 지속성을 보장한다. 합의: 모든 노드가 어떤 것에 동의하게 만들어, 리더가 두 개가 되는 스플릿 브레인 같은 문제를 해결할 수 있다. (후반부에서 합의 알고리즘을 알려줄게) 일관성 보장 최종적 일관성 동시에 DB 노드 두 대를 본다면 두 노드에서 서로 다른 데이터를 볼 가능성이 있다. 근데 시간이 지나면 대부분 최신데이터가 반영이 돼 스스로 같은 값을 반환하게 해소된다. "기다리면 최종적으로 값이 일치하는 일관성을 보장한다" 라는 의미 → 근데 이건 언제까지 기다려야할지 아무도 모르기 때문에 약한 보.. 이전 1 2 3 다음
