AWS
VPC란 무엇인가요?
VPC는 가상 개인 클라우드(Virtual Private Cloud)의 약자입니다. VPC는 클라우드 컴퓨팅 환경에서 프라이빗 네트워크를 구성하기 위해 사용되는 가상 네트워킹 기술입니다.
일반적으로 VPC는 공용 클라우드 제공 업체(예: Amazon Web Services의 Amazon VPC)가 제공하는 클라우드 환경에서 사용됩니다. VPC를 사용하면 사용자는 가상의 네트워크를 생성하고, IP 주소 범위, 서브넷, 라우팅 테이블 등을 정의하여 네트워크를 사용자의 요구에 맞게 구성할 수 있습니다.
VPC를 사용하면 사용자는 가상 서버(인스턴스), 데이터베이스, 로드 밸런서 등을 네트워크 내에 배치하여 애플리케이션을 실행할 수 있습니다. 이 가상 서버 및 리소스는 외부에서 접근할 수 없는 프라이빗 네트워크 내에 있기 때문에 보안과 격리를 강화할 수 있습니다. 또한 VPC는 가상 네트워킹을 통해 여러 가용 영역에 걸쳐 리소스를 분산시키고 가용성을 향상시킬 수 있습니다.
VPC는 기업의 내부 네트워크와 유사한 방식으로 작동하며, 네트워크 주소 할당, 서브넷 분할, 라우팅 등과 같은 네트워크 관리 작업을 수행할 수 있습니다.
라우팅 테이블의 역할은 무엇인가요?
라우팅 테이블은 네트워크에서 데이터 패킷의 전송 경로를 결정하는 데 사용되는 중요한 구성 요소입니다. 라우팅 테이블은 네트워크 장비(라우터, 스위치 등)에 저장되며, 목적지 IP 주소에 따라 어떤 경로로 패킷을 전달해야 하는지를 정의합니다.
라우팅 테이블에는 네트워크의 서브넷(IP 대역)과 연결된 다른 네트워크 또는 장비에 대한 정보가 포함됩니다. 각 항목은 대상 네트워크의 IP 주소 범위와 대상에 도달하기 위해 사용해야 하는 다음 홉(네트워크 세그먼트 간의 경로)의 IP 주소를 지정합니다.
라우팅 테이블은 라우터에 의해 참조되며, 패킷이 특정 네트워크로 전달될 때 라우터는 라우팅 테이블을 조회하여 최적의 경로를 결정합니다. 경로 선택은 일반적으로 가장 긴 접두사 매칭(longest prefix match) 알고리즘에 따라 이루어집니다. 이 알고리즘은 대상 IP 주소를 라우팅 테이블의 항목과 비교하여 가장 긴 접두사(가장 구체적인 네트워크)에 해당하는 항목을 선택합니다.
라우팅 테이블을 사용하면 네트워크 트래픽을 효율적으로 전달하고, 다양한 네트워크 간의 연결성을 제어할 수 있습니다. 또한 복잡한 네트워크 환경에서 다양한 경로 및 우선순위를 설정하여 트래픽을 로드 밸런싱하고, 장애 조치 및 고가용성을 위한 백업 경로를 정의할 수 있습니다.
NAT 게이트웨이의 역할은 무엇인가요?
NAT(Network Address Translation) 게이트웨이는 네트워크에서 사설 IP 주소와 공인 IP 주소 간의 주소 변환을 수행하는 장치입니다. NAT 게이트웨이는 사설 네트워크에 속한 장치들이 인터넷과 통신할 때 사설 IP 주소를 공인 IP 주소로 변환하고, 반대로 인터넷에서 들어오는 응답 패킷의 공인 IP 주소를 사설 IP 주소로 변환하여 해당 장치로 전달합니다.
NAT 게이트웨이의 주요 역할은 다음과 같습니다:
- 사설 IP 주소와 공인 IP 주소 간의 주소 변환: NAT 게이트웨이는 사설 네트워크 내의 장치들이 인터넷에 접속할 때 사설 IP 주소를 공인 IP 주소로 변환하여 외부 네트워크로 나가는 트래픽을 처리합니다. 이를 통해 사설 IP 주소를 가진 여러 장치가 하나의 공인 IP 주소를 공유하여 인터넷에 접속할 수 있습니다.
- 보안과 네트워크 격리 강화: NAT 게이트웨이는 사설 네트워크 내부에 있는 장치들의 IP 주소를 외부로 노출시키지 않고, 공인 IP 주소를 사용하여 통신하므로 네트워크 보안을 강화할 수 있습니다. 외부에서는 사설 네트워크 내부의 IP 주소를 알 수 없으며, 사설 네트워크 내부의 장치들도 외부에서 직접 접근할 수 없습니다.
- IP 주소 고갈 문제 해결: NAT 게이트웨이를 사용하면 사설 IP 주소를 사용하는 사설 네트워크를 구축할 수 있으므로, IPv4 주소의 한정된 공급에 따른 IP 주소 고갈 문제를 완화할 수 있습니다. 하나의 공인 IP 주소를 가진 NAT 게이트웨이로 여러 사설 IP 주소를 변환하여 사용할 수 있습니다.
보안 그룹과 네트워크 ACL의 차이점은 무엇인가요?
보안 그룹은 AWS(Amazon Web Services)와 같은 클라우드 환경에서 제공되는 가상 방화벽으로, EC2 인스턴스와 관련된 인바운드 및 아웃바운드 트래픽을 제어하는 데 사용됩니다. 보안 그룹은 인스턴스 수준의 보안을 설정하며, 인스턴스에 대한 액세스를 제어하는 데 사용됩니다. 보안 그룹은 기본적으로 "허용 규칙"만 정의하며, 특정 IP 주소, 포트, 프로토콜 등을 허용하거나 차단할 수 있습니다. 보안 그룹은 stateful(상태를 유지하는)이므로 허용한 트래픽에 대한 응답 트래픽은 자동으로 허용됩니다.
반면에 네트워크 ACL은 VPC(Virtual Private Cloud)의 수준에서 작동하는 방화벽입니다. 서브넷과 관련된 인바운드 및 아웃바운드 트래픽을 제어하는 데 사용됩니다. 네트워크 ACL은 서브넷 내의 모든 인스턴스에 대한 트래픽을 제어하는데 사용되며, 서브넷 간의 트래픽 흐름을 관리할 수 있습니다. 네트워크 ACL은 순서가 있는 규칙 목록으로 구성되어 있으며, 명시적으로 허용한 규칙 외의 모든 트래픽은 거부됩니다. 네트워크 ACL은 stateless(상태를 유지하지 않는)이므로 인바운드 및 아웃바운드 트래픽에 대한 규칙을 따로 정의해야 합니다.
요약하자면, 보안 그룹은 인스턴스 수준에서 작동하며, 상태를 유지하며 허용 규칙을 정의하여 특정 인스턴스에 대한 액세스를 제어합니다. 반면에 네트워크 ACL은 VPC 수준에서 작동하며, 서브넷 수준에서 트래픽을 제어하고, 순서가 있는 규칙으로 구성되어 있으며, 상태를 유지하지 않고 명시적으로 정의한 규칙을 적용하여 트래픽을 필터링합니다.
IAM의 구성 요소에 대해서 설명해주세요.
IAM(Identity and Access Management)은 AWS(Amazon Web Services)에서 제공하는 서비스로, 사용자, 그룹, 역할과 같은 식별자(Identity)와 해당 식별자가 AWS 리소스에 대한 액세스를 어떻게 관리하는지를 정의하는 액세스 권한(Permissions)을 관리합니다. IAM은 AWS 계정의 보안과 리소스 접근을 중앙 집중화하고, 사용자와 리소스 간의 권한을 세밀하게 제어할 수 있습니다.
IAM의 주요 구성 요소는 다음과 같습니다:
- 사용자(User): IAM 사용자는 AWS 계정에 액세스할 수 있는 개별적인 엔터티입니다. 각 사용자는 고유한 액세스 키와 비밀 액세스 키를 가질 수 있으며, 이를 사용하여 AWS API 및 콘솔에 로그인하여 서비스를 사용할 수 있습니다.
- 그룹(Group): 그룹은 IAM 사용자의 집합으로 사용자들에게 동일한 액세스 권한을 부여하는 데 사용됩니다. 그룹을 사용하면 여러 사용자에게 동일한 권한을 일괄적으로 할당할 수 있으며, 새로운 사용자가 추가되거나 기존 사용자의 액세스 권한이 변경되더라도 일관성 있게 적용될 수 있습니다.
- 역할(Role): 역할은 AWS 리소스에 대한 액세스를 임시로 할당하기 위해 사용됩니다. 역할은 사용자나 그룹과 다르게 직접 로그인하지 않고, AWS 서비스나 인증된 외부 엔터티(예: 회사의 ID 공급자)가 역할을 전환하여 액세스할 수 있습니다. 역할은 보안 상의 이유로 인증 자격 증명을 외부에 노출시키지 않고도 권한을 부여할 수 있도록 해줍니다.
- 정책(Policy): IAM 정책은 AWS 리소스에 대한 액세스를 규정하는 규칙 세트입니다. 정책은 JSON 형식으로 작성되며, 사용자, 그룹, 역할에 연결되어 특정 작업을 수행할 수 있는 권한을 정의합니다. 정책은 최소 권한 원칙에 따라 사용자에게 필요한 권한만을 부여하고, 필요하지 않은 권한을 제한하여 보안을 강화할 수 있습니다.
이러한 IAM 구성 요소를 사용하여 AWS 리소스에 대한 액세스를 효율적으로 관리하고, 사용자 및 그룹별로 권한을 구성함으로써 보안을 강화할 수 있습니다.
IAM 사용자를 보다 안전하게 관리할 수 있는 방법으로는 무엇이 있을까요?
- 강력한 암호 정책 설정: IAM 사용자의 암호는 강력하고 예측하기 어려운 형태여야 합니다. 길이가 적절하고 대소문자, 숫자, 특수 문자를 혼합하여 사용하는 것이 좋습니다. 또한, 암호 정책에서 주기적인 암호 변경을 요구하고, 이전 암호의 재사용을 제한할 수 있습니다.
- 다단계 인증(Multi-Factor Authentication, MFA) 활성화: MFA는 추가적인 보안 계층으로 사용됩니다. 사용자가 로그인할 때 비밀번호 외에도 추가 인증 요소(예: OTP(One-Time Password), SMS, 하드웨어 토큰)를 요구하므로 계정에 무단 액세스하는 것을 어렵게 만듭니다.
- 최소 권한 원칙 적용: 사용자에게 필요한 최소한의 권한만 부여하여 범위를 제한하는 것이 중요합니다. 정책을 작성할 때 필요한 작업과 리소스에 대해서만 허용하도록 설정하고, 특정 작업을 거부하는 규칙을 적용할 수 있습니다.
- IAM 그룹 사용: 비슷한 권한을 가진 사용자를 그룹으로 묶어서 권한을 일괄적으로 관리하는 것이 유용합니다. 그룹을 사용하여 사용자에게 권한을 할당하고, 필요에 따라 그룹에 새로운 사용자를 추가하거나 제거하여 일관성을 유지할 수 있습니다.
- 정기적인 권한 검토: 사용자의 권한을 정기적으로 검토하여 필요한 권한을 유지하고, 불필요한 권한을 제거해야 합니다. 사용자의 업무나 책임이 변경될 때마다 권한을 업데이트하여 보안을 유지합니다.
- 로깅 및 감사: AWS CloudTrail과 같은 로깅 서비스를 활용하여 IAM 사용자의 활동을 모니터링하고, 이를 통해 이상 행위나 보안 위험을 탐지할 수 있습니다. 이러한 로그를 감사 및 분석하여 보안 사고 조사에 활용할 수 있습니다.
- 교육과 인식 제고: 사용자에게 IAM 사용에 대한 적절한 교육과 훈련을 제공하여 보안 사고나 위험에 대한 인식을 높이는 것이 중요합니다. 정기적인 보안 교육과 최선의 보안 관행에 대한 지침을 제공하여 사용자들이 보안에 대한 중요성을 이해하고 적절한 조치를 취할 수 있도록 지원해야 합니다.
애플리케이션 로드 밸런서와 네트워크 로드 밸런서의 차이는 무엇인가요?
- 애플리케이션 로드 밸런서 (Application Load Balancer, ALB):
- 계층 7 (응용 계층)에서 동작합니다.
- HTTP, HTTPS 및 WebSocket 트래픽을 로드 밸런싱할 수 있습니다.
- URL 기반 라우팅, 쿠키 기반 세션 어피니티, 동적 포트 매핑 등 고급 기능을 제공합니다.
- 트래픽을 여러 대상 그룹(인스턴스, 컨테이너, IP 주소 등)으로 분산시키고, 대상 상태를 주기적으로 확인하여 건강한 대상에만 트래픽을 전달합니다.
- 애플리케이션의 로드 밸런싱 및 스케일링에 적합합니다.
- 네트워크 로드 밸런서 (Network Load Balancer, NLB):
- 계층 4 (전송 계층)에서 동작합니다.
- TCP, UDP, TLS 등의 프로토콜을 로드 밸런싱할 수 있습니다.
- 고성능 로드 밸런서로서 대량의 연결을 처리하고, 초당 수백만 개의 요청을 처리할 수 있습니다.
- 고정 IP 주소를 사용하여 서비스를 제공하므로 클라이언트에게 항상 동일한 IP 주소를 제공할 수 있습니다.
- 로드 밸런서 수준에서 TCP 연결 및 스트림 처리를 지원합니다.
- 높은 처리량과 낮은 대기 시간 요구 사항을 가지는 네트워크 트래픽을 처리하기에 적합합니다.
애플리케이션 로드 밸런서는 웹 애플리케이션과 관련된 기능과 프로토콜을 지원하며, 사용자의 요청을 기준으로 대상 그룹으로 트래픽을 분산시킵니다. 반면에 네트워크 로드 밸런서는 다양한 프로토콜을 로드 밸런싱할 수 있으며, 고성능 처리를 위한 TCP 연결 및 스트림 처리를 지원합니다. 선택할 로드 밸런서는 애플리케이션의 특성과 요구 사항에 따라 결정되어야 합니다.
수평 확장을 하기 위해 Auto Scaling 정책을 구성할 때, 어떤 경우에 Auto Scaling이 되도록 만들면 좋을까요?
- 예상치 못한 트래픽 증가: 애플리케이션 또는 서비스에 대한 트래픽이 예측하기 어렵거나 예상치 못한 트래픽 증가가 발생하는 경우 Auto Scaling을 구성하는 것이 유용합니다. 예를 들어, 특정 이벤트, 프로모션, 마케팅 캠페인 등으로 인해 애플리케이션에 대한 트래픽이 급증할 수 있는 경우, Auto Scaling을 통해 트래픽에 적응하여 자동으로 인스턴스 수를 늘리고 처리량을 유지할 수 있습니다.
- 일일 또는 주간 패턴의 변동성: 일일 또는 주간 패턴에 따라 트래픽이 변동하는 경우 Auto Scaling을 구성하여 트래픽 변동성에 신속하게 대응할 수 있습니다. 예를 들어, 웹 애플리케이션의 경우 주간에는 트래픽이 많아지고 주말에는 감소할 수 있습니다. 이러한 경우에 Auto Scaling을 사용하여 주간에는 인스턴스 수를 늘리고 주말에는 줄여서 자원 사용을 최적화할 수 있습니다.
- 로드 밸런서 사용: 로드 밸런서와 함께 Auto Scaling을 구성하면 로드 밸런서가 트래픽을 분산하고 인스턴스 수를 조정할 수 있습니다. 로드 밸런서를 사용하여 트래픽을 분산하면 부하가 골고루 분포되고, 필요한 경우 Auto Scaling을 통해 인스턴스를 자동으로 추가하거나 제거하여 성능과 가용성을 유지할 수 있습니다.
- 비즈니스의 변동성: 비즈니스 요구 사항이나 수요의 변동성에 따라 Auto Scaling을 구성하는 것이 유용합니다. 예를 들어, 온라인 상점의 경우 휴일, 특정 이벤트 또는 판매 기간 동안 수요가 증가할 수 있습니다. 이러한 경우 Auto Scaling을 사용하여 인스턴스 수를 동적으로 조정하여 수요에 맞게 대응할 수 있습니다.
Auto Scaling은 애플리케이션의 수요에 따라 리소스를 자동으로 확장하거나 축소하여 효율적인 운영을 지원합니다. 따라서 예상치 못한 트래픽 변동이나 일정한 패턴의 변동성이 있는 경우 Auto Scaling을 구성하여 애플리케이션의 가용성과 성능을 유지할 수 있습니다.
인스턴스 종료시 볼륨이 삭제되는 것을 막으려면 어떻게 해야 할까요?
- EBS 볼륨의 "삭제 보호" 옵션을 활성화하여 인스턴스 종료 시 볼륨 삭제를 방지할 수 있습니다.
- 정기적으로 스냅샷을 생성하여 데이터를 백업하고, 필요한 경우 스냅샷을 사용하여 볼륨을 복원할 수 있습니다.
- 인스턴스 테레이네이션 기능을 활용하여 인스턴스 종료 시에도 연결된 EBS 볼륨을 보존할 수 있습니다.
API Gateway란 무엇인가요?
- API Gateway는 웹 서비스 및 애플리케이션의 API 진입점을 제공하는 서비스입니다.
- API 라우팅, 인증 및 권한 부여, 스로틀링 등 다양한 기능을 제공하여 API 개발과 관리를 단순화합니다.
- 보안, 성능, 로깅, 캐싱 등의 기능을 활용하여 API의 보안과 성능을 강화할 수 있습니다.
람다를 사용할 때, 가용성을 위해서(쓰로틀링이 걸리지 않도록) 신경써야 할 부분은 무엇인가요?
- 리소스 할당을 적절히 조정하여 람다 함수의 성능과 가용성을 향상시킵니다.
- 쓰로틀링 제한과 병렬성 설정을 확인하고 필요에 따라 조정하여 요청 처리에 제한이 없도록 합니다.
- 에러 처리 및 재시도 로직을 구현하여 실행 중에 발생할 수 있는 문제에 대비하고, 다중 리전 배포를 고려하여 장애 시에도 계속적인 가용성을 제공합니다.
ECS/EKS에서 Fargate와 EC2를 사용하는 것의 차이는 무엇인가요?
- Fargate는 서버리스 컴퓨팅 기술을 사용하여 컨테이너 실행 환경을 제공하며, 사용자는 인프라 관리 없이 컨테이너에 집중할 수 있습니다.
- EC2는 가상 서버를 프로비저닝하여 컨테이너를 실행하는 기존의 클라우드 컴퓨팅 서비스로, 사용자는 인스턴스와 클러스터 관리를 수행해야 합니다.
- 선택은 사용자의 요구 사항과 관리 모델에 따라 결정되어야 하며, Fargate는 서버 관리 없이 컨테이너 실행에 집중하고자 할 때 유용하며, EC2는 더 많은 제어권과 구성 가능성을 필요로 할 때 적합합니다.
애플리케이션 설계
프로세스 간의 느슨한 결합이 왜 중요할까요?
- 느슨한 결합은 시스템의 유연성과 확장성을 향상시킵니다.
- 모듈화와 유지 보수성을 개선하며, 오류 격리와 안정성을 증진시킵니다.
- 팀 간 협업과 분리된 개발을 용이하게 하여 개발 생산성을 높입니다.
마이크로서비스 아키텍처의 장점과 단점을 설명해주세요.
장점: 모듈화와 독립성으로 개발과 배포를 용이하게 하며, 확장성과 기술 다양성을 제공합니다. 단점: 복잡성과 관리 부담이 증가하고, 네트워크 오버헤드와 테스트 및 디버깅의 어려움이 있을 수 있습니다. 마이크로서비스 아키텍처는 장점으로 유연성과 독립성을 가져오지만, 단점으로는 관리 부담과 복잡성을 주의해야 합니다.
쿼리와 커맨드를 분리(CQRS)해야 하는 이유는 무엇인가요?
- CQRS는 읽기 작업과 쓰기 작업을 분리하여 성능 최적화와 확장성을 도모합니다.
- 읽기와 쓰기에 대한 각각의 모델을 사용하여 도메인 모델을 명확하게 분리하고 유지보수성을 향상시킵니다.
- 도입 시 도메인의 복잡성과 추가 개발 비용을 고려해야 하지만, CQRS는 데이터 조작과 조회에 특화된 이점을 제공합니다.
메시지 큐의 종류와 컨셉, 대표 서비스를 설명해주세요.
- Apache Kafka: 고성능 분산 스트리밍 플랫폼으로 대규모 실시간 데이터 스트림 처리와 메시지 전달을 위한 publish-subscribe 모델을 지원합니다.
- RabbitMQ: 오픈 소스 메시지 브로커로 AMQP를 기반으로 하며, 유연한 메시지 전달을 위한 다양한 메시지 패턴과 프로토콜을 지원합니다.
- Apache ActiveMQ: 오픈 소스 메시지 브로커로 JMS를 구현하고, 클러스터링과 보안 등 다양한 기능을 제공하여 안정적인 메시징 시스템을 구축할 수 있습니다.
DDD가 무엇인가요?
DDD(Domain-Driven Design)는 도메인을 중심으로 소프트웨어를 설계하는 방법론으로, 비즈니스 도메인을 이해하고 모델링하여 유연하고 확장 가능한 소프트웨어를 구축합니다. 전문가 지식과 공통 언어를 활용하며, 복잡성을 다루고 도메인 영역과 서브시스템 간의 상호작용을 관리합니다.
캐시란 무엇인가요?
캐시는 데이터나 결과를 임시로 저장하여 액세스 시간을 단축시키는 저장소입니다. 주로 성능 향상과 응답 시간 단축을 위해 사용되며, 자주 액세스되는 데이터를 더 빠르게 제공하여 전체 시스템 성능을 향상시킵니다. 캐시는 하드웨어, 운영체제, 웹 애플리케이션 등 다양한 분야에서 활용됩니다.
어떤 데이터를 캐시하는 것이 best practice인가요?
Best practice로 캐시하는 데이터는 자주 액세스되는 데이터, 비용이 큰 데이터, 불변 데이터 등입니다. 이를 캐시에 저장하여 반복 액세스 시간을 단축시키고 성능을 향상시킬 수 있습니다. 캐시 일관성과 메모리 사용에 주의하여 데이터 갱신 및 메모리 관리를 수행해야 합니다.
'DevOps BootCamp > CS 면접' 카테고리의 다른 글
| 자주 물어보는 질문 (0) | 2023.07.26 |
|---|---|
| Kubernetes (0) | 2023.07.12 |
| Linux, DevOps (0) | 2023.07.10 |
| Docker, 네트워크 (0) | 2023.07.05 |
| CS 질문 (0) | 2023.07.05 |