목록Architecture/Infrastructure (17)
ecsimsw
Dynamic secret 정적인 Secret은 위험하다. 사용자가 모두 같은 키 공유하기 때문에 하나의 키만 탈취당해도 모든 권한을 갖는다. 마찬가지로 하나의 키를 공유하여 여러 서비스가 사용하고 있기에 퇴사자가 생기거나 탈취 상황에서 키를 만료시키기 쉽지 않다. 극단적인 예로 하나의 AWS 키를 모든 개발자와 CI/CD agent가 사용하다가 퇴사자가 나쁜 마음을 먹고 키를 사용한다고 가정해 보자. 키를 revoke -> renew 하는 사이 시간 동안 모든 개발 작업, CI/CD 동작들이 멈출 것이다. Dynamic secret은 미리 정의한 사용자 허가 범위에 따라 임시 키를 만들어 사용자에게 반환한다. 그 임시 키는 사용자마다 공통되지 않고, 만료 기간이 정의되어 있어 기간 외엔 사용할 수 없는..
Vault 시작하기 Vault의 가장 기본적인 기능들을 소개한다. 0. Vault dev server 실행 1. Secret Engine의 개념과 Secret 생성 2. Seal / Unseal 3. Auth engine / Auth method 4. Policy로 접근 가능 리소스, 액션 제한 5. Entity, 여러 인증 방식을 사용자로 묶어 관리 6. Group, 여러 Entity를 집합으로 관리 0. 간단한 Dev server 실행 Dev server 설치가 간단해서 로컬에서 먼저 테스트해 보기 좋다. 실 서버는 정책이나 설정, Audit을 저장할 저장소가 필요하지만 개발 서버는 인 메모리로 실행되어 Vault 외 준비할 것들이 없다. 1. vault 설치 brew tap hashicorp/tap..
AWS 자원 생성 시에 태깅을 강제하자 AWS의 비용을 계산하고 유휴 자원을 관리하려고 한다. 문제는 어디에 사용되었는지 모르는 레거시 자원들과 여러 팀이 얽힌 프로젝트, 퇴사자들로 이 자원이 현재 사용되고 있는지, 바로 삭제해 버려도 되는지 자원의 출처와 사용처를 알기 어려웠다. 이런 배경 아래, 자원 생성하는 과정에서 태깅을 강제하는 정책을 고민했고 이를 IAM Policy로 풀었던 경험과 필요 개념, 간단한 팁을 공유하고자 한다. 0. 요구 사항 0. 기존 Policy 정책/사용자 그룹은 가능한 건드리지 않도록 한다. 1. 사용자는 정책으로 지정한 자원을 생성하는 경우 태그를 붙여야만 한다. 2. 단순히 태그의 Key 값만 일치하면 생성을 허용할 수 있는 조건이 있을 수 있다. 3. 태그의 Key에..
How to add new hosted VPC 회사 내부에서 사용하는 내부 서비스 도메인이 public하게 열려있었다. 이를 외부에 노출되지 않도록 하고 싶었다. 개발/테스트/배포 환경 등 서비스 환경에 따라 다른 AWS 계정과 리전, 인프라가 분리되어 있었고, 모든 각 계정/리전마다 사용할 DNS를 등록하는 것이 아닌 전면의 한 계정에서 공통된 도메인을 갖고, 노출된 VPC만 따로 등록하는 식으로 관리 포인트를 줄일 수 있었다. Route53의 private dns를 사용해서 지정된 VPC 안에서만 접근할 수 있는 내부용 DNS를 만들 수 있었다. How to configure Route53에서 Dns를 생성할 때 private hosted zone 를 선택할 수 있다. 이때 같은 도메인 이름으로 pu..
개념 1. 리버스 프록시 / Web server와 Web Application Server의 분리 서버 아키텍처에서 WAS(web application server)와 web server를 분리하는 방식이 보편적으로 사용되고 있다. 위 구조처럼 사용자 요청을 처리하는 로직을 갖는 서버 애플리케이션 전면에서 web server를 둬, 사용자 요청이 해당 web server를 거쳐 WAS에 전달되고, 반대로 WAS에서 처리가 완료된 결과가 WAS를 거쳐 다시 사용자에게 응답하는 구조이다. 이렇게 WAS 전면에 요청을 선 처리할 수 있는 web server를 두는 형태, 또는 그 web server를 리버스 프록시(reverse proxy)라고 한다. 이런 구조가 갖는 이점은 다음과 같다. 1. 정적 요청에 ..
CloudWatch agent 로그 파일 지정과 이벤트 수집 Spring application에서 발생하는 로그 파일을 확인하기 위해 매번 인스턴스에 직접 들어가서 파일을 확인하는 작업은 번거롭고, 위험하다. 가급적이면 개발자 개인이 배포 서버 인스턴스를 직접 건드는 작업을 피하고 싶었고, application에서 생성되는 로그 파일을 CloudWatch에 출력하고자 했다. 애플리케이션에서 생성된 파일을 CloudWatch에 출력하는 방법, 그리고 파일로 생성하지 않고 서버의 정보를 CloudWatch에 직접 뿌리는 방법을 공부해왔다. 전자의 경우에는 에러 파일을 그래도 출력하기 위함이었고, 후자의 경우에는 서버의 동작 여부를 확인하기 위함이었다. 해당 프로젝트내에선 사실상 에러 로깅 외의 로그가 없었고..
AWS Cloudwatch Agent AWS Cloudwatch로 인스턴스 상태를 확인, 관리할 수 있다. CloudWatch에서 기본적으로 제공하는 cpu 사용률, 네트워크 패킷 수 외에도, 다음을 따라 Cloudwatch agent를 이용하면 해당 인스턴스의 메모리와 디스크 사용률까지도 확인할 수 있다. 적용한 Cloudwatch 대시보드는 아래와 같다. 1. IAM role, ec2 cloudwatch API 생성 2. 원하는 ec2 인스턴스에 해당 role 적용 3. 우분투 기준, CloudWatchAgent 다운로드 및 설치 wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent..
Load Balancing과 세션 유지 로드 밸런싱을 간단히 말하면, 트래픽을 한 서버에서 모두 처리하는 것이 아니라, 다수의 서버에 적절하게 분배해주는 것이다. 보통 여러 대의 WAS 전면에 Web Server를 두고, 요청을 WAS에 적절히 나누는 식으로 사용된다. 이렇게 로드 밸런싱을 이용하면 서버의 부담도 줄일 수 있으면서, 한 서버가 다운되더라도 서비스를 이어갈 수 있다는 장점이 있다. 문제는 세션이다. 세션은 서버에 데이터를 저장한다고 배웠는데, 여러 was에 요청을 분산하면 세션 지속에 문제가 없을까 궁금했다. 해결책 먼저 세션 지속을 보장하는 Web Server를 사용할 수 있을 것 같다. 예를 들면 NginX plus는 Session Persistence를 지원하고 있음을 확인했다. (S..