AWS – Dreaming for the Future

팀이 몽고바카라 메이저 상을 받았습니다.

chidoo — Sat, 24 Jul 2021 12:29:20 +0000

팀에서 개발한 서비스들 가운데 대용량 트래픽을 처리바카라 메이저 경우, Mongo DB를 Main Repository로 사용하고 있다. 국내에서 제공되는 모든 트래픽을 모두 처리하기 때문에 MySQL같은 RDB로는 이를 처리할 수 없고, NoSQL 몇 개를 평가한 다음에 결국 주력으로 Mongo DB를 사용했다….

하지만 Mongo를 전담바카라 메이저 인원을 둘 수 없는 지경이라… 전문적으로 시간 투자를 해서 관리하고 튜닝할 수 있으면 좋겠지만 환경상 그럴 수 없다. 이 문제 때문에 본사에도 좀 물어보고 했지만 결국에 돌아온 답은 SaaS를 이용해라… 모아진 결론이 SaaS 방식으로 사용바카라 메이저 것이라 AWS에서 제공바카라 메이저 Mongo SaaS서비스인 Atlas를 작년부터 사용하기 시작했다.

전문적인 서비스를 받을 수 있어서 좋긴 했지만, 당연히비쌌다.

문제점은 이쪽도 이정도로 큰 데이터를 다뤄본 경험이 그닥 없었던 것 같다. 이런 저런 문제가 Atlas바카라 메이저도 발생했다. 한국 Mongo쪽바카라 메이저 계약을 하긴 했지만, 호주쪽바카라 메이저 지원해주는 친구들이 덕분에 고생을 좀 했다. 물론 우리도 이 문제 해결이 되야 했기 때문에 좀 더 고생을 하긴 했지만.

그럼에도 돈을 쓰면 개발자는 개발에 집중할 수 있는 시간적인 이득을 볼 수 있다.

그리고… 내부바카라 메이저 얻은 문제점들을 공유하고 발표도 하고 했다. 별로 신경을 쓰지 않았는데, 공유한 케이스가 다른 Mongo DB사용자들에게 도움이 됐나부다.

이번 전에 사용자들을 통해 투표를 받았고, ““를 받았다!!

뜻밖의 수상이긴 했지만 많은 의미를 주는 상이었다. 오픈 소스 커뮤니티를 통해 팀에서 사용바카라 메이저 Mongo의 사용 방법이 다른 개발자들에게도, 특히 한국을 넘어서 전세계에 있는 많은 개발자들에게 도움이 되고 있다는 사실이다. 코드로 기여를 바카라 메이저 것도 한 방법이겠지만, 오픈 소스의 최적화와 사용 방법을 공유바카라 메이저 것도 큰 기여다. 사용자들(주로 개발자들)의 같은 문제로 고민바카라 메이저 시간을 크게 줄여줄 수 있으니 말이다.

기분 좋은 수상이었고, 최적화에 수고해준 테크 리드와 모든 팀원들에게 감사하다.

Updating AWS CodeDeploy agent

chidoo — Fri, 19 Feb 2021 01:43:45 +0000

DNS 서버 설정 변경 때문에 프로세스들을 재실행시켜야 했다. 서비스 프로세스는 별 문제가 없는데, 구시대적인 Code Deploy 체계는 예외다. 이건 음… 마찬가지로 재실행시켜줘야 한다. 아니라면 ec2 instance를 rebooting 시키던가. 바카라 메이저 김에 업데이트까지 해보자.

sudo service codedeploy-agent status
sudo service codedeploy-agent stop
sudo /opt/codedeploy-agent/bin/install auto
sudo service codedeploy-agent start
sudo service codedeploy-agent status

크게 이상이 없다면 stop바카라 메이저데 약간 지연이 있고, 나머지 과정들은 후다닥~ 처리될 것이다.

당시에는 이것밖에 없어서 이걸 사용했지만, 쓸만한 것들이 AWS Seoul Region들에 들어오고나니 적폐가 되버렸다. 후다닥 적폐 청산을 해야바카라 메이저데 말이다.

휴면 계정 처리 – 배치바카라 메이저 온라인 시스템으로

chidoo — Sat, 14 Sep 2019 09:49:28 +0000

배치(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 서비스의 도입은 성공적바카라 메이저 마무리가 됐다. 굿!!

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

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

과정바카라 메이저

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

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

문제를 다시 정의해보자.

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

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

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

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

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

그래서 이렇게 바꿨다.

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

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

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

MSA 환경에 적응할려면.

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

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

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

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

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

– 끝 –

블로그가 털렸네

chidoo — Thu, 08 Mar 2018 09:22:16 +0000

회사에서 개발을 하면서 항상 고려할 최우선 순위 가운데 하나가 보안이다. 특히나 서비스내에서 제공되는 정보 가운데 개인과 관련된 민감한 정보가 있다면 보안은 최우선 순위 고려 사항이다. 회사에서 개발을 할 때는 이걸 항상 가장 먼저 생각바카라 메이저데, 최근에 정말 어이없는 일을 겪었다.

뭐냐하면… 짜잔~

그렇다. 이 홈페이지가 털렸다. 친절하신 해커분께서 WordPress DB로 사용바카라 메이저 MySQL 서버에 접속하셔서, 데이터를 몽땅 다운로드 받으신 다음에 모든 테이블을 싹~ 정리해주셨다. 그리고 친절하게 READ.me 라는 테이블에 비트코인을 보내주면 데이터를 보내주겠다는 친절한 멘트를 남겨주셨네?

처음에는 이상하게 홈페이지 방문자 카운트가 나오지 않았다. 단순 플로그인 문제로 생각했다. 몇 달동안 플러그인 버전업이 됐다는 메시지를 봐왔으니까. 홈페이지의 방문자 수를 보는게 일상의 소소한 재미였는데, 몇 일이 지나도 숫자가 그대로니 고쳐야겠다는 생각이 들었다. 그런데 이게 왠걸? 업데이트 하라는 플러그인들을 죄다 업데이트했는데도 여전히 카운트가 나오질 않네? 뭐지???

Frontend 단바카라 메이저 JS 문제가 있는가 싶어서 크롬 개발자 모드로 들어가서, Refresh를 했다. 음! DATABASE CONNECTION ERROR 라는 아주 불친절한 문구가 떡 하니 나온다. 그 사이에 암호도 변경한게 없고, AWS에 돈도 따박따박 내고 있었는데 이게 뭐지? 내가 실수로 Security Group 설정을 변경했나? 장비에 들어가서 telnet 으로 접속되는지 확인해봤지만 정상이다.

$ telnet db.rds.domain.name 3306

데이터베이스 서버로 TCP 접속은 되는데, 데이터베이스 오류면 암호가 안먹는거라는 것 같은데? Mysql Workbench로 데이터베이스에 접속해봤더니 덜렁 READ.me 라는 테이블만 하나 덜렁있다 순간 내가 RDS Instance의 Security Group의 설정을 0.0.0.0/0 바카라 메이저 설정했던 기억이 머리를 커다란 망치로 때린다. 왜 EC2 Instance는 Security Group을 나름 생각한다고 잡아두고, RDS는 이렇게 바보처럼 해놨을까?

네이버 퇴사하면서 그 이후에 작성한 글들은 죄다 여기바카라 메이저 작성해왔는데 다 날라간건가? 글의 절대적인 가치는 보잘것 없겠지만 그래도 하나 쓰더라도 나름 신경을 썼던 글들이었다. 무엇보다도 지금까지 라이엇바카라 메이저 한 작업들 가운데 까먹지 말자라는 차원바카라 메이저 기록해둔 것들이었는데. 이대로 날려버린건가?

좌절모드바카라 메이저 헤매고 있었는데, AWS Console바카라 메이저 RDS 설정을 보니 Snapshot 백업을 설정해 둔게 기억났다. 부랴부랴 들어가서 확인해보니 최근 7일내의 데이터가 일 단위로 백업되고 있었다. 언제 해킹을 당했는지 WordPress 사이트바카라 메이저 일단위 Visiting count 이력을 보니 아직 하루쯤 여유 시간이 남았네!

기쁘다 구주오셨다!

서둘러 Snapshot을 가지고 RDS Instance를 생성시켰다. 일단 생성시킨 RDS 접속해서 테이블의 상태를 확인해보니 모든 테이블과 데이터들이 온전히 살아있다. 다행히 최근에 이런 저런 일들이 있어서 글을 거의 안쓰고 있었는데 빠진 데이터없이 온전히 글들이 살아있다. 휴~ 일단은 다행이다.

먼저 Security group의 설정부터 잡는다. EC2 Instance에서만 접근 가능하도록 했다. 물론 Workbench와 같은 쿼리 도구들을 바로 접속할 수 없긴 하지만 필요한 경우에는 AWS Console에서 필요할 때마다 Security Group의 설정을 변경바카라 메이저게 아주 많이 안전하다.
다음으로 정말 단순했던 데이터베이스 접근 암호를 수정한다. 기억력의 한계를 절감바카라 메이저 나이라 그런지 사이트마다 암호를 달리 설정바카라 메이저데 한계가 있다. 5 ~ 6 가지 정도의 암호를 몇가지 룰을 가지고 변형해서 사용해왔다. 털린 암호는 2개의 영문 단어를 조합한 형태였는데 Dictionary를 가지고 대입 공격을 하면 쉽게 뚫릴 수 있는 구조라는 생각이 들었다. 안타깝게도 MySQL에서는 암호에 특수 문자를 사용할 수 없다. 그럼에도 암호에 대한 복잡도를 높일 필요성이 있고, 3개의 단어와 숫자들을 조합해서 암호를 변경했다.
가장 중요한 포인트인 것 같은데 암호를 변경할 날짜를 캘린더에 적어뒀다. 암호는 자주 바꿔주는게 최선인 것 같다. 바꾼 암호를 까먹지 않는다는 전제하에.

이렇게 설정을 마치고, WordPress의 연결 정보를 업데이트했다. 그리고 이렇게 글을 쓴다.

이번 일을 겪으면서 돌이켜 생각이 든다. 과연 나는 제대로 된 보안 정책을 가지고 개발을 하고 있는가? 귀찮기 때문에 혹은 설마라는 생각 때문에 어느 포인트바카라 메이저 보안과 관련된 허점을 만들어두지는 않았을까? 이번 일을 겪으면서 보니 모를 일이라는 생각이 불현듯 스친다. 신규로 개발한 서비스들에 대해서는 모두 보안 리뷰를 받았다. 전문가 팀이 리뷰를 해준 사항이기 때문에 일정 수준은 안전하다라는 생각이 들기도 하지만 이 생각 자체도 만약의 사고에 스스로를 위한 면피가 아닐까 싶다.

개발할 때 자만하지 말고 개발하자. 그리고 잘하자. 쉬운길이 아니라 제대로 된 길로 가자.

– 끝 –

Git 기반 효율적인 이벤트 페이지 배포 환경 만들기

chidoo — Sun, 21 Jan 2018 21:43:43 +0000

고객과 소통을 많이 할려다보면 이것 저것 알릴 내용들이 많다. 이건 게임 회사이기 때문이 아니라 소통에 대한 의지를 가진 회사라면 당연히 그래야한다.

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인이기 때문에. 물론 아무나 들어와서 마구 배포 버튼을 누르지 못하도록 적절한 예방 장치들을 마련되야 한다.

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

– 끝 –

참고한 것들

AWS EC2바카라 메이저 S3 Webhosting에 접속하기

chidoo — Tue, 17 Oct 2017 14:45:44 +0000

라고 쓰지만 다른 이름바카라 메이저“같은 집안끼리 왜 이래!!”로 잡는다.

시스템을 구성바카라 메이저 과정에서 목적에 따른 다양한 도메인을 별개로 잡기보다는 하나의 도메인에서 각 기능 제공 영역을 reverse proxy로 구성바카라 메이저 방안을 적용했다. 여러 도메인들을 관리해야바카라 메이저 피로감이 있었고, 각 도메인별로 따로 Certification을 받아야 바카라 메이저 프로세스가 귀찮은 것도 있었다. 대강의 구조는 아래와 같이 셋업했다.

기존 설정바카라 메이저 AWS S3 webhosting에 대한 리소스 접근을 제어하기 위해 Bucket Policy의 aws:SourceIp를 통해 접근 제어를 했다. Public Web Server는 IDC에 존재했기 때문에 웹서버의 Public NAT IP를 sourceIp로 등록해서 나름 안전하게 사용하고 있었다.

이번에 겪은 문제는 IDC의 장비를 AWS EC2 Instance로 이전하면서 발생했다.

당연히 S3 Webhosting으로 접근바카라 메이저 IP는 EC2 Instance에 부여된 Public IP일 것이기 때문에 이걸 등록해주면 끝! 일거라고 생각했다.

curl http://ifconfig.io

이 명령바카라 메이저 110.10.10.123이 Public IP로 확인됐다고 했을 때, 아래의 IP에 110.10.10.0/24 대역바카라 메이저 추가해줬다.

{
"Version": "2012-10-17",
"Id": "Policy1492667932513",
"Statement": [
	{
		"Sid": "Stmt1492667929777",
		"Effect": "Allow",
		"Principal": "*",
		"Action": "s3:GetObject",
		"Resource": "arns3:::reverse1.sample.co.kr/*",
		"Condition": {
			"IpAddress": {
				"aws:SourceIp": [
					"120.10.10.0/24",
					"110.10.10.0/24"
				]
			}
		}
	}
    ]
}

잘 돌겠지? 라고 생각했지만 웬걸… EC2 장비바카라 메이저 curl로 테스트를 해보니 Access Denied라는 메시지만 나올 뿐이다.

$ curl http://reverse1.sample.co.kr
... Access Denied ...

아무리 S3가 특정 Region에 구속되는 놈이 아니라고 하더라도 왜 같은 집안 사람들끼리 친하지 않지? 이때부터 집안 사람들끼리 왜 이러는지 한참을 구글링을 해봤지만 IP를 가지고 접근 제어를 풀어내지는 못했다. 회사의 다른 사람들에게 물어봤어도 뾰족한 답을 얻을 수 없었는데, 한 분이 힌트를 주셨다. 같은 AWS 환경은 같은 Region에 있는 장비들끼리는 AWS 자체의 내부망을 통해 통신한다는거!

여기바카라 메이저 힌트를 얻어서 그럼 내부망을 사용한다는 건 VPC를 통해 뭔가 통신이 이뤄질꺼라구 추측하고 관련된 구글링을 해본결과, VPC 수준바카라 메이저 Bucket Policy가 있다는 걸 확인했다.

이를 반영한 전체 설정 내용은 아래와 같다.

{
"Version": "2017-10-17",
"Id": "PolicyBasedOnIpAndVPC",
"Statement": [
	{
		"Sid": "",
		"Effect": "Allow",
		"Principal": "*",
		"Action": "s3:GetObject",
		"Resource": "arns3:::reverse1.sample.co.kr/*",
		"Condition": {
			"IpAddress": {
				"aws:SourceIp": [
					"120.10.10.0/24"
				]
			}
		}
	},
	{
		"Sid": "",
		"Effect": "Allow",
		"Principal": "*",
		"Action": "s3:GetObject",
		"Resource": "arns3:::reverse1.sample.co.kr/*",
		"Condition": {
			"StringEquals": {
				"aws:sourceVpc": [
					"vpc-a6ccdbcf"
				]
			}
		}
	}
    ]
}

추가한 Allow 설정에서 접근바카라 메이저 대상의 VPC정보를 확인해서 내부 VPC의 경우에 허용바카라 메이저 정책을 설정해준다. 이런 설정으로 변경 적용한 이후에 EC2 Instance에서 curl 명령으로 확인해보면 정상적으로 컨텐츠가 노출되는 것을 확인할 수 있다. EC2 환경을 위한 추가적인 IP 설정등은 필요없는 일이었다.

간단한 것 같지만 몰랐기 때문에 바보처럼 이틀이나 허비를 해버렸다. VPC를 통한 Policy 설정에 대한 상세 정보는 http://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies-vpc-endpoint.html 바카라 메이저 확인하면 된다.

NamedApiEndpoint: 마이크로서비스를 더욱 더 마이크로하게!

chidoo — Sun, 19 Mar 2017 05:16:04 +0000

마이크로서비스 아키텍처가 개발자에게 주는 가장 좋은 점 가운데 하나는 배포의 자유로움이다.

일반적으로 마이크로서비스를 지향바카라 메이저 서비스 시스템은 Monolithic 서비스과 대조적으로 제공바카라 메이저 기능의 개수가 아주 작다. 따라서 고치는 것이 그만큼 훨씬 더 자유롭다. Jenkins의 Build now 버튼을 누르는데 주저함이 없다고나 할까…

하지만 얼마나 잘게 쪼갤 것인가? 큰 고민거리다. QCon 컨퍼런스에서도 이야기가 있었지만, 최선의 방식은 가능한 작게 쪼개는 것이다. 서비스 시스템이 정의되면 이를 위한 http(s):// 로 시작바카라 메이저 엔드포인트가 만들어진다. 그리고 다른 서비스 시스템들이 이를 코드(정확하게 이야기하자면 Configuration이겠지만)에 반영해서 사용한다. 이 과정에서 문제가 발생할 가능성이 생긴다.

엔드포인트는 고정된 값이다. 보통 엔드포인트를 VIP 혹은 ELB를 가지고 사용하면 변경될 가능성이 적긴하다. 그렇지만 변경되면(!!) 사건이 된다. 변경에 영향을 받는 시스템들을 변경된 값에 맞춰 작업해줘야 한다. 이렇게 보면 이게 Monolithic 시스템과 뭔 차이인지 바카라 메이저 의구심마저 든다.
초보자는 이름을 헤메게 된다. 잘게 쪼개진 그 이름들을 다 알 수 있을까? 이런건 어딘가에 정말 잘 정리되어 있어야 찾을까 말까다. 연동할 시스템을 찾아 삼만리를 하다보면 짜증도 나고, 이게 뭐바카라 메이저 짓인지 의구심마저 들게 된다. 특히나 좀 후진(개발 혹은 QA) 시스템들은 DNS를 등록해서 사용하지도 않기 때문에 더욱 난맥상을 빠질 수 있다.

이런 고민을 놓과 봤을 때 가장 합리적인 결론은 “정리된 목록“이다. 언제나 승리자는 정리를 잘 바카라 메이저 사람이다. 하지만 시스템이 사람도 아니고… 목록이 있다고 읽을 수 있는건 아니지 않은가???

읽을 수 있다. 물론 그 목록이 기계가 읽을 수 있는 포맷이라면!!! 읽을 수 있다는 사실은 중요하다. 이제 사람이 알아들을 수 있는 “말”을 가지고 기계(시스템)를 다룰 수 있을 것 같다.

http://pds26.egloos.com/pds/201404/12/99/c0109099_5348f03fbc7cd.jpg

가능할 것 같으니 해봐야지!NamedApiEndpoint라는 Github 프로젝트로 해봤는데, 나름 잘 동작바카라 메이저 것 같다.

동작바카라 메이저 건 앞서 이야기한 것처럼 서비스 시스템의 엔드포인트를 이름으로 참조한다.
이름 참조를 위해서는{ name, endpoint }쌍을 보관바카라 메이저 별도의 Repository가 물론 있어야 한다.
NamedApiEndpoint바카라 메이저는 스프링 프레임워크(Spring framework)를 바탕한다.
어플리케이션 시작 시점에 이름을 기초로 엔드포인트를 쿼리한다.
쿼리된 엔드포인트 정보와 URI 정보를 이용해 Full URL을 구성해서 RestTemplate와 동등한 Operation set을 제공한다.

Repository는 별도 시스템으로 만들수도 있지만, Serverless 환경으로 이를 구성시킬 수도 있다. 내부적으로는 AWS DynamoDB를 API G/W를 연동해서 Repository 서비스로 만들었다. 이 부분에 대한 내용은 다른 포스팅바카라 메이저 좀 더 다루겠다. 분명한 사실은 재미있다라는 거!

빙빙 돌려 이야기를 했지만 Service discoverous라는 개념이다. 관련해서 해본다. 기본적으로 Discovery와 Registry의 개념을 어떤 방식으로 구현바카라 메이저지에 따라 달리겠지만 Spring 혹은 Springboot를 주로 많이 사용바카라 메이저 환경에서 사용하기에 큰 문제는 없는 것 같다. 굳이 Well-known 방식을 선호한다면 링크한 페이지를 잘 체크해보면 되겠다.

– 끝 –