패스트캠퍼스 캐시백 챌린지 1일차

 

 

수강 인증샷

 

 

Fastcampus에서 진행중인 캐시백 챌린지 이벤트에 참가하게 되어 한 번에 끝내는 AWS 인프라 구축과 Devops 운영 초격차 패키지 강좌에 대해 1일 1 블로깅 챌린지를 시작하게 되었다.

챌린지 신청일과 시작일 사이에 약간의 텀이 존재하기에 이미 수강한 내용은 2개정도씩 묶어서 다시 보고 블로깅하고 새로운 강의 1개를 매일 보는 식으로 진행할 예정이다. 온라인필기는 Notion을 자주 애용하여 Notion을 계속 사용할 것이다.

 

박병진 강사님 소개

• 현 당근페이 SRE 업무담당
• 그 외 github opensource Awesomecv, 해킹방어대회 defcon 참여 등..
• 박병진 강사님과는 devops 기본 강의준비,Iac,도커/쿠버네티스 강의에서 만날 예정

 

강의 자료&질문응답 안내

• Github 저장소 : https://github.com/tedilabs/fastcampus-devops
• Github Discussion https://github.com/tedilabs/fastcampus-devops/discussions

 

Devops 관련 커뮤니티 소개

• 하시코프 한국 사용자 모임 : https://fb.com/groups/hasicropkrug

⇒ Terraform, Packer, Vault, Nomad, Consul 등 하시코프의 제품에 관해 정보를 공유

• AWS 한국 사용자 그룹 : http://www.awskr.org

⇒ AWS 서비스에 대한 정보 공유 , Facebook&Slack 활성화

 

Devops 정의

• 위키피디아 정의

⇒ A set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality

⇒ 제품의 변경사항을 품질을 보장함과 동시에 프로덕션에 반영하는 데 걸리는 시간을 단축하기 위한 실천 방법의 모음

• 간단한 정의

⇒ 개발(Dev)과 운영(Ops)의 합성어로 개발과 운영의 경계를 허물고 통합하고자 하는 문화/철학

 

Devops 역사

• 단어가 처음 만들어진 것은 2009년 O’Reilly Velocity Conference의 “하루에 10회 이상 배포하기: Flickr에서 Dev와 Ops의 협업

⇒ 당시에 클라우드 서비스가 도입되지 못했던 상황이기에 서버 장비를 직접 구비하여 개발 환경을 갖추었고, 개발팀과 운영팀은 분리되어있었다. 개발팀에서 개발을 완료하더라도 서비스 운영팀에 개발 결과물을 전달해주어야 하고, 운영팀에서는 Production에 올리기 위해 개발 결과물을 이해하는 식으로..

⇒ 이 과정에서 많은 커뮤니케이션 오버헤드가 발생하고 부서 간의 갈등 발생

  (서버 문제야 vs 운영 쪽은 문제없는데 코드 문제야)

• 패트릭 드부아가 10 Deploys per Day 발표를 듣고 감명받아 DevOpsDay라는 콘퍼런스를 주최

 

Devops가 필요한 이유

• 소프트웨어의 개발 주기 SDLC(Software Development Lifecycle)에 대해 먼저 이해할 필요가 있다. Design - Develop - Test - Deploy - Operate - Support
• ( Architect - Developer - SDET - Release Eng - Sys Admin - Customer Support)
• (Netflix blog에 의하면..)

⇒ 조직의 규모가 크다면 각 단계별로 전문가로 구성된 기능 조직을 운영할 수 있다.

⇒ 하지만 각 단계를 넘어가기 위해 의사소통이 많아지기 때문에 커뮤니케이션 문제가 발생하고, 특정 구간에서 병목구간이 생기기 쉬워진다.

• Devops는 위와 같은 Process를 개선하기 위한 움직임이다. Devops가 조직에 정착되면 개발자는 작성한 코드에 대해 스스로 테스트하고, 배포하고, 운영에 참여할 수 있다.
• Netflix는 더 나아가 소프트웨어의 모든 단계에 참여할 수 있는 풀 사이클 개발자 모델을 제시한다. ( Full Cycle Developer)

 

Devops는 어떻게 하는 것인가?

• 데브옵스는 패러다임이다.
• 데브옵스는 방법을 제시하지 않는다.
• 데브옵스는 문화이다.

⇒ “개발과 운영의 벽을 허물어 더 빨리 자주 배포하자”라는 명확한 목표를 가지고 있다.

• devops 초격차 패키지에서는 devops실천방법으로 다음과 같은 6가지를 제안한다.

1. 지속적 통합(Continuous Integration) : 개발자가 만든 변경사항에 대해 빌드 및 테스트를 진행해본 뒤에 종합 코드 저장소에 통합하여 빠르게 버그를 발견하고 제품의 품질을 보장하게 하는 개발 방법
2. 지속적 배포(Continuous Delivery) : 개발 결과물의 산출물을 자동으로 개발환경이나 운영환경까지 배포하도록 만든 자동화된 파이프라인
3. 마이크로서비스(Micro-Service) : 규모가 큰 서비스인 경우 아무리 자동화된 파이프라인이 있더라도 서비스가 거대해 빌드하는 데에 시간이 오래 걸리기에 빌드/테스트 단계에서 병목현상이 일어난다. 커다란 서비스를 여러 서비스로 쪼개 빌드 타임과 배포 타임을 단축시킨다.
4. Iac(Infrastructure as Code) : 인프라의 변경사항을 자동화시켜 빠르게 적용하기 위해 인프라 또한 자동 화적으로 관리가 필요
5. 모니터링과 로깅(Monitoring & Logging) : 개발자들에게 제품의 metric과 log데이터를 중앙에서 확인할 수 있는 환경 제공
6. 소통 및 협업(Communication & Collaboration) : 사내에서 사용하는 slack 메신저, 지라 같은 이슈 트래킹 , Confluence, Notion 같은 wiki 시스템 잘 활용

• Flickr에서 제시된 모델은 다음과 같다.

 

변화에 대응하기 위한 도구

 

1. 자동화된 인프라(Automated Infrastructure)

2. 버전 관리 공유(Shared Version Control)

3. 쉬운 빌드 및 배포(One-Step Build and Deploy)

4. 기능 활성화 스위치(Feature Flag)

5. 메신저 봇(IRC and IM Robot)

 

변화에 대응하기 위한 문화

 

1.존중(Respect)

2.신뢰(Trust)

3.실패에 대한 긍정적인 자세 (Healthy Attitude about Failure)

4.비난하지 않기 (Avoiding Blame)

 

 

---

그동안 devops에 관한 여러 정의들을 보았을때 다소 추상적인 설명으로 다가왔었는데 본 강의를 통해 devops의 철학과 역할에 대해 잘 알게되었던 것 같다. 66일간의 챌린지를 통해 devops의 전반적인 업무에 대해 이해하고 캐시백까지 받을 수 있기를!!

 

 

https://bit.ly/3L3avNW

패스트캠퍼스 [직장인 실무교육]

*본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.