기록들 https://github.com/ndgndg91

먼저 TTL (Time To Live) 의 개념을 정리해보자. 한국말로 "살아 있을 시간" 으로 해석할 수 있다. 무엇이 살아 있을 시간일까? 주로 TTL 은 Cache 개념과 묶여서 설명할 수 있다. 따라서 Cache 이야기를 먼저해보자. Client Server topology 에서 예를 들자면, Client 가 특정 자원을 Server 에 요청을 할 것이다. Server 는 해당 Client 의 요청에 대해서 응답하기 위해서 Server Side Resource (CPU, Memory etc.) 를 사용할 것이다. 하지만 Client 의 요청이 많아질수록 이는 Server 의 부담이 된다. 만약에 동일한 응답을 Client에게 반환할 경우에 이전의 응답한 결과를 다시 사용할 수 있다면 자원 활용도를 높일 수 있다. 하지만 이전의 응답한 결과에 변경이 발생한다면 Server 는 올바르지 않은 응답을 하게 된다.  이와 같은 현상을 해결하기 위해서는 변경되지 않을 자원만 Cache 를 적용 하거나, 변경되는 자원을 Cache 와 Sync 를 할 수 있는 전략들이 필요하다. Cache 전략은 여러가지가 있고 제공하고자 하는 데이터에 따라 그리고 아키텍쳐에 따라 여러가지 적용 기법이 있겠지만 몇 가지만 들어보겠다. 처한 상황에 따라서 어느 한 가지만 사용할 수도 있고, 여러 전략들을 동시에 취합해서 사용해야 하기도 한다. Lazy Loading / Cache-Aside 이름에서 추측할 수 있듯이, 필요할 때 데이터를 Cache 에 로드하는 전략이다.  Cache Hit 예를 들어, Client 가 Server 에 요청을 한다. 제일 먼저 Cache 저장소에 Cache 데이터가 있는지 확인한다. Cache 저장소에 Cache 데이터가 있고, 해당 Cache 데이터가 stale 이 아닌 최신 상태라면 바로 Client 에 해당 데이터로 응답한다. Cache Miss Cache 데이터가 Cache 저장소에 없거나 stale 이라면, 원래의 데이터 저...

 Mutable Infrastructure 필요할 때 변경하고 업그레이드하는 인프라를 말한다. 예를 들어 10 대의 VM 혹은 여러 대의 물리 서버가 있을 경우, 관리자는 SSH 접속을 통해 하나하나 접속하여 패키지를 수동으로 업그레이드 하거나 다운그레이드 하면서 직접 관리한다. 그리고 기존 서버에 직접 새 코드를 배포한다. 이 과정에서 패키지 설치 혹은 변경에 실패할 수 도 있고 성공할 수 도있다. 이로 인해서 서버간의 조금씩 차이가 발생하게 된다. 제각기 다른 크기의 눈송이와 같다고 하여 snowflake server 라 부른다. 다른 용어로는 configuration drift 라고 한다. Immutable Infrastructure Mutable 과는 다르게, 한 번 프로비전되거나 배포가 되었을 때 해당 서버의 변경을 만들지 않는다. 변경사항이 발생하거나 업데이트가 필요할 때는 해당 서버에서 작업하지 않고, 새로운 VM 혹은 이미지를 통해서 서버를 생성하고 교체한다. 이전 버전의 서버는 버려진다. 재에서 부터 다시 살아나는 피닉스에 비유하여 Phoenix server 라 부른다. Pet (Snowflake Server) and Cattle (Phoenix Server) 눈송이 서버와 피닉스 서버 처럼 비유되는 또 다른 표현이 있다. 바로 pet 과 cattle 이다. 왜 snowflake server 를 pet 에 비유했을까? pet 은 애완동물이다. 애완동물은 하나하나 제각기 주인들에게 특별하게 여겨지며 사랑받는다. 강아지의 경우 이름은 "호두", "룽지", "희동이" 등 각각 특별하다. 이는 snowflake server 처럼 각각의 서버가 다르게 설정될 수 있다는 것에 비유해서 pet 이라는 별칭이 붙게 되었다. 그렇다면 phoenix server 는 어째서 cattle 에 비유될까? cattle 은 소, 가축을 의미한다. 보통 농장에서 가축을 키울 때, 애완동물과는 다르게 사육한다. 가축에게는...

사이드 프로젝트 여정 제 4탄의 주제는 AWS 비용을 줄여보자! 이다. Back-end Spring boot 와 Docker 와 ECR 등 정리해야 될 것들이 남아 있지만.. 그동안 너무 글을 쓰는게 귀찮았다. 그러다가 요 몇달동안 AWS 비용이 부담스러워서 비용절감을 하는 과정을 정리한다.  우선 아래는 그동안 1~3탄의 내용이다. 1탄 : SSO 2탄 : AWS Amplify 3탄 : CORS && SOP with Spring Boot 2021년 3월 AWS 사용 요금이다. 10만 7천원 가량 나왔다.. RDS 는 익히 가격이 비싸다는 것은 알고 있지만, ELB 가 이렇게 비싼줄 몰랐다. 2월 보다 더 나온 이유는 당연히 3월은 31일 까지 있으니.. 2월 보다 가동시간이 많다.    아래는 2021년 2월 요금이다. 2월 부터 1 ~ 말일 까지 풀로 24시간 내내 돌린 비용이다.. 아래는 2021년 1월 요금이다. 1월 초중순에 서비스를 출시 했었나?,, 기억이 정확하게 안나지만,, 1월 내내 풀로 가동한것이 아니기 때문에 제일 비용이 낮다. my.new 서비스의 처음 출시 아키텍쳐 다이어그램이다. 인증 서버와 자원(Resource) 서버를 나누어서 만들었다. 인증서버는 user.my.new 라는 도메인을 사용했고, ALB 와 ACM 을 통해서 SSL 을 적용했다. 자원(Resource) 서버는 app.my.new 라는 도메인으로 그리고 마찬가지로 ALB 와 ACM 을 통해서 SSL 적용했다. 이처럼 ALB 2개, 인증 서버 EC2 t3.micro, 자원 서버 t3.small 을 프로비저닝 했다. 위에 1월, 2월, 3월 요금 내역을 보면 ELB 가 가장 많은 비용이 든다. ELB 를 사용한 이유는 1가지 뿐이였다.  바로 CORS 를 위해서 SSL 적용이다. 물론 이 서비스가 진짜 잘되서 EC2 하나로 트래픽을 감당하지 못해서 Auto Scale group 을 사용하기위해서 ELB 를 사용할 수 도 있지만...

사이드 프로젝트 여정 제 3탄의 주제는 개발자라면 누구나 한 번 쯤 마주치는 SOP, CORS 에 대해서 이전에 정리한 것 보다 상세하게 정리하고, Spring Boot 에서 어떻게 동작 하는지 어떻게 적용하는지 정리를 해보려고 한다. 1탄 : SSO 2탄 : AWS Amplify 3탄 : CORS && SOP with Spring Boot 먼저, CORS 란 무엇인가? Cross Origin Resource Sharing 의 약자이다. 한국어로는 교차 출처 리소스 공유이다. 역시 번역은 쓸모없는 경우가 많다.  Origin ? Protocol + Host + Port 를 합쳐서 Origin 이라고 부른다. ex) http://localhost:8080 은 하나의 Origin 이다. 그렇다면 Cross Origin 은 뭘까? 한국어로 교차 출처라고 하는데, 쉽게 말해서 Origin 이 다를 때 Cross Origin 이라고 한다. Origin 이 다르다는 의미는 무엇일까? 방금 언급한 Protocol + Host + Port 중 하나라도 다르면 Cross Origin 이다. ex) http://localhost:8080 과 http://localhost:9090 은 Cross Origin 이다. ex) http://example.com 과 https://example.com 도 Cross Origin 이다. ex) https://example.com 과 https://www.example.com 도 Cross Origin 이다. Cross Origin 이 무엇인지 알아봤는데 리소스 공유는 무엇인가? web application 스스로 자원을 가지고 있어서 방문자들에게 serving 을 할 수 도있지만, 다른 server 에 있는 자원을 요청해서 보여주거나, 다른 server 에 어떤 자원을 생성하거나 삭제하거나 변경하기 위해서 요청을 할 수도 있다. 다른 server 에 요청할 때 이는 Cross Origin 에게 요청을 하는 것을 의미한...