아마존 웹 서비스(AWS)로 시작하는 데브옵스-1

 

1. DevOps란 무엇인가?

 데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 또한 데브옵스는 소프트웨어 개발 조직과 운영 조직 간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

 

  개발자(Dev)는 고객의 요구사항을 빠르게 수용해서 서비스를 개발하고 적용하길 원하며, 운영자(Ops)는 제공될 서비스가 안정적으로 동작하기를 원한다. 서로 다른 목적과 개발툴의 차이로 인해 빈번히 충돌이 발생하게 된다. 데브옵스는 개발자와 운영자의 소통, 협업 및 통합을 강조하는 문화, 방법론, 프로세스, 도구 모두를 의미한다.

 

 

2. 애자일 방법론과 데브옵스의 유래

  애자일 개발방법론은 계획을 통해 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 끊임없이 프로토타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하며 하나의 커다란 소프트웨어를 개발해 나가는 Adaptive Style이라고 할 수 있다.

 

 

  애자일 소프트웨어 개발 원칙 12가지

1. 우리의 최우선 순위는 가치있는 소프트웨어를 일찍, 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. 2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라, 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다. 3. 작동하는 소프트웨어를 자주 전달하라. 2주에서 2개월 간격으로 하되, 더 짧은 기간을 선호하라. 4.  비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다. 5. 동기가 부여된 개인을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라. 6. 개발팀, 개발팀 배누에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 면대면 대화이다. 7. 작동하는 소프트웨어가 진척의 주된 척도이다. 8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다. 9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 민첩성을 높인다. 10. 단순성 즉, 안 하는 일의 양을 최대화하는 기술이 필수적이다. 11. 최고의 아키텍처, 요구사항, 설계는 스스로 조직된 팀에서 나온다. 12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

 애자일 방법론은 더 빨라진 소프트웨어 배포, 빌드로 인해 운영팀에게 많은 부하와 운영적인 문제점을 촉발하게 되었다. 그래서 개발과 운영의 전반적인 주기 자동화에 대한 필요성이 대두되었고, 데브옵스가 등장하게 된다.

 

 

3. Why? DevOps

 IT 조직에 대한 이상적인 상황 다음과 같다.

 

 첫 번째, 비즈니스 경쟁력 확보, 구성원의 유기적인 협력을 통해 조직의 공동 목표 달성 노력으로 높은 안정성 신뢰성, 보안성 가용성으로 기업 경쟁력을 강화한다.

 두 번째, 고객 Needs를 효과적으로 대응, 교차기능팀(Corss-Functional Teams)을 통해 적시적소에 고객의 Needs 파악이 가능하며, 다른 팀에 의존하지 않고 빠르게 업무관련 기술을 활용 가능하다.

 세 번째, 소규모 팀의 독립적 프로세스, 소규모의 팀이 코드를 신속하고 독립적으로 개발, 테스트, 배포할 수 있는 프로세스 구축 및 신뢰할 수 있는 가치를 제공한다.

 

  위 세 가지 결과는 모두 데브옵스를 통해 얻을 수 있는 결과이다. 하지만 일반적인 기업 IT 조직의 상황은 시스템 장애로 인해 비지니스에 막대한 피해를 초래할 수 있다. IT팀에서는 개발과 운영이 절재적으로 중요하고, 테스트 또는 정보보안 활동은 프로젝트 종료 시점이나 문제가 발생괴지 전까지는 중요하게 생각되지 않는다. 또한 대부분의 중요한 활동은 수작업과 이관 작업이 필요하며, 많은 시간이 소요되어 고객이 원하는 시점에 결과물을 전달하기 어렵게 된다. 결과적으로 조직은 목표 달성에서 멀어지게 되고, 기업은 부족한 성과로 인해 예산이 삭감되며, 이로 인해 프로세스에 대한 개선은 더욱 어려워지게 된다. 이를 해결하기 위한 방법은 무엇일까?

 

  일하는 방법을 바꾸는 것이다. IT조직 입장에서는 기술 제품과 서비스를 시장 상황에 맞추어 빠르고, 민첩하게 제공하는 것이 필요하다. 과거에 비해 개발하고 배포하는데 필요한 시간과 비용은 기술의 발전을 통해 지속적으로 감소되었다. 데브옵스의 도입과 하드웨어, 소프트웨어의 지속적인 발전으로 지금과 같은 클라우드 환경을 이용하면 단 몇시간에서 몇분만에 시스템을 배포할 수 있다. 이를 통해 조직은 실험을 통해 비즈니스 아이디어를 손쉽게 구현하고 테스트하며 고객의 Needs에 신속하게 대응할 수 있게 되었다. 오늘날 매일 수십 번 배포할 수 없는 조직은 경쟁자들에게 패배할 운명에 처해 있다.

 

 데브옵스의 목표는 작은 규모의 개발자로 구성된 팀에서 IT 서비스의 기능을 독립적으로 구현하고, 운영 환경과 동일한 환경에서 실제와 같은 테스트를 수행하며, 코드를 운영 환경에 빠르게 배포하는 환경을 구성하는 것이다.

 

 

4. DevOps를 위한 필요 구성 요소

  DevOps는 단순한 도구가 아니며, 도구 이상의 역할을 수행한다. DevOps의 핵심 사항은 협업과 목표 공유의 문화이다. 문제에 대한 지적이나 손가락질을 없애고, 팀워크를 증진하고 장려하는 동시에 모든 사람이 동일한 목표를 달성하기 위해 함께 일하며 노력하여 신뢰할 수 있는 소프트웨어를 빠르고 신속하게 개발하고 구축하는 것이 가능하다. 이러한 목표를 달성하기 위해 대부분의 조직에서 가장 많이 고민하는 것이 바로 DevOps 문화를 구축하는 방법이다. 문화(Culture)는 성공적인 DevOps를 수행하는 데 필요한 중요한 밑바탕이며, 이것을 지원하는 기술적 요소인 도구(tool)와 기술(Technology)이 DevOps를 가능하게 한다.

  DevOps를 도입하면서 흔하게 겪게되는 실수 중 하나가 조직과 문화의 변화 없이, 단지 툴만 도입하여 반쪽짜리 DevOps프로젝트가 되면서 실제 투입 비용에 비해 많은 효과를 보지 못하는 경우가 발생한다.

 

 DevOps를 위한 문화적 구성요소

 

1. 배려와 존중의 환경 구성하기. 개발자는 운영자를 존중하고, 운영자는 개발자를존중하여, 개발자와 운영자 간의 배려와 존중하는 환경이 필요하다. 또한 개발자와 운영자가 서로의 일을 떠넘기지 않으며, 이슈가 발생하였을 때 단답형으로 'No'라고 하지 않고, 문제 해결을 위해 서로 두움을 주고받는 것이 매우 중요하다.

 

2. 자유로운 토론 환경 조성하기. 문제로부터 숨지 않으며, 오픈된 마인드로 커뮤니케이션을 수행하고, 개발자와 운영자 간 자유로운 토론과 대화를 장려하며, 진해오디고 있는 일이나 향후 계획을 서로 공유하는 것이 중요하다. 그리고 운영팀은 개발팀에 시스템 접근 권한을 부여하여, 필요 사항에 대해 협업하는 분위기를 조성하는 것이 중요하다.

 

3. 남 탓하지 않기. 대부분 문제가 발생하면 '나만 아니면 괜찮아~'라는 식으로 다른팀의 문제로 치부하고 서로 헐뜯는 일이 빈번하다. DevOps 문화를 위해 서로 헐뜯거나 남의 탓을 하지 않아야 하며, 운영 중 문제 발생 시 개발팀과 운영팀 간 책임이 공유되어 서로 비난하지 않고 협력하며 문제를 빠르게 해결 할 수 있도록 한다.

 

4. 완료되었다고 해서 책임을 회피하지 않기. 개발팀은 프로그램을 배포하였다 하다고, 책임이 끝나지 않아야 하며, 개발팀과 운영팀은 서로 개발과 운영에 참여하여 상호 업무에 대한 이해와 협력이 필요하다. 

 

 이러한 성공적인 DevOps를 위한 문화적 변화는 단숨에 이루어내기 어렵다. 문화적 변화를 위해서는 조직적인 변화의 노력과 Bottom Up으로부터 변화를 만들며, 공통된 목표를 달성하기 위한 개발팀과 운영팀이 신뢰를 기반으로 협력 관계를 만들어가는 것을 통해 DevOps를 위한 문화적 변화를 이어갈 수 있어야 한다. 

 

 DevOps를 위한 기술적 구성 요소

 

 1. 코드 기반 인프라(Infrastructure as Code) 관리이다. '프로그래밍형 인프라'라고도 하는 Infrastructure as Code는 인프라 구성을 소프트웨어를 프로그래밍하듯이 처리하는 방식이다. 결과적으로 애플리케이션의 실행 환경을 코드 기반으로 구현 관리하는 것이다.

 

2. 버전 관리이다. 개발 시간이 지남에 따라 발생되는 소스코드의 변경사항을 개발팀이 관리하는 데 도움을 주는 소프트웨어 도구로, 버전 제어 소프트웨어는 특별한 종류의 데이터베이스에 소스코드의 모든 수정 사항을 저장하고 추적한다. 대부분의 개발팀에서 소스코드는 문제 해결을 위한 지식과 이해의 저장소로, 개발자들의 노력을 통해 수집되고 정제된다. 모든 개발 프로젝트에서 소스코드는 보호되어야 하는 귀중한 자산이며, 사람의 실수와 의도하지 않은 결과로부터 보호하는 역할을 한다.

 

3. One-Step 빌드와 배포(Build & Deploy)이다. 빌드작업은 개발팀이 개발한 소스를 GIT에 통합하고, 통합된 소스를 컴파일/테스트/정적분석 등을 실시해 실제 동작 가능한 S/W로 변환하는 작업을 한다. 배포 작업은 빌드된 파일을 개발 혹은 운영서버에 등록하여, 개발된 사항들이 반영되는 과정을 말한다. 배포 과정에서 작은 식수는 곧 서비스 장애로 연결된다. 그런 위험성을 최소화하기 위해 안정적인 배포툴이 필요하다. 자동화된 배포툴을 통해 조금씩 자주 변경되는 내용을 배포함으로써 위험을 분산시킬 수 있다. 이런 빌드와 배포 도구는 자동화를 통해 지속적으로 수행 가능한 시스템으로 구성되며, 이런 자동화 도구는 DevOps의 기술적 구성 요소의 핵심이다.

  이런 DevOps의 자동화 서비스를 CI/CD(Continuous Integration/Continuous Delivery)라 말하며, 다양한 CI/CD 툴을 통해 보다 효과적인 DevOps를 통한 자동화 환경을 지원한다.

 

4. 장애 발생 시 인프라의 빠른 배포이다. 문제가 발생하면 문제가 된 인프라를 재구성하기위해 OS 설치 및 솔루션 설치와 환경 구성까지 많은 시간과 노력이 필요하다. 하지만 DevOPs 기반의 인프라 환경은 문제 발생 시 기존 인프라를 빠르게 재배포가 가능한 환경으로 제공한다. Image기반의 인프라를 활용하여 Infra에 문제 발생 시, 기존 인프라를 수정하지 않고 손쉽게 재패보할 수 있으며, 환경 관리도구(Configuration Management Tool)를 이용하여, 쉽고 빠르게 신규 환경을 구성할 수 있다.

 

 

5. 클라우드와 DevOps

 클라우드 없는 데브옵스도 데브옵스 없는 클라우드도 가능하지만, 함께일 때 훨씬 많은 것을 얻을 수 있다. 데브옵스에는 클라우드가 필요하고, 클라우드에는 데브옵스가 필요하다. 그 이유는 데브옵스가 제공하는 것은 요청하는 즉시 애플리케이션을 구축할 수 있는 역량이기 때문이다. 이 역량을 제대로 구현해도 클라우드처럼 애플리케이션을 바로 배치할 수 있는 민첩한 플랫폼이 없으면 아무런 가치가 없다. 마찬가지로 클라우드 역시 빠르고 민첩한 애플리케이션 개발을 만나야 진가를 발휘한다.