사용자가 많아지고 트래픽이 많아질고 시스템 스케일링이 필요해지는 시점이 오면 데이터베이스 캐싱에 대한 고민을 하게된다.

이번 포스팅에서는 데이터베이스 캐싱 전략에 대해 알아보고자 한다

 

 

먼저 들어가기에 앞서 Cache Hit을 알아보자

 

Cache hit 이란?

찾으려는 데이터가 캐쉬에 저장되어 있어 데이터베이스를 거치지 하고 캐쉬에서 바로 데이터를 가져오는 형태.

Cache hit이 많이 발생할수록 데이터 베이스에 대한 부담이 줄어든다.

 

Cache-Asdie

일반 적인 형태의 캐쉬로 어플리케이션이 캐쉬업데이트 업데이트 담당.

캐쉬에 먼저 쿼리문을 보내고 캐쉬에 데이터가 없을시 데이터베이스에서 데이터를 가져온후 캐쉬에 데이터를 업데이트 한다

 

 

장점

1. 데이터베이스 데이터 모델과 캐쉬의 데이터 모델이 다르게 저장 가능

2. 캐쉬 서버가 다운되도 데이터베이스에서 데이터를 가져올수있다.

3. Lazy Loading 

 

단점:

1. 데이터와 캐쉬간의 데이터 불일치 발생 가능성. (Time to live 값을 설정하거나 캐쉬를 무효화하는 전략 수립 필요)

2. 어플리케이션이 캐쉬관리 담당

 

Read-Through (동기적 처리)

캐쉬에 데이터가 없으면 원본 데이터 소스에 접근해서 데이터를 가져오고 캐쉬에 저장

 

장점:

1. Lazy Loading 

2. 어플리케이션이 캐쉬를 관리하지 않음

 

단점:

1. 최초로 데이터를 요청한 사람의 응답속도가 느림.

 

 

Write-Through (동기적 처리)

캐쉬가 데이터베이스와 어플리케이션 사이에 위치하고 있고 캐쉬에 데이터를 저장하고 데이터베이스 이어서 바로 저장.

Read through 전략과 같이 이용되면 Cache Hit 확률을 높일수 있다.

 

장점:

1. Write-Behind 보다 데이터 유실 위험 적음

단점

1. 캐쉬와 데이터베이스에 동시에 저장하기때문에 느린 쓰기 속도

 

 

Write-Behind (비동기적 처리)

캐쉬에만 데데이터를 저장하고,  데이터 소스에는 별도의로 주기적으로 저장하는 방식

장점

1. Write-Through 보다 향상된 쓰기 속도

2. 데이터베이스에 대한 부담을 줄일

 

단점

1. Cache 가 다운되면 데이터 유실 위험

 

 

 

 

ES6 module 시스템이 등장하며 Typescript Namespace 가 현격히 줄어들었지면 Typescript가  ES6 module 등장전에 어떻게 Typescript 코드 재사용을 이루었는지 이해하기 위해 알아보았다.

 

 

사용법

먼저 아래와 같은 폴더구조를 가진다고 하자. 

 

- base-component.ts

- input-component.ts

- utils.ts

 

base-component.ts 코드

namespace App {
	export abstract class Component { }
}

 

utils.ts 코드

namespace CommonUtils {
	export class StringUtils { }
}

 

위의 코드를 보면 Component 클래스는 같은 네임스페이스안에 Util 클래스는 다른 네임스페이스 안에 설정된것을 볼수 있다.

* 참고로 같은 Namespace에 선언되어있더라도 다른파일에서 사용하기 위해서는 내보내는 변수, 클래스, 함수등에 export 키워드를 붙여줘야한다

 

input-component.ts 코드

/// <reference path="base-component.ts" />
/// <reference path="utils.ts" />

namespace App {

   // 같은 네임스페이스내에 선언된 클래스 사용
   class InputComponent extends Component { }
   
   // 다른 내임스페이스에 선언된 클래스 사용
   CommonUtils.StringUtils.method();
}

사용법은 간단한데 /// <reference path="모듈위치.ts" />

 

이렇게만 하고 Typescript 기본설정으로 하면 파일들이 제각기 따로 생성되기때문에 각각의 파일들을 따로 불러오지 않는 이상 브라우저에서는 사용할수 없다. 그런 경우애 편의를 위해 한파일로 된 파일을 생성할수 있는데 tsconfig.json 에 outFile 옵션을 활성화 한다. outFile 옵션은 amd 혹은 system 모듈일 경우에만 선택가능하니 용도에 맞게 선택한다

{
    "outFile": "./dist/bundle.js",
    "module": "amd"
}

 

그리고 HTML 파일에서는 아래 한파일만 불러오면 된다

<script src="dist/bundle.js"></script>

 

Namespace 의 단점

1. 의존성들이 불러오지 않더라도 오류 메세지를 발생시키지 않고 정상적으로 Javascript 로 Transpile 하는 경우가 생긴다. 이점은 규모가 큰 프론트 엔드 프로젝트가 될수록 치명적 단점으로 작용한다. 

 

 

그렇다면 Namespace 와 Modules 중에 어떤것을 선택해서 선택해야 될까? 이점은 Typescript 팀에서 명확히 가이드 라인을 제시해주었는데 아래 공식문서에 따르면 모던 코드들에 대해 ES Module 을 사용할 것을 권장하고 있다.

It is also worth noting that, for Node.js applications, modules are the default and we recommended modules over namespaces in modern code.
 

Documentation - Namespaces and Modules

How to organize code in TypeScript via modules or namespaces

www.typescriptlang.org

 

운영환경에서 장애가 발생시에 서버내로 직접 접속해서 어플리케이션 로그를 확인해야하는 경우가 생긴다. 물론 정상적인(?) 환경이라면 이미 ELK Stack 같은 Log management tool 이미 설치되어 거기에서 애플리케이션 로그를 확인하면된다. 하지만 간혹해서 서버에 직접 접속하여 로그를 확인하는 경우가 생기는데 그런경우에 유용한툴이 multitail 소개하고자한다.

 

보통 다중서버에서 애플리케이션 로그를 확인시에 아래와 같은 과정을 거친다

 

1. ssh sever1

2. tail -f <로그파일 위치> 

 

다중 터미널 띄어놓고 서버 별로 1, 2번과정 무한반복

 

이러한 과정을 한번에 해결하는 툴이 multitail 이다. 명령어는 아래와 같다

multitail -l "ssh server1 tail -f 로그 파일 위치위치" -l "ssh server2 tail -f 로그 파일 위치위치"

 

추가 서버가있을때마다 -l 을 추가해서 계속해서 연결해 주면 된다.

 

로컬내에서 서로 다른 파일을 확인하고자 하는 경우에는 더 간단한데 아래와 같이 설정해주면된다

multitail 로그파일위치1 로그파일위치2

 

리눅스 시스템 운영하는 경우에 간혹 서버의 하드웨어 용량 사용량을 수동으로 체크하는 경우가 생기는데 (물론 이에 대해 Monitoring 툴을 설치해서 특정 용량이상이 넘거나면 자동으로 경고메세지를 설정하는게 가장좋다) 가끔 사용하기에 잊어먹는 명령어들을 저장한다.

 

 

1. 시스템내 Mount (or 파티션) 별로 용량 보기

df -h

2. 현재 있는 폴더 및 하위 폴더내 파일들 크기

du -h

VCS (Version Control System) 은 과거부터 소스코드 관리를 위해 자주 사용하는 툴이다.

그중 VCS 의 한갈래중 하나인 DVCS (Distributed Version Control System) 에서 가장 대중적으로 사용하는 Git 에서 가장 자주 사용하는 커맨드들을 따로 성리했다

 

 

1. git commit --amend

바로 이전 커밋 메세지를 수정하는 경우에 사용

 

2. git rebase <target_branch>

현재 브랜치를 타켓 브랜치 위로 이동하기 위한 명령어

 

3. git rebase -i <starting_point>

어느 특정순간부터 현재 커밋시점까지의 GIt 커밋 기록을 수정하고 싶을떄 사용

 

4. git config --global rerere.enabled true

통일 프로젝트에서 여러 팀원들이 동시에 작업하는 경우에 mergre conflict 가 발생하는 경우가 있다. 이 옵션을 키면 과거에 conflict 를 해결하는 결과물을 git 에서 기억하고 같은 conflict 에 대해 동일하게 적용하여 반복해서 같은 conflict 를 해결해야하는 상황을 피하게 해준다 

 

 

'Tools > GIT' 카테고리의 다른 글

GIT 자주쓰는 명령어 정리  (0) 2016.03.30

+ Recent posts