컴맹 : 진화의 시작

개인 블로그에 재직하는 회사와 관련된 글을 작성하는 건 언제나 그렇듯 조심스럽습니다. 이 글은 애드테크 기반 모바일 퍼포먼스 마케팅 회사 '매드업'에 합류한 과정과 맡은 업무, 회사를 소개하고 있습니다. 본인은 회사를 대표하지 않으며 본문은 지극히 개인적인 견해입니다. 각자의 상황이 있고 바라보는 시각도 다르기 때문에 얕은 참고만 부탁드립니다. 유독 많은 일이 있었던 작년 말, 시원하게 사표를 내던졌다. 근무했던 곳은 이커머스 분야로 영세한 스타트업이었다. 그러다 보니 Tech Lead/Product Manager/Product Owner/People Lead 등 너무 많은 role을 수행했고 나는 누구인가에 대한 끝없는 질문을 던졌다. 아, 이렇게 많은 role을 맡아서 진행하는 게 정말 가능한 거냐고..

컨테이너와 컨테이너 인스턴스라는 용어로 본문에 많이 등장합니다. 컨테이너 인스턴스는 클러스터에 묶여있는 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 통신으로 동작시키는 것보다 나은 상황이 있기 때문이다. 아무튼, 이렇게 자식 프로세스를 만들어서 일을 시켜보면 의도치 않게 자식이 고아가 되는 경우가 발생한다. 자식의 자식의 자식 이라던가... 뭐 물론 좋은 설계는 아니지만. 이런 경우가..

# 시간이 지나야 지로소 보이는 것들 퍼블릭 클라우드의 엔터프라이즈 서포트를 받으며 technical account manager가 회사에 상주하던 때가 있었다. 그때는 그게 얼마나 행복한 환경인지 몰랐다. 표현이 조금 이상하지만, 궁금한걸 몇 걸음만 이동해서 물어볼 수 있었기 때문에 개인적으로는 본전 뽑았다고 생각한다. 회사 차원에서는 글쎄. 워낙 비싼 분이라 나 혼자 뽑아 먹는 걸로는 부족했을 텐데. 아무튼, 그쪽 분야로는 걸어 다니는 스택오버플로 느낌이었는데.. 찰싹 붙어서 더 배웠어야 했다. 하하하 한편, 개발자가 마음껏 인프라를 만질 수 있는 환경도 장점이자 단점이다. 커리어 측면에서 스킬을 쌓는다고 생각하면 장점이고, 인프라 엔지니어나 데브옵스 엔지니어의 부재는 개발자의 리소스를 갉아먹는다. ..

이번에 진행하는 프로젝트를 AWS 환경에서 개발하면서 여러 가지 개념을 접했다. 특히 ECS(elastic container service)를 깊이 있게 보고 있는데 GCP에서 GKE(google kubernetes engine)를 살짝 다뤄봤던 경험 덕분이 많은 도움이 됐다. 아무튼, VPC부터 Security Group 등 알고 있는 개념들을 정리할 겸 책을 꺼내 들었다. 합리적인 구성으로 담백하게 쓰인 책이다. 특히 책의 제목처럼 "입문"을 위해 클라우드 시스템이란 무엇인지부터 퍼블릭 클라우드의 종류와 컴퓨팅 등 다양한 개념과 기초지식을 초반에 잘 풀어내 주고 있다. 주요 목차는 다음과 같다. 1장. 클라우드의 역할 2장. AWS 기본과 계정 등록 3장. Web 서버 구축 4장. Web 애플리케이션..

제이펍은 책의 리뷰를 작성한 사람들 중에 매달 우수 리뷰어를 뽑아서 도서를 보내준다. 지난달에 “테라폼 설치부터 운영까지”라는 책을 구입해서 읽고 맨 뒷 페이지에 적힌 도서 리뷰에 참가하라는 글을 보고 블로그에 적어놓은 리뷰를 보내보자”라는 생각이 들었다. 밑져야 본전이니 써놓은 리뷰를 보냈고 결과는 2월의 우수 리뷰어로 뽑혔다! 그리고 원하는 도서 한 권을 보내준다는 메일을 받았다. 어떤 책을 고를지 고민하다가 로버트 C.마틴의 “클린 소프트웨어”를 선택했다. 어차피 읽는 책, 재밌게 읽고 또 리뷰를 써봐야지. :) 좋은 책 보내주셔서 감사합니다 제이펍 ♥️

예전에 사놓고 묵혀뒀던 “Amazon Web Services로 시작하는 클라우드 입문” 책을 주말동안 빠르게 훑어봤다. 담백하게 기초에 충실한 책인데 AWS로 클라우드 입문하는 사람들에겐 꽤 도움이 될 듯. 책을 다 봤으면 필요한 기술을 깊이있게 리서치하고 모범사례를 통해 아키텍처를 공부하면 끝. 말은 쉽다. ㅎㅎ 한편, 어쩌다보니 AWS ECS를 다이브하고 있는데 전에 GKE를 통해 잡아뒀던 개념들이 많은 도움이 된다. 어디서 어떤 일을 하던지 일의 연결고리를 만들 수 있는 기술이 자산이 된다. 그래서 cloudformation을 안쓰고 다양한 클라우드 환경에서 쓸 수 있는 terraform을 공부한거고. 나를 AWS에 락인시키고 싶지 않거든. C언어만 주구장창 하던 내가 서비스 레벨로 올라올 수 있었..

예전 직장에서 ISMS 대비 때문에 강제로 SSM(AWS Systems Manager)을 브라우저에서 사용했었는데 이거 터미널에서도 되는거였구만. 무식하게 브라우저 몇 개를 띄워놓고 썼었는데말야. 아무튼, 직접 Systmes Manager 하나씩 설정해보니 원하는 것을 아두 쉽게 얻었다. 역시 직접 해보는거랑 차려준거 먹는거랑은 다름. - bastion host와 다르게 권한, 보안 두 마리 토끼를 한번에 잡음 - pem 관리는 이제 굿바이 - bastion host 서버가 필요 없으니 비용 절감 됨 - 터미널에서 뭔일이 일어나는지 다 기록되서 좋음. bash_history와 다르게 타이핑한 명령어 뿐만 아니라 화면에 뿌려진 결과도 다 기록되니까. cloudwatch 로그 비용은 비밀 GCP와 잠시 이별..

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

작년 가을에 작성해뒀던 글. 묵혀두기엔 아까워서 어떤 생각으로 살았었는지 두고두고 꺼내보려고 블로그에 기재한다. 그때와 지금은 상황이 다르고, 지금과 내일도 다르겠지.. 결정적으로 본문에서 재직했던 회사는 퇴사했다... 지금 몸 담고 있는 회사로 이직한 지 일 년 남짓 시간이 흘렀다. 정확히 일 년이 되는 시점에 회고를 쓰려고 마음먹었었는데 시간이 야속할 뿐이다. 현재 나는 대부분의 사람들이 스타트업에 갖는 걱정과 두려움 모든 걸 끌어안고 가고 있다. 이번 글에서는 그런 내용을 써보고자 한다. 여기서 말하는 스타트업은 다수의 투자를 받고 성장 궤도에 올라있는 회사를 지칭하지 않는다. 중소기업보다는 벤처에 가까운 회사가 되겠다. 이건 head of engineering라는 직책으로 프로덕트 팀을 이끌고 있..

이번에 한빛미디어 도서 서평단으로 받은 "처음 배우는 셸 스크립트". 우선 번역서가 아니라 저자가 한국사람이다. 그렇기 때문에 번역서를 읽으면서 이따금씩 찾아오는 괴로움이 없다. (한글을 읽고 있는데 영어를 읽는 느낌) 국내에 셸 스크립트 책이 얼마나 있는지는 잘 모른다. 알고 싶지도 않았고. 왜냐하면 그동안 셸 스크립트는 온라인에서 풍성하게 찾아볼 수 있었고 프로그래밍 언어로는 받아들여지지 않기 때문에 따로 공부해야 하는 필요성은 못 느꼈기 때문. 말은 이렇게 하지만 첫 직장이 리눅스 커널을 개발하던 회사였기 때문에 현업에서 선배들에게 치이며 셸 스크립트를 몸으로 익혔었다. 아무튼, 이 책을 처음 받았을 때는 "아, 이번에 리뷰 대상인 책들 재밌는 거 많던데 하필 다 아는 내용만 있을 셸 스크립트 책이..

terraform —— 이렇게 불안정한걸 왜 쓰는 거야! 싶다가도 고비를 넘길 때마다 코딩의 짜릿함이 있다. 더욱이 온라인에 있는 글(나 포함)은 대부분 예제 수준이라 고급 스킬은 다른 곳에서 주워야 한다. 특히 hashicorp GitHub에 issue 쪽에서 많은 내용이 다뤄지기 때문에 뭔가 해결하고 싶은 문제가 있으면 그 동네로 가면 된다. 아무튼, 테라폼이라는 키워드를 알고 모듈 활용해서 환경 분리되는 수준으로 5일 정도 걸려서 끝내고 우쭐했다. 공식문서 읽으며 개념잡는데 이틀, 모범사례 숙지 차원으로 책 한 권 읽고(하루), 구현에 다시 이틀. 근데 고-급 활용을 위해 고민하다보니 고개가 절로 숙여지네. 뭔가 인프라를 수정할 게 있어서 코드를 다시 열어보면 보이 스카웃 규칙에 따라 계속 손이 간..

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)을 통해 형상관리할 수 있게 됩니다 인프라를 코드로 관리하면 애플리케이션을 형상관리 했을 때와 완벽하게 동일한 이점을 갖게 됩니다 누가, 언제, 왜 인프라를 변경 했는지 확인할 수 있고, 애플리케이션 코드를 리..

gem을 통해 terraforming을 설치하다가 아래와 같은 오류가 발생했습니다. $ gem install terraforming Fetching jmespath-1.4.0.gem Fetching aws-partitions-1.427.0.gem Fetching aws-eventstream-1.1.0.gem Fetching aws-sdk-core-3.112.0.gem Fetching aws-sdk-autoscaling-1.54.0.gem Fetching aws-sigv4-1.2.2.gem Fetching aws-sdk-cloudwatch-1.49.0.gem Fetching aws-sdk-dynamodb-1.59.0.gem Fetching aws-sdk-ec2-1.224.0.gem Fetching aws-..

프로그래밍을 하다 보면 필연적으로 메모리 사용량을 디버깅해야 하는 일이 생깁니다. 메모리 누수가 발생해서 디버깅을 해야 하는 경우도 있고 메모리 사용량이 비정상인 경우도 디버깅이 필요해요. 일부 언어는 힙 메모리 공간을 통째로 덤프 떠서 확인하는 일도 비일비재하죠. 이번 글에서는 파이썬 프로그램을 개발하면서 메모리 사용량을 추적하는 방법을 알아봅니다. 거창하게 시작했지만 파이썬에서 메모리 추적은 psutil 이 대표적입니다. 일단 사용 방법부터 바로 알아보고 조금 더 상세한 이야기를 해봅니다. 사용법은 심플합니다. 다음 공식 예제를 살펴보시죠. >>> import psutil >>> p = psutil.Process() >>> p.memory_info() pmem(rss=15491072, vms=8402..

이 글은 웨이브를 저격하거나 폄하하는 글이 아닙니다. 이번 일을 통해 스트리밍 기술을 이해하고, OTT 서비스를 하고자 한다면 보안적으로 어떤 부분을 신경 쓰면 좋은지 점검하는 글입니다. 오해 없으시길 바랍니다. 2021년 신년이 되자마자 wavve에서 대형 사고가 터졌습니다. 이전에도 유사한 문제가 있었다고 하는데 개발직군에 종사하고 있는 사람으로서 문제를 진단하고 처방하는 시간을 갖도록 하겠습니다. 포털에 "wavve 뽀로로"를 검색하면 아래와 같이 이번 사고 내용이 확인됩니다. "뽀로로 컴퓨터 왕국 대모험"이 시청되는 도중에 성인물 베드신이 송출되었다고 하네요. 어떻게 이런 일이 가능한 걸까요? 웨이브 측은 에러파일을 복구하는 과정에서 일부 오류가 있었음을 인정했다고 합니다. 한편, 1월 30일에 ..

AWS, Google Cloud Platform, Azure 등 퍼블릭 클라우드가 서비스로 흘러들면서 효율적인 인프라 관리를 위한 방법이 화두가 되었습니다. 서버 운영, 관리에 조예가 깊은 개발자라면 잘 알겠지만 애드 훅 스크립트를 통한 서버 관리는 대안이 없던 그 시절 매우 효율적인 것처럼 보였습니다. 요즘은 애드 훅 스크립트를 넘어 다양한 도구들이 쏟아지고 있는데 그 중심에 Terraform(테라폼)이 있다고 해도 과언이 아닐 겁니다. 테라폼은 대표적인 코드형 인프라(Infrastructure as Code: 이하 IaC)로 서버 프로비전 도구입니다. 이 책에서는 서버 관리를 위한 다양한 도구를 설명하고 테라폼과 비교합니다. 그리고 테라폼의 기본적인 철학과 사용법, 나아가 고도화 전략을 다룹니다. 책..