Racon

Blue Green 배포 Blue/Green 배포를 해야 할 일이 생겨서 한번 정리 해 보았습니다.Docker를 사용하여 개발을 진행했지만, 실제 배포는 하나의 인스턴스를 추가하고 도메인 포트를 전환하는 방식입니다.개념적인 내용은 하단 링크를 참고하시고, 필요시 GitHub 프로젝트를 확인하세요.프로젝트 구성blue-green│ # 실제 배포 Shell 파일├─ deploy.sh │ # 이미지 생성 Dockerfile├─ Dockerfile │ # docker-compose├─ docker-compose.blue.yml ├─ docker-compose.green.yml│ # nginx.conf 파일├─ nginx-blue.conf├─ nginx-green.conf│ # Gradle 파일..

Dockerfile도커 이미지 생성 파일FROM openjdk:11-jre-slimWORKDIR /appCOPY ./application.jar /app/application.jarRUN mkdir -p ./logsCMD ["java", "-Duser.timezone=Asia/Seoul", "-Dspring.profiles.active=dev", "-jar", "application.jar"] docker-compose.yml도커 컴포즈 실행 파일services: application: container_name: application_container restart: unless-stopped image: application-image:latest ports: - "..

1. 헥사고날 아키텍처란?헥사고날 아키텍처(Hexagonal Architecture)는 시스템을 여러 모듈로 분리하여 유지보수성과 확장성을 높이기 위해 고안된 소프트웨어 설계 패턴입니다. 2005년 Alistair Cockburn이 제안했으며, 포트 & 어댑터 아키텍처(Ports and Adapters Architecture)라고도 불립니다.2. 주요 개념의존성 분리애플리케이션 코어(Core)를 외부 시스템(데이터베이스, 메시징, UI 등)과 완전히 분리합니다. 느슨한 결합핵심 비즈니스 로직은 외부 구현 세부사항에 의존하지 않고, 포트(Ports)와 어댑터(Adapters)를 통해서만 통신합니다. 유연한 확장·변경외부 시스템을 바꿀 때 코어를 수정할 필요가 없습니다.3. 주요 요소코어(Core) 비..

1. 롤링 배포 (Rolling Deployment)설명 점진적 업데이트: 전체 시스템을 한 번에 교체하지 않고, 일부 인스턴스씩 새 버전으로 바꿔가며 배포 방식: 기존 인스턴스를 하나씩 종료하고, 새 버전을 띄운 뒤 다음 인스턴스로 넘어감 장점 무중단 배포: 일부 인스턴스만 교체하므로 서비스 중단 없음 리소스 효율: 한꺼번에 모든 인스턴스를 업데이트하지 않아도 됨 단점 상태 불일치: 구버전·신버전이 공존하므로 호환성 주의 롤백 어려움: 혼재된 상태에서 문제 원인 파악 및 복구가 복잡 배포 흐름 시간 →ABCD1구 → 신구구구2신구 → 신구구3신신구 → 신구4신신신구 → 신2. 블루-그린 배포 (Blue-Green Deployment)설명 두 환경(Blue/Green)을 운영하여, 한..

Kill 명령어프로세스에 신호를 보내는 kill 명령어의 옵션 숫자는 특정 신호 번호를 나타냅니다. 주요 신호와 의미는 다음과 같습니다:신호 번호이름설명1SIGHUP설정 파일 변경 시 프로세스에 재시작을 요청합니다.2SIGINT인터럽트 신호(Ctrl+C)와 동일합니다. 프로세스를 정상 종료시킵니다.9SIGKILL무시할 수 없는 강제 종료 신호입니다. 즉시 프로세스를 종료할 때 사용합니다.15SIGTERM기본 종료 신호입니다. 프로세스에 정상 종료를 요청하며, 프로세스가 이를 처리할 수 있습니다.18SIGCONT일시 중지된 프로세스를 다시 실행(restart)합니다.19SIGSTOP무시할 수 없는 일시 중지(pause) 신호입니다.예시kill -9 1234: PID가 1234인 프로세스를 강제로 종료합니다..

https://raconer.tistory.com/entry/MySql-%EC%84%B1%EB%8A%A5-%EA%B0%9C%EC%84%A0%EC%97%90-%EA%B4%80%ED%95%98%EC%97%AC%ED%95%B4%EA%B2%B0-%ED%95%B4-%EB%B3%B4%EC%9E%901explain [MySql] 성능 개선에 관하여_해결 해 보자_1_explainExplainSql문 성능 개선에 빠질수 없는 것 들 중 하나인 Explain 쿼리를 한번 확인해 볼려고 한다.컬럼 과 설명id쿼리의 각 부분을 식별하는 고유 번호입니다.서브쿼리나 UNION이 있을 경우 여러 id가 있raconer.tistory.com경험에 따른 Query 튜닝1. Index 설정 확인질문.1예)Mysql 에서 Index 설..

ExplainSql문 성능 개선에 빠질수 없는 것 들 중 하나인 Explain 쿼리를 한번 확인해 볼려고 한다.컬럼 과 설명id- 쿼리의 각 부분을 식별하는 고유 번호입니다. - 서브쿼리나 UNION이 있을 경우 여러 id가 있을 수 있으며, 값이 클수록 실행 순서가 나중입니다.select_type쿼리의 유형을 나타냅니다. 주요 값은 다음과 같습니다: - SIMPLE 단순 SELECT 쿼리 (서브쿼리 없음) - PRIMARY 쿼리의 가장 바깥쪽 SELECT 쿼리 - UNION UNION 연산자에서 두 번째 이상의 SELECT 쿼리 - SUBQUERY 서브쿼리의 SELECT 쿼리 - DERIVED 서브쿼리의 결과를 임시 테..

[MySQL] 성능 개선에 관하여_고찰성능 개선그동안 데이터가 적은 회사를 다녔기 때문에 DB 쿼리 성능에 대해 크게 신경을 쓰지 않았던 것 같다.하지만 데이터가 많아짐에 따라 쿼리 성능 개선은 필수적이며, 서버 관리에 있어 가장 중요한 지식이 되는 것 같다.예전에는 서비스 부하를 줄이는 방법에 대해 고민했지만, 실제로는 DB 부하를 줄이는 것이 서비스 성능을 눈에 띄게 개선하는 데 더 효과적이라는 것을 알게 되었다.따라서 DB의 부하를 줄일수록 서비스 성능이 가장 빠르고 효과적으로 개선된다고 생각한다."데이터가 많을 때를 경험해 본 적 없으니...." 앞으로 앞의 글이 많이 보일 거다. 변명을 하는 게 아니다.내가 놓치고 있던 것에 대해 뇌에 각인시키는 것이다.그동안 "DB 부하는 Redis, Mess..

클러스터를 사용할 때의 성능클라이언트가 MOVED 에러에 대해 재요청을 해야하는 문제클라이언트(라이브러리)는 key-node 맵을 캐싱하므로 대부분의 경우 발생하지 않음클라이언트는 단일 인스턴스의 REdis를 이용할때 와 같은 성능으로 이용 가능분산 시스템에서 성능은 데이터 일관성(Consistency)과 trade-off가 있음Redis Cluster는 고성능의 확장성을 제공하면서 적절한 수준의 데이터 안정성과 가용성을 유지하는 것을 목표로 설계클러스터의 데이터 일관성Redis Cluster는 Strong consistency를 제공하지 않음높은 성능을 위해 비동기 복제를 하기 때문클러스터의 가용성 - auto failover일부 노드(master)가 실패(또는 네트워크 단절) 하더라도 과반수 이상의..

클러스터를 사용할 때의 성능클라이언트가 MOVED 에러에 대해 재요청을 해야 하는 문제 → 클라이언트(라이브러리)는 Key-Node 맵을 캐싱하므로 대부분의 경우 발생하지 않음클라이언트는 단일 인스턴스의 Redis를 이용할 때와 같은 성능으로 이용 가능분산 시스템에서 성능은 데이터 일관성(Consistency)과 trade-off가 있음 → Redis Cluster는 고성능의 확장성을 제공하면서 적절한 수준의 데이터 안정성과 가용성을 유지하는 것을 목표로 설계클러스터의 데이터 일관성Redis Cluster는 Strong Consistency를 제공하지 않음높은 성능을 위해 비동기 복제를 하기 때문Ack와 복제는 순서가 정해져 있지 않으므로, 복제가 완료되기 전에 master가 죽으면 데이터는 유실된다..