차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- wiki:pm:devops:데브옵스_devops_구축에_관해 [2022/03/24 16:02]
bjlee
+++ wiki:pm:devops:데브옵스_devops_구축에_관해 [2023/01/13 18:44] (현재)
@@ 줄 1: / 줄 1: @@
-=====데브옵스 구축=====
+====== 데브옵스 구축 ======
-데브옵스(DevOps)구축에 틀이 정해진 것은 아니다. __좋은 건 알겠는데 개발팀과 운영팀의 업무를 어떻게 나누고, 그 업무를 잘 나누도록 결정하는 사람은 누가될 것인가?__\\
+데브옵스(DevOps)구축에 틀이 정해진 것은 아니다.
+\\
+__좋은 건 알겠는데 개발팀과 운영팀의 업무를 어떻게 나누고, 그 업무를 잘 나누도록 결정하는 사람은 누가될 것인가?__\\
 데브옵스의 핵심이자 가장 어려운 부분이다.
 ----
-===데브옵스는 팀을 만들자는 것이 아니다.===
+=== 데브옵스는 팀을 만들자는 것이 아니다. ===
+\\
 데브옵스 팀은 1인 2역(개발+운영)을 담당하는 사람들의 모임이 아니다.
 운영팀과 개발팀은 같은 제품에 관여하지만, 입장과 역할이 다르다.\\ 데브옵스는 이들의 일을 합해서 한 부서에 몰아주는 것이 아니라, 각자의 역할에 집중하도록 만드는 일에 가깝다.
 ===소통과 협업을 통해 각자의 업무에 집중할 수 있게 하는 것===
+\\
 조직 내 데브옵스를 구축하는 것은 __개발자와 운영자 중간에 존재하는 모호한 업무 영역을 어떻게 관리할지 정하는 일__이다.\\
 소통과 협업, 투명하고 솔직한 문화를 통해, 개발하는 사람은 개발에만 집중할 수 있고 운영하는 사람은 운영에만 집중할 수 있는 환경을 만들어야 한다.
 ----
-===문화를 바꿔보자===
+=== 문화를 바꿔보자 ===
+\\
 데브옵스 문화는 개발하는 서비스, 회사 규모, 조직 구성원에 따라 다를 수 있다.\\
 따라서 완벽한 데브옵스의 기준도 명확히 정의할 수 없으며, 서비스 개발에 관여한 모두가 데브옵스 문화에 기여해야 한다.
@@ 줄 24: / 줄 29: @@
 ----
 ===문화를 만든다고 데브옵스 인가?===
+\\
 당연히 No\\
 문화와 사고방식의 변화는 데브옵스를 적용하기 위한 가장 기본적인 조건이다.\\
-모두 한 마음 한 뜻으로 데브옵스를 적용하기로 했다면, 소통과 협의를 통해 어떤 부분을 자동화할 것인지, 어떤 도구를 사용하면 효율적인지 끝없는 협의와 조율의 시간을 갖자.\\
+모두 한 마음 한 뜻으로 데브옵스를 적용하기로 했다면, 소통과 협의를 통해 어떤 부분을 자동화할 것인지, 어떤 도구를 사용하면 효율적인지 끝없는 협의와 조율의 시간을 갖자.
-=====올바른 데브옵스 구축을 위한 7가지 고려 사항 (Feat. 툴 선택을 잘하자)=====
+\\
-{{:wiki:pm:devops:devops_model.png?400}}\\
-그림_데브옵스 모범 모델
+===== 올바른 데브옵스 구축을 위한 7가지 고려 사항 (Feat. 툴 선택을 잘하자) =====
+<그림>데브옵스 모범 모델\\
+{{:wiki:pm:devops:devops_model.png?550}}\\
 \\
 \\
@@ 줄 68: / 줄 76: @@
 \\
 **목표는 모든 것을 자동화 하며 이를 통해 DevOps를 더 잘 수행하는 방법을 지속적으로 실험해보고 DevOps 운영을 해야 하는 것이다!**
+===== DevOps 사례 =====
+==== Amazon ====
+\\
+<그림>2000년도 초반의 아마존\\
+{{:wiki:pm:devops:amazon01.png?400|}}\\
+작은 application이나 소규모의 개발 환경에는 문제가 없지만, 빠르게 성장하고 있는 Amazon에게는 문제가 되었다.
+  * 확장성 부재
+  * 컴포넌트 문제로 전체 시스템 장애
+  * 느린 배포 속도
+  * 다양성 부족
+\\
+\\
+<그림>데이터를 분리 하기 시작\\
+{{:wiki:pm:devops:amazon02.png?500|}}\\
+\\
+\\
+<그림>서비스 진화\\
+{{:wiki:pm:devops:amazon03.png?400|}}\\
+  * 개발에서 배포까지의 일련의 과정이 수일~수주까지 걸리는 어려움이 있었음.\\
+\\
+\\
+{{:wiki:pm:devops:amazon04.png?400|}}
+  * 서비스 지향 아키텍처의 도입으로 서비스를 분리
+  * 애자일 개발 방식 도입
+  * 개발 속도 향상
+  * 작은 장애 범위 구성
+\\
+\\
+{{:wiki:pm:devops:amazon05.png?400|}}\\
+  * application을 단위별로 쪼개고, 분해하기 시작
+    * 고객 지향적
+    * 서비스에 대한 책임 부여
+    * 빠른 혁신
+    * 빠른 움직임
+\\
+\\
+{{:wiki:pm:devops:amazon06.png?400|}}\\
+  * 각 서비스를 담당하는 팀에 그들만의 tool을 제공
+    * self-service 환경 제공
+    * 각 팀에게 자체 배포 process를 소유, 관리하게 함
+  * 서비스간의 통신은 모두 API로 표준화
+    * backend 간의 dependency를 없애게 됨
+  * 서비스를 개발한 팀이 해당 서비스를 가장 잘 안다는 기준 아래서 bug가 발생하면 바로 수정을 하는 형식
+    * 운영 권한과 모니터링 권한을 줌
+    * 서비스 빌드 / 테스트를 하도록 함
+\\
+\\
+==== Facebook ====
+\\
+페이스북은 사용자 증가와 새로운 서비스 오픈에 따라 엄청난 트래픽이 발생했으며, 이로 인해 시스템이 중단되었다.\\
+시스템에 영향이 가지 않으면서도 새롭게 출시하는 기능을 테스트할 수 있는 방법으로 다크 론칭(Dark Launching) 기법을 고안했다.\\
+다크 론칭 기법은 특정 사용자에 한정해 새로운 기능을 배포하고 테스트한 뒤 피드백을 반영하여 새 기능이 안정화되면 전체 배포하는 방식이다.\\
+또한 CD(Continuous Delivery) 도입을 통해 새로운 서비스 배포가 기존 애플리케이션 성능에 영향을 미치지 않고, 더욱 빠르고 편리하게 서비스를 릴리즈한다.\\
+\\
+다크 론칭 기법에서는 전용 배포 파이프라인을 통해 새로운 기능을 일부 사용자에게 배포한다.\\
+아래 그림처럼 선택한 사용자 그룹에 해당하는 파이프라인만 동작하고 그 외 파이프라인은 모두 꺼진다.\\
+{{:wiki:pm:devops:darklaunching.jpg?600|}}\\
+새 기능이 배포된 특정 사용자 그룹을 지속적으로 모니터링하고 피드백을 반영하여 동일한 사용자 기준으로 안정성이 확보되면 꺼져있는 다른 배포 파이프라인을 켜서 나머지 사용자를 대상으로도 점진적으로 배포한다.
+\\
+\\
+만약 테스트에서 문제를 발견하면 롤백한다. 이는 페이스북이 데브옵스를 기반으로 CI/CD 도입함으로써 가능하게 되었다.\\
+{{:wiki:pm:devops:darklaunching02.png?600|}}
+\\
+\\
+페이스북에는 별도 QA팀이 없다.\\
+개발자는 새롭게 개발한 모든 코드를 직접 테스트하며, 코드는 커밋과 푸시 작업의 일부로 자동화된 테스트를 모두 통과해야 한다.\\
+개발자는 DevOps를 위해 구성된 조직을 통해 개발 외에 소프트웨어 운영 및 사용에도 동참하며, 이는 개발 시점부터 좋은 코드를 쓰고 철저하게 테스트를 진행하는 동기가 된다.\\
+이러한 책임 문화는 심각한 버그 발생을 막는 데 도움이 됐다.
+\\
 ===== Ref =====
-https://cloudmt.co.kr/?p=3436\\
+[[https://cloudmt.co.kr/?p=3436]]\\
-[[https://media.fastcampus.co.kr/newsletter/wennews/%EA%B0%9C%EB%B0%9C%EC%9E%90-%ED%95%84%EB%8F%85-%EC%B6%94%EC%B2%9C-%EC%98%AC%EB%B0%94%EB%A5%B8-%EB%8D%B0%EB%B8%8C%EC%98%B5%EC%8A%A4-%EA%B5%AC%EC%B6%95%EC%9D%84-%EC%9C%84%ED%95%9C-7%EA%B0%80%EC%A7%80|올바른 데브옵스 구축을 위한 7가지]]
+[[https://naon.me/posts/til137]]\\
-{{tag>밤즌 데브옵스 DevOps 데브옵스구축}}
+[[https://media.fastcampus.co.kr/newsletter/wennews/%EA%B0%9C%EB%B0%9C%EC%9E%90-%ED%95%84%EB%8F%85-%EC%B6%94%EC%B2%9C-%EC%98%AC%EB%B0%94%EB%A5%B8-%EB%8D%B0%EB%B8%8C%EC%98%B5%EC%8A%A4-%EA%B5%AC%EC%B6%95%EC%9D%84-%EC%9C%84%ED%95%9C-7%EA%B0%80%EC%A7%80|올바른 데브옵스 구축을 위한 7가지]]\\
+[[https://chloe-codes1.gitbook.io/til/aws/aws-builders-series/06_devops_-_-_-_-_-_|Amazon's DevOps]]\\
+[[https://m.post.naver.com/viewer/postView.naver?volumeNo=33504820&memberNo=15488377&searchKeyword=aws&searchRank=729|Facebook's DevOps]]
+{{tag>밤즌 데브옵스 DevOps 데브옵스구축 데브옵스사례}}

문제를 잘 정의하는 것은 문제를 절반 해결한 것이다. - 2023.12

사용자 도구

사이트 도구

차이

문서 도구