mtools를 통해 EXPLAIN과 같이 slow query를 분석할 수 있다.
/var/logs/mongod 밑에 있는 로그 파일을 50mb 정도의 사이즈로 나눠서
mloginfo --queries --no-progressbar 쪼개진파일.log > slow_queries.txt
(mtools 파이썬 패키지 설치하면 mloginfo라는 executable 생깁니다)하면 늦은 query를 분석할 수 있다.
Object class에 기본 포함되는 함수는
- public boolean equals(Object o)
- public String toString()
- finalize() : 가비지 콜렉션이 정리할 때 사용
- public native int hashCode() - 대략적인 hashCode 이며
- clone()
(그 외 wait, notify 등)
Vector 와 ArrayList의 차이
- Vector는 synchronized라서 Thred Safe하고 좀 늦다는 게 가장 큰 차이이고
- 둘 다 고정 사이즈이고 내부적으로는 array를 사용하며, size를 증가시킬 때 Vector는 100%씩 증가, ArrayList는 50%씩 증가.
spring에서 bean은 아무 생각없이 만들면
spring container에서 singleton 으로 만들어 준다.
(즉, 전체 sping container에서 항상 동일한 하나의 global instance로 bean을 만들어 준다)
따라서 immutable이고 status도 없이 만드는 것이 좋음.
만약, 다른 용도로 만드려면
Prototype Bean - 매번 생성
Session Bean - WEB 세션별로 생성
Request Bean - WEB Request별로 생성
이 존재하며..
@Component
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE) 과 같이 annotate 한다.
- @Scope("prototype") 만 해도 되지만.. 위에 방식이 더 안전.
xml에서 할 경우에는
<baen id="note" class="my.Note" scope="prototype"> 으로 한다.
1. json obj 이용 세팅
setCount(prev => prev + 1) 처럼 json이용해서 사용하려면
setUser (prev => { ...prev, name:'kim'} ) 하면 안된다. 이유는 { 를 함수시작으로 인식하기 때문이며, 해결 법은 2가지인데
setUser(prev => ({...prev, name:'kim'}) ) 괄호이용 , usetUser (prev => { return {prev..., name:'kim'} }) return 이용.
2. handleChange 에서 e.target.name 이용
const handleChange = e => {
setUser( {...user,
[e.target.name]: e.target.value} ). 이렇게 중괄호(curly brace)를 이용하면 변수를 이용해 필드설정 가능
} => 여러개 의 input text 를 하나의 handleChange로 이용하게 된다.
3. 페이지 reload 하는 경우
const TestApp = () => {
console.log("reloaded"); // setQuantity(0) 호출시 안찍힘. setQuantity(1) 호출시 찍힘. 즉 state가 바뀔때만 reload
// json obj는 같은 {age:1} 대신 {age:1} 형태로 같은 내용이라도 pointer가 항상 바뀌므로 찍힘.
const [quantity, setQuantity] = useState(0)
const totalPrice = quantity * 5; // useState 필요없이 이 방식대로 해도 page가 reload 될 때마다 재계산된다.
}
4. api호출 취소
axios는 cancelToken 이용
fetch는 AbortController 의 controller.signal 이용해서 취소
관련 react JSX코드:
<div className="App">
<h2> CSS Sample </h2>
<div className="MyDiv">
<div className="Child"></div> * 5개
</div>
<div className="MyDiv" style={{display:'flex', justifyContent:'spaceBetween'}}>
<div className="Child" > </div>
<div className="Child" > </div>
</div>
<div className="MyDiv">c</div>
</div>
<POSITON 4가지 - 기본 static은 제외 > - 4개 포지션은 left,top,right, bottom 제공.
- relative - 기본static과 거의 동일하지만 left/top 등을 쓰면 dom흐름에서 좀 벋어난다.
- absolute - (sticky가 아닌 다른 포지션에 대해, 없을경우는 전체 window에 대해) left, top을 고정한다.
=> 그래서 부모를 relative로 하면 제일 좋고, 부모를 absolute로 해도 좋음. - fixed - absolute와 비슷하나, fixed는 스크롤도 되지 않고 그자리 고정된다(absolute는 parent에 고정되므로 스크롤이 따라서 됨)
- sticky = (relative+fixed) : 보통은 relative처럼 동작하지만, 스크롤시 fixed 처럼 동작한다.
<grid > display:flex와 함께 display:grid 가 유연한 레이아웃을 제공. flex에서도 flex-wrap: wrap; 으로 어느정도 구현가능.
혹시 TreeMap TreeSet에서 element가 primitive일때 reverseOrder로 간단히 하려면.
TreeMap<Integer,Integer> tm = new TreeMap<>(Collections.reverseOrder());
public static int[] mergeSortedArrays(int[] arr1, int[] arr2) {
int[] result = new int[arr1.length + arr2.length];
int i = 0, j = 0, k = 0;
while (i < arr1.length && j < arr2.length) {
if (arr1[i] < arr2[j]) {
result[k++] = arr1[i++];
} else {
result[k++] = arr2[j++];
}
}
while (i < arr1.length) {
result[k++] = arr1[i++];
}
while (j < arr2.length) {
result[k++] = arr2[j++];
}
return result;
}
}dynamic 프로그래밍은 로직만으로 계산이 어려워서
컴퓨터에게 반복적으로 계산도 시키고, 캐싱도 시키면서 캐싱된걸 이용해 나가면서 답을 구하는 방법이다.
문제 예제 1 . 숫자 n 만 주고, 가능한 모든 BST 개수 구하기.
- BST(binary search tree: child는 max 2개이고, left child는 작은값, right child는 큰값)
소프트웨어 아키텍처 패턴
정의
소프트웨어 아키텍처 패턴은 시스템의 전반적인 구조를 설명합니다. 아키텍처 패턴은 시스템의 핵심 구조와 그 구조의 특징을 묘사하며, 대규모 설계 문제를 해결하기 위한 고수준의 템플릿입니다.
종류
- 계층형 패턴 (Layered Pattern): 시스템을 독립된 계층으로 나누고 각 계층간의 상호작용을 정의합니다.
Presentation Layer, Application Layer, Domain Layer(비즈니스 로직), Infra Layer(데이터베이스 상호작용) - 클라이언트-서버 패턴: 클라이언트와 서버의 역할 분리로 서비스 요청과 처리를 관리합니다.
- MVC (Model-View-Controller) 패턴: 사용자 인터페이스와 비즈니스 로직을 분리하여 관리합니다.
View(사용자 상호작용) -> Controller에서 Model(비지니스 로직)과 View사이의 중계자 역할을 하게 됨. - 이벤트 버스 패턴: 컴포넌트 간 메시지를 중앙 이벤트 버스를 통해 전달합니다.
- 마이크로서비스 패턴: 작은 서비스로 분할하여 독립적으로 운영 및 개발할 수 있게 합니다.
그 외 6~10번 더 나열하자면...
(Master-slave pattern
. Pipe-filter pattern - 파이프를 통해 흐르는 데이터를 중간중간 필터 모듈이 처리하는 패턴.
. Broker pattern
. Peer-to-peer pattern
. Blackboard pattern - "블랙보드"에 비유되는 중앙 저장소에 데이터를 공유 .
(interpreter패턴도 여기 들어갈 수 있는데, 아래꺼랑 헤깔려서 일단 제외)
SW 디자인 패턴
정의
디자인 패턴은 소프트웨어 설계 단계에서 특정 문제를 해결하는 일반적인 해법을 제공합니다. 디자인 패턴은 보다 구체적이며, 작은 범위의 설계 문제에 적용됩니다.
종류
- 생성 패턴: 객체 생성과 관련된 패턴으로, 싱글턴, 팩토리 메서드, 추상 팩토리, 빌더, 프로토타입 등이 있습니다.
- 구조 패턴: 객체 간의 구조화된 관계를 설명하는 패턴으로, 어댑터, 브리지, 컴퍼지트, 데코레이터, 퍼사드, 플라이웨이트, 프록시 등이 있습니다.
- 행동 패턴: 객체 간의 상호작용과 책임을 다루는 패턴으로, 책임 연쇄, 명령, 해석자, 반복자, 중재자, 메멘토, 옵저버, 상태, 전략, 템플릿 메서드, 방문자 등이 있습니다.
Redis 의 영속성(persistency):
- default로 스냅샷(.rdb)파일 옵션이 켜져 있으며, 주기적으로 스냅샷을 찍고, 복구시 이를 이용한다. => 끌 수도있고 설정변경 가능.
(기본값: 15분, 5분, 1분/key 1개, 10개, 1만개)
- AOF(append only file) 을 설정하면 용량이 크지만 모든 기록을 aof파일에 기록을 하고, 복구시에 사용한다.
=> 데이터 유실 확률이 더 적어지지만, 로딩속도가 늦고, 100%복구는 장담할 수 없다. (매우 critical한데서는 사용 비추)
Rate Limiter: (http 429: too many request 에러 리턴)
- 직접 구현시에는 요청을 Intercepter해서 ConcurrentHashMap 같은데 클라이언트IP+시간키 / 개수 등으로 관리.
(서버가 여러대일때는 1/n이 되고 약간 부정확)
- 보통은 라우터 단에서 더 많이 하게되는데, 예를 들면 AWS의 API Gateway에서는 api별로 Throttle 옵션을 설정하면 된다.
=> Stage설정을 통해 전체 API에 대한 요청 제한 관리.
- cloudFlair와 같이 전문적으로 제공해 주는 서비스 존재. AWS의 WAF는 미세설정이 좀 부족했음.
서킷 브레이크:
서킷 브레이커(Circuit Breaker) 패턴은 분산된 마이크로서비스 아키텍처에서 일반적으로 사용되는 패턴 중 하나입니다. 이 패턴은 서킷 브레이커가 전기 회로에서 과부하로부터 회로를 보호하는 것과 유사한 방식으로 작동합니다.
온라인 서비스 시스템에서, 한 서비스가 다른 서비스에 의존할 때, 호출되는 서비스가 실패하거나 지연될 경우 전체 시스템에 문제가 생길 수 있습니다. 서킷 브레이커 패턴은 이러한 문제를 방지하기 위해 사용됩니다.
서킷 브레이커는 특정 서비스에 대한 요청이 일정 임계치를 초과하여 실패할 경우, 추가 요청을 차단하고 즉시 실패 응답을 반환합니다. 이렇게 하면 실패한 서비스에 대한 의존성이 전체 시스템에 미치는 영향을 최소화하며, 실패한 서비스가 회복될 시간을 제공합니다.
MSA migration:
용어
- AWS의 CDN = cloudFront : 에지서버(가까운 서버)에서 컨텐츠를 직접 제공.
- C.A.P 이론 : CAP 이론은 분산 시스템에서 세 가지 핵심 C.A.P 중 어느 두 가지만을 선택할 수 있다는 개념을 나타내는 이론입니다. 이런 선택은 분산 시스템의 설계와 운영에서 중요한 결정을 내리는 데 영향을 미칩니다.
- 일관성(Consistency): 모든 노드가 동시에 같은 데이터를 보는 것입니다. 즉, 어떤 노드가 데이터를 변경하면, 다른 모든 노드도 동일한 데이터를 볼 수 있어야 합니다.
- 가용성(Availability): 모든 요청은 성공하거나 실패해야 합니다. 시스템은 항상 요청에 대한 응답을 주어야 합니다. 실패한 노드에 대한 요청도 응답을 반환해야 합니다.
- 분할 내성(Partition Tolerance): 네트워크 지역이 분할되고 지역간 통신 실패 같은 상황에서도 시스템이 정상적으로 작동하거나 복구할 수 있어야 함 => Consistency와 바로 상반 됨.
CAP 이론은 "일관성", "가용성", "분할 내성"을 모두 동시에 만족시키는 것은 불가능하다고 주장합니다. 이를 그림으로 나타내면 CAP 이론의 유명한 "CAP 삼각형"이 나옵니다. 이 삼각형에서는 세 속성이 모두 연결되어 있는데, 그 중에서 두 개를 선택할 수 있다는 것을 의미합니다.
CAP 이론은 분산 시스템의 설계와 구축 시 어떤 속성을 우선시할 것인지 결정해야 한다는 중요한 이론
- SDLC (S/w Development LIFE Cycle) : 개발을 위한 단계별 접근방식 - Waterfall, agile, V-Model 등이 있다. REF
- SRS (Service Requirement Specification) - 요구사항 정의 느낌.
- SLE (Service Level ObjEctive)의 약자로, 서비스 수준 목표를 나타내는 개념입니다. SLE는 서비스의 성능 및 가용성과 같은 품질 지표를 정의하고 측정하기 위해 사용. 즉: 응답시간, 가용성, 에러비율, 처리량 등.
-
1. 백엔드 Cache 적용하기 => 보통 redis나 memCached 를 많이 이용하지만, 당연히 mongoDB casandra등 다른 방법을 이용할 수 있다
- 이를 통해 DB query를 하지않고 바로 리턴하게 된다. 가끔씩 db를 조회해서 최신정보를 가져오는 step은 readThrough라고 부름.
2. (SQL구조 개선) query tunning + index추가 작업 .
(+N+1 Query 문제 해결. -> 게시글하나+댓글N개인 경우 N+1조회 등)
3. 데이타가 클때 : Payload Compresion 적용. (예: brotli 솔루션)
4. 프론트 엔드 개선: 데이터 많은 곳에 paging 적용 등 UI 개선을
프론트에서 Cache 적용하기 (react-cache 등 적용해서 API호출 회수 자체를 감소 가능)
5. 비동기 logging : 로그 때문에 시스템이 느려질 수도 있으므로 loggiin에 비동기 방식 적용.
및 Connection Pool 을 유지/관리 (계속 새로 오픈하는 것 보다 속도가 좋으므로)
