회사와 개인프로젝트의 계정을 분리한다던지, 개인 프로젝트와 스터디 그룹의 계정을 분리한다던지 한 컴퓨터에서 여러 Github 계정을 사용해야 할 경우가 있다. SSH를 활용하여 관리하는 방법을 사용하면 편하다.

기존에 ssh 키가 있는지 확인

  ls -al ~/.ssh

ssh 키를 생성 및 agent 등록

  # 2개의 키 생성하기
  ssh-keygen -t rsa -C "{private}@mail.com" -f "~/.ssh/{rsa file for private}"
  ssh-keygen -t rsa -C "{group}@mail.com" -f "~/.ssh/{rsa file for group}"

  # 키 생성 확인
  ls -al ~/.ssh

  # ssh-agent 실행 확인
  eval "$(ssh-agent -s)"

  # 생성한 키 등록
  ssh-add ~/.ssh/{rsa file for private}
  ssh-add ~/.ssh/{rsa file for group}

  # 등록한 키 확인
  ssh-add -l
  4096 SHA256:... {private}@mail.com (RSA)
  4096 SHA256:... {group}@mail.com (RSA)

ssh 설정 파일 수정

ssh 설정 파일은 ~/.ssh/config이다. 파일이 존재하지 않는다면 생성 후 진행한다.

  # 파일 존재 여부 확인
  cat ~/.ssh/config

  # 파일 생성
  touch ~/.ssh/config

  # 파일 수정
  vi ~/.ssh/config
  # IDLOOK
  Host github.com-{group_name}
    HostName github.com    
    User {group_github_name}
    IdentityFile ~/.ssh/{rsa file for group}

  # PRIVATE
  Host github.com-{private_name}
    HostName github.com
    User {private_github_name}
    IdentityFile ~/.ssh/{rsa file for private}

git 설정파일 수정

git user name과 user email 설정 파일을 각각 생성 수정한다

  touch ~/.gitconfig-{private}
  touch ~/.gitconfig-{group}

개인용

  vi ~/.gitconfig-{private}
  [user]
    name = {private_github_name}
    email = {private}@mail.com

업무용

  vi ~/.gitconfig-{group}
  [user]
    name = {group_github_name}
    email = {group}@mail.com

git 설정 파일에서 해당 파일을 읽어오도록 한다

  vi ~/.gitconfig
  [includeIf "gitdir:{개인 프로젝트 경로}"]
    path = .gitconfig-{private}
  [includeIf "gitdir:{그룹 프로젝트 경로}"]
    path = .gitconfig-{group}

Github 계정에 SSH 키를 등록

생성한 ssh 키를 각각 두개의 github 계정에 등록해준다.

우측 상단 Github Profile > Settings > 좌측 SSH and GPG keys > 우측상단 New SSH Key
타이틀은 편하게, Key type은 Authentication Key, Key 부분에 생성한 키를 복사해서 붙여 넣는다.

  # shell에서 명령어로 복사하는 방법
  pbcopy < ~/.ssh/{rsa file for private}

  # shell에서 명령어로 출력한 후 terminal에서 복사하는 방법
  cat ~/.ssh/{rsa file for private}

Github 등록 확인

  ssh -T git@github.com-{private_name}

로컬로 Github 레포지토리 복사

복사시 https가 아닌 ssh로 한다

  git clone git@github.com-{private_name}:{user-name}/{repository-name}.git

로컬이 이미 레포지토리가 있을 경우 주소 변경

  # 기존 리모트 url 확인
  git config --get remote.origin.url
  git@github.com:{A}/{B}.git
  # 리모트 url 변경
  git remote set-url origin git@github.com-{private_name}:{A}/{B}.git

  # 동작 확인
  git pull

clone, pull등 git 명령어 결과에서 에러가 나올 경우 ssh를 디버깅 모드로 시도

  GIT_SSH_COMMAND="ssh -v" git fetch

DL;DR

모든 내용은 git manual에 있다.https://git-scm.com/docs/git-config#_conditional_includes

참고

728x90
반응형

'VCS' 카테고리의 다른 글

[GIT]  (0) 2024.04.10
[VCS] 좋은 커밋 메세지 간단 작성법  (0) 2023.07.14
[GIT] 브랜치, 커밋 간 다른 파일 목록 조회  (0) 2022.04.05
[GIT] remote branch 가져오기  (0) 2022.04.05
[TortoiseSVN] Disconnect 방법  (0) 2021.09.10

1. 테스트 프로세스

테스트 프로세스는 테스트와 관련된 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 모든 구성요소를 엮어주는 역할을 함.

테스트 프로세스 5 단계

  계획/제어 -> 분석/설계 -> 구현/실행 -> 완료/리포팅 -> 마감

테스트 프로세스는 계획/제어, 분석/설계, 구현/실행, 완료/리포팅, 마감 5단계로 구성.

  1. 계획과 제어 :
    테스트 계획 수립은 테스트 목표와 임무를 달성하기 위해 이를 확인하고 필요한 활동을 정의.
    테스트 제어는 계획 대비 실제 신행 상황을 비교하는 지속적인 활동.
  2. 분석과 설계 :
    테스트 분석과 설계는 일반적이고 추상적인 테스트 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환.
  3. 구현과 실행 :
    테스트 구현과 실행은 가장 효율적이고 효과적으로 테스트스를 실행하기 위하여 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시져를 명세화.
  4. 완료 조건과 리포팅 :
    초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가.
  5. 테스트 마감 :
    완료된 테스트에서 발견된 사실 및 수집된 데이터, 경험을 취합하고 축적.

2. TC 작성 절차

  문서 수집 -> TC 작성 -> 내부 검토 -> 커버리지 분석 -> 승인
  1. 참조 문서 수집 :
    테스트 계획서에 명시된 테스트 케이스 작성 지침과 수준을 고려,
    테스트 설계에 필요한 분석 및 설계 문서 수집.
  2. TC 작성 :
    테스트 설계 기법을 이용하여 TC를 작성.
  3. 내부 검토 :
    PM, 아키텍트, 디자이너, 기획자, 개발자, QA 담당자가 작성된 TC의 적정성 검토.
  4. 요구사항 대비 커버리지 분석 :
    TC가 어느 정도 요구사항을 반영하는가에 대한 분석.
    기본적으로 테스트 가능한 요구사항은 모두 TC에 반영되어있는지 확인.
  5. 승인 :
    작성된 TC를 클라이언트(현업), 기획자 및 PM에게 승인을 받음.

3. TC 구성요소

  • 식별 번호 :
    TC의 고유 식별자.
  • 이슈 번호, 제목 :
    제목과 이슈 번호를 기입. (Redmine NO., Jira NO.)
  • 요약 (Description) :
    TC의 목표 등 요약된 정보
  • 사전 조건 (Precondition) :
    테스트 수행에 필요한 조건 및 실행환경. (선행 조건, 전제조건)
  • 종속성 (Dependencies) :
    테스트 요구사항 또는 기타 TC에 대한 의존성 판단.
  • 수행 절차 (Test Step) :
    TC를 수행하기 위한 정확한 단계.
  • 기대 결과 (Expect Result) :
    절차대로 진행 시 테스트 통과 여부를 결정하는 기대 결과.
  • 실제 결과 (Actual Result, PASS / FAIL) :
    테스트 수행 후 실제 결과.
  • 비고 (Remark, Note, Comment) :
    기타 비고 사항을 기입.
  • 그 외 :
    우선순위, 모듈 이름, 테스트 설계자, 설계일, 테스트 수행자, 수행일 등

구성 요소는 조직이나 프로젝트에 따라 변경/추가/삭제 될 수 있다.


4. TC 작성 시 주의 점 및 장/단점

주의점

  • 절차의 누락 :
    테스트 절차를 정확하게 입력하지 않을 경우 테스트 수행의 어려움이 생기는 테이스 발생 가능.
  • 장황한 설명 :
    TC 작성 시 상세하고 충분한 정보를 제공해야 하지만, 너무 많은 단어와 불필요한 설명으로 소통의 오류 유발 가능.
  • 전문 용어의 과다 사용 :
    TC 작성 시, 직군간 소통이 불가능한 전문용어를 과다사용시 테스트 수행에 어려움이 있을 수 있음.
  • 분명하지 않은 PASS/FAIL 기준 :
    테스트 수행 후 테스트 결과가 통과인지 실패인지 예상 결과에 정확히 기입하지 않아 결과 판단에 어려움 유발 가능.

단점

  • TC 작성 시간이 수행 시간보다 오래 걸릴 수 있음.
  • 기능 변화에 따른 TC 변경 :
    기능을 자주 변경한다면 추후 테스트 케이스의 통제에 어려움이 생기게 될 수 있음.
  • 배경 지식 판단의 어려움 :
    TC를 작성하는 사람은 테스트 하는 기능을 잘 알고 있으나, 테스트 수행자는 배경 지식이 없을 경우 테스트 수행 시간이 길어지거나 수행에 어려움이 있을 수 있음.

장점

  • 이력 참조 :
    TC는 어플리케이션 런칭 후에도 사용, 유지보수 팀과 추후 어플리케이션의 버전을 담당자의 테스트 이력 참고가 가능.
  • 테스트 진행 상황 추적 :
    TC를 문서화 하면 수행한 TC의 수, 통과/실패 수, 과업 범위 별 케이스 수, 테스트 커버리지 등의 정보를 추적/확인 가능.
  • 반복성 :
    잘 작성된 TC는 누구나 반복적으로 수행 가능.

5. TC 정렬

TC의 정렬은 업부의 효율과 연결될 수 있다. 테스트의 흐름, 테스트 환경 등을 고려해서 정렬 하도록 하자.

흐름이 이어지는 TC 정렬

정렬 전 스펙 문서에 따라 쓴 TC 정렬 후 흐름에 맞춘 TC
1. A 기능 1 실행 1. A 기능 1 실행
2. A 기능 2 실행 2. A 기능 1의 추가기능 실행
3. A 기능 3 실행 3. 기능 2 실행
4. A 기능 1의 추가기능 실행 4. A 기능 2의 추가기능 실행
5. A 기능 2의 추가기능 실행 5. 기능 3 실행
6. A 기능 3의 추가기능 실행 6. A 기능 3의 추가기능 실행

환경이 비슷한 TC 정렬

정렬 전 스펙 문서에 따라 쓴 TC 정렬 후 흐름에 맞춘 TC
1. 기능 A를 관리자(Root) 계정으로 테스트 1. 기능 A를 관리자(Root) 계정으로 테스트
2. 기능 A를 사용자(User) 계정으로 테스트 2. 기능 B를 관리자(Root) 계정으로 테스트
3. 기능 B를 관리자(Root) 계정으로 테스트 3. 기능 C를 관리자(Root) 계정으로 테스트
4. 기능 B를 사용자(User) 계정으로 테스트 4. 기능 A를 사용자(User) 계정으로 테스트
5. 기능 C를 관리자(Root) 계정으로 테스트 5. 기능 B를 사용자(User) 계정으로 테스트
6. 기능 C를 사용자(User) 계정으로 테스트 6. 기능 C를 사용자(User) 계정으로 테스트


TC-template-20240510.xlsx
0.02MB

728x90
반응형

GIT

git : Linux 커널 소스를 관리하기 위해 리누스 토발즈가 직접 개발한 분산형 버전관리 도구.
분산형이라는 의미는 여러 클라이언트들이 각자의 컴퓨터에 저장소를 반들어 중앙 서버의 전체 사본을 가지고 작업하는 것임.

SVN과 차이점

  1. SVN

    • 중앙 서버에서 소스코드와 히스토리를 관리함
  2. GIT

    • 소스를 여거 개발 PC와 저장소에 분산해서 저장
    • 로컬에서 버젼을 관리하기 때문에 SVN에 비해 빠름

GIT의 장점

  1. 같은 파일을 여러 명이 동시 작업하는 병렬 개발 가능
    (브랜치를 통해 개발한 뒤, merge 하는 방식으로 개발 진행 가능)
  2. 분산 관리이기 때문에 중앙저장소에 문제가 생겨도 원상복구 가능

Git 기본 용어

  • repository : 저장소를 의미함
    저장소를 통해 소스, 히스토리, 태그의 관리가 가능하며, 저장소를 통해 작업자가 변경한 소스의 히스토리 확인 가능
  • working tree : 저장소의 어느 한 시점을 바라보는 작업자의 현재 시점
  • staging area : 저장소에 커밋하기 전에 커밋을 준비하는 위치
  • commit : 현재 변경된 작업 상태에서 점검이 끝나면 확정하고 저장소에 저장하는 작업
  • head : 현재 작업중인 branch를 가리킴
  • branch : 가지 또는 분기점
    작업을 할 때 원본을 복사해서 branch에서 작업을 한 후 완전할 때 merge하여 작업함
  • merge : 다른 branch의 내용을 현재 branch로 가져와 병합하는 작업.

git 주요 명령어

ropository 생성

  • git init : 깃 저장소 초기화
  • git clone {url} : 원격 저장소 복사

상태 확인

  • git status : 작업 디렉토리에 변경된 파일 확인하기
  • git diff : 변경된 파일들의 변경된 내용 확인
  • git log : 변경 이력 보기

브랜치 작업

  • git branch : 로컬 브랜치 목록 확인

  • git branch -r : 원격 브랜치 목록 확인하기

  • git branch -av : 로컬과 원격 브랜치 목록 확인하기

  • git branch -m {old_name} {new_name} : 브랜치 이름 변경하기

  • git branch {new_branch_name} : 브랜치 생성

  • git checkout {branch_name} : 브랜치 변경하기

  • git branch -d {branch_name} : 브랜치 삭제

반영

  • git add . : 모든 변경사항을 커밋 준비 "스냅샷"
  • git add {file} : 특정 파일의 변경사항을 커밋 준비
  • git commit -m '{message}' : 메세지와 함께 커밋하기
  • git commit --ammend : 마지막 커밋 메세지 수정하기 (push한 commit에는 하지 말것)

취소

  • git reset --hard HEAD^ : 이전 commit 취소, 변경사항 폐기
  • git reset --soft HEAD^ : 이전 commit 취소, 변경사항 유지
  • git reset --soft merge : merge 취소하기
  • git reset --hard HEAD && git pull : 변경사항 폐기 후 원격 저장소의 최신 코드로 덮어쓰기
  • git revert {commit_code} : 커밋 되돌리기

동기화 하기

  • git fetch {remote} : 원격 저장소의 최신사항 가져오기
  • git pull {remote} {branch} : 원격 저장소의 최신사항을 가져와서 병합하기
  • git pull --rebase : 원격 저장소의 변경사항을 가져오고 초기화 하기
  • git push : 원격 저장소에 변경사항 발행하기
  • git merbe {branch} : 브랜치 병합하기
  • git rebase {branch} : 리베이스 하기

브랜치의 변경사항 임시저장

  • git stash : 임시로 변경사항 저장하기
  • git stash pop : 임시 변경사항 불러오기
  • git stash list : 임시 변경사항 보기

계정

  • git global user.name "user_name" : git 계정 name 저장/수정
  • git global user.email "user_email" : git 계정 email 저장/수정
728x90
반응형

구글에서 제공하는 웹페이지 품질 개선을 위항 오픈 소스 자동화 툴.
성능, 접근성, 권장사항, SEO, PWA 에 대한 검사 가능.

중요 측정 항목

  • FCP (First Contentful Paint)
    • 페이지 로드가 시작된 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링되는 시점까지의 시간 측정.
    • 1.8초 이하 권장
    • FCP
  • LCP (Lagest Contentful Paint)
    • 페이지가 로드되기 시작한 시점부터 가장 큰 텍스트 믈록 또는 이미지 요소가 화면에 렌더링되는 시점 까지의 시간 측정.
    • 2.5초 이하 권장
    • LCP
  • INP (Interaction to Next Paint)
    • 페이지에서 이루어지는 모든 탭, 클릭, 키보드 상호작용의 지연 시간.
    • 상소작용 수를 기반으로 페이지의 최악 상호작용 지연시간을 페이지의 전반적인 응답성으로 판단.
    • INP
  • TBT (Total Blocking Time)
    • 사용자가 화면에서 페이지를 이용(상호작용)할 수 있기 전까지 브라우져가 상호작용을 차단하는 시간.
    • 50 ms 권장
    • TBT
  • CLS (Cumulative Layout Shift)
    • 레이아웃 변경 횟수.
    • 콘텐츠 로딩으로 인해 사용자가 읽던 위치를 잃거나 잘못된 링크 또는 버튼을 클릭하게 되는 레이아웃의 변경 횟수.
    • 0.1 점 이하 권장
    • CLS
  • TTFB (Time to First Byte)
    • 리소스 요청과 응답의 첫 번째 바이트가 도달하는 시작점간의 시간의 측정도.
    • TTFB

결과 요약 항목

  • Performance : 웹페이지의 로딩 속도와 같은 성능 측정.
  • Accessibility : 접근성 지표 (버튼 간의 간격이나 글 폰트 싸이즈 등)
  • Best Practices : 권장 사항을 따라 개발되었는지 확인.
  • SEO (Search Engine Optimization) : 검색엔진 최적화 지표.
  • PWA (Progressive Web App) : 웹과 네이티브 앱의 기능 모두 이점을 가지도록 만들어진 서비스인지 확인.
728x90
반응형

'WEB > CLIENT_SIDE' 카테고리의 다른 글

[FE] 이벤트 버블링 (Event Bubbling)  (0) 2023.07.14
Webpack과 Babel 그리고 Polyfill  (0) 2020.11.30
 

아이젠하워 매트릭스

  • 업무의 우선순위를 먼저 해야 할 일, 계획해야 할 일, 위임할 일, 하지 않아도 될 일 4단계로 분류

업무 우선순위

  1. 자신의 업무를 모두 나열
  2. 각 업무의 긴급성과 중요도 판단
  3. 업무를 4개의 카테고리로 분류
    1. 긴급하고 중요한 일 - 먼저 해야할 일
    2. 긴급하지 않지만 중요한 일 - 계획해야 할 일
    3. 긴급하지 않지만, 중요하지 않은 일 - 위임할 일
    4. 긴급하지도, 중요하지 않은 일 - 하지 않아도 될 일
  4. 아이젠하워 매트릭스에 따라 우선순위 확인하고, 일정 계획

아이젠하워 매트릭스

 

아이젠하워 매트릭스

  1. 중요하고 급한 일 - 먼저 한다
    명확한 결과가 따르며 장기 목표에도 영향을 주는 업무로서, 가장 먼저 해야 하는 업무입니다.
    이 카테고리 안의 업무들은 미루지 않고 바로 처리하는 것이 좋습니다.
  2. 중요하지만 급하지 않은 일 - 계획한다
    장기 목표에 영향을 미치지만 당장 처리하지 않아도 되는 일입니다.
    긴급하지 않기 때문에 신중하게 준비하고 계획하여 완성도를 높일 수 있습니다.
    중요하고 급한 일을 해결한 뒤 이 카테고리 안의 업무를 처리합니다.
    이 업무들을 마냥 미뤄두지는 않도록 주의해야 하며, 집중력을 발휘하여 수행할 수 있도록 합니다.
  3. 중요하지 않지만 급한 일 - 위임한다
    바로 처리되어야 하지만 장기 목표에는 영향을 미치지 않는 업무입니다.
    이러한 업무는 에너지 소모가 많지만 특별한 기술은 요하지 않는 잔업인 경우가 많습니다.
    꼭 본인이 직접 하지 않아도 되는 일이기 때문에, 다른 사람에게 위임하거나 대체 시스템을 마련하도록 합니다.
  4. 중요하지도 급하지도 않은 일 - 하지 않는다
    목표를 달성하는 데 방해가 되는 일입니다.
    업무 목록에서 삭제하도록 합니다.

긴급한 일과 중요한 일을 구별하는 법

  • 긴급한 일
    • 즉시 해야 하는 일로, 기한 안에 처리하지 못하면 명확한 결과가 나타납니다.
      • 예) 기한이 임박한일, 장애, 긴급 지시사항, CS 이슈 등
  • 중요한 일
    • 당장 하지 않아도 되지만, 장기적인 목표에 도움이 되는 일입니다.
      • 예) 신 기능 스터디, 프로젝트 계획, 3rd Party 솔루션 도입

참고자료

https://1891ghaon.tistory.com/117

 


업무의 우선순위 7단계

  1. 모든 업무가 포함된 하나의 작업 목록을 만들기
    1. 효과적으로 우선순위 정하는 첫 단계는 업무의 전체 범위를 파악하는 것부터 시작합니다.
    2. 모든 업무가 기록되면 각 업무의 중요성, 긴급성, 소요 시간, 보상을 적습니다.
  2. 중요한 사항 식별하기 : 진정한 목표 이해하기
    1. 우선순위를 정하는 일은 즉각적인 '시간 관리 전략'처럼 보일 수 있지만 장기적인 '목표 달성 전략'이기도 합니다.
    2. 설정된 목표(큰 그림)를 위해 자신이 어떤 일을 하고 있는지 이해해야 미래 결과와 가장 관련이 있는 업무파악할 수 있습니다.
    3. 최종 목표에 영향을 주지 않는 작업으로 하루를 채우는 것은 시간 낭비입니다.
      항상 목표를 염두해 두고 있어야 합니다.
  3. 긴급한 사항을 강조 표시하기
    • 할 일 목록에서 마감일이 눈에 띄도록 하면 신속하게 완료해야 하는 작업을 알 수 있습니다.
    • 공식적으로 필요하지 않은 경우에도 마감일을 설정해야 합니다. 그렇지 않으면 중요한 작업을 계속 미루게 될 것입니다.
  4. 중요성 긴급성을 바탕으로 우선순위를 정한다.(아이젠하워 매트릭스)
    • 중요하고 긴급한 일 : 먼저 수행합니다.
    • 중요하지만 긴급하지 않은 일 : 전략적 계획을 세우고 완료일을 정합니다.
    • 긴급하지만 중요하지 않은 일 : 일을 축소하거나 권한을 위임합니다.
    • 긴급하지도 중요하지도 않은 일 : 할 일 목록에서 삭제합니다.
  5. 우선순위가 겹치는 것은 피한다
  6. 한 번에 하나의 중요한 작업에 집중해야 합니다.
    여러 가지의 우선 순위를 계속 시도하고 관리하는 것은 성과 저하로 이어집니다.
  7. 시간과 노력을 고려한다
  8. 할 일 목록이 너무 많아 부담스럽다면 최소한의 시간과 노력이 드는 작업에 우선순위를 두고 신속하게 진행하세요.
    작업을 정리하면 여유와 함께 작업을 추진할 수 있는 성취감이 생깁니다.
  9. 끊임없이 검토하고 현실을 반영해라
  10. 업무 목록과 우선순위자주 검토하는 것이 '통제력 및 집중력 유지'에 중요합니다.

 

참고자료

 

 
728x90
반응형
 

인터넷 속도를 측정하기 위해서 fast.com등 여러 사이트를 이용한다.

맥 터미널에서 명령어 하나로 간단하게 인터넷 속도를 측정할 수 있다.

networkQuality

 
728x90
반응형

'OS > MacOS' 카테고리의 다른 글

맥(mac)에서 텍스트 파일 인코딩 변경하기  (0) 2024.01.15

윈도우를 사용하는 분들과 협업을 하다보면 윈도우에서 작성된 텍스트 파일이 UTF-8이 아닌 MS-949 (CP-949) 인코딩으로 작성된 파일을 받을 때가 있다. 국제 표준인 UTF-8을 이용해 주시면 감사하겠지만, 어쩔 수 없이 내가 인코딩을 변경 해 줘야 한다.

CP-949에서 UTF-8로 인코딩을 변경하는 것은 터미널에서 간단하게 처리 할 수 있다.

iconv -c -f {원본 인코딩} -t {변환 인코딩} {원본 파일} > {저장 파일}

 
 
728x90
반응형

'OS > MacOS' 카테고리의 다른 글

mac(맥)에서 인터넷 속도 측정하기  (0) 2024.01.15
728x90
반응형

캐시 설계 전략

  Caching은 H/W, S/W 전반에 걸쳐 사용되는 기술이다.
  DB - application 뿐 아니라 클라이언트나 CDN에서도 캐싱을 사용한다.
  이 글에서는 DB - Web Application의 캐싱만 다룬다.

서비스 응답시간에 큰 영향을 미치는 부분은 주로 네트워크 통신과 DB I/O이다. 캐싱을 통하면 DB I/O로 인해 발생하는 오버헤드를 줄일 수 있다.

서론

Caching?

캐시는 빠른 응답과 비용 절약을 위해 사용하는 임시 데이터다.

  • 클라이언트의 요청으로 특정 데이터가 필요한 경우 서버는 DB에 질의한 뒤 결과를 반환한다.
  • 만약 요청하는 데이터의 캐시가 존재한다면 DB에 질의하지 않고 캐시로부터 데이터가 반환된다.
  • 캐기사 없다면? DB에 질의가 수행되어 반횐되고 그 결과를 캐싱한다.

캐시의 관리

캐시는 임시 데이터다. 따라서 캐시를 저장할 때 캐시가 만료되는 시간 (expire time || TTL; Time To Live)를 명시한다.
캐시는 해당 시간 내에서만 유효하고 만료 시간이 경과하면 사용할 수 없다.

캐시에 만료되는 시간을 두는 이유는 캐시가 실시간 데이터가 아니기 때문이다. 만약 원본 데이터가 바뀐다면 캐시된 내용도 바뀌어야 한다.

캐시를 사용하는 이유

캐시를 사용하면 DB에서 데이터를 읽을 때 발생하는 I/O 오버헤드를 줄일 수 있다. 캐시는 보통 Redis와 같은 In-Memory DB를 사용한다.
In-Memory DB는 메모리를 사용하기 때문에 일반적인 RDBMS보다 데이터를 읽는 속도가 빠르다. 따라서 캐시는 DB에서 데이터를 읽는 것 보다 월등히 속도가 빠르다.

모든 데이터를 캐싱하는 건?

In-Memory DB를 사용하면 요청을 빠르게 처리할 수 있지만, 메모리 특성상 데이터 소실의 위험이 있다. 또한 메모리 사용은 비용이 발생하기 때문에 방대한 양의 데이터를 모두 메모리에 적재하는 것은 큰 비용이 든다.

캐시 설계 전략이 필요한 이유

따라서 데이터의 특성에 따라 DB와 캐시를 적절히 사용하는 것이 매우 중요하다. 캐싱 전략을 올바르게 수립하면 적은 비용으로 큰 퍼포먼스 향상을 기대할 수 있다.


What to Cache

어떤 데이터를 캐싱하는 것이 좋을지 생각해 보아야 한다. 캐싱하기 좋은 데이터의 특성은 다음과 같다.

  1. 자주 바뀌지 않는 데이터
  2. 자주 사용되는 데이터
  3. 자주 같은 결과를 반환하는 데이터
  4. 오래 걸리는 연산의 결과

자주 바뀌지 않는 데이터

자주 바뀌지 않는 데이터의 경우, 한 번 캐시로 저장하면 메모리에서 읽어 빠르게 사용가능하다.
원본 데이터가 바뀌면 캐시도 바뀌어야 한다. 자주 바뀌지 않는 데이터의 캐시는 오랫동안 사용이 가능하기 때문에 캐싱하는 것이 효율적이다.

자주 사용되는 데이터

자주 사용되는 데이터는 캐싱하기 좋다. 한 번 캐싱해 놓으면 캐시를 사용하여 다수의 요청을 효율적으로 처리할 수 있다.
다만, 자주 사용될 지라도 매번 결과 값이 다르면 오히려 캐싱하지 않는 것이 낫다. 만약 일정시간 동안 데이터가 변하지 않는 것이 보장되면 해당 시간만큼의 TTL로 짧은 캐시를 생성하면 된다.
예를 들어 검색처럼 새로 요청하더라도 일정 시간 동안 같은 결과가 반환되는 경우에 해당한다.

자주 같은 결과를 반환하는 데이터

자주 같은 결과를 반환하는 데이터의 경우도 캐싱을 적용하기 좋다. 예를 들어 특정 arguments의 조합에 따라 결과가 일정한 경우 해당된다.
이런 경우는 각 arguments의 조합을 key로 연산 결과를 캐싱하면 된다.

오래 걸리는 연산의 결과

무거운 연산이 반복적으로 계산되어야 한다면 연산의 특성에 맞게 결과를 캐시하는 것이 효율적이다.
또는 사전에 별도의 프로세스에서 작업을 수행하여 결과를 미리 캐싱해 놓을 수 있다.

이 밖에도 일반적인 쿼리나 연산보다 캐싱할 때의 비용이 더 적다면 캐싱을 사용할 수 있다.
로그 분석이나 프로파일링을 통해 캐시를 적용할 함수나 API를 찾을 수 있다. 그러나 모든 사항을 고려하여 캐싱을 적용할지, TTL은 얼마나 적용할지 등은 개발자의 선택이 중요하다.


캐싱 전략 패턴의 종류

캐시를 이용하게 되면 닥쳐오는 문제점이 바로 데이터 정합성의 문제이다. 같은 종류의 데이터라도 두 저장소에 저장된 값이 서로 다른 현상이 일어날 수 밖에 없는 것이다.
따라서 적절한 캐시 읽기 전략(Read Cache Strategy)과 캐시 쓰기 전략(Write Cache Strategy)를 통해, 캐시와 DB간의 데이터 불일치 문제를 극복하면서도 빠른 성능을 잃지 않게 하기위해 연구를 할 필요가 있다.

캐시 읽기 전략 (Read Cache Strategy)

Look Aside Pattern

  • Cache Aside 패턴이라고도 불림.
  • 데이터를 찾을 때 우선 캐시에 저장된 데이터가 있는지 우선 확인, 캐시에 데이터가 없으면 DB에서 조회함.
  • 반복적인 읽기가 많은 호출에 적합.
  • 캐시와 DB가 분리되어 가용되기 때문에 원하는 데이터만 별도로 구성하여 캐시에 저장.
  • 캐시와 DB가 분리되기 때문에 캐시 장애 대비 구성이 되어 있음.
    만일 Cache Store가 다운되더라도 DB에서 데이터를 가져올 수 있어 서비스 자체는 문제가 없음.
  • 대신 Cache Store에 붙어있던 connection이 많았다면, Cache Store가 다운된 순간 DB로 몰려 부하발생 가능.

일반적으로 사용되는 기본적인 캐시 전략. 이 방식은 캐시에 장애가 발생하더라도 DB에 질의를 실행함으로 캐시 장애로 인한 서비스 문제는 대비할 수 있지만, Cache Store와 DB간 정합성 유지 문제가 발생할 수 있음.
반복적으로 동일 쿼리를 수행하는 서비스에 적합, 단건 호출 빈도가 높은 서비스에는 비적합.
이런 경우 DB에서 캐시로 데이터를 미리 넣어주는 작업을 하기도 하는데 이를 Cache Warming이라고 함.

Read Through 패턴

  • 캐시에서만 데이터를 읽어오는 전략 (inline cache)
  • Look Aside와 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이라는 차이가 있음.
  • 따라서 데이터를 조회하는데 전체적으로 속도가 느림.
  • 또한 데이터 조회를 전적으로 캐시에만 의지하므로 Cache Store가 다운될 경우 서비스 이용에 차질이 생길수 있음.
  • 캐시와 DB간의 데이터 동기화가 항상 이루어져 데이터 정합성 문제에서 벗어날 수 있음.
  • 읽기가 많은 호출에 적합

Cache Aside 방식과 비슷하지만, Cache Store에 저장하는 주체가 Server인가 혹은 Data Store 자체인가의 차이가 있음.
직접적인 DB 접근을 최소화 하고, Read에 대한 소모되는 자원을 최소화할 수 있음.
하지만 캐시에 문제가 발생하는 경우 바로 서비스 중단이 되기 때문에 Cache Store의 Replication 또는 Cluster구성하여 가용성을 높여야 함.

캐시 쓰기 전략 (Write Cache Strategy)

Write Back 패턴

  • Write Behinde 패턴이라고도 불림.
  • 캐시와 DB 동기화를 비동기하기 때문에 동기화 과정이 생략.
  • 데이터를 저장할 때 DB에 바로 질의하지 않고, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영.
  • 캐시에 모아놨다 DB에 쓰기 때문에 쓰기 커넥션 회수 비용과 부하를 줄일 수 있음.
  • Write가 빈번하면 서 Read를 하는데 많은 양의 리소스가 소모되는 서비스에 적합.
  • 데이터 정합성 확보.
  • 자주 사용되지 않는 불필요할 리소스 저장.
  • 캐시에서 오류발생시 데이터 영구소실의 가능성.

데이터를 저장할 때 DB가 아닌 캐시에 먼저 저장하여 모아놓았다가 특정 시점마다 DB로 쓰는 방식으로 일종의 Queue 역할을 겸하게 됨.
캐시에 데이터를 모았다 한 번에 DB에 저장하기 때문에 DB 쓰기 횟수 비용과 부하를 줄일 수 있지만, 데이터를 옮기기 전에 캐시 장애가 발생하면 데이터 유실이 발생할 수 있다는 단점이 존재.
반대로 DB에 장애가 발생하더라고 지속적인 서비스 제공을 보장하기도 함.
Replication이나 Cluster 구조를 적용하면 Cache Store 서비스의 가용성을 높일 수 있고, Read Through와 결함하변 가장 최근에 업데이트 된 데이터를 항상 캐시에서 사용할 수 있음.

Write Through 패턴

  • DB와 Cache에 동시에 데이터를 저장하는 전략.
  • 데이터를 저장할 때 먼저 캐시에 저장한 다음 DB에 저장.
  • Read Trough와 마찬가지로 DB 동기화 작업을 캐시에 위임.
  • DB와 캐시가 항상 동기화 되어 있어, 캐시의 데이터는 항상 최신 상태로 유지.
  • 캐시와 백업 저장소에 업데이트를 같이 하여 데이터 일관성 유지.
  • 데이터 유실이 발생하면 안 되는 상황에 적합.
  • 자주 사용되지 않는 불필요한 리소스 저장.
  • 매 요청마다 두번의 Write 가 발생함으로 빈번한 생성, 수정이 발생하는 서비스에서는 성능 이슈 발생.
  • 기억장치 속도가 느릴 경우, 데이터를 기록할 때 CPU가 대기하는 시간이 필요하기 때문에 성능 감소.

Cache Store와 DB에 동시에 반영하는 방식. 항상 동기화 되어 있고 항상 최신정보를 가지고 있다는 장접이 있음.
저장할 때마다 2개 과정을 거치기 때문에 상대적으로 느림.

Write Around 패턴

  • 모든 데이터는 DB에 저장
  • Cache Miss가 발생하는 경우에만 DB와 캐시에 데이터 저장
  • DB와 Cache Store의 데이터가 다를 수 있음.

Cache Miss가 발생하기 전에 DB에 저장된 데이터가 수정되었을 때, 사용자가 조회하는 Cache Store와 DB 간의 데이터 불일치 발생.


Cache 읽기 + 쓰기 전략 조합

  • Look Aside + Write Around
  • Read Through + Write Around
  • Read Through + Write Through

캐시 저장시 참고

  • Cache Hit Ratio : 캐시 사용의 정중도. 적중율이 높을 수록 CPU와 주기억장치 속도 차이로 인한 병목현상을 최소화할 수 있다.
    자주 사용되면서 자주 변경되지 않는 데이터를 캐시에 저장할 경우 높은 성능 향상을 이뤄낼 수 있다.
  • 지역성 (Locality) : Cache Hit Ratio는 캐시의 Locality, 즉 지역성에 의해 높아진다. 지역성이란 데이터 접근이 시간적 혹은 공간적으로 가깝게 일어나는 것을 의미함.
    • 시간적 지역성 : 최근에 엑세스 된 프로그램이나 데이터가 가까운 미래에 다시 엑세스 될 가능성이 높은을 의미.
    • 공간적 지역성 : 기억장치 내에 인접하여 저장된 데이터들이 연속적으로 엑세스 될 가능성이 높음을 의미.
    • 순차적 지역성 : 분기가 발생하지 않는 이상 명령어들이 기억장치에 저장된 수서대로 인출되어 실행됨을 의미
  • 일반적으로 캐시는 메모리에 저장되는 형태를 선호한다.
  • 메모리 저장소(Cache Store)는 대표적으로 Redis와 MemCached가 있으며, 메모리를 1차 저장소로 사용하기 때문에 디스크와 달리 제약적인 저장 공간을 사용한다.
  • 자주 사용되는 데이터를 어떻게 뽑아 캐시에 저장하고 자주 사용되지 않는 데이터는 어떻게 제거해 갈것이냐를 지속적으로 고민해야 할 필요성이 있다.
  • 캐시는 자주 사용되며 자주 변경되지 않는 데이터를 기준으로 하는 것이 좋다.
  • 캐시는 휘발성을 기본으로 하기 때문에 어느 정도 데이터 수집과 저장 주기를 가지도록 설계해야 한다.
  • 유실 또는 정합성이 일부 깨질 수 있다는 점을 항상 고려해야 한다.
  • 레파토 법칙 (8:2 법칙)
    전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 가리킨다.
    80%의 활동을 20%의 유저가 하기 때문에 20%의 데이터만 캐시해도 서비스 대부분의 데이터를 커버할 수 있다는 의미다.

캐시 제거시 참고

  • 캐시는 기본적으로 영구 저장소에 저장된 데이터의 복사본으로 동작하는 경우가 많다.
  • 데이터 동기화 작업이 반드시 필요하다는 의미로 개발시 고려해야 한다.
  • 캐시 만료 정책이 제대로 구현되지 않은 경우 클라이언트는 데이터가 변경되었음에도 오래된 정보가 캐싱되어 오래된 정보를 사용할 수 있다는 문제점이 있다.
  • 따라서 캐시 구성시 기본 만료정책을 설정해야 한다.
  • 만료 주기가 너무 짧으면 데이터는 너무 짤리 제거되고 캐시의 이점이 줄어든다.
  • 만료 주기가 너무 길면 데이터 변경의 가능성과 메모리 부족현상, 자주 사용해야 하는 데이터가 제거되는 등의 역효과를 나타낼 수 있다.

Cache Stampede 현상

  • TTL 값이 너무 작게 설정될 경우 발생할 수 있는 현상이다.
  • Cache Miss로 DB에 데이터를 요청한 뒤, 다시 Cache Store에 저장하는 과정을 거칠 경우 모든 application에서 DB에서 값을 찾는 duplicate read가 발생한다.
  • 읽어온 값을 각각 Cache Store에 저장하는 duplicate write도 발생하여 처리량도 다 같이 느려질 뿐 아니라 불필요한 작업이 굉장히 늘어나 폭주장애로 이어질 가능성이 있다.

캐시 공유시 참고

  • 캐시는 application의 여러 인스턴스에서 공유하도록 설계한다.
  • 각 application의 인스턴스가 캐시에서 데이터를 읽고 수정할 수 있다.
  • 캐시 업데이트 방식
    1. 캐시 데이터의 변경 직전에 데이터가 검색된 후 변경되지 않았는지 확인해야 한다.
      변경되지 않았다면 업데이트하고 변경되었다면 업데이트 여부를 어플리케이션 레벨에서 결정할 수 있어야 한다.
    2. 캐시 데이터를 업데이트 하기 전에 Lock을 잡는 방식.
      lock을 사용할 경우 조회성 업무를 처리하는 서비스에 Lock으로 인해 대기현상이 발생할 수 있다.

캐시 가용성 참고

캐시를 구성하는 목적은 빠른 성능 확보와 데이터 전달에 있으며 데이터의 영속성 보장하기 위함은 아니다.
데이터의 영속성은 기존 RDBMS에 위임하고, 캐시는 데이터 읽기에 집중하는 것이 성능확보의 지침사항이다.
또한 Cache Store가 장애로 인해 다운 되었을 경우나 서비스가 불가능 할 경우에도 지속적인 서비스가 가능해야 한다. 이는 데이터가 결국 RDBMS에 동일하게 저장되고 유지된다는 점을 뒷바침 한다.

728x90
반응형

참고 페이지의 간소화 버전이다. 아주 조금의 신경을 쓰면 명확하게 전달되는 커밋 메세지를 작성할 수 있다.

commit message 구조

  <타입>[적용 범위(선택 사항)]: <설명>

  [본문(선택 사항)]

  [꼬리말(선택 사항)]

1. 타입

  • commit 이 무엇애 대한 작업인지 키워드를 통해 인지
    • fix: - 버그 수정
    • feat: - 새로운 기능 추가, 기존 기능 변경
    • build: - 빌드 관련 수정
    • ci: - CI 관련 수정
    • docs: - 문서(주석) 수정
    • style: 코드 스타일, 포멧팅 수정
    • refactor: - 코드 리팩토링 (기능 수정 아님. )
    • test: - 테스트 코드 추가, 수정
    • chore: 기타 변경사항 수정 (.gitignore 등)

2. 설명

  • 커밋 메시지 제목
    • 제목은 50자를 넘기지 않고, 마침표를 붙이지 않기
    • 제목에 커밋 타입을 함께 작성
    • 과거 시제를 사용하지 않고 명령조로 작성
    • 제목과 본문은 한 줄 띄워 분리
    • 제목의 첫 글자는 반드시 대문자로
    • 이슈에 관련된 내용이라면 이슈 번호를 붙히기

3. 본문

  • 자세한 설명

4. 꼬릿말

  • 이슈 번호 등

참고 : https://www.conventionalcommits.org/ko/v1.0.0/#%ea%b0%9c%ec%9a%94

728x90
반응형

'VCS' 카테고리의 다른 글

[GIT] 한 컴퓨터에서 Github 계정 여러개 사용하기  (0) 2024.05.27
[GIT]  (0) 2024.04.10
[GIT] 브랜치, 커밋 간 다른 파일 목록 조회  (0) 2022.04.05
[GIT] remote branch 가져오기  (0) 2022.04.05
[TortoiseSVN] Disconnect 방법  (0) 2021.09.10

+ Recent posts