nur mir!

EBS 볼륨 유형을 gp2에서 gp3로 변경하면 최대 20%의 비용을 절감할 수 있다 gp3 볼륨은 gp2 볼륨에 비해 GB당 최대 20% 저렴한 비용으로 IOPS 및 처리량을 독립적으로 프로비저닝할 수 있기 때문에 비용 및 성능면에서 효율적이기도 한데, EBS 볼륨 유형은 인스턴스가 켜져있는 상태에서도 변경 가능하여 서비스에 영향이 없다 (다만, EBS 볼륨 크기에 따라서 변경이 완료될 때까지 성능 지연은 발생할 수 있다) EBS 볼륨 유형 변경하려면 인스턴스 중지 없이 콘솔에서 EBS 볼륨을 gp3로 수정하기만 하면 되기 때문에 변경하지 않을 이유가 없다.

SRE 업무의 꽃 모니터링 중 발생한 연결성 오류 검사 에러 건에 대해트러블슈팅 및 가능한 조치 방법에 대해 소개하고자 한다. 상황연결성 오류 검사 에러가 발생 트러블슈팅free명령어로 확인 → available 쪽에 많이 할당되어서 메모리 낮다고 보기 어려웠음top 봐도 당장 메모리 많이 잡고 있는 ps 없음/var/log/message 로그에서 에러 뜬 시간대에 어떤 동작했는지 보기동작 내용 대강 확인했으면 검색해서 오류 발생한 시기와 인스턴스 에러 시기 비슷한지 확인 - 이번 경우 OOM 오류로 확인해서 OOM 발생시기 = 연결 오류 검사 시기 확인함가능 조치 방법 볼륨 최대 처리량 변경현재 볼륨 최대 처리량은 125MiB/s알림이 발생한 시간대에 처리량(CW상 읽기 처리량)이 최대치인 125MiB..

1. amazon-efs-utils 패키지 설치*sudo yum install -y amazon-efs-utils* 2. 마운트 할 디렉토리 생성*sudo mkdir 디렉토리 명* 3. 파일 시스템 마운트 실행*sudo mount -t efs -o tls fs-xxx:/ efs* 4. EFS 보안그룹 인바운드 규칙에 연결할 인스턴스의 서브넷 CIDR 추가포트 : 2049 참고문서#EFS 마운트 도우미를 사용하여 Amazon EC2 Linux 인스턴스에 마운트하기 -https://docs.aws.amazon.com/ko_kr/efs/latest/ug/mounting-fs-mount-helper-ec2-linux.html

해결 전 : 해결 후 : 이슈 내용NLB 443 리스너규칙을 만들고 ALB를 타겟그룹으로 지정하면 상태검사가 Unhealthy로 떴음 해결 방법참고 사이트 : https://bigco-growth-diary.tistory.com/32443 리스너 규칙에 매핑할 타겟그룹 프로토콜을 TCP:443으로 변경상태검사 설정시 프로토콜을 HTTPS로 변경→ 상태검사 healthy로 바뀜

.참고 문서 : https://docs.aws.amazon.com/ko_kr/acm/latest/userguide/dns-validation.html 위 사진과 같이 DNS 검증시 검증 대기 중이 계속된다면 Route 53에서 레코드 생성 버튼을 누른다.추가 설명을 하자면 DNS 검증을 선택하려면 ACM이 CNAME 레코드를 제공해야 한다. 제공여부는 Route53에서도 확인 가능한데, 만약 위와 같은 문제가 발생한다면 레코드 생성을 통해 CNAME 레코드를 입력하면 된다.

.Whatap Focus를 이용한 방법으로 모든 파드에 대해 모니터링 설정하면 리소스가 너무 많이 소모되어아래와 같은 방법이 있어 적어본다. 네임스페이스를 특정해서 kubectl get pod 명령어를 보낸 후 모든 pod가 Running이면 정상, 그렇지 않으면 비정상으로 판단하는 것이다. 그리고 output으로 뿌려주는 0인지 1인지만 확인하면 된다. 예)네임스페이스 : example-ns $ k get po -example-ns|grep -v "Running\|NAME"|wc -l0 $ k get po -example-ns|grep -v "Running\|NAME"|wc -l1