개발자에게 인프라는 무엇일까?

왜 인프라와 데브옵스를 공부하게 되었나요? 🤔

안녕하세요, 오늘은 인프라와 데브옵스에 관한 이야기를 적어보려 합니다. (연휴라 오랜만에 적어봅니다! 삼일절 만세!)

현재 저는 회사에서 도커와 쿠버네티스 환경에서 작업 중이에요. 팀원들과 원활한 소통을 위해 스터디와 같은 다양한 학습을 시작하게 되었습니다.

 

하지만 단순히 개념만 공부하는 것은 아쉬웠어요.

그래서 실제로 인프라를 운영하는 데브옵스 팀과의 협업이라는 관점에서 정리해보고 싶었습니다.

 

또한 제가 개인적으로 운영 중인 상용 프로젝트에서도 수의사분들의 운영비용 절감을 위해 인프라 학습이 큰 도움이 될 것이라고 판단했어요. 이런 실질적인 필요성이 더 깊은 학습을 가능하게 만들어줍니다.

이 글은 현재 제게 필요한 내용과 제 주관이 들어간 정리본이니, 읽으시는 분들도 꼭 교차검증이나 추가적인 학습을 진행하시는 것을 추천드려요!

---

인프라 지식의 실무적 가치 🌉

• 인프라를 이해하면 개발 환경과 배포 과정을 완벽하게 제어할 수 있어요.
• 클라우드 인프라에 능숙해지면 리소스 확장과 비용 최적화를 손쉽게 관리할 수 있어요.
• 도커 & 쿠버네티스를 자연스럽게 다루면 어떤 환경에서도 일관된 개발과 신속한 배포가 가능해져 작업 효율이 크게 향상돼요!

데브옵스 철학 💭

• 데브옵스 철학에서는 개발이 운영까지 하는 것을 원칙으로 해요.
• 개발자가 운영환경까지 관여하는 것을 다루는 것이 데브옵스 철학이에요.
• 이때 많이 다루는 기술셋 중 하나가 도커와 쿠버네티스예요.

도커 역량은 어느정도가 필요할까요? 🐳

• 개발자는 기본적으로 애플리케이션을 Docker 컨테이너를 사용하여 패키징, 배포, 실행하는 전체 과정인 도커라이징을 할 수 있어야 해요.
• 컨테이너 상황에서의 최적화와 일반적인 애플리케이션 배포 상황에서의 최적화 방법이 다르기 때문이에요.
  • 예: 컨테이너 내부는 불변성(immutability)을 가지므로 로그를 어떻게 관리할지 고민해야 해요.
  • 컨테이너 이미지 크기 최소화: 불필요한 파일과 종속성을 제거하여 이미지 크기를 줄여야 해요.
  • 컨테이너 내부의 데이터를 외부로 링크를 걸어줄 때 사용하는 기능(볼륨)을 통해 영속적 데이터를 관리해야 해요.
• 도커로 갔을 때 어떤 특성이 있고 어떤 식으로 최적화해야 할지 이런 것들을 설계할 수 있어야 해요.
  • 이미지 레이어 최적화 (캐싱 활용)
  • 멀티 스테이지 빌드 사용: 하나의 Dockerfile에서 여러 단계를 거쳐 최종 이미지를 만드는 방법으로, 빌드 도구나 소스 코드 없이 실행 파일만 포함된 작은 크기의 최종 이미지를 생성해요.
  • 비루트 사용자로 애플리케이션 실행하기
  • 환경변수를 통한 설정 관리

아키텍처 설계 방법은? 🏗️

• 일반적으로 단순히 애플리케이션을 배포해서 서비스할 때는 모놀리식(Monolithic) 상태로 배포해야 할 때가 있어요.
• 도커나 쿠버네티스를 다루다 보면 마이크로서비스 상태로 설계하고 쪼개야 할 때가 많아요.
• 쿠버네티스의 특성을 활용하는 경우도 많아요.
  • 서비스 분리와 독립적 스케일링
  • 장애 격리(Fault Isolation)
  • 기능별 배포 및 롤백 용이성
• 예시)
  • 모놀리식 아키텍처는 전체 애플리케이션이 하나의 큰 코드베이스로 구성되어 있어 개발, 테스트, 배포가 상대적으로 간단해요.
  • 그러나 아래와같은 이유로 도커나 쿠버네티스와 같은 컨테이너 기술을 다루다 보면, 애플리케이션을 마이크로서비스 아키텍처로 설계하고 분할해야 하는 경우가 많아져요.
    • 독립적인 배포: 각 서비스를 개별적으로 배포할 수 있어, 전체 시스템을 중단하지 않고도 특정 기능을 업데이트하거나 확장할 수 있어요 (API 서버, 프론트엔드, 데이터베이스 등으로 분리하여 각각을 독립적인 컨테이너로 운영).
    • 리소스 효율성: 쿠버네티스의 특성상 각 서비스에 필요한 리소스를 개별적으로 할당하고 관리할 수 있어, 메모리와 CPU 사용을 최적화할 수 있어요.
    • 기술 다양성: 각 마이크로서비스는 독립적이므로, 서비스별로 가장 적합한 기술 스택을 선택할 수 있어요.

프론트엔드 개발자도 배포에 관심을 가져야 해요! 🌐

당장 도커까진 아니더라도, React.js를 다루는 프론트엔드 개발자분들 중에 배포를 완전히 백엔드 개발자나 인프라팀에 넘기고 관심을 두지 않는 경우가 있어요. 하지만 이러면 많이 아쉽잖아요?!

아래에 제 기준을 적어놨어요.

• FE도 배포를 클라우드쪽에 하다보니 클라우드 기술들을 많이 알고 있어야 해요.
• 이를테면 FE쪽에서 다루다보면 Node.js로 개발하고 서빙을 하게 돼요.
• 실제로 클라우드를 사용하게 되면 'CFS3'라고 많이 이야기를 하는데, 이는 CloudFront 더하기 S3로 스태틱하게 파일을 빌드해서 서빙한다는 뜻이에요.
• 이런 것들을 하기 위해서는 데브옵스팀과 이야기를 해야 하고, 적어도 내가 개발하는 시스템이 어떤 형상으로 배포되어 서빙될 것인지 그 구조를 알아야 인프라팀이나 데브옵스팀, 혹은 클라우드 엔지니어와의 대화가 편하실 거예요.

그러니 프론트엔드 개발자분들도 배포 과정과 인프라에 대해 알고 계셔야 좋습니다!!

데브옵스 엔지니어와의 협업은 어떻게 이루어질까요? 🤝

• 데브옵스 엔지니어는 서비스를 오픈하기 전이나 인프라에 배포하기 전에 쿠버네티스에 배포하기 위해 몇 가지 질문을 하게 돼요 (이때 잘 대답하기 위해 지금부터 설명할 내용들을 학습해보아요).
• 이때 쿠버네티스나 도커 같은 기반기술을 폭넓게 알고 있지 않으면 문제가 되는 경우가 많아요.
  • 리소스 요구사항(CPU, 메모리)
  • 네트워크 정책 및 요구사항
  • 환경변수 및 구성 관리 방법
  • 상태 관리 전략

그럼 협업을 위해 알아야 할 쿠버네티스 이론은 무엇이 있을까요? ☸️

• 운영 측면에서 필요한 쿠버네티스 이론이 있고 개발이나 배포 측면에서 필요한 쿠버네티스 이론이 있어요.
• 개발자는 개발이나 배포 측면에서 필요한 쿠버네티스 이론을 많이 다루는 것이 좋아요.

개발자가 알아야 할 쿠버네티스 리소스 📦

• 개발이나 배포 측면에서 다루는 쿠버네티스 리소스들은:
  • 파드(Pod): 쿠버네티스의 가장 기본적인 배포 단위예요 (원래 표기는 Pod이며 한글로는 '파드'로 표기해요).
  • 서비스(Service): 파드 집합에 대한 단일 진입점을 제공하는 추상화 계층이에요.
    • 서비스는 여러 파드에 걸쳐 트래픽을 로드밸런싱 해주는 역할을 해요.
    • ClusterIP, NodePort, LoadBalancer, ExternalName 등 다양한 유형이 있어요.
    • 서비스 디스커버리와 내부 DNS를 통해 마이크로서비스 간 통신을 가능하게 해요.
    • 파드의 생성, 삭제, 재시작에 관계없이 안정적인 엔드포인트를 제공해요.
    • 레이블 셀렉터를 통해 어떤 파드가 서비스에 포함될지 결정해요.
  • 인그레스(Ingress): 클러스터 외부에서 내부 서비스로의 HTTP/HTTPS 라우팅 규칙 관리예요.
  • 인그레스 컨트롤러(Ingress Controller): 인그레스 규칙을 실제로 구현하는 컴포넌트예요.
• 컨트롤 플레인 영역은 아직 깊게 알 필요 없다고 판단했어요. 기본적인 것만 알면 됩니다!
  • 기본적인것의 예시:
    • kube-apiserver가 무슨 일을 하는지, kube-dns(CoreDNS)가 무슨 일을 하는지 정도의 기본 개념만 알면 돼요.

데브옵스/인프라 전문가가 알아야 할 것 🔍

• 인프라를 전문적으로 다루거나 데브옵스를 하게 되면 컨트롤 플레인 영역에서 다루는 4대 컴포넌트에 대해 상세히 알아야 해요.
  • kube-apiserver: API 요청을 처리하는 프론트엔드예요.
  • etcd: 클러스터 상태를 저장하는 키-값 데이터베이스예요.
  • kube-scheduler: 파드를 노드에 할당하는 컴포넌트예요.
  • kube-controller-manager: 다양한 컨트롤러를 실행하는 컴포넌트예요.
• IRSA(IAM Roles for Service Accounts) 같은 인증 방식에 대해서도 잘 알아야 해요.
  • 서비스 계정에 대한 IAM 역할을 기반으로 한 보안 인증 정보 체인을 사용하는 방식이에요.
• GKE(Google Kubernetes Engine), AWS의 EKS(Elastic Kubernetes Service) 등 각 클라우드에서 제공하는 쿠버네티스 환경들의 특성에 대해서도 잘 알아야 해요.

리소스 설계와 구성 결정 📝

현재 환경

• 우리는 현재 OKD(OpenShift Kubernetes Distribution)라는 쿠버네티스 배포판을 사용하고 있어요.
• OKD는 Red Hat의 오픈소스 엔터프라이즈 쿠버네티스 플랫폼으로, 기본적인 쿠버네티스 기능 외에도 다양한 추가 기능들을 제공합니다.

OKD 내부 리소스 설계

• OKD 환경에서 리소스 구성을 어떻게 할지 설계하여 데브옵스 팀에 가이드를 제공해야 합니다:
  • Routes vs Ingress: OKD는 Route라는 고유 리소스를 제공하며, 이는 기본적으로 HAProxy 기반 인그레스 컨트롤러와 함께 작동해요.
  • 템플릿과 오퍼레이터: OKD에서 제공하는 템플릿과 오퍼레이터를 활용하여 애플리케이션 배포를 단순화할 수 있어요.
  • 프로젝트와 네임스페이스: OKD의 프로젝트는 쿠버네티스 네임스페이스의 확장 개념으로, 추가적인 보안 및 관리 기능을 제공해요.
  • DeploymentConfig: OKD에서는 Deployment 대신 DeploymentConfig를 사용할 수 있으며, 더 세밀한 배포 전략을 제공해요.

커스텀 리소스 및 확장 구성

• 특정 요구 사항에 따라 추가 구성이 필요할 수 있습니다:
  • 커스텀 리소스(CustomResources) 정의를 통해 OKD에서 기본적으로 제공하지 않는 리소스 타입을 구현할 수 있어요.
  • 스테이트풀셋(StatefulSet) 구성으로 상태 유지가 필요한 애플리케이션(예: 데이터베이스)을 관리할 수 있어요.
  • 서비스 메시(Service Mesh): OKD에서는 Red Hat Service Mesh(Istio 기반)를 통합하여 마이크로서비스 간 통신을 관리할 수 있어요.

인그레스 및 트래픽 관리 옵션

• OKD 환경에서 다양한 인그레스 옵션을 고려할 수 있습니다:
  • 기본 HAProxy 인그레스: OKD는 기본적으로 HAProxy 기반 인그레스 컨트롤러를 제공해요.
  • NGINX 인그레스 컨트롤러: 고부하 트래픽 환경에서는 NGINX 인그레스 컨트롤러를 대안으로 설치할 수 있어요.
    • 장점: 고성능, 세밀한 설정 가능, 광범위한 커뮤니티 지원
    • 단점: 추가 구성 및 관리 필요
  • API 게이트웨이: Kong, Ambassador 등의 API 게이트웨이를 OKD 위에 설치하여 고급 라우팅 기능을 활용할 수 있어요.

OKD의 대안책 검토

• 현재 OKD를 사용 중이지만, 필요에 따라 다른 쿠버네티스 배포판도 고려할 수 있습니다:
  • EKS(Amazon Elastic Kubernetes Service): AWS 환경에서 관리형으로 쿠버네티스를 운영하고 싶을 경우
    • 장점: 관리 부담 감소, AWS 서비스와의 통합 용이
    • 단점: OKD의 추가 기능들(CI/CD 통합, 개발자 카탈로그 등) 부재
  • GKE(Google Kubernetes Engine): Google Cloud에서 관리형 쿠버네티스를 원할 경우
  • AKS(Azure Kubernetes Service): Microsoft Azure에서 관리형 쿠버네티스를 원할 경우
  • Rancher: 다중 클러스터 관리 기능이 필요한 경우의 대안

개발자와 운영 협업

• 개발 팀에서도 인프라를 충분히 이해할 필요가 있습니다:
  • OKD의 웹 콘솔을 통해 개발자들도 배포 및 모니터링 과정에 참여할 수 있어요.
  • 개발자와 운영팀이 함께 사용할 수 있는 OKD의 CI/CD 파이프라인 구성이 가능해요.
  • 개발자들이 직접 애플리케이션 리소스 요구사항(CPU, 메모리, 스토리지 등)을 정의하도록 가이드해줘야 해요.

리소스 관리 전략 ⚙️

• 특히 쿠버네티스 환경에서는 리소스를 어떻게 쪼개고 나눌 것인지 결정이 필요해요.
• 어느 부분을 ConfigMap에 두고 어느 부분을 Secret으로 관리할 것인지에 대한 설계도 개발 팀에서 제공하면 좋아요.
  • ConfigMap: 환경별 설정, 로그 레벨, 앱 구성 등 민감하지 않은 설정이에요.
  • Secret: API 키, 인증서, 패스워드 등 민감한 정보예요.

마치며 

이상으로 인프라와 데브옵스에 관한 중요 개념들을 간략히 보았습니다! 이 글이 여러분의 학습과 업무에 도움이 되었으면 좋겠어요.

다시 한번 말씀드리지만, 이 글은 제 주관적인 관점과 경험을 바탕으로 작성되었답니다. 꼭 다른 자료들도 함께 참고하시고, 실무에 적용하실 때는 교차검증을 하시는 것을 추천드려요!

궁금한 점이나 의견이 있으시면 언제든지 댓글로 남겨주세요. 함께 성장하는 기회가 되었으면 좋겠습니다. 

감사합니다!