Skip to content

태그: DevOps

SLO, SLI, SLA
monitoring
SLA: Service Level Agreements SLA는 고객이 서비스를 사용할 때 기대하는 서비스 레벨이다. SLA를 정의할 떄는 단순한 지표를 사용하는 것이 좋다. SLO: Service Level Objectives SLO란 시스템에서 기대하는 가용성을 설정한 목표이다. SLA가 사용자가 기대하는 수치라면, SLO는 실제로 팀에서 지키기 위해 노력할 달성 목표이다. SLO는 발생할 수 있는 변수를 감안하여 SLA보다 더 높은 값으로 설정하는 경우가 많다. 목표에 집중하기 위해선 SLO는 최소 갯수만 정의하는 것이 좋다. SLI: Service Level Indicator SLI란 사용자가 시스템의 가용성을 경험하는 방식을 정량적으로 측정한 것이다. 즉, 목표에 대비한 실제 지표이다. SL
MetalLB
kubernetes
MetalLB는 BareMetal LoadBalancer의 약자로, Kubernetes 클러스터에 연결되어 온프레미스 환경(IDC)에서 로드밸런서 타입 서비스를 구현해주는 툴이다. MetalLB가 제공하는 기능을 크게 나누면 주소를 할당해주는 기능과 외부와 연결하는 기능 두 가지로 나누어 볼 수 있다. 주소 할당 클라우드 제공업체의 Kubernetes 클러스터에서는 로드밸런서를 요청하면 클라우드 플랫폼이 IP 주소를 할당해준다. 베어메탈 클러스터에서는 MetalLB가 이 할당을 담당한다. MetalLB에 사용할 수 있는 IP 주소 풀을 제공하면 해당 풀에서 LB를 생성해준다. 외부 연결 MetalLB가 서비스에 외부 IP 주소를 할당한 후에는 해당 IP가 클러스터에 “존재한다”는 것을 클러스터 외부
AWS Organization
aws
AWS Organization는 AWS 계정 (accounts)을 단일 단위로 통합해 관리할 수 있는 개체이다. Organization 안의 모든 계정을 중앙에서 확인하고 관리할 수 있다. AWS Organizations는 비즈니스의 예산, 보안과 규정 준수 필요 충족에 도움이 되는 계정 관리 및 통합 결제 기능까지 함께 제공한다. 조직의 관리자로서 조직에서 계정을 생성하고 기존 계정을 조직에 초대할 수 있다. 1개의 관리자 계정(management account)과 0개 이상의 멤버 계정(member account)을 갖고 있다. 위 그림에 나타나 있듯이 tree 계층 구조로 OU를 생성할 수 있다. 각 계정(Each Account)을 OU에 포함하거나 루트에 포함할 수 있다. 루트 (Root) Orga
Pyroscope Distributor and Ingester
grafana
Distributor Distributor는 Agent로부터 프로파일링 데이터를 받아 처리하는 Stateless 컴포넌트이다. Distributor는 데이터를 일괄 처리하여 여러 Ingesters에 병렬로 보내고, 시리즈를 Ingesters 사이에 나누며, 각 시리즈를 구성된 복제 요소에 따라 복제한다. 기본적으로 구성된 복제 요소는 세 개이다. 유효성 검사 Distributor는 데이터를 Ingester에 전달하기 전에 유효성을 검사, 변환 절차를 거친다. 데이터 중 일부 샘플만 유효하다면 유효한 데이터만 Ingester에 전달하고, 유효하지 않은 데이터는 Ingesters에 보내지지 않는다. 요청에 유효하지 않은 데이터가 포함되어 있으면 Distributor는 Bad Request 코
Platform Engineering
devops
플랫폼 엔지니어링은 클라우드 네이티브 시대에 소프트웨어 엔지니어링 조직의 작업을 촉진하고 가속화하기 위한 플랫폼을 설계하고 제공하는 분야이다. 다시 말해, 플랫폼 엔지니어링의 목적은 “소프트웨어 엔지니어링 조직이 일을 더 빠르게 잘 할 수 있도록 하는 것”이고, 그 문제를 “플랫폼”을 통해 해결한다. 애플리케이션을 빠르게 제공할 수 있도록 지원하는 DevOps와도 비슷한 목적을 가지고 있다. 개발과 운영 조직의 비효율성을 문화와 도구들을 이용해 해결하려는게 DevOps라면, 플랫폼 엔지니어링은 DevOps의 도구로 ‘플랫폼’을 채택한 것이라는 차이가 있다. 플랫폼 엔지니어링 팀은 DevOps 방법론 위에서 소프트웨어 엔지니어링 팀, 프로덕트 팀을 지원할 수 있는 플랫폼을 만든다. 플랫폼 엔지니어링은 아래와
Docker와 PID1
container
1. 배경 Linux 신호는 컨테이너 내부의 프로세스 수명 주기를 제어하는 주요 방법이다. 앱의 수명 주기를 앱이 포함된 컨테이너와 긴밀하게 연결하려면 앱이 Linux 신호를 올바르게 처리하도록 해야한다. 프로세스 식별자(PID)는 Linux커널이 각 프로세스에 제공하는 고유한 식별자이다. PID는 namespace입니다. 즉, 컨테이너에는 호스트 시스템의 PID가 매핑되는 고유한 PID 세트가 있다. Linux 커널을 시작할 때 실행된 첫 번째 프로세스에는 PID 1이 있다. 정상적인 운영체제의 경우 이 프로세스는 init 시스템(ex. systemd 또는 SysV)이다. 마찬가지로 컨테이너에서 실행된 첫 번째 프로세스는 PID 1을 얻는다. Docker와 Kubernetes는 신호를 사용하
Athena
analytics
Amazon Athena는 오픈 소스 프레임워크를 기반으로 구축된 서버리스 대화형 분석 서비스로, 오픈 테이블 및 파일 형식을 지원한다. 페타바이트 규모의 데이터를 분석할 수 있는 간단한 방법을 제공한다. Athena를 사용하면 SQL 또는 Python을 사용하여 Amazon Simple Storage Service(S3) 데이터 레이크와 온프레미스 데이터 소스나 다른 클라우드 시스템을 포함한 30개의 데이터 소스에서 데이터를 분석하거나 애플리케이션을 구축할 수 있다. 오픈 소스 Trino 및 Presto 엔진과 Apache Spark 프레임워크를 기반으로 구축되어 있으며, 프로비저닝이나 구성 작업 없이 사용할 수 있다. SQL용 Amazon Athena는 AWS Management Conso
Instance Store
ec2
AWS Instance Store는 Amazon Elastic Compute Cloud (EC2)에서 제공하는 임시 블록 수준 스토리지 서비스이다. EC2 인스턴스에 직접 연결된 로컬 디스크로, EC2 인스턴스가 실행 중인 동안에만 데이터를 유지한다. Instance Store는 인스턴스와 함께 묶여 있어 저렴하면서도 빠른 I/O 처리량을 제공한다. 그러므로 인스턴스 스토어를 사용하여 저지연 및 높은 처리량 작업을 수행할 수 있다. (대규모 데이터베이스, 데이터 웨어하우스, 로그 분석, 캐싱 등) 하지만 Instance Store는 휘발성이므로, 인스턴스가 종료되거나 재부팅되면 데이터가 영구적으로 삭제된다. 그러므로 임시 데이터나 캐시와 같이 데이터의 지속성이 필요하지 않은 작업에 적합하다. AWS Inst
RI와 Saving plan
ec2
RI 예약 인스턴스(Reserved Instance)라고 한다. 1년 혹은 3년 동안 EC2 혹은 RDS 인스턴스의 특정 유형을 예약하여 사용하는 방법이다. 예를 들어, t2.micro 인스턴스 3개를 1년치 예약한다고 하자. 그럼 1년 동안은 실행 중인 t2.micro 인스턴스 3개에 대해 추가 비용 없이 사용할 수 있다(이미 비용을 지불했기 때문). 즉, 기존 t2.micro 인스턴스를 삭제하고 새로운 t2.micro 인스턴스를 생성해도 새로운 인스턴스는 자동으로 예약 인스턴스에 포함된다. 예약 인스턴스는 3가지 결제 방식을 지원한다. 전체 선결제(All Upfront) 비용을 모두 선결제, 가장 저렴하다. 부분 선결제(Partial Upfront) 일부는 선결제, 일부는 선결제 없음(No Upfro
VPC
netwoking
가상 프라이빗 클라우드(VPC)는 퍼블릭 클라우드 내에서 호스팅되는 안전하고 격리된 프라이빗 클라우드이다. VPC를 사용하면 정의한 논리적으로 격리된 가상 네트워크에서 AWS 리소스를 효율적으로 관리할 수 있다. VPC별로 네트워크를 구성하거나 각각의 VPC에 따라 다르게 네트워크 설정을 줄 수 있다. 또한 각각의 VPC는 완전히 독립된 네트워크처럼 작동한다. 아래 그림은 VPC의 예시이다. VPC에는 리전의 각 가용성 영역에 하나의 서브넷이 있고, 각 서브넷에 EC2 인스턴스가 있고, VPC의 리소스와 인터넷 간의 통신을 허용하는 인터넷 게이트웨이가 있는 구조이다. 쉽게 예시를 들자면, 퍼블릭 클라우드를 붐비는 레스토랑으로, 가상 프라이빗 클라우드를 붐비는 레스토랑의 예약된 테이블로 생각해볼 수 있다.
VPC Mapping Service
netwoking
AWS VPC를 이용해서 가상 네트워크를 만들면 아래와 같은 구성이 된다. 물리 Host 내에 다수의 VPC가 존재할 수 있고, 각 VPC 간에는 독립적인 구성이 가능하다. 각 VPC는 서로 다른 IP 대역(CIDR)를 사용하는 것 뿐 아니라, 내부 IP를 같은 값으로 지정할 수도 있다. 하나의 VPC는 여러 물리 Host로 나뉘어 위치하기도 한다. 서로 다른 Host에 위치한 ZIGI-VM1과 ZIGI-VM3은 논리적으로 같은 네트워크이기 때문에 서로 간의 통신이 가능하다. 근데 물리적으로 서로 다른 ZIGI-VPC1과 ZIGI-VM3은 어떻게 통신이 가능할까? 바로 아래과 같이 VPC에 대한 정보는 Encapsulation하고, 통신하고자 하는 물리 Host IP 정보를 같이 담아 전송하게 된다. 그
KMS
security
KMS는 Key Management Service의 약자로, 데이터를 암호화 할떄 사용되는 암호화 Key를 안전하게 관리하는데 목적을 둔 AWS의 서비스이다. KMS는 크게 세가지 방식으로 key 관리 서비스를 제공한다. AWS managed key AWS 서비스들이 내부적으로 발급받는 Key로, 내부적으로 자동으로 일어나게 되며 사용자가 직접적으로 제어가 불가능하다. 자신의 AWS 계정에 들어가면 만들어진 Key의 목록을 확인하는건 가능하다. (참고) 모든 AWS managed keys는 1년마다 rotate된다. 이 주기는 사용자가 변경할 수 없다. Customer managed key(CMK) 사용자가 직접 key를 생성하고 관리하는 것이다. CMK에 대해서는 IAM을 통해 권한을 부여받아 제
AppSync
storage
AppSync는 AWS에서 제공하는 Managed GraphQL 서비스이다. 즉, 서버리스의 형태로 GraphQL 백엔드를 개발할 수 있는 서비스이다. AppSyn 를 사용하지 않고도 AWS Lambda 등을 활용하여 GraphQL 백엔드를 구축하는 것이 가능했으나, 이 경우에는 Lambda 메모리 사이즈, 콜드스타트, DataSource와의 통신, 인증된 유저 토큰 처리 등등 고민해야하고 직접 개발해야하는 것들이 더 많았다. 그러나 AppSync 를 활용하면 GraphQL 스키마를 작성하고 스키마의 각각의 필드에 대한 resolvers 를 작성하는 것만으로도 GraphQL 엔드포인트를 생성할 수 있다. Resolver AppSync에서는 resolver를 VTL이라는 자바 기반 템플릿 언어으로 작성한다.
CI/CD파이프라인
devops
CI(Continuous Integration) CI는 지속적 통합이라는 뜻으로 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 충돌 없이 작업, 관리할 수 있음을 의미한다. 또한, 공유 버전 관리 레포지토리에 통합되어 있는 코드에 대해, 자동화된 테스트를 진행하여 통합된 코드에서 생기는 문제를 신속하게 파악하고 해결할 수 있도록 하는 것이 CI의 특징이다. CD(Continuous Delivery/Deployment) CD는 지속적인 제공또는 지속적인 배포를 모두 의미한다. 두 가지 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만, 자세한 개념은 다르다. 지속적인 제공(Continuous Delivery) 지속적인 제공은 개발자들이 애플리케이션에 적용한 변경사항이 버그 테스
CNI
cni
container를 돌리는 모든 소프트웨어들은(ex. docker, rkt, mesos, k8s) 각 컨테이너간의 네트워크를 구현한다. 그것은 모두 네트워크 네임스페이스를 통해 구현되고, 서로 비슷한 절차를 거쳐 브릿지를 생성한다. 약간의 차이는 있을 수 있지만 전반적인 흐름은 아주 유사하다. 그렇다면 그 작업을 표준화한 인터페이스를 만든다면 어떨까? 이를 위해 정의된 것이 바로 CNI(Container Network Interface)이다. CNI는 컨테이너 네트워크 작업을 수행하는 코드가 대략적으로 어떤 동작을 해야하고, 어떻게 호출되어야햐는지를 정의한다. 컨테이너를 돌리는 소프트웨어는 CNI 스펙에 맞추어 함꼐 동작할 수 있도록 구현됐기 때문에 해당 Interface를 구현하는 구현체중 원하는 것을
ContainerRuntime
container
컨테이너를 쉽게 다운로드받거나 공유하고 구동할 수 있게 도와주는 툴 컨테이너를 실행하기 위해서는 다음과 같은 세 단계를 거쳐야한다. 즉, 컨테이너 런타임은 이러한 단계들을 실행해주는 기능을 가진다. 런타임은 실제 컨테이너를 실행하는 단계만 수행하는 저수준 컨테이너 런타임(OCI 런타임)과 컨테이너 이미지의 전송 및 관리, 이미지 압축 풀기 등을 실행하는 고수준 컨테이너 런타임으로 나뉜다. 컨테이너를 실행하려면 저수준 및 고수준 컨테이너 런타임이 각각의 역할을 해야한다. 즉, 컨테이너를 실행하려면 두 런타임이 모두 있어야한다. 저수준 컨테이너 런타임(Low-Level Container Runtimes) 컨테이너는 Linux namespace와 cgroup을 사용하여 구현한다. namespace : 각 컨
Container Orchestration
container
레드햇(Red Hat)의 정의에 따르면, IT 업계에서 오케스트레이션(Orchestration)이란 용어는 “컴퓨터 자원과 어플리케이션, 서비스에 대한 자동화된 설정, 관리 및 제어 체계”를 의미한다. 비슷한 느낌으로 컨테이너 오케스트레이션은, "컨테이너화 된 애플리케이션에 대한 자동화된 설정, 관리 및 제어 체계"로 받아들일 수 있다. 컨테이너 오케스트레이션이 필요한 이유 단일 호스트로 구성된 환경은 확장성(Scalability)과 가용성(Availabilty), 그리고 장애 허용성(Fault Tolerance) 측면에서 많은 한계점을 가지기 때문에, 애플리케이션을 여러개의 호스트로 나누어 구축해야하는 경우가 많다. 마이크로서비스 아키텍처(MSA; Microservice Architecture)에서는 프
DockerSwarm
docker
Docker Swarm은 도커에서 자체적으로 제작한 컨테이너 오케스트레이션 도구이다. Docker Swarm을 사용한다면 여러 컨테이너의 배포를 관리하고, 네트워크 및 컨테이너 상태를 제어 및 모니터링 할 수 있다. 쿠버네티스와의 차이? 컨테이너 오케스트레이션을 위한 툴로는 여러가지가 있는데 그중 가장 널리 쓰이는 것은 쿠버네티스로, 사실상 표준 기술로 자리잡았다 볼 수 있을 정도로 널리 쓰이고 있다. 하지만 도커 스웜(Docker Swarm)은 Mirantis가 Docker의 엔터프라이즈 플랫폼 사업을 인수한 이래로 유지보수 단계에 접어들어 더 이상의 발전과 기능 추가를 기대할 수 없게 되었다. 그렇다면 도커 스웜보다는 쿠버네티스를 배우는게 좋지 않을까? 굳이 도커 스웜을 사용해야하는 이유가 뭘까? 도커
Prune
docker
Docker를 오랜 시간 사용하게 되면 여러가지 오브젝트들이 시스템에 쌓이게 된다. 컨테이너나 이미지는 많으면 수십 수백개까지도 늘어난다. Docker 컨테이너, 이미지, 볼륨은 사용중이 아니더라도 디스크를 차지하고 있다. 오브젝트들을 일일히 삭제하거나 통째로 날려버릴 수도 있지만, 사용하지 않는 오브젝트들을 파악해 빠르게 시스템 자원을 확보하는 방법도 있다. prune 서브 커맨드가 바로 이런 역할을 한다. Prune 커맨드를 사용하면 사용하지 않는 컨테이너, 볼륨, 이미지를 일괄적으로 삭제할 수 있다. container docker container prune --filter 옵션으로 특정 오브젝트만 삭제할 수도 있다. 중지된 지 1시간 이상 지난 컨테이너만 삭제docker container prune
README
docker
도커는 LXC(리눅스 컨테이너스)라는 커널 컨테이너 기술을 이용하여 만든 컨테이너 기술 중 하나로, 컨테이너 기반의 오픈소스 가상화 플랫폼이다. 컨테이너를 모듈식 가상머신처럼 유연하게 사용하여 애플리케이션을 안정적으로 배포 및 구축할 수 있도록 한다. 또, 이미지 기반 배포 모델을 제공하고 여러 환경 전반에서 애플리케이션 또는 서비스를 모든 종속 항목과 손쉽게 공유할 수 있다. 운영체제를 가상화하지 않는 컨테이너 기술이기 때문에 가상머신에 비해 가볍고, 한 대의 서버에 여러 애플리케이션을 실행하기 좋다. 단일한 물리적 컴퓨터 위에서 여러 애플리케이션을 돌릴 수 있기 때문에 물리적 하드웨어의 컴퓨팅 용량을 효율적으로 사용할 수 있다. 가상머신(VM)들과 달리, 기존 리눅스 자원(디스크, 네트워크 등)을 그대로
가상화와 컨테이너
docker
가상화 가상화는 단일 컴퓨터의 프로세서, 메모리, 스토리지 등과 같은 하드웨어 요소를 가상 머신(VM, Virtual Machine)이라고 하는 다수의 가상 컴퓨터로 분할할 수 있도록 해주는 추상화 계층을 구축하는 기술을 말한다. 실제로는 컴퓨터의 일부에서만 실행됨에도 불구하고, 각각의 VM은 자체적으로 운영체제(Guest OS)를 실행하며 마치 여러개의 컴퓨터인 것 처럼 독립적으로 작동된다. ✔️가상화의 장점 1. 리소스 효율성 가상화 이전에는 애플리케이션마다 별도의 서버를 구성해야했다. 그렇기 때문에 한 애플리케이션이 유휴상태에 있을때는 서버가 활용되지 못한 채 방치된다. 하지만 서버 가상화를 사용하면 단일한 물리적 컴퓨터 위에서 여러 애플리케이션을 돌릴 수 있기 때문에 물리적 하드웨어의 컴퓨팅 용량을
도커 네트워크
docker
Docker 컨테이너(container)는 격리된 환경에서 돌아가기 때문에 기본적으로 다른 컨테이너와의 통신이 불가능하다. 하지만 여러 개의 컨테이너를 하나의 Docker 네트워크(network)에 연결시키면 서로 통신이 가능해잔다. 다시말해, Docker 네트워크는 컨테이너 간 네트워킹이 가능하도록 도와주는 역할을 한다. 네트워크 종류 Docker는 목적에 따라 다양한 종류의 네트워크 드라이버를 지원한다. 그 종류에 대해 알아보자. none none 네트워크에서 도커 컨테이너는 서로 독립되어서, 정보를 전혀 주고받을 수 없다. 호스트 외부로 접근하는 경우에도 네트워크가 연결되지 않는다. host host 네트워크에서는 host와 컨테이너가 네트워크의 구분 없이 서로 면결된다. 만약 컨테이너가 80
도커 스토리지
docker
여러 작업 중 컨테이너 내부에서 생성한 정보, 파일은 컨테이너가 종료된 후에 모두 사라진다. 이러한 데이터를 저장하려면 별도의 저장공간이 필요한데, 컨테이너가 동작 중인 상태에서는 접근이 제한되기 때문에 직접 옮기기는 쉽지 않다. 도커는 스토리지에 파일을 저장하여 컨테이너가 종료되더라도 파일을 유지할 수 있도록 한다. 스토리지는 원본 이미지를 수정 하는 대신 변경된 정보를 따로 저장하고, 원본 데이터와 변경된 정보를 조합해서 복원하는 식으로 데이터를 읽는다. 이렇게 하여 원본 이미지를 수정 할 필요 없이 각 컨테이너마다 다른 정보를 저장 할 수 있다. 스토리지 종류 도커 스토리지의 종류는 3가지가 있다. Volume, bind mount, tmpfs mount이다. 아래 그림은 각 방식을 나타내는 그림이다.
도커 안에서 도커 사용하기
docker
도커를 사용하다보면 모종의 목적으로 도커 컨테이너 안에서 도커를 사용할 일이 생길 수 있다. 이것을 Docker in Docker (DinD)라고 부르는데, 이를 위한 방법은 크게 2가지로 나뉜다. 호스트의 도커 데몬을 사용(마운트)하여 도커 컨테이너 내부에서 호스트의 도커 데몬을 사용하는 방법 도커 컨테이너 내부에서 ‘실제’ 도커를 사용하는 방법 1. 도커 컨테이너 내부에서 호스트의 도커 데몬을 사용하는 방법 이 방법은 도커 컨테이너 내부에서 도커를 사용할 때, 도커 컨테이너 내부의 도커가 아닌, 호스트의 도커 데몬을 사용해서 도커를 사용하는 방법이다. 도커 데몬에게 명령을 내릴 수 있는 인터페이스인 ‘docker.sock’ 파일을 마운트해서 실행하면 된다. 이렇게 설정해주면 도커 컨테이너 내부의 도커
cAdvisor
container
Kubernetes(k8s)에서 cAdvisor는 “Container Advisor”의 줄임말로, 컨테이너 메트릭을 수집하고 모니터링하기 위한 도구이다. cAdvisor는 Google에서 개발한 오픈 소스 프로젝트로, 컨테이너화된 환경에서 작동하는 애플리케이션 및 서비스의 성능을 실시간으로 추적하고 이해하는 데 도움을 준다. 주 기능 컨테이너 메트릭 수집: cAdvisor는 호스트 시스템에서 실행 중인 각 컨테이너에 대한 메트릭을 수집한다. 이 메트릭은 CPU 사용량, 메모리 사용량, 디스크 I/O, 네트워크 사용량 및 다른 성능 관련 정보를 포함한다. 시각화: cAdvisor는 수집된 메트릭을 시각적으로 표시하여 사용자가 컨테이너의 성능과 리소스 사용 상태를 쉽게 이해할 수 있도록 도와준다. 리소스 모니
Fail over와 서버 이중화
dr
Fail over fail over는 장애 대비 기능을 의미한다. 컴퓨터 서버, 시스템, 네트워크 등에서 이상이 생겼을 때 미리 준비했던 다른 시스템으로 자동으로 전환해서 무정지 시스템을 운영하여 fail over할 수 있다. failback : 페일오버에 따라 전환된 운용환경을 장애 발생 전 상태로 되돌리는 처리 High Availability(서비스를 정상적으로 사용 가능한 정도를 의미)을 요구할 때 구성한다. 웹 서버, 네트워크 장비, DB 등 다양한 영역에 대비한다. 하드웨어적인 장애 뿐만 아니라 소프트웨어를 포함한 서비스가 운영되지 않은 모든 장애를 포함한다. 서버 이중화 Active-Active 주로 부하 분산 등의 목적, 서비스 단위를 나누어서 분산 다중화 장비 두 대가 모두 활성화 되어
Phoenix Server
iac
예전에 일반적으로 서버를 운영할때는 주로 서버를 설치한 후 OS를 설치한 후에, 필요한 소프트웨어와 애플리케이션을 설치하여 운영하였다. 여기에 문제가 생긴 경우 패치를 하거나 정기적인 보안 패치 튜닝들을 해당 서버에 지속적으로 적용하고, 애플리케이션은 CI/CD 등의 툴을 이용하여 배포하는 구조를 가지고 있었다. 이렇게 한번 설치한 서버에 계속해서 설정을 변경하고 패치를 적용하는 등의 업데이트를 지속적으로 적용하여 운영하는 서버를 Snowflakes Server라고 하는데, 이렇게 설정된 서버는 다시 똑같이 설정하기가 매우 어렵다. 모든 설정과정이 문서화가 잘되어 있으면 모르겠지만 대부분 문서화가 꼼꼼한 경우가 굉장히 드물고, 담당자가 바뀌거나 관리 조직이 바뀌는 경우에는 그 이력이 제대로 유지되는 경우가
K8s Architecture
kubernetes
쿠버네티스는 중앙(Master)에 API 서버와 상태 저장소를 두고 각 서버(Node)의 에이전트(kubelet)와 통신하는구조로 동작한다. 하지만 이 개념을 여러 모듈로 쪼개어 구현하고 다양한 오픈소스를 사용하기 떄문에 설치가 까다롭고 구성이 복잡해보일 수 있다. 마스터-노드 구조 쿠버네티스는 전체 클러스터를 관리하는 마스터와 컨테이너가 배포되는 노드로 구성되어있다. 모든 명령은 마스터의 API 서버를 호출하고 노드는 마스터와 통신하면서 필요한 작업을 수행한다. 특정 노드의 컨테이너에 명령하거나 로그를 조회할 때도 노드에 직접 명령하는게 아니라 마스터에 명령을 내리고 마스터가 노드에 접속하여 대신 결과를 응답한다. Master 마스터 서버는 다양한 모듈이 확장성을 고려하여 기능별로 쪼개져 있는 것이 특징이
Kubernetes
kubernetes
쿠버네티스(Kubernetes)는 컨테이너화 된 애플리케이션의 대규모 배포, 스케일링 및 관리를 간편하게 만들어주는 오픈 소스 기반 컨테이너 오케스트레이션 도구이다. 프로덕션 환경에서는 애플리케이션을 실행하는 여러 컨테이너를 관리하고 다운타임이 없는지 확인해야하는데, Kubernetes는 다중 컨테이너 처리를 자동으로 처리하고, 분산 시스템을 탄력적으로 실행할 수 있는 프레임워크를 제공한다. K8s를 사용하면 애플리케이션의 확장 및 장애 조치를 처리하고 배포 패턴 등을 쉽게 처리할 수 있다. 쿠버네티스의 특징 5가지 1. 선언적 접근 방식 쿠버네티스에서는 동작을 지시하는 개념보다는 상태를 선언하는 개념을 주로 사용한다. 쿠버네티스는 원하는 상태(Desired state)와 현재의 상태(Current sta
ServiceDNS
dns
생성된 서비스의 IP는 어떻게 알 수 있을까? 서비스가 생성된 후 kubectl get svc를 이용하면 생성된 서비스와 IP를 받아올 수 있지만, 이는 서비스가 생성된 후이고, 계속해서 변경되는 임시 IP이다. DNS를 이용하는 방법 가장 쉬운 방법으로는 DNS 이름을 사용하는 방법이 있다. 서비스는 생성되면 [서비스 명].[네임스페이스명].svc.cluster.local 이라는 DNS 명으로 쿠버네티스 내부 DNS에 등록이 된다. 쿠버네티스 클러스터 내부에서는 이 DNS 명으로 서비스에 접근이 가능한데, 이때 DNS에서 리턴해주는 IP는 외부 IP (External IP)가 아니라 Cluster IP (내부 IP)이다. 간단한 테스트를 해보자. hello-node-svc 가 생성이 되었는데, 클러스터내의
PV & PVC
object
k8s에서 Volume을 사용하는 구조는 PV라고 하는 퍼시스턴트 볼륨(PersistentVolume)과 PVC라고 하는 퍼시스턴트 볼륨 클레임(PersistentVolumeClaim) 2개로 분리되어 있다. PV/PVC PV는 Persistent Volume의 약자이다. pod와는 별개로 관리되며 별도의 생명 주기가 있다. PVC는 사용자가 PV에 하는 요청이다. 사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등을 정해서 요청한다. k8s 볼륨을 pod에 직접 할당하는 방식이 아니라 중간에 PVC를 두어 pod와 pod가 사용할 스토리지를 분리할 수 있다. 이런 구조는 pod 각각의 상황에 맞게 다양한 스토리지를 사용할 수 있게 한다. 클라우드 서비스를 사용할 때는 본인이 사용
Pod
object
Pod는 동일한 실행환경에서 실행되는 애플리케이션 컨테이너와 볼륨으로 구성된 집합체다. 포드는 쿠버네티스 클러스터에서 배포 가능한 가장 작은 아티팩트(artipact)다. 즉, 포드에 있는 모든 컨테이너가 동일한 머신에 있음을 뜻한다. Pod에 있는 각 컨테이너는 각자의 cgroup을 운영하지만 몇가지 Linux 네임스페이스는 공유한다. Pod의 각 컨테이너는 각자의 cgroup 을 운영하지만 몇가지 리눅스 네임스페이스를 공유하며, 서로 다른 파드는 각 애플리케이션이 격리되어 있고 각기 다른 IP주소와 호스트네임을 갖는다. 또한 System V IPC나 POSIX 메시지 큐(IPC 네임스페이스)를 통해 기본 프로세스 간 통신 채널을 사용해 서로 통신할 수 있다. 동일한 노드에서 동작하는 서로 다른 Pod의
RollingUpdate
object
Rolling Update는 k8s의 업데이트 방법 중 하나로, 새로운 버전의 애플리케이션을 배포하고 기존 버전을 점진적으로 대체하는 과정으로 진행된다. 새로운 버전의 Pod로 트래픽이 전달되기 전까지 기존 버전이 유지되므로 무중단으로 애플리케이션을 업데이트 가능한 장점이 있다. 그러나 새로운 버전의 Pod와 기존 Pod가 함께 유지되는 기간이 존재하기 때문에 업데이트 중에 리소스를 더 사용할 수 있다. 기본적으로 Rolling Update는 다음과 같은 단계로 이뤄진다. 새로운 버전의 애플리케이션을 배포한다. 이때 기존 버전은 유지된 상태로 새로운 버전의 Pod가 함께 생성된다. 새로운 버전의 Pod가 정상적으로 동작하고, 준비 상태가 되면, 이전 버전의 Pod을 하나씩 종료한다. 이때 제거되는 Pod
Service와 port
object
쿠버네티스 환경에서 Service는 Pod들을 통해 실행되고 있는 애플리케이션을 네트워크에 노출(expose)시키는 가상의 컴포넌트다. 쿠버네티스 내부의 다양한 객체들이 애플리케이션과, 그리고 애플리케이션이 다른 외부의 애플리케이션이나 사용자와 연결될 수 있도록 도와주는 역할을 한다. 쿠버네티스에 Service가 있는 이유는, Pod들이 반영속적인 특성을 가지고 있기 때문이다. 쿠버네티스에서의 Pod는 무언가가 구동 중인 상태를 유지하기 위해 동원되는 일회성 자원으로 언제든 다른 노드로 옮겨지거나 삭제될 수 있다. 또한 Pod는 생성될 때마다 새로운 내부 IP를 받게 되므로, 이것만으로 클러스터 내/외부와의 통신을 계속 유지하기 어렵다. 따라서 쿠버네티스는 Pod가 외부와 통신할 수 있도록 클러스터 내부에서
ingress
object
인그레스(ingress)는 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리한다. 인그레스는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅을 제공할 수 있다. 인그레스는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출한다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다. 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. 인그레스 컨트롤러는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. 인그레
가상 IP와 서비스 프록시
개념
쿠버네티스 클러스터의 모든 노드는 kube-proxy를 실행한다. kube-proxy는 ExternalName 이외의 유형의 서비스에 대한 “가상 IP”의 역할을 한다. service를 조회했을때 나오는 cluster IP가 바로 k8s의 프록시로 만들어진 가상 IP이다. 이 IP는 k8s 내부에서만 접근할 수 있다. 쿠버네티스에서 가상 IP를 사용하는 이유 쿠버네티스가 프록시를 통해 가상 IP를 만드는 이유는, 실제 IP와 DNS를 사용하기 부적절하기 때문이다. k8s의 서비스 객체는 IP를 할당할 수 있는 기기가 아니고 잠시 생겼다가 사라질 수 있는 유한한 존재이다. 하지만 서비스를 식별하고 호출할 수 있는 무언가가 필요하기 때문에 그 방법으로서 프록시로 만든 가상 IP를 사용하는 것이다. ku
사이드카 패턴
개념
사이드카 패턴이란 쿠버네티스와 같이 컨테이너 오케스트레이션 툴에서 구성할 수 있는 컨테이너 배치 패턴으로, 마치 오토바이 옆에 붙어 있는 사이드카와 비슷한 형태이다. 장점 1. 기존 로직의 변경 없이 기능 추가 사이드카 컨테이너를 통해 기존의 로직은 그대로 놔둔체 새로운 기능을 덧붙일 수 있다. 예를 들어 기존 http 프로토콜에 대해서만 서비스를 하는 웹서버에 tls layer를 추가하고 싶은 경우, 메인 컨테이너인 기존의 legacy 웹서버는 그대로 놔둔체 사이드카 컨테이너를 통해 https 서비스를 클라이언트에게 제공할 수 있다. 2. 컨테이너 재사용성 사이드카 컨테이너를 단일한 기능을 하게 모듈화하면 다른 곳에서 재사용하기 수월해진다. 대부분의 app에서는 로깅, 실행 프로세스 정보 확인 등의
OIDC Authentication with Dex
auth
OIDC (Open ID Connect) 인증 방법은 OAuth2 위에서 동작하는 인증으로, Github이나 Google과 같이 서드 파티에서 부여받은 OAuth 권한을 통해 쿠버네티스의 인증을 수행한다. 기존에 사용하던 OAuth 인증 방법을 쿠버네티스에 그대로 가져온다고 생각하면 이해하기 쉽다. OIDC 인증 방법은 OAuth + JWT 토큰을 사용한다는 점에서 Webhook Token 인증 방법과 차이점을 갖는다. OAuth 토큰을 관리하기 위한 중간 서버를 구현한 Dex를 사용하여 OIDC 인증을 구현해보자. Dex Concept Dex는 서드 파티로부터 OAuth 인증 토큰을 가져와 관리하는 인증 도구이다. OAuth를 사용하기 위해 반드시 Dex를 써야 하는 것은 아니지만, Dex는 OAuth 서
Token Webhook with Guard
auth
Webhook 서버에 인증 데이터를 전달한 뒤, 클라이언트가 유효한지 인증하여 Third party에 권한을 부여하는 Webhook Token 인증 방법에 대해 알아보자. 사용자는 미리 인증 데이터를 발급받아 놓고, 사용자가 인증 데이터를 Bearer 헤더에 담아서 REST API 요청을 보내면 API 서버는 클라이언트가 유효한지를 검증하기 위해 Webhook 서버에 인증 데이터를 전달한다. Webhook 서버는 해당 데이터를 검사한 뒤, 인증 여부를 API 서버에 반환하는 간단한 방식으로 되어 있다 Token Webhook, OIDC 중 어느 방법을 선택하든지에 상관 없이 클라이언트는 HTTP의 Bearer 헤더에 인증 데이터를 담아서 보내기만 하면 된다. 클라이언트는 인증 방법이 무엇인지 알 필요가
k8s 클러스터 root CA를 통한 사용자 인증
auth
k8s는 기본적으로 root CA 인증서를 스스로 발급해 사용한다. 이 인증서를 이용하면 별도의 Third-party 연동 없이도 User와 Group을 사용할 수 있다. 단, 이 방법은 여러모로 한계점이 많기 때문에 가능하면 사용하지 않는 것이 좋다. 인증서가 유출되었을 때 revoke가 힘들기도 하고, 파일 단위로 인증 정보를 관리하는 것은 매우 비효율적이고 보안에 취약하기 때문이다. 따라서 k8s는 인증서 발급을 통한 사용자 인증은 극히 제한된 경우에만 사용하고 있다. 대표적으로는 관리자 권한을 가져야 하는 system:master 그룹의 인증 정보를 생성한다거나 (/etc/kubernetes/admin.conf), k8s의 핵심 컴포넌트에 인증서를 발급한다거나 할 때가 이에 해당한다. 우선, k8s는
datadog
datadog
💡 APM, log, Infrastructure를 통합적으로 모니터링·관리하는 클라우드 모니터링 솔루션 여러 클라우드 환경에 나뉘어있는 리소스들을 통합적으로 모니터링 가능하다. 클라우드의 상태를 지속적으로 감시하여 예기치 못한 상황과 오류를 대비, 대응할 수 있다. 장점 에러를 빠르게 확인하여 신속한 대응 가능 애플리케이션 정보(log, query 등) 축적하여 데이터 기반 개선 개발자, 운영팀, 비즈니스 유저간 긴밀한 협업 다양한 언어과 환경을 지원하기 때문에, 원하는 애플리케이션에 확장 가능 커스텀 대시보드 생성 가능 공식 문서가 친절함 단점 비용이 많이 든다. 기능이 많아서 실무에 도입하기 위해 사전 지식이 필요함. Datadog의 주요기능 Integrations 여러가지 서비
datadog APM 기능 사용하기
datadog
서버에 datadog agent를 설치하면 CPU 점유율, Memory, Disk사용량 등의 중요한 성능 정보를 모니터링할 수 있다. 하지만 애플리케이션의 전반적인 LifeCycle에 대한 리포트 (ex: GC, JVM, I/O 등)를 바탕으로 에러나 병목현상에 더 빠르게 대응할 수 있도록 하고싶다면 Datadog APM을 연결해야한다. APM 이란? Application Performance Monitoring 의 약자로 구동 중인 애플리케이션의 대한 성능측정과 에러탐지 등, 전반적인 애플리케이션 라이프사이클의 정보를 수집해 모니터링할 수 있게 해준다. 보다 편리성을 위해서 다양하게 시각화한 Metrics, 그리고 API 테스트도 지원한다. 여러 대의 애플리케이션에 설치가 가능하며 이를 한꺼번에 같은 UI
ElasticSearch 검색 명령어
elk
Elasicsearch 검색 명령어 클러스터 상태 (Health) 클러스터가 어떻게 진행되고 있는지 기본적인 확인 클러스터 상태를 확인하기 위해 _cat API를 사용 curl를 사용하여 수행 가능 -노드 정보: GET /_cat/nodes?v 상태 정보 : GET /_cat/health?v Elasticsearch에서 _언더바가 붙은 것들이 API v는 상세하게 보여달라는 의미 녹색 : 모든 것이 정상 동작 노란색 : 모든 데이터를 사용 가능하지만 일부 복제본은 아직 할당되지 않음(클러스터는 완전히 동작) 빨간색 : 어떤 이유로든 일부 데이터를 사용 불가능(클러스터가 부분적으로만 동작) 데이터베이스(index)가 가진 데이터 확인하기 index는 일반 RDB에서의 DB 역할 모든 인덱스 항목을
Elastic Search
elk
확장성이 뛰어난 오픈 소스 전체 텍스트 검색 및 분석 엔진 대량의 데이터를 신속하고 거의 실시간으로 저장, 검색 및 분석 일반적으로 복잡한 검색 기능과 요구 사항이 있는 응용 프로그램을 구동하는 기본 엔진 / 기술 핵심 개념 Near Realtime (NRT) Elastic Search는 거의 실시간 검색 플랫폼 문서를 색인할 때부터 검색 기능할 때까지 약간의 대기시간(일반적으로 1초)이 매우 짧음 클러스터(Cluster) 전체 데이터를 함께 보유하고 모든 노드에서 연합 인덱싱 및 검색 기능을 제공하는 하나 이상의 노드(서버) 모음 -노드의 그룹이라고 생각 클러스터는 기본적으로 elasticsearch 라는 고유한 이름으로 식별 이 이름은 노드가 이름으로 클러스터에 참여하도록 설정된 경우 노드가
Logstash
elk
Logstash는 실시간 파이프라인 기능을 가진 데이터 수집 엔진 오픈소스이다. Logstash는 서로 다른 소스의 데이터를 동적으로 통합하고 원하는 대상으로 데이터를 정규화 할 수 있는 능력을 가진다. 다양한 입력과 필터 및 출력 플러그인을 통해, 모든 유형의 이벤트를 보강하고 변환할 수 있으며, 많은 기본 코텍이 처리 과정을 단순화한다. 따라서 Logstash는 더 많은 양과 다양한 데이터를 활용하여 통찰력 있게 볼 수 있게 해 준다. Logtash 파이프라인 Logstash의 전체적인 파이프라인에는 INPUTS과 FILTERS, 그리고 OUTPUT이 있다. 이 중에서 2가지의 필수적인 요소는 INPUTS과 OUTPUTS이고, 파싱 여부에 따라 필터는 선택적으로 사용이 가능하다. Logstash.ym
리버스 프록시
nginx
클라이언트 요청을 대신 받아 내부 서버로 전달해주는 것을 리버스 프록시(Reverse Proxy)라고 한다. 리버스 프록시가 필요한 이유 로드 밸런싱 : Nginx는 클라이언트의 요청을 프록시 서버에 분산하기 위해 로드 밸런싱을 수행하여 성능, 확장성 및 신뢰성을 향상시킬 수 있다. 캐싱 : Nginx를 역방향 프록시로 사용하면 미리 렌더링된 버전의 페이지를 캐시하여 페이지 로드 시간을 단축할 수 있다. 서버의 응답에서 수신한 콘텐츠를 캐싱하고 이 콘텐츠를 사용하여 매번 동일한 콘텐츠를 프록시 서버에 연결할 필요 없이 클라이언트에 응답하는 방식으로 구현하는게 가능해진다. SSL 터미네이션 : Nginx는 클라이언트와의 연결에 대한 SSL endpoint 역할을 할 수 있다. 압축 : 프록시 서
GPG
tools
GPG(GNU Privacy Cuard)는 GNU에서 제공하는 OpenPGP(RFC4880)의 오픈소스 구현이다. PGP란? 메시지나 파일을 암호화하여 전송할 수 있는 툴이나 소스를 배포하는 각종 프로그램의 변조 유무를 검사할 수 있는 프로그램이다. 누군가 악의적인 목적으로 소스에 해킹툴이나 바이러스를 내포하여 원본과 다른 소스를 배포할 수 있는데, 배포자의 서명과 서명된 파일을 제공하여 소스에 대한 무결성 검사를 할 수 있도록 한다. 메일이나 중요한 데이터에 대해 서명과 함께 전송함으로써 허가된 사용자만 해당 데이터를 볼 수 있는 권한을 부여할 수 있다. 보안 메일, 전자 서명 시스템에서 응용 가능하다. 정리하자면 GPG(PGP)는 개인간, 머신간 또는 개인 머신간에 교환되는 메시지나 파일을 암호화 하
Keycloak
tools
Keycloak은 ID 및 액세스 관리 솔루션을 제공하고, 인증(Authentication)과 인가(Authorization)을 쉽게 해주고 SSO(Single-Sign-On)을 가능하게 해주는 오픈소스이다. SSO란? SSO는 Single-Sign-On의 약자로 한번의 로그인을 통해 그와 연결된 여러가지 다른 사이트들을 자동으로 접속하여 이용할 수 있도록 하는 방법이다. 일반적으로는 여러 사이트를 사용할 떄 각각의 DB에 각각의 사용자 정보가 있고 그 정보를 통해서 관리를 하게 되는데, 필요에 따라서는 사용자 정보를 연동하여 사용해야 하는 경우가 발생한다. 이런 경우에 SSO 기능을 사용하게 되며 하나의 시스템에서 인증을 할 경우 그와 연결된 다른 시스템에서는 인증 정보가 있는지 없는지를 확인하여 이후 처
데브옵스
devops
DevOps는 development와 operations가 합쳐진 단어이며, 소프트웨어 개발과 배포 프로세스를 자동화하고 통합하는 개발방법론, 철학이다. 팀 지원, 팀 간 커뮤니케이션 및 공동 작업, 기술 자동화를 강조한다. DevOps는 소프트웨어 제공 프로세스를 효율적으로 수행하는 것을 목표로 한다. 이를 위해 워크플로를 자동화하고 신속하게 피드백하여 프로젝트를 더 잘 제어할 수 있도록 하는 여러 방법을 사용한다. DevOps 문화 철학 DevOps에서는 개발과 운영이라는 두 팀간의 장벽을 없애 개발자의 생산성과 운영의 안정성을 모두 최적화한다. 두 팀은 자주 소통하고, 효율성을 높이고, 고객에게 제공하는 서비스의 품질을 향상하기 위해 최선을 다한다. 최종 고객의 요구와 자신이 어떻게 이러한 요구를 해