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

흔히 VPC, Subnets 을 설계할 때 Public Subnet 과 Private Subnet 의 형태로 구성이 된다. Public Subnet 의 경우 Load Balancer 혹은 web internet facing 자원들을 배치하게 되고, Private Subnet 의 경우 RDS 나 back-end application 을 배치하게 된다. Private Subnet 의 경우 Public Subnet 과는 다르게 Internet 을 통해서 직접 연결을 할 수 없기 때문에 추가의 작업이 필요하다. 예를 들어, Private Subnet 에 있는 Database 작업을 위해서 접속해야한다. 1. Bastion Host - Public Subnet 에 Bastion Host 를 구성하여 Bastion Host 를 통해서 Private Subnet 의 자원에 접속하고 관리한다. Bastion Host 의 경우 별도로 관리해야할 EC2 혹은 VM 이 증가하게 되는 단점이 있다. 2. VPN - VPN 은 비교적 Bastion Host 나 Security Group 설정에 비해서 비용이 많이 든다. 각각의 장단점이 있기 때문에 상황에 맞게 사용해야 한다. 위의 방법 말고 AWS Session Manager 를 이용할 수 있다.  AWS Session Manager 는 AWS Systems Manager 라는 서비스의 속한 기능으로 EC2 혹은 온프레미스 환경의 VM 들을 관리할 수 있는 기능이다.  Session Manager 가 동작하는 원리는 SSM Agent 를 통해서 Session Manager 와 통신한다. 따라서 접속하려는 EC2 혹은 온프레미스 환경의 VM 에 SSM Agent 가 설치되어야 한다. 또한 EC2 에 적절한 instance profile 이 설정 되어 있어야한다.  - AmazonSSMManagedInstanceCore - AmazonSSMDirectoryServiceAccess 그리고 EC2 의 user da...

Github Action 을 이용하여 Spring Boot Multi Modules Project 를 환경에 따라 Gradle 을 이용하여 Jar Artifact 를 생성하고 이를 바탕으로 Docker Image Build 와 ECR 에 Push 하는 과정을 정리해보겠다. 1. Project Structure - folder, gradle, dockerfile 먼저 프로젝트 구조는 아래의 이미지와 같다. gradle multi module 의 구조이며 batch, buyer-auth, seller-auth, product, order 로 총 5개의 모듈로 구성되어 있다. 각각의 모듈하위에는 Dockerfile 을 작성했다. 아래는 각 모듈 하위에 있는 Dockerfile 의 예시 이다.  Spring Boot 2.5.4 와 java 11 LTS 를 사용했다. 2. aws ecr private repository, iam user with policy 다음으로 각각의 모듈들의 이미지 저장소로 Private ECR 을 terraform 을 이용하여 아래와 같이 작성했다. 각각의 이미지 태그는 변경이 불가능하도록 IMMUTABLE 을 활성화 했다. Private Repository 로 생성했기 때문에, 해당 레포지에 대하여 읽기/쓰기 작업을 하기 위해서는 별도의 IAM 계정의 권한이 필요하다. 아래의 공식 문서를 통해서 private ecr repository 들에 대해서 이미지를 push 와 pull 을 가능하도록 IAM user 를 설정해야 한다. 혹은 어드민 권한을 가진 IAM user 를 통해서 사용가능 하겠지만, 보안을 준수하는 방법이 아니기 때문에 권한을 세세하게 나누어서 관리하는 것이 권장사항이다. https://docs.aws.amazon.com/ko_kr/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html 3. github action yaml file 4. enviro...

먼저 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 에게 요청을 하는 것을 의미한...