본문 바로가기

분류 전체보기

AWS CodeDeploy와 AWS CodeDeploy Agent (1) - 1. CodeDeploy 요즘 AWS CodeDeploy Agent 오픈소스 커미터되기 스터디를 하고 있다. AWS CodeDeploy Agent 코드를 분석하면서 알게 된 내용들을 틈틈이 정리해보고자 한다 👩‍🎓 1. CodeDeploy CodeDeploy의 기본적인 구동 방식 ( 참고 링크 ) 1. AWS CodeDeploy Agent 코드를 다운받아서, AWS EC2에 실행시켜두기 2. AWS CodeDeploy 에서 배포하기 3. AWS CodeDeploy에서 배포되었다는걸, Agent가 감지하면 코드를 EC2에 복사시켜준다. EC2에 CodeDeploy 세팅하는 방법 https://jojoldu.tistory.com/281 CodeDeploy에서 배포할 코드를 가져오는 방법 1. S3에 배포할 파일 압축해서 올려두기 압..
(Django) Django로 e-commerce 개발할 때 참고하기 좋은 오픈소스 e-commerce Django 오픈소스 shuup django-rest-framework를 사용하고 있다면 강력추천한다. 가장 현실적이고, 참고하기 좋은 오픈소스다 ! https://github.com/shuup/shuup https://github.com/shuup/shuup-project-template saleor 가이드문서 - https://docs.getsaleor.com/en/latest/gettingstarted/installation-macos.html 데모 사이트 - https://demo.getsaleor.com/en/ django-oscar 메인 github - https://github.com/django-oscar/django-oscar/ 데모 사이트 - https://lates..
제럴드 와인버그 <Quality Software Book : How Software Is Built > - 9장 요약 Chapter 9: Why It's Always Hard to Steer9.2.2 The history of software engineeringThe Size/Complexity Dynamic 은 문제의 크기가 커질수록 복잡도가 제곱으로 높아지는 문제 유형을 말한다.소프트웨어 역사를 보면, 성공하는 경험을 할 수록, 조직은 점점 더 어려운 문제를 찾고, 도전해왔다. 그러면서 소프트웨어가 발전해왔다. 위의 그림은 소프트웨어 개발에 대한 effect diagram이다.소프트웨어 조직이 성공을 경험하면 -> 도전적인 과제를 찾아서 -> 문제의 크기가 커져서 -> 솔루션의 복잡도가 높아진다.문제의 난이도가 높아지면, 처음에는 개발자수를 늘리고, 고급인력을 채용하면서 리니어하게 문제를 해결할 수 있다. 그런데 ..
(Pytest) mongoengine + factoryboy 조합으로 사용할 때, 데이터 리셋시키기 mongoengine + factory boy 조합 문제점 원래 factoryboy를 쓰면, 테스트 데이터가 롤백된다. 그런데 mongoengine을 factory boy로 매핑해서 사용하면, 데이터가 롤백되지 않는다. mongo에 테스트 데이터가 계속 쌓인다. 해결방법 테스트코드가 돌때마다 몽고 디비를 drop 시키면 된다. ( 이렇게하면 몹시 느리다 ㅋ ) A. 몽고 DB Drop fixture 만들기 ### FILE: fixtures.py import pytest import mongoengine as me @pytest.fixture(scope=’function’) def mongo(request): db = me.connect(‘testdb’, host=’mongodb://localhost’) ..
(Draw.io) 온라인 다이어그램 툴 https://www.draw.io/여기 들어가서 그리면 된다 ㅎㅅㅎ XML으로 저장해두고, 나중에 재수정해서 쓸 수도 있다. 요런식으로 그려다가 쓰면 된다 ㅎㅅㅎ
(ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 4 ) - 안티패턴과 멱등성 관리 이 글은 [elastic] Keeping Elasticsearch in Sync 문서를 정리한 글 입니다 ㅎㅅㅎ 엘라스틱서치에 원본 데이터를 싱크할 때, 주의해야하는 점이 있다. Why Marking Source Records is an Anti-Pattern엘라스틱서치 인덱싱 필요 여부를 체크하는 방법 중, 원본 테이블에 필드를 하나 추가하는 방법이 있다. 그런데 이건 안티패턴이다. 하면 안된다. 안티패턴인 이유 1. 엘라스틱서치 데이터 복제와 원본 데이터 간의 커플링이 높아진다. 그러면 유지보수가 어렵다. - 장애로 실제 인덱싱 여부와 원본 데이터에 저장된 인덱싱 여부가 달라질 수도 있다. 2. 전체 테이블을 재인덱싱해야하는 경우, 전체 테이블을 업데이트해줘야한다. UPDATE SET reindex=..
(ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 3 ) - Batching Based on Ranges 이 글은 [elastic] Keeping Elasticsearch in Sync 문서를 정리한 글 입니다 ㅎㅅㅎ 이전글 ((ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 2 ))에서는 계속 변경되는 데이터를 엘라스틱서치에 싱크하는 방법에 대해서 설명했다.이번에는 Immutable한 데이터를 엘라스틱서치에 추가하는 방법에 대해서 설명하고자 한다. Batching Based on RangesImmutable한 데이터의 예시로는 로그가 있다. 로그는 한번 추가되어도, 변경되지 않는 데이터다. 그래서 이 경우에는 ElasticSearch에 Insert만한다. Update는 필요하지 않다. 이 경우, 큐를 이용해서 배치에 사용될 데이터를 가져오는건 오버스펙이다. 단순하게, 데이터를 가져와야하는 범위..
(ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 2 ) - Using Queues to Manage Batches 이 글은 [elastic] Keeping Elasticsearch in Sync 문서를 정리한 글 입니다 ㅎㅅㅎ 이전 글에서는 엘라스틱서치에 저장된 문서를 업데이트할 때, Batch로 한번에 업데이트하는게 효과적이라는 내용을 살펴봤었다. - (ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 1 ) 이번 글에서는 Batch로 한번에 업데이트할 문서 정보들을 원본 데이터에서 가져오는 방법에 대해서 정리해보려고 한다. Using Queues to Manage Batches배치로 데이터들을 일괄 업데이트하려면, 수정해야하는 데이터들만 골라서 가져와야한다. 이 때 큐를 사용하면 효율적으로 관리할 수 있다. 큐 대기열을 관리할 저장소로는 SQL 테이블, Redis Sorted Set 등을 사용할 수 있..