개발 관련 글 보다보면 답은 docker 다라는 글을 많이 보는데
솔직히 저는 거의 써본적이 없네요 대략 개념은 알고
한때 공부도 했지만 도커로 시작해서 쿠버네틱스
fabric 아키텍쳐 막 끝이없더라구요
이제 무시하기에는 뭔가 트렌드에 뒤쳐지는것 같고
실무에서 많이 쓰는지 궁금하군요
잠시 운용해볼까 했는데 Docker 로 말아서
무슨 고래 아이콘 모양 프로그램 깔고
온라인으로 작동하는 느낌이라
그냥 거기까지 해본것 같습니다.
솔직히 그런 필요성이 없는 회사에서 혼자서 삽질하기에는 한계가 있었어요
MSA 에 필수라고는 하는데 실무에서는 대중적인지 궁금하네요
업계마다 상황이 다르다고 봐야 할 것 같습니다. 일단 클라우드 컴퓨팅 사용빈도가 높은 곳에서는 기본기처럼 많이 사용될겁니다.
여러 확장된 개념들이 많이 언급되지만, 도커, 아니 컨테이너 기술에서 가장 핵심은 이겁니다.
소프트웨어 개발, 특히 클래스 설계에서 SOLID 원칙 이야기와 불변성 이야기를 많이 하는데, 컨테이너에서도 크게 다르지 않습니다. 한 컨테이너는 그 자체로 "한 가지 역할"만 수행하는 “불변하는” 분리된 OS 인스턴스로서 (컨테이너가 가상화 기술을 쓰건 쓰지 않건 이건 부차적인 문제입니다), 이런 OS 인스턴스를 한 컴퓨터 안에서 여러 개로, 더 나아가서는 이런 컨테이너들을 호스팅하는 서버들을 동시에 지휘 (오케스트레이션)한다는 개념을 쓰는 것이지요.
대조를 위해 VM을 이야기하면, VM도 격리라는 면에서는 비슷한 점이 있긴 하지만, VM은 상태 불변적이지 않으며, 당연히 기존의 서버 컴퓨터처럼 동시에 여러 역할을 수행할 것을 기대할 수 있어서 구성이 복잡하고 물리 서버에 준하는 복잡성을 가집니다.
이상적인 것처럼 보이지만, 관리 코스트가 많이 늘어난다는 문제도 동시에 공존합니다. 그래서 수많은 데브옵스 모니터링 툴들이 범람하는 것이기도 하고, 로그 수집을 많이 해서 이걸 가지고 AI 분석을 돌리겠다는 이야기가 나오는 것입니다.
만약 관리 코스트를 많이 들일 여력이 되지 않는다면, 굳이 컨테이너 기반 워크로드를 고집할 이유는 없습니다. 그러나 앞서 말씀드린 특성을 활용해서 "노가다"를 면할 수 있는 면도 있기 때문에, 적절한 규모의 컨테이너화는 개발 자동화에 어느 정도 도움이 되니 검토해보셔도 좋을 듯 합니다. ㅎㅎ
앞으로 분산처리와 모니터링 으로 업무 도메인 옮겨볼까 하고
요즘 고민이 많아서요 ㅎ java 진영에 관제 라는 개념의
요즘 자극을 많이 받았어요
도커를 짧게 2년 써보고, MSA(Micro Service Architecture)를 따라해보려고 시도만 했던 사람으로서 컨테이너 기술은 필수입니다.
위에서 @rkttu 님께서 언급하신대로 코딩과 비슷하게 컨테이너가 한 가지 역할만 수행하도록 하게 만듭니다. 개발로 치면 캡슐화 & 추상화 정도로 볼 수 있을 것 같습니다.
일반 온프레미스 서버 1대와 DB를 이용한 기존의 방식과 차이점(stateful)이 있을 것은, 격리가 되고, Scale-Out이 가능하도록 만들어야 하기 때문에 Stateless 하게 개발해야만 합니다.
예를 들어 static 변수가 데이터를 들고 있어서 다음에 어떤 요청이 왔을 때 그 변수에 의존해서 처리하고 뭐 그런 흐름에 의존적인 개발을 해서는 안된다는 것입니다.
개발에서도 추상화가 어렵고 감 잡기 어렵듯 stateless 하게 개발하는 것이 가장 어려웠습니다.
그래서 제가 대안으로 사용했던 것은 온프레미스로 Docker를 사용하는 것이 아니라 아래처럼 Cloud에 내장된 Stateless 를 이용하는 것이었습니다.
Docker를 짧게 맛이라도 보고 싶으시다면 Docker로 Redis를 설치하셔서 써보시는 것도 추천드립니다.
도커 이외에도 컨테이너 격리 기술이 여러개 있겠지만 도커는 가장 대중적인 컨테이너 기술입니다.
MSA, 도커, 오케스트레이션의 다른 말은 관리비용 증가라고 합니다.
아무래도 국내의 공공 거대 시스템은 자바 기술로 구현되어 있을 테니, 그쪽에서 많이 언급되는 모양입니다.
도입할 가치가 있다고 합니다.
그렇지 않은 경우, (파느님도) 모노리스 프로젝트를 전통적인 배포 방식으로 배포하라고 권고하더군요.
실제로 저도 도커로 배포하고 서비스하려고 했는데, 도커 호스팅 서비스를 발견하기 어렵더군요.
이는 서버를 빌려서 도커를 위한 기반 인프라를 직접 설치한 후에 앱을 도커로 빌드한 후에 배포하는 구조로 만들어야 함을 의미합니다.
앱과 상관없는 도커라는 관리 포인트가 생긴 것이죠.
데이터 베이스는 Supabase에서 서비스로 제공하기 때문에, 도커는 오로지 앱만을 위한 것이었고, 단일 도커이기 때문에 오케스트레이션은 아직 도입하지도 않았습니다.
문제는 도커의 실패를 관리할 능력이 안된다는 것이었죠.
대여 받은 시스템에서 도커 자체가 이상 동작을 할 경우, 그것을 해결하는 것은 일단 신의 영역인 걸로.
그래서 도커 아웃!!. => 속이 후련함.
참고로, CI/CD도 도입했었는데요.
문제는 배포 서버 고유의 문제로 빌드하는 과정에서 에러가 발생하는 경우가 종종 있더군요.
그래서, 깃허브에 푸시하고, 배포 서버의 빌드 메시지를 꼬박 꼬박 지켜봐야 했습니다.
아니 이럴거면… 그냥 로컬 빌드하고, 빌드 파일을 서버에 올리는 것과 뭐가 다르지?
심지어, 로컬 빌드는 빌드 도구의 문제로 빌드 실패를 만나기란 매우 힘들지 않습니까?
그래서, CI/CD 도 아웃!!
그냥, 로컬에서 빌드하고, 서버에 파일 업로드하는… 스윗홈으로 되돌아 왔습니다.
집나가서 고생할 썰입니다.
저도 실무에 도입할때 비슷한 경험과 좌절을 한것 같습니다.
이게 혼자서 해결할려니 만만치 않고
주변에서 괜한짓으로 일만 만든다는 시각도 힘들고
아무래도 대형화 전문화 안된 개발조직에서는 이런 체계 데브옵스
도입부터 팀원들의 이해부터 힘든것 같아요
결론은 그냥 독재 해야 한다는 생각이긴 한데
Java 진영이 부러운것이 이런 eco 시스템의 대한 공감과 필요성에 대해서
군말없이 한다는 점이긴 합니다.
도커의 경우는 MSA 에서는 당연히 필수적이고
모놀리스 환경에서도 충분히 필요합니다.
개발환경과 배포환경의 차이 때문에 그것을 편하게 해결하기 위한것이 도커이고
환경만 잘 구축해놓는다면 이후에는 그냥 사용만 하면 되기 때문에 편합니다.
닷넷쪽에서 도커랑 친하지 않았던 이유는 닷넷이 리눅스와 친해진지 오래되지 않았기 때문인 것 같습니다.
대형 플랫폼 회사들이 등장하면서 하나의 솔루션, 하나의 서비스, 또는 결합된 서비스가 하나의 엔드포인트를 갖고 있거나… 이런 상황이 클라우드가 등장하면서 부터 폭발적으로 증가해서 문화가 그렇게 된 것이라고 생각합니다.
요컨대 개발인력이 충분하지 않을 때는 이런 자동화기술들은 필요가 없습니다. 커리어를 쌓고 싶고 공부 목적으로 할 수는 있지만 이런 파이프라인을 만들어갈때 장점은 분업과 전문화 영역이 가능해진다는 건데, 내가 혼자 전문화를 다하고 있으면 내가 짱짱맨이 되는것이지요. 개발자 자체가 스파게티 코드 객체가 되는 거라고 볼 수 있을 것 같습니다.
저는 개인적으로 전문 DBA와 일해본 경험을 가지게 되면서 ORM에 대한 고정관념을 상당히 깨게 되었는데요.
DBA를 만나기 전까지는 보통 영세한 기업에서 개발자가 그냥 코드를 칠줄알고 검색을 할줄 안다는 이유만으로 DB까지 몽땅시키기 때문인데, 그러다가 개발자가 DBMS도 만지고 IDE도 만지면서 관리포인트가 2개로 나뉘는 데다 Stored Processor는 버전관리도 안되어서 혼자하기엔 벅차다는 그런게 있어서 ORM을 무조건 써야한다는 주의였지만, DBA가 따로 있는 환경에 가서는 ORM은 생각도 할 필요가 없이 우수한 DBA 분께서 만들어주신 SP를 열심히 호출해서 업무를 빠르게 끝낼 수 있었습니다.
사실 이렇게하면 DB가 WAS서버가 된다고 경계하시는 분들도 많지만, DB도 우리가 개발자라서 잘 모를 수 있는데 DB도 JSON도 파싱이나 리턴이 가능하고 HTTP 호출도 할 수 있게끔 일반 서버처럼 많은 업데이트를 거쳐왔습니다.
따라서 뭐가 좋기만하고, 아키텍쳐상으로 어떻고 간에 저는 현재 상황에서 전문가가 제시하는 방향이 좋다고 생각하며, MSA나 Docker같은 걸 실무로 도입하기 위해서는 그만한 충분한 인력이 있어야한다고 생각합니다.
일반화 할 수는 당연히 없겠지만 제가 많이 봐온 부류로서, 매번 혼자는 일하는 개발자는 자신만의 고유한 소스코드 스타일로 OOP를 거의 지키지 않으며 코드 파일 하나에 자기만 알아보기 편하게 개발하는 것과 같은 이유입니다.
사실 OOP 적으로서, 일반적인 개발 지식으로서 대중화되지 않겠지만 적어도 일을 처리함에 있어서는 자신의 고유한 방식으로 빠르게 처리하는 유지보수가 좋을 수도 있습니다.
대신 우물 안에 갇히거나 그런건 다른 문제인 것 같습니다.
따라서 커리어때문에 Docker를 공부하신다면 해보시는 게 좋고 실무에 도입하신다고 하시면 경력자를 채용하셔서 좋은 가이드던, 좋지 않은 가이드던 함께 연구할 수 있는 머리(관리자)가 따로 있는게 좋다고 생각합니다.
이것이 바로 데브옵스 엔지니어 카테고리가 부각된 이유이죵. ㅇㅅㅇ/
개발자가 해야할 일에 비해 이 영역은 잔손질과 관리 비용이 너무 크죵. 알아야할 것도 엄청 많구욤.
(게다가 헤딩하기 시작하면 끝도 없…)
그래서 데브옵스 엔지니어가 있어야 개발자들의 개발 효율이 올라갑니닷.
글구, 저희 회사에 데브옵스 엔지니어가 따로 있어서
개발자들은 CI/CD 부터 컨테이너 관리, 환경 구성과 설정 등등의 것들은 거의 신경 쓰지 않고 기능 개발에만 집중할 수 있슴다.
필요한 게 있으면 언제나
… 해줘…
하면 해줍니다… >ㅁ</
물론 업무 영역이긴 하지만 그래도 해줘... 할 땐 커피 한 잔씩 바치면서 하고 있죵 ㅋㅅㅋ
덕분에 저는 이제 docker 파일을 보면 거의 까막눈 수준이 되었…
잘 아시겠지만, observability는 자바만 해당되는 기술이 아닙니다. asp.net core에도 관련 기능이 충분히 보강되었고, 헬스체크, 로그 수집이나 관제에 필요한 최신 기능이 모두 잘 갖추어져 있습니다. ㅎㅎ
덧. 이 계정은 일반 사용자로 포럼 서비스 테스트가 필요해서 만든 계정입니다. 
헬스 체크나 로그수집 APP Metics 등으로 관제 수집 등등 다 갖춰줬긴 했는데
그걸 제대로 적용하거나 아직 제 생각으로 상식적으로 적용하지는 않는것 같습니다.
애초에 .net 템플릿은 그런 모든걸 고려해서 설계했지만 아직 홍보가 덜된 느낌입니다.
AWS, Azure, GCP같은 Cloud를 사용하게 되면 EC2와 같은 컴퓨팅 비용이 비싸다는 것을 느끼게 됩니다.
같은 비용으로 리소스 낭비 없이 사용하려면 아무래도 컨테이너 기반으로 서비스할 수 밖에 없다는 결론이 나올겁니다.
관리 측면에서도 Kubernetes가 강조되서 그렇지, AWS의 ECS나 Azure의 App Service와 같은 관리형 서비스를 사용하면 큰 문제 없이 사용할 수 있습니다.
도커없는 삶으로 돌아 갈수가… 있군. golang
저같은 경우는 도커가 거의 필수입니다.
개발부터 배포까지 해야하는데 기존 방식으로는 어려워서 이번에 classic asp를 asp.net 8.0 razor pages로 포팅후 도커로 운용하고 있습니다. 물론, 규모가 작아서 가능한 부분입니다.
쿠버네티스나 스웜까지는 필요없을 것 같아서 도커에 portainer + portainer agent + ncloud registry로 사용중입니다.