devops

Producer 카프카의 토픽은 병렬처리가 가능하기 위해서 파티션으로 나뉘어, 최소 하나 이상의 파티션으로 구성된다. 그리고 프로듀서가 카프카로 전송한 메시지는 토픽 내 각 파티션의 로그 세그먼트에 저장된다. 그래서, 프로듀서는 토픽으로 보낼 때 토픽의 어느 파티션으로 메시지를 보내야할 지 결정해야하고 이 때 사용하는 것이 '파티셔너(Partitioner)'다. 그래서 파티션의 증가에 따라 관리자의 의도와 다르게 메시지 전송이 이뤄질 수 있기 때문에 되도록 파티션 수를 변경하지 않는 것이 좋다. 파티셔닝 방법 2가지 레코드들은 배치 처리를 위해서 프로듀서의 버퍼 메모리 영역에서 잠시 대기한 후에 카프카로 전송된다. 이 때 크게 두가지전략을 고려할 수 있다. 1) 라운드 로빈 전략 키 값을 지정하지 않은 ..

Producer와 Consumer는 Python으로 테스트, Broker와 Zookeeper는 Docker로 올려본다. 서버를 EC2로 올리는 건 비용이 들기 때문에 간단한 테스트용으로 추천한다. (Confluent-Kafka는 개발이 활발하고 다른 버전들보다 여러면에서 스펙이 가장 뛰어나기 때문에 Confluent버전을 사용함) 1) Confluent-kafka 설치 $ pip install confluent-kafka (consumer와 producer 어플리케이션을 위해) 2) Broker와 Zookeeper docker-compose로 올리기 # docker-compose.yml --- version: '3' services: zookeeper: image: confluentinc/cp-zooke..

여러 곳을 찾아봐도 깔끔하게 개념을 이해할 수 있는 정리된 자료가 없어서 직접 정리해보려고 한다. kafka는 높은 처리량과 가용성, 확장성을 지니고 있지만, 의외로 구조는 간단하기 때문에 쉽게 이해할 수 있으리라 생각함. 카프카를 구성하는 주요 요소들 1) 주키퍼(Zookeeper) 카프카의 메타데이터를 관리하고 브로커의 health check를 담당하는 역할을 한다. 주키퍼는 여러 대의 서버를 클러스터로 구성한다. 그래서 살아 있는 노드가 과반수 이상이면 유지될 수 있다. 그래서 홀수로 구성되어야 한다. Znode를 통해서 카프카의 메타정보가 주키퍼에 기록된다. 주키퍼는 지노드를 이용하여 브로커의 노드 관리부터, 토픽과 컨트롤러를 모두 관리할 수 있다. 2) 카프카(Kafka) 카프카 클러스터(Clu..

the ecs service cannot be updated due to an unexpected error: TaskDefinition is inactive CodeDeploy로 ECS Blue-Green Service를 생성해서 테스트하는 와중에 발견한 에러다. Codebuild에서부터 Deploy까지 taskdef.json 파일도 Copy했는데 TaskDefinition이 비활성화되었다는 에러가 뜬다. taskdef.json 파일이 없는게 아니라, 설정에 문제가 발생했다는 의미다. 그래서 ECS Cluster를 통해서 Task를 실행하면 문제가 없지만, Codedeploy 혹은 Codepipeline을 통해서 서비스가 작동하면 문제가 발생한다. (taskdefinition 관련 설정이 실행되기 때문..

Dockerfile을 이용해서 이미지를 빌드하다 보면 최종 컨테이너 이미지에 필요 없는 환경과 파일이 포함될 수 있다. 이를 해결하기 위해서 빌드와 실행을 구분해 이미지를 빌드할 수 있는 'Multi-stage build' 기능을 이용하면 된다. 위처럼 빌드를 통해서 text 파일이 생성되면, 이 파일만 이용해서 내용을 추가하고 최종 스테이지에선 필요한 파일만 사용할 수 있게 된다. # syntax=docker/dockerfile:1 FROM golang:1.16 AS builder WORKDIR /go/src/github.com/alexellis/href-counter/ RUN go get -d -v golang.org/x/net/html COPY app.go ./ RUN CGO_ENABLED=0 go..

개발을 위해서 용도와 목적에 따라 여러 Account를 활용해서 AWS 리소스를 사용한다. AWS CodePipeline은 일련의 CI/CD 과정을 통합한 서비스로, 운영 Account에서 여러 Account들의 CI/CD를 관리할 수 있어야 한다. 이 포스팅에서는 운영 Account에서 소스코드를 받아 빌드하여 Artifact를 S3에 보관하는 것을 진행하고, 나머지 CodeDeploy만 다른 Account에서 배포하는 아키텍처를 구성해봤다. 이를 위해 Account, 리소스 간 연결을 위한 Role 생성과 리소스의 데이터 보호에 사용되는 KMS를 통해서 AccountA의 CodePipeline을 중심으로 AccountB, AccountC에 배포할 수 있는 위 아키텍처를 구성한다. 2. 구성방법 2.1..

Controller node에서 managed node 관리에 유용하게 사용할 수 있는 명령어 정리 (1) 실행 명령어 $ ansible [host 명] -m [모듈명] -a [Argument] (2) 옵션 -i : ansible 실행 시 사용할 인벤토리 지정 (Inventory) -l : 그룹, 호스트 지정 (Limit.subset) -m : 사용할 모듈 지정 (Module) -a : 실행할 모듈의 인자값 (Argument) -e : 추가적으로 사용할 변수 (Extra_vars) 1. managed node 디스크 용량 확인 $ ansible all -m shell -a "df -Th" 2. managed node 메모리 확인 $ ansible all -m shell -a "free -h" 3. con..

Ansible을 사용하다보면, 빈번히 삭제되고 생성되는 EC2 인벤토리를 정의하는 것이 쉽지않다. 그러나 Ansible Plugin을 활용해서 Dynamic Inventory를 활용하면 구성된 EC2를 자동으로 인벤토리에 할당하기 때문에 아주 간편하다. 기본적으로 Managed node를 관리하는 Controller node에 다음과 같은 기본설정이 필요하다. Controller node - AmazonEC2FullAccess 권한 - Managed node와 통신을 위한 키페어(.pem) - python과 boto설치 Managed node - 조회 시 사용될 tag를 설정한다. - ssh Port가 열려있어야한다. (Ansible은 ssh 프로토콜을 통해서 통신) Dynamic Inventory 생성..

지금까지 Terraform을 통해서 클라우드 인프라 리소스를 생성하고 관리했다. 그러나 Terraform은 사실상 클라우드 아키텍처를 구성하거나, 새로 생성, 변경하는데 효율적인 인프라 관리 도구다. 생성하고 나서부터, 동작 중인 서버를 효율적으로 관리, 운영하는데 사용될 수 있다. 물론 Terraform과 동일한 기능이 있으나, 이미 생성된 인프라에 application을 구성하고 배포, 관리하는데 아주 효과적이다. 그래서 Terraform과 Ansible은 통합되어 상호보완적으로 활용될 수 있다고 생각한다. Ansible Ansible은 크게 Control Node와 Managed Node로 나뉜다. Python 베이스로 작동하며, Control과 Managed Node 모두 Python이 기본적으로..

DevOps, SRE의 정의에 대해서 간단히 알아보자. DevOps(Development + Operations) 데브옵스는 전체적인 개발 사이클을 빠르게 하고자 하는 소프트웨어 개발 접근방법이다. Continuous delivery이 가능하게 하며, 빈번한 release와 자동화된 소프트웨어와 앱 개발이 가능하도록 하는데 초점을 둔다. 그래서 업무의 빠른 flow가 가능하게 된다. 데브옵스 프로세스의 주요 목표는 프로덕트의 출시를 가속화 소프트웨어의 개발 라이프사이클 단축화 시장 니즈에 빠른 대응 그래서 development와 operation의 융합이자, 코드를 가능한 부드럽고 빠르게 배포될 수 있도록 하는 팀을 의미하기도 한다. 팀은 개발과 운영을 위해 원활한 소통이 요구되며 높은 수준의 자동화를 ..