2022년엔 나의 목표를 달성했을까 ?

달성하지 못했다

연말에 프로잭트 배포까지 마무리 한 후

팀원들과 발표도하고 마무리 하다보니 23년이 됬다.

1월 말이 되서야 작년을 뒤돌아 볼 여유가 생겼고 이렇게 연간회고를 적게 되었다.

 

인공지능 찍먹도전

22년은 시작부터 끝까지 고민과 선택의 연속이었다.

인공지능을 6개월정도 공부하면 데이터 엔지니어가 될 수 있을것이라 생각했지만 어림없었다.

반년정도 더 하고나면  되지않을까? 했지만 막상 이력서를 쓰고 입사지원을 해보니 현실의 벽을 만났다.

대부분의 기업들은 데이터와 관련된 직무에 석사 이상의 학위 또는 석사급의 배경지식과 논문경험 같은 독학 비전공자가 경험해보기 어려운 것들을 필요로 했다.

물론 현업 개발자 지인들은 비전공 학사로 입사하는 경우도 많다고 했다. 하지만 내가 생각하는 것과는 많이 달랐다.

최상위권 대학의 학사들이 많았고 통계학이나 컴퓨터과학을 복수전공한 사람들도 많았다.

 

하지만 후회는 들지 않았다. 대학원을 가야 배울 수 있는걸 경험해 봤다는 뿌듯함과

데이터베이스, 웹 백엔드 & 프론트앤드, 앱 개발 같이 개발자가 될 수 있는 영역이 많이 남았다는 설렘이 컸다.

 

대학원 진학을 해야하는가

데이터 분야는 공부량이 많았지만 실습을 할때 마다 새로웠다.

데이터를 크롤링해서 전처리한 다음 시각화하는 과정부터 인공지능 모델을 만드는것까지 모두 흥미로웠다.

서버와 데이터베이스, API, SQL 같은 내용도 등장했으며 백엔드 개발에도 흥미가 생겼다.

일반적으로 백엔드 개발자로 연차를 쌓고 데이터엔지니어나 데이터 아키텍쳐로 넘어간다는 정보를 얻었다.

그래서 바로 데이터 엔지니어가 되기위해 대학원을 지원할것인가, 백엔드 개발자로 우선 취업하는것을 고민했고

결국 백엔드 개발자로 일단 취업하고, 데이터엔지니어로 이직하기로 정했다.

 

파이썬 백엔드

한국에선 자바의 비중이 압도적으로 높았지만 우선 익숙한 파이썬으로 프로젝트를 진행하며 학습했다.

장고 백엔드를 사용하는 회사도 적었고 공부할 자료도 많지 않아 공식문서를 뒤져가며 공부했다.

구체적으로 어떤 서비스를 만들고 싶은지도 고민했고 결국 9월~12월동안 팀원 두명과 구독서비스 관리 웹서비스를 만들었다.

이 과정에서 어떤 언어와 프레임워크를 사용하는지는 크게 중요하지 않다고 느꼈다.

기초적인 네트워크와 웹서비스의 흐름을 파악해서 설계하고 구현하는것이 중요하다고 생각이 되었는데

이때 컴퓨터공학 기초가 왜 중요한것인지 와닿았던것 같다.

 

정말 하고싶은 직무가 어떤 것인가

처음 개발자라는 직업을 선택했을때 적어도 2년은 공부해보고 결정하자는 생각이었는데 예정보다 기간이 길어졌다.사실 2023년 상반기에는 취업하겠다는 목표로 공부를 시작했는데 하반기에 60곳이 넘는곳에 지원했지만 합격하지 못했다.스스로 고찰도 해보고 주변의 피드백도 받으며 느낀점은나는 2년이라는 시간을 투자했지만 정작 한 분야에 깊게 들어가지 않았다는 것이다. 주변에서 보기엔 그저 반년정도 경험해본 컴퓨터 공학과를 갓 졸업한 취준생과 다를게 없었다.

그래서 정말 하고싶은 한가지 직무를 골라서 올인하기로 했다.

뛰어난 인공지능 모델을 개발하는것, 정밀한 코딩으로 서버를 설계하고 api를 만드는 것 모두 재미있었지만

빅데이터라 불리는 수없이 늘어나는 정보를 수집하고 그 정보에서 의미있는 아웃풋을 낼 수 있도록 돕는것이 가장 내 적성에 맞았다.

다른 직업을 거쳐서 원하는 직업으로 이직한다거나, 일단 취업해서 경력을 쌓고 이직한다는 계획은 나의 성격과는 맞지 않았던것 같다.

한가지를 딱 정해야겠다 생각했다.

 

그래서 앞으로 데이터 엔지니어라는 목표를 쫒을 것이다.

데이터 엔지니어는 백엔드 지식부터 인프라 설계까지 넓은 분야를 알아야 하기 때문에 신입은 잘 뽑히지 않는다고 들었지만 도전해볼 생각이다.

성인이 된 후로 2022년만큼 빠르게 지나간 해는 없었던것 같다. 너무 빨리 지나가서 뭘 공부했는지 기억이 나질 않...

2023년은 작년보다 더 치열하고 알차게 불태울 예정이다.

2023년 연말 회고에는 반드시 데이터 엔지니어의 현업 다이어리? 같은 내용이 되도록 만들것이다

REmote DIctionary Server 레디스는 딕셔너리 자료구조로 이뤄진 원격 데이터베이스다 (redis 공식문서)

단, redis를 이해하기 위해선 메모리와 캐시에대해 알고있어야 한다.

 

캐시

캐시는 나중에 올 요청에 대한 결과를 미리 저장해두었다 사용한다.

속도는 빠르지만 용량이 작기 때문에 데이터베이스로 사용하기는 어렵다.

캐시는 빠르지만 용량이작고 메인메모리, 하드디스크로 갈수록 용량은 커지지만 속도는 느려진다.

 

메인 메모리

메인 메모리는 캐시보다 용량이 크고 하드디스크보다 열배 이상 빠르다.

하지만 데이터 휘발성이있다(컴퓨터를 재부팅하면 데이터가 모두 날아간다).

그래서 속도는 느리지만 비휘발성이고 용량이 큰 하드디스크(데이터베이스)에 데이터를 저장했다.

 

redis = 캐시 ?

하지만 기술 발전으로 메모리의 용량이 커지고 속도도 빨라졌다.

그래서 메모리 안에 자주 사용하고 드물게 수정되는 데이터를 저장해서 사용하는것이 redis 이다.

메모리 안의 공간을 쓰기 때문에 In-memory Database 라고 불린다.

저장되는 데이터는 기본적으로 Key-value로 된 JSON 형태다.

 

collection

redis가 강력한 이유는 다양한 자료구조가 구현된 콜렉션 떄문이다.

(자료구조를 이용해서 데이터 저장,조회에 시간복잡도를 낮게 유지할 수 있다)

  • String : 단일 key, value 형태
  • List : linked list 와 동일
  • Set : set 과 동일 (중복 x)
  • Sorted Set : score 라는 숫자값으로 순서를 정함
  • Hash : 여러개의 key, value 형태

 

 

비동기 처리에서 redis를 어떻게 사용하는가?

비동기 작업이 필요한 이유를 보자.

고객이 가입했다. 

아이디 비번을 저장하고, 프로필사진도 넣고, 기본프로필 배경사진도 넣어주고, 알것같은 친구 리스트도 만든다. 

그 다음 가입 인증(웰컴) 이메일을 보내야한다!

그런데 이걸 순서대로 다 동기적으로(순서대로 하나씩) 하고있으면 시간이 오래걸린다.

만약 동시에 수십명이 가입하는 중이라면? 

사용자의 데이터들을 DB에 넣는동안 이메일보내는 작업은 계속된다. 그동안 사용자는 다른 작업을 하지 못하고 기다려야된다.

그래서 결과를 즉시 받아야하거나, 지연되면 사용자경험을 떨어트리는 작업은 다른작업이 수행되는 동안에 백그라운드에서 비동기적으로 빠르게 처리할 필요가 있다.

 

메세지 기반 비동기 작업의 흐름은 이렇다. (셀러리 기준)

1. 프로듀서가 메세지를 생산해서 브로커에 보낸다

2. 브로커가 메세지를 확인하고 컨슈머에게 메세지 전달한다

3. 컨슈머는 메세지를 확인한다

a) 만약 올바른 메세지라면 브로커에게 Acknowledge를 보낸다

b) 잘못된 메세지라면 브로커는 Acknowledge 를 받지 못한다

c) 브로커가 Ack를 받으면 메세지 전달이 잘됬구나! 하고 큐에서 메세지를 제거한다.

여기서 브로커의 역할을 하는게 redis 다.

 

 

실제 redis의 사용

보통 여러개의 서버에서 같은 데이터를 공유할 때 사용하며, 단일 서버일 경우 캐시 기능과 원자성 유지를 위해 사용한다.

단, 싱글스레드이므로 레디스 내부에서 데이터를 다룰때는 시간복잡도에 신경써야한다. O(N)의 시간복잡도만 가져도 느려진다.

메모리상의 저장공간을 사용하므로 휘발성에 대비한 복제기능도 제공한다.

(복사 과정에서 Fork 라는 과정을 거치는데 이 Fork연산시 메모리에 여유공간이 없다면 데이터손실이 일어난다)

레디스를 저장소처럼 사용하는 RedisPersistent, RDB, AOF

레디스 데이터를 주기적으로 백업,스케일아웃 해주는 RedisCluster

부하를 분산시켜주는 ConstantHashing

등의 기술들이 레디스의 사용성을 높이고 있다.

 

MSA (micro service architechure)

서비스의 내부 기능을 작은단위로 나눠서 구현하는 방법입니다.

MSA 에는 여러가지 패턴이 있고 각각의 장단점이 있기 때문에 상황에 따라 다른 패턴을 사용할 수 있습니다.

여러가지 MSA 패턴에 대한 요약 글

예전 서비스는 큰 덩어리 내부에 기능을 같이 넣어 서로를 호출하며 트레픽이나 오류가 연쇄적으로 이어집니다.

하나의 기능에서 에러가 발생하면 같이 묶여있는 나머지 기능, 전체 시스템이 전부 영향을 받습니다.

MSA는 일정 단위로 나누어 연결시켰기 때문에 하나의 기능이 고장나도 전체시스템이 다운되지 않습니다.

MSA는 여러패턴으로 구현할 수 있는데 CQRS 패턴을 예시로 보면 쿼리와 명령을 나누어 관리하는 형식입니다.

 

유저 사용량의 90%를 차지하는 조회기능을 개선하려면?

모놀리식이라면 하나의 큰 덩어리이므로 서비스의 전체적 업그레이드가 필요하지만

msa라면 조회기능만 따로 업그레이드 가능합니다.

조회 내부에서도 각각의 이벤트(업무)를 AWS의 SQS(비동기작업 큐) + SNS(작업관리)를 이용해 관리하여 한 작업이 다른 작업의 속도나 트레픽에 영향을 주지 않도록 설계합니다.

 

MSA 장점

  • 단일 모듈의 장애에 대해 전체 어플리케이션은 크게 영향을 받지 않습니다.
  • 의존 관계가 기존 Monolithic 아키텍처보다 적고 유연합니다.
  • 개발자가 기능을 더 쉽게 이해 할 수 있습니다.

 

MSA 약점

  • 분산 시스템 개발은 일반 개발보다 복잡합니다. 모든 것이 독립적인 서비스이기 때문에 각 모듈간의 인터페이스를 신중하게 처리 해야 합니다. 서비스중 하나가 응답하지 않게 될 경우에 대한 방어코드도 작성해야 합니다. 호출 대기 시간이 발생하게 되면 복잡한 상황이 발생할 수 있습니다.
  • Multiple Databases 및 트랜젝션 관리가 어려울 수 있습니다.
  • 마이크로 서비스 기반의 어플리케이션을 테스트하는 것은 번거로울 수 있습니다. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 합니다.
  • 마이크로 서비스의 배포는 복잡 할 수 있습니다. 각 서비스 간의 조정이 필요 할 수 있습니다.

 

마이크로 서비스의 배포 및 가상화

마이크로 서비스기반의 어플리케이션을 배포하는 가장 좋은 방법은 컨테이너 가상화를 이용하는 것입니다. (Docker)

AWS와 같은 IaaS업체의 VM을 이용하여 마이크로 서비스를 배포할 수 있지만 작은 단위의 마이크로 서비스는 VM의 리소스를 전부 활용 하지 못해 비용 효율성을 저하 시킬 수 있습니다. 따라서 컨테이너 기반으로 배포를 하는 것이 유리합니다.

 

참고자료

'TopicClipping' 카테고리의 다른 글

UML 이란?  (0) 2022.10.13
동기와 비동기  (0) 2022.09.29
파이썬의 TDD 훑어보기  (0) 2022.09.22
트랜잭션 겉핥기  (0) 2022.09.22
AWS & 클라우드 컴퓨팅 유형  (0) 2022.09.22

구독관리 서비스 개발하기

 

프로젝트 아이디어를 고민하던 중 Spotify에서 정기결제 문자가 왔다.

저번달 운동하며 무료체험 한달을 이용했는데, 해지하는걸 깜빡해서 자동결제가 되버렸다...

그래서 월간구독 서비스가 몇개인지 살펴보니 유튭, 넷플릭스, 디즈니플러스, 애플티비, 스포티파이, 핸드폰게임까지 6개가 있었다.

그런데 정작 신용카드 결제문자 외에는 정기결제에 대한 알람메일이나 문자가 재대로 오지않는걸 발견했다.

(물론 습관적으로 알람동의에 체크를 하지않은 내 잘못도 있다..ㅋㅋ)

 

그래서 월간구독내용을 한눈에 보여주는 구독알리미 서비스를 구상했고 같이 교육듣은 두분과 한팀이되어 실제 서비스를 만들어보기로 했다.

첫 일주일동안은 기술명세서와 화면단 구성, DB설계 및 ERD 작성을 마무리했다. 

팀원분들은 각자 로그인/회원가입, 메인화면과 DB설계 역할을 맡았고 나는 서비스의 핵심기술인 알람메일 발송과 화면 갱신 작업을 맡았다.

 

알람메일, 구독정보 테이블을 갱신 작업은 스케쥴링과 SMTP 키워드로 자료를 조사했다.

처음엔 비동기 스케쥴링 이라는 스마트하고 어려울것같은 고급기술을 구현하고 싶어서 celery, redis, aws SQS 같은 기술에대해 공부해봤는데, 내용자체도 어려웠지만 지금 진행하는 프로젝트에 이 기술을 적용시키기엔 배보다 배꼽이 더 커지는 꼴이었다.

 

그래서 스케쥴링과 비동기의 원리와 작업흐름에 대해서만 파악하고

기간 내 프로젝트를 완성할 수 있는 현실적인 기술을 다시 찾아보았다.

 

멘토님들과 상의해보고 구글링 해보니 AWS의 서버리스 기술인 Lambda와 Eventbridge, SES 같은 서비스를 이용하면 클릭 몇번으로 스케쥴링과 이메일 발송이 가능하다는것을 알게되었다. 물론 이 기술들을 모두 유기적으로 연결시키고 팀의 장고프로젝트와 반응하게 만드는건 여전히 어려웠다. 

 

1. eventbridge로 스케쥴링을 설정하고 Lambda의 트리거로 등록해둔다.

2. 이 람다함수에게 AWS의 API gateway를 적용시켜 특정 url로 접근할 수 있도록 설정한다

3. 장고프로젝트에서 urls와 view에 코드를 작성해 이 API와 연결한다(?) / 아직 API에 대한 이해가 부족해서 이정도로 적어두었다

4. management.py 에 db조회와 수정, 이메일발송 같은 기능을 구현한다 !  

고 이해했는데 아직 틀린부분도 많고 실제로 구현하기 위해선 갈길이 멀다.

 

인프라를 이용하기 vs 직접 구현하기

AWS의 서비스들을 이용하며 문득 의문이 생겼다.

신입 백엔드 개발자가 회사에가서 직접 AWS를 설정할 일이 있을까 ?

이미 만들어진 AWS를 프로젝트에 연결시켜서 사용하는건 그저 사용법만 익히는게 아닐까 ?

그렇다면 SES 서비스를 쓰는대신 직접 장고의 SMTP를 이용해서 이메일을 발송해야하고,

Eventbridge로 스케쥴링을 하는대신 장고의 크론탭을 사용해서 직접 크론식으로 스케쥴링을 하는게 맞지 않을까?

 

그래서 현업에서 장고와 AWS를 모두 사용하는 백엔드 멘토님께 질문을 드렸는데,

결론은 "일단 작동을 하는것이 중요하다" 였다.

 

AWS 서비스를 사용하더라도 결국 서버리스,스케쥴링,SMTP 의 개념에대해 알고 있어야하고 현업에서 많이 쓰이는 AWS를 사용하는법을 미리 공부할 수 있어서 도움이되고

퓨어장고로 직접 구현하더라도 전체 흐름을 직접 구상해보면 현업에서는 많이 쓰이지않지만 기초를 익히는데 도움이된다고 하셨다.

그래서 우선 AWS 서비스를 기준으로 구현해서 배포까지 마친다음 부가적으로 직접 구현해보기로 했다.

프로젝트 진행 상황은 깃허브와 프로젝트카테고리에 정리해서 작성할 예정이다.

 

 

Javascript 컴백

프로젝트의 프론트단을 구성할때 필수적으로 js로 이벤트를 주고 동적으로 화면을 관리하는게 필요해졌고, 팀원분들과 같이 매주 목요일마다 자바스크립트 스터디를 진행하기로 했다.

우선 유튭에 코딩앙마님이 올리신 기초100분 완성 영상으로 한번 훑어봤는데 아주 기초적인 부분이라 추가적으로 드림코딩의 유료강의를 결제해서 공부중이며 프로젝트에 필요한 기술을은 필요할때 마다 구글링해서 적용해보기로 했다.

 

 

2주 회고 평가

 

2주간 개인 공부를 줄이고 프로젝트 준비에 대부분의 시간을 투자했다.

팀원분들이 장고 부분을 맡고 스케쥴링에만 집중할 수 있도록 배려해주셔서 우선 스케쥴링을 마무리 한 후 장고 파트에 합류할 예정이며 마무리 단계에서 프론트 관련 피그마, js, 깃허브 readme 정리 등의 작업을 진행할 것 같다.

프로젝트 마무리까지는 자바스크립트와 장고ORM, 코딩테스트 스터디를 겸행하고 팀원들과 24:00~02:00 까지는 각자 개인공부를 하기로 정했다.

앞으로 알찬 2개월이 될것같아서 흥미진진하다 . 

 

프로젝트에서 스케쥴링을 위해 AWS Lambda를 공부했습니다.

처음엔 장고의 셀러리 사용을 고려했지만, 프로젝트의 규모가 작고 비동기처리가 필요한 만큼 작업량이 많지않아 AWS Lambda와 SNS, SES, Eventbrigde 네가지 키워드를 활용해보기로 했습니다.

 

AWS Lambda

실습에 자주 사용되는 AWS 의 EC2 인스턴스는 사용하기는 편리하지만, 오래 켜두는만큼, 특히 여러대의 EC2 인스턴스를 사용한다면 상당한 비용이 듭니다.

물론 AWS의 인스턴스 스케쥴러를 사용하면 EC2 인스턴스의 작동시간을 자동으로 조절할 수 있지만, 이번 프로젝트는 하나의 인스턴스로 충분하기 때문에 고민하던 중 서버리스 개념을 알게 되었습니다.

AWS Lambda 공식페이지

 

클라우드 컴퓨팅 PaaS | Amazon Web Services

AWS Lambda 및 Amazon Kinesis를 사용하여 애플리케이션 활동 추적, 트랜잭션 주문 처리, 클릭 스트림 분석, 데이터 정리, 로그 필터링, 인덱싱, 소셜 미디어 분석, IoT 디바이스 데이터 텔레메트리 및 측

aws.amazon.com

 

Serverless

서버리스는 서버가 없는것이 아닙니다. 백엔드에서 개발자가 직업 서버를 관리하지 않는 경우를 서버리스라고 합니다.

예전에는 서버개발자는 서버를 직접 관리해야 했습니다. 하지만 지금은 AWS의 EC2 를 대여하면 직접 서버를 관리할 필요가 없어졌습니다. (구글, MS)

하지만 이 방법도 제공회사의 하드웨어를 빌려서 비어있는 서버를 개발자가 관리했습니다. 보안, 백업, 유지보수 같은 작업을 모두 직접 해야합니다.

여기서 등장하는것이 서버리스 입니다.

백엔드에서 작성한 코드를 작은 함수단위로 쪼갠다음 직접 관리할 필요가 없는 AWS Lambda에 올려서 작업합니다.

Lambda에 올려둔 작은 단위의 함수는 요청이 오기 전 까지는 비활성상태로 대기합니다.

만약 요청이 왔다면 AWS가 함수를 불러와서 작업을 수행하고 다시 비활성상태로 전환합니다.

즉, 서버가 24시간 꺠어있을 필요가 없고 기존의 EC2 처럼 비용에 대한 부담이 줄어듭니다.

(AWS Lambda를 사용하면 월 백만번 함수를 수행해도 한화 몇백원으로 처리가 가능합니다)

특히 데이터를 모아서 일괄적으로 처리하는 배치작업과 여러 자동화 작업들은 서버리스로 구현하기에 적절합니다.

하지만 함수가 비활성상태라면 요청을 받은 후 활성회 될때까지 약간의 시간이 필요하다는 단점이 있습니다.

물론 AWS에서 자주 사용되는 함수를 미리 지정하고 활성상태로 유지시켜 주는 컨커런시라는 서비스로 문제를 완화시켰습니다.

(프로비저닝 컨커런시)

 

AWS Lambda 함수, Provisioned Concurrency를 통해 빠른 성능 제공 (서울 리전 포함) | Amazon Web Services

AWS Lambda가 출시되고 5년이 흘렀지만 여전히 팀은 더 쉽게 애플리케이션을 구축하고 실행할 수 있는 새로운 방법을 찾고 있습니다. 특히, 중요 애플리케이션이 서버리스로 이동하면서 애플리케

aws.amazon.com

 

또 한가지 단점은 서버리스로 작업하면 어플리케이션의 구조자체가 서버에서 작업할떄와 다릅니다.

그래서 AWS 서버리스 → 구글 서버리스 같은 어플리케이션의 이동에 많은 제약이 생깁니다. (회사별 구조도 다르고 ec2같은 서버에 올리는 형식도 상이하기 때문입니다.)

 

"Lambda는 한마디로 요청이 들어온 그 아주 짧은 순간만 AWS 서버를 사용하고 바로 종료합니다."

 

Lambda 사용해보기

 

EC2는 인스턴스, S3는 버킷 이라는 단위로 사용하듯, 람다는 함수라는 단위로 대여할 수 있습니다.

 

1. 람다에서는 함수라는 단위로 대여하며 함수생성 버튼을 눌러 간편하게 사용할 수 있습니다.

2. 새로 작성을 선택해서 런타임은 파이썬을 선택하고 함수를 생성합니다.

 

3. 함수 생성 후 left, right 값을 리턴하는 간단한 함수를 만들고 저장합니다. (저장 후 deploy 버튼을 누르면 람다가 실행가능한 상태가 됩니다. )

 

4. 실행 가능한 함수를 주황색 test버튼을 눌러 입력하려는 left,right값을 설정하고 다시 test를 누르면 아래와 같이 응답과 실행시간 등의 정보가 나옵니다.

 

Lambda 디버깅

실행된 함수의 로그는 AWS의 CloudWatch (LogStream) 를 통해 확인할 수 있습니다.

 

 

Lambda가 강력한 이유

 

AWS의 다른 서비스를 트리거로 연동가능한것이 람다의 강점입니다.

주로 정해진 시간에 어떤 업무를 처리할 땐 EventBridge(간편하게 시간을 지정하거나 크론식으로 원하는 시간에 업무를 스케줄링),

특정 기능을 API에 요청할 땐 APIGateWay와 사용합니다.

트리거는 이 람다를 실행되게하는 조건(서비스)을 뜻합니다.

 

예를들어 S3 를 트리거로 설정하면, S3에 파일이 업로드 되었을때 Lambda가 실행되게 설정할 수 있습니다.

그럼 트리거로 설정한 S3에 json 형식의 파일을 업로드하면 파일 전송이 트리거가 되어 람다 함수를 실행합니다.

UML(Unified Modeling Language)

프로그램의 설계를 그림으로 표현하는 것으로 객체지향 언어와 밀접한 관련이 있어서 객체지향 모델링 언어 라고도 불린다.

단, UML은 모델링 언어일뿐 프로그래밍 언어가 아니고 방법론 또한 아니다.

건물을 짓기 전 청사진을 그리는것 처럼 소프트웨어 시스템을 구축하기전에 모델을 설계하는것이 필수인데, 이때 복잡한 설계상황을 가독성이 좋은 시각화 모델링을 할 수 있도록 돕는것이 UML의 가장 큰 역활이다.

한마디로 UML은 분석하고, 디자인하고, 프로그래밍하는 3단계 과정이다.

  1. OOA : Object Oriented Analysis
    • 서비스가 무슨 작업을 해야하는지
  2. OOD : Object Oriented Design
    • 어떻게 그 작업이 수행되는지
  3. OOP : Object Oriented Programming
    • 이 모든것을 구현하는지

UML의 다이어그램은 구성요소간의 형태를 표현하기 위한 `구조적 다이어그램` 과 구성요소가 어떤 행위를 하는지 표현하기위한 `행위 다이어그램`으로 나눌 수 있다.

  • 구조적 다이어그램은 클래스다이어그램, 객체다이어그램, 컴포넌트 다이어그램 등이 있다.
  • 행위 다이어그램은 시퀀스 다이어그램, 유케이스 다이어그램 등이 있다.

 

 

클래스 다이어그램

가장 일반적으로 사용되는 클래스다이어그램의 예시다.

시스템의 구조를 나타내며 클래스끼리 연결시켜 그 내부에 변수,데이터 타입함수를 정의할 수 있으며 한눈에 보기에도 편하다.

 

 

시퀀스 다이어그램

이 시퀀스 다이어그램은 Batch 인스턴스에서 DB로 사진의 아이디값을 전달하면 DB에서 해당 아이디를가진 사진을 return 해주는 흐름을 보여준다.

 

PlantUML

PlantUML은 텍스트로 UML 다이어그램을 생성하는 오픈소스 프로젝트다.

PlantUML Docs

PlantUML GitHub

특이한 점은 UML 외에도 JSON data, 네트워크 다이어그램, Archimate diagram 등의 여러가지 다이어그램을 지원한다.

PlantUML로 시퀀스다이어그램을 그린 예시이다.

 

 

Mermaid

마크다운 문법을 사용해서 UML을 그릴 수 있는 자바스크립트 기반의 라이브러리다. (IDE에서 플러그인을 설치하면 mermaid를 바로 사용할 수 있다)

Mermaid

Mermaid 라이브에디터

플로우차트, 시퀀스다이어그램, 간트차트, 클래스다이그럼, User Journey diagram 를 사용가능하다.

mermaid를 이용해서 클래스다이어그램을 그리는 코드예시이며, 심지어 Notion 노트 앱에서 임배디드형식으로 입력이 가능하다.

 

 

'TopicClipping' 카테고리의 다른 글

MSA  (0) 2022.11.04
동기와 비동기  (0) 2022.09.29
파이썬의 TDD 훑어보기  (0) 2022.09.22
트랜잭션 겉핥기  (0) 2022.09.22
AWS & 클라우드 컴퓨팅 유형  (0) 2022.09.22

 

점프투 장고와 개인 프로젝트

10월부터 점프투 장고라는 책과 교육을 병행하며 장고 실습에 많은시간을 투자했다.

수강중인 교육에서는 최신 현업기술을 바탕으로 자세한 이론을 배우고, 책으로는 최신은 아니지만 보다 간편하고 연습하기 좋은 내용으로 실습했다.

같은 과정이라도 ORM 에서 다른 함수나 조건을 걸어서 동작시켜보고 로그인시 사용하는 view도 서로 다른 form 을 사용해봄으로써 각각의 장단점과 코드의 차이를 확인했다.

2주동안 공부한내용을 정리해보니 생각보다 적은 내용을 공부했다. 책과 강사님의 학습자료와 공식문서를 검색해가며 하나의 기능을 만드는데도 적게는 반나절에서 길게는 이틀까지 걸렸고, 막상 만들고나니 훨씬 쉽고 간단한 방법이 있어서 헛웃음이 나오기도 했다.

 

개인적으로 진행중이던 프로젝트는 잠시 멈춰있는데, 그 이유는 장고에대해 기본적인걸 알지 못하고 만드는데만 급급하려다 보니 구글에서 다른사람의 코드를 복붙하거나 함수의 파라미터도 재대로 알지 못한채로 사용하는 경우가 다반사였다.

결국 하반기 채용공고에 혹해서 스스로 설명하지 못하는 프로젝트를 꾸역꾸역 진행하려는 시도가 얼마나 멍청했는지 자기반성의 시간을 가졌다.

추가로 멘토분이 ERD에 대해서 조언을 해주신 내용을 바탕으로 DB 설계를 다시하기로 했다. DB도 정확한 지식없이 그냥 필요한 정보 받아서 저장하고 저장된것끼리 비교하면 끝이라고 생각했는데, 사실은 그것보다 훨씬 복잡하고 더 단순하게 만들 수 있는 방법이 있었다.

그래서 MySQL과 DB설계(ERD작성)에 대한 이론을 공부하기 시작했고 다음주 주말까지 완료할 예정이다.

 

이번주의 키워드와 다음주 목표

이번주 키워드는 서버 비동기와 동기 그리고 웹소캣 이었다.

동기와 비동기를 공부해보며 결국 기초적인 웹 소켓에대한 이해도가 필요했고 유투브와 CS관련 강의를 들으며 내용을 정리했다.

(정리된 내용은 따로 토픽클리핑에 작성할 예정이다, 특히 소켓에 관한내용은 공부할수록 웹개발에 큰 비중을 차지하는 것 같아서 길 글이 될것 같다.)

다음주 목표는 MySQL, DB 이론 학습과 자바스크립트 기초이론 마스터하기, Heap 자료구조와 알고리즘 문제풀이 그리고 소켓에대한 내용 마무리로 설정했다.

 

*TMI 지만 두번의 연휴중 2박3일을 꼬박 개인적인일로 노트북앞에 앉지못해서 더 자세히 공부하지못한게 아쉽다. 그래도 쉰만큼 머리가 환기되서 다음주는 하루 순공부 10시간을 다 채울수 있을것같다. !

파일시스템

리눅스에서는 하드디스크(HDD)를 추가하면 인식은 하지만 복잡한 별도의 처리과정을 거쳐야 그 저장공간을 사용할 수 있다.
윈도우는 추가만하면 자동으로 인식하고 바로 사용할 수 있도록 해준다.

 

File System

파일, 디렉토리를 효율적/구조적으로 관리하기 위한 트리 구조 시스템이다.
하드디스크나 씨디같은 물리적 저장공간을 저장장치로 활용한다. 네트워크를 이용해서 서버간 마운트로 하나의 파일 스토리지처럼 사용하기도 한다.(NFS)
리눅스가 지원하는 파일시스템은 윈도우보다 다양하고, 리눅스의 파일시스템은 커널에 포함되어 있으며 대부분의 기본 구성에 포함되어있다.

/lib/modules/[kernel_version]/kernel/fs

일반적인 과정은 사용자가 명령을 입력하면 쉘을 통해 커널에 전달되고, 커널은 이 명령을 하드웨어에 전달한다. 만약 올바른 명령이라면 하드웨어는 명령의 결과값을 다시 사용자에게 보낸다. (엄청나게 축약한 버전이므로 후에 CS에서 더 깊게 공부해야한다)

 

Partition

하나의 물리적 디스크를 여러개의 연속되는 논리적인 디스크로 분할하는 것이다.
파티션을 나누기 위해서는 물리적인 저장장치에 남아있는 연속된 공간이 필요하고, 서로 다른 물리적인 저장장치는 하나의 파티션으로는 구성할 수 없다.

단일파티션과 다중파티션의 차이는 MBR(#0) 의 유무이다.

  • MBR : 하드디스크의 가장 첫부분으로 다중파티션이라면 메인이되는 파티션에 MBR이 존재한다.
    • 모든 파티션은 Boot Sector 라는위치에 정보가 저장되어있고, MBR에 이 BootSector값을 저장해두고 포인터처럼 이용한다. 즉 MBR이 없는 파티션을 실행하면 자동으로 MBR이 있는 메인파티션으로 연결되어 실행된다.
    • C 드라이브에 엑셀이 있고, D 드라이버에 map.xls 파일이 있으면 ?
    • map.xls 파일을 바로 실행시켜도 C 드라이브에 MBR에서 D드라이버의 BootSector를 참조해 자동으로 엑셀을 열고 거기서 map파일을 여는것이다.

 

크게 두종류의 파티션이 있고, 거의 대부분의 파티션은 DOS에 해당된다

옵션 내용

DOS Partition Table 현재 가장많은 OS가 채택했으며 0번 섹터중 Boot Code가 사용하고 남은 64 byte를 사용한다. 파티션은 16byte로 최대 4개까지 만들 수 있다.
BSD Disk Label 하나의 섹터 안에 파티션 정보를 포함한 디스크 정보를 저장한다. 1번 섹터의 148~403번까지 총 256byte를 사용하고 파이션은 16byte 이다.
Apple Partition Map BSD 계열의 기록방식을 채택했다. 0번섹터(MBR) 미사용, 1번 섹터 512byte 전체를 사용하며 파티션은 16byte에 최대 32개까지 만들 수 있다.
Solaris Disk Label Sun Sparc에서는 0번섹터에 Disk Label가 위치한다. 파티션은 444번부터 64byte에걸쳐 8개까지 만들 수 있다.

 

fdisk

파일시스템을 생성한다

fdisk [옵션] [File System]

 

Mount

하드디스크와 파티션을 추가한 후에는 반드시 mount가 필요하다.
디스크와 같은 물리적인 장치를 특정위치나 디렉토리에 연결시키는 작업이다.

리눅스에서는 하드디스크가 아니라 파티션을 연결하는 개념이다.

  1. 수동마운트 : mount 명령어를 사용
  2. 자동마운트 : 부팅시 자동으로 마운트 (/etc/fstab 에서 확인할 수 있다)
  3. 언마운트 : unmount명령을 통해 마운트된 file system을 해제

이미지처럼 외부 디바이스는 드라이버를 통해 OS가 활용할 수 있다.

 

마운트 명령어

 

mount[Option][Device:Partition][Directory:MountPoint]

  • 마운트 포인트는 사용자와 관련된 디렉토리를 사용하면 안된다. (사용되지않는 임의의 디렉토리로 써야함)
  • 마운트 포인트는 Primary Partition, Logical Partition 만 가능하다
    • #mount /dev/sda1 / d_drive

옵션 내용

-a /etc/fstab에 명시된 파일시스템을 마운트
-f 실제로 마운트하지 않고 마운트 가능한지만 확인
-t 파일 시스템 타입을 선택
-r 읽기만 가능하게 마운트
-w 읽기, 쓰기 모드로 마운트

 

unmount 명령어

마운트 되어있는 파티션을 해제하는 명령어로 마운트 포인트가 아닌 다른위치에서만 가능하다.

 

unmount [Option][Device:Partition] or [Directory:MountPoint]

옵션 내용

-a /etc/fstab에 기록된 모든 파일시스템을 언마운트
-f 강제로 연결을 해제할때 사용

 

mount 확인

mount

명령어를 통해 마운트된 파티션의 정보를 확인할 수 있다.

 

df -h

마운트되어있는 파운트포인트와 자세한 내용까지 보두 볼 수 있다.

 

NFS(Network File System)

네트워크 파일시스템으로 공유된 영역을 마운트한다.
한마디로 준비된 하드디스크를 ip주소를 통해 해당 서버가 하드디스크를 사용할 수 있도록 연결하는것이다.

mount -t nfs [IP:/EXPORT DIR] [LOCAL DIR]

 

자동마운트

마운트는 시스템을 껏다키면 자동으로 모두 해재되므로, 자동마운트가 필요하다.
즉 /etc/fstab 파일에 설정해두면 부팅시 자동으로 마운트가 이뤄진다.

/etc/fstab (File System Table) 내용

필드 내용

fs_spec 디스크이름, 디스크 UUID(H/W)
fs_file 마운트 포인트(S/W)
fs_vfstype 파일시스템 (ext4, nfs)
fs_mntops 마운트 옵션 (defaults, usrquota, grpquota, acl)
fs_freq 덤프(백업) 유무 (0,1,2)
fs_passno fsck 검사 순서(1,2)

'Computer Science > 리눅스' 카테고리의 다른 글

[리눅스] 데이터 저장  (1) 2022.09.23
[리눅스] 프로세스  (0) 2022.09.22
[리눅스] 허가권과 소유권  (0) 2022.09.22
[리눅스] 사용자 계정관리  (1) 2022.09.22
[리눅스] 기본 명령어  (0) 2022.09.22

+ Recent posts