[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Managing Your AWS Infrastructure at Scale(2015, 영문)내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
본 문서는 총 2부로 구성되어 있으며 이 글은 1부입니다.
2부 링크 : 대규모로 AWS 인프라 관리하기 2/2
요약
AWS(Amazon Web Services)를 통해 조직은 여러 지리적 위치에 대규모 애플리케이션 인프라를 구축할 수 있습니다. 이러한 대규모 클라우드 기반 애플리케이션을 배포할 때는 이러한 시스템을 운영하는 데 드는 비용과 복잡성이 크기에 비례하여 증가하지 않도록 하는 것이 중요합니다.
이 백서는 AWS에서 확장 가능하고 예측 가능한 방식으로 인프라를 구축 및 관리하고자 하는 기존 및 잠재 고객(특히 설계자, 개발자 및 sysop 관리자)을 대상으로 합니다.
이 백서에서는 새로운 인스턴스를 프로비저닝하고, 요구 사항에 맞게 인스턴스를 구성하고, 애플리케이션 코드를 배포하는 툴과 기술에 대해 설명합니다. 또한 인스턴스를 상태 비저장 상태로 유지하여 확장성과 내결함성이 뛰어난 아키텍처를 구축하기 위한 전략도 소개합니다. NAT에서 설명하는 기술을 사용하면 서비스를 단일 인스턴스에서 수천 개의 인스턴스로 확장하는 동시에 일관된 프로세스와 툴셋을 유지하여 관리할 수 있습니다.
본 백서의 목적상, 기본 스크립팅 및 Amazon Elastic Compute Cloud(Amazon EC2)와 같은 핵심 서비스에 대한 지식을 보유하고 있다고 가정합니다.
소개
대규모 클라우드 기반 애플리케이션을 설계하고 구현할 때는 인프라를 어떻게 관리하여 이러한 시스템을 실행하는 데 드는 비용과 복잡성을 최소화하는 것이 중요합니다. Amazon EC2를 처음 사용하기 시작하면 데이터 센터에서 실행되는 일반 가상 서버와 마찬가지로 EC2 인스턴스를 쉽게 관리할 수 있습니다. 인스턴스를 생성하고, 로그인하고, 운영 체제를 구성하고, 추가 패키지를 설치하고, 애플리케이션 코드를 설치할 수 있습니다. 보안 패치를 설치하고, 코드의 새 배포를 롤아웃하고, 필요에 따라 구성을 수정하여 인스턴스를 유지할 수 있습니다. 운영 오버헤드에도 불구하고 오랫동안 이러한 방식으로 인스턴스를 관리할 수 있습니다.
그러나 사용자의 인스턴스는 불가피하게 원래 규격과 다르기 시작하므로 동일한 환경의 다른 인스턴스와의 불일치가 발생할 수 있습니다. 여러 환경에서 대규모 인스턴스(instance)를 관리할 때 알려진 기준선과 이러한 차이가 큰 문제가 될 수 있습니다. 궁극적으로는 환경 예측이 떨어지고 유지 관리가 어려워지기 때문에 서비스 문제로 이어질 수 있습니다.
AWS 플랫폼은 다른 접근 방식으로 이러한 문제를 해결할 수 있는 일련의 도구를 제공합니다. Amazon EC2 및 관련 서비스를 사용하면 EC2 인스턴스 및 기타 실행 구성 요소와 독립적으로 인프라의 원하는 최종 상태를 지정하고 관리할 수 있습니다.
예를 들어 기존 접근 방식을 사용하면 각 서버에 차례로 로그인하고 수동으로 변경하여 웹 서버에서 실행되는 Apache 서버의 구성을 변경할 수 있습니다. AWS 플랫폼을 사용하면 웹 서버의 기본 규격을 변경하고 새 EC2 인스턴스를 실행하여 이전 버전을 대체하는 다른 접근 방식을 취할 수 있습니다. 따라서 각 인스턴스가 동일하게 유지됩니다. 또한 변경 사항을 구현하려는 노력을 줄이고 오류가 발생할 가능성을 줄입니다.
실행 중인 EC2 인스턴스 및 환경에서 다른 구성 요소와 독립적으로 인프라를 정의하는 것으로 간주하기 시작하면 동적 클라우드 환경의 이점을 더 크게 활용할 수 있습니다.
· 소프트웨어 정의 인프라 — 소프트웨어 아티팩트 집합을 사용하여 인프라를 정의하면 소프트웨어 구성 요소를 개발할 때 사용되는 많은 도구와 기술을 활용할 수 있습니다. 여기에는 버전 제어 시스템에서 인프라의 진화를 관리하는 것과 지속적인 통합(CI) 프로세스를 사용하여 인프라 변경을 지속적으로 테스트하고 검증한 후 운영 환경에 구축할 수 있습니다.
· 오토 스케일링 및 자가 복구 — 일관된 규격에서 새 인스턴스를 자동으로 프로비저닝하는 경우 자동 크기 조정 그룹을 사용하여 EC2 함대의 인스턴스 수를 관리할 수 있습니다. 예를 들어, EC2 그룹의 평균 활용률이 높을 때 새 EC2 인스턴스를 자동 확장 그룹에 증분하여 추가하는 조건을 설정할 수 있습니다. 또한 Auto Scaling을 사용하여 손상된 EC2 인스턴스와 비정상적인 애플리케이션을 감지하고 개입 없이 인스턴스를 교체할 수도 있습니다.
· 빠른 환경 프로비저닝 — 일관된 환경을 빠르고 쉽게 프로비저닝할 수 있으므로 팀 내에서 새로운 작업 방식이 열립니다. 예를 들어, 테스터가 다른 변경 사항과 격리된 자신의 개인 테스트 환경에서 새 버전의 응용 프로그램을 검증할 수 있도록 새 환경을 프로비저닝할 수 있습니다.
· 비용 절감 — 이제 환경을 신속하게 프로비저닝할 수 있으므로 더 이상 필요하지 않을 때 제거할 수도 있습니다. 이를 통해 사용하는 리소스에 대해서만 비용을 지불하므로 비용이 절감됩니다.
· 블루-그린 배포 — 기존 인프라 옆에 새 인스턴스(코드의 새 버전 포함)를 프로비저닝하여 새 버전의 애플리케이션을 배포할 수 있습니다. 그런 다음 Blue-green 배포라고 하는 접근 방식으로 환경 간에 트래픽을 전환할 수 있습니다. 이는 문제 발생 시 쉽고 빠르게 배포를 롤백할 수 있는 기능 등 기존 구축 전략에 비해 많은 이점을 제공합니다.
이러한 이점을 활용하려면 인프라에 다음과 같은 기능이 있어야 합니다.
1. 새로운 인프라 구성 요소는 알려진 버전 제어 기준선에서 반복 가능하고 예측 가능한 방식으로 자동으로 프로비저닝됩니다.
2. 모든 인스턴스는 상태 비저장 상태이므로 애플리케이션 상태 또는 시스템 데이터가 손실될 위험 없이 언제든지 제거 및 폐기할 수 있습니다.
다음 그림은 전체 프로세스를 보여 줍니다.
다음 섹션에서는 이러한 기능을 갖춘 시스템을 구축하는 데 사용할 수 있는 도구 및 기법에 대해 설명합니다. 데이터 손실 없이 인스턴스를 쉽게 프로비저닝하고 제거할 수 있는 아키텍처로 전환하면 인프라 관리 방식을 근본적으로 변경할 수 있습니다. 궁극적으로, 시간과 관련된 운영 오버헤드를 크게 늘리지 않고도 인프라를 확장할 수 있습니다.
새로운 EC2 인스턴스 프로비저닝
여러 외부 이벤트를 수행하려면 환경에 새 인스턴스를 프로비저닝해야 합니다.
· 새 인스턴스를 만들거나 기존 환경을 복제합니다.
· 기존 환경에서 실패한 인스턴스를 교체합니다.
· 오토 스케일링 그룹에 인스턴스를 추가하기 위해 “스케일업” 이벤트에 응답합니다.
· 소프트웨어 스택의 새 버전을 배포합니다(블루-그린 배포 사용).
이러한 이벤트 중 일부는 예측하기 어렵거나 심지어 불가능하기 때문에 환경에 새 인스턴스를 생성하는 프로세스가 완전히 자동화되고 반복 가능하며 일관성이 있어야 합니다.
새 인스턴스를 자동으로 프로비저닝하고 이를 서비스로 가져오는 프로세스를 부트스트래핑이라고 합니다. Amazon EC2 인스턴스 부트스트래핑에는 여러 가지 방법이 있습니다. 가장 널리 사용되는 두 가지 접근 방식은 AMI(Amazon Machine Image)를 직접 생성하거나 동적 구성을 사용하는 것입니다. 다음 섹션에서 두 가지 접근 방식을 설명합니다.
자신의 AMI 생성
AMI(Amazon 시스템 이미지)는 Amazon EC2 인스턴스를 시작하는 데 필요한 모든 정보를 제공하는 템플릿입니다. 최소한 기본 운영 체제를 포함하지만 추가 구성 및 소프트웨어도 포함될 수 있습니다. AMI의 여러 인스턴스를 시작할 수 있으며 단일 AMI에서 여러 유형의 인스턴스를 시작할 수도 있습니다.
새 EC2 인스턴스를 시작할 때 다음과 같은 몇 가지 옵션이 있습니다.
· AWS에서 제공하는 AMI를 선택.
· 커뮤니티에서 제공하는 AMI를 선택.
· AWS Marketplace에서 사전 구성된 소프트웨어가 포함된 AMI를 선택.
· 사용자 지정 AMI를 생성.
운영 체제만 포함하는 기본 AMI에서 인스턴스를 시작하는 경우 인스턴스가 시작된 후 추가 구성 및 소프트웨어로 인스턴스를 추가로 사용자 지정할 수 있습니다. 사용자 정의 AMI를 생성하는 경우 전체 소프트웨어 스택이 이미 포함된 인스턴스를 시작할 수 있으므로 런타임 구성이 필요하지 않습니다. 그러나 사용자 정의 AMI를 생성할지 여부를 결정하기 전에 이점과 단점을 이해해야 합니다.
사용자 정의 AMI의 장점:
· 속도 증가 — 모든 구성은 AMI 자체로 패키징되므로 새 인스턴스를 시작할 수 있는 속도가 크게 향상됩니다. 이 기능은 자동 스케일링 이벤트 중에 특히 유용합니다.
· 외부 의존성 감소 — 모든 것을 AMI로 패키징한다는 것은 새로운 인스턴스(예: 패키지 또는 코드 저장소)를 시작할 때 외부 서비스의 가용성에 의존하지 않는다는 것을 의미합니다.
· 시작시 복잡한 구성 스크립트에 대한 의존성을 제거 — AMI를 사전 구성함으로써 이벤트 및 인스턴스 교체를 확장하는 것은 더 이상 출시 시점에 구성 스크립트가 성공적으로 완료되는 데 의존하지 않습니다. 따라서 잘못된 스크립트로 인한 운영 문제가 발생할 가능성이 줄어듭니다.
사용자 정의 AMI의 단점:
· 민첩성 저하 — 모든 것을 AMI로 패키징하면 간단한 코드 변경 및 결함 수정도 새로운 AMI를 생성해야 합니다. 따라서 애플리케이션의 개선 사항과 수정 사항을 개발, 테스트 및 릴리스하는 데 걸리는 시간이 늘어납니다.
· 복잡성 — AMI 빌드 프로세스를 관리하는 작업은 복잡할 수 있습니다. 수정사항 간의 변경사항을 식별할 수 있고 감사할 수 있는 일관되고 반복 가능한 AMI를 생성할 수 있는 프로세스가 필요합니다.
· 런타임 구성 요구 사항 — AMI가 생성된 시점에 알 수 없는 런타임 정보를 기반으로 AMI에 추가 사용자 지정을 해야 할 수 있습니다. 예를 들어, AMI가 사용되는 위치에 따라 애플리케이션에 필요한 데이터베이스 연결 문자열이 변경될 수 있습니다.
이러한 장점과 단점을 고려하여 스택의 정적 구성 요소를 AMI로 구축하고 런타임에 정기적으로 변화하는 동적 측면을 구성하는 하이브리드 방식을 권장합니다.
사용자 정의 AMI에 포함할 구성과 동적 실행 시간 스크립트에 포함할 구성을 결정하는 데 도움이 되는 요소는 다음과 같습니다.
· 배포 빈도 — 시스템에 향상된 기능을 얼마나 자주 구현할 수 있으며, 스택에서 어떤 수준으로 구현할 예정입니까? 예를 들어 애플리케이션에 대한 변경 사항을 매일 배포할 수 있지만 JVM 버전을 훨씬 덜 자주 업그레이드할 수 있습니다.
· 외부 의존성 감소 — 시스템의 구성이 다른 외부 시스템에 종속된 경우 인스턴스를 시작할 때가 아니라 AMI 빌드의 일부로 이러한 구성 단계를 수행하기로 결정할 수 있습니다.
· 빠르게 확장하기 한 요구 사항 — 애플리케이션이 오토 스케일링 그룹을 사용하여 로드 변화에 적응합니까? 그렇다면 애플리케이션의 로드는 얼마나 빨리 증가합니까? 그러면 EC2에 새 인스턴스를 프로비저닝해야 하는 속도가 결정됩니다.
이전 기준에 따라 애플리케이션 스택을 평가한 후에는 사용자 지정 AMI에 포함할 스택의 요소와 출시 시점에 동적으로 구성될 요소를 결정할 수 있습니다.
다음 그림은 일반적인 Java 웹 애플리케이션 스택과 AMI 및 동적 스크립트 전반에서 이를 관리하는 방법을 보여 줍니다.
기본 AMI 모델에서는 OS 이미지만 AMI로 유지됩니다. AMI는 AWS 관리 이미지일 수도 있고 사용자가 관리하는 AMI에 사용자 고유의 OS 이미지가 포함될 수도 있습니다.
기본 AMI 모델에서는 자주 변경되지 않는 스택 요소(예: JVM 및 애플리케이션 서버와 같은 구성 요소)가 AMI에 내장됩니다.
전체 스택 AMI 모델에서는 스택의 모든 요소가 AMI에 내장됩니다. 이 모델은 응용 프로그램이 자주 변경되지 않거나 응용 프로그램의 자동 확장 요구사항이 빠른 경우에 유용합니다(즉, 응용 프로그램을 동적으로 설치하는 것은 가능하지 않음). 그러나 응용 프로그램을 AMI로 빌드하더라도 응용 프로그램을 실행 시간에 동적으로 구성하는 것이 유리할 수 있습니다. 예를 들어, 응용 프로그램을 사용하면 여러 환경에서 AMI를 사용할 수 있습니다.
AMI 빌드 관리
대부분의 사용자는 다음과 유사한 프로세스를 사용하여 AMI를 수동으로 구성하는 것으로 시작합니다.
1. 최신 버전의 AMI를 시작합니다.
2. 인스턴스에 로그인하고 수동으로 재구성합니다(예: 패키지 업데이트 또는 새 응용 프로그램 설치).
3. 실행 중인 인스턴스를 기반으로 새 AMI를 생성합니다.
이 수동 프로세스는 단순한 애플리케이션에 충분하지만 AMI 업데이트가 정기적으로 필요한 더 복잡한 환경에서는 관리하기가 어렵습니다. AMI를 생성하기 위해서는 일관되고 반복 가능한 프로세스가 필수적입니다. 또한 AMI의 한 버전과 다른 버전 간에 변경된 사항을 감사할 수 있어야 합니다.
이를 위한 한 가지 방법은 자동 스크립트를 사용하여 기본 AMI의 사용자 지정을 관리하는 것입니다. 고유한 스크립트를 개발하거나 구성 관리 도구를 사용할 수 있습니다. 구성 관리 도구에 대한 자세한 내용은 이 백서의 구성 관리 도구 사용 섹션을 참조합니다.
자동 스크립트를 사용하면 수동 방법에 비해 여러 가지 이점이 있습니다. 자동화는 AMI 생성 프로세스의 속도를 크게 높입니다. 또한 스크립트/구성 파일에 버전 제어를 사용할 수 있으므로 AMI 버전 간의 변경 내용이 투명하고 감사 가능한 반복 가능한 프로세스가 생성됩니다.
이 자동 프로세스는 수동 프로세스와 유사합니다.
1. 최신 버전의 AMI를 시작합니다.
2. 원하는 도구를 사용하여 자동 구성을 실행합니다.
3. 실행 중인 인스턴스를 기반으로 새 AMI 이미지를 생성합니다.
패커와 같은 타사 도구를 사용하여 프로세스를 자동화할 수 있습니다. 그러나 많은 이들은 이 접근 방식이 여러 환경에 걸쳐 자주 구축되는 AMI를 사용하는 환경에서는 여전히 시간이 너무 많이 소요된다는 사실을 알고 있습니다.
Linux 운영 체제를 사용하는 경우 실행 중인 인스턴스가 아닌 Amazon EBS(Amazon Elastic Block Store) 볼륨을 사용자 지정하여 새 AMI를 생성하는 데 걸리는 시간을 줄일 수 있습니다. Amazon EBS 볼륨은 단일 Amazon EC2 인스턴스에 연결할 수 있는 내구성이 뛰어난 블록 레벨 저장 장치입니다. 기본 AMI 스냅샷에서 Amazon EBS 볼륨을 생성하고 이 볼륨을 새 AMI로 저장하기 전에 사용자 지정할 수 있습니다. 이는 EC2 인스턴스를 초기화하는 데 걸리는 시간을 EBS 볼륨을 생성하고 첨부하는 데 필요한 훨씬 짧은 시간으로 대체합니다.
또한, 이러한 접근방식은 Amazon EBS 스냅샷의 증분적 특성을 이용합니다. EBS 스냅샷은 Amazon S3에 저장된 EBS 볼륨의 지정 시점 백업입니다. 스냅샷은 증분 백업으로, 가장 최근 스냅샷 이후에 변경된 장치의 블록만 저장됩니다. 예를 들어 구성 업데이트가 8GB EBS 볼륨의 블록 중 100MB만 변경되면 100MB만 Amazon S3에 저장됩니다.
이를 위해 최신 AMI 빌드를 기반으로 새 EBS 볼륨을 연결하고, 볼륨을 사용자 지정하는 데 필요한 스크립트를 실행하고, 볼륨의 스냅샷을 생성하고, 스냅샷을 AMI의 새 버전으로 등록하는 작업을 수행하는 장시간 실행되는 EC2 인스턴스가 필요합니다. 예를 들어 Netflix는 오픈 소스 도구에서 이 기술을 사용합니다. 아미네이터라고 합니다.
다음 그림은 이 프로세스를 보여 줍니다.
1. 최신 AMI 스냅샷에서 볼륨을 생성합니다.
2. 새 AMI 구축을 담당하는 인스턴스에 볼륨을 연결합니다.
3. 자동 프로비저닝 스크립트를 실행하여 AMI 구성을 업데이트합니다.
4. 볼륨을 스냅샷으로 만듭니다.
5. 스냅샷을 새 AMI 버전으로 등록합니다.
동적 구성
이제 AMI에 포함할 항목과 런타임에 동적으로 구성해야 할 항목을 결정했으므로 동적 구성 및 부트스트래핑 프로세스를 완료하는 방법을 결정해야 합니다. 단순 스크립트에서 복잡한 중앙 집중식 구성 관리 툴에 이르기까지 인스턴스를 구성하는 데 사용할 수 있는 툴과 기법이 많이 있습니다.
자체 솔루션을 스크립팅
AMI에 포함된 사전 구성에 따라 애플리케이션 스택의 최종 요소를 구성할 수 있는 간단하고 우아한 방법으로 단일 스크립트 또는 스크립트 집합만 필요할 수 있습니다.
사용자 데이터 및 클라우드 초기화
AWS Management Console 또는 API를 사용하여 새 EC2 인스턴스를 시작하면 사용자 데이터를 인스턴스로 전달할 수 있는 옵션이 제공됩니다. EC2 메타데이터 서비스를 통해 인스턴스에서 사용자 데이터를 검색하고 이를 사용하여 자동화된 작업을 수행하여 처음 시작할 때 인스턴스를 구성할 수 있습니다.
Linux 인스턴스가 시작되면 사용자 데이터를 통해 인스턴스로 전달 된 초기화 명령어는 cloud-init라는 기술을 사용하여 실행됩니다 .cloud-init 패키지는 Canonical에서 빌드 한 오픈 소스 애플리케이션이며 여러 기본에 포함되어 있습니다. Linux AMI (배포에서 cloud-init를 지원하는지 확인하려면 배포 별 설명서를 참조하십시오.) AWS에서 생성하고 유지 관리하는 Linux 배포 인 Amazon Linux에는 사용자 정의 된 버전의 cloud-init가 포함되어 있습니다.
EC2 인스턴스에서 실행중인 cloud-init에 쉘 스크립트 또는 cloud-init 지시문의 두 가지 유형의 사용자 데이터를 전달할 수 있습니다. 예를 들어 설치된 모든 패키지를 업데이트하고 인스턴스를 PHP 웹 서버로 구성하기 위해 다음 셸 스크립트를 인스턴스로 전달할 수 있습니다.
#!/bin/sh yum update -yyum -y install httpd php php-mysql chkconfig httpd on/etc/init.d/httpd start
다음 사용자 데이터는 동일한 결과를 얻지만 cloud-init를 사용합니다.
지침은 다음과 같습니다.
#cloud-configrepo_update: true repo_upgrade: allpackages:- httpd- php- php-mysqlruncmd:- service httpd start- chkconfig httpd on
AWS 윈도우즈 AMI에는 AWS에서 설치한 추가 서비스인 EC2Config가 포함되어 있습니다. EC2Config 서비스는 인스턴스에서 윈도우즈 활성화, 관리자 암호 설정, AWS 콘솔에 쓰기, 애플리케이션 내에서 원클릭 sysprep 수행 등의 작업을 수행합니다. 윈도우즈 인스턴스를 시작하는 경우 EC2Config 서비스는 사용자 데이터를 통해 인스턴스로 전달되는 스크립트를 실행할 수도 있습니다. 데이터는 cmd.exe 프롬프트 또는 Windows PowerShell 프롬프트에서 실행하는 명령의 형식일 수 있습니다.
이 방법은 단순한 사용 사례에 적합합니다. 그러나 관리해야 하는 환경 수와 함께 인스턴스 역할(웹, 데이터베이스 등)의 수가 증가함에 따라 스크립트를 관리하기가 어려워질 수 있습니다. 또한 사용자 데이터는 16KB로 제한되므로 구성 작업 및 관련 논리가 많은 경우 사용자 데이터를 사용하여 Amazon S3에서 추가 스크립트를 다운로드하여 실행할 수 있는 것이 좋습니다.
EC2 메타 데이터 활용
새 인스턴스를 구성할 때는 일반적으로 인스턴스가 시작되는 컨텍스트를 이해해야 합니다. 예를 들어 인스턴스의 호스트 이름이나 인스턴스가 시작된 영역 또는 가용성 영역을 알아야 할 수 있습니다. EC2 메타데이터 서비스를 쿼리하여 인스턴스에 대한 상황별 정보를 제공하고 사용자 데이터를 검색할 수 있습니다. 실행 중인 인스턴스 내에서 인스턴스 메타데이터에 액세스하려면 cURL 또는 GET 명령과 같은 도구를 사용하여 표준 HTTP GET를 만들 수 있습니다. 예를 들어 인스턴스의 호스트 이름을 검색하려면 다음 URL에 HTTP GET 요청을 할 수 있습니다.
http://169.254.169.254/latest/meta-data/hostname리소스 태깅
EC2 리소스를 관리하는 데 도움이 되도록 호스트 이름, 가용성 영역 및 기타 리소스를 정의하는 데 사용되는 EC2 메타데이터 외에도 각 인스턴스에 고유한 메타데이터를 할당할 수 있습니다. 태그를 사용하여 이 작업을 수행합니다. 각 태그는 키와 값으로 구성되며, 두 태그 모두 인스턴스가 시작될 때 정의합니다.
EC2 태그를 사용하여 시작 중인 인스턴스에 대한 추가 컨텍스트를 정의할 수 있습니다. 예를 들어 다음 그림과 같이 다양한 환경 및 역할에 대해 인스턴스에 태그를 지정할 수 있습니다.
EC2 인스턴스가 인터넷에 액세스할 수 있는 한 이러한 태그는 부트스트래핑 스크립트 내의 AWS CLI(명령줄 인터페이스)를 사용하여 해당 인스턴스의 역할과 해당 인스턴스가 시작되는 환경에 따라 구성할 수 있습니다.
모두 결합된 설명
다음 그림은 Amazon S3에서 호스팅되는 사용자 데이터 및 구성 스크립트 집합을 사용하는 일반적인 부트스트래핑 프로세스를 보여 줍니다.
이 예에서는 사용자 데이터를 경량 메커니즘으로 사용하여 Amazon S3에서 기본 구성 스크립트를 다운로드합니다. 이 스크립트는 역할 및 환경에 관계없이 모든 인스턴스에서 시스템을 기준선으로 구성하는 역할을 담당합니다(예: 스크립트가 모니터링 에이전트를 설치하고 OS가 패치되었는지 확인할 수 있음).
이 기본 구성 스크립트는 CLI를 사용하여 인스턴스 태그를 검색합니다. 이 스크립트는 “역할” 태그의 값에 따라 특정 역할을 수행하는 데 필요한 추가 구성(예: 웹 서버에 Apache 설치)을 담당하는 추가 오버레이 스크립트를 다운로드합니다. 마지막으로 스크립트는 인스턴스 “환경” 태그를 사용하여 적절한 환경 오버레이 스크립트를 다운로드하여 인스턴스가 상주하는 환경에 대한 inal 구성을 수행합니다(예: 개발 환경에서 로그 수준을 DEBUG로 설정).
스크립트에 포함될 수 있는 중요한 정보를 보호하려면 IAM 역할을 사용하여 이러한 자산에 대한 액세스를 제한해야 합니다.
구성 관리 도구 사용
자체 솔루션을 스크립팅하는 것은 효과가 있지만 대규모 환경을 관리할 때는 빠르게 복잡해질 수 있습니다. 또한 변경 사항을 식별하거나 구성 문제를 해결하는 등 환경을 제어하고 감사하기가 어려워질 수 있습니다. 구성 관리 도구를 사용하여 인스턴스 구성을 관리하여 이러한 몇 가지 문제를 해결할 수 있습니다.
구성 관리 도구를 사용하면 일반적으로 도메인별 언어를 사용하여 환경의 구성을 코드로 정의할 수 있습니다. 이러한 도메인별 언어는 코드에 대한 선언적 접근 방식을 사용합니다. 여기서 코드는 종료 상태를 설명하며 실행할 수 있는 스크립트가 아닙니다. 환경은 코드를 사용하여 정의되므로 구성의 변경 내용을 추적하고 버전 제어를 적용할 수 있습니다. 또한 많은 구성 관리 도구는 컴플라이언스, 감사 및 검색과 같은 추가 기능을 제공합니다.
푸시 / 풀 모델
구성 관리 도구는 일반적으로 푸시 또는 풀 중 하나를 활용합니다. 도구에 사용되는 모델은 노드(AWS의 대상 EC2 인스턴스)가 마스터 구성 관리 서버와 상호 작용하는 방식으로 정의됩니다.
푸시 모델에서 마스터 구성 관리 서버는 관리해야 하는 노드를 인식하고 구성을 원격으로 푸시합니다. 이러한 노드는 마스터 서버에 미리 등록해야 합니다. 일부 푸시 도구는 에이전트 없이 SSH와 같은 기존 프로토콜을 사용하여 원격으로 구성을 실행합니다. 다른 사용자는 패키지를 누른 다음 에이전트를 사용하여 로컬로 실행됩니다. 푸시 모델에는 일반적으로 동적 및 확장 가능한 AWS 리소스로 작업할 때 다음과 같은 제약 조건이 있습니다.
· 마스터 서버에는 관리해야 하는 노드에 대한 정보가 있어야 합니다. 노드가 오고 갈 수 있는 자동 스케일링과 같은 도구를 사용하는 경우 이 문제가 어려울 수 있습니다.
· 원격 실행을 수행하는 푸시 시스템은 노드에서 구성 변경 사항이 오프로드되어 로컬로 실행되는 시스템뿐만 아니라 확장되지 않습니다. 대규모 환경에서는 여러 시스템을 병렬로 구성할 때 마스터 서버가 오버로드될 수 있습니다.
· 노드에 원격으로 연결하려면 특정 포트를 노드에 인바운드하도록 허용해야 합니다. 일부 원격 실행 도구의 경우 원격 SSH가 포함됩니다.
두 번째 모델은 풀 모델입니다. 풀 시스템을 사용하는 구성 관리 도구는 노드에 설치된 에이전트를 사용합니다. 에이전트는 마스터 서버에 구성을 요청합니다. 노드는 부팅 시 구성을 끌거나 에이전트를 데몬하여 마스터를 정기적으로 폴링하여 구성 변경을 수행할 수 있습니다. 풀 시스템은 특히 동적 및 확장 가능한 AWS 환경을 관리하는 데 유용합니다. 풀 모델의 주요 이점은 다음과 같습니다.
· 노드를 구성하기 전에 마스터가 노드가 존재하는지 알 필요가 없으므로 노드를 쉽게 스케일업 및 스케일다운할 수 있습니다. 노드는 서버에 등록하기만 하면 됩니다.
· 모든 프로세싱이 원격 노드에서 오프로드되어 로컬로 실행되므로 풀 시스템을 사용할 때 구성 관리 마스터의 확장 필요성이 줄어듭니다.
· 특정 포트를 노드에 인바운드에서 열 필요가 없습니다. 대부분의 도구를 사용하면 에이전트가 HTTPS와 같은 일반적인 아웃바운드 포트를 사용하여 마스터 서버와 통신할 수 있습니다.
Chef 예
많은 구성 관리 도구가 AWS와 함께 작동하며 가장 인기있는 것은 Chef, Puppet, Ansible 및 SaltStack입니다.이 섹션의 예에서는 Chef를 사용하여 구성 관리 도구로 부트 스트랩을 시연합니다. 다른 도구를 사용하고 동일한 원리를 적용할 수 있습니다.
Chef는 에이전트(Chhef-client)를 사용하여 마스터 서버(Chef 서버)에서 구성을 가져오는 오픈 소스 구성 관리 도구입니다. 이 예에서는 부팅 시 Chef 서버에서 구성을 가져와 노드를 부팅하는 방법을 보여 줍니다.
이 예제는 다음과 같은 가정을 기반으로 합니다.
· Chef 서버를 구성했습니다.
· AWS 명령줄 도구가 설치되어 구성되어 있는 AMI가 있습니다.
· Cheff-client가 설치되어 AMI에 포함되어 있습니다.
먼저 Chef 내에서 구성 할 내용을 살펴 보겠습니다 Apache 웹 서버를 설치하고 ‘Hello World’사이트를 배포하는 간단한 Chef cookbook을 만들겠습니다 Chef cookbook은 레시피 모음입니다. 파일, 패키지, 권한 등을 포함 할 수 있는 노드 정의이 아파치 요리 책의 기본 레시피는 다음과 같습니다.
## Cookbook Name:: apache# Recipe:: default## Copyright 2014, YOUR_COMPANY_NAME## All rights reserved - Do Not Redistribute#package "httpd"#Allow Apache to start on boot service "httpd" doaction [:enable, :start] end#Add HTML Template into Web Root template "/var/www/html/index.html" dosource "index.html.erb" mode "0644"end
이 레시피에서는 HTTPD (HTTP 데몬) 서비스를 설치, 활성화 및 시작한 다음 index.html에 대한 템플리트를 렌더링하여 /var/www/html 디렉토리에 배치합니다. 이 경우는 매우 간단한 HTML 페이지입니다.
<h1>Hello World</h1>다음으로, 요리 책은 Chef 서버에 업로드되고 Chef는 cookbook을 역할로 그룹화 할 수 있는 기능을 제공합니다. 역할은 환경 내의 서버가 여러 역할을 하고 cookbook이 겹치는 역할을 하는 대규모 환경에서 유용합니다. 이 cookbook을 ‘webserver’역할에 추가합니다.
이제 EC2 인스턴스 (노드)를 시작할 때 Chef를 사용하여 부트스트랩 하기 위해 EC2 사용자 데이터를 제공 할 수 있습니다.이를 최대한 동적으로 만들기 위해 EC2 태그를 사용하여 노드에 적용 할 Chef 역할을 정의 할 수 있습니다. 예를 들어, 웹 서버와 데이터베이스 서버는 EC2의 ‘role’태그에 다른 값을 할당하면 동일한 사용자 데이터를 사용할 수 있습니다.
또한 새로운 인스턴스가 Chef 서버로 인증되는 방법을 고려해야하며, Amazon S3 서버 측 암호화를 사용하여 개인 키를 암호화 된 Amazon S3 버킷에 저장할 수 있으며 IAM 역할을 사용하여 이 버킷에 대한 액세스를 제한 할 수 있습니다. 그런 다음 키를 사용하여 Chef 서버에 인증 할 수 있으며, Chef-client는 validator.pem 파일을 사용하여 새 노드를 등록 할 때 Chef 서버에 인증합니다.
또한 구성을 가져올 Chef 서버를 알아야합니다. 사전에 채워진 client.rb 파일을 Amazon S3에 저장하고 이를 사용자 데이터 스크립트에 복사 할 수 있습니다. 이 예제에서는 Chef 서버가 하나만 있고 사전에 채워진 client.rb 파일이 충분하다고 가정하고 이 두 파일을 사용자 지정 AMI 빌드에 포함시킬 수도 있습니다.
사용자 데이터는 다음과 같습니다.
#!/bin/bash cd /etc/chef#Copy Chef Server Private Key from S3 Bucketaws s3 cp s3://s3-bucket/orgname-validator.pem orgname- validator.pem#Copy Chef Client Configuration File from S3 Bucket aws s3 cp s3://s3-bucket/client.rb client.rb#Change permissions on Chef Server private key. chmod 400 /etc/chef/orgname-validator.pem#Get EC2 Instance ID from the Meta-Data Service INSTANCE_ID=`curl -s http://169.254.169.254/latest/meta-data/instance-id`#Get Tag with Key of ‘role’ for this EC2 instance ROLE_TAG=$(aws ec2 describe-tags --filters "Name=resource- id,Values=$INSTANCE_ID" "Name=key,Values=role" --output text)#Get value of Tag with Key of ‘role’ as string ROLE_TAG_VALUE=$(echo $ROLE_TAG | awk 'NF>1{print $NF}')#Create first_boot.json file dynamically adding the tag value as the chef role in the run-listecho "{\"run_list\":[\"role[$ROLE_TAG_VALUE]\"]}" > first_boot.json#execute the chef-client using first_boot.json config chef-client -j first_boot.json#daemonize the chef-client to run every 5 minutes chef-client -d -i 300 -s 30
앞의 사용자 데이터 예에서와 같이 프라이빗 S3 버킷에서 클라이언트 구성 파일을 복사 한 다음 EC2 메타 데이터 서비스를 사용하여 인스턴스에 대한 정보 (이 예에서는 인스턴스 ID)를 가져옵니다. ‘role’키가 있는 모든 태그에 대한 EC2 API를 생성하고 이 값의 Chef 역할로 Chef 실행 목록을 동적으로 구성한 다음 마지막으로 포함 된 first_boot.json 옵션을 제공하여 첫 번째 Chef-Client 실행을 실행합니다. 그런 다음 chef-client를 한 번 더 실행하지만 이번에는 5분마다 구성을 가져 오기 위해 데몬화 된 설정에서 실행합니다.
이제 새로운 EC2 인스턴스에 적용할 수 있는 재사용 가능한 EC2 사용자 데이터가 있습니다. ‘역할’ 태그에 대상 Chef 서버의 역할과 일치하는 값이 제공되면 해당 Chef cookbook을 사용하여 인스턴스를 구성합니다.
모두 결합된 설명
다음 그림은 인스턴스 시작부터 트래픽 서비스를 제공할 준비가 된 완전히 구성된 인스턴스에 이르기까지 일반적인 워크플로우를 보여 줍니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
