1. 올해 첫 직장에 입사하며 다룰 수 있었던 기술

 

 

1-1. AWS

  • 기존의 알던 온프레미스 환경에서 벗어나 클라우드를 접하였다.
  • 쓴만큼 지불한다는 개념이 존재하였기 때문에 각 클라우드 제품을 사용하는 것에 대한 최적화, 기반 기술, 한계점, 단위 비용에 대해 명확히 알고 있어야만 설계가 가능했다.
  • 그러므로, 일반 개발자보다 훨씬 더 많은 학습을 통해 deep하게 공부를 할 필요성을 인지하였다.
  • 중점적으로 사용한 서비스로는 Lambda, EC2, S3, API Gateway, EKS이다.
  • 2020에는 EKS, MSK, Elastic Search 등 더욱 많은 서비스를 경험하여 내 것으로 만들 것이며 기반 기술에 대해 심도 있는 공부를 할 예정이다.

 

1-2. Kubernetes & Docker

  • 입사 후 AWS Dev-Day를 통해 가장 처음 접한 지식이다.
  • 컨테이너라는 단어만 알고 있었지만, 이 컨테이너의 의미와 어떻게 관리를 하는지에 대해 알 수 있었다.
  • 컨테이너를 통한 관리의 한계 또한 학습하여 상황에 맞게 쓰도록 노력해야할 것이다.
  • 현재 이에대한 우선순위가 낮아져 공부가 pending 된 상태이다.
  • AWS EKS를 통한 deploy대신, 모두 메뉴얼로 구성을 하면서 느낀 점에 대해 정리를 해볼 생각이다.

 

1-3. Apache Kafka

  • 가장 처음 접한 메시지 큐 오픈소스이다.
  • 지금까지 메시지가 direct하게 전달되거나 DB에 저장되어서 query를 통해 데이터를 임시 버퍼로 저장하는 절차로 알고있었지만,
  • push, pull형태로 topic라는 키워드를 가지고 대용량 데이터를 주고 받았다.
  • NHN에 데이터를 중계하는 프로젝트의 샘플 워크플로우를 작성하며 producer와 broker에 대해 공부를 할 수 있었으며
  • 설정 파라미터애 따라 어떻게 통신이 달라지는지에 대해 명확히 알 수 있었다.
  • 향후 대용량 메시지 관련 프로젝트 참여 시, 이에 대한 지식을 가지고 가이드 할 수 있도록 학습을 해야한다.

 

1-4. API Gateway & lambda 기반의 Serverless APP

  • 기존 서버상에서 APP을 deploy하게되면 확장성, 보안성 등 많은 부분에 시간과 비용이 소모된다.
  • 이에 대해 부담을 줄이고 개발에만 집중 할 수 있기 때문에 이러한 점에 대해서는 장점이지만,
  • FaaS(Function as a Service) 제공사에 많은 의존을 하게 되며
  • AWS같은 경우 하나의 lambda function 당 500MB의 /tmp storage와 3GB의 메모리라는 제약사항이 존재한다.
  • Serverless 이기 때문에 localstorage를 사용하는데 제약사항이 있다.
  • 정리하면 제약사항에 대해 deep하게 파악하고 있어야 하며, 필요한 부분에 대해서만 사용해야한다.

 

 

1-5. DynamoDB & MongoDB

  • 입사 후 대용량 데이터 처리에 관한 이론을 공부하다 처음 알게 되었다.
  • RDB에 비교하여 attribute(schema)에 자유로운 형태를 지니며, 자유롭게 필드를 삽입 할 수 있다.
  • 이를 이용하여 빠른 개발을 할 수 있다는 장점이 있으나, 관계가 없는 DB이기 때문에
  • Join연산에 약하며, 데이터에 대한 update시 모든 table에 대해 관계가 있는 데이터에 접근해야한다.
  • 그 결과, RDB에 비해 상대적으로 데이터무결성에 약할 수 있다는 단점이 있다.
  • 절대적으로 이게 낫다는 것이 아닌 서로 상호보완적 관계이기 때문에 상황에 맞는 데이터베이스를 사용해야한다.
  • 특히 DynamoDB는 다른 NOSQL 엔진에 비교하여 RCU, WCU라는 개념이 존재하기 때문에 이에 대한 최적화를 신경써서 하지 않으면...
  • 요금 폭탄을 맞게 된다. 그러므로 처음 설계시 Partition Key와 Sort Key를 잘 설계하여 인덱스와 scan연산을 덜 쓰도록 해야한다.

 

1-6. Spring Framework & Oracle DB

  • 신입사원 교육으로 6개월 중 각각 1개월씩 Spring Framework, Oracle DB에 때한 교육을 수강하였다.
  • 위 2개의 대한 존재만 알고 있고 건드려본적이 없기 때문에 이를 학습하는 2개월이 작년에 가장 힘들었으며, 시간 투자가 많았다.
  • 사수님께서 위 2개는 SI에서 보편적으로 가장 많이 쓰는 것이기 때문에 deep하게 알아두는 것이 좋다고 하셨다.
  • 그러나 교육을 들을 당시 신입사원 프로젝트를 찍어내는데에 급급하여 spring framework에 대한 아키텍처와,
  • Oracle DB query최적화에 대해 제대로 학습을 하지 못하여 매우 아쉽다.
  • 올해 시간이 날때 조금씩 학습을 하여 상황에 맞는 framework를 사용할 수 있도록 가이드라인을 제시하도록 하겠다.
  • 어떠한 프로젝트에 들어가도 준비된 사람이 되도록 하겠다.

 

 

 

2. 올해 이룬 목표

2-1. AWS Solution Architect Associate 취득

 

2-2. 최소 하나의 프로젝트에 참여하여 기여하기

 

 

 

2-3. 블로그 open하여 한달에 100명 이상의 유입자수 달성 (2019 11월 블로그 오픈)

 

 

 

2-4. 누군가의 멘토가 되어 멘티가 주니어개발자가 되도록 도와주기

  • 학교 한 후배에게 가이드라인을 지속적으로 제시해주고 있으며, 졸업 작품 설계에 대해 지속적으로 관찰 중.
  • 회사를 다니며 알게 된 개발자로써의 자세와 필요한 역량에 대해 알려주며
  • 함께 공부를 하며 성장해나가고 있다.

 

 

 

 

 

3. 올해 이루지 못한 목표

3-1. AWS Solution Architect Professional 취득 실패

  • 공부를 함에 있어서 시간 분배를 실패하였다.
  • 지속적으로 Architeecture에 대해 학습하고 시험 대비를 해야했으나, 준비가 부족하여 1/31에 있던 시험을 3월 2째주로 연기하였다.

 

 

3-2. 정보보안기사 취득 실패

  • 대학교 졸업 전 취득이 목표였으나, 우선순위를 AWS학습과 회사 적응에 둠에 따라 자연스럽게 공부를 하지 못했다.
  • 2020 실기를 보기 전 자격이 소멸될 예정이다.
  • 클라우드를 학습하며 다져진 지식을 기반으로 학생이 아닌 개발자로써의 시각으로 재접근하여 천천히 공부 할 예정이다.

 

 

3-3. 인간답게 살지 못함.

  • 학교를 졸업 후 급작스러운 환경변화가 있었다. (청주 → 서울)
  • 너무 조급한 하루의 대부분을 학습하는데에만 시간을 투자했다.
  • 1일 1식을 함에 따라 운동을 하여도 제 몸을 유지 할 수 없었다. (72kg → 현재 63kg)
  • 스트레스로 폭식하여 불어난 체중을 되돌리는데 성공하였으나, 급작스런 체중변화에 근손실도 존재하였다.
  • 결과론적으로 체력이 떨어졌음.
  • 정작 나에대한 투자를 하지 못하였기 때문에 2020은 나에 대한 투자를 늘릴 계획이다.

 

 

4. 근무간 팀장님의 나에 대한 평가 (실제원본이다)

 

더보기

정형님은 업무를 수행하는 데 있어서 열정 있고 책임감 있으며 성실한 인재입니다. 본인이 계획한 일정에 맞춰 업무를 수행할 수 있도록 업무 시간 외에도 개인의 시간을 투자해 업무를 완수합니다.

또한, 개발자로서 기본적인 소양인 새로운 기술에 대한 호기심과 문제 해결을 위한 성실함과 끈기를 가지고 있는 좋은 인재입니다. 본인의 임무를 완수 후에 기다리지 않고 팀의 업무에 도움이 되거나 개인의 역량을 개발하기 위해 솔선수범하는 적극적인 모습을 보입니다.

다만, 본인이 노력하는 만큼 자신이 습득한 기술이나 지식에 관해 주장이 강해 자칫 잘못된 결론에 도달할 위험성도 있습니다. 신입 사원인 만큼 아직 다양한 서비스 개발 및 운영 경험 부족으로 인해 섣부른 결론을 내지 않도록 본인의 겸손한 태도와 차분한 의사 전달력이 필요합니다.

또한, 조급한 성격으로 의사전달에 있어서 상대방의 반응이나 참여자의 분위기를 고려치 않고 발언하는 경우가 있어 주의할 필요가 있습니다. 물론, 기술 멘토나 리더가 논리적인 지도와 토론으로 긍정적인 결론을 이끌어 나아가면 구성원에게 좋은 영향을 미치겠지만, 항상 그런 상황이 함께할 수는 없음으로 상대방을 배려하는 태도를 익히도록 해야 합니다. 더불어 자신이 알고 있는 지식에 대한 발표 능력과 주변 사람들과의 지식 전달을 매끄럽게 할 수 있도록 공감 능력을 좀 더 키워 나아갔으면 합니다.

 

  • 내가 봐도 나는 얕은 지식으로 다른사람들에게 설명하려는 습관이 있다. 잘못된 지식의 전파는 모두가 잘못되는 길이기 때문이 이러한 습관을 지양해야한다.
  • 잘못된 결론에 도달하지 않기 위해서는 그만큼 deep하게 학습하여야 한다. 팀장님께서 항상 배운 것은 글로 정리하는 습관을 들여라고 지도해주셨고,
  • 이는 내가 향후 기술에 대해 이야기 할때 조금 더 매끄럽게 나의 의견을 주장할 수 있는 밑거름이 되었다.
  • 기술에 대해 이야기 하려 하니 모르는 것이 많아 발표능력이 모자란 것도 사실이다. 항상 머리 속에서 생각을 하고 말을 하도록 하자.
  • 한참 모자라지만, 뒤로 퇴보할 것이 개선될 여지만 있기 때문에 충분히 많이 성장할거라 생각한다..

 

5. 2020 목표 (와..... 많다... 파이팅..)

  • dynamodbguide.com에 번역 contritube를 하기로 했다. (승인을 받았으며, 2020/2/1부터 천천히 해나갈 예정이다)
  • Serverless APP에 대해 사상부터 개발까지 deep하게 이해를 하여 나 없으면 프로젝트가 진행 되지 않을 정도의 실력을 지녀야 한다.
  • Pending된 Kubernetes와 docker에 대해 학습을 재개하여 현재 서비스를 일시 중지한 냠냠챗봇에 대해 이 기술을 적용하여 사용자 중심의 서비스로 재오픈
  • AWS Solution Architect Professional과 AWS DEVOPS자격증 취득
  • NOSQL과 RDB의 deep dive

'회고' 카테고리의 다른 글

20200624 회고 - 배치 프로세스 및 데이터베이스  (0) 2020.07.28
2019 회고  (2) 2020.02.01
20191126 회고 - 프로그래밍 패턴  (0) 2019.11.26
  1. 달고냥이 2020.02.12 22:43

    일은 삶의 도구로 잘 활용하는 것이 중요합니다
    일이 삶의 목적이 되지 않기를..

  2. LOL전사 2020.04.16 10:34

    잘 보고갑니다~

1. DynamoDB Partitioning 원리

  • DynamoDB는 자체 내부 Hash Function이 있다.
  • Partition Key값을 파라미터로 계산된 Hash Value를 기준으로 DynamoDB Table 내부의 파티션이 결정되어 데이터는 적재된다.
  • Primary Key가 복합키인 경우에도 단일 Partition Key로 이루어진 경우와 같은 방식으로 partition key hash값을 계산하여 partition에 적재한다.
  • 그러나 같은 partition key를 가진 데이터들은 물리적으로 가깝게 설계되며, Sort Key 값으로 정렬된다.

 

 

 

 

2. Partition Key 설계시 고려사항

 

2-1. 분산된 워크로드

  • Partition Key는 테이블에서 데이터가 저장되는 논리적 및 물리적 파티션을 결정하는 요소이다.
  • DynamoDB는 결정된 파티션들에게 프로비저닝된 Capacity Unit을 균일하게 분배한다.
  • 즉, Partition Key의 분산도를 고려하지 않고 설계시, 요청에 대해 효율적인 Capacity Unit을 사용할 수 없게 된다.
  • 물론 DynamoDB는 관리형 서비스이기 때문에 어느정도 조절은 해 주지만, 최적화를 위해서는 위 관리형 서비스에 의존하지 않고, 직접 튜닝하는 것이 적절하다.

 

 

 

다음 데이터는 실제로 필자가 DynamoDB를 학습하며 설계하였던 테이블이다. (나중에 이 테이블을 보니 최악이었다 :(  ) 

 

 

위 테이블의 경우, 사내 회의실 예약 시스템에 대한 정보를 구현하기 위해 설계한 내역이며, partition key가 INFO_TYPE이며, sort key가 HASH_VALUE로 설계되었다. 

현재 위 테이블의 Partition Key의 값은 단 2개로 나뉘어져 있다. 위 DynamoDB Partition 아키텍처는 다음과 같이 그림으로 나타낼 수 있다.

 

 

 

 

 

위 아키텍처를 염두에 두고 생각해보자. 회의실의 개수는 건물에 한정적이고, 이 한정적인 회의실에서는 수많은 직원들이 회의실을 사용한다.

그러므로 상대적으로 회의실 정보보다 예약 정보가 훨씬 많을 것이고, 데이터에 대한 접근도 예약정보가 훨씬 많을 것이다.

그 결과, 같은 Capacity Unit을 제공받은 partition이지만, I/O요청이 압도적으로 많은 "res" partition key를 가진 파티션은 그만큼 비효율적인 요청처리를 하게 된다.

 

 

 

 

다음 아키텍처는 위 아키텍처를 조금이나마 개선한 아키텍처이다. (극단적인 예시이므로 참고만 해주길 바란다.)

위같이 설계를 바꾼 이유는 다음과 같다.

  • 회의실에 대한 예약은 현재 HASH_VALUE값 자체를 이용하며, [회의날짜]#[회의실]#[회의시작시간]#[회의종료시간] 의 format을 가진다.
  • 시간의 흐름 중에서 뽑은 하나의 시간 표본은 유일하다.
  • HASH_VALUE도 시간 값 이므로, 유일한 값이다.
  • 위 HASH_VALUE를 Partition Key로 설계하면 Partition의 분포도가 좋아진다.
  • 그러므로 한 파티션에 대한 I/O 병목현상이 개선될 수 있다.

 

 

 

 

 

 

2-2. Partition Key에 난수 추가 (Sharding)

  • Sharding은 Partitioning의 한 부분이며, "Horizontal Partitioning"과 같은 의미이다.

  • 기존 설계한 Partition Key에 난수를 추가하게 되면, Hash Function에 의해 결과값이 다양해진다.
  • 그 결과로 DynamoDB 내부의 논리적 및 물리적 파티션의 분포는 분산된다.
  • 파티션이 분산됨에 따라 병렬처리를 개선할 수 있다.

 

2-3. Partition Key를 이용한 효율적인 쓰기 작업 분산

  • DynamoDB는 기본적으로 파티션의 크기와는 상관 없이 균일한 Capacity Unit을 할당받는다.
  • DynamoDB는 관리형 서비스이기 때문에 어느정도 파티션간 Capacity Unit을 프로비저닝 해주지만, 이에 의존한 key설계는 올바르지 못하다.
  • 그러므로, 쓰기 작업에 대해서도 타겟 파티션을 분산시켜 정의할 필요가 있다.

 

 

case1. partition key의 정렬 순서대로 데이터를 쓰는 경우

 

  •  위와 같이 쓰기작업을 정의할 시, 한 파티션의 Capacity Unit을 집중적으로 쓰기 때문에 병목현상이 발생 할 수 있다.

표 출처 : AWS DynamoDB 설명서

 

 

case2. partition key의 순서와 무관하게 분산시켜 데이터를 쓰는 경우

표 출처 : AWS DynamoDB 설명서

  • 위와 같이 쓰기 작업을 개선할 시, 매 작업마다 다른 파티션의 Capacity Unit을 사용하기 때문에 case1 보다 Capacity Unit의 사용률에 대해 보다 유연하게 대처 가능하다.

 

 

 

 

 

3. 참고문헌

금일 개발환경 구축을 위해 개발 팀원들에게 Amazon Linux에서 새로운 계정을 발급하여 배포하였다.

 

 

 

팀원이 사용하는 계정에서는 문제가 없었지만, 패키지를 설치하고 관리하는 admin역할을 담당하는 팀장님의 계정에 문제가 있었다. 그 문제는 다음과 같다.

 

 

다음과 같이 sudo 권한 획득을 요구한 유저가 sudoer 파일에 없다는 에러 메시지가 출력이 되었다.

위와 같은 에러메시지를 해석하기 위해 sudoer라는 파일에 대해 찾아보았다.

 

 

 

 

Path : /etc/sudoers (Amazon Linux2 기준)

Role : Sudoers allows particular users to run various commands as the root user, without needing the root password.

      (Sudoers는 특정 유저에게 여러 커맨드를 root password를 사용하지 않고 root user처럼 사용할 수 있게 허용한다.)

 

 

 

 

 

위 파일 내부에서 다음과 같이 특정 유저에게 sudo 권할을 부여할 수 있는 명령을 찾았다.

 

 

 

 

 

Allow root to run any commands any command anywhere와 밑의 root ALL=(ALL) ALL를 보았을 때, 이와 같은 권한을 다른 유저에게 주면 sudo를 언제든 사용할 수 있기 때문에 나는 다음과 같이 testuser에 대해서도 root와 같이 어떠한 커맨드든 어디서든 sudo 권한으로 실행할 수 있게 권한을 인가하였다.

 

 

 

 

 

위와 같이 권한을 testuser에게 준 결과, 다음과 같이 sudo 권한을 준 명령어가 잘 작동함을 볼 수 있었다.

 

'IT > Security' 카테고리의 다른 글

[Linux] user not in the sudoers file.  (0) 2020.01.06

+ Recent posts