일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 도메인
- VPC
- CLI
- AD
- RDS
- Dedup
- CloudFront
- Jenkins
- FSX
- Python
- ncp
- AWS
- terraform
- storage gateway
- dns
- lambda
- Storage
- EC2
- NaCl
- security group
- Athena
- route table
- Windows
- S3
- 테라폼
- Subnet
- ALB
- 윈도우
- 네이버 클라우드 플랫폼
- Linux
- Today
- Total
목록STUDY (98)
끄적이는 보송
문제 발생 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 캐싱이 긴 경우 더 길어질 수 있다...
nGrinder에서 부하테스트를 위한 스크립트 실행 전, viliation check라는 걸 수행해서 정상적으로 동작하는지 확인할 수 있는데 아래와 같이 실패하는 현상이 있었다. 나만 겪은 문제는 아닌 거로 보인다. 나는 이때 당시 가장 최신 버전인 3.5.8을 사용했는데 3.5.6 이하로 버전을 낮추면 문제가 해결되는 듯 보이다. 버그인 듯. [+] https://github.com/naver/ngrinder/discussions/942
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). 결론부터 말하자면 콘솔환경 기준으로 '고급 클러스터 설정 - 선택사항'을 클릭해 '최대 절 수' 값을 입력하면 된다.
서버 시간이 틀어졌을 때를 가정하고 Chrony를 사용해서 리눅스 서버 시간 동기화를 해 볼 생각이다. Chrony란? 주로 Chrony와 NTP 둘 다 사용하며, 둘 다 시간 동기화에 사용되는 프로토콜이지만 Chrony가 일반적으로 더 나은 선택지로 취급된다. 이유는 NTP보다 더 정교하고, 리소스 사용량도 적고, 효율적이며 기타 등등 여하튼 최신 Linux 시스템에서 시간 동기화에 권장되는 옵션이라고 한다. NTP는 무쓸모일까? 그렇다면 NTP는 Chrony보다 떨어지니 전혀 쓸 일이 없을까? 아마 일부 구형 시스템의 경우, Chrony와 호환되지 않을 수 있어 NTP를 사용해야 하는 경우가 있을 수도 있다. 혹은 이전부터 쭈욱 사용해 왔던 시간 동기화 프로토콜이 NTP이거나, 다른 동기화 프로토콜에..
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..
nGrinder Controller를 실행할 일이 있어 "java -jar ngrinder-controller-3.5.3.war --port=8080" 명령어를 날렸는데, "-p=8080 port is already occupied by the other system or failed to bind. Please use the other port"라고 에러를 반환했다. [root@ip-172-31-33-181 ~]# java -jar ngrinder-controller-3.5.3.war --port=8080 08:12:13,377 |-INFO in ch.qos.logback.classic.LoggerContext[default] - ... 08:12:13,378 |-INFO in ch.qos.logbac..
환경은 EC2의 Amazon Linux2이며, 기본적으로 설정되어 있는 UTC timezone을 KST로 변경하려고 한다. System 수정을 이용한 방법 # 파일 시스템 timezone이 설정되어 있는 /etc/sysconfig/clock 파일을 수정 [root@localhost ~] vi /etc/sysconfig/clock # 아래와 같이 수정 ZONE="UTC" UTC=true # /etc/localtime 파일을 조회해 아직까진 UTC 기준인 것을 확인할 수 있음 [root@localhost ~]# cat /etc/localtime TZif2UTCTZif2�UTC UTC0 # 기존 시간 설정(UTC) /etc/localtime 백업 및 제거 [root@localhost ~] cp..