DevOps 실현
- Immutable Infrastructure로의 변경 : 운영 영역
- Deployment 방법론 변경 > ex) Blue-Green Deployment : 운영 영역
- Public Cloud(Cloud 환경이 유리) : 운영 영역
- SaaS 솔루션 활용 : 운영 영역
- Log 수집 및 분석 : 운영에서 개발 개선으로 가는 영역
Immutable Infrastructure
- 기존 인프라의 사례(문제점)
: 개발 환경에서 어떤 설정을 하고 동작하는지 테스트하여 확인(문제 없음 확인)
: 이후, 운영환경에서 실시했더니 문제 발생
예시1)
- 문제 : 필요한 모듈이 없어 동작하지 않음
- 진단 : 개발 환경에서 이전의 테스트를 위해 도입했었던 모듈 존재(운영환경에는 없었음)
예시2)
- 문제 : 운영환경 서버의 내장 디스크 용량의 고갈
- 진단 : 장애 대응을 하면서 분석을 위해 일시적으로 보관하던 파일이 지워지지 않고 남아 있음
예시3)
- 문제 : 미들웨어 업그레이드 진행 ~> 미들웨어가 업그레이드를 지원하지 않음
- 경과 : 모든 것을 Uninstall 한 후 재설치 ~> 작업 기간 동안 서비스 사용 불가능
- 기존 문제점 정리
: 인프라를 과거의 상태에서부터 누적하여 관리하지 않으면 안되기 때문에 발생 > 매우 어려움
: 해결방안 > 과거의 상태를 관리하지 않기 : Immutable Infrastructure 개념
> 과거의 상태를 관리 안하면 어려움이 없다!
- 과거의 상태를 누적하지 않아도 되는 인프라 = 변하지 않는 인프라
: 개념> 한 번 가동하기 시작한 인프라는 두 번 다시 변경하지 않는다.
: 그렇다면 인프라를 변경하지 않고, 인프라에 대한 변경이나 개선을 어떻게 하는가?
> 모든 것을 처음부터 다시 만든다
> 인프라의 변경이 필요할 시 기존 인프라 폐기 & 새로운 인프라를 구축하며 개선
- 가능해진 이유
: 가상화 기술과 클라우드 기술이 보급
> 인프라를 캐쥬얼하게 만들거나 파괴할 수 있는 환경
> + Ansible과 같은 인프라 구성 도구의 존재 : 언제든지 동일한 인프라 구축을 자동화 가능
- 인프라 변경 비교
> 가상화 기술, 클라우드 기술, 인프라 구성 관리 도구 발전 등으로 신규 구축 난이도가 쉬움
- Immutable Infrastructure의 장점
: 예상 외의 문제를 막을 수 있음
> 깨끗한 환경 유지 : 불필요한 패키지 및 설정과 불필요한 파일이 없음 = 문제 발생 여지가 없음
: 실행 후 인프라 설정과 상태를 관리할 필요 없음
> 운영환경에 어떤 설정이 적용되었는지 관리할 필요 없음 : IaC에 따라 코드로 구현
> 운영환경을 만들기 위해 사용한 IaC는 관리
: Infrastructure as Code를 강제적으로 실현
> Ansible 등의 인프라 구성 관리 도구를 도입하여도 불안함
- 누군가의 운영환경 수정 / 운영환경과 관련 없는 코드 등
> 운영환경의 수정이 무의미 함
- 다음 Release 시에 파기하고 새로 제작
- 운영환경을 수정하려고 하지 않게 됨 = IaC의 실현
: 장애 대응 및 설정 변경 작업이 획일적으로 가능
> 어떤 문제든지 대응 방법 = 처음부터 다시 제작
- 기존) 모든 설정 변경 및 복구 처리 지침 > 필요에 따른 선택과 진단, 해결
- 인프라를 새로 생성 > 자동화 > 작업의 변동폭의 감소 > 운영자의 부담 감소
- Immutable Infrastructure의 단점
: 모든 인프라가 Immutable 할 수 없음
: 상태의 재현 불가능
> "파기 후 신규 생성" => "인프라를 처음부터 만들어 복구 가능"
> Ansible과 같은 인프라 구성 관리 도구
- 소프트웨어 / 시스템의 구축 및 설정까지는 가능(자동화)
- 상태 재현은 불가능(데이터 문제)
> 상태가 없는 인프라에 적용은 손쉽게 가능
ex) Stateless 방식인 웹 시스템 들
> 상태가 있는 인프라에 적용은 어렵거나 비현실적
ex) Database
- 주의할 점
: 인프라를 파기하지 않고 남겨두고 싶은 경우
> Immutable Infrastructure는 기존 인프라를 파기
- 새로운 인프라에 문제가 발생하였을 때, 이전 인프라와 비교 분석 후 진단이 필요할 수도 있음
- 기존 인프라를 파기 하지 않고 남겨둘 필요가 있음
: Immutable Infrastructure를 통해 재구축 시, 조작의 대상이 대상 서버에만 머물지 않음
= Infra만 바꾸면 끝나는 것이 아님(Infra를 감시하고 있는 외부의 서비스가 존재할 경우 이를 해결해야 함)
> ex) 감시 설정
- 감시 대상 서버 : 모니터링 서버에 감시 대상 서버 등록 및 해제 필요
- 발견과 해제에 대한 자동화가 지원된다면 쉽게 해결 가능
: 기존 인프라 파기 -> 새로운 인프라로 전환하는 문제는 여전히 존재
> Blue-Green Deployment 전환
Blue-Green Deployment
- 지속적인 개발 > 지속적인 통합 > 지속적인 딜리버리 > 디플로이
- "디플로이" : 가동 중인 서비스의 조작
~> 설정/관리의 어려움은 Immutable Infrastructure 도입으로 해결
~> 전환 문제 해결 필요
- 기존 Release 작업의 문제
: Release 할 때, 제공되는 서비스를 정지할 필요 발생
> 자동화를 통해 Release 작업 시간을 단축해도 중단 시간은 발생 함
= 서비스의 Usability(유용성)을 해침
: Release 할 때, 발생한 문제 해결에 많은 시간이 소요됨
> Release 중 문제가 발생하면, 장애의 규모가 더 커짐
- 문제 해결
> 목표 : 이용자가 서비스를 이용할 수 있는 상태가 되는 것
> 방안 :
1) Release 이전 상태로 되돌리기
2) 대첵 마련을 위한 원인 조사와 문제 해결
- 문제 발생의 원인
: 운영 환경이 한 종류 밖에 없기 때문
: 운영 환경이 단 하나 밖에 없다면 앞의 문제는 피하거나 해결할 수 없음
>> Blue-Green Deployment 고안
- Blue-Green Deployment 개념
: 환경은 Blue와 Green, 두 가지 환경으로 구성
> 사용자는 두 환경 중 하나만 이용
> Blue, Green 여부는 인식 X
: 사용자가 사용하지 않는 쪽의 환경에 Release 작업 수행
> 최종적으로는 상위 레벨에서 Blue 또는 Green으로 연결 전환
= Blue, Green 위에서 사용자를 연결시켜주는 상위레벨의 연결자가 필요(ex, 로드밸런서 등)
> 순식간에 전환을 완료 시키는 것
- 장점
1. Release 작업의 대부분을 사용자에게 영향을 주지 않고 가능
: 사용자가 Blue 환경이면 Green에서 독립적으로 작업 수행 = 서비스 영향 X
2. 전환 작업을 순식간에 할 수 있음
: Release 작업을 모두 마친 후, 전환을 순식간에 완료할 수 있음
: Release 작업으로 인한 영향 최소화
3. 문제 발생 시 쉽게 이전 버전으로 되돌릴 수 있음
: Blue에서 Release 수행 > Green에서 Blue로 전환 > Blue에서 장애 발생
: Blue에서 Green으로 전환(되돌리기) = 복구 완료 > Blue의 문제 조사 및 대응 실시
- 해결해야하는 과제
: 원래의 인프라를 이중으로 유지할 필요
> 한 쪽을 활용하지 않기에 유휴 인프라 발생
> 가상화 기술 / 컨테이너 기술의 적극적 도입으로 해결
= 리소스를 최소화 할 수 있게 조정 가능(비용 최소화)
: 비용 추가는 존재
: 상태를 가지는 서버는 이용이 어려움
- Blue <=> Green 전환 방법(전환 기술 추가 필요)
: DNS를 사용한 전환
: Load Balancer를 사용한 전환
: Cookie 를 통한 전환
Cloud 서비스(위의 전환 기술까지 포함되어 있음)
- On-Premise
: 서버 및 네트워크 장비 등을 자사에서 구매(또는 리스)
: 전통적인 인프라 활용
- Public Cloud
: 인프라를 인터넷에서 클라우드 공급자를 통해 관리(IaaS)
: 자원 조달의 편리성 극대화
- On-Premise VS Public Cloud
> 처음부터 웹 서비스를 구축/제공 한다면
: IaC 관점 + DevOps 관점 = Cloud 환경이 용이
> 기 구축된 On-Premise 환경이 있다면
: 클라우드로 마이그레이션 할 만큼의 장점이 있는지 파악
: 마이그레이션 : Immutable Infrastructrue / Blue-Green Deployment 전환 수반 필요
SaaS(Software as a service)
- 모니터링 : Datadog, ...
- 외형감시 : Pingdom, ...
- 지속적 통합 : CircleCi / Dron Ci / Travis Ci ...
- Single Sign On : OneLogin, ...
- Incident 관리 : PagerDuty
- 대시보드 : Chartio, ...
- 전화 통지 : twilio, ...
- 로그 분석 : simologic, ...
로그 수집과 분석
- 시스템 로그, Access 로그, 오류 로그
- 당시에 기록된 사건을 분석하는 데 필요한 매우 중요한 원천
: 장애 분석 및 감사 목적에 주로 사용
: DevOps > 발전적인 목적으로 활용 가능
- Logstash / Fluentd 등으로 실시간 수집
: 기존 > 정기적으로 로그 취합
> 정해진 시간에 로그를 취합 서버에 전송 > 모아서 한번에 전송
: DevOps의 Immutable Infrastructure 같은 환경
> 언제든지 파기 가능 ~> 실시간에 가깝게 로그 전송 필요
'DevOps' 카테고리의 다른 글
| #13 Site Reliability Engineering (0) | 2025.06.11 |
|---|---|
| #12 DevOps와 애자일 개발 (3) | 2025.06.11 |
| #10 CI/CD (1) | 2025.06.11 |
| #9 Github Action (0) | 2025.06.11 |
| #8 Build Pipeline 관리 (0) | 2025.04.26 |
