AWS 스터디
EC2에 파일로 key를 저장하는 것은 위험하다고 한다.
우리 서버(EC2)에는 scp를 이용하여 .env파일을 보내고, 수정할 필요가 있으면 EC2에 들어가 vim으로 수정해주고 있다.
그러나, EC2도 털릴 수 있기 때문에 이 방식은 아주 최소한의 보안이라고 한다.
그래서 os환경변수로 설정하거나, DB에 넣거나, API key를 보관하는 SaaS를 이용하거나, encrypt해서 코드에 넣는 등 여러 대안이 있다고 한다. 하지만, 이 방안들 역시 결국 서버에 최소한으로 필요한 secret key가 존재할 뿐만 아니라 최악에는 메모리에 남아있는 key들을 긁어 갈 수도 있다고 한다.
이에 대응하는 방안으로 AWS API Gateway가 있다고 한다.
나중에 참고하자!!
Dry run
dry run이란 우리가 예상하는 결과 시나리오를 테스트하여 품질을 높이는 테스트 과정이라고 한다.
AWS에서의 dry run예시를 하나 들었는데, 팀원들에게 IAM 유저 권한을 부여하고 잘 작동하는지 팀원을 붙잡고 테스트를 해왔다고 한다. 찾아보니 IAM 정책 시뮬레이터라는게 존재했고, 이를 이용하여 개별적으로 테스트를 할 수 있게되었다는 말을 들었다.
추가로, CLI를 통해 EC2를 생성하는 경우 --dry-run 커맨드를 이용해 실제로 EC2를 런칭하지 않고 테스트를 해볼 수 있다고 한다. (과금 X!!)
Policy 커스터마이징
IAM User를 처음 사용했을때, AWS가 제공하는 기본 Policy를 적용하여 부여하였다.
Policy역시 내가 원하는 권한만 지정하여 만들어서 사용가능하다고 한다.
- EC2에 IAM User가 아닌 Role 적용
(role 적용하는것을 헬멧을 씌우는것에 비유한다고 한다 ㅎㅎ)
데스크탑 앱을 만들면서 node에서 이미지 업로드시 multer-s3를 사용해야했기 때문에 aws-sdk에 access key, password를 입력해야했다.
당시에 role을 적용하려고 했으나, role을 생성하면 key, password가 발급되지 않아서 user로 만들어 사용했는데 EC2에 role을 부여하는게 더 일반적이라고 한다.
1인 개발자이라 role, user에 필요성을 못느껴서 관심을 안주고 있었는데, 시간날때 둘의 차이점과 데스크탑 앱에서 role적용 방안을 찾아봐야겠다.
CI (Continuous Integration)
이전까지는 단순한 자동화된 버전관리인줄 알았다.
그러나, 단순히 빌드, 배포만이 아닌 코드를 검증하는 방법까지 포함한다고 한다.
이는 자동화된 테스팅을 통해 지속적으로 균일한 품질을 유지하는 목적이다.
실 예로 들어주신게 자동화 테스팅이 없었던 시절에 다른 서비스 작업을 진행하는 팀원이 자신의 서비스 코드를 망가뜨려 고생했던 기억이 있다고 하셨다.
만약 hook으로 테스팅 도구가 있었다면 이런일이 일어나지 않았을 것이라고 현재 사용하고 계신 Circle CI를 알려주셨다.
예를 들어서 이해가 갔지만, 상당히 어렵고 중요한 영역인것 같다.
기회가 된다면 좀 더 공부할 수 있으면 좋겠다.
PaaS, laaS, SaaS, BaaS
Elastic BeanStalk이 PaaS중 하나라고 설명을 했는데, 그럼 PaaS가 뭐냐는 질문에 정확한 대답을 못하고 애매모호하게 넘어갔다.
끝나고 간단하게라도 어떤 의미인지 살펴봐야겠다는 생각이 들어 찾아보니 백날 말하는것보다 위의 그림으로 한번에 쉽게 이해가 된다고 한다.
이들의 차이는 사용자가 어디까지 직접 관리하느냐의 차이인데, 계속 읽어봐도 말로 잘 표현하진 못하겠고 조금 애매모호한것 같아 내가 이해한 수준에서 간단하게 정리하면,
- On-Premise
직접 인프라, 플랫폼, 어플리케이션을 운영하는 방식을 뜻한다.
- IaaS (Infrastructure as a Service)
서비스 제공자는 가상화 서버, OS, 스토리지 프로비저닝 을하여 사용자가 유형의 서버를 구축할 필요없이 어플리케이션을 올려서 사용할 수 있는 서비스
ex) AWS EC2, S3
- PaaS (Platform as a Service)
IaaS가 제공하는것을 넘어서서 runtime과 web server까지 제공하여 사용자가 어플리케이션에만 집중할 수 있는 서비스
ex) Azure, Google AppEngine, AWS Elastic Beanstalk
- SaaS (Software as a Service)
우리가 일반적으로 사용해왔던 Gmail과 같은 서비스로, 사용자는 어플리케이션 관리, 데이터에 신경쓰지 않고 단순히 제공되는 서비스만 이용하게 된다.
ex) GMail, Google Docs
- BaaS (Backend as a Service)
앱개발을 위해 기존의 벡엔드 서버를 구현하지 않고 사용자는 API를 통해 앱에 필요한 서비스들(Oauth, DB, Location 등..)을 제공받는 서비스
ex) Aws Amplify, Firebase
Beanstalk에서 Rolling과 Rolling with additional batch의 차이점
둘의 차이점을 어제까지 잘 이해해놓고 설명하려고 하니 갑자기 까먹어서 다시한번 정리하고자 한다.
이 둘의 차이점은 업데이트시 최초 배치방법에 차이 및 배포 실패시의 영향에 차이점이 있다.
- Rolling
업데이트시 전환율에 따른 기존의 인스턴스들이 업데이트가 된다.
최초 업데이트 되는 인스턴스들의 배포가 실패하면 해당 인스턴스들은 서비스가 불가하게 된다.
배포 실패 전에 업데이트가 성공한 인스턴스들은 새 버전으로 계속 실행되어 배포된다.
- Rolling with addintional batch
최초 업데이트시 초기 전환율에 따른 인스턴스 개수에 따라 새로운 인스턴스를 생성하여 업데이트를 진행한 후 합병된다.
최초 실패했을때의 문제점을 줄이고자 위의 방식을 이용하며, 최초 실패시 기존 어플리케이션에 영향을 끼치지 않는다.
이후의 업데이트에서는 Rolling과 유사하다.
