Merge pull request MichaelCade#346 from Me1e/ko/translate

Translated 2022 day05~ to korean

Author: MichaelCade

2022/ko/Days/day05.md

@@ -0,0 +1,86 @@
+---
+title: '#90DaysOfDevOps - Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor > - Day 5'
+published: false
+description: 90DaysOfDevOps - Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor >
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048830
+---
+
+## 계획 > 코드 작성 > 빌드 > 테스트 > 릴리즈 > 배포 > 운영 > 모니터링 >
+
+오늘은 데브옵스 환경에서 애플리케이션의 시작부터 끝까지 개별 단계와 continuous cycle에 대해 집중적으로 살펴보겠습니다.
+
+![DevOps](/2022/Days/Images/Day5_DevOps8.png)
+
+### 계획
+
+개발팀이 다음 스프린트에서 출시할 기능과 버그 수정을 결정하는 계획 프로세스는 데브옵스 엔지니어가 참여하여, 앞으로 어떤 일이 발생할지 파악하고 개발팀의 결정이나 경로에 영향을 미치고, 그들이 구축한 인프라로 작업하도록 돕거나 그들이 다른 경로를 따를 경우 더 나은 방향으로 안내할 수 있는 기회입니다. 중요한 점은 개발자나 소프트웨어 엔지니어링 팀이 데브옵스 엔지니어의 고객이 되므로, 고객이 나쁜 방향으로 가기 전에 고객과 협력할 수 있는 기회라는 것입니다.
+
+### 코드 작성
+
+이제 계획 세션을 마치고 코드 작성 단계에 진입합니다. 이 단계에서 당신이 참여할 수 있는 역할 중 하나는 코드를 작성하는 동안 인프라에 대한 이해도를 높여서 어떤 서비스를 사용할 수 있는지, 그 서비스와 어떻게 상호작용할 수 있는지를 더 잘 이해할 수 있도록 돕는 것입니다. 또한, 코드 작성이 완료되면 해당 코드를 리포지토리에 병합하는 일도 중요한 역할입니다.
+
+### 빌드
+
+여기에서는 자동화 프로세스의 첫 번째로, 코드를 가져와서 사용하는 언어에 따라 변환하거나 컴파일하거나 해당 코드에서 도커 이미지를 생성할 수 있기 때문에, CI 파이프라인을 사용하여 이러한 프로세스를 자동화할 것입니다. 이렇게 함으로써, 코드를 변경하거나 새 코드를 추가할 때마다 일일이 수동으로 작업하는 것이 아니라, 자동화된 프로세스를 통해 더욱 효율적이고 일관성 있는 작업을 수행할 수 있게 됩니다.
+
+## 테스트
+
+빌드가 완료되면 몇 가지 테스트를 실행합니다. 개발 팀은 보통 어떤 테스트를 작성할지 제안할 수 있지만, 이를 실행해야 합니다. 테스트는 프로덕션에 문제가 발생하지 않도록 최소화하기 위한 시도입니다. 새로운 버그가 발생하지 않도록 보장하는 것은 불가능하지만, 최대한 이전에 작동하던 것이 깨지지 않도록 보장하기 위해 노력합니다.
+
+## 릴리즈
+
+테스트가 모두 통과되면, 애플리케이션 유형에 따라 릴리스 프로세스가 수행됩니다. 하지만 이 단계는 작업 중인 애플리케이션에 따라 생략될 수도 있습니다. 일반적으로, GitHub 리포지토리나 git 리포지토리에서 가져온 코드나 빌드된 도커 이미지를 프로덕션 서버에 배포하기 위해 레지스트리나 리포지토리에 저장합니다. 이를 통해 배포 프로세스가 진행됩니다.
+
+## 배포
+
+배포는 모든 개발과정의 최종 단계이기 때문에, 프로덕션 환경에 코드를 적용하는 과정입니다. 이 단계에서 비즈니스에서는 여러분과 소프트웨어 엔지니어링 팀이 지금까지 이 제품에 투자한 모든 시간과 노력의 가치를 실현할 수 있습니다.
+
+## 운영
+
+한 번 배포가 완료되면, 해당 제품이 운영되기 시작하게 됩니다. 운영에는 고객이 사이트나 애플리케이션을 사용할 때 발생하는 문제를 파악하고, 이에 대한 대처 방안을 마련하는 것이 포함됩니다. 예를 들어, 사이트가 느리게 실행되는 문제가 발생하면, 운영팀은 이유를 파악하고 피크 기간 동안은 서버 수를 늘리고, 사용량이 적은 기간에는 서버 수를 줄이는 자동 확장 기능을 구축할 수 있습니다. 또한, 운영 유형 메트릭 처리와 같은 다양한 작업도 수행됩니다. 가능한 경우에는 이러한 작업을 자동화하는 것이 좋습니다. 그러나, 몇 가지 단계를 수행해야 하는 환경에서는 자동화가 어려울 수도 있습니다. 그런 경우에는 가능한 한 자동화를 시도하면서도, 일부 작업을 수동으로 처리해야 할 수도 있습니다. 그리고, 자동화 프로세스에서는 운영팀이 배포가 발생했음을 알 수 있도록 몇 가지 유형의 알림을 포함하는 것이 좋습니다.
+
+## 모니터링
+
+위의 모든 부분이 마지막 단계로 이어지는데, 특히 운영 문제 자동 확장 문제 해결과 관련된 모니터링이 필요하기 때문입니다.
+문제가 있다는 것을 알려주는 모니터링이 없다면 문제가 있는 것이므로 메모리 사용률 CPU 사용률 디스크 공간, API 엔드포인트, 응답 시간, 엔드포인트가 얼마나 빨리 응답하는지 등을 모니터링할 수 있으며, 이 중 큰 부분은 로그입니다. 개발자는 로그를 통해 프로덕션 시스템에 액세스하지 않고도 무슨 일이 일어나고 있는지 확인할 수 있습니다.
+
+## 다듬기 & 반복
+
+여태까지 수행한 프로세스를 검토하고 개선할 부분을 찾습니다. 그리고 이를 바탕으로 다시 계획 단계로 돌아가 전체 과정을 재진행합니다. 이는 지속적인 개선과 반복적인 프로세스 개선을 위한 사이클을 형성하며, 더 나은 제품과 높은 품질의 서비스를 제공하기 위한 필수적인 단계입니다.
+
+## Continuous
+
+여러 도구들이 지속적인 프로세스를 달성하는 데 도움을 줍니다. 이 모든 코드와 클라우드 인프라 또는 모든 환경을 완전히 자동화하는 것이 궁극적인 목표이며, 이를 지속적 통합/지속적 배포/지속적 배포 또는 줄여서 "CI/CD"로 설명하기도 합니다. 이번에는 90일 후에 CI/CD에 대한 기본 사항을 예제와 함께 배울 수 있는 워크숍을 제공할 예정입니다.
+
+### Continuous Delivery
+
+Continuous Delivery = 계획 > 코드 작성 > 빌드 > 테스트
+
+### Continuous Integration
+
+이는 위에서 설명한 지속적 배포 단계와 릴리스 단계의 결과를 합친 것입니다. 이 단계는 성공과 실패 모두에 해당하며, 지속적 배포를 통해 피드백을 받거나 지속적 배포로 진행될 수 있습니다.
+
+Continuous Integration = 계획 > 코드 > 빌드 > 테스트 > 릴리즈
+
+### Continuous Deployment
+
+성공적인 CI 릴리스 후, CD 단계로 이동합니다.
+
+성공적인 CI 릴리즈 = Continuous Deployment = 배포 > 운영 > 모니터링
+
+위의 세 가지 개념은 데브옵스 라이프사이클의 각 단계를 간단히 정리한 것으로 볼 수 있습니다.
+
+이전에 다룬 Day 3 를 약간 요약했었지만, 이제는 더 이해하기 쉬워진 것 같습니다.
+
+### 자료
+
+- [DevOps for Developers – Software or DevOps Engineer?](https://www.youtube.com/watch?v=a0-uE3rOyeU)
+- [Techworld with Nana -DevOps Roadmap 2022 - How to become a DevOps Engineer? What is DevOps?](https://www.youtube.com/watch?v=9pZ2xmsSDdo&t=125s)
+- [How to become a DevOps Engineer in 2021 - DevOps Roadmap](https://www.youtube.com/watch?v=5pxbp6FyTfk)
+
+여기까지 왔다면 이 여정이 자신이 찾던 여정인지 아닌지를 판단할 수 있을 것입니다.
+
+[Day 6](day06.md)에서 봐요!

2022/ko/Days/day06.md

@@ -0,0 +1,75 @@
+---
+title: '#90DaysOfDevOps - DevOps - The real stories - Day 6'
+published: false
+description: 90DaysOfDevOps - DevOps - The real stories
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048855
+---
+
+## 데브옵스 - 실제 사례
+
+처음에는 넷플릭스나 포춘지 선정 500대 기업처럼 데브옵스를 실행하는 기업이 없었기 때문에 많은 사람들이 데브옵스를 쉽게 접하기 어려웠습니다. 그러나 현재는 많은 기업이 데브옵스를 도입하면서, 데브옵스가 점차 일상적인 개발 방법으로 자리 잡게 되었다고 생각합니다.
+
+뒤에 나올 예시를 통해 다양한 산업과 업종에서 DevOps를 적용하고 있으며, 이로 인해 비즈니스의 목표 달성에 큰 긍정적인 영향을 미치고 있다는 것을 알 수 있습니다.
+
+여기서 가장 중요한 이점은 데브옵스를 올바르게 수행하면, 비즈니스의 소프트웨어 개발 속도와 품질을 개선하는 데 큰 도움이 된다는 것입니다.
+
+저는 오늘 이 자리를 통해, 데브옵스를 성공적으로 도입한 기업들의 사례를 살펴보고 이와 관련된 몇 가지 리소스를 공유하고자 합니다. 이 자리는 여러분들이 함께 참여하여, 서로 도움을 주고받을 수 있는 좋은 기회가 될 것입니다. 여러분의 비즈니스에 데브옵스 문화를 도입하셨나요? 그렇다면, 성공적이었나요?
+
+앞서 언급한 넷플릭스는 매우 좋은 사례이며, 오늘날 우리가 일반적으로 볼 수 있는 것들과 비교하면 상당히 발전된 모델입니다. 그러나, 성공하고 있는 다른 대형 브랜드들에 대해서도 언급하고자 합니다.
+
+## Amazon
+
+2010년에 아마존은 물리적 서버 공간을 AWS(Amazon Web Services) 클라우드로 이전하여, 아주 작은 단위로 용량을 확장하거나 축소함으로써 리소스를 절약할 수 있게 되었습니다. 이를 통해 아마존은 리테일 지점을 운영하면서 뿐만 아니라, AWS 자체적으로도 높은 수익을 창출하게 되었다는 사실도 알려져 있습니다.
+
+아마존은 2011년에 (자료를 통해 확인할 수 있는 바와 같이) 지속적인 배포 프로세스를 채택하여, 개발자가 원할 때 필요한 서버에 코드를 배포할 수 있게 되었습니다. 이를 통해 아마존은 새로운 소프트웨어를 평균 11.6초 만에 프로덕션 서버에 배포할 수 있게 되었습니다!
+
+## Netflix
+
+넷플릭스를 사용하지 않는 사람이 있을까요? 그들은 고품질의 스트리밍 서비스를 제공하며, 개인적으로도 훌륭한 사용자 경험을 제공합니다.
+
+사용자 경험이 왜 그렇게 좋을까요? 글쎄요, 기억에 남는 결함 없이 서비스를 제공하려면 속도, 유연성, 품질에 대한 관심이 필요합니다.
+
+넷플릭스 개발자는 IT 운영에 의존하지 않고도 배포 가능한 웹 이미지로 코드를 자동으로 빌드할 수 있습니다. 이미지가 업데이트되면 맞춤형으로 구축된 웹 기반 플랫폼을 사용하여 넷플릭스 인프라에 통합됩니다.
+
+이미지 배포에 실패하면, 롤백 되어 이전 버전으로 트래픽이 다시 라우팅 되도록 지속적인 모니터링이 이루어집니다.
+
+Netflix 팀 내에서 수행해야 할 일과 수행하지 말아야 할 일에 대해 자세히 설명하는 훌륭한 강연이 뒤에 있습니다.
+
+## Etsy
+
+많은 회사에서는 배포가 느리고 고통스러워서 어려움을 겪는 경우가 많습니다. 이와 관련하여, 많은 팀이 사일로에 갇혀 협력하지 못하는 문제가 있습니다.
+
+Amazon과 Netflix에 관한 글을 읽으면서 알게 된 것 중 하나는, Etsy가 2009년 말에 이미 개발자가 코드를 배포할 수 있도록 해뒀을 가능성이 높다는 것입니다. 이는 다른 두 회사보다 훨씬 앞선 시기였습니다. (흥미로운 사실이죠!)
+
+더 흥미로운 점은, 개발자가 배포 책임감을 느낄 때 애플리케이션 성능, 가동 시간 및 기타 목표에 대한 책임감도 함께 갖게 된다는 것을 깨달았다는 것입니다.
+
+학습 문화는 데브옵스의 핵심적인 부분입니다. 실패를 통해 교훈을 얻는다면, 실패도 성공으로 이어질 수 있다는 내용은 인용된 것 같지만, 어느 정도 일리가 있는 것 같습니다!
+
+일부 대규모 기업에서는 데브옵스가 판도를 바꾼 다른 사례도 뒤에 추가했습니다.
+
+## 자료
+
+- [How Netflix Thinks of DevOps](https://www.youtube.com/watch?v=UTKIT6STSVM)
+- [16 Popular DevOps Use Cases & Real Life Applications [2021]](https://www.upgrad.com/blog/devops-use-cases-applications/)
+- [DevOps: The Amazon Story](https://www.youtube.com/watch?v=ZzLa0YEbGIY)
+- [How Etsy makes DevOps work](https://www.networkworld.com/article/2886672/how-etsy-makes-devops-work.html)
+- [Adopting DevOps @ Scale Lessons learned at Hertz, Kaiser Permanente and lBM](https://www.youtube.com/watch?v=gm18-gcgXRY)
+- [Interplanetary DevOps at NASA JPL](https://www.usenix.org/conference/lisa16/technical-sessions/presentation/isla)
+- [Target CIO explains how DevOps took root inside the retail giant](https://enterprisersproject.com/article/2017/1/target-cio-explains-how-devops-took-root-inside-retail-giant)
+
+### 데브옵스에 대해 살펴본 첫 며칠의 요약
+
+- 데브옵스는 전체 애플리케이션 개발 라이프사이클인 **개발**, **테스트**, **배포**, **운영**을 단일 팀이 관리할 수 있도록 하는 개발과 운영의 조합입니다.
+
+- 데브옵스의 주요 초점과 목표는 개발 라이프사이클을 단축하면서도 비즈니스 목표와 긴밀하게 연계하여 기능 및 수정 사항을 자주 제공하는 것입니다.
+
+- 데브옵스는 소프트웨어를 안정적이고 신속하게 배포하고 개발할 수 있는 소프트웨어 개발 접근 방식으로, 이를 **지속적인 개발, 테스트, 배포, 모니터링**이라고도 합니다.
+
+여기까지 왔다면 이 여정이 자신이 찾던 여정인지 아닌지를 판단할 수 있을 것입니다. [Day 7](day07.md)에 뵙겠습니다.
+
+Day 7 에서는 개발자가 되는 것이 목표가 아니라, 개발자들이 하는 일을 이해할 수 있도록 프로그래밍 언어에 대해 알아보게 됩니다.
+
+일주일 안에 모든 것을 배울 수는 없겠지만, 7일 또는 7시간 동안 무언가를 배운다면 처음 시작할 때보다 더 많은 것을 알게 될 것입니다.