본문 바로가기

SearchDeveloper

(81)
[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 를 적용했다는 점을 공통으로 적용하고 있었다. 올해 '데이터 중심 애플리케이션 설계' 책을 힘겹게 정리해가면서 완독했지만 주로 이론적인 내용..