aws – Dreaming for the Future 영원한 개발자를 향해서. 월, 13 1월 2025 13:44:09 +0000 ko-KR hourly 1 https://wordpress.org/?v=4.7 108384747 휴면 계정 처리 – 배치에서 온라인 시스템으로 /index.php/2019/09/14/from-batch-to-online-processing-in-msa/ /index.php/2019/09/14/from-batch-to-online-processing-in-msa/#comments Sat, 14 Sep 2019 09:49:28 +0000 /?p=659

Continue reading ‘휴면 계정 처리 – 배치에서 온라인 시스템으로’ »]]> 배치(Batch)라는 작업은 주기적으로 실행되는 작업을 말한다. 다루는 데이터가 적은 경우는 별 걱정이 없다. 하지만 다룰 데이터가 많다면 과연 이 작업이 정해진 시간안에 끝날지 걱정하게 된다. 배치 작업은 대량의 데이터에 대한 문제도 있지만, 한 주기안에 그 일이 끝나야한다는 시간적인 제약도 존재하는 문제기도 하다.

서비스와 이를 뒷받침하는 시스템은 계속 진화한다. 그리고 데이터와 시간에 대한 최적화도 진화에 맞춰 지속되어야 한다. 최근의 시스템은 MSA(Microservice Architecture)를 따라 보편적으로 개발한다. 그리고 기존의 시스템들도 MSA화 하기 위한 방향으로 변경을 진행한다. 내가 있는 라이엇게임즈 개발팀에서도 시스템을 개편하거나 신규 시스템들은 모두 MSA를 따라 개발 작업을 진행한다.

MSA 방식으로 구성된 시스템은 Monolithic 방식으로 구성된 시스템보다는 내부 Component간 연동이 느릴 수밖에 없다. 어플리케이션 내부의 함수 콜이 작은 어플리케이션간의 RESTful API 호출로 바뀌었기 때문에 당연히 느릴 수밖에 없다. 각각의 컴포넌트는 독립적이고 자율적인 형태로 바뀌었지만, 이에 대한 반대 급부로 컴포넌트간의 연동 속도 저하가 단점이 될 수 밖에는 없다. 배치 작업 가운데 여러 외부 컴포넌트를 연동하는 경우가 많다면 MSA를 따르면서 전반적인 시스템의 최적화가 난관에 봉착하게 마련이다. 생각보다 한 주기의 시간안에 작업을 끝내는게 심각하게 어려운 작업이라는 것을 새롭게 알 수 있게 될 수 도 있다..

이 글에서는 팀이 MSA 환경에서 어떻게 배치 시스템의 속도 문제를 사고의 전환으로 해결했는지 소개한다.

휴면 계정이란?

휴면 계정은 개인 정보 보호 조치 가운데 하나다. 계정이 1년 동안 아무런 활동도 없으면, 해당 계정과 관련된 개인 정보를 라이브 시스템에서 없애고 이를 라이브 시스템과 분리된 별도의 공간에 저장하는 조치다. 유럽에서 GDPR이 작년(2017)에 실행되면서 개인 정보 보호 조치를 강화했지만, 한국에서는 이미 2015년에 이 조치를 실행했다. 이런 경우들을 두고보면 개인 정보를 다루는 법률적인 측면에서 한국이 되려 다른 나라보다 선두에 있음에 틀림없다. 꼭 이런 조치를 실행하고, 시스템을 만들어야 하는가에 대한 논의가 있긴하다. 하지만 불필요한 개인 정보를 굳이 라이브 시스템에 둘 이유는 없다. 필요없다면 지우는게 맞다. 이런 측면에서 옳은 정책임에는 틀림없다. 다만 이를 어떻게 구현하고 실행할지 그 방법론이 문제가 될 수 있을지도 모르겠다.

휴면 계정 대상자는 휴면 조치를 취하기 전 1개월내에 최소 1회 이상, 계정 소유주에게 휴면 조치가 취해진다는 사실을 알려야 한다. 그럼에도 불구하고 추가적인 활동이 없다면 최종 활동이 있었던 시점으로부터 1년이 되는 날에 계정에 대한 휴면 조치를 실행한다.

일반적으로는 이렇게 합니다.

1년 동안 아무런 활동도 없는 계정들을 추출하기 위해서 어떤 방식을 사용하나? 가장 쉽고 일반적으로 생각할 수 있는 방안은 매일 전체 Active 계정들(ACCOUNT 테이블)을 추출한 다음에 해당 계정들의 최종 Activity Date를 확인하는 방법이다.

안목있는 아키텍트가 있다면, 최종 활동에 대한 정보를 하나의 테이블(RECENT_ACTIVITY)에 모아둘 것이다. 그리고 모든 데이터가 하나의 데이터베이스에 있는 구조라면 이 문제를 가장 손쉽게 해결할 수 있다. SQL 쿼리 한방으로.

SELECT * FROM ACCOUNT, RECENT_ACTIVITY
WHERE ACCOUNT.id = RECENT_ACTIVITY.account_id
AND RECENT_ACTIVITY.activity_datetime < now() - 365;

휴면 계정으로 추출된 계정 정보들을 휴면 계정화하고, 이를 계정 테이블에서 삭제한다. 정말 깔끔하다. 휴면 계정화 1개월 전에 보내야하는 통보 기능도 비슷한 쿼리로 이메일 주소를 추출해서 처리할 수 있다.

SELECT * FROM ACCOUNT, RECENT_ACTIVITY
WHERE ACCOUNT.id = RECENT_ACTIVITY.account_id
AND RECENT_ACTIVITY.activity_datetime < now() - 335;

원래 있던 쿼리의 365를 335로 간단히 바꾸면 통보를 위한 대상자도 손쉽게 추출할 수 있다.

MSA가 대세라구요!?

MSA를 서비스에 적용하면서 이제 역할에 따른 DBMS를 별도로 분리한다. MSA의 기본 원칙 가운데 하나는 하나의 마이크로서비스가 자신의 데이터를 서비스를 위해 정의한 저장소에 관리하고, 해당 데이터가 필요한 다른 서비스들은 API를 통해 참조하는 것을 원칙으로 한다.

이제 최종 활동에 대한 관리 기능이 별개의 서비스(ActivityLogger)로 분리된다. 잦은 로깅으로 전체 서비스에 영향을 주던 민폐를 걷어내고, 온전히 로깅에 대한 역할을 담당하는 마이크로서비스로 거듭난다. 계정의 최종 활동일을 계정 테이블에 담고자하는 노력이 있긴 했지만, 계정 테이블은 많은 서비스들에서  기본적으로 참조하는 데이터 영역이고, 잦은 업데이트는 과도한 IO 부하를 일으키기 때문에 ActivityLogger 서비스의 API를 통해 참조해서 처리하기로 한다.

ElasticSearch를 통해 구현된 최종 활동 API는 빠른 응답 속도를 보장한다. 이를 사용하기로 했기 때문에 어쩔 수 없이 전체 계정들을 모두 로딩 후 API를 호출해서 최종 Activity Date를 구하고, 1년이 경과한 계정을 찾는다. 하지만 백만 건이 넘는 계정에 모두 로딩해서 처리하는 건 많은 소요 시간을 필요로 한다. 계정 아이디에 따라 이를 N개의 그룹으로 나누고, 각 그룹을 로딩해서 동시에 처리하도록 병렬 쓰레딩을 도입한다.

어차피 전체 계정들을 모두 로딩해야했기 때문에 이메일 통보 기능과 휴면화 기능을 2개의 배치 작업에서 1개의 배치 작업으로 합친다.

전체 데이터 셋과 유사한 환경을 구성하고, 테스트를 해보니 6시간이면 배치 작업이 성공적으로 완료됐다. 이제 라이브 서비스에서 실제로 배치를 실행할 시점이다.

이라, 이건 아닌데

테스트 환경과 달리 라이브 환경은 계정 테이블에 대한 다양한 조회와 변경이 존재하기 때문에 6시간 보다 완료 시간이 2시간 더 걸렸다. 하지만 24시간내에 작업이 완료됐기 때문에 ActivityLogger 서비스의 도입은 성공적으로 마무리가 됐다. 굿!!

Clock6h

성공적인 사업의 확장과 MSA의 도입으로 조직과 서비스 시스템들은 수평적인 확장을 통해 안정적인 서비스를 제공한다.

가입자 증가로 휴면 처리 시간이 점차 오래 걸린다. 12시간

Clock12h

과정에서

  • 이메일 발송 기능도 클러스터링 기반의 독자적인 이메일 서비스로 새롭게 탄생한다.  – 13시간
  • 상품을 판매하기 시작했고, 결제 데이터가 개인화 데이터로 분류됐다. 마찬가지로 해당 데이터 역시 휴면화 대상 프로세스에 편입되어야 한다.  – 16시간
  • 가입자가 더 늘었다. – 20시간

Clockmh

하루안에 휴면 처리 배치가 완료되어야 하지만 이대로 두면 하루를 넘길 것이 분명하다. 계정 데이터에 대한 그룹을 세분화하고, 추가 장비들을 도입해서 병렬화를 높이는 것도 방법이긴 하지만 과도한 조회로 인해 계정 테이블에 무리를 주는 건 그닥 올바른 방법으로 보이지 않는다.

문제를 다시 정의해보자.

MSA 적용 전/후의 휴면 계정 처리 시스템이 갖는 가장 큰 차이점은 대상 계정을 추출하는 방식이다. MSA 적용 이전의 Monolithic 시스템 상황에서는 DBMS를 통해 전체 계정을 조회했다. 이후에는 직접 전체 계정을 조회하는 방식이 적용됐다. 방식의 차이가 있긴 하지만 모두 전체 계정을 조회한다는 점에는 차이가 없다. 바꿔 이야기하면 두 방식 모두 가입자가 늘어나는 상황에서는 모두 문제를 가질 수 밖에는 없게 된다.

우리가 해야할 문제를 다시 한번 짚어보자. 계정의 휴면화가 진행되는 과정을 살펴보면 1년이 되기 한 달 전에 계정의 소유주에게 알림을 주고, 1년이 경과한 시점에 휴면화를 처리한다. 즉 시간의 흐름에 따라 발생하는 이벤트다. 그리고 꼭 전체 계정을 대상으로 해야할 작업이 아니라 이 조건은 특정 계정에 관련된 이슈라고 정의할 수 있다.

문제를 이렇게 다시 정리해보니, 계정을 시간 조건에 의한 State Machine으로 간주하면 쉬운 해결 방안을 찾을 수 있다. 즉 위 조건에 따르면 다음과 같은 계정의 상태 전이가 이뤄진다.

AccountActivities

NOTIFIED 혹은 DORMANTED 상태에서 계정에 Activity가 발생했다면, 당연히 ACTIVE 상태로 변경된다. 그리고 각각의 상태 변화가 발생하는 시점에서 필요한 작업들을 해주면 된다. 예를 들어 이메일을 발송하거나 계정의 개인 정보를 분리된 데이터베이스로 옮기는 작업들이 이에 속한다.

이렇게 정리되면 계정의 상태 변화를 발생시킬 수 있는 도구만 있으면 된다. 그리고 생각외로 이런 기능을 지원해주는 Repository들을 손쉽게 찾아볼 수 있다.

그래서 이렇게 바꿨다.

휴면 계정 처리 작업에서 계정을 시간을 조건으로 한 State Machine으로 정의하고 보니, 계정 테이블을 직접 연동하는 것이 아니라 휴면 프로세스를 위한 State Machine용 repository를 만들어버리는데 훨씬 더 깔끔한 접근 방법이다. 이런 식으로 방향을 잡으니 아예 휴면 계정을 위한 별도의 마이크로 서비스를 만드는게 더 효과적이다. 그래서 다음과 같은 방식으로 휴면 계정 처리 서비스의 아키텍쳐와 도구들을 잡았다.

  1. 시간의 흐름에 따른 계정의 상태 변화를 관리하기 위해 별도의 Repository를 AWS DynamoDB를 활용하여 정의한다.
    • AWS DynamoDB의 기능 가운데 TTL 관리 기능이 존재한다.
    • DynamoDB의 TTL 기능은 단일 Entry 수준에서 TTL 값을 모두 다르게 설정할 수 있다.
    • 지정된 시간이 초과한 데이터를 AWS Lambda를 통해 추가적인 필요한 처리를 실행할 수 있다.
  2. 상태의 변화가 일어날 때 처리해야할 작업들이 좀 된다.  람다의 성격상 복잡한 Biz Logic을 구현하는 건 맞지 않다고 보기 때문에 별도 Application에서 따로 처리한다.
  3. AWS Lambda는 Expire된 항목들을 받아 계정의 상태 변화를 관리하는 어플리케이션에 전달한다.
  4. 어플리케이션은 전달된 계정의 지정된 State Transition을 관리하고, 상태 변경시에 취해져야할 기능들을 실행한다.
  5. ActivityLogger 서비스와 연동해서 계정의 활동이 발생하면 해당 계정의 상태가 항상 ACTIVE 상태가 되도록 한다.
  6. 물론 마이크로서비스를 위한 최초 상태 데이터는 계정 데이터베이스와 ActivityLogger 시스템으로부터 생성한다.

Dormant service

이와 같은 구조로 변경되면 앞서 이야기했던 배치 작업이 없어진다. 시간의 흐름에 따른 개별 계정의 상태 변화는 DynamoDB와 ActivityLogger 서비스에 의해 실시간으로 처리된다. 더 이상 배치 작업이 하루 안에 마무리 될지 가지고 조바심내지 않아도 된다.

MSA 환경에 적응할려면.

마이크로서비스 아키텍처는 서비스를 제공하는 환경을 크게 탈바꿈시켰다. 개발된 기능을 배포하는 시간을 크게 줄였을 뿐만 아니라 서비스의 독립성과 빠른 배포 주기를 기본 사상으로 가지고 있기 때문이다. 이를 충실히만 따른다면 빠른 피드백 사이클을 갖는 서비스의 개발과 유지가 가능하다.

하지만 모든 것에는 장단이 있기 마련이다. 때문에 모든 Monolithic 어플리케이션을 악의 축으로 보고, 이를 MSA화 하는 것은 상당한 위험을 내포하고 있다. 실제 변화를 꾀하기 전에 단기적으로 발생하는 손익도 반드시 고려해야한다. 이 글에서 이야기한 것처럼 예기치 않은 부작용이 발생할 수 있으며 관련된 추가 비용이 발생한다.

MSA를 효과적으로 반영하기 위해서는 상황에 맞는 적절한 도구들을 활용해야 한다. 휴면 계정용 서비스를 구현하는데는 AWS DynamoDB라는 도구를 이용해 시간에 따른 이벤트를 활용할 수 있었다. 물론 DynamoDB도 Expiration이라는 것을 정확하게 체크하지는 못한다. 해당 시간이 지난 후 4시간 안에는 지워진다지 정각에 지워지는건 아니다. 하지만 휴면 계정을 실행하는데 10분 ~ 20분의 차이는 서비스의 동작에 영향을 미치지 않는다.

마이크로서비스는 기능에 집중하기 때문에 해당 기능에 최적화된 도구를 사용할 수 있느냐 없느냐에 따라 서비스의 효율성이 좌우된다. MSA 환경에서 아키텍트는 특정 도구만 고집할 것이 아니라 다양한 도구들이 어떤 특성을 가지고 있고, 상황에 따라 유연하게 도구들이 사용될 수 있도록 가이드할 수 있어야 한다. 물론 어느 한 사람이 현재의 도구나 최신 기술들을 모두 알기란 불가능하고 또 그럴 필요도 없다. 개념이면 충분하다. 그럼 활용할 수 있는 시점에 도구들을 찾아내기만 하면 된다.

무엇보다도 중요한 점은 하나의 틀에 얽매이지 않는 자세가 중요하다. MSA가 아무리 좋다고 하지만, 본인이 있는 환경에 어울리지 않는다면 사용하지 않는 용기도 가지고 있어야 한다. 좋은 개발자 혹은 테크 리더가 보여줘야 할 태도중에는 항상 최신이 아닌 최선을 위해 최신 기술을 미룰줄도 알아야 하는게 아닐까 싶다.

– 끝 –

]]> /index.php/2019/09/14/from-batch-to-online-processing-in-msa/feed/ 3 659 Git 기반 효율적인 이벤트 페이지 배포 환경 만들기 /index.php/2018/01/22/effective-continous-delivery-with-git-and-jenkins-for-publishing/ Sun, 21 Jan 2018 21:43:43 +0000 /?p=508

Continue reading ‘Git 기반 효율적인 이벤트 페이지 배포 환경 만들기’ »]]> 고객과 소통을 많이 할려다보면 이것 저것 알릴 내용들이 많다. 이건 게임 회사이기 때문이 아니라 소통에 대한 의지를 가진 회사라면 당연히 그래야한다.

SVN을 사용했었는데 무엇보다도 변경 사항에 대해 파악하는 것이 너무 힘들었다. 또한 매번 배포 때마다 브랜치를 머지하고 관리하는데 쉽지가 않다. 대부분의 프로젝트들은 모두 git을 사용하고, 전환했지만, 프로모션 영역은 7G라는 덩치의 Hell of Hell이었기 때문에 차일피일 미뤄지고 있었다.

기술 부채를 언제까지 끌고갈 수는 없다. 해야할 것을 미루기만 해서는 두고두고 골치거리가 된다.

이벤트/프로모션 페이지들은 배포되면, 이후의 코드 변경은 거의 발생하지 않는다. 하지만 다른 사이트등을 통한 참조가 발생할 수 있기 때문에 유지는 필요하다. 해당 페이지들을 통해 컨텐츠 혹은 정보들이기 때문에 그냥 404 오류가 발생하도록 놔둘 수는 없다. 따라서 기간이 지나면 관리해야하는 용량이 커질 수밖에 없다.  이렇게 커진 용량을 빌드/배포하는 건 전체 프로세스의 효율성을 확 떨어트린다. 특정 프로모션 영역(디렉토리)별로 배포하는 체계를 이미 갖췄기 망정이지, 그게 아니라면 7G 짜리를 매번 배포하는 최악의 배포 환경이 될 수 밖에는 없었을 것이다.

특정 영역별로 배포하는 방식에서 힌트를 얻었서 전체 코드들을 각 이벤트/프로모션 영역별로 쪼개서 각자 관리하기로 했다. 개별적인 성격의 프로모션 사이트로 볼 수 있기 때문에 각각의 디렉토리는 의존성이 없다. 때문에 개별 Repository로 나눠놓는 것이 완전 독립성 부여라는 관점에서 맞기 때문에 SVN repository를 git organization으로 만들고, 개별 디렉토리를 git repository로 만들었다. 이 방식의 문제점은 SVN 작업 이력을 git 환경으로 가져가지 못한다는 점이다.  하지만 “새 술은 새 부대에“라는 명언이 있지 않은가!!

맘을 정하고, Organization을 생성한 다음에 Repository를 Github을 통해 생성했다. 수련하는 마음으로 열심히 노가다를 하다보니 이내 모든 Repository를 만들긴 했는데… 이렇게 노가다한 결과 Repository를 세어보니 100개가 훌쩍 넘는다. 헐… 올리긴 해야하니까 스크립트의 도움을 받아 push했다.

쪼개놓는 건 일단 이쁘게 정리를 했는데 이제 배포 체계다. 일반적으로 개발 단게에서 master로 머지되는 코드는 자동으로 배포한다. 그래야 과정의 결과물을 관련된 사람들이 즉시즉시 확인할 수 있다. Git을 사용하는 경우, 이를 위해 webhook을 이용한다. Polling을 이용하는 경우도 있긴 하지만 이건 SVN을 쓰때나 써먹는 방법이다. 현대적이지도 않고 아름답지도 않다.  그런데 100개 이상이나 되는 코드에 일일히 webhook을 걸려고 생각해보니 이건 장난이 아니다. 노가다도 개발자의 숙명이라고 이야기하는 사람이 있을지 모르겠다. 하지만 프로모션이 늘어날때마다 webhook을 한땀한땀 설정하는 것도 웃기다. 누가 이 과정을 까먹기라도 한다면 사수에게 괴롭힘을 당할 수도 있기 마련이기도 하고. (안타깝지만 정말 이런게 어느 분야를 막론하고 흔하게 있다. 적폐에 타성으로 물든다고나 할까?)

자동화다. 개발자의 숙명은 적폐를 청산하고 사람의 개입없이도 돌아가는 시스템을 만들어내는 것이다. 다행이도 git의 경우에는 개별 repository에서 발생한 push 이벤트를 repository가 소속된 organization에 전달하는 기능이 있고, wehbook을 oragnization에 설정하는 것을 허용한다. 이 기능을 활용하면 신규 프로모션 작업을 위해 새로운 repository를 만들더라도 별도로 webhook을 설정할 필요가 없다.

(Jenkins는 application/json content-type만을 받아들인다. 괜히 urlencoded 형식으로 해서 안된다고 좌절하지 말자)

이제 배포를 위해 Jenkins에 해당 webhook을 이용해 정보를 전달하면 된다. 근데 어케 webhook payload를 jenkins가 이해하지? 그렇다. 여기서 다시 큰 문제점에 봉착한다. Jenkins에서 활용할 수 있는 git plugin은 이름이 지정된 특정 repository의 webhook을 인식할 수 있지만, 이 경우를 상대할려면 jenkins쪽에 각 repository들에 대응하는 jenkins job을 만들어줘야 한다. 이게 뭔 황당한 시츄에이션인가? 간신히 한 고비를 넘겼다고 생각했는데 앞에 비슷한 역대급 장애물이 기다리고 있다.

하지만 갈구하면 고속도로는 아니지만 길이 나타난다.  Jenkins에서 아래와 같은 두가지 아름다운 기능을 제공한다.

  • Parameterized build – 비드를 할 때 값을 파라미터로 정의할 수 있도록 하고, 이 파라미터 값을 빌드 과정에서 참조할 수 있도록 해준다.
  • Remote build trigger – Job에서 지정한 Token값이 HTTP authorization header를 통해 Jenkins에 전달되면 해당 Job이 실행된다. 와중에 Parameter 값을 별도로 설정도 할 수 있다.

이 두가지 기능을 활용하면, Job 하나만 만들어도 앞서 정의한 100개 이상의 repository의 빌드/배포를 실행할 수 있게 된다. 환경 설정을 위해 아래와 같이 Jenkins Job에 Repository 맵핑을 위해 String parameter를 정의하고, git repository 설정에서 이를 참조하도록 한다.

Jenkins Job을 선택하기 위한 Token은 아래 방식으로 설정한다. Jenkins는 해당 토큰값으로 어느 Job을 실행한지 선택하기 때문에 중복된 값을 사용해서 낭패보지 말길 바란다.

설정이 마무리됐다면 아래와 같이 테스트를 해보자.

 

curl -X POST "http://trigger:jenkins-trigger-user-credential@jenkins.sample.io/job/deploy-promo-dev/buildWithParameters?token=TOKEN&delay=0&PROMOTION=promotion”

Jenkins Host 이름 앞에 들어가는 건 Jenkins 접근을 위한 사용자 정보이다. 일반 사용자의 아이디 및 Credential을 바로 사용하지 말고, API 용도의 별도 계정을 생성해서 사용할 것을 권한다.

하지만 Build trigger를 누가 호출해주지? 누구긴, 당신이 짠 코드가 해야지! 이제 본격적인 코딩의 시간이다.

Git org에 설정한 webhook의 로부터 개발 작업이 이뤄진 repository와 branch를 확인하고, 이를 build trigger의 query parameter로 전송하면 된다. 일반적인 웹 어플리케이션처럼 상시적인 트래픽을 받는 시스템이 아니기 때문에 운영을 위해 별도의 어플리케이션 서버를 구축하는 건 비용 낭비다. 이를 경우에 딱 맞는 플랫폼이 AWS Lambda이다.  복잡한 코딩이 필요한 것도 아니기 때문에 Node.js를 활용해서 간단히 어플리케이션을 만들고, S3를 통해 이 어플리케이션이 Lambda에 적용될 수 있도록 했다. 실제 호출이 이뤄지도록 API Gateway를 앞단에 배치하면 끝!

Node.js를 이용한 Lambda 코드는 아래와 같이 작성해주면 된다.

var http = require('http');
var btoa = require('btoa');
exports.handler = (event, context, callback) => {
  var repository = event.repository.name;
  var options = {
    host: 'jenkins.sample.io',
    port: 80,
    headers: {
     'Accept': 'application/json', 
     'Authorization': 'Basic ' + btoa('trigger:jenkins-trigger-user-credential') 
    },
    path: '/job/deploy-promo-dev/buildWithParameters?token=TOKEN&delay=0&PROMOTION=' + repository,
    method: 'POST'
  };

  var refElements = event.ref.split('/');
  var branch = refElements[2];
  if (branch === 'master') {
    http.request(options, function(res) {
      console.log('STATUS: ' + res.statusCode);
      res.on('data', function(chunk) {
        console.log(chunk);
      })
    }).on('error', function(e) {
      console.loge('error',e);
    }).end();
    callback(null, 'Build requested');
  } else {
    callback(null, 'Build ignored for ' + branch + ' pushing');
  }
};

 

이제 개발하시는 분들이 개발을 막~~~ 해주시면 그 내용이 프로모션 웹 영역에 떡하니 표시되고, 프로모션 담당자들이 확인해주면 된다. 그리고 최종적으로 완료되면 라이브 환경에 배포를 해주면 된다.

근데 배포를 누가 해주지?? 라이브 배포는 자동으로 할 수 없으니까 개발 환경과 유사한 라이브용 Jenkins Job으로 개발자가 돌려야 하는거 아니가? 맞다. 걍 개발자가 하면 된다. 흠… 개발자가… 하지만 이 단계에서 개발자가 하는건 배포 버튼을 눌러주는게 다 아닌가? 개발과 라이브의 환경 차이가 물론 있긴하지만 프로모션이라는 특성상 그닥 크지 않다. 이미 개발 환경에서 프로모션을 담당자들이 깔끔하게 확인한 걸 개발자가 한번 더 확인할 필요도 없고 말이다.

게으른 개발자가 더 열열하게 게으르고 싶다. 어떻게 하지?? 뭘 어떻게 하긴, 열 코딩하는거지.

Git이란 환경은 정말 개발자에게 많은 것들을 아낌없이 나눠준다. 그 가운데 하나가 바로 API. 내가 사용하는 Git의 경우에는 Enterprise(Private) Git이기 때문에 적절하게 Credential만 맞춰주면 API를 호출할 수 있다. 보통은 이걸 위해 API 전용 Secrete을 생성해서 사용하는게 안전하다. (어느 바보가 자기 아이디 암호를 API 호출하는데 사용하지는 않겠지??)

Git API를 이용하면 Git org에 속한 모든 repository들을 모두 가져올 수 있다. 그럼 이 가운데 배포 대상을 하나 선택해서 프로모션 담당자가 Jenkins job을 trigger할 수 있도록 해주면 되는거 아닌가!! 쓰는 사람을 위해 배려 하나를 더해 준다면 가장 최근 작업 repository가 배포 대상이 될 것이라 업데이트 시간을 기준으로 최근 repository가 앞에 오게 하자. 아름다운 이야기다.

복잡하지 않다. jQuery를 이용한 간단한 웹 어플리케이션이면 족하다. 100줄 미만으로 구현된다. 물론 미적 추구를 더한다면 더 길어질 수도 있겠지만 개인적으로 절제된 공백의 아름다움이 최고라고 생각하는 1인이기 때문에. 물론 아무나 들어와서 마구 배포 버튼을 누르지 못하도록 적절한 예방 장치들을 마련되야 한다.

전체를 그림 하나로 그려면 대강 아래와 같다.

 

– 끝 –

참고한 것들

]]> 508 AWS를 활용한 블로그 시스템 만들기 /index.php/2016/03/15/wordpress-with-aws/ Mon, 14 Mar 2016 15:18:49 +0000 /?p=28

Continue reading ‘AWS를 활용한 블로그 시스템 만들기’ »]]> 그동안 네이버에서 제공하던 블로그를 써서 글을 써왔다.

많지 않은 글이긴 하지만 그래도 근 10년 가까이 글을 쓸 수 있도록 해준 고마운 친구였다. 하지만 변화하는 세월앞에서 그 친구도 새로운 옷을 점점 갈아입기 시작하더니 결국에는 내가 싫어하는 스타일로 가버렸다.

개발자의 이야기를 많이 하고 싶은 심정이긴 하지만 받아주는 친구가 맛집에 너무 친화적으로 바뀌다보니까 개발자스럽게 글을 쓸 수 있는 거랑은 거리가 멀어져버린 것 같다.   절이 싫으면 중이 떠나서 본인 입맛에 맞는 걸 찾는 수밖에 없겠지…  온라인 툴로 많이 사용하는 브런치도 꽤 좋은 선택지일 것 같지만 코드를 담아내기에는 최적은 아닌 것 같았다.

결론은 워드프레스(WordPress)를 이용해서 나만의 시스템을 만들자!  최근에 아마존 AWS 기반으로 일을 하고 있기 때문에 처음부터 끝까지를 해본다면 얼마나 할 수 있을지를 시험해보고 싶기도 했다. 하면 된다고 말을 했지만 실제로 처음부터 끝까지 내 손으로 해본 적은 또 없기 때문에 이번이 좋은 기회라는 생각도 들었다.

간단히 무료 블로그 시스템을 구성하는데 사용한 것들은 아래와 같다.

  • EC2 – 1 CPU, 1G Mem, 30G SSD Disk
  • Elastic IP – Public IP (고정 IP 할당용)
  • RDS – MySQL Instance, 20G 용량
  • Route53 – 도메인 등록 및 Sub domain 관리

 

Setting AWS Environment

EC2

EC2DiskUsage사용할 워드프레스는 PHP 기반이므로 아파치에서 동작된다. 이건 이걸 돌리는데 그리 큰 메모리를 필요로 하지 않는다는 것이다. 또한 특성상 CPU를 많이 먹을 이유도 없다.  그렇기 때문에 죽는걸 고려하지 않는다면 아주 간단한 웹서버만으로도 돌리는게 가능하다.

EC2에서 제공하는 Free Tier 장비로 1CPU, 1G를 제공한다. 자바 어플을 돌리기에는 부담스럽긴 하지만 워드프레스류를 돌리기에는 부담이 없다. 와중에 저장 공간 역시 30G를 제공한다. 당장 쓰는데 필요한 모든 소프트웨어를 다 깔아둔 상황임에도 불구하고 5% 수준을 사용하고 있다. 95%를 언제 채울 수 있을까 싶긴하다.

EC2를 통해 생성된 클라우드 장비는 변동 IP를 가진다. 고로 장비를 Restart되거나 혹은 리부팅되면 IP가 바뀔 가능성이 아주 농후하다.  물론 Private IP는 변경되지 않지만 Public IP는 소중한 존재이기 때문에 고정된 형태로 한 장비에 이를 허해주지는 않는다.

외부에서 그 이 장비를 어떻게 볼 수 있는거지?  그 방안을 Elastic IP를 통해 제공한다.

 

Elastic IP

AWS 환경에서 고정 Public IP를 사용하기 위해서는 Elastic IP를 사용해야 한다.  가난히 설명하면 고정 Public IP를 갖는 Domain Name을 생성하고, 그 IP에 다시 특정 EC2 Instance를 Binding 시키는 방법이다.

물론 익히 아는 바와 같이 이건 유료다. Public IP를 할당받았으면 아마존은 담달부터 당신에게 청구서를 보낼 것이다.

RDS

예전에 이런 서비스가 있다는 이야기를 듣긴 했지만 써보니 역시 좋았다. 각종 RDBMS를 내가 별도로 설치하는게 아니라 몇 개 설정만 꾹꾹 누르면 설정하기 힘든 데이터베이스 서버가 쭉쭉 생겨난다.

가장 흔하게 사용할 수 있는 MySQL 서버를 지정했다. 인스턴스 타입을 보면 Production용과 Dev/Test용 장비로 분명하게 고를 수 있다. Dev/Test 용도의 장비는 무료이기 때문에 당연히 이걸로 갔다. 와중에 용량도 최대 20G(!!)나 준다. 내가 이걸 다 채울려면 아마도 글을 정말 열심히 써야할 것 같다는 생각 뿐이다.

생성된 데이터베이스 인스턴스는 이름을 통해 접근 가능한 Entry Point를 제공한다. 물론 IP를 통해 접근도 가능하겠지만, 클라우드 환경에서 IP는 믿을 수 없는 존재이다. 어떻게든 이름을 가지고 접근할 수 있어야 한다.  설정에서 주의할 점은 MySQL 데이베이스에 대한 접근을 모든 IP 대역에서 접근하도록 허용하면 좀 곤란한다. 가급적 외부망에서의 접근은 차단하고 EC2에서 생성된 Instance만을 통해 접근이 되도록 제어를 해주는게 좋다.

Router53

도메인을 신청한다.  여기에서는 chidoo.me  물론 이것도 다 돈이다. 하지만 인터넷상에 자신의 집을 하나 가진다고 생각하면 머… 술한잔 값도 아니니 안심하구 지르시길 바란다.

도메인이 신청되면 Hosted Zone이라고 해당 도메인의 Sub domain을 관리할 수 있는 기능이 생긴다. CNAME 방식으로 Elastic IP를 통해 생성된 내부 도메인 이름을 www.chidoo.me가 되도록 설정한다.

Setting WordPress

워드프레스 설정 자체는 인터넷상에서 충분한 정보가 있기 때문에 굳이 따로 언급하지는 않는다.

다만 주의할 점은 한가지 있다. 워드프레스의 각종 기능들을 업데이트하기 위해 ftp 기능을 사용한다.  하지만 ftp는 매우 보안상 취약한 놈이기 때문에 쓰지 말아야 한다. 이 방식보다는 다음의 방법을 통해 각종 테마나 플러그인을 업데이트할 수 있다.

다음의 두 사이트에서 원하는 걸 찾는다.

  • 플러그인: https://wordpress.org/plugins/
  •  테마: https://wordpress.org/themes/browse/new/

다운로드를 원하는 것을 찾았다면 다음의 방법을 해당 모듈의 다운로드 링크를 찾는다.

GetDownloadAddress

복사를 했다면 터미널에 접속해서 이걸 플러그인 혹은 테마 디렉토리에 wget 명령을 이용해서 다운받는다.

$ cd $WPINSTALL/wp-content/

해당 디렉토리에 보면 plugins, themes 라는 디렉토리가 존재하는 것을 확인할 수 있다.


$ wget <download-url>

$ unzip <downloaded_file>

$ mv <downloaded_file>

확인 후 워드프레스의 Dashboard를 통해 활성화시키면 적용 완료!  약간의 수고를 더하면 불필요한 위험을 굳이 감내할 필요가 없다.

끝.

]]> 28