ryanpark.dev

About Me

😊

About Me

POST

Development

Post

if kakao 2019 Day1 후기

development

8/29/2019

Intro

Project Euler 문제를 풀면서 수학적인 사고와 새로운 프로그래밍 언어를 학습하고 익혀갔습니다. 수학문제를 푸는 것을 좋아하고 평소에 알고리즘 문제를 푸는 것을 좋아했기에 적합한 난이도 였습니다. 초반에 나온 문제들은 수학적으로 많은 사고를 요구하지 않습니다. 그래서 새로운 언어를 익힐 때 ‘어떤 예제를 짜볼까’ 고민을 많이 하게 되는데, 개인적으로 여기에 나오는 문제들이 그러한 고민을 많이 해소해주었습니다.

Solution

아직 문법적으로 미숙한 상태에서 풀어가기에 부족한 점이 많이 보일 수 있습니다. 좀 더 개선할 수 있는 부분이 보이면 이글의 댓글이나, 링크에 있는 github issue에 올려주시면 감사합니다 🙂

Project Euler Solutions

development

8/19/2019

1. Makefile에 help 타겟 추가

help: @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}'

2. help 에 노출하고 싶은 곳에 설명추가

##으로 해당 타겟에 대한 설명추가

prod-deploy: ## Deploy Production dep deploy production -v -p

완료된 파일

Makefile

help: @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' prod-deploy: ## Deploy Production dep deploy production -v -p prod-rollback: ## Rollback Production dep rollback production -v -p prod-unlock: ## Unlock Production dep deploy:unlock production -v

결과

ryan@macbook:~/deployer$ make help prod-deploy Deploy Production prod-rollback Rollback Production prod-unlock Unlock Production

Makefile에서 help target 추가하는 법

development

4/24/2018

1. “/etc/munin/plugin-conf.d/munin-node” 내용 확인

... [mysql*] user root env.mysqlopts --defaults-file=/etc/mysql/debian.cnf #env.mysqluser debian-sys-maint env.mysqluser root env.mysqlconnection DBI:mysql:mysql;mysql_read_default_file=/etc/mysql/debian.cnf ...

해당 내용을 통해 /etc/mysql/debian.cnf을 이용해 접속한다는 것을 확인 가능하다.

2. “/etc/mysql/debian.cnf” 에서 접속정보(user, password) 변경

# Automatically generated for Debian scripts. DO NOT TOUCH! [client] host = localhost #user = {$sys_maint_user} #password = {$sys_maint_password} user = {$user} password = {$password} socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] host = localhost #user = {$sys_maint_user} #password = {$sys_maint_password} socket = /var/run/mysqld/mysqld.sock basedir = /usr

3. munin 플러그인 설정 명령어 확인

4. munin-node 재시작

# sudo service munin-node restart // 재시작 후 munin 그래프가 생성이 안될시에 아예 stop 후 start 시도 # sudo service munin-node stop # sleep 5 # sudo service munin-node start

참고

http://munin-monitoring.org/wiki/munin-node-configure

Munin에서 mysql plugin 세팅방법

development

development>DB

4/11/2018

terraform을 이용해서 인프라를 관리하다가 보면 노출되면 안되는 값을 코드로 작성해야 될 상황이 생긴다. 예를 들어, terraform으로 RDS를 생성할 때 마스터의 비밀번호가 한 예이다. terraform을 아래와 같이 작성해 버리면 해당 코드나 관련 저장소를 볼 수 있는 모두가 DB의 마스터 비밀번호를 알게되서 보안상 취약하게 된다

resource "aws_db_instance" "db-sample" { ... password = "master-password123!" ... }

그래서 이를 해결하기 위해 AWS에서 제공하는 KMS를 통해 비밀번호를 암호화하는 방법을 공유하고자 한다.

1. KMS Key 생성

KMS 암호화를 하는데 사용될 key를 생성해야 한다. AWS 공식문서를 따라하면 쉽게 만들수 있다.

2. 비밀번호를 암호화

터미널창을 열고 아래 비밀번호를 별도 파일로 만들어둔다.

$ echo -n 'master-password123!' > plaintext-password

그리고 아래 명령어를 실행한다. 이때 $key_id는 1번에서 KMS key를 생성하고 나서 생성된 key의 id를 넣어줘야 한다. 혹시 터미널에 AWS CLI 구성이 안되어 있으면 여기를 참고하기 바란다.

$ aws kms encrypt \ --key-id $key_id \ --plaintext fileb://plaintext-password \ --output text --query CiphertextBlob

실행하고 나면 아래와 같이 암호화된 문구가 출력이 된다.

$ aws kms encrypt \ --key-id $key_id \ --plaintext fileb://plaintext-password \ --output text --query CiphertextBlob AQICAHi1tzJHZQT30hQmf3yueEfl/t9tZ2L+7jqr6IcHddQEV1guYe/AlotboEYBuPA

이것을 terraform에에 아래와 같이 추가하여 세팅해주면 끝난다.

data "aws_kms_secret" "db" { secret { name = "master_password" payload = "AQICAHi1tzJHZQT30hQmf3yueEfl/t9tZ2L+7jqr6IcHddQEV1guYe/AlotboEYBuPAAAAajBoBgkqhkiG9w0BBwagAzPleEZAgEAMFQGCSqGSIb3DwEQQMYzETfPvyHhzpT8tvGAntNu/P2fexBnxRTa2L6T4w/d3z/5mxeTGk/aM=" } } resource "aws_db_instance" "db-sample" { ... password = "${data.aws_kms_secret.db.master_password}" ... }

Terraform에서 KMS Encryption 사용법

development

development>AWS

4/4/2018

IOS 개발하는데 있어서 참고적으로 알고 있어야 메모리 관리에 대해 적어보려고 한다. 메모리를 관리하는데 있어서 3가지지의 방식이 존재한다.

가비지 컬렉션

수동 레퍼런스 카운팅 및 오토릴리즈

자동 레퍼런스 카운팅

1. 가비지 컬렉션 (GC, Garbage Collection)

가비지 컬렉션은 JAVA를 사용해본 사람이라면 누구나 알고 있는 것이다. 동일한 것이라고 생각하면 되는데, 잠시 가비지 컬렉션의 특징에 대해 잠시 짚고 넘어가자. 가비지 컬렉션은 런타임 중(=앱이 실행되고 있는 동안)에 내가 생성했던 오브젝트가 현재 사용중인지 아닌지를 모니터링을 주기적으로 하다가, 사용중이지 않은 오브젝트가 많이 쌓이기 시작하면 불필요한 오브젝트를 제거해서 사용 가능한 메모리 공간을 확보하는 방식이다. 이런 방식때문에 아래와 같은 단점이 있다.

어떤 오브젝트가 사용중인지 아닌지 확인하고 메모리를 해제하는데 별도 비용이 발생한다. 그렇기 때문에 메모리 관리를 제대로 하지 않고 개발을 하게되면, 가비지 컬렉션이 자주 동작하게 되고 이로 인해 전체적인 앱 성능이 저하된다.

가비지 컬렉션이 언제 일어나는지 개발자 입장에서 예측할 수가 없다. 그렇기 때문에 앱을 어느 상황이든 실시간으로 빠르게 이용하고 싶어하는 사용자의 입장에선 안좋은 UX경험이 될 가능성이 있다.

2. 수동 레퍼런스 카운팅 및 오토릴리즈

이건 쉽게 생각해서 수동으로 현재 생성한 오브젝트가 몇 군데에서 사용중인지 갯수를 카운팅하는 것이다. A를 객체를 만들고 A를 사용하고 있는 사용처가 생기면 +1, 사용 후 필요가 없으면 -1하는 개념이라고 생각하면 된다. 사실 중요한건 3번이기에 ‘대충 이렇군아’하고 넘어가자.

3. 자동 레퍼런스 카운팅 (ARC, Auto Reference Counting)

바로 위에서 말한 2번의 개념을 자동으로 컨파일러가 해주는 것이다. 여기서의 핵심은 컴파일러가 해준다는 것이다. 그렇기 때문에 앱을 빌드(=컴파일)하는 시점에, 2번에서 처럼 우리가 수동으로 레퍼런스 참조하는 곳에서 카운팅을 +1 또는 -1하는 코드를 넣어야했던 것을 컴파일러가 자동으로 대신해주는 것이다.

가비지 컬렉션 != ARC

많은 이들이 가비지 컬렉션과 ARC을 동일한 것으로 착각하는데, 그렇지 않다. ARC는 가비지 컬렉션과 다르게 런타임이 아닌 컴파일 단계에서 처리가 된다. 이때문에 ARC는 런타임 중(=앱이 실행되고 있는 동안)에 메모리 관리를 위해 별도 비용이 발생하지 않는다. 또한 1번에서 언급했던, 가비지 컬렉션이 런타임중에 실행되면서 발생하는 두가지 단점들이 ARC에서는 모두 해결이 된다.

메모리 관리와 ARC

development

4/2/2018

ssh로 접속시에 실수에 의해 비밀번호를 자주 틀리게 되면 sshguard에 의한 해당 ip가 차단되는 경우가 있다. 이럴 경우 다른 서버를 통해 접속하고자 하는 서버에 접속 후 아래 명령어들을 통해 해결할 수 있다.

$ sudo iptables -L sshguard --line-numbers --numeric Chain sshguard (1 references) num target prot opt source destination 1 DROP all -- 192.168.0.123 0.0.0.0/0 $ sudo iptables -D sshguard {num}

sshguard에 의해 접속 실패하는 경우 해결방법

development

4/1/2018

1. Isolation Level

여러개의 트랜잭션에서 변경되고 수행되는 쿼리가 동시에 일어났을 때, 성능과 신뢰, 일관성 사이에서 균형을 잡는 수준이다. 예를 들어서 한 트랜잭션에서 A라는 데이터를 수정하고 아직 커밋이 되지 않은 경우, 다른 트랜잭션은 A라는 데이터에 락을 걸어 접근할 수가 없게 할 수 있다(Read Committed Isolation Level인 경우). 반면 Isolation Level을 조정하여, 한 트랜잭션에서 A라는 데이터를 B라고 수정하고 아직 커밋이 되지 않은 경우, 다른 트랜잭션은 B라는 데이터에 접근할 수 있게 할 수도 있다(Read Uncommitted) 이렇게 위에 예시로 든 2개를 포함하여 총 4개의 Level이 존재하는데, 이 중에서 innoDB의 기본값인 Repeatable Read Isolation Level에 대해서 설명하고자 한다.

2. Repeatable Read Isolation Level

하나의 트랜잭션내에서 첫 번째 SELECT 쿼리가 실행되었을 때 스냅샷을 찍어서 타 트랜잭션의 변경사항과 상관없이 SELECT 결과를 계속해서 같은 상태로 보여주는 것이다. 예를 들어 아래와 같은 테이블이 있다고 가정해 보자.

CREATE TABLE `table_1` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `val` tinyint(3) unsigned DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

그리고 아래와 같이 (1), (2) (3) 순으로 쿼리가 실행되었다고 가정해 보자

## A 트랜잭션 START TRANSACTION; SELECT * FROM table_1 WHERE id = 1; # (1) => 결과가 (id =1, val = 5) 나왔다고 가정. SELECT * FROM table_1 WHERE id = 1; # (3) => B 트랜잭션의 (2)에서 update가 이루어졌지만 repeatable isolation level에 의해 (1)의 결과와 동일하게 나옴 COMMIT; # B 트랜잭션 START TRANSACTION; UPDATE table_1 SET val = 2018 WHERE id = 1; # (2) => (1) 에서 select 했던 row의 데이터를 변경함 COMMIT;

여기에서 주의해야 할 것이 있는데, 바로 첫 SELECT 쿼리가 실행되었을 때 스냅샷을 찍는다는 것이다. 아래 두가지 예시를 비교해보면 이해가 될 것이다.

1) 첫번째 예시

## A 트랜잭션 START TRANSACTION; SELECT * FROM table_1 WHERE id = 500; # (1) => 해당 row가 비어서 empty set이 나왔다고 가정 SELECT * FROM table_1 WHERE id = 500; # (3) => (1)과 동일하게 empty set이 나옴. (1)의 첫 SELECT 쿼리에서 스냅샷을 찍고 스냅샷의 데이터를 읽기 때문에 계속해서 동일하게 (1)번의 결과가 나옴 COMMIT; ## B 트랜잭션 START TRANSACTION; INSERT INTO table_1 (`id`, `val`) VALUES(500, 999); # (2) => id=500에 데이터를 새로 추가해 줌 COMMIT;

2) 두번째 예시

위의 첫번째 예시와 동일하게 id=500인 row가 없다고 가정.

## A 트랜잭션 START TRANSACTION; INSERT INTO table_1 (`id`, `val`) VALUES(200, 300); # (1) => id=500과 상관없는 데이터를 삽입. SELECT * FROM table_1 WHERE id = 500; # (3) => (id = 500, val = 999) 데이터가 나옴 (3)번 이전에 스냅샷을 찍은적이 없기에 B 트랜잭션의 (2)에서 새로 추가된 값을 읽음 COMMIT; ## B 트랜잭션 START TRANSACTION; INSERT INTO table_1 (`id`, `val`) VALUES(500, 999); # (2) => id=500에 데이터를 새로 추가해 줌 COMMIT;

Book

Post

My Life

Post

2018년도는 나에게 많은 일이 있었던 해였다. 임시적이었지만 5명 정도 되는 팀을 이끄는 매니저가 되었었고, 2년 정도 함께 했던 팀(스토어팀)에서 다른 팀(뷰어팀)으로의 인사이동도 있었다. 회사에서의 변화와 더불어 학교에 복학하여 일과 학업을 1학기 정도 병행하게 되었다. 이 외에도 많은 일들이 있었지만, 내게 가장 의미있던 매니저가 된 이야기와 팀 인사이동에 대한 이야기 그리고 그 외 부수적인 이야기로 회고하려 한다.

2. 본론

2-1. 주니어가 매니저가 되다

먼저, 매니저가 되게 된 배경을 적어 보는 게 좋을 것 같다. 스토어팀은 크게 백엔드 파트와 프론트엔드 파트로 나뉜다. 당시 정확히 기억은 안 나지만 백엔드 파트는 10명 정도 있었던 것 같다. 백엔드 파트는 겉으로 보았을 때는 잘 굴러가는(?) 것 처럼 보였지만, 결제관련 코드의 복잡성이 높다라는 큰 문제가 있었다. 여러 클래스들이 얽혀있었고, 추상화가 되지 않아 결제 수단이나 상품 타입(단권도서인가 세트도서인가 같은)에 따라 if-else의 향연이었다. 이를 위해 리팩토링이 필요하다는 인식을 오래 전부터 하고 있었고, 매 분기 마다 마일스톤으로 잡혀있었지만, 계속 되는 서비스 요구사항의 대응에 1년 동안 진행을 하지 못하고 있었다. 이를 해결하기 위해 백엔드 파트를 결제 스쿼드와 서비스 스쿼드로 나눠서 좀 더 결제 도메인에 집중할 수 있도록 하였다. 이렇게 나뉘고 결제 도메인에 대한 집중도가 높아지면서 리팩토링도 진행되게 되고, 지금의 리디페이가 나올 수 있었지 않나 생각이 된다. 나는 이렇게 나눠진 서비스 스쿼드의 임시 매니저를 맡게 되었다.

2-1-1. 나는 무엇을 배웠나

대략 5개월 정도의 짧은 기간이었지만 많은 것을 배운 시기였던 것 같다. 특히나 개발 외적인 부분에서 많이 배울 수 있었던 시간이었다. 타 팀과 커뮤니케이션 하는 방법, 팀원들에게 적절한 태스크 분배, 프로젝트 일정관리 등 많은 것들이 고민의 연속이었지만, 이 고민들을 해결 해나가면서 스스로 답을 찾아갔던 것이 큰 공부가 되었다. 처음에는 정말 폭풍 같았다. 잦은 회의와 팀원들이 쏟아내는 태스크들(예를 들어 배포나 코드리뷰와 같은) 때문에 정작 내가 해야 될 업무를 할 시간이 없었다. 하루 종일 Asana를 통한 타 팀과의 커뮤니케이션과 팀원들의 태스크 관리를 하느라 코드한줄 적지 못한 채 퇴근한 적도 많았다. 이를 해결하게 도와준 도서가 있는데, 몽키 비즈니스라는 책이다. 매니저를 맡게 되면서 읽어보라고 추천받은 도서인데, 여기선 원숭이를 하나의 태스크로 정의하고 있다. 이 책을 통해 매니저로서 많은 것을 배울 수 있었던 것 같다. 여기서 이 책의 내용을 설명할 순 없지만, 이를 통해 팀원에게 분배된 태스크가 잘 진행되고 있나 수시로 모니터링 하지 않게 되었고, 나의 업무에 조금 더 집중할 수 있게 되었다.

2-1-2. 짧은 기간의 아쉬움

매니저 역할을 하면서 가장 큰 아쉬움은 매니저를 할 수 있었던 기간이 너무 짧았다는 것이다. 물론 내가 학교 복학을 하지 않고 미루었다면 계속할 수 있었겠지만 그래도 아쉬움이 많이 남는다. 특히 내가 팀원들에게 태스크를 분배하면서 가장 많이 했던 실수가 있었는데 그 해결책을 아직도 못 찾은 것이 아쉽다. 그 실수는 팀원들에게 간단하다고 생각되는 태스크를 주었는데, 막상 코드를 수정하다보니 일이 커지게 되는 경우가 많았던 것이다. 2주가 넘게 태스크를 진행하다가 일이 너무 커져서 홀딩 되는 경우도 있었고, 내가 잘못된 해결방안을 제시해서 처음부터 다시 개발을 하게 되는 경우도 있었다. 내가 좀 더 도메인 분석을 잘하고 태스크를 줬다면 이런 실수가 안 나왔을 것 같다고 생각도 들지만 사실 이게 정답은 아닌 것 같다. 내가 제시한 방향대로 개발하는 것이 아니라 스스로 고민해보고 분석해서 나보다 더 좋은 제시를 하는 것이 정답인 것 같은데, “팀원 스스로가 그렇게 할 수 있도록 어떻게 만들까”에 대한 해답은 아직 찾지 못하였다.

2-1-3. 그래도 잘한 것

그래도 잘 했다고 생각하는 것 한 가지를 뽑자면, 도메인 지식의 이중화인 것 같다. 서비스 안정화를 위해 애플리케이션 서버 이중화나 DB 이중화를 하듯, 팀원들이 갖고 있는 도메인 지식에 대한 이중화도 필수적이라고 생각한다. 실제로 당시에 CRM(고객 관계 관리, 알림센터나 앱푸시 이메인 전송)에 대한 안정화를 진행 하고 있는 중이었는데, 장애가 발생했을 시에 대응할 수 있는 팀원이 1명뿐이었다. 그래서 항상 CRM 장애 관련 대응 태스크는 한 명에게만 쏠려 있었다. 이를 해결하기 위해, CRM과 같이 큰 도메인의 경우엔 도메인 지식을 공유하는 자리를 별도로 만들어 싱크를 맞추었다. 더불어, 두 명이 한 쌍을 이뤄서 CRM 관련 다양한 태스크를 함께 해결하도록 하였다. 또한, 특정 도메인에 대한 이해도가 높은 팀원에게 주면 효율적으로 빨리 끝낼 수 있을 태스크도 되도록이면 익숙하지 않은 다른 이에게 주려고 적절한 태스크 분배를 하였다.

2-2. 새로운 팀으로 이동하다

학교 복학 시점과 동시에 타 팀으로의 인사이동 기회를 얻게 되었다. 스토어팀에서 갖고 있던 여러 도메인(별점/리뷰, 선호작품 등)이 타 팀으로 오너쉽이 넘어가게 되었고 그 작업을 새로운 팀으로 이동하여 진행할 수 있게 되었다. 물론 내가 거절하고 스토어팀에 계속 남을 수도 있었지만, 이동하기로 결정하였었다. 이 결정을 내리게 된 2가지 이유가 있었다. 첫 째로는 2년이란 긴 시간을 한 팀에 있다 보니 내가 ‘우물 안 개구리는 아닐까’라는 생각이 들기 시작했기 때문이다. 스토어팀에서 많은 것을 배우고, 해봤지만 ‘이게 정말 맞는 걸까’, ‘다른 방법은 없을까’라는 생각이 들었다. 그래서 새로운 팀에서 새로운 사람들과 함께 일하면서 익숙함에서 벗어나고자 했다. 두 번째는 새로 옮겨지는 팀에서 맡게 될 업무가 만족스러웠다. 하나의 서비스를 처음부터 쭉 만들어 본 경험이 없었는데, ‘언어를 무엇을 쓰고 어떤 프레임워크를 쓸지’부터 시작해서 인프라 구성, CI/CD 구축까지 모두 혼자 할 수 있는 기회를 얻게 되었다. 더구나 스토어 팀에서 조금씩 해보았던 것들이라, 크게 부담감이 느껴지지 않았다. 아직까지 이때의 선택을 후회하진 않는다. 아마 앞으로도 후회하진 않을 것 같다. 이 태스크와 관련한 회고는 어느 정도 완료된 후에 하도록 하겠다.

2-3. 나는 올해 성장하기 위해 무엇을 했나

나는 스스로 성장하기 위한 방법으로 주로 책을 읽는다. 올해 읽었던 책은 아래와 같다.

2018년도 회고

my life

my life>회고

12/31/2018

소개

이 글의 모든 내용은 내가 출석하고 있는 교회내에 있는 “재정학교”라는 훈련을 바탕으로 기록하였다. 이 글을 작성 중인 시점은 아직 훈련을 받고 있는 중이라 내가 잘 못된 이해로 작성되었을 수도 있고, 같은 말씀을 읽어도 개개인이 다른 시각으로 이해할 수 있기 때문에 단순 참고용으로만 받아들이길 바란다. 이 것을 내가 이렇게 요약해서 공유하는 이유는 여러가지가 있다. 아직 훈련의 초반부임에도 불구하고 나만 알고 있기엔 아깝다는 생각이 든 것이 첫번째이고, 그 다음으로는 요즘 금수저, 은수저, …, 흙수저라는 말이 나오는 시대 가운데서 나의 또래(9x년생)에겐 재정, 돈, 재산을 어떻게 관리하고 바라봐야 할 지 어려울거란 생각이 들어서이다. 이 글이 여러 그리스도인에게 도움이 되고 도전이 되길 바란다. 더불어 현재 이 글을 읽고 있는 자신이 기독교인이 아니라도 현재 재정적인 어려움과 고민이 있다면 한 번이라도 훑어보길 권한다.

컴퍼스 머니맵

아래 표를 보고 자신의 현재 위치를 파악하고, 참된 재정적 자유를 이루기 위해 다음 스텝이 무엇인지 확인해 보자.

참고도서

청지기 성경적 재정 교육(하워드 데이튼 저자 / 한국청지기아카데미 번역 / 한국청지기아카데미) 돈에 넘어진 성경의 사람들(척 벤틀리 지음 / 왕진무 옮김 / 한국청지기아카데미)

*혹시 자신이 좀 더 자세히 도움을 얻고자 한다면 아래 사이트를 통해 도움을 얻을 수 있다. (http://www.koreasa.org/)

성경적 재정관리는 무엇일까?

my life

my life>신앙

1/27/2017

Recent Post

Post

if kakao 2019 Day1 후기

development

8/29/2019

Project Euler Solutions

Makefile에서 help target 추가하는 법

development

4/24/2018

Munin에서 mysql plugin 세팅방법

development

development>DB

4/11/2018

Terraform에서 KMS Encryption 사용법

sshguard에 의해 접속 실패하는 경우 해결방법

MariaDB Replication 설정

MariaDB GTID(Global Transaction ID)

<Copyright 2020. Ryan Park. All right reserved.>