Developing

Amazon Load Balancer와 EC2 Instance를 연결하여 웹을 실행하는 클립을 복습하고 다른 클립을 수강하는식으로 챌린지를 진행하였다. 매번 EC2와 RDS를 지우고 작업하다보니 예상치못했던 상황들에 부딪히게 되는데 나름 대처를 잘 하고 있는 것 같다. 가령 RDS 이름이 default명으로 되어있는 것으로 사용하다가 project명 설정해주는 것을 깜빡해서 다시 default명으로 생성해주었는데 그것으로 인해 database 변수의 host이름으로 넣어야하는 내용이 미세하게 달라지는 부분이 있다던지, rds mysql inbound설정이라던지, 새로 생성한 ec2주소 적용이라던지, ubuntu에서 pull 해준다던지.. 거의 매일매일 생성과 삭제를 반복해서 그때마다 새로 해주니 이것저것..

로드밸런서 L4/L7의 동작원리와 AWS ELB의 개념에 관한 클립을 복습하고 새 클립을 수강하는식으로 챌린지를 진행하였다. 평소에 궁금하던 내용이었는데 OSI 7 layer와 접목해서 설명해주셔서 잘 이해가 갔던 것 같다. 추후의 강좌에는 L7을 위주로 진행할 것이라 하였고, L4,L7로드밸런서의 장단점도 알 수 있었다. 다음 포스팅은 EC2와 로드밸런싱에 관련된 포스팅을 할 예정이다. 로드밸런싱 서버에게 정보를 요청하는 Client가 늘어날때 서버가 감당하기 힘들 수 있다. ⇒ 이를 해결하기 위한 2가지정도의 방법이 있다. 1. 서버의 용량이나 성능을 올린다. 2. 서버를 더 두어서 트래픽을 분산시키는 방법이 있다. 첫번째 방법은 감당가능한 트래픽의 수를 많이 늘려야하는 상황에서 서버의 용량이 압도적..

EC2에 벡엔드 개발한 Django Project를 Deploy해보는 내용의 클립을 복습하고 다른 클립을 수강하는식으로 챌린지를 진행하였다. RDS와 EC2는 매번 사용하면 바로바로 닫아주기에 생성해주어 설정 반영해주어 진행해주었다. 강사분은 github desktop을 사용하시면서 문제생기면 그때마다 다 지우고 새로 clone하는 식으로 진행하셨고 개인적으로는 cmder 쓰면서 수정할 내용 있으면 push 해주고 ubuntu에서 pull 해주는 방식으로 진행하였다. 기존에 패키지 명령어들이나 requirements 사용하는게 많이 익숙하진 않았는데 이번에 좀 익힌 것 같다.. 다음 포스팅은 로드밸런싱에 관련된 포스팅을 할 예정이다. EC2에 Django Project 배포하기 EC2를 하나 생성해주고,..

Amazon RDS 서비스와 연동하는 부분의 클립을 복습하고 새로운 클립을 수강하는식으로 챌린지를 진행하였다. Django에서 migrate 명령어를 실행할때 'django.db.utils.operationalerror' 가 발생하였었는데, 해당 문제를 AWS 메뉴얼이나 다른 개발블로그들을 통해 여러 방법을 시도하여 해결하였다. 그중에 원인이었던 내용을 간단하게 포스팅하려고 한다. 한편으로 RDS 과금정책 관련해서 찾다보니 '생각보다 과금이 빡셀 것 같다'라는 생각이 많이 들었다.. 다음 포스팅은 EC2에 지금껏 백엔드개발을 한 Django Project를 올리는 내용과 관련된 포스팅을 할 예정이다. Amazon RDS 활용하기 Django에서 RDS를 사용하기 위해서는 우선 AWS RDS서비스에서 DB..

3주가 넘는시간동안 포스팅을 하다보니 문득 캐시백 챌린지이벤트로 30일정도의 기간으로 성공하는 사람들이 대단하다고 느껴졌다.(그런데 이번엔 무려 66일이라는 기간인데다 성공조건이 상당히 까다롭다..ㅎㅎ..;;;;) 더불어서 1일 1커밋 블로깅하고 커밋하는 개발자들이 존경스러워진다.. 저번에 언급한 것과같이 A to Z 모든 과정을 모두 보이려고하면 포스팅이 Long~~~~long 해지고 많은 내용을 챌린지기간동안 포스팅에 다루지는 못할거같기에 주요내용만 짚고 넘어가는식으로 포스팅을 하려고한다. 매일매일 블로깅하다보니 무슨 내용을 어떻게 담아야할지 매번 콘티(?)를 짜는 기분이다.. 기존계획은 Boss app과 Delivery app 파트부분을 2개정도로 나누어서 포스팅하려고했지만 구성을 하다보니 한포스팅..

포스팅을 하기 앞서서 큰 고민에 빠졌었는데, A to Z의 모든과정을 다 포스팅에 녹이면서 하기에는 엄청 늘어질 것 같다는 생각이 들었다. 그래서 주요한 내용들을 언급하고 빠르게 다음 내용으로 넘기는 식으로 포스팅하는 것이 바람직하다는 결론에 이르렀다. 가령 오늘 할 포스팅을 Order 쪽 부분의 백엔드 파트를 A to Z 다 과정을 보이려면 앞으로 한 3개정도로 나뉘어서 포스팅을 해야하는데, 그것은 너무 비효율적이라는 판단이 섰다. 크게는 Order App - Boss App - Delivery App 로 구성되어있는데 Order쪽은 1포스팅 , Boss나 Delivery쪽을 1~2포스팅으로 단축시킬 수 있을 것 같다. (단축안시키면 포스팅이 너무 많아져버린다.) Boss App에 대한파트 클립들을 전..