컴맹 : 진화의 시작

클러스터를 생성할 때 함께 만든 슈퍼계정 이름을 변경하는 방법을 기술합니다. 우선, 계정 이름을 변경하는 쿼리는 다음과 같고 슈퍼계정 권한이 있어야만 실행할 수 있습니다. ( 기존 계정 이름이 admin이고 이를 sysadmin으로 변경하겠다는 예제입니다 ) alter user admin rename to sysadmin; 하지만 위에 쿼리를 실행하면 아래와 같은 에러를 만나게 됩니다. 현재 접속한 계정의 이름을 변경할 수 없다는 내용입니다. 이 상태에서 우리가 선택할 수 있는 방법은 1) 임시 계정(tempadmin)을 추가로 2) 임시 계정에 슈퍼계정 권한을 줍니다 3) 임시 계정으로 접속해서 기존 계정(admin)의 이름을 변경해줍니다 4) 그리고 다시 변경된 이름(sysadmin)으로 접속해서 임..

작은 프로젝트를 진행할 때도 메시지 브로커는 아키텍처에 따라 필요한 경우가 종종 있습니다. 이때 Apache kafka를 쓰자니 배보다 배꼽이 커지고, 클라우드의 메시지 큐(AWS SQS 등)를 사용하자니 벤더 락인(vendor lock-in)이 우려될 때 Redis stream은 아주 좋은 대안이 됩니다. 혹시 kafka를 redis pub/sub과 비교하려 한다면 정확한 비교가 안되는데 토픽 개념은 유사하지만 redis pub/sub에는 소비자 그룹의 개념이 없기 때문입니다. ( stream에서 xread의 경우에는 소비자 그룹을 사용하지 않습니다. xgroupread로 접근하는게 맞습니다. 소비자 그룹의 개념이 들어가면서 메시지가 잘 도착했는지 확인이 가능합니다. 혹시 메시지 전달의 성공/실패/처리..

macOS에서 docker를 사용하기 위해 그간 Docker Desktop을 사용해왔었는데 유료화 소식이 전해져 왔다. Docker Desktop은 개인은 무료, 기업은 직원이 250명 이상이거나 연매출이 대략 110억($10 million) 이상인 경우 유료 버전을 사용해야 한다 (아직 유예기간 있음). https://www.docker.com/blog/updating-product-subscriptions/ Docker is Updating and Extending Our Product Subscriptions - Docker Blog Learn from Docker experts to simplify and advance your app development and management with Do..

redis를 사용하면서 필요에 의해 CONFIG SET을 통해 설정을 변경하는 경우가 있습니다. 아마 처음 config set을 검색했을 때 목적은 notify-keyspace-events 변경을 통해 key expire에 대한 이벤트를 받기 위해서가 많을 듯합니다. notify-keyspace-events 변경은 아래 페이지에 자세히 설명되어 있습니다. https://redis.io/topics/notifications Redis Keyspace Notifications – Redis *Redis Keyspace Notifications IMPORTANT Keyspace notifications is a feature available since 2.8.0 *Feature overview Keyspac..

키보드 자판 위에 vim 단축키를 나타내는 이미지가 돌아다니지만 입문자 입장에서 보기 어렵지 않을까 싶은 생각에 입문자용 핵심 단축키 정리를 마음먹었다. 아래 이미지를 보시라. 한글 버전판도 있지만, 입문자에게 이게 다 무슨 소리인가 싶지 않겠냐는 거다. 우주선 조종 기판 같다. 나는 개발 커리어를 리눅스 커널로 시작해서 약 7년간 vim으로만 개발을 해왔으면 이후에도 IntelliJ에 vim 플러그인을 이용하는 등 광적으로 vim을 사랑하는 유저이다. 지금이야 순정이 좋지!라는 마음으로 웬만하면 IDE는 그냥 플러그인 없이 순정으로 이용하는 편이지만. 아무튼 각설하고 vim을 처음 입문하는 사람에게 실제로 도움이 될만한 단축키를 설명하도록 한다. 본문에 있는 단축키는 모두 완벽하게 손으로 익혀주는게 좋..

scrapy는 웹사이트에서 필요한 데이터를 추출하는 오픈소스 프레임워크입니다. 네, 많고 많은 crawler 중에 하나입니다. 혹시 듣보잡 아니냐고요? 네, 뭐 구글 트렌드로 다른 크롤러와 비교해보면 크게 뒤떨어지는 건 사실입니다. (지난 5년간 대한민국 기준 트렌드 자료입니다. 파란색이 selenium, 노란색이 beautifulsoup, 빨간색이 scrapy) GitHub에 Star를 인기의 척도라고 본다면 scrapy는 상당히 인기 있는 프레임워크로 볼 수 있습니다. 이 말인즉, 개발자에게는 꽤나 인기 있는 크롤러라는 겁니다. 아래를 보세요. 스타 수가 무려 41.1k 개고 아직도 활발히 개발되고 있습니다. scrapy는 가볍고, 빠르고, 확장성이 좋습니다. 개발자는 파이썬 기반으로 spider라고..

앞서 docker-compose를 통해 airflow를 심플하게 설치하는 방법에 대해서 다뤄봤습니다. 스터디, 혹은 가벼운 인프라에서 사용되는 목적이라면 기본 설치된 airflow 환경으로 충분합니다. 하지만 조금 더 묵직한 환경에서 운영이 되어야 한다면 튜닝이 필수인데요, 튜닝에 어떤 것들이 있는지 살펴보도록 하겠습니다. # concurrency, max_active_runs 아마도 튜닝의 첫 단계가 아닐까 싶습니다. airflow의 목적은 병렬로 다수의 task를 운영하는 것이기 때문에 concurrency, max_active_runs 옵션은 제일 먼저 손봐줘야 하는 부분이 될 겁니다. 각각이 나타내는 의미는 아래 그림에서 가장 잘 표현되어 있습니다. 이 이상의 설명은 존재할 수 없을 듯. 설정은 ..

이전 글에서 Airflow란 무엇인지 알아봤습니다. 이번 글에서는 플랫폼을 구축해보고 기본적인 터미널 명령어를 살펴보도록 하겠습니다. 위에 그림에 있는 것처럼 airflow를 구축하기 위해서는 webserver, scheduler, worker, database까지 함께 움직이는 서비스가 많습니다. 이것들이 조합되면 airflow라고 하는 워크플로 플랫폼이 완성되는 겁니다. 여기 있는 서비스를 하나씩 설치하면서 고생하기에는 우리의 시간이 넉넉하지 않죠? 이번 글은 airflow를 제일 빠르고 간편한 방법으로 만날 수 있는 docker-compose를 통한 설치 방법을 알아봅니다. # docker로 airflow 설치 airflow를 운영하려는 환경에 docker-compose가 설치되어 있는지, 설치되어..

Airflow는 Airbnb에서 2014년 10월 시작된 오픈소스 프로젝트입니다. 오픈소스로 2015년 6월 발표되었으며 2016년 3월에 Apache Software Foundation에 인큐베이팅되었어요. 그리고 2019년 1월 아파치 재단은 Apache Airflow를 탑티어 프로젝트로 발표했습니다. 자, 그럼 Airflow가 무엇인지 천천히 살펴보도록 하겠습니다. airflow는 workflow를 구축하고 실행할 수 있는 하나의 플랫폼입니다. 워크플로라는 단어가 모든 것을 설명해주는데요, airflow에서 워크플로는 DAG(Directed Acyclic Graph)으로 표시되며 세부사항으로는 개별 작업을 포함해서 종속성 및 데이터 흐름을 정렬하게 됩니다. 이게 다 무슨 소리인가 싶을 수 있는데요...

AWS에서 EC2를 제 돈 주고 쓰면 많이 손해입니다. 비용을 절약할 수 있는 몇 가지 방법이 있는데요, SP (Savings Plans) RI (Reserved Instances) Spot 이렇게 기본적으로 세 가지를 언급할 수 있겠습니다. 이번 글에서는 Spot의 설명은 아니고, 그래서 얼마나 할인되는데? 에 대한 이야기를 해보려고 합니다. 위에 그림에서 보여지듯이 Spot Instance 가격은 c5.large 기준으로 리전 별로 차이는 보이지만 최대 64%까지 할인되는 것을 볼 수 있습니다. 한 달이면 $44 차이까지 발생하죠. 이런 인스턴스 열 대를 운영하면 $440입니다. 절대 무시할 수 있는 수준이 아닙니다. 위에 표를 볼 수 있는 경로는 EC2 -> INSTANCES -> Spot Requ..

AWS에서 선택 가능한 EC2 인스턴스 타입은 범용, 컴퓨팅 최적화, 메모리 최적화, 가속화된 컴퓨팅, 스토리지 최적화로 나눌 수 있습니다. 이번 글에서는 범용 타입에서도 버스터 가능한 인스턴스 타입을 소개합니다. 버스트(burst) 가능한 인스턴스 타입은 현재(2021-05-06) 기준으로 T2, T3, T3a, T4g 네 가지 타입이 존재하고 각각의 타입은 CPU와 메모리에 따라서 nano, micro, small, medium, large, xlarge, 2xlarge로 나누어집니다. T 타입 인스턴스에는 CPU credits이라는 개념이 존재하는데 CPU 유휴시간에 따라 credits을 획득하고, CPU가 사용되면 사용률에 따라 획득한 크레딧을 소모하게 되는 구조입니다. 이 의미를 상세히 이해하기..

ECS 클러스터 안에 서비스를 등록할 때 선택하게 되는 Service type에 대해서 살펴보겠습니다. 먼저 옆에 i 아이콘에 마우스를 올려서 팝업 도움말을 살펴보면 다음과 같은 문구를 볼 수 있습니다. Replica services place and maintain a desired number of tasks across your cluster. Daemon services place and maintain one copy of your task on each container instance. If a capacity provider strategy is used, the DAEMON service type is not supported. 위의 내용은 아래와 같이 정리하고 사용할 수 있습니다 # R..

SQLAlchemy는 애플리케이션 개발자에게 SQL의 모든 기능과 유연성을 제공하는 Python SQL 툴킷 및 객체 관계형 매퍼입니다 (공식 홈페이지 소개 문구). 모든 데이터베이스 객체를 다룰 때 신경 써야 하는 부분이 트랜잭션(Transaction)인데 SQLAlchemy도 예외는 아닙니다. 공식 홈페이지의 예제를 통해 기본적인 트랜잭션 관리를 살펴봅시다. from sqlalchemy import create_engine from sqlalchemy.orm import sessionmaker # an Engine, which the Session will use for connection # resources engine = create_engine('postgresql://scott:tiger@l..

컨테이너와 컨테이너 인스턴스라는 용어로 본문에 많이 등장합니다. 컨테이너 인스턴스는 클러스터에 묶여있는 EC2 인스턴스를 나타냅니다. 표준 표현을 따르다 보니 본문을 읽는데 어려움이 있을 수 있습니다. 이번 글에서는 Task, Container에 CPU와 Memory 설정에 대해 알아봅니다. ECS를 처음 접하면 리소스를 설정하는 곳이 너무 많아서 정신이 혼미해질 정도인데요, 추려보면 다음과 같습니다. 인스턴스의 CPU, Memory 설정 (인스턴스 타입에 따라 고정, 혹은 custom 사용) task의 CPU, Memory 설정 container의 CPU, Memory 설정 위에서 아래로 갈수록 작은 개념으로 이어집니다. 직감적으로 보면 container는 task 안에서 돌기 때문에 당연히 task에..

ECS를 구축, 관리하기 위해서는 그 안에서 사용되는 용어를 이해해야 합니다. 이번 글에서 ECS에서 통용되는 용어들의 개념을 이해하도록 합니다. 자원 개념 위에서 아래로 내려갈수록 큰 개념으로 생각하시면 됩니다. container는 ECS에서 가장 작은 단위, cluster가 가장 큰 단위입니다. # container 단순히 시야가 제한된 리눅스 프로세스입니다. namespace 분리로 컨테이너 환경 안에서 호스트의 프로세스 목록을 볼 수 없고, 루트 디렉터리 변경으로 호스트의 디렉터리를 볼 수 없도록 제한합니다. (chroot) 끝으로 제어 그룹을 통해 컨테이너가 접근할 수 있는 자원을 제어합니다. (control group) 우리가 알고 있는 바로 그 컨테이너의 원리죠? # task definiti..

본문을 읽기 전에 Zombie, Orphan 프로세스란 무엇인지 알고 있을 필요가 있다. 관련된 내용은 다음 글에 매우 잘 정리가 되어 있으니 참고하기 바란다. - Zombie process reaping 에 대하여, Container에서 고려할 부분들 컨테이너를 생성할 때 한 개의 일만 처리하게 설계하면 좋겠지만 그렇지 못한 경우도 분명 생길 수 있다. 간혹 자식(child process)을 만들어서 일을 시켜야 하는 경우가 있는데 새로운 컨테이너를 생성하거나 API 통신으로 동작시키는 것보다 나은 상황이 있기 때문이다. 아무튼, 이렇게 자식 프로세스를 만들어서 일을 시켜보면 의도치 않게 자식이 고아가 되는 경우가 발생한다. 자식의 자식의 자식 이라던가... 뭐 물론 좋은 설계는 아니지만. 이런 경우가..

이번 글에서는 AWS에서 제공하는 대표적인 컨테이너 서비스 중 하나인 ECS의 기본 개념을 살펴보도록 합니다. ECS는 쿠버네티스 기반의 완전 관리형 컨테이너 오케스트레이션인 AWS EKS(Elastic Kubernetes Service), 그리고 옆동네 GCP의 GKE(Google Kubernetes Engine)와 비교할 수 있는데요, 여기서는 ECS에 초점을 맞춰서 설명합니다. ECS는 완전 관리형 컨테이너 오케스트레이션 서비스 입니다. 컨테이너와 오케스트레이션을 이해하기 위해 기존 서비스 방식을 살펴보면 다음과 같습니다. 애플리케이션을 인스턴스에 직접 설치해서 운영 진입 장벽이 낮아서 빠르게 애플리케이션을 개발&검증하는데 유리합니다 한편, 컴퓨팅 리소스의 수평확장(scale-out)을 위해 애플리..

providers, resource, data, module 등을 묶어서 뭐라고 표현해야 할지 잘 모르겠습니다. 예약어, 키워드 등으로 볼 수 있을 텐데 여기서는 키워드라고 통칭하도록 합니다. 이번 글에서는 테라폼에서 통용되는 키워드를 하나씩 살펴보도록 합니다. # providers 테라폼은 docker, AWS, GCP 등 2021년 02월 기준으로 700개가 넘는 다양한 프로바이더를 제공합니다. 그중 핵심이 되는 것은 아래처럼 퍼블릭 클라우드와 쿠버네티스입니다. 이런 프로바이더를 providers 블록을 통해 선언하고 사용할 수 있습니다. 더 많은 정보는 다음 링크를 참고하세요. https://registry.terraform.io/browse/providers # resource resource는 ..

이번 글에서는 테라폼에서 통용되는 주요 키워드를 통해 테라폼을 이해하도록 합니다. 테라폼은 크게 configure, plan, apply 세 가지의 단계가 있습니다. 풀어서 보자면 설정(configure)하고 실행 계획(plan)을 살펴본 후에 배포(apply)하는 구조입니다. 실행 계획이라고 하면 SQL에서 explain을 생각하면 되고 apply는 배포에서 일반적으로 사용되는 deploy 키워드를 생각하면 됩니다. 여러 팀원이 인프라를 같이 만지더라도 VCS에 의해 인프라가 관리되기 때문에 충돌을 피해 갈 수 있습니다. 이로 인해 서비스 가용성을 보장받을 수 있습니다. 사실 여러 사람이 동시에 같은 인프라를 만지는 상황 자체가 정상은 아니지만 말입니다. configure 설정은 HLC(Hashicor..

인프라가 복잡하고 특히 development, staging, production 환경을 분리해서 사용하는 회사라면 IaC 도입이 필수입니다. 테라폼은 hashicorp에서 개발된 인프라 스트럭처를 효율적으로 구축, 변경, 관리하기 위한 도구(IaC)입니다. hashicorp은 한국에서 하시코프로 많이 통용됩니다. 앞에 hash를 보고 해시콥 이라고 읽어도 적당히 대화는 되지요도입 이후 기대되는 내용은 다음과 같습니다. # pros 인프라 변화 과정, 히스토리를 사용 중인 버전 관리 시스템(VCS)을 통해 형상관리할 수 있게 됩니다 인프라를 코드로 관리하면 애플리케이션을 형상관리 했을 때와 완벽하게 동일한 이점을 갖게 됩니다 누가, 언제, 왜 인프라를 변경 했는지 확인할 수 있고, 애플리케이션 코드를 리..