생각을 개발하자, 박진형

[TIL - 1018] git command, APM이란, aws 리소스 알아보기

git

git flow(+operation)

  • fork flow : master, develop, feature, release, hotfix 브랜치로 구성하고, 저장소는 upstream, origin, local으로 구성함
    • 브랜치 : master가 현재 운영, develop은 기능 개발 시 출발점이 되는 브랜치, feature는 각 기능 개발 때 사용되는 브랜치(develop에서 branch 생성), release는 다음 release될 브랜치, hotfix는 긴급하게 수정해야하는 상황이 발생했을 때 master로부터 브랜치를 따서 수정 후 merge 배포를 진행함(절대적인 것은 아님! - 각 팀의 운영 노하우에 따라 조금씩 수정될 수 있음)
    • 저장소 : upstream을 prod로 사용하고 origin은 개발자 개인 repo로 upstream을 fork한 repo, local은 개발자의 로컬 저장소

command

  • cherry-pick : 특정 브랜치와 merge 하는 것이 아니라 특정 브랜치들의 변경사항은 각각 놔두면서 흡수하는 것 - 새로운 커밋(들)을 만들어냄(내용은 복사본, pick한 커밋만큼 생성)
    • next-release 작업이 진행되고 있는 상황에서(dev까지 완료되었건 feature에 있건 간에) master에 긴급 수정한 내용이 생겼을 때 next-release에도 반영해야한다면 cherry-pick을! : release 브랜치에서 새로운 커밋 생성
/* master */
4c01e372f5f7e7ff727f3f5422fae19f0154d7ad (HEAD -> master) prod hotfix
bb237d418692237ebd09bf09178675b8e067fb9e prod commit

> git cherry-pick 4c01e37

/* release branch */
97594e7ccb7b20f375ed109cf0f107f9ee96dc9c (HEAD -> release) prod hotfix
c869dada3813365f36ff4c034fbd244fe2c57324 next-release commit
bb237d418692237ebd09bf09178675b8e067fb9e prod commit
  • interactive rebase(squash) : 여러 커밋을 하나의 커밋으로 만드는 작업을 할 때 사용 - 단 원격저장소(hub 목적)에 push한 커밋가지고는 하지말기!(reset 보다 revert를 사용하는 것이 더 나은 이유와 같음)

infra

  • APM : Application Performance Management(성능 관리, 모니터링툴) - pinpoint, new relic 등이 있음
    • 3계층(tier) 구조 : 프론트 / 서버 / 데이터베이스, 지금은 3계층 이상으로 N계층으로 더 세분화해서 나눔(MSA) - 도메인 별로 더 쪼개서 관리하기 쉽도록, 관리해야할 대상이 많아져 몇군데만 보는 것이 아니라 다 들여다보고 대응할 수 있어야해서 APM을 사용하게 됨
    • tier와 layer 차이 : 외부로 분리해내는 것과 내부적으로 계층을 나눈 것

AWS 리소스

  • AMI : Amazon machine Image - 인스턴스를 이미지화 하여 복제(scale out)가 쉬움, AWS는 트래픽에 따라 오토스케일링이 편하다는 점!
  • access key ID/secret key : API로 리소스 사용가능(써드파티툴로 제어가능) - 주로 마스터 계정의 액세스키가 아닌 IAM 계정(제한된 권한)의 액세스키를 발급하여 사용
  • cloud watch : EC2 인스턴스를 비롯한 모니터링 가능한 서비스의 인스턴스에 attach 시키면 됨, 알람 수치를 설정할 수 있음, 뿐만 아니라 오토스케일링(out, in)
  • aws-cli : cli에서 aws 리소스를 제어할 수 있음 - 단 access-key가 있어야함(발급 받으면 됨)
  • s3 : HTTP로 파일 업로드, 다운로드 가능 - 동적인 처리없이 정적으로 파일만 주고 받는 프로그램을 만든다면 S3를 사용하는 것이 더 효율적
    • 업로드 후 curl로 다운로드 테스트
    • 버킷에 권한 설정 가능 : AWS에서 제공해주는 기능으로 버킷에 대한 정책(공개 여부, 공개 범위 등) json 데이터를 만들기 쉽고 적용하기도 쉬움
    • metadata 설정으로 캐시 설정 가능, 라이프 사이클 설정 가능, 버져닝 가능(동시에 라이프 사이클 설정은 안됨)
    • 해봐야할 것 : spring cloud로 S3 파일 업로드 해보기
  • cloud front(캐시 서버 - 엣지 로케이션) : HTTP 메소드로 동적인 작업일 경우(POST, PUT, DELETE 등) origin으로, 그 외엔 파일 있을 경우 캐시된 파일을 내려주고 origin으로
    • cloud front에 복사된 파일이 없을 경우 origin으로 가게 되어있음 : 임의 갱신할 때 이용할 수 있는 특징(요청 URL 변경하기)
    • deploy : 엣지 로케이션에 배치된(생성된) 단위
    • 단순하게 가까워서 얻는 이점도 있음
    • ec2 - cloud front(custom origin) 연동 : HTTP 통신
  • rds
    • 탄력적으로 관리 가능 : 스케일링 가능, replica 서비스 제공 등
    • 해봐야할 것 : master/slave(Replication) 구성해보기

네트워크

HTTP 헤더

  • referer : 어디에서 요청을 했는지 나타내는 값을 Request 헤더에 넣어서 보냄