Grace's Tech Blog

첫 번째 프로젝트로 진행한 SAFU 웹 서비스 을 배포하기 위해 서버 구축을 하려하며, '서버 단위의 로드 밸런서' 아키텍쳐 중 애플리케이션 서버가 (일단은)하나인 아래의 구성으로 진행하고자 한다. 순서는 1. EC2 배포 및 inbound 설정 2. ACM 에서 SSL 인증서 발급 3. ELB 생성 및 리스너 세팅 4. Route53의 도메인과 ELB의 인스턴스 DNS 연결 5. EC2에 nginx 설치 및 세팅 으로 진행 될 것이다. Domain Name System이 뭐고, DNS의 구성 및 동작 원리 등은 매우 복잡하다. 그래서 다른 포스트에서 이에 대해 정리하고자 하며, 지금 해당 포스트에서는 4. Route53의 도메인과 ELB의 인스턴스 DNS 연결 에 대해서만 정리하고자 한다. 제목에 EL..

첫 번째 프로젝트로 진행한 SAFU 웹 서비스 을 배포하기 위해 서버 구축을 하려하며, '서버 단위의 로드 밸런서' 아키텍쳐 중 애플리케이션 서버가 (일단은)하나인 아래의 구성으로 진행하고자 한다. 순서는 1. EC2 배포 및 inbound 설정 2. ACM 에서 SSL 인증서 발급 3. ELB 생성 및 리스너 세팅 4. Route53의 도메인과 ELB의 인스턴스 DNS 연결 5. EC2에 nginx 설치 및 세팅 으로 진행 될 것이다. 세 번째 단계인 ELB 생성 및 리스너 세팅을 해보고자 한다. Load Balancing이란 로드 밸런싱은 네트워크 기술 중 하나로 네트워크 트래픽을 하나 이상의 서버나 장비로 분산하기 위한 *기술이다. * 그리고 이 기술을 수행하는 소프트웨어나 하드웨어를 Load Ba..

첫 번째 프로젝트로 진행한 SAFU 웹 서비스 을 배포하기 위해 서버 구축을 하려하며, '서버 단위의 로드 밸런서' 아키텍쳐 중 애플리케이션 서버가 (일단은)하나인 아래의 구성으로 진행하고자 한다. 순서는 1. EC2 배포 및 inbound 설정 2. ACM 에서 SSL 인증서 발급 3. ELB 생성 및 리스너 세팅 4. Route53의 도메인과 ELB의 인스턴스 DNS 연결 5. EC2에 nginx 설치 및 세팅 으로 진행 될 것이다. 두 번째 단계인 ACM 에서 SSL 인증서 발급을 해보고자 한다. 참, 왜 이러한 다섯 단계가 필요한가? 왜냐면 SAFU 웹 서비스 을 배포단계에서 막혔던 부분이 sameSite issue였는데, 이유는 HTTPS 프로토콜을 사용하지 않아서 sameSite = none을..

Amazon Web Service에는 매우 많은 서비스들이 있다. 이 중에는 가장 기본이 되어 다른 서비스들의 인프라와 같이 가장 폭넓게 역할을 하는 서비스도 있고, 특정 상황에서 편리하고 저렴하게 사용할 수 있는 특수화 된 서비스도 있다. AWS의 주요 서비스에 대해서 정리해보자면 아래와 같다. 1. AWS의 주요 서비스 1) 컴퓨팅 서비스 - Amazon EC2(Elastic Compute Cloud): 가상화 서버. 다양한 형태의 타입과 서비스에 따라 적합한 사양을 선택할 수 있으며, 사용량만큼 비용을 지불하는 컴퓨팅 서버. - Amazon Auto Scaling: 서버의 특정 조건(서버 사용량이 많은 경우 추가로 생성하고, 사용하지 않는 경우 서버를 자동으로 삭제)에 따라 서버를 추가/삭제 할 수..

주기 계산, 1일전, 8일전 등의 날짜 계산 등을 해야하는 일이 생기면서 기존의 DB의 schedules_date 테이블의 year, month, date로 나뉘는게 매우 비효율적이라는 의견이 제시되었다. 1일 전, 8일 전 year, month, date을 3번의 between을 걸어주는게 - 년도가 다를경우, 뒤의 월의 앞의 월보다 작은 경우, - 다음월로 넘어간 경우, 뒤의 날짜 일이 앞의 날짜 일보다 작은 경우 에 제대로 되지 않는 것이었다. HI님과 같이 구현하면서도 이런 점이 걱정된다고 얘기 나누었었고 마침 1일전, 8일전 등의 날짜 계산을 할 때도 그냥 Date 타입의 필드 하나만 있는 것이 좋을 것 같다는 생각을 하고 있었는데, HJ님께서 질문을 주신 김에 year, month, date ..

우리 서비스(SAFU)는 '깃헙으로 로그인하기(간편 로그인 기능)'을 제공한다. HJ님과 나를 아주 맘고생시켰던 깃헙 소셜로그인..ㅎㅎ 특히 client가 사용하는 주소(port:3000)와 server가 사용하는 주소(port:4000)이 달라서 리다이렉트 로직이 너무 헷갈려서 힘들었다. 예전에 OAuth2와 소셜로그인에 대해서 블로그에 정리한 적이 있었지만 백지상태에서 처음부터 구현하려고 하니 결국 내가 아무것도 모르고 있는 상태였구나를 깨달았다. 그 포스팅과 이번에 구현해본 코드를 통해 여기에 내가 이해한 바를 다시 한번 자세히 정리해보기로 했다. 1. OAuth2의 이해 libertegrace.tistory.com/entry/40-Authentication-OAuth-20 40. Authentic..

점점 SAFU 웹페이지가 예뻐지고 있다! SH님께서 CSS를 전적으로 담당해주셔서 시간이 갈 수록 점점 예뻐지고 있다. 회원가입, 로그인, 로그아웃, 아이디 비번 찾기, 리뷰 카드 랜더링, 로그인 전/후 메인 페이지 까지 구현이 완료 되었다. 로그인 후 Mypage 버튼을 누르면 이 페이지로 이동하며 Mypage는 컴포넌트는 회원 정보 출력과 컴포넌트로 구성되어 있다. 들어가자마자 자신의 회원 정보와 자신이 작성한 리뷰카드들이 보여야 하며 컴포넌트의 '회원정보수정' 버튼을 누르면 비밀번호와 githubID를 수정할 수 있는 /Editinfo 페이지로 넘어간다. 그리고 컴포넌트의 각 카드인 컴포넌트에서 바로 리뷰 수정을 할 수도 있다. 여기서 Oct 26, 2020 ~ Oct 30, 2020 동안 구현한 ..

벌써 Bare Minimum을 마무리 하기로 한 31일이 일주일도 채 남지 않았다. 제목은 통일성있게 맞추려하다보니 이라고 지었지만 저것만 한 것은 아니다. Client와 Server의 통신이 바로바로 확인 되고 두 파트 모두 마무리가 되는 것을 확인해봐야 다음 기능 구현으로 넘어가기에도 수월하다는 것을 프로젝트 초반부터 깨달았고, 그러다보니 양 쪽 파트의 PR사항을 그날그날 코드 리뷰하느라 여기에도 코드 작업하는 시간 만큼 쓰이는 것 같다. 양 쪽 파트를 모두 코드리뷰하는 것은 정말 좋다. Client 파트를 맡아서 Server구현을 프로젝트가 진행되는 한 달간 못(?) 하게 되어 잊어버리면 어떡하지? 라는 걱정이 있었는데 코드리뷰를 통해 이 걱정은 할 필요가 없게 되었다. 또 블로그를 통해 각 기능에..

API 와 마찬가지로 DB schema역시 Client 파트와 Server 파트의 커뮤니케이션 및 합의가 많이 이루어지는 부분이다. 프로젝트를 진행하기 이전에는 DB에서 MVC 디자인 패턴으로 데이터를 가져오는 것은 Server 파트라고 생각했던 탓인지 client와 server 파트를 오가며 코드 리뷰하는데 이 부분이 은근 많은 걸림돌이 되었다. 그리고 프로젝트가 2/3 정도 마무리 될 쯤에 회원탈퇴에 대한 DB 처리 이슈가 큰 논의사항이 되었고, 그래서 많은 마이그레이션이 이루어졌는데, 만약 이러한 상황이 파트 불문하고 커뮤니케이션이 바로바로 이루어지지 않았다면 DB가 꼬여버리는 현상이 발생하게 된다. (ex. '같은 시점에서 저도 pull 받아왔는데 저는 왜 DB에서 데이터를 받아올 때 null 에..

https://nodejs.org/ko/docs/guides/anatomy-of-an-http-transaction/ HTTP 트랜잭션 해부 | Node.js Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine. nodejs.org Interaction With Server Sprint에서는 Client와 Server 통신에 관한 개념을 배우고, (이미 잘 구축되어있는 Server가 있어서)fetchAPI를 이용하여서 Client를 구축 하고, 서버에 GET, POST요청을 보내고 그 응답 결과를 이용해 화면을 구성하고 변경하는 것에 대해 배웠다. 이번 Server&Node Sprint에서는 node.js를 이용하여 이미 잘 구..