끄적이는 보송

문제 발생 External ALB가 외부 Client의 요청을 Private Subnet에 위치한 Web/WAS 서버에 전달하는, 아주 단순한 구조의 웹서비스 운영에 문제가 있었던 적이 있었다. Client가 웹에 요청을 보내면 20초 넘도로 오래 걸린다는 점이었다. 정말 단순한 이유였지만 기록 차원에서 남겨본다. 문제 분석 Client가 웹에 접속하는데 너무 느리다. 여기에는 정말 다양한 이유가 있을 수 있다. 내가 했던 것들을 나열해 보았다. 1. Client 마다 증상이 달랐다. 누구는 빠르게 접속이 되고, 누구는 그렇지 않았다. Client를 탄다는 이야기인데 아주 이상한 부분이었다. 2. Web/WAS 인스턴스의 타입은 t타입이었다. 보통 운영환경에 t타입은 사용하지 않는다. t타입의 공지된 스..

얼마 전 Amazon ElastiCache의 서비스 업데이트 알람이 뜬 적이 있었다. Amazon ElastiCache는 새로운 업데이트(최신 보안 패치, 버그 fix, 기능 향상 등...)가 출시되면 자동으로 업데이트 알리는데 나의 경우, 보안 업데이트와 엔진 업데이트였다. Amazon ElastiCache 업데이트 시(혹은 수정) 걸리는 시간과 내부 동작 순서는? 전체 변경에 걸리는 시간은 각각 상이하겠지만 일반적으로 20분 내외로 진행되며, 리소스가 보유 중인 데이터의 양, 쿼리 사용량, 등에 따라서 전체 걸리는 시간은 더 길어질 수 있다. 실제 연결 끊김과 실패가 발생하는 시간은 1~2회의 수초 간의 시간이 발생할 수 있다. 하지만 Endpoint IP DNS 캐싱이 긴 경우 더 길어질 수 있다...

Amazon OpenSearch를 생성하는데 아래와 같은 오류 메시지를 반환했다. max_clause_count 값이 잘못되었다는 건데... indices.query.bool.max_clause_count is not a valid query count value. Please enter a integer value between 1 and 2147483647 (inclusive). 결론부터 말하자면 콘솔환경 기준으로 '고급 클러스터 설정 - 선택사항'을 클릭해 '최대 절 수' 값을 입력하면 된다.

AWS 콘솔 환경에서 정보 누락 발생 얼마 전 ELB 콘솔 환경에서 ELB의 Tag 값이 누락되는 일이 있었다. ELB에 분명 특정 Tag 값이 기입되어 있는데(ex. env=dev, service=example), Tag 값 기반으로 특정 ELB를 검색할 수도 없어 불편함이 있었다. 별다른 생각 없이 콘솔 버그로 생각하고 Global Support에 문의했는데, 이슈 해결은 아니더라도 조금 재밌는 내용이 있어 기록차원에서 남겨본다. 원인 AWS Global Support에 문의해 보니 AWS 콘솔에서 ELB 리소스들에 대한 TAG 가 일부 누락되는 원인은 API throttling이라고 한다. 요약하자면 AWS는 리전별로 계정에 대한 API Call을 조정하는데, 허용되는 호출값 이상을 API Call..

발단 같이 일하는 동료로부터 Amazon Aurora 분석 중, CloudWatch Metric 값에 이상한 점을 있다는 이야기를 들었다. 바로 Aurora의 몇몇 지표(volume iops 관련)는 CloudWatch 지표에 바로 반영되지 않고 느리게 쌓인다는 것이다. 적게는 10분 많게는 2~30분 정도, 혹은 그 이상으로 데이터가 현재 시간을 기준으로 지표가 느리게 출력되어 마치 바로 반영이 안 되는 모습을 보였다. 흥미가 생겨 분석한 내용을 포스팅해 본다. 혹시 Aurora의 다른 지표는 어떨까? 단순한 예로, CPUUtilization을 봤지만 디폴트 설정대로 정상적으로 5분 주기로 데이터가 찍히는 것을 볼 수 있었다. 확실히 volume IOPS 관련 지표는 다르다는 것이 보인다. 하지만 도큐..

빌링 관련 CloudWatch Metric 확인할 일이 있었다. 내가 확인한 지표는 'EstimatedCharges'라는 계정에 과금되는 비용을 볼 수 있는 지표였으며, 주기는 6시간을 선택했다. 하지만 아래 지표 예시에도 볼 수 있듯이 그래프가 끊겨 누락된 데이터가 있는 것처럼 보였다. 과금은 꾸준히 발생하고 있다. 갑자기 서비스를 중단했다고 해도 말이 안 되는 게 정말 누락되었다면 그래프가 끊긴 시점과 시작되는 시점의 지표값이 동일해야 하지만 지표값은 꾸준히 상승하는 모습을 보였다. 왜 이런 일이 발생한 걸까? 원인은 내가 'EstimatedCharges' 지표의 주기 값을 6시간을 지정했던 것과 (AWS에선 6시간을 권장하는 듯 보이다. 확실하진 않음), 실제 CloudWatch에 쌓이는 'Esti..

개요 AWS 계정 탈취나 침입자에 의해 비정상적인 서비스 이용으로 빌링이 말도 안 되게 나오는 경우를 종종 듣는다. 이것을 예방하기 위해 여러 수단이 있다. 오늘은 하루 단위로 특정 비용 이상으로 비정상적인 과금이 탐지됐을 때 CloudWatch와 SNS 서비스를 통해 이메일로 알람을 보내도록 설정하는 포스팅을 다루려 한다. 요구사항 - 하루에 100 USD 이상 과금되는지 탐지하고 싶음. - 100 USD 이상 과금이 발생하면 이메일로 알람 전송받고 싶음. - 가능한 빠르게 알람을 받고 싶음. 사전작업 먼저 빌링 대시보드에 접근해 'Billing preference' > 'Receive Billing Alerts'를 클릭해 활성화해줘야 한다. 이것이 활성화돼야 알람 설정에 이용할 CloudWatch의 ..

AWS Compute Optimizer란 클라우드 아키텍처 최적화 작업을 하면서 AWS Compute Optimizer라는 서비스를 알게 되었다. AWS 리소스의 구성 및 사용 지표를 분석하는 서비스라고 한다. 간단히 말하면 EC2 Instance의 경우, 과거 리소스 사용률을 참고해 알맞은 스펙을 권장하는 서비스라고 봐도 된다. 매번 EC2 Instnace의 세부 정보에 보이는 거였는데 이런 서비스인 줄은 몰랐다. 이참에 간단히 정리해 본다. 요구 사항 Compute Optimizer 서비스는 과거 CloudWatch 리소스 사용률 이력을 보고 스펙을 권장하는 서비스이다. 그러다 보니 최소한의 데이터는 수집되어야 한다. 도큐먼트에 따르면 최소 30시간(끊김 없이)의 CloudWatch 메트릭 데이터가 ..