전체적인 흐름 : Route 53 ➡️ Datadog ➡️ API Gateway ➡️ Lambda ➡️ Jenkins ➡️ Terraform 1. Route 53 Health Check 실패특정 서비스가 비정상(HTTP 5xx, 타임아웃 등)일 때 특정 엔드포인트(CloudFront, ALB)가 unhealthy 상태로 감지됨 2. Datadog이 상태 감지이 상태는 Datadog으로 자체 모니터링 되는 중 3-1. Slack으로 알림 발송장애 발생 상황에 대한 알림 발송 3-2. Datadog Webhook 트리거 호출Datadog에서 설정된 Webhook 통합을 통해 API Gateway 엔드포인트에 HTTP POST 요청 전송전달되는 Body 예시*Datadog → Lambda 직접 호출도 ..

가중치 기반 라우팅가중치 기반 라우팅을 사용하면 다수의 리소스를 단일 도메인 이름(example.com) 또는 하위 도메인 이름(api.example.com)과 연결하고 각 리소스로 라우팅되는 트래픽 비율을 선택할 수 있습니다. 이러한 방식은 로드 밸런싱, 새 버전의 소프트웨어 테스트 등을 비롯한 다양한 목적에 활용될 수 있습니다.가중치 기반 라우팅을 구성하려면 각 리소스에 대해 동일한 이름의 레코드를 생성합니다. 각 리소스에 보낼 트래픽 양에 해당하는 상대적 가중치를 각 레코드에 할당합니다. Amazon Route 53는 그룹 내 전체 레코드의 총 가중치에 대한 비율에 따라 레코드에 할당된 가중치를 기반으로 트래픽을 리소스에 전송합니다.- AWS 개발자 가이드 | https://docs.aws.amaz..

웹 서비스가 운영 환경에 배포된 이후에는 안정성, 확장성, 보안성이 중요하다. 특히 사용자 수가 증가하고 트래픽이 커질수록, 이에 유연하게 대응할 수 있는 아키텍처와 운영 전략이 필수적일 것이다.최근에는 초기 인프라 구축 비용 부담 없이 필요한 만큼만 자원을 사용하는 온디맨드(On-Demand) 기반 클라우드 수요가 증가하고 있다. 이러한 흐름 속에서 클라우드 환경의 장점을 극대화하고 트래픽 변화에 능동적으로 대응할 수 있는 전략을 마련하는 것이 중요하다. 1. 유연한 확장을 위한 컨테이너 기반 아키텍처 도입트래픽 증가에 대비하기 위해서는 기존의 모놀리식 아키텍처보다 컨테이너 기반 아키텍처가 더 적합하다. 컨테이너는 애플리케이션을 빠르게 배포하고, 환경에 구애받지 않고 실행할 수 있는 장점이 있다. 이러..

프록시클라이언트쪽으로 데이터(Response)를 밀어주는게 포워드(Foward Proxy)라면, 그 반대편인 서버 쪽으로 데이터(Request)를 밀어주는 것이 리버스 프록시(Reverse Proxy) 라고 보면 된다.클라이언트(사용자)와 서버 사이에 위치해 클라이언트의 요청을 대신 전달해주는 중간 서버사용자 IP를 숨김 (익명성 제공) # 프록시 사용 예시 리버스 프록시서버 측에 위치한 프록시, 클라이언트는 이를 일반적인 서버로 인식보통 기업의 네트워크 환경에서는 DMZ라고 부르는 내부네트워크/외부네트워크 사이에 위치하는 구간이 존재한다. (내부네트워크/외부네트워크에 둘다 접근할 수 있는 공간)이 구간에는 보통 메일 서버, 웹 서버, FTP 서버 등 외부 서비스를 제공하는 서버가 위치하게 된다. WAS..

비대칭키 (Asymmetric Key)공개키(Public Key) + 개인키(Private Key)로 구성. 흔히 키페어라고 말함공개키로 암호화하여 개인키로 복호화 대표 예: SSH, HTTPS(TLS), PGPSSH 접속 시 클라이언트는 개인키를 사용, 서버는 등록된 공개키로 인증 공개키 (Public Key)서버(ex: Bastion, 접근하려는 서버)에 등록하여, 이 공개키에 대응하는 개인키를 가진 사용자만 접속할 수 있게 한다.key.pub개인키 (Private Key)비대칭키 쌍 중 비공개로 보관해야 하는 키이다. 개인키를 유출하면 보안 문제 발생key.pemAWS에서 EC2를 만드는 경우 자동으로 서버에 등록되어 있다. 사용자는 자신의 개인키만 소지하고 관리하면 된다. 접속 시에 필수적 세션키..

용어 정리소프트웨어 저작권자(Licensor): OSS를 제공하는 주체사용자(Licensee): OSS를 사용하는 주체License 양립성양립 불가능 시 배포 불가능 조건 1. 사용여부 명시2. 소스 코드 공개3. 특허 어떤 라이선스의 경우는 세가지 모두를, 어떤 라이선스는 일부만을 요구사용 여부 명시명시 요구: GPLv2, GPLv3, LGPL 2.1, MPL명시 요구 없음: BSD, MIT, EPL, CPL소스 코드 공개수정 또는 추가한 부분이 있을 경우, 해당 부분의 소스 코드를 공개해야 하는 라이선스가 있음소스 코드 공개 요구: GPL, LGPL, MPL, EPL소스 코드 공개 의무 없음: BSD, MIT, Apache License특허Patent Grant (특허 허가): 라이선스가 가진 특허권..

최근에 테스트 코드 작성하면서 좀 생소하기도 하고 애매한 부분들이 많다는 생각이 들었다. 제일 애매한 부분은 테스트 코드 작성의 범위라고 생각하는데 내가 얼마나 테스트 케이스를 잘 설정하고 있는 것인가에 대해서다.그런 관점에서 JaCoCo는 나의 고민에 도움을 줄 수 있는 부분이라고 생각이 들었다. JaCoCo란?JaCoCo(Java Code Coverage)는 Java 애플리케이션의 코드 커버리지를 측정하는 데 사용되는 오픈 소스 라이브러리코드 커버리지란?테스트 코드가 프로덕션 코드를 얼마나 커버하고 있냐를 측정해주는 지표테스트 케이스가 프로그램의 소스 코드를 얼마나 실행했는지를 백분율로 확인 가능 적용STEP 1. 프로젝트 설정gradle 기준으로 작성jacoco 버전 명시 가능 -> java 버전 ..

테스트 코드란?테스트 코드는 소프트웨어의 기능과 동작을 검증하기 위해 작성하는 코드 단위 테스트 Vs 통합테스트단위 테스트작은 범위: 특정 메서드, 클래스, 함수 등 단일 모듈만 테스트 통합 테스트넓은 범위: 데이터베이스, API, 외부 시스템 등 다양한 컴포넌트를 포함여러 컴포넌트가 함께 동작하는 것을 검증하는 테스트통합 테스트는 시스템의 전체적인 동작을 검증하기 때문에, 유닛 테스트보다 더 복잡하고 시간이 많이 소요 테스트 코드의 중요성테스트 코드는 애플리케이션의 기능이 올바르게 동작하는지 확인하고, 버그를 조기에 발견하며, 코드의 유지보수성을 높이는 데 기여 테스트 코드의 기본 원칙테스트 코드는 독립적 => 다른 테스트에 영향을 받지 않고 독립적으로 실행반복 가능 => 신뢰성 향상을 위해 항상 ..

CI/CDCI (Continuous Integration) : 지속적 통합코드가 수정이 될 때마다 지속적으로 편하게 통합이 되어 빌드, 테스트를 하는 과정 CD (Continuous Deploy/Delivery) : 지속적 배포 새로운 수정사항이 생길때 마다 수동 배포를 하는 방법도 물론 가능하다. 하지만 프로젝트의 규모가 커지고 이에 따른 수정사항이 잦아질수록 수동 재배포에는 한계가 존재한다. 대규모 프로젝트에서는 수동 배포가 비효율적이기 때문에 자동화된 CI/CD 방식을 선호한다.자동배포라 하면 방식이 정말 다양하다. 도커, Jenkins 부터 정말 많지만 여러 방식 중에서 이번에는 Github Actions를 이용하여 CICD 구성을 해보았다. CI/CD 파이프라인 구축어떤 서버를 선택했는지, 어떤..

Git에 연결되어 있지 않은 경우 / 초기 커밋git config --global user.name "사용자이름" // 로그인 필요 시git config --global user.email "깃허브이메일" // 로그인 필요 시 git initgit add .git commit -m " "git remote add origin git push origin Git 연결 확인git remote -v // reomote된 레포지토리 확인 가능git status // 상태 확인 레포지토리 내용 가져오기원하는 디렉토리로 이동git clone // git에 올라간 모든 내용 가져오기git clone -b // 특정 브랜치만 가져오기 (but, 수정 불가능하니 비추) 상위 브랜..