Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWS 데이터 콜렉터 서버를 항상 동작시키는 기능 구현 #223

Open
kmu-leeky opened this issue Sep 29, 2022 · 10 comments
Open
Assignees

Comments

@kmu-leeky
Copy link
Member

AWS collector 의 경우 서버에서 주기적으로 동작을 하는데, 서버가 정상동작을 멈출 경우 이를 감지하고 새로운 서버를 시작하는 기능이 필요.
Auto scaling 의 min 서버 갯수를 활용하면 구현 가능.
launch configuration 에서 userdata 세팅을 통해서 데이터 수집 스크립트를 서버 시작시 자동으로 실행되게 하면 됨.

@chris0765
Copy link
Contributor

auto scaling을 구성하던 도중, 기존에 생성해둔 collector instance를 기반으로 template을 생성하여, 이를 scaling group에 사용하려고 하였습니다.
하지만 기존에 생성해둔 instance들의 subnet 설정이 문제가 되어 template를 설정할 수 없었고,
template 생성에 사용할 수 있도록 설정한 새로운 instance를 이용해야할 듯 싶습니다.

해당 작업은 #210 PR이 끝나고 새로운 코드 업데이트가 없다고 생각될 때 쯤 진행해야할 것 같습니다.

@kmu-leeky
Copy link
Member Author

재일아. 내생각엔 기존 인스턴스를 기반으로 템플릿을 생성할수도 있는데, 그런 자동화된 기술이 얼마나 잘 되었을지 모르니

  • 기본적인 패키지가 포함된 AMI 생성
  • userdata 에서 최신의 코드를 pull 해도록 설정
  • crontab 설정이 필요하다면 설정 후 주기적으로 동작하게 만들기
    이 정도 단계가 필요하지 않을까 싶어.

수동으로 구성을 한번 해보면 좋을것 같아. 중간에 설정등은 공유해주면 같이 보도록 하자.

@chris0765
Copy link
Contributor

클라우드 컴퓨팅 수업을 통해 Auto-Scaling을 어떻게 설정하면 좋을지 파악할 수 있었습니다.

우선 aws collector와 유사한 환경을 만들어 Auto-Scaling Group 생성을 진행 후 코멘트 남기도록 하겠습니다.

다만, auto-scaling을 통해 생성된 인스턴스는 AMI를 생성한 인스턴스와 별개로 동작하는 것으로 보이는데,
두 인스턴스에서 사용하는 credentials 파일이 같고, 같은 Timestream을 대상으로 하고 있으므로, 실제 collector를 Auto-Scaling Group으로 생성할 때에는 적당한 Auto-Scaling Group 생성 시기를 정하여 진행하도록 하겠습니다.

@kmu-leeky
Copy link
Member Author

코멘트에서 약간 이해가 안되는 부분이 " auto-scaling을 통해 생성된 인스턴스는 AMI를 생성한 인스턴스와 별개로 동작" 이 부분인데. collector 가 동작하는 AMI 를 하나 만들고, 해당 AMI 를 활용해서 launch configuration 만들어서 minimum, desired, maximum 동작갯수를 하나로 하면 되지 않을까? 내일 만나서 같이 이야기 나눠봐도 좋겠다. 클라우드 컴퓨팅 수업 실습에서 진행한 내용 잘 확인해보면 많이 도움 될거야.

@kmu-leeky
Copy link
Member Author

이 이슈도 계속 작업이 안되고 있구나.
https://towardsaws.com/implementation-of-aws-ec2-autorecovery-c7892887bb09

이런식의 auto-recovery 가 빠르게 작업을 가능하게 해줄듯 하다.

@chris0765
Copy link
Contributor

넵, auto-recovery 활용하여 콜렉터 서버가 중단되지 않도록 구현 시도해보겠습니다.

@chris0765
Copy link
Contributor

Cron이 AutoScaling에서 정상적으로 동작하는것은 확인되었으나,
다시 한 번 확인하던 중, AMI를 통해 구성된 Launch Configuration을 사용하여 AutoScaling을 구현할 경우, AMI 생성 이후의 변경점은 새롭게 생성되는 인스턴스에 반영되지 않는 것을 확인하였습니다.

이는 AWS Collector에서 latest_data, workload 등의 중요한 변화를 반영하지 못하므로 현재 상태대로 AutoScaling을 구성할 경우 정상적으로 동작하지 않을 수 있습니다.

현재 인스턴스의 상태를 다음 인스턴스로 반영할 수 있도록 하는 방법을 다시 한 번 찾아보겠습니다.

@kmu-leeky
Copy link
Member Author

만약 문제가 latest_data, workload 등이라면 특정 경로에 해당 파일들이 없다면 다운 받게끔 하는걸로 해결한다라고 이야기를 했던 기억이 있는것 같기도 한데, 지금은 그렇지는 않은거지? 파일 확인 후 없다면 S3 에서 다운로드 받는다. 이렇게 되면 해결이 가능할까?

@chris0765
Copy link
Contributor

현재 workload 파일은 말씀하신것처럼 사용하고 있습니다.

하지만 compare_data에 사용할 latest 데이터, credentials 데이터는 코드의 추가적인 수정이 필요할 것 같습니다.
따로 이슈 생성하여 먼저 진행하도록 하겠습니다.

@chris0765
Copy link
Contributor

check

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants