[신한투자증권 프로 디지털 아카데미] Github 및 DevOps 환경에 대한 이해(3)

 
 

0. Git

 
1) main
: 프로젝트의 기본 흐름을 관리하는 중심 브랜치, 모든 개발이 모이는 기본이자 최종 목표 브랜치, 여기로 기능을 합쳐서 결과물을 완성하고 사용자에게 전달한다
 
2) HEAD
: 지금 내가 작업하고 있는 스냅샷(commit)을 가리키는 포인터(pointer)
- Git은 내부적으로 포인터를 사용해서 커밋들을 관리
- 이 때 HEAD는 현재 작업 중인 커밋을 가리키는 특별한 포인터, 항상 하나의 커밋 또는 브랜치를 가리킴

- add 는 staging 하는 과정

$ git commit -am "메세지"		// -am = add + commit

 
 

1. Hello Conflict - 모르면 사고, 알면 기능 !

 
1) Git 3 way merge
: 공통 조상(Base) + 두 브랜치의 최신 상태(HEAD & Merge)를 비교해서 자동 병합하는 방식

• Base: 공통 조상 (두 브랜치가 갈라지기 전의 공통 커밋)
• Ours (HEAD): 현재 브랜치의 최신 커밋
• Theirs: 병합하려는 대상 브랜치의 최신 커밋

 
- Merge 할 때 깃에서는 공통의 조상을 찾음 그게 A, 그리고 각각의 브랜치에서 달라진 점을 찾음
- A → C1, A → C2 에서 달라진 점을 찾음, 이렇게 삼자대면 해서 merge 한다고 해서 3 way merge 라고 함
 
2) cherry-pick
: 부분 병합 가능 ↔ merge는 전체 변경 사항을 병합하는 것

$ git cherry-pick C1		// 현재 브랜치가 main 이고 최신 커밋이 C2인 상태에서 실행

 
- main(C2) 라고 가정하고 C1 을 cherry-pick 하고 싶은 경우, B1(부모 커밋) → C1(이식하고 싶은 커밋) 에서 달라진 내용을 C2(현재 브랜치의 최신 커밋) 에 이식함 → 이식 반영된 D 생성
- merge 처럼 base 와 비교 X
- cherry-pick 은 특정 상황에서의 변경만 병합하고 싶은 경우 사용
- 특정 커밋을 한 분기(branch)에서 다른 분기로 복사하는 명령어
 
3) reset
: HEAD 를 과거 커밋으로 되돌리는 명령어

현재 : A → B → C ← HEAD (현재 커밋)

$ git reset 옵션 커밋

결과 : A → B → C
	HEAD (현재 커밋)

• --soft : 커밋만 취소하고 스테이징 상태 유지, 주로 최근 커밋 메시지를 고치거나 다시 커밋할 때 사용
• --mixed (기본값) : 커밋 + 스테이징만 되돌리고 워킹 디렉토리는 건드리지 않음, 코드는 남기고 스테이지만 비우고 싶을 때 사용
• --hard : 커밋 + 스테이지 + 작업 파일까지 모두 삭제, 복구 불가능한 삭제가 될 수 있음

 
4) rebase
: 병합 기록 없이 내 브랜치의 커밋들을 상대 브랜치의 최신 커밋 위에 다시 쌓는 것 = 브랜치의 기반(base)을 바꿔서 커밋을 다시 쌓음
 
- 커밋 내용은 유지하되 순서 재정렬(조작을 해서 작업을 일렬로 만듦)
- 한 브랜치의 커밋을 다른 브랜치 위에 다시 적용
- 커밋 이력이 더 깔끔하고 직선형으로 됨 - 디버깅하거나 과거 코드를 찾기 쉬워짐
 

현재 : A---B---C  (main)
       \
        D---E  (feature)

$ git checkout main
$ git rebase exp		// 내가 main 에서 작업중이고 exp 는 동료가 작업한 브랜치, exp 위에 내 작업(main)을 재배치하고 싶은 경우

결과 : A---B---C---D'---E'	// D, E가 C 이후로 재적용됨 (D', E'는 새로운 커밋)

 
- 이렇게 하면 내 작업 커밋이 exp 커밋 뒤에 새롭게 이어짐
- 히스토리는 깔끔해지고, 처음부터 exp 기반으로 작업한 것처럼 보이게 해줌
 
 
5) revert
: 지정한 커밋의 반대 작업을 새 커밋으로 추가 ↔ cherry pick : 작업을 병합하는 게 아니라, 작업을 취소한 결과를 병합하는 것임
하는 명령어
 
- reset 처럼 커밋을 지우는 게 아니라, 취소하는 새 커밋을 추가
- 실수로 잘못된 코드 배포했을 때 유용
 
- 협업 중 안전하게 롤백

현재 : A---B---C---D  (HEAD)

$ git revert D

결과 : A---B---C---D---D'  (D'는 D의 반대 작업)

 
cf. https://error-note.tistory.com/15

[git] git reset,revert,restore를 통한 수정 전으로 되돌리는 방법(commit 취소, 삭제 등)

 
 

1. DevOps 알아보기

1. DevOps 가 중요한 이유

 
1) DevOps는 고객 만족과 더 빠른 가치 제공이라는 핵심 가치를 추구
- 개발팀과 운영팀 사이의 협력과 커뮤니케이션을 강화
- 전체 생명주기 관리
- 고객 만족과 가치 제공
 
- 방법론 : 스크럼, 칸반, 애자일
 
 

2. 마이크로서비스와 데브옵스 기술 소개 - Amazon 사례를 중심으로

0. Basics

 
1) Why Micoroservices?
- 과거: Two-tier Monolithic Architecture (2계층 모놀리식 구조)

• 하나의 애플리케이션으로 모든 기능이 통합된 구조, 전통적인 소프트웨어 개발 방식
• 과거 아마존은 프론트엔드 + 백엔드로 구성된 단일 애플리케이션 구조였음
• 한 부분의 문제가 전체 서비스에 영향
• 모든 기능이 한 앱에 묶여 있어서 유지보수와 확장에 어려움이 있었음
• 코드가 복잡하게 얽혀 있고, 작은 변경도 전체 애플리케이션 재배포가 필요했음

- 변화: Fully-distributed, Decentralized Services Platform

• 각 기능을 독립된 서비스(마이크로서비스)로 분리함
• 각 서비스는 독립적으로 배포 및 확장이 가능함

- 현재: 마이크로서비스 아키텍처 (MSA: Microservice Architecture)

• 서비스를 기능 단위로 잘게 나눠서 각각 독립적인 애플리케이션(서비스)으로 개발 및 배포하는 구조
• 사용자가 아마존에 접속하면, 백엔드는 100개 이상의 마이크로서비스를 호출하여 데이터를 모음

 
- SOA: Service-Oriented Architecture
: 서비스 지향 아키텍처, 서로 독립적인 서비스들이 네트워크를 통해 통신하면서 전체 시스템을 구성하는 아키텍처, 재사용 가능
 
- AWS Building Blocks

• AWS는 클라우드 아키텍처를 구성할 수 있는 기본 단위(Building Blocks)를 제공
• 사용자는 필요한 서비스들을 조합하여 자신만의 인프라 및 서비스를 구성 가능

- Amazon DynamoDB = 대표적인 Building Block

• DynamoDB는 Amazon이 설계한 고가용성(Highly Available) 기반의 Key-Value 저장소, NoSQL DB
• 대규모 분산 시스템을 위한 핵심 구성 요소로 활용됨

 
2) How to DevOps?
- Two pizza team : 한 팀이 피자 두 판으로 충분히 식사할 수 있을 정도의 소규모 팀일 때 가장 효율적이라는 아마존의 조직 철학, 의사결정이 빠르고, 커뮤니케이션이 간결해짐 → DevOps 문화에 적합
 
 

1. SOA Architecture

 
1) How to design smaller services?
- A Microservice Definition : Loosely coupled service oriented architecture with bounded contexts
 
- Loosely Coupled (느슨한 결합)

• 각 서비스가 독립적으로 개발·배포·운영 가능해야 함
• 변경이 다른 서비스에 영향을 주지 않아야 함
• “모든 서비스를 동시에 업데이트해야 한다면, 그것은 느슨하게 결합된 것이 아니다.”

- Service-Oriented Architecture (SOA)

• 서비스 단위로 기능을 분리하고, 명확한 책임을 부여함.

- Bounded Context

• 각 서비스는 자신의 업무 영역(Context) 내에서 독립적으로 동작.
• “주변 서비스에 대해 너무 많이 알아야 한다면, 경계가 제대로 설정되지 않은 것이다.”
  → 도메인 주도 설계(DDD, Domain-Driven Design)의 핵심 개념

 
2) About Netflix
- Service Oriented Architecture 를 클라우드 기반 배포 모델의 기반으로 채택
- 수백 개의 microservices 운영 중
- 사용자 요청은Edge Services(Netflix API Service)를 통해 프론트와 백엔드를 연결
- 경량화된 REST 기반 프로토콜을 사용
 
3) Death star architecture diagram
: 마이크로서비스가 지나치게 얽히고 복잡해진 상태를 보여주는 시각화 도구, 설계와 운영의 경고 신호

 
- 마이크로서비스가 많아지면 서비스 간 호출 관계도 늘어나고, 이걸 무분별하게 관리하면 데스 스타처럼 얽히고 설킨 시스템이 됨
- 결과적으로 트래픽 흐름 파악, 장애 추적, 서비스 독립성 유지가 어려워져 마이크로서비스의 취지가 퇴색됨
 
- 트위터는 loosely coupled 되어 있지 않음, 많이 사용되는 곳을 공격하면 트위터 전체가 무너질 수 있음, 그래서 넷플릭스가 더 좋은 설계임
 
4) How small is small?
- something that could be rewritten in two weeks
: 각 서비스(마이크로서비스)는 작고 독립적이어야 하며, 만약 문제가 생기거나 처음부터 다시 만들어야 한다면 2주 안에 개발자 1~2명이 다시 만들 수 있을 정도로 작아야 한다는 원칙
 

 
- 온 프레미스(On-Premise)
: 기업이 자체적으로 IT 인프라를 소유, 관리 및 운영하는 것
: 즉, 클라우드와 같이 원격 서버를 이용하는 방식이 아닌, 기업의 물리적인 공간에 서버를 설치하고 운영하는 형태
 
- Chaos monkey
: 장애를 미리 발생시켜 복원 능력을 검증함으로써 실제 장애가 났을 때도 사용자 서비스는 중단되지 않도록 설계할 수 있음
: 특정 시간에 무작위로 EC2 인스턴스(서버)를 종료하고, 그 상황에서 시스템이 자동 복구되고 트래픽이 다른 인스턴스로 우회되는지 확인
 
 
- Blue-Green Deployment 블루그린배포
: 애플리케이션을 무중단 배포, 서비스의 가용성과 안정성을 극대화하는 방식
: 빠르고 안정적인 롤백, 실서비스에 영향 주지 않고 테스트 가능
 
- Amazon DevOps Guru
: 애플리케이션 가용성을 향상시키는 ML 기반 클라우드 운영 서비스

• 개발자와 운영자가 문제를 자동으로 감지하여 애플리케이션 가용성을 개선하고 비용이 많이 드는 다운 타임을 줄일 수 있음
• 머신 러닝 경험 불필요
• 심각도가 높은 사고 이상을 감지하고 노이즈를 제거
• 장애에 의해 트리거 된 관련 메트릭의 이상, 추적, 변경 및 로그 이벤트를 상호 연관시킴
• 근본 원인이 될만한 가능성을 식별해 문제를 더 빨리 해결하도록 지원