새벽 2시, 보안팀으로부터 긴급 슬랙 메시지가 온다. "Log4Shell(CVE-2021-44228) 취약점 패치 지금 당장 전체 서버에 올려야 합니다." EC2 인스턴스가 300대다. SSH 키 다 찾고 Bastion 거쳐서 일일이 접속하면 날 샌다. 패치 스크립트는 있지만 어떻게 300대에 동시에 뿌릴 것인가. 이때 운영자가 꺼내는 도구가 AWS Systems Manager(SSM)다.
SSM은 2015년에 "EC2 Run Command"라는 이름으로 시작해, 지금은 Agent 기반 인스턴스 관리부터 설정 중앙화, 패치 자동화, 세션 감사, 복잡한 운영 자동화까지 아우르는 거대한 운영 플랫폼으로 진화했다. SOA-C02 시험에서 SSM은 전체 시험 문항의 15~20%를 차지한다고 봐도 과언이 아닐 만큼 비중이 크다. 오늘은 이 SSM의 전체 지형을 그리고, 운영자가 매일 확인해야 하는 Managed Instance의 조건과 트러블슈팅 방법을 파악한다.
SSM을 이해하려면 에이전트 기반 서버 관리(Agent-based management)의 역사를 알아야 한다. 2000년대 데이터센터에서는 Puppet(2005), Chef(2009), CFEngine이 서버 상태를 선언적으로 관리했다. 이들은 모두 에이전트가 주기적으로 중앙 서버에 체크인하는 "pull 모델"을 썼다. Ansible(2012)은 SSH 기반 "push 모델"로 에이전트 없이 동작했다.