오픈소스 가상화 플랫폼, Docker

 
오늘은 복잡하고 어려운 서버관리를 효율적으로 할 수 있도록 개발된 플랫폼 ‘Docker` 대하여 알아보고자 합니다.
Docker는 애플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼으로서 환경에 구애받지 않고 신속한 배포와 확장이 가능하다고 하는데요,
Docker 가 이 이상 어떠한 장점과 특징들을 가졌는지 아래 내용에서 소개해드리고자 합니다.
 

[그림 1] Docker

서버 관리는 어렵고 복잡합니다. 고급 개발자도 서버를 관리하기 위해서는 아기를 다루듯이 섬세한 기술이 필요합니다. 개발에 필요한 언어인 JAVA나 Python 그리고 대표적 DBMS인 오라클과 MySQL 등 서버에서 사용 중인 서비스들이 업데이트 등에 의해 버전이 바뀌게 되고 이에 따라 다양한 버전의 서비스를 서버에서 관리하게 됩니다. 이렇듯 시간이 지날수록 서버에 점점 필요한 서비스들이 많아지게 되고, 관리는 어려워집니다. 서버 관리자나 개발자들은 필요한 서비스를 효율적으로 관리할 필요성을 느끼게 되고 이런 사용자의 욕구를 충족시키기 위해 개발된 오픈소스가상화플랫폼이 'Docker’입니다.


 
2013년 3월 산타클라라에서 열린 Pycon Conference에서 Docker의 창립자, 최고 기술 책임자 (CTO) 및 최고 설계자이며 Docker 오픈 소스 이니셔티브의 창시자인 Solomon Hykes가 'The future of Linux Containers(리눅스 컨테이너의 미래)' 라는 세션을 발표하면서 처음 세상에 알려졌습니다. 'The future of Linux Containers(리눅스 컨테이너의 미래)'는 5분 남짓한 짧은 발표로 이루어졌고, Docker를 사용하여 'Hellow World'를 찍는 것을 보여주었습니다. 이후 Docker가 인기를 얻으면서 2013년 10월 Docker Inc를 설립하고 2014년 6월 Docker 1.0을 발표하였습니다. 2016년에 진행한 Docker 선호도 조사에서는 90%가 개발에 사용 중이며, 80%가 DevOps에 사용할 예정이고 58%가 운영환경에서 사용 중이라고 합니다.
 

Docker는 프로그램이나 라이브러리, 시스템 도구 등과 같은 소프트웨어를 컨테이너라는 표준화된 방식으로 패키징 합니다. 패키징 된 컨테이너는 Docker 위에서 동작하며 가상 머신이 서버 하드웨어를 가상화하는 방식과 비슷합니다. Docker는 각 서버에 설치되며 제공된 명령어를 사용하여 컨테이너를 구축, 시작 또는 중단할 수 있습니다.




Docker : Docker에서 사용하는 컨테이너는 코드와 종속성을 함께 패키지하는 앱 계층의 추상화입니다. 여러 컨테이너가 동일한 머신에서 실행될 수 있고 OS 커널을 다른 컨테이너와 공유할 수 있으며, 각각은 사용자 공간에서 격리된 프로세스로 실행됩니다. 컨테이너는 VM보다 공간을 덜 차지하며 (컨테이너 이미지는 일반적으로 수십 MB 크기) 더 많은 응용 프로그램을 처리할 수 있습니다.

[그림 3] Docker Container

Virtual Machine : 하나의 서버를 여러 서버로 바꾸는 물리적 하드웨어의 추상화입니다. 하이퍼 바이저를 사용하면 여러 VM을 단일 컴퓨터에서 실행할 수 있습니다. 각 VM에는 운영 체제, 응용 프로그램, 필요한 바이너리 및 라이브러리의 전체 사본이 포함되며 수십 GB를 차지합니다. VM의 부팅 속도가 느려질 수도 있습니다.

[그림 4] Virtual Machine




Docker는 소프트웨어 인터페이스를 하드웨어와 비슷하게 만들어주는 반가상화와는 다르게 경량화된 방식이며 Guest OS를 설치하지 않습니다. 그리고 Docker에서는 분리된 공간을 이용해 서버 운영을 위한 프로그램과 라이브러리를 쉽게 설치할 수 있습니다. Virtual Machine과는 다르게 Host의 자원을 직접 이용할 수 있으므로 메모리 접근이나 네트워크 속도, 파일시스템이 월등히 빠르게 동작합니다. 그렇기 때문에 Host와 Docker의 컨테이너 사이의 계층과 성능 차이는 크게 발생하지 않습니다.
정리하자면, 프로그램이나 라이브러리들을 쉽게 설치와 삭제를 할 수 있으며 성능도 뛰어나고, Docker 사용자들끼리는 구축해 놓은 환경을 간편하게 주고받을 수 있습니다. 이 같은 편리함 때문에 많은 사용자가 Docker를 사용하고 있고, Stack OverFlow에서 진행한 2019 Survey에서는 Docker가 가장 널리 사용하는 플랫폼 3위, 가장 좋아하는 플랫폼 2위를 차지하였습니다. 사람들이 많이 쓰고 좋아하는 플랫폼에는 이유가 있다고 생각합니다. 이 글이 Docker를 사용하기 위한 첫걸음을 내딛는 데 조금이라도 도움이 될 수 있었으면 좋겠습니다. 감사합니다.



 

Posted by 人Co

2020/05/20 11:20 2020/05/20 11:20
Response
No Trackback , No Comment
RSS :
https://www.insilicogen.com/blog/rss/response/345

DevOps 란?



최근 IT 업계에서 지속적인 소통을 통한 협업 문화가 중시되고 있는데요, 이를 위해 여러 가지 방법론 또한 등장하고 있습니다. 오늘은 이러한 소통과 협업 방식인 디봅스(DevOps)를 주제로 유용한 정보를 공유해드릴까 합니다.
 
 



[출처] DevOps
 
DevOps는 소프트웨어개발(Development) 그리고 운영(Operations)의 합성어로, 일반적 정의는 개발과 운영을 하나의 조직으로 합쳐서 팀을 운영하는 문화이자 방법론입니다.
 
[출처] Dev vs Ops

개발자들은 고객에게 검토를 요청한 변경 사항을 빨리 확인하길 원합니다. 반면 운영진은 안정성에 더 무게 중심을 두고 싶어 합니다. 일반적인 업무 프로세스상 이 둘 간의 타협은 쉽게 이뤄지지 않게 되고 시장과 고객에 대처하는 속도 또한 더딜 수밖에 없습니다. 하지만 DevOps는 이 둘의 공통 지표를 맞추고 지속적인 커뮤니케이션을 통해 차이를 줄이며 설계부터 배포까지 하나의 조직으로 협업하여 빠르게 변화하는 고객 중심의 시장에 맞춰 효율적으로 신속하게 대처할 수 있도록 하는 "문화" 라고 할 수 있겠습니다.
 




[출처] DevOpsCycle

1. 속도 : 배포까지의 작업 속도가 빨라져 고객을 위해 더 빠르게 혁신하고 시장 변화에 빠르게 대처하여 더 효율적인 비즈니스 성과를 창출할 수 있습니다
2. 신속한 제공 : 빌드에서 배포까지 소프트웨어 릴리스 프로세스를 자동화하여 새로운 기능의 배포와 이슈에 대한 대처 속도를 개선하여 고객에게 제공한 제품을 더 빠르게 혁신, 개선하여 시장 경쟁 우위를 차지할 수 있습니다.
3. 안전성 : 소프트웨어 업데이트와 변경 시의 품질 보장, 지속적인 통합과 전달을 통해 변경 사항이 안전하고 정확하게 작동하는지 테스트하고 모니터링과 로깅 방식을 통해 실시간으로 성능에 대한 정보를 얻을 수 있습니다.
4. 확장 : 자동화와 일관성이 지원되어 안전성을 보장하며 복잡한 시스템 또는 변화하는 시스템을 효율적으로 관리할 수 있습니다.
5. 협업 강화 : 개발부서와 운영부서의 긴밀한 협력을 통해 비효율성을 줄이고 시간을 절약할 수 있습니다.
6. 보안 : 자동화된 규정 준수 정책, 세분화된 제어 및 관리 기술을 사용하여 DevOps 모델을 도입할 수 있습니다.
 



1. Cross Functional Team : 팀 하나에서 개발부터 운영까지 전부 할 수 있는 인원으로 채우는 것이 아닌 각 프로세스의 담당자들을 하나씩 팀원으로 구성하는 뜻으로 서비스 기획부터 개발, 테스트, 운영 배포 등 모든 제품 개발 프로세스를 하나의 팀에서 할 수 있도록 해야 한다는 것입니다.
2. Widely Shared Metrics : 팀 구성원 전체가 기준으로 삼을 수 있는 서비스 제품에 대한 공통적인 지표를 통해 개발 후 잘 운영되고 있는지, 사용자의 반응은 어떤지 등 서비스 진행 상태를 인지할 수 있어야 한다는 것입니다.
3. Automating repetitive tasks : 반복적인 일들을 CI(Continuous Integration)/CD(Continuous Delivery) 를 이용하여 프로세스를 자동화해야 한다는 것입니다. 반복적 작업에 투입되는 시간을 줄여 작업의 효율을 높이고 빠른 서비스 업데이트가 가능하며 전체 시스템에 대한 이해도를 높일 수 있습니다.
4. Post Mortem : 서비스의 장애나 이슈가 있을 때, Fix 후 팀 전체가 공유하여 이러한 이슈들의 심각도를 판단하고 차후 같은 이슈에 대해 예방을 할 수 있습니다.
5. Regular Release : 서비스 릴리즈는 개발, 테스트 배포 과정을 거치게 되고 릴리즈가 끝난 후엔 다음 릴리즈를 위한 기능 정의 등의 과정을 거쳐야 하므로 불필요한 많은 시간이 소요될 수 있습니다. 정기적으로 릴리즈를 하게 되면 팀의 협업시점이 명확해지고 서비스의 기능을 빠르게 개선하여 고객의 VOC(Voice Of Customer)를 반영해 나갈 수 있다는 것입니다.





[출처] CI,CD,CD

1. Continuous Integration : 개발자들이 개별적으로 개발한 프로그램 소스 코드를 하나로 모아 빌드하는 통합 빌드의 과정을 특정 시점에 하는 것이 아니라 주기적으로 수행하여 통합에서 발생하는 충돌 등의 오류를 각기 다른 레벨의 자동화 테스트(단위 및 통합 테스트가 일반적)를 통해 변경 사항이 잘 통합되었는지 확인하고 이슈 발생 시 사전에 해결, 복잡성을 제거하자고 시간을 단축하기 위한 기법을 말합니다. Agile 방법론이 대두하면서 더욱 주목받게 되었고 빌드, 테스트 단계 등에서 걸리는 시간을 절약하여 빠른 시장에서의 경쟁력을 확보할 수 있습니다. CI 시스템을 구축하기 위한 핵심 구성요소는 Jenkins,Travis CI등의 CI Server,subversion,Git 등의 소스 코드 형상 관리 시스템(Source code Management), Maven, Gradle, Ant 등의 Buil Tool, 그리고 테스트 코드에 따라 자동으로 테스트를 수행해주는 JUnit, Mocha 등의 Test Tool이 있습니다.

2. Continuous Delivery : 프로그램에 적용된 사항들을 자동을 빌드, 단위 및 통합 테스트 진행에 이어서 하나의 리포지토리에 (예를 들면 Git)에 업로드되는 것을 말합니다. 이를 통하면 운영부서는 리포지토리의 프로그램을 실시간으로 프로덕션 환경에 배포가 가능할 것입니다. 이것이 효율적인 방법이 되려면 앞서 언급했던 CI의 자동화 프로세스가 제대로 구축하고 작동하여야 가능할 것입니다.
 

3. Continuous Deployment : Continuous Delivery와 개념이 유사하여 살짝 헷갈릴 수 있는 부분이지만 쉽게 말씀드리자면 Continuous Delivery는 프로덕션은 수동으로 배포하고 Continuous Deployment는 프로덕션까지 자동으로 배포하는 것입니다.
 



조직이 오래 지속하였거나 프로젝트 중간에는 이런 DevOps 방식의 "문화"를 도입하기는 쉽지 않을 것입니다. 경영자 또는 PM이 DevOps에 대해 이해가 없다면 도입하더라도 단기성, 일회성에 불과하리라 생각합니다. 이미 다른 방법론인 애자일 방법론을 도입하려 한 수많은 기업의 실패도 앞서 말씀드린 내용에 근거가 됩니다. 물론 실패한 사례만 있는 것은 아닙니다. DevOps는 아니지만 한 소셜커머스 업체에서는 애자일 방법론을 성공적으로 도입한 조직이 하나가 되어 문화를 바꾼 의미 있는 사례도 있습니다.
"한 사람의 꿈은 꿈이지만 만인의 꿈은 현실이 된다."는 말이 있습니다. 이러한 문화, 방법론 도입을 수동적으로 도입하는 것보다는 직급을 떠나 조직 전체가 이를 공감하고 이해하여 능동적으로 받아들이고 형성할 자세가 되어 있어야 한다고 생각합니다. 고객 중심으로 빠르게 변화하는 시장에 알맞게 대응하기 위해 Google, Facebook, Netflix 등 세계 유명 기업들도 개선된 개발 방법론들을 도입하여 시장에 발맞춰 나가고 있습니다. DevOps를 잘 적용했을 때 이전보다 배포주기 46배, 개선속도 440배, 복구시간 96배, 매출 20% 신장 등 좋은 효과를 얻고 있는 사례들이 있는 만큼 조직에 알맞게 DevOps, 또는 개선된 개발 방법론을 도입하여 업무의 효율성과 만족도 향상 그리고 빠르게 변화하고 있는 시장에서의 경쟁력을 가져보는 것은 어떨까요.


Posted by 人Co

2020/05/07 08:16 2020/05/07 08:16
Response
No Trackback , No Comment
RSS :
https://www.insilicogen.com/blog/rss/response/344