오늘도 지식 한점!

AWS WAF AWS Workload 에서 Layer 7 의 웹 어플리케이션을 보호하고 HTTP/HTTPS 트래픽을 모니터링하고 차단하는 역할을 수행 AWS WAF 는 외부에서 수신되는 트래픽 기준으로 Inspection 수행 AWS WAF 구현 순서 권고안 적용할 WAF 의 대응 룰셋 이해와 대처 방안 WAF 요구사항 WAF 구현 WAF 룰 배포 비용 검토 평판 정보를 이용한 차단 적용 Spamhaus 평판정보 IP 차단 - https://www.spamhaus.org/drop/ DROP / EDROP 목록 추가 Tor Node 평판정보 IP 차단 - https://check.torproject.org/exit-addresses 추가 Proofpoint 평판정보 IP 차단 - https://rules...

Service Mesh(여기서는 istio)를 사용하는 이유를 들어보자면, MSA(Micro Service Arch.)구조에서는 너무나 많은 마이크로 서비스들이 생성될 수 있습니다. 그것은 서비스 단위를 설계하여 쪼개는 설계자에 달려있으나 이론적으로 아주 작게 분리하면 감당하기 힘들 정도의 서비스들로 나눌수도 있습니다. 이런 경우 외부에서 들어오는 트래픽이나, 컨테이너들끼리의 통신의 가시성을 확보하고 제어를 상대적으로 쉽게하는 기술이 필요하게 되었고 이를 위해 등장한 것이 서비스 메쉬(mesh)입니다. 여기서는 istio를 활용하여 서비스 디스커버리, 네트워크 모니터링, 컨트롤 등이 가능하게 시도하는 것입니다. 이를 가능하게 하는 것이 바로 sidecar 입니다. 각 컨테이너마다 통신을 담당하는 prox..

AWS는 CloudWatch를 기본으로 Monitoring, Logging, Alarm 및 Dashboard와 X-Ray를 통해 Tracing를 제공합니다. Observability(관측가능성)의 3가지 구성요소인(Telemetry, Log, Trace)를 제공합니다. X-Ray는 Tracing의 근본적인 부분이므로 CloudWatch와 함께 동작합니다. 오픈소스 observability interoperability (상호운영성)을 위해 Managed Prometheus 및 Grafana 서비스를 제공하며 OpenTelemetry까지 지원합니다. 구성 아키텍쳐(Overall) 모든 요소는 중복구성이 될 수 있기 때문에 의사결정이 필요하고, cloudwatch로 기본 수집되는 영역은 추가로 있습니다. I..

EKS는 기본적으로 오픈 소스 Kubernetes(이하, k8s)를 수정하지 않습니다. EKS는 업스트림 및 인증된 k8s 버전을 포함해서 오픈 소스와의 일관성을 유지하기 위해 보안 수정 사항을 backporting를 진행합니다. k8s 운영의 복잡도를 줄이기 위한 EKS는 k8s API의 모든 GA 기능을 지원하고, 기본적으로 활성화되어 있는 알파 기능을 제외한 모든 베타 기능도 지원합니다. 또한, 업스트림 버전을 장기간 지원하는데 EKS는 최대 4가지 버전의 k8s를 지원하기 때문에 운영단에서 롤아웃 업그레이드를 수행할 수 있는 충분한 시간을 제공합니다. 그 일환으로 AWS는 현재 커뮤니티에서 지원하지 않을 수도 있는 k8s에 대한 패치, 수정 및 업그레이드를 backporting하고 있습니다. 업스..

셋탑 위치(지역) 기반 테스트용 vs 일반 사용자 요금별(유료 고객 vs 무료 고객) Feature Flag Ramdom(Weighted) Flow Diagram 구성의 예> API Path에 따라 stable(blue) 또는 preview(green)으로 라우팅되도록 구성하였습니다. 롤 아웃 진행중에 preview(green) 환경으로 트래픽을 보내기 위해서는 특정 트래픽의 요청 path를 변경해야 합니다.(API GW에서 구성) 모든 POD를 새버젼(Green Pod)로 보내기 전에 weight에 따라 stable/preview 환경으로 트래픽 전달 특정 시간동안 일부 트래픽을 랜덤으로 Green 환경으로 배포 후 요청 사항을 수집하여 자동/수동으로 Promotion 진행 인증 POD에서 인증정보(s..

Intro helm은 kubernetes cluster에 어플리케이션을 배포하는 도구입니다. 쿠버네티스를 운영할때 단일 클러스터만으로 운영하는 경우는 흔치 않습니다.결국 애플리케이션을 여러 클러스터에 배포해야하는데, 이 과정에서 발생하는 관리 이슈가 생길 수 있습니다. 서비스의 경우는 그렇다 쳐도, 인그레스와 같이 호스트가 지정된 정보들의 경우 클러스터마다 상이하게 설정해야하는데 클러스터마다 매니패스트를 따로관리하는것도 문제입니다. 따라서 환경에 따라 달라지는 값만 정의해두고 이에 따라 배포하는 메커니즘이 필요하며 이를 해결하는것이 바로 “헬름” 입니다. Helm 이란? helm은 deis라는 회사에서 시작한 Helm Classic 프로젝트와 Google에서 진행되던 GCS Deployment Manag..

Branch 끝장내기 1에서 기본적인 Branch 명령어를 정리하였습니다. 이번엔 원격 브랜치에 대해서 간단히 정리하도록 하겠습니다. 깃은 다수의 개발자와 협업으로 코드를 유지할 수 있습니다. 주요 개발 작업들은 로컬 저장소에서 하지만 협업은 원격 저장소도 공유 합니다. 로컬 저장소도 하나의 저장소이고, 원격 저장소도 하나의 저장소 입니다. 깃은 분산형 버전 관리로서 다수의 저장소를 만들어 연결할 수 있기 때문입니다. 이번에는 브랜치를 이용하여 협업하는 것을 정리합니다. 원격 브랜치를 제공하는 git hosting 업체중 대표적인 회사가 github입니다. 추후에 github enterprise에 대해서 정리하도록 하겠습니다. 1. 리모트 브랜치 저장소는 각자의 고유한 브랜치를 생성하고 관리합니다. 원격..

소스 코드 이력을 관리하는 Version 외에 git과 같은 VCS 도구를 사용하는 또 다른 이유는 브랜치 작업 때문입니다. 각설하고 꼭 필요한 기능 위주로 정리하였습니다. 1. 브랜치 생성 깃의 브랜치를 생성하는 동작과 이동하는 동작은 별개입니다. 브랜치 생성은 branch 명령어를 사용하고, 브랜치 이동은 checkout 명령어를 사용합니다. $ git branch 'feature' 이라는 이름으로 브랜치를 만들어 봅시다. $ git branch feature 2. 브랜치 이동(전환) 아래와 같이 입력하여 'feature' 브랜치를 체크아웃 해 봅시다. $ git checkout feature Switched to branch 'feature' 생성과 함께 생성된 BRANCH로 이동 $ git che..

마이크로 서비스 아키텍처에서 문제중 일반적인 것은 cascading failure을 꼽을 수 있습니다. 어떤 이유로 서비스가 응답하지 않는 경우, 서비스에 request를 계속해서 보내면 latency가 길어지고 그에 따른 서비스에 불필요한 부하가 발생할 여지가 있습니다. 마이크로 서비스의 경우 다양한 서비스로 구성되는데, A 서비스와 B 서비스가 연계되어 있을 경우 다른 서비스의 부하로 이어지는데 이런 현상을 cascading failure라 한다. 이런 현상을 circuit breaking을 통해 과부하된 서비스의 연결을 끊고 서비스가 회복할 시간을 줄 수 있게하여 장애를 처리할 수 있게 됩니다. Destination rule에서 또는 value에서 이용하여 circuit break 설정이 가능합니다..

AWS내에서 CORS (Cross-origin resource sharing)를 설정하는 방법을 설명합니다. 먼저 CORS 이해를 위해 아래 참조 바랍니다. 교차 출처 리소스 공유(Cross-origin resource sharing, CORS), 교차 출처 자원 공유는 웹페이지 상의 제한된 리소스를 최초 자원이 서비스된 도메인 밖의 다른 도메인으로부터 요청할 수 있게 허용하는 구조이다. 다만 특정 교차 도메인 간(cross-domain) 요청, 특히 Ajax 요청은 동일-출처 보안 정책에 의해 기본적으로 금지된다. CORS는 교차 출처 요청을 허용하는 것이 안전한지 아닌지를 판별하기 위해 브라우저와 서버가 상호 통신하는 하나의 방법을 정의한다. 순수하게 동일한 출처 요청보다 더 많은 자유와 기능을 허용..