Development Artist

서론이직을 하게 되면서, 3주간 개인 시간이 생겼다. 무엇을 할지 고민하던 차에, Google Cloud Platform(GCP)를 사용해보자고 결심했다.1차 인터뷰 중 클라우드 인프라 환경이 Google Cloud Platform 이라는 것을 알게 되었는데, PoC 정도로만 사용을 해보고 실제 업무에 경험이 없었기 때문이다.이전에 AWS, Azure, OCI 환경은 잘 사용해보았지만, 하필 GCP 경험이 부족했다. 여유 시간을 활용하여 GCP에서 GKE 클러스터를 구축하고 여유가 된다면, Jenkins / Monitoring 등 여러 툴과 연동을 해보겠다.GCP 프로젝트 생성 및 설정모든 클라우드 플랫폼이 그렇지만, 당장 GCP 콘솔에 접속하여 GKE를 생성하겠다고 하는 것은 어불성설이다. 우선 새 프..

서론퇴사를 하고 잠시 쉬는 날, 책을 읽으며 여유를 즐기고 있을 때였다.문득 떠오른 생각 하나."파일 시스템이 읽기 전용일 때, 쓰기까지 하려면 어떻게 해야 할까?" 보통은 mount 명령어에서 -o remount,rw 옵션을 주면, 읽기 전용 파일 시스템을 다시 쓰기 가능하게 마운트할 수 있다.하지만, 이렇게 해도 여전히 쓰기가 되지 않는 경우가 있다. 왜일까? 이럴 땐 시스템이 더 큰 손상을 막기 위해 스스로 파일 시스템을 읽기 전용(read-only)으로 다시 마운트했을 가능성이 있다.이런 상황을 파악하려면 dmesg 명령어를 통해 커널 메시지를 확인해야 한다.특히 EXT3-fs error로 시작하는 메시지나 Remounting filesystem read-only와 같은 문구가 있는지 살펴보면 된..

왜 서버가 이렇게 느리지? CPU, RAM 그리고 디스크 I/O의 자원 고갈"서버가 왜 이렇게 느리지?"라는 질문은 시스템 관리자라면 하루에도 몇 번씩 듣는 말이다.서버 성능 저하의 원인은 다양하지만, 기본적으로 점검해야 할 세 가지는 CPU, 메모리(RAM), 그리고 디스크 I/O이다. 이 글에서는 데브옵스 책 2장을 읽고 실제 Linux 시스템에서 자원 고갈을 진단하고, 필요한 도구를 이용해 문제를 파악하는 방법을 정리한다.1. 시스템 부하$ uptime 14:00:31 up 10 days, 2:34, 2 users, load average: 2.15, 1.80, 1.75load average: 1분, 5분, 15분 동안의 평균 부하부하 1.00은 논리 CPU 1개가 100% 점유된 상태를 의미..

문제 해결 우수 사례문제 해결은 단순한 작업이 아니라, 반복 학습을 통해 발전하는 하나의 능력이다. 특히 기술적인 문제를 다루는 개발자라면 체계적인 문제 해결 능력은 실력의 핵심이라 할 수 있다. 이 글에서는 데브옵스 책을 읽고 1장, 실무에서 유용하게 적용할 수 있는 문제 해결 우수 사례를 정리한다.1. 문제 영역 나누기문제에 직면했을 때 가장 먼저 해야 할 일은 문제를 영역별로 나누는 것이다. 전체 문제를 한 번에 해결하려다 보면 오히려 파악이 더 어려워질 수 있다.예: "API 응답이 느리다"는 문제는 네트워크, 데이터베이스, 애플리케이션 레이어로 나누어 접근할 수 있다.2. 느리고 복잡한 테스트 보다 간단한 테스트 하기복잡한 시나리오를 바로 테스트하기보다, 가장 단순한 형태의 테스트부터 시도해보자..

서론쿠버네티스(Kubernetes)는 단지 컨테이너 오케스트레이션 시스템이 아니다. 그것은 복잡한 분산 시스템의 ‘논리적 질서(logical order)’를 추구하는 운영 체계이자 철학이다. 이 철학의 핵심에는 다음 세 가지 리소스가 있다: 네임스페이스(Namespace), 컨피그맵(ConfigMap), 그리고 시크릿(Secret). 이 글에서는 해당 세 리소스가 어떻게 쿠버네티스의 구조적 복잡성을 통제하고, 실제 운영 환경에서 어떤 가치를 제공하는지 학문적으로 탐구하고자 한다.1. Namespace: 멀티테넌시와 격리의 시작점1.1 정의Kubernetes에서 Namespace는 리소스를 논리적으로 분리하는 단위이다. 리눅스에서의 chroot나 가상 메모리 공간처럼, 네임스페이스는 쿠버네티스 클러스터 내..

“In theory, there is no difference between theory and practice. In practice, there is.”– Jan L. A. van de Snepscheut서론현대의 분산 시스템에서 마이크로서비스 아키텍처(MSA)는 서비스 간의 유기적인 연결을 전제로 한다. 그러나 컨테이너 기반의 인프라에서 컨테이너는 생성과 소멸이 자유로운 반면, 그들 간의 네트워크 주소는 영속적이지 않다. 이때 등장하는 개념이 바로 쿠버네티스 서비스(Kubernetes Service)이다.쿠버네티스 서비스는 동적으로 변하는 파드(Pod) 들에 대해 안정적인 네트워크 접근점을 제공한다. 본 칼럼에서는 쿠버네티스 서비스의 개념적 정의부터 동작 원리, 유형별 특성, 그리고 실무에서의 응용..

서론쿠버네티스(Kubernetes)는 클러스터 기반의 애플리케이션 운영을 표준화하는 강력한 오픈소스 플랫폼이다. 하지만 설치와 운영은 여전히 복잡하고, 사용 목적이나 인프라 환경에 따라 다양한 설치 도구를 선택해야 한다. 이번 글에서는 세 가지 대표적인 설치 도구인 Kubespray, kubeadm, kops의 특징과 장단점을 비교하여, 상황에 따라 어떤 도구가 적절할지 살펴보자.1. KubesprayKubespray는 Ansible을 기반으로 하는 프로덕션 수준의 쿠버네티스 설치 자동화 도구이다. 다양한 클라우드 및 온프레미스 환경에 대응할 수 있으며, 고가용성(HA) 구성도 지원한다.주요 특징Ansible 기반의 선언적 인프라 관리다양한 클라우드 및 베어메탈 지원고가용성 클러스터 구성 지원커스터마이징..

서론서비스 하나를 띄운다는 건 생각보다 많은 일을 수반합니다.백엔드 서버 하나만 있어도 DB가 필요하고, 캐시가 필요하고, 때로는 메시지 큐나 외부 API 목업 서버까지 붙어야 하죠. 그때마다 우리는 명령어를 반복합니다.docker run ...docker run ...docker run ...처음엔 재밌을 수 있지만, 곧 지칠겁니다."이 많은 걸 왜 매번 따로 띄워야 하지?""내가 띄운 환경을 다른 팀원도 그대로 재현하려면 어떻게 하지?" 이런 반복적인 부분 뿐만이 아닙니다.팀원들의 다양한 요구사항을 관리하기에는 쉽지 않았기 때문입니다."내 애플리케이션은 DB 없이는 작동하지 않아요.""Redis도 필요하고, Celery도 있어야 해요.""그러면 그걸 다 띄우는 스크립트라도 줘야 하나요?" Docker..

서론DevOps 엔지니어로 일하다 보면 도커(Docker)는 매일 사용하는 필수 도구다.컨테이너를 활용하면 애플리케이션을 빠르게 배포하고, 개발과 운영 환경을 동일하게 맞출 수 있어서 협업이 훨씬 수월해진다. ‘시작하세요! 도커/쿠버네티스’ 책을 읽으면서 도커에 대해 다시 한 번 정리하고 싶은 내용들을 이렇게 기록하고자 한다.도커 엔진도커 엔진에서 가장 핵심이 되는 구성 요소는 이미지(Image)와 컨테이너(Container)다.이미지는 여러 계층(layer)으로 구성된 읽기 전용 파일이다. 애플리케이션 실행에 필요한 모든 파일과 설정이 포함되어 있다.컨테이너는 이 이미지를 실행한 결과물로, 독립된 프로세스 공간에서 동작하는 일종의 가상 환경이다.컨테이너를 실행하면 도커는 해당 이미지 기반으로 컨테이너 ..

서론회사에서 DWG 파일을 GLTF로 변환하는 기능을 구현해야 하는 과제가 생겼다. 여러 가지 방법을 검토한 끝에, 변환 과정에서 Blender 엔진을 사용하고, 서버리스(Serverless) 환경에서 배포하는 방향으로 결정했다. 이러한 요구 사항을 충족하기 위해 AWS Lambda를 컨테이너 기반으로 실행하는 방법을 선택했다.이번 글에서는 컨테이너 기반 Lambda의 개념과 이를 도입하는 과정에서 겪은 우여곡절을 공유하려고 한다.LambdaAWS Lambda는 서버를 관리할 필요 없이 코드 실행을 자동으로 처리하는 서버리스 컴퓨팅 서비스다. 사용자는 트리거 이벤트를 기반으로 코드를 실행할 수 있으며, 인프라를 직접 설정할 필요 없이 AWS가 자동으로 리소스를 할당하고 관리한다.Lambda를 활용하는 방..