Information Security Study

오토스케일링과 로드밸런서로 요금최적화하기 Auto Scaling인스턴스를 자동으로 확장하고 축소하는 기능이다.사용자가 정의한 조정 정책에 따라 인스턴스 수가 증가 되거나 축소된다.ex) 서버의 로드가 증가하면 인스턴스 개수가 추가되고 감소하면 인스턴스도 줄어든다.k8s의 Deployment나 ReplicaSet과 같이 동작한다.    오토 스케일링 구성 요소1) 오토 스케일링 그룹- ec2 인스턴스의 그룹 2) 시작 템플릿(런치 템플릿)- ec2 서버를 시작하기 위한 AMI- 인스턴스 유형 정보를 가진 템플릿 3) 조정 옵션(조정 정책)- 오토 스케일링을 실행하기 위한 조건  EC2 Auto Scaling - 조정 정책 1) 항상 현재 인스턴스 수준 유지 관리지정된 수의 실행 인스턴스를 항상 유지하도록 ..

프로메테우스 페더레이트 설정하기Prometheus Federate: 여러 Prometheus 서버에서 데이터를 수집하여 중앙에서 통합된 메트릭을 조회할 수 있도록 해주는 기능  프로메테우스 페더레이트를 사용하는 이유1) 중앙집중화된 메트릭 조회- 페더레이트 기능으로 개별적으로 데이터를 수집하고 보관하는 각 프로메테우스를 중앙 서버에 통합해서 조회할 수 있다.- 여러 지역이나 데이터 센터에 분산된 프로메테우스 인스턴스를 한 곳에서 관리하고 모니터링 할 수 있다. 2) 리소스 절약- 프로메테우스 인스턴스 간의 데이터 복제 없이 각 인스턴스의 데이터를 페더레이트 서버에서 직접 가져오기 때문에 중복 저장을 방지하고 리소스를 절약할 수 있다. 3) 간편한 데이터 집계- 페더레이트 서버를 통해 여러 인스턴스에서 수..

nginx 설정파일 내의 아이피가 중복되는 문제와 무중단 배포가 안 되는 문제 해결하기  https://gayeon-l.tistory.com/463 블루/그린 방식으로 무중단 배포하기블루/그린 방식으로 무중단 배포하기 기본 로직은 이전 프로젝트에서 사용했던 블루/그린 방식의 무중단 스크립트를 참고했다. https://gayeon-l.tistory.com/431새vpc), 롤백, 무중단 배포(롤링, 블루/gayeon-l.tistory.com 현재 진행상황은 위 게시글 내용과 같다.   Switch Traffic 단계에서 action이 add일 때 그린 서버의 ip가 추가되고   곧바로 블루 서버의 ip가 제거되지만 upstream 내에서 ip가 중복되는 문제와 배포 및 CD테스트 완료 후에 로드밸런서에 업..

블루/그린 방식으로 무중단 배포하기 기본 로직은 이전 프로젝트에서 사용했던 블루/그린 방식의 무중단 스크립트를 참고했다. https://gayeon-l.tistory.com/431새vpc), 롤백, 무중단 배포(롤링, 블루/그린) 이어서" data-og-description="오늘 해야 할 것db용 private 서브넷 하나 더 만들고 -> 했음로드밸런서 없애고 -> 롤백 성공하고 할 예정두 가용영역을 부하 분산하는 nginx 생성하기(public, nginx 끼리 연결) -> 롤백 성공하고 할 예정" data-og-host="gayeon-l.tistory.com" data-og-source-url="https://gayeon-l.tistory.com/431" data-og-url="https://gay..

Infile Load 방식으로 병합된 로그 MySQL에 저장하기 https://gayeon-l.tistory.com/460 인스턴스 설정과 DB 저장을 위한 사전 설정들은 위 글에 작성했다.  현재 파일 구조~/log_aggr: 날짜별 로그 병합 파일이 있는 디렉토리~/log_db: log_aggr의 로그 파일들을 데이터베이스 스키마에 맞게 정렬한 로그 디렉토리  Infile Load 방식MySQL에서 대량의 데이터를 효율적으로 테이블에 삽입할 때 사용되는 명령어이다.외부 파일에서 데이터를 읽어와서 MySQL 테이블에 직접 삽입할 수 있다.데이터 로딩 작업을 빠르고 효율적으로 처리할 수 있어 많은 양의 데이터를 처리할 때 유용하다. /home/ubuntu/log/log-db-store.shInfile L..

반복문으로 파일 내에 있는 모든 로그를 DB에 저장하기(시도중)log_aggr 디렉토리에 날짜별로 집계된 로그 파일을 db에 저장해볼 것이다.   우선 db 인스턴스를 생성했다.   3306 포트도 열어두었다.   인스턴스에 접속해서 root 계정의 비밀번호 설정을 해주었다.   사용할 유저를 생성하고 실습을 위해 우선 모든 권한을 부여했다.권한 부여 후 적용을 위해 Flush privileges를 입력해야 한다. select host, user form mysql.user where user = '유저명';으로 유저의 권한을 확인할 수 있다.%로 뜨는 것으로 보아 권한이 잘 부여되었다.   db 인스턴스에 root가 아닌 사용자로 접속한다.   데이터베이스를 생성하고 use해주었다.   위와 같은 구조..

젠킨스 파이프라인으로 배포 시 로그 파일이 다른 위치에 생기는 문제 해결  젠킨스 파이프라인을 통해 배포 시 로그가 ~ 하위에 생기는 문제가 생겼다.원래는 ~/log-tracking-app/build/custom-libs/logs에 생성되어야 한다.logs 디렉토리를 생성한 적이 없는데 이 디렉토리가 생기면서 로그 파일이 쌓였다.  젠킨스 배포 말고 터미널에서 직접 git clone해서 생긴 jar를 실행하면 위와 같이 로그가 잘 생성된다.   멋대로 생성된 logs 디렉토리를 지우고 젠킨스로 다시 빌드하고나니 logs 디렉토리가 생긴 것을 확인했다.이것으로 젠킨스 스크립트에 적은 배포 경로에 로그가 저장하는 것을 알 수 있었다.(쌓인 jar는 모두 삭제했다.)   그래서 정확한 경로에 로깅될 수 있도록..

롤링 방식으로 무중단 배포하기https://gayeon-l.tistory.com/429 롤링방식 무중단배포 구현하기롤링방식 무중단배포 구현하기 깃허브에 commit, push 등 변경 사항이 생겨 webhooks이 감지하면 젠킨스가 다시 빌드를 시작하게 되어프로세스를 종료했다가 시작하는 준비 시간이 필요한데 이때 gayeon-l.tistory.com 2차 프로젝트 때 썼던 롤링 배포 스크립트를 참고했다. pipeline { tools { gradle "GRADLE" } agent any stages { stage('Clone') { steps { git branch: 'main', url: 'git 레포지토리 주..