DevOps
DevOps는 IT산업에서 자주 들을 수 있는 일종의유행어이다.- 상대적으로 새로운 개념일 뿐이지 엄청 새로운 개념은 아니다.
- 매년
DevOps의 인기는 늘어나고 있고 전세계적으로 성장을 기대하는 분야이다.
하지만 DevOps의 개념을 정확히 정의하기에는 너무 방대한 분야를 다루고 있어서 다른 IT 용어와 비교해서 우리가 이해하기 쉽도록 DevOps의 의미를 좁혀보자
DevOps는 기본적으로 개발과 운영의 합성어이지만 그 경계가 모호하다. 어디까지가 DevOps의 개발이고 어디까지가 DevOps의 운영일까? 그리고 DevOps의 존재 이유는 무엇일까
개발과 운영
개발과 운영은 어플리케이션의 가장 큰 두 가지 영역이라고 볼 수 있다.
결국 어플리케이션의 목적은 end user에게 요구사항에 맞게 개발된 어플리케이션을 서비스하는 것이라고 볼 수 있다.
그 과정에 있어서 폭포수 모형을 사용하든지 애자일 개발 모형을 사용하든지는 중요하지 않다. 결국 애플리케이션을 잘 개발해서 end user에게 공급만 잘 해주면 되는 것이다.
위에서 언급한 과정을 조금 디테일하게 살펴보자면 아래와 같다.
처음 생각한 아이디어에 맞게 요구사항을 설정하고 이를 바탕으로 개발 코드를 완성한다.
그리고 이를 테스트해보고 빌드패키지과정을 거쳐서 이를 배포할 서버를 구성한다거나 보안 방화벽같은 것들을 구성하고
최종적으로 enduser에게 배포하면 되는 것이다.
배포만 하면 끝일까? 아니다
더 나아가서 어플리케이션에 문제가 발생할 수 있고 사용자에게 불편사항을 피드백 받을 수도 있고 이용자가 많아지면 서버를 증축해야하는 상황도 있을 수 있다. 물론 보안 취약점이 발생할 수도 있는 것이다.
이렇게 어플리케이션 배포 이후에도 다양한 상황들을 모니터링하고 관리해주어야 한다.
이런 일련의 과정속에서 어플리케이션은 많은 새로운 버전들이 생겨난다. 이런 버전들을 오류없이 관리하고 빠르게 업그레이드 또는 다운그레이드 해주는 것이 고객만족으로 이어질 확률이 크다.
바로 이 점이 DevOps의 최종 목표이다. 고객만족을 위해서 앞서 언급한 모든 과정들을 더욱 빠르게 해주고 오류는 줄여주는 것이다. 일련의 과정들을 코드화하여 자동화하면 사람이 하는 실수를 줄여주고 속도는 더욱 향상시킬 수 있다.
DevOps의 해결과제
데브옵스의 주 해결과제들 중에서 한 가지는 개발자와 운영 엔지니어사이의 Miscommunications를 줄여주는 것에 있다. 개발자가 운영상황을 이해하지 못한 상황에서 어플리케이션을 개발했을 경우 이를 배포하기 전에 운영 엔지니어가 어플리케이션을 확인하고 반려시키는 경우가 많기 때문이다. 이는 결국 업데이트를 지연시키는 원인이 된다.
또 한 가지는 서로의 이해관계 충돌이다. 개발자는 새롭고 다양한 기능을 많이 개발해서 어플리케이션에 공급하는 것으로 인센티브를 받지만 운영 엔지니어는 안정적이고 에러가 없는 운영을 유지할 경우 인센티브를 받는다. 때문에 서로의 이해관계가 충돌하는 문제가 발생한다.
세 번째는 Security이다. 개발자는 보안의 취약성을 없애기 위해서 새로운 보안 기능들을 추가하려고 한다. 이 또한 운영 엔지니어 입장에서는 변화로 받아들이기 때문에 해당 변화가 운영의 안정성을 저해할 수 있다고 판단할 수 있다.
또 한 Testers와의 문제도 발생한다. 개발된 어플리케이션이 잘 작동하는지 뿐만 아니라 다양한 환경에서 문제는 없는지 소비자의 만족도는 개선되는지 등 다양한 테스트과정은 새로운 기능 추가를 저해하는 요소가 될 수 있다.
마지막으로 Manual Work이 있다. 프로비저닝, 프로그램 버전관리, 배포, 인프라관리 등등 운영을 위한 수많은 수작업이 필요하다. 이 또한 DevOps가 해결해야하는 중요한 과제 중에 하나이다.
이렇듯 DevOps는 전방위적으로 관여하는 직무이다. 이렇게 보면 DevOps의 업무가 엄청 많다라고 생각할 수도 있겠으니 결국 DevOps가 중점적으로 해결해야하는 과제들을 요약해서 살펴보자
아래 그림과 같이 모든 과정들이 잘 흘러가도록 그리고 그 진행을 자동화하는 것이 DevOps가 나아갈 방향이라고 생각하면 조금 더 쉽게 다가올 것이다.
DevOps는 어떻게 목적을 달성하는가
지금까지 알아본 바로 DevOps는 단 한가지 단어로 정의할 수 없다는 것을 알게 되었을 것이다. DevOps는 이런 일련의 방향성을 의미하기도 하고 DevOps를 성공시킨 사례들을 의미하기도 하고 DevOps를 가능하게 하는 도구들을 의미하기도 한다. 때문에 DevOps의 단어에 너무 초점을 두지 말고 어떻게하면 빠르고 안정적으로 배포를 할 수 있을지 그리고 어떻게하면 더욱 운영과 개발이 긴밀하게 협업할 수 있을지를 고민해본다면 궁극적으로 DevOps의 목적을 달성하는데에 한 걸음 다가설 수 있을 것이다.
DevOps의 업무
지금까지 알아본 내용으로도 아직 모호한 점들이 많을 수 있다. 때문에 이번에는 DevOps의 업무관점에서 알아보도록 하자.
아래 그림이 DevOps가 받는 주요 업무들이다.
너무 많은가? 하지만 걱정할 필요 없다. DevOps의 직무 영역은 위 그림이 맞지만 회사마다 팀마다 본인이 다뤄야할 영역은 그 중에 몇몇으로 특정하게 될 것이다.
누군가는 개발자로서의 DevOps 누군가는 운영 엔지니어로서의 DevOps 또는 정말 DevOps만을 전문적으로 다루는 사람이 있을 것이다. 실질적으로 DevOps가 어떤 업무를 하는지는 각 회사의 Needs에 따라 다르므로 사람인 또는 잡코리아 링크드인 같은 구인구직 사이트를 직접 들어가보고 어떤 업무를 하는지 디테일하게 살펴보는 것 또한 DevOps를 이해하는데 도움이 될 것이다.
DevOps 엔지니어가 되기 위한 길
DevOps 엔지니어가 되기 위해서는 무슨 도구를 사용하는지, 업무와 책임은 어떤 것이 있는지, 마지막으로 DevOps엔지니어는 개발과 운영중에 어떤 바운더리를 가지고 있는지 알아야한다.
개발 업무에 있어서 DevOps는 기본적으로 Code Repository를 중심으로 다루게 되고 이에 대하여 개발업무는 어떻게 진행되는지, Git Workflow는 어떤지, 어플리케이션은 어떻게 구성되어있는지, Test는 어떻게 자동화되었는지를 파악할 필요가 있다.
운영업무에 있어서는 다음과 같다. 서버는 기본적으로 리눅스를 기반으로 운영하기 때문에 리눅스를 다룰줄 알아야하고, 그와 동반하여 CLI에 익숙하면 좋고 Shell Commands도 많이 사용한다. 그리고 리눅스만의 File System을 이해한 상태로 서버 관리를 할 줄 알아야한다. 추가적으로 SSH 키 관리 또한 리눅스를 사용한다면 빼놓을 수 없는 요소이다.
네트워크 또한 빼놓을 수 없다. 보안을 위한 Firewall이나 Proxy Servers 그리고 대규모 네트워크 트래픽을 다루기 위한 Load Balancers 웹보안을 위한 HTTP/HTTPS 마지막으로 고객이 접속하는 IP와 DNS 또한 네트워크의 중요한 요소이고 DevOps엔지니어는 이러한 부분들까지 관여하게된다.
다만, 이러한 영역들에는 전문가들이 존재하기 마련이다. 시스템, 네트워크, 보안을 전문적으로 다루는 사람들이 있기 때문에 DevOps엔지니어는 해당 내용들을 다룰 줄 아는 것이지 깊이있게 모든 내용을 파악하는 것까지는 전문가에게 맡기도록 하자.
다음 내용은 컨테이너이다. 컨테이너는 소프트웨어 패키징 모델로서의 디팩토가 되는 중이다. 대부분의 소프트웨어를 컨테이너로 패키징하여 관리하고 사용하므로 DevOps엔지니어는 해당 내용 또한 숙지하고 사용할 줄 알아야한다. 그 중에서 Docker의 점유율이 가장 높으므로 Docker를 먼저 공부하는 것을 추천한다.
위 내용을 토대로 인프라를 구성하고 네트워크를 구성하고 개발에 대한 이해를 토대로 소프트웨어를 컨테이너화 해서 다루었다면 이 모든 내용을 종합하여 CI/CD를 유지해주는 것이 DevOps의 주요 방향성 중에 하나이다.
조금 더 구체적으로 CI/CD의 흐름을 짚어보자면 먼저, Code Repository에 개발된 코드들이 업로드되면 이를 run tests하여 잘 동작하는지 확인하고 해당 코드들을 Maven이나 Gradle을 사용하여 JAR파일 이나 WAR파일로 패키징한다. 그리고 해당 JAR나 WAR파일들 포함하여 Docker Image를 말고 Docker Hub같은 artifact repository에 업로드시킨다. 여기까지가 CI이고 이를 받아서 end user까지 서비스를 전송하는게 CD가 된다.
위의 모든 파이프라인을 자동화하여 새로운 기능이 추가되든 버그를 수정하든 Code Repository에 새로운 코드들이 올라오면 일련의 과정들을 계속해서 Deployment 까지 진행시키는 것이 DevOps 엔지니어가 달성하고자 하는 목표이다.
특히 Deployment과정에 있어서 cloud provider를 이용하게 된다. Infrastructure들이 모두 가상화 되어있기 때문에 확장 및 축소가 가능하고 IaC를 실현시켜 주기 때문에 매우 편리하다. cloud providers는 여러 개가 있지만 그 중에서 가장 점유율이 높은 AWS를 먼저 공부해보는 것을 추천한다. 그리고 AWS에는 많은 서비스들이 있지만 그 중에서 실질적으로 사용되는 몇몇 (VPC, 서브넷, 인스턴스, 로드밸런서, 오토스케일링, RDS 등등..)만 익혀놔도 나중에 사용하면서 천천히 확장해 나아가면 된다.
또한 앞서 언급했던 컨테이너를 보다 정교하고 안정적으로 관리하기 위해서는 K8s를 사용할 줄 알아야한다. K8s를 사용해서 컨테이너를 관리하게되면 대규모 트래픽에 대한 확장 및 축소가 매우 빠르고 컨테이너에 에러가 생겼을 경우 자동으로 해당 컨테이너를 지우고 새로운 컨테이너를 대체하는 등 수 많은 컨테이너를 관리하는 기술이다. 다만 K8s는 마치 Customizing 할 수 있는 운영체제라는 비유가 있을 정도로 복잡하고 디테일한 설정이 많다.
다음은 Monitoring이다. 위에서 컨테이너를 자동으로 유지 관리하도록 설정했지만 서비스가 작동하지 않거나 버벅거릴 경우 어느 지점에서 문제가 발생했는지 쉽게 파악할 수 있도록 도와준다. 리소스가 부족한지 네트워크가 문제인지 pod가 제대로 올라가있지 않은지를 쉽게 확인해야 오류에 빠르게 대응할 수 있고 이는 고객만족으로 이어질 수 있다.
IaC 업무도 있다. 한 마디로 인프라 전체 구성을 코드화 하여 관리한다는 것이다. 이는 cloud provider들이 사용 환경을 만들어주고 하시코프사의 Terraform이 해당 IaC 서비스를 주도적으로 개발하고있다. 인프라를 코드로 관리한다는건 시각적으로 관리하기 편하고 재해복구를 할 때에도 매우 빠르게 복구가 가능하게 한다. 또한 모든 인프라 정보가 몇 키로 바이트의 Code에 담겨있으니 매우 적은 용량으로 수 천개의 인프라를 관리할 수 있다. 다만 IaC를 해보면 알겠지만 초기에 IaC하는것이 시간이 많이 걸린다.
DevOps는 자동화를 많이 수행한다. 이를 가능케 하는 도구중에 하나가 이 Scripting Language이다. 반복적인 작업을 Script로 작성하여 명령어 하나만으로 주기적인 반복 또는 연속적인 반복을 가능하게 만들어준다. 요즘은 이 반복을 Python으로 주로 사용하니 Python언어를 공부해보는 것도 필요하다.
이렇듯 IaC나 Script를 작성하다보니 DevOps 엔지니어도 Code를 작성하게 된다. 때문에 자연스럽게 Git을 배워서 Version Control을 할 줄 알아야한다.
지금까지 DevOps가 사용하는 많은 역할과 많은 도구들을 봐왔다. 공부량이 너무 방대하다고 느낄 수 있다. 하지만 이 모든 역할을 수행할 줄 알아야 DevOps가 가능하다. 때문에 처음에는 각 분야별로 가장 많이 사용되는 기술 한 가지씩을 배우고 이것들을 사용해서 DevOps 파이프라인을 한 번 구성해보는 것을 목표로 공부해보자. 필자도 엔코아 플레이데이터에 클라우드 부트캠프를 시작으로 입문하게 되었다. 처음에는 강의나 부트캠프를 활용하는 것이 도움될 것이다.
DevOps, compared with SRE - Site Reliability Engineering
Reliability는 신뢰할 수 있음이라는 뜻이다. SRE 엔지니어도 모든 과정을 자동화하는 목표를 수행하고 있지만 그 최종 목적이 모든 과정의 신뢰성 즉 가용성을 높이는 방향에 그 목표를 두고 있다. 이에 반에 DevOps 엔지니어는 지금까지 살펴봤던 CI/CD과정을 빠르고 효과적으로 만들어서 end user가 추가된 서비스나 변경된 서비스를 빠르게 받아볼 수 있도록 자동화하는데에 그 목표가 있다. 만약 SRE에 대해서 더 자세하게 알아보고 싶다면 맨 아래 링크를 타고 들어가보자.
SRE는 무엇일까?
