EC2, CodeDeploy pt.2

1. EC2를 사용하여 어떤 애플리케이션을 배포한 경험이 있나요? 그 과정은 어떻게 진행되었나요? 

"저는 GitHub Actions를 이용해서 CI/CD 파이프라인을 구성하고 AWS EC2에 웹 애플리케이션을 자동으로 배포한 경험이 있습니다.

이러한 작업 흐름은 다음과 같이 이루어졌습니다:

1. 먼저, 웹 애플리케이션의 소스 코드를 Git을 통해 GitHub 리포지토리에 업로드했습니다.
2. GitHub Actions를 설정하기 위해 .github/workflows 디렉토리에 YAML 파일을 생성했습니다.
3. 이 파일에는 원격 서버(EC2 인스턴스)에 접속하기 위한 SSH 키와 AWS 접근 정보를 포함하고 있었습니다. 이 정보는 GitHub Secrets를 통해 안전하게 관리되었습니다.
4. 파일에는 또한 배포가 이루어질 때마다 실행되는 일련의 명령들을 정의하였습니다. 이 명령들은 애플리케이션의 종속성을 설치하고, 테스트를 실행하고, 애플리케이션을 빌드하고, 빌드된 애플리케이션을 EC2 인스턴스로 전송하는 것을 포함했습니다.
5. 마지막으로, 애플리케이션을 EC2 인스턴스에서 실행하는데 필요한 명령들을 작성했습니다.

이런 식으로, GitHub Actions를 통해 CI/CD 파이프라인을 구축하고, 코드 변경 사항이 GitHub 리포지토리에 푸시되는 즉시 자동으로 EC2에 배포되도록 설정했습니다."

 

2. EC2 인스턴스의 선택과 관리에 어떤 고려 사항이 있나요? 

1. 인스턴스 유형 선택: AWS는 다양한 유형의 EC2 인스턴스를 제공하며, 이는 다른 CPU, 메모리, 스토리지, 네트워크 용량을 가지고 있습니다. 이 중에서 애플리케이션의 요구 사항과 예상 트래픽에 맞는 유형을 선택해야 합니다.
2. 비용 최적화: 각 인스턴스 유형에는 다른 비용이 연관되어 있으며, 이를 최적화하는 것이 중요합니다. 예를 들어, 상시 실행해야 하는 애플리케이션의 경우 예약 인스턴스를, 일시적이거나 비정상적인 워크로드의 경우 스팟 인스턴스를 사용할 수 있습니다.
3. 보안 그룹 설정: EC2 인스턴스의 보안 그룹을 적절하게 설정하여, 필요한 트래픽만 허용하고 그 외의 트래픽은 차단하는 것이 중요합니다.
4. 스케일링: 애플리케이션의 로드와 성능 요구 사항이 변화할 때 자동으로 EC2 인스턴스를 스케일링할 수 있는 방법을 고려해야 합니다. AWS의 Auto Scaling 기능을 사용하여 이를 처리할 수 있습니다.
5. 백업과 복구: EC2 인스턴스의 데이터를 보호하고, 시스템 장애나 데이터 손실이 발생했을 때 복구할 수 있는 전략이 필요합니다. 이를 위해 Amazon EBS 볼륨 스냅샷을 주기적으로 생성하고 관리하는 것이 중요합니다.
6. 모니터링과 로깅: AWS CloudWatch를 사용하여 EC2 인스턴스를 모니터링하고 로그를 수집할 수 있습니다. 이를 통해 시스템의 성능을 추적하고 문제를 빠르게 식별할 수 있습니다.
7. AMI 관리: Amazon Machine Image(AMI)를 사용하면 EC2 인스턴스의 설정을 빠르게 복제하고 재사용할 수 있습니다. AMI를 적절히 관리하면 인스턴스 배포를 표준화하고 빠르게 확장할 수 있습니다

3. AWS CodeDeploy를 사용한 배포 프로세스에서 어떤 문제가 발생했고, 어떻게 해결했나요? 

문제 1: 배포 실패

때때로, 배포가 실패하며 이는 다양한 원인으로 인해 발생할 수 있습니다.

해결책: AWS CodeDeploy는 배포 중에 발생한 문제에 대한 로그를 제공합니다. 이를 통해 배포가 실패한 원인을 파악하고 해결할 수 있습니다. 일반적으로, 이 문제는 애플리케이션의 종속성, 스크립트 오류, 리소스 부족 등으로 발생합니다. 이러한 문제를 해결하기 위해 해당 로그를 검토하고, 필요한 수정사항을 소스 코드에 반영한 뒤, 다시 배포를 진행합니다.

문제 2: 오래된 배포 구성

배포 과정에서 이전에 사용되었던 구성이나 설정이 여전히 존재하여, 최신 버전의 애플리케이션을 제대로 배포하지 못하는 경우가 있습니다.

해결책: 이런 경우, AWS CodeDeploy의 배포 설정을 검토하고 필요한 변경사항을 적용해야 합니다. 이에는 배포 그룹의 설정, 배포 방법, 배포 구성 등이 포함될 수 있습니다.

문제 3: 서비스 중단

일부 배포는 애플리케이션에 서비스 중단을 야기할 수 있습니다. 이는 배포 중에 새로운 버전의 애플리케이션을 실행하면서 이전 버전의 애플리케이션이 중지되기 때문입니다.

해결책: 이를 해결하기 위해 AWS CodeDeploy의 블루/그린 배포 방법을 사용할 수 있습니다. 이 방법을 사용하면, 새로운 버전의 애플리케이션을 배포하는 동안 서비스를 계속 유지할 수 있습니다.

 

4. AWS CodeDeploy의 어떤 기능을 활용하여 배포 프로세스를 최적화했나요? 

1. 블루/녹그린 배포: 이 기능을 사용하면 애플리케이션이 배포되는 동안 서비스가 중단되지 않습니다. 새 버전의 애플리케이션을 별도의 환경에서 실행하고, 배포가 성공적으로 완료되면 트래픽을 새 환경으로 전환합니다. 이렇게 하면 애플리케이션의 가용성을 높이고 배포 리스크를 줄일 수 있습니다.
2. 인스턴스 대상 묶음: CodeDeploy는 인스턴스 대상 묶음을 사용하여 복잡한 배포를 쉽게 관리할 수 있게 합니다. 이 기능을 사용하면 동일한 설정을 공유하는 인스턴스 그룹을 한 번에 업데이트할 수 있습니다.
3. 롤백: 배포가 실패하거나 애플리케이션이 예상대로 작동하지 않는 경우, CodeDeploy는 자동 롤백 기능을 통해 이전 버전으로 쉽게 되돌릴 수 있습니다. 이 기능은 배포 리스크를 크게 줄여줍니다.
4. 훅스: CodeDeploy는 배포 생명주기 동안에 실행할 수 있는 여러 훅스를 제공합니다. 이러한 훅스를 사용하여 배포 전, 배포 중, 배포 후에 커스텀 스크립트를 실행할 수 있습니다. 예를 들어, 배포 전에 테스트를 실행하거나, 배포 후에 모니터링 도구를 설정할 수 있습니다.
5. AWS 서비스와의 통합: CodeDeploy는 다른 AWS 서비스와 쉽게 통합될 수 있습니다. 예를 들어, AWS CloudWatch를 사용하여 배포를 모니터링하고, AWS Auto Scaling을 사용하여 인스턴스를 자동으로 스케일링할 수 있습니다.

5. GitHub Actions를 사용하여 CI/CD 파이프라인을 구성한 경험 및 그 과정에서 어떤 도구나 기술을 사용했나요? 

1. 소스 코드 관리: 먼저, 애플리케이션의 소스 코드를 Git을 통해 GitHub 리포지토리에 업로드합니다.
2. CI/CD 파이프라인 구성: GitHub Actions는 .github/workflows 디렉토리 내부의 YAML 형식 파일을 통해 CI/CD 워크플로우를 구성합니다. 이 파일에는 워크플로우의 트리거 조건, 실행 환경, 실행할 명령어 등을 정의합니다.
3. 빌드 및 테스트 자동화: 워크플로우 파일에는 소스 코드의 빌드와 테스트를 자동화하는 단계를 포함합니다. 이는 프로젝트에 따라 다르지만, 일반적으로 필요한 패키지를 설치하고, 코드 빌드 도구를 실행하며, 단위 테스트나 통합 테스트를 실행하는 단계를 포함합니다.
4. 배포 자동화: 배포 단계에서는 빌드된 애플리케이션을 최종 배포 환경으로 전송하고 실행합니다. 이는 AWS EC2 인스턴스, Kubernetes 클러스터, 서버리스 환경 등이 될 수 있으며, 해당 환경에 맞는 배포 도구와 명령어를 사용합니다.

6. GitHub Actions와 AWS CodeDeploy를 통합하여 어떻게 작업했나요? 이를 통해 얻은 이점은 무엇인가요? 

GitHub Actions과 AWS CodeDeploy를 통합하면 GitHub에서 코드 변경이 발생할 때마다 자동으로 AWS에 코드를 배포하는 효율적인 CI/CD 파이프라인을 구축할 수 있습니다. 이를 통해 코드 품질을 개선하고 배포 시간을 단축할 수 있습니다.

• 효율성: 코드 변경이 발생할 때마다 자동으로 테스트하고 배포하는 것으로 개발자가 배포를 위한 시간을 줄일 수 있습니다.
• 신뢰성: 모든 코드 변경이 자동으로 테스트되므로, 배포 전에 문제를 발견하고 수정할 수 있습니다.
• 속도: 코드를 더 빠르게 테스트하고 배포함으로써, 기능을 더 빠르게 사용자에게 제공할 수 있습니다.

 

7. GitHub Actions를 사용한 배포 프로세스에서 보안 관련 고려 사항은 무엇인가요? 

1. 비밀 관리: 비밀(예: API 키, 비밀번호 등)은 절대로 워크플로우 파일이나 소스 코드에 직접 포함시키지 않아야 합니다. 이러한 비밀은 GitHub Actions의 "Secrets" 기능을 사용해 안전하게 저장하고 워크플로우에서 참조해야 합니다.
2. 최소한의 권한 원칙: 워크플로우에서 사용하는 AWS 계정이나 비밀은 필요한 최소한의 권한만을 부여해야 합니다. 이렇게 하면 잠재적인 보안 위협이 발생했을 때도 피해를 최소화할 수 있습니다.
3. 코드 리뷰 및 병합 정책: 모든 코드 변경은 코드 리뷰를 통해 검증되어야 합니다. 또한, 보안 측면에서 중요한 변경(예: 워크플로우 파일이나 보안 설정 변경)은 권한이 있는 사람만 병합할 수 있어야 합니다.
4. 외부 동작의 사용: GitHub Actions에서는 외부 동작(actions)을 사용할 수 있습니다. 이들 동작은 소스 코드를 검토하고 신뢰할 수 있는 소스에서만 사용해야 합니다. 가능한 경우, 동작의 버전을 지정하여 무작위 변경으로부터 보호할 수 있습니다.
5. 로그 및 모니터링: 워크플로우 실행에 대한 로그를 수집하고 모니터링해야 합니다. 이를 통해 잠재적인 보안 문제를 조기에 발견할 수 있습니다.

8. 배포 과정에서 롤백을 처리한 경험은 있나요? 어떻게 처리했나요? 

 

 

9. 애플리케이션 모니터링 및 로깅에 사용한 도구나 전략은 무엇인가요? 

애플리케이션의 모니터링과 로깅은 시스템의 안정성과 성능을 유지하고 문제를 신속하게 해결하는 데 중요합니다. 이를 위한 다양한 도구와 전략이 있습니다.

1. 로깅 도구: 애플리케이션의 작동에 대한 정보를 로깅하고 분석하는 데 사용되는 도구입니다. AWS CloudWatch, ELK 스택(Elasticsearch, Logstash, Kibana), Grafana, Splunk 등이 대표적인 예입니다.
2. 성능 모니터링 도구: 시스템의 성능을 실시간으로 모니터링하고 분석하는 데 사용되는 도구입니다. 이를 통해 CPU 사용률, 메모리 사용, 네트워크 트래픽, 디스크 IO 등을 모니터링하고 문제를 신속하게 파악할 수 있습니다. AWS CloudWatch, New Relic, Datadog, Prometheus 등이 대표적입니다.
3. 에러 트래킹 도구: 애플리케이션에서 발생하는 에러를 실시간으로 추적하고, 에러의 원인을 분석하고 보고하는 데 사용되는 도구입니다. Sentry, Rollbar, Bugsnag 등이 이에 해당합니다.
4. 분산 추적 시스템: 마이크로서비스 아키텍처와 같이 분산 시스템에서 요청이 어떻게 처리되는지를 추적하는 데 사용되는 도구입니다. Zipkin, Jaeger, AWS X-Ray 등이 대표적입니다.
5. 로깅 및 모니터링 전략: 로깅 및 모니터링 전략은 어떤 데이터를 수집할 것인지, 얼마나 오래 보관할 것인지, 어떻게 분석하고 사용할 것인지 등을 결정합니다. 이는 회사의 요구사항, 규제 준수, 데이터 저장 및 분석 비용 등을 고려하여 결정됩니다.

 

10. 병렬 또는 블루/그린 배포와 같은 다른 배포 전략에 대해 경험이 있나요? 

1. 병렬 배포: 병렬 배포는 모든 서버 또는 인스턴스에 동시에 업데이트를 배포하는 전략입니다. 이 방식은 매우 빠르지만, 만약 새로운 버전에 결함이 있다면 전체 시스템에 영향을 미칠 수 있습니다. 따라서 이 전략은 테스트가 철저히 이루어진 경우나, 전체 시스템에 빠르게 변경사항을 적용해야 하는 경우에 적합합니다.
2. 블루/그린 배포: 블루/그린 배포는 두 개의 동일한 프로덕션 환경(블루와 그린)을 두고 한 환경에는 실제 트래픽을, 다른 한 환경에는 새로운 버전의 애플리케이션을 배포하는 전략입니다. 새로운 버전이 정상적으로 동작한다면, 트래픽을 새로운 환경으로 점진적으로 이동시킵니다. 이 방식은 실제 사용자에게 서비스 중단 없이 새로운 버전을 안전하게 배포할 수 있으므로, 신뢰성이 중요한 애플리케이션에 적합합니다.

이 두 가지 전략 모두 장단점이 있으며, 특정 상황에 따라 적합한 전략을 선택해야 합니다. 예를 들어, 신뢰성이 중요하다면 블루/그린 배포를, 빠른 배포가 필요하다면 병렬 배포를 선택할 수 있습니다.