천천히, 꾸준하게

지난 포스팅에서는 온프레미스 환경에서 호스팅 하는 서버에 대해서 AWS로 마이그레이션 에 대한 내용을 다뤘다. 이번에는 온프레미스 환경에서 호스팅 하는 데이터베이스를 AWS RDS로 마이그레이션 해보려고 한다. AWS DMS(Database Migration Service) 서비스를 이용하여 온프레미스 환경의 데이터베이스를 AWS RDS로 아주 쉽게 마이그레이션 할 수 있다. 심지어 SCT(Schema Conversion Tool)을 사용해 이기종 데이터베이스 간 마이그레이션도 가능하다. 이를 테면, PostgreSQL에서 MySQL로 마이그레이션이 가능하다. 데이터만 알아서 복제해주기 때문에, 데이터베이스의 버전은 크게 상관이 없고, 기존 온프레미스 환경에서 낮은 버전의 데이터베이스를 사용하고 있었다면..

기존에 레거시 시스템들은 대부분 IDC에 서버 장비를 두고 직접 하드웨어/소프트웨어를 운영하는 온프레미스 형태가 대부분이다. 지금은 클라우드 인프라 환경이 너무 좋아져서 시스템이 성장하면 할수록 마이그레이션 하는 추세다. 이게 단순하게 트렌드가 아니라 실제로 인프라를 운영하면서 온프레미스 환경보다는 클라우드 환경에서 더 안전하게 관리할 수 있고, 관리 포인트가 적어질 수 있고, 비용을 탄력적으로 사용하면서 좀 더 유연한 관리가 가능하게 됐다. 그리고 AWS MGN(Application Migration Service) 서비스를 이용하여 온프레미스 인프라에서 AWS로 마이그레이션 할 수 있다. AWS는 정말 없는 게 없다. MGN에서 제공하는 Agent만 온프레미스 서버에서 설치하면 알아서 서버의 CPU,..

이번에는 SysOps Administrator - Associate 자격증을 취득했다. 확실히 지난 Solutions Architect 자격증을 준비할 때 보다는 이미 경험했던 터라 시험 예약, 장소, 유의사항 등 시험 외에 알아볼 것들이 적어서 수월했다. 시험 예약, 장소, 유의사항 등에 대한 내용은 이전 포스팅에서 확인할 수 있다. 시험 준비 이전 시험과 비슷하게 시험 안내서, 그리고 늘 많은 도움이 되는 AWS 공식 레퍼런스, 그리고 Udemy에 있는 시험 덤프를 활용하여 공부했다. 공부는 평일 지하철 이동 시간, 주말 시간을 활용하여 약 한 달정도 준비를 했다. 이전에 Solutions Architect 자격증과 내용이 많이 겹치진 않았지만, 그래도 전반적인 AWS 서비스에 대해서 한 번 훑어본 ..

클라우드 환경에서 서비스를 운영하다 보면, 나도 언제 생성했는지 모르는 리소스나 쓰임이 명확하지 않은 리소스들이 있다. 그런 경우 임시 방편으로 EC2의 경우에는 인스턴스 중지를, RDS의 경우에는 중지 후 최종 스냅샷을 생성 후 삭제 등 다양하게 리소스를 관리하게 된다. 그렇게 되면, 해당 EC2와 관련된 EBS 혹은 ELB는 중지 상태로 유지할 수 없으니 삭제하지 않는 한 비용이 발생하게 된다. 또 남겨진 스냅샷의 경우에도 이제는 이게 쓰임이 있는 리소스 였는지, 아니였는지 정말 무한의 굴레에 빠지게 된다. 리소스를 삭제할수도 없는 이러한 상황에서 비용을 아낄 수 있는 가장 효율적인 방법을 일부 소개하려고 한다. 실제로 우리 회사에서는 해당 방법들을 적용시킨 이후에 비용을 무려 약 53.87%나 감소..

EC2를 접근하기 위해서는 AWS 기준으로 Key File을 이용하여 SSH로 접근한다. 그렇다면, 프라이빗 서브넷(인터넷이 차단된)에 있는 EC2는 어떻게 접근할까? 이전에 사용하던 방식은 앞 단에 Bastion Host를 두고 프록시하여 SSH 접속을 했다. 이렇게 되면 보안 상 취약한 요소가 키 파일 사용 SSH 포트 개방 Bastion Host 관리 서버 접속 사용자의 행동 추적이 어려움 정도가 있을 수 있다. 또, 프라이빗 서브넷에 RDS 혹은 ElastiCache 등 데이터 관련 리소스가 있다고 가정한다면, 이 리소스들도 Bastion Host를 통해 접속해야 하고, 그렇게 되면 터미널로 접속하기 때문에 보통 데이터베이스를 접속할 때 DataGrip과 같은 데이터베이스 툴을 사용할 수 없어 굉..

AWS 리소스를 관리할 때는 보통 보안 상의 이유로 루트 계정으로 관리하지 않고, 따로 IAM 계정을 생성하고 해당 계정이 사용할 리소스에 대한 여러가지 접근 권한 정책을 부여하여 사용하게 된다. 예를 들면, IAM 계정에 모든 EC2에 대해 읽기 권한만 주고 싶다면 아래의 정책을 생성하여 할당한다. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" } ] } 그리고 일반적으로, 좀 더 수준 높은 보안을 위해 IAM 계정에 MFA(Multi Factor Authentication)를 설정하는 것이 권장된다. 이처럼 하나의 AWS 계정 안에서 IAM 계정을 어떻게 하면..

인프라를 운영하다 보면, 현재 사용하고 있는 디스크 볼륨의 크기를 늘리거나, 줄여야 할 때가 있다. EBS의 경우에는 기본적으로 확장의 개념은 쉽다. EBS 크기를 확장하고 서버에 접속하여 명령어로 파티션 크기만 늘려주면 된다. 반대로 축소는 굉장히 까다로운 작업이다. 기본적으로 확장만 제공하고 축소 기능은 제공하고 있지 않다. 물론, 서브 볼륨이라면 크기가 작은 새로운 볼륨을 마운트하여 파일 복사만 하면 되지만, 루트 볼륨인 경우에는 단순하게 파일 복사만 해선 안 된다. 새로운 볼륨을 추가하고, 부트 로더를 설치해주고, 기존에 사용하던 루트 볼륨의 UUID를 가져와서 교체할 루트 볼륨에 라벨을 넣어줘야 한다. Amazon Linux 2 기준으로 작성된 문서입니다. 그 외 CentOS나 RHEL 계열의 ..

한 해도 정말 빠르게 지나갔다. 개인적으로도 크고 작은 일이 정말 많았다. 그래서 시간이 더더욱 빨리 지나간듯 하다. 그럼에도, 뭐랄까 나의 발전에 대해서는 긍정적이라고 생각할 수가 없다. 그래서 매년 항상 해왔던 다짐들을 이제는 정말 실천해볼까 한다. 2022년은 어땠을까 2022년은 내가 25살이 되던 해였다. 반오십의 나이인데, 나는 특성화고등학교를 졸업하고 대학교 대신에 취업의 길을 선택했다. 또래보다는 확실하게 빠른 시작을 할 수 있었다. 사실 20살부터 25살까지는 그게 내가 제일 내세울 수 있는 장점이자 독이었던 것 같다. 늘 그런 생각을 했다. '난 어린 나이에 일찍 취업했으니까, 남들보다 더 천천히 해도 돼.' 어리석은 생각이었다. 매년 그 쓸데 없는 장점에 취해 남들은 앞..

애플리케이션 로그를 CloudWatch로 수집하고 로그를 통해서 문제가 생겼음을 감지하기 위해 CloudWatch로 수집된 로그 중 특정 조건(필터)를 통해서 Slack으로 메세지를 보내는 설정을 구성해보고자 한다. Spring Boot에서 CloudWatch 로그를 수집하는 내용은 이전 포스팅에서 다뤘기 때문에 참고하면 된다. 실습 환경 AWS EC2 CloudWatch Lambda (Node 16) Slack Webhook 구조 CloudWatch에 저장된 로그를 Lambda 함수에 특정 필터와 함께 트리거하여, Slack에 메세지를 보내는 구조이다. 수집된 로그 확인 일반적으로 애플리케이션에서 이런 식의 여러 레벨의 로그들이 꾸준히 발생되고 있을 것이다. 애플리케이션이 정상적으로 동작하기 위해 특별..

기존에 회사에서 애플리케이션 로그를 수집하는 방식은 애플리케이션 서버에 일주일 로그를 저장을 하고 매 주마다 로그를 저장하는 원격 서버로 파일을 저장하는 명령어인 scp를 통해 저장하고 로그 정책에 따라 shell 스크립트를 이용해 저장 기간이 지난 로그를 삭제하는 구성이었다. 로그를 원격지에 소산하는 것에는 큰 문제가 없었지만, 생각보다 스크립트를 작성하고 관리하는 측면에서 꽤나 여러가지 문제가 있었다. 예를 들면, 사전에 충분히 테스트가 되지 않아 스크립트 자체에 문제가 있는 경우 혹은 서버 레벨에서 cron을 통해 주기적으로 스크립트를 실행했는데 cron이 올바르게 동작하지 않는다든가, 꽤 관리적 측면에서 많이 신경을 써줘야 했다. 그래서 간단한 설정으로 Spring Boot 애플리케이션 자체에서 ..