개발과 일상

개요새로운 서비스가 시작하면서 AWS관리부터 devOps, BE 개발을 전반적으로 다 관리하고 있다. 그러다보니 서버 설정을 만질때가 많은데, 그중에서 관리가 특히 필요한 것들이 외부 API 키나 DB 커넥션 관련 정보다. 1. 누출되면 데이터를 싹 털릴 수도 있고, 무분별한 사용으로 비용이 치솟을 수 있는 것들.2. 기간 만료/갱신 등으로 인해 수시로 변경되고, 서버 프로필 별로 따로 관리가 필요한 것들.  이런 것들을 한번에 관리할 수 있도록 서비스를 지원하는게 AWS Parameter Store다. 이번 포스팅에는 아래와 같이 사용법을 정리해보려고 한다. 1. Terraform으로 db관련 간단한 파라미터를 등록2. ECS Task의 IAM 정책에 ssm 작업 추가3. SpringBoot 3.0에서..

이번에 새로 진행하는 프로젝트의 인프라는 k8s가 아니라 ECS로 선택했다. BE를 병행하는 입장에서 k8s의 계속해서 바뀌는 업데이트와 복잡성을 따라가기 어렵다 판단해서였다. 그래서 차근차근 Terraform으로 ECS를 구축하던 중 IAM을 설정하다 의외의 문제를 발견했다. aws_iam_policy_attachment와 관련된 문제여서 짚고가보려고한다. 현상부터 특이하다. 1. terraform init (-upgrade)2. terraform plan를 할때 매번 새로운 upgrade 요소가 나옴3. terraform apply에서 아래와 같은 에러가 발생4. 다시 1로 돌아가서 upgade를 해주면 plan에서 새로운 리소스가 잡힘. 2~3의 반복 분명 정책을 만들고 attachment를 실행했..

문제 발생상용 배포 당일 정신없던 배포 준비를 마친 후, 상용서버 배포를 진행했다. 그리고 몇 번의 핫픽스를 내보낸 후 FE 개발자 분이 안보이는 부분에 문제가 있다고 연락이 왔다. FE에서 자기들이 쓰려고 FE의 서버로 보내는 API를 만들었는데 이 URL로 요청을 보내면 403 에러가 난다는 것.  403 Forbidden을 가장 많이 보는 경우는 CORS 문제다. 하지만 해당 요청이 들어온 CloudFront(이하 CF)의 옵션을 보면 CORS 문제가 아니다라는 걸 바로 알 수 있다. AWS에서도 403 에러 관련 문서를 제공하는데 나에겐 큰 도움이 되지 않았었다. 함정이 도사리고 있어서 매우 고통스러웠던, 문제 해결과정을 알아보자.. 문제 분석1. 정말 CORS 문제가 아닌가?이 도메인으로 접근하..

문제 상황 정리작년 9월쯤부터 비용절감을 위해 dev 서버를 spot 인스턴스로 변경했다. 약 30% 정도 비용절감이 효과가 있어서 당시에는 꽤 괜찮은 선택이었는데, 운영하면서 문제가 발생했다. dev 서버가 spot 인스턴스를 너무 자주 뺏기고, 다시 할당 받는데 시간이 오래 걸리는 현상이 반복됐다. 한두번이면 상관 없는데 하루에도 몇 번씩 뺏기고 다시뜨는데 10분씩 걸리니까, 개발에 차질이 생기는 경우가 생겼다. 이 문제를 해결하고 싶었다. 문제 정의spot instance란?스팟 인스턴스는 실행 중인 동안에는 온디맨드 인스턴스와 정확히 동일합니다. 그러나 스팟은 실행 중인 인스턴스를 워크로드를 완료할 수 있을 만큼 충분히 오래 유지할 수 있다고 보장하지 않습니다. 또한 스팟은 찾고 있는 인스턴스의 ..

AWS에서 제공하는 완전관리형 쿠버네티스 서비스인 EKS는 업데이트 주기가 엄청나게 빠르다. Amazon EKS Kubernetes 버전에 관한 문서를 읽어보면 다음과 같이 안내한다. 1. EKS 신규 버전 출시는 쿠버네티스 업스트림 릴리즈 주기(4개월)을 따름.2. 신규 버전 출시 후 14개월은 무료로 표준 지원3. 표준 지원 종료 후 12개월 추가 지원 (클러스터 당 0.6$/h의 추가 요금 발생)4. 추가버전 종료까지 업그레이드를 하지 않을경우 가장 마지막 버전으로 강제 업그레이드5. 평균적으로 업스트림 릴리즈 이후 약 2~6개월 이후 EKS 지원 만약 추가 지원으로 빠진다면, 클러스터 당 한달에 약 60만원(0.6 × 1380 × 24 × 30) 정도의 추가 비용이 발생한다. 그래서 그런지 콘솔에..

상용 DB를 막 만져봤던 뉴비 시절에 "우리 서비스의 데이터베이스는 HA 구조야" 라는 말을 들었었다. 그 당시에는 아무것도 몰라서 "오 상용서비스에서는 이렇게 구성하는구나"하고 넘어갔었다. 몇 년이 지난 지금, 그 기억을 곰곰이 떠올려보니 HA는 구조가 아니라 High Availability, 고가용성을 말하는 것이었다. 고가용성은 구조를 의미하는게 아니라, 예상치 못한 중단 없이 지속적으로 운영될 수 있는 능력을 의미하는 개념이다. 데이터베이스의 고가용성을 보장하기 위해 여러 가지 이중화 전략이 사용된다.  이중화는 단순히 하나의 시스템이 고장나더라도 다른 시스템이 그 기능을 대신할 수 있도록 구성하는 것이다.  전회사에서는 DB 고가용성을 제공하기위해서 Active/StandBy 구조를 사용하고 있..

작년 말에 Aurora MySQL 5.7 버전의 지원 종료와 연장 지원 안내를 받았었다.https://aws.amazon.com/ko/blogs/korea/your-mysql-5-7-and-postgresql-11-databases-will-be-automatically-enrolled-into-amazon-rds-extended-support/ 요약하면 권장 사항인 MySQL 8.0 대신 MySQL 5.7 버전을 계속 사용할 경우 돈을 더 내라는 내용이었다. 올해 전반기 내내 다사다난해서 지금껏 미뤘다가 이제서야 업데이트를 시작할 여유가 생겼다. 버전 업데이트에 앞서 문제 상황을 확인해보자. 1. 연장 지원 비용비용이 저렴하다면 그냥 둬도 될 것 같다. 그런데 연장 지원 비용을 계산해보면 다음과 같다...

실제 EKS에서 동작 확인을 하는건 ArgoCD 까지만 진행할 예정이다. 백엔드 개발자에게 관찰 가능성 도구들까지 배포하고 기능 확인까지하라는건 너무 가혹하다. k8s에서 어플리케이션을 개발하고 배포한다면, ArgoCD는 한번쯤 들어봤을 수 있다. 주로 GitOps를 위해 사용되는데 ArgoCD와 GitHub을 이용해 자동 배포까지 진행해보려 한다. 이번 장에서는 ArgoCD를 배포하고 대시보드를 만들어 볼 것이다. GitOps란?GitOps는 Git 리포지토리를 단일 정보 소스로 사용하여 인프라를 코드로 제공합니다. 제출된 코드에서는 CI 프로세스를 확인하고, CD 프로세스에서는 보안, 코드형 인프라(IaC) 또는 애플리케이션 프레임워크에 설정된 기타 경계와 같은 요구 사항을 확인하고 적용합니다. 코드..