Grace's Tech Blog

첫 번째 프로젝트로 진행한 SAFU 웹 서비스 을 배포하기 위해 서버 구축을 하려하며, '서버 단위의 로드 밸런서' 아키텍쳐 중 애플리케이션 서버가 (일단은)하나인 아래의 구성으로 진행하고자 한다. [EC2] AWS를 이용한 서버 환경 이해 및 구축에 정리해둔 를 보면 단일서버의 여러 단점으로 인해 애플리케이션과 데이터베이스 서버를 분리하는 구조가 나왔다. 그리고 서버 단위의 로드 밸런서는 이런 구조로 되어 있다. 여기서 RDS로 데이터베이스 서버를 만들어보고자 한다. 1. Amazon RDS(Relational Database Services) Amazon RDS는 클라우드에서 관계형 데이터베이스를 간편하게 설정, 운영, 확장 할 수 있는 서비스이다. 이는 매우 비싸다. (프리티어는 RDS 단일 AZ(..

AWS 공부와 병행하여 배포를 진행하였기때문에 AWS 카테고리에 정리 및 저장해 놓았습니다. 여기에는 링크를 순서대로 삽입하는 것으로 대신하겠습니다. Server Side 1. [EC2] AWS를 이용한 서버 환경 이해 및 구축 2. [ACM] 도메인 주소 생성 및 AWS Certification 3. [ELB] Elastic Load Balancer 생성 및 세팅 4. [Route 53] Route53의 도메인과 DNS 연결 5. [NGINX] EC2에 nginx 설치 및 세팅 Database 1. [RDS] 데이터베이스 서버 생성과 접속 Client Side 1. [ACM] 도메인 주소 생성 및 AWS Certification 2. [S3] S3를 이용한 정적 웹 사이트 호스팅 3. [CloudFro..

첫 번째 프로젝트로 진행한 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구현을 프로젝트가 진행되는 한 달간 못(?) 하게 되어 잊어버리면 어떡하지? 라는 걱정이 있었는데 코드리뷰를 통해 이 걱정은 할 필요가 없게 되었다. 또 블로그를 통해 각 기능에..