일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- ELB
- REPLICATION
- ci/cd
- 아키텍처
- springboot
- TypeScript
- codepresso
- Auto Scaling Group
- Typesript
- kubernetes
- AWS
- k8s
- Jenkins
- Elastic Load Balancing
- Redis
- 코드프레소
- docker
- ASG
- NoSQL
- Today
- Total
목록아키텍처 (7)
Study Note
Technical Debt은 개발 단계에서 제대로 개발을 하지 않으면, 나중에 이자가 붙어 더 많은 일을 해야 한다는 뜻이다. 여러 원인중 다음과 같은 주요 원인을 통해 Technical Debt가 발생한다. 비스니스 조직으로부터으 무리한 압박 부정확한 요구 사항이나 잦은 변경 잘못된 의사 결정 프로세스 부족한 협업 부족한 테스트 부족한 문서화 리팩토링 지연 낮은 수준의 아키텍처 설계 Technical Debt가 꼭 나쁜 것은 아니다. 회사에서 부채를 유지하면서 다른 곳에 투자할때 이익이 생길수 있다. 이처럼 Technical Debt이 발생 시키면서 개발 인력을 다른 곳에 투자함으로써 더 좋은 효과를 낼수 있다. 중요한건 Technical Debt의 비율이다. Technical Debt, 아키텍처, 기..
도구를 사용하는 이유 멀리 떨어져 있어도 쉽게 공유가 가능하다. 검색 등을 이용하여 지난 이슈애 대한 내용 추적이 좋다. 업무 프로세스에 맞춰 플로 등을 커스터 마이징 할 수 있다. 다음과 같이 태스크 관리에 많은 효율성을 부여 하지만 중요한건 프로세스와 조직 문화 자체임을 인지해야 한다. 도구 선택시 고려 사항 워크플로 사용자 정의(Workflow Customization) [필수] 태스크는 처리과정에 따라 상태 값을 가진다. 상태 값의 변화는 일종의 흐름인 워크플로를 가진다. 워크플로는 개발 조직의 업무 프로세스에 맞추어서 다시 정의되기 때문에 워크플로를 커스터마이징해야 한다. 계층(Hierachy) [필수] 태스크의 종류별로 상하, 평행의 관계를 설정해야 한다. 일반적인 링크 기능은 연결성만 제공하..
요구 사항 저장 요구 사항이 지족성으로 변경된다. 변경된 요구 사항을 일관된 하나의 문서로 관리한다. 만약 그렇지 않고 워드, 파워포인트 같은 문서로 저장하면 요구 사항이 변경될때 마다 문서를 수정하고 재배포 해야한다. 그 과정에서 예전 문서의 요구 사항이 참조될수 있다. 온라인으로 문서를 저장해서 공유하면 일관된 하나의 문서로 관리된다. 공유 파일 저장소 / 마이크로소프트의 셰어포인트 / 위키 등등 그 중 위키 페이지 사용시의 장점이다. 요구사항이 변경 될때마다 최신 문서를 볼수 있다. 업데이트 내용에 대한 히스토리를 저장해 놓기 때문에 문서 변경 내용도 함깨 관리할 수 있다. 요구 사항 변경 협의 요구 사항이 변경될 경우 근거 자료인 회의록(Meeting Minutes)을 남겨야 한다. 회의록에서 나..
태스크란 상세 요구 사항을 구현하기 위해 디자인, 문서 작성, 코딩, 테스트 과정에서 발견된 버그들을 처리하는 행위를 태스크라고 한다. 태스크는 1~2일 단위로 처리할 수 있도록 분리한다. 요구사항 ~ 태스크까지 계층 구조를 갖는 연결성을 부여한다. 개발 프로세스에 맞는 태스크 종류를 정의한다. 태스크의 종류 작업 아이템 (Working Item) 디자인, 구현, 디버깅 작업등에 해당한다. 문서화 (Documentation) 산출물/매뉴얼을 작성하는 문서화 작업이다. 테스트 (Test) 태스크를 테스트한다. 코딩에서 테스트 작업, 문서화에선 리뷰를 통한 테스트 이다. 버그 (Bug) 테스트 과정에서 생긴 버그에 해당하며, 추적성을 부여하기 위해 서브 요구 사항과 연결한다. 우선순위 결정 보통 1달 주기의..
다음과 같은 절차를 통해서 NoSQL의 데이터 모델링이 진행 된다. 도메인 모델 파악하기 데이터 출력 형태 디자인(쿼리 결과 디자인) 패턴을 이용한 데이터 모델링 최적화에 필요한 기능 리스팅 후보 NoSQL 선정과 테스트 데이터 모델을 선정한 NoSQL에 최정화 및 하드웨어 디자인 도메인 모델 파악하기 RDBMS든 NoSQL이든 먼저 도메인 모델을 파악해야 한다. 어떤 데이터 개체가 있고 데이터 개체 간의 관계가 어떻게 되는지를 파악한 후 ERD를 그린다. 해당 과정 없이 바로 어플리케이션 관점에서 접근하면 저장할 데이터에 대한 명확한 이해 없이 데이터 모델링을 하는 것이기 때문에 문제가 생길 수 있다. 간단한 블로그 시스템의 도메인 모델이다. 사용자 ID를 기반으로 블로그의 분류를 가진다. 분류별로 글..
NoSQL/RDBMS의 데이터 모델링 차이 쿼리결과 지향 모델링 NoSQL은 복잡한 쿼리를 할 수 없기 때문에 필요한 쿼리를 정의하고 데이터 저장 모델인 테이블을 디자인 한다. RDBMS : 도메인 모델 -> 테이블 -> 쿼리 NoSQL : 도메인 모델 -> 쿼리 -> 테이블 역정규화 RDBMS : 모델링은 데이터 일관성과 도메인 모델의 일치성을 위해 데이터 모델을 정규화한다. NoSQL : 쿼리의 효율성을 위해 데이터를 의도적으로 중복해서 저장하는 것과 같이 데이터 모델을 비정규화 한다. NoSQL 데이터 모델링 패턴 NoSQL은 RDBMS의 쿼리 기능들 (ORDER BY, GROUP BY, JOIN, INDEX)을 지원하지 않기 때문에 데이터 모델링을 통해 쿼리 기능들을 구현해야 한다. 기본적인 데이..
NoSQL이란 시대에 따라 다르게 요구되는 데이터 저장 기술이 바뀌면서 NoSql이 대두되었다. RDBMS는 기존 기업의 복잡한 데이터를 저장/분석 하는대 최적화 되었다. 기존의 기업에서 사용된 데이터는 한정된 규모와 복잡한 관계를 가진 데이터였다. NoSql은 근래에 SNS가 활성화 되고 그에 따라 단순한 형태의 대규모 대이터가 생산되었고 이런 데이터 저장 기술에 대한 요구사항이 바뀌면서 이 대두되었다. 대용량 데이터를 가장 많이 보유했던 구글과 아마존에 의해 Bigtable과 Dynamo라는 논문이 발표되면서 새로운 데이터 저장 기술을 만들어내는 시발점이 되었다. NoSql(Not Only SQL)은 RDBMS와 다른 형태의 테이터 저장 구조를 총칭한다. 따라서 제품에 따라 특성이 다르기 때문에 No..