ecsimsw

About Vault 회사에서 키 관리를 위해 HashiCorp 사의 Vault를 도입하였다. 이 글에서는 내가 키 관리를 하면서 어떤 상황들을 고려해야 했는지, Vault는 뭐고 Vault는 그 문제들을 어떻게 해결했는지를 소개하려고 한다. 혼자 공부할 때는 키 관리에 이렇게까지 신경 쓰지 못 했다. 로컬에 들고 있거나 잘해봐야 github private 저장소에 올려 관리하는 정도였다. 회사에서는 여러 사람들이 키를 사용하고, 퇴사자를 고민해야 하고, 사용자 안에서도 권한을 분리해야 하는 등의 여러 요구 사항을 만나면서 이제는 당연하지만 지금까지 고려하지 못했던 것들을 고민할 수 있게 되었다. 이렇게 키 관리에 대한 고민을 전혀 못하고 있던 나에게 팀에서 고려 해야하는 상황과 공부 방향, 정책을 함께..

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..

요구 사항 : trigger filtering by tag name 회사에서 젠킨스 Trigger를 사용해서 레포지토리에서 발생하는 web hook을 받아 빌드를 자동으로 할 수 있도록 하는 작업을 맡게 되었다. 문제는 한 레포지토리 안에서, branch나 comment가 아닌, tag 이름으로 구분되는 Job이었다. - 한 코드 저장소 안에서 tag로 구분된 여러 JOB이 있었다. - 태그가 생성되는 이벤트를 받아 이 여러 JOB 빌드를 실행시켜야 하는데, JOB에 해당하는 tag가 아닐 경우 빌드를 실행시키지 않는 필터링이 추가되어야 한다. Webhook request 안의 정보를 이용해서 깔끔하게 필터링 할 수 있는 방법을 고민했고, 괜찮은 플러그인을 찾아 소개하게 되었다. 1. Generic We..

배경 발명소 프로젝트 중이었다. 발명소는 신뢰도 있는 프로젝트에서 '변수명', '메서드명', '클래스명' 등 개발자의 작명이 얼마나 보편적으로 사용되는지를 검색할 수 있는 서비스이다. 개발자는 본인의 작명이 얼마나 빈번하게 사용되고, 어떤 상황에서 어떻게 사용되는지 확인할 수 있다. 시운영에서는 백만개를 넘는 코드 파일이 있었고, 테스트에서 가장 많았던 변수명(i) 또는 코드 내 단순 단어 검색은 그 검색 결과가 만개를 훌쩍 넘었다. 우리 팀은 페이지네이션을 적용했고, 그 페이지 수를 프론트 앱에서 결정할 수 있도록 했다. 서버에 보내는 요청 예시는 아래와 같다. i가 변수명으로 사용된 코드 부분을 검색하는데 한 페이지 안에 30개의 검색 결과를 갖는다고 할 때, 두 번째 페이지를 반환해줘. // ex)..

개념 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. 정적 요청에 ..

Cache 매번 느린 메인 메모리에서 instruction을 가져오는 것이 아닌 프로세서와 메인 메모리 사이에 위치하여 자주 사용하는 명령어를 더 빠르게 가져올 수 있도록 하는 기술이다. instruction을 fetch 할 때, 특히 같은 구간을 반복해서 fetch 할 때, memory안 어떤 주소의 데이터(명령어)가 바뀌지 않는다면 메모리에서 바로 명령어를 가져오는 것이 아닌 좀 더 작고 빠른 장치에서 해당 주소에 해당하는 데이터를 기억해 두었다가 꺼내쓸 수 있는 임시 공간을 만들어서 메모리 접근을 줄인다. 고속의 장치는 비싸다. 가격이 비싸거나, 용량이 적거나, 발열이 크다. 다른 조건(가격, 발열)을 동일하게 한다면 고속의 저장 장치는 더 작은 공간을 갖게 된다. 그 말은 즉 모든 메모리의 데이터..

Pipelining 기존의 파이프라인을 적용하지 않은 멀티사이클 방식은, 한 명령어를 처리하고 그 이후에나 다음 명령어를 처리시켜 ALU를 사용 시에는 메모리가 쉬고, 메모리를 사용 시에는 ALU가 쉬었다. 즉 명령어의 단계 외의 다른 컴포넌트가 IDLE 상태로 처리를 대기하는 식이었다. 파이프라이닝은 여러 명령어를 중첩하여 명령어 처리 단계를 병렬 실행시키는 기술이다. 한 사이클 안에서 여러 명령어를 동시에 처리하여 쉬는 컴포넌트 없이 작업하여 더 효율적인 처리를 가능토록 한다. 위 그림에서의 예시라면 위의 파이프라인을 적용하지 않은 프로세서는 3개의 LW 명령어를 처리하는데 2400ps의 시간을, 아래 파이프파인을 적용한 프로세서는 약 1400의 시간을 사용한다. 이때 3개의 명령어가 아닌, 명령어를..