워드프레스 KBoard 피드 https://cloud.syncrofusion.com/wp-content/plugins/kboard/rss.php 워드프레스 KBoard 피드 <![CDATA[SaaS 클라우드 솔루션에 대한 5개 인프라 조건 (Azure vs AWS)]]> SaaS 클라우드 솔루션에 대한 5개 인프라 조건 (Azure vs AWS)   이 White Paper는 Microsoft Azure 클라우드 솔루션에 대한 포괄적인 개요를 제공합니다. Azure는 기업의 디지털 변혁을 지원하고 비즈니스 성과를 극대화하기 위한 풍부한 기능과 서비스를 제공합니다. 이 문서에서는 Azure의 핵심 서비스 및 기능, 보안 및 규정 준수, 비용 효율성, 확장성 등에 대해 다룹니다. 또한 Azure가 제공하는 다양한 솔루션과 혁신적인 기술을 통해 기업이 비즈니스 성과를 달성하는 방법에 대해 설명합니다. AWS는 기업의 디지털 전환과 혁신을 위한 세계적인 클라우드 플랫폼으로, 다양한 기능과 서비스를 제공합니다. 이 문서에서는 AWS의 주요 서비스와 기능, 보안 및 규정 준수, 비용 효율성, 확장성 등에 대해 소개합니다. 또한 AWS가 제공하는 클라우드 솔루션을 통해 기업이 비즈니스 성과를 극대화하는 방법에 대해 다룹니다.   클라우드 솔루션에 대한 White Paper (Azure 버전)   물리적 보안(Azure 버전) Microsoft Azure는 글로벌 클라우드 서비스 제공업체로서, 높은 수준의 보안 및 규정 준수를 실현하기 위해 다양한 물리적 보안 요소를 제공합니다. 1.데이터 센터 보안: Microsoft Azure는 안전한 데이터 센터 인프라를 운영하여 고객 데이터를 보호합니다. 무단 접근을 방지하기 위해 생체 인식, 스마트 카드 등의 접근 제어 시스템을 채택하고 CCTV 등의 보안 시스템을 통해 데이터 센터를 모니터링합니다. 접근 제어 및 식별 인증: Microsoft Azure는 데이터 센터 접근을 엄격히 제어하기 위해 다중 요소 인증(MFA)과 Azure Active Directory를 활용하여 신뢰할 수 있는 사용자만이 데이터 센터에 접근할 수 있도록 보장합니다. 2.백업 및 복구 시설: Microsoft Azure는 지속적인 백업 및 복구 시설을 운영하여 재해 발생 시에도 데이터의 안전한 보관과 신속한 복구를 지원합니다. 이를 위해 지리적으로 분산된 데이터 센터를 활용하여 데이터의 손실을 최소화합니다. 3.물리적 환경 관리: Microsoft Azure는 데이터 센터 내 환경 요소를 지속적으로 모니터링하고 최적화하여 안전성과 안정성을 유지합니다. 온도, 습도, 전력 공급 등의 요소를 모니터링하고 신속하게 대응하여 데이터 센터 운영을 지원합니다. 4.물리적 네트워크 보안: Microsoft Azure는 데이터의 기밀성, 무결성 및 가용성을 보장하기 위해 물리적 네트워크 보안을 강화합니다. 방화벽, 네트워크 분리, 가상 사설 네트워크 등의 기술을 활용하여 데이터의 안전한 전송과 보호를 지원합니다. Microsoft Azure는 이러한 물리적 보안 조치를 통해 고객의 데이터를 안전하게 보호하고 규정 준수를 준수함으로써 신뢰할 수 있는 클라우드 솔루션을 제공합니다.   데이터 분리(Azure 버전) Microsoft Azure를 활용하여 데이터를 분리하는 것은 보안 및 규정 준수를 준수하는 데 있어서 핵심적인 요소입니다. 데이터 분리는 다양한 측면에서 보안 및 개인 정보 보호를 강화하고, 데이터의 무결성과 가용성을 유지하기 위해 중요한 역할을 합니다. 아래는 Microsoft Azure를 통한 데이터 분리의 핵심적인 측면입니다. 1.가상 네트워크(Virtual Network, VNet): Microsoft Azure의 가상 네트워크를 사용하면 고객은 자체 가상 네트워크를 설정하고 관리할 수 있습니다. 각 VNet은 논리적으로 분리되어 있어 다른 VNet 간의 네트워크 트래픽이 격리되며, 데이터 간의 침입을 방지하고 보안을 강화하는 데 중요한 역할을 합니다. 2.서브넷(Subnet) 분할: VNet 내에서 서브넷을 사용하여 데이터를 더욱 세분화하고 분리할 수 있습니다. 각 서브넷은 서로 다른 보안 요구 사항을 충족하기 위해 다른 네트워크 보안 그룹(NSG)을 적용하여 데이터를 분리하고 보호합니다. 3.네트워크 보안 그룹(Network Security Group, NSG) 및 네트워크 ACL: Microsoft Azure의 네트워크 보안 그룹과 네트워크 ACL을 사용하여 데이터 트래픽을 제어하고 필요한 경우 필터링할 수 있습니다. 이를 통해 데이터 간의 통신을 제한하고 민감한 데이터를 보호합니다. 4.Azure Active Directory 및 권한 관리: Azure Active Directory(AD)를 사용하여 데이터에 대한 액세스 권한을 세밀하게 관리할 수 있습니다. 데이터에 대한 접근 권한을 필요에 따라 부여하고 사용자 또는 역할별로 액세스를 제어하여 데이터의 무단 액세스를 방지합니다. 5.데이터 암호화: Microsoft Azure는 데이터 암호화를 위한 다양한 서비스를 제공합니다. Azure Disk Encryption을 사용하여 가상 머신 디스크를 암호화하거나, Azure Storage Service Encryption을 통해 데이터를 암호화하여 데이터의 기밀성을 보장하고 무단 액세스로부터 데이터를 보호합니다. 이러한 Microsoft Azure의 기능들을 통해 데이터를 효과적으로 분리하고 보호함으로써 고객은 민감한 정보를 안전하게 보관하고 규정 준수를 준수할 수 있습니다. Microsoft Azure는 데이터 분리를 위한 다양한 옵션을 제공하여 고객이 데이터 보안을 최대한 강화할 수 있도록 지원합니다.   데이터 백업(Azure 버전) Microsoft Azure를 활용한 데이터 백업은 클라우드 환경에서 데이터의 안전한 보관과 복구를 보장하는 핵심 요소입니다. 다음은 Microsoft Azure의 데이터 백업에 관한 주요 내용입니다. 1.Blob Storage를 활용한 안전한 저장: Microsoft Azure의 Blob Storage는 데이터를 안전하게 저장하는 데 널리 사용되는 서비스 중 하나입니다. Blob Storage는 데이터를 여러 지역에 복제하여 안정성과 내구성을 보장하며, 데이터의 무결성을 유지합니다. 또한 Blob Storage의 설정을 통해 데이터 암호화, 버전 관리 등의 기능을 활용하여 데이터 보안을 강화할 수 있습니다. 2.Azure Backup 서비스: Microsoft Azure는 Azure Backup 서비스를 통해 데이터 백업 프로세스를 간소화하고 자동화합니다. 이 서비스를 활용하면 다양한 Azure 서비스에서 데이터를 자동으로 백업할 수 있으며, 백업된 데이터를 쉽게 관리하고 복구할 수 있습니다. 또한 Azure Backup은 보안 및 규정 준수 요구 사항을 준수하여 데이터 보호를 강화합니다. 3.보안 및 규정 준수: Microsoft Azure는 데이터 보안과 규정 준수를 위한 다양한 기능을 제공합니다. 데이터 암호화, 엑세스 제어, 감사 로깅 등의 기능을 활용하여 데이터의 기밀성과 무결성을 보호하고 규정 준수 요구 사항을 준수합니다. 이러한 Microsoft Azure의 데이터 백업 기능은 클라우드 환경에서 데이터의 안전한 보관과 복구를 보장하여 비즈니스 연속성을 유지하고 데이터 손실로부터의 위험을 최소화합니다. Microsoft Azure의 다양한 백업 서비스 및 기능을 효과적으로 활용하여 데이터 관리 및 보호를 강화합니다.   재해 복구(Azure 버전) Microsoft Azure를 활용한 재해 복구는 비즈니스의 연속성을 유지하고 중요한 데이터와 시스템을 보호하는 데 중요한 역할을 합니다. 다음은 Microsoft Azure의 재해 복구에 관한 주요 내용입니다. 1.가용성 영역: Microsoft Azure는 다중 가용성 영역을 통해 재해에 대비하여 데이터와 애플리케이션을 복제하고 분산시킵니다. 이를 통해 한 가용성 영역에서 장애가 발생해도 다른 지역이나 가용성 영역에서 시스템을 계속해서 운영할 수 있습니다. 2.자동화된 복구 프로세스: Microsoft Azure는 자동화된 복구 프로세스를 통해 재해 복구 시간을 단축하고 오류 가능성을 줄입니다. 예를 들어, 인프라를 코드화하여 자동으로 복구하는 등의 기능을 제공합니다. 3.선별적 복구: Microsoft Azure는 필요한 데이터나 서비스만을 우선적으로 복구할 수 있는 선별적인 복구 기능을 제공합니다. 이를 통해 비즈니스의 핵심 기능을 빠르게 복구하고 중요한 데이터를 보호할 수 있습니다. 이러한 Microsoft Azure의 재해 복구 기능은 비즈니스의 연속성을 유지하고 중요한 시스템과 데이터를 보호하는 데 필수적입니다. Microsoft Azure의 다양한 서비스와 기능을 통해 조직은 재해에 대비하고 신속하게 복구할 수 있으며, 이는 비즈니스의 안정성과 신뢰성을 높이는 데 기여합니다.   퍼블릭 클라우드(Azure 버전) Microsoft Azure의 퍼블릭 클라우드를 통해 보안을 강화하는 것은 현대 기업이 안전한 데이터 관리와 보안 요구 사항을 충족시키는 데 중요한 전략입니다. Microsoft Azure는 고객이 안전한 클라우드 환경에서 비즈니스를 운영할 수 있도록 다양한 보안 기능과 서비스를 제공합니다. 1.Microsoft Azure의 다층 보안 모델: Microsoft Azure는 다층 보안 모델을 채택하여 네트워크, 인프라 및 애플리케이션 수준에서 보안을 강화합니다. 이 모델은 네트워크 보안 그룹, 가상 네트워크 등을 활용하여 외부 공격으로부터 시스템을 보호합니다. 2.강력한 암호화: Microsoft Azure는 데이터의 기밀성을 보호하기 위해 데이터를 저장 및 전송하는 과정에서 강력한 암호화를 적용합니다. Azure Disk Encryption과 같은 서비스를 통해 데이터 암호화를 제공하여 고객이 안전하게 데이터를 보관할 수 있도록 지원합니다. 3.권한 관리와 Azure Active Directory를 사용하여 사용자 및 그룹에 대한 액세스 권한을 정밀하게 관리할 수 있습니다. 이를 통해 사용자에게 필요한 최소한의 권한만 부여하여 무단 액세스를 방지합니다. 4.감사 및 모니터링: Microsoft Azure는 Azure Monitor, Azure Security Center와 같은 서비스를 통해 클라우드 환경에서의 액세스 및 활동을 감사하고 모니터링할 수 있습니다. 이를 통해 보안 사고를 조기에 감지하고 대응할 수 있습니다. 이러한 Microsoft Azure의 보안 기능과 서비스를 통해 고객은 안전하고 신뢰할 수 있는 퍼블릭 클라우드 환경에서 비즈니스를 운영할 수 있으며, 보안에 대한 우려를 해결할 수 있습니다.   물리적 보안(AWS 버전)   AWS(Amazon Web Services)는 세계적인 클라우드 컴퓨팅 서비스 제공 업체로, 높은 수준의 보안과 규정 준수를 제공합니다. 이를 위해 AWS는 다음과 같은 물리적 보안 요소를 갖추고 있습니다: 1.데이터 센터 보안: AWS는 안전하고 격리된 데이터 센터를 운영하여 고객의 데이터를 보호합니다. 무단 접근을 방지하기 위해 생체 인식, 스마트 카드 등의 접근 제어 시스템을 운영하며, CCTV 등을 통해 데이터 센터를 모니터링합니다. 2.접근 제어 및 식별 인증: AWS는 데이터 센터에 접근하기 위한 엄격한 접근 제어 및 식별 인증 절차를 시행합니다. 다중 인증 요소와 AWS IAM Identity Center을 활용하여 권한 관리를 강화하고, 신뢰할 수 있는 사용자만이 데이터 센터에 접근할 수 있도록 합니다. 3.백업 및 복구 시설: AWS는 데이터의 안전한 보관을 위해 백업 및 복구 시설을 운영합니다. 이를 통해 재해 발생 시에도 데이터의 손실을 최소화하고 고객의 데이터를 안전하게 보호합니다. 물리적 환경 관리: AWS는 데이터 센터 내부의 환경 요소를 지속적으로 모니터링하고 최적화하여 안전성과 안정성을 유지합니다. 온도, 습도, 전력 공급 등의 요소를 신속하게 감지하고 조정하여 데이터 센터의 운영을 지원합니다. 4.물리적 네트워크 보안: AWS는 데이터의 기밀성, 무결성 및 가용성을 보장하기 위해 물리적 네트워크 보안을 강화합니다. 방화벽, 네트워크 분리, 가상 사설 네트워크 등의 기술을 활용하여 데이터의 안전한 전송과 보호를 지원합니다. 이와 같은 물리적 보안 조치를 통해 AWS는 고객의 데이터를 안전하게 보호하고 규정 준수를 준수하며, 우리는 신뢰할 수 있는 클라우드 솔루션을 제공합니다.   데이터 분리(AWS 버전)   AWS(Amazon Web Services)를 사용하여 데이터를 분리하는 것은 보안 및 규정 준수를 준수하는 데 있어서 핵심적인 요소입니다. 데이터 분리는 다양한 측면에서 보안 및 개인 정보 보호를 강화하고, 데이터의 무결성과 가용성을 유지하기 위해 중요한 역할을 합니다. 아래는 AWS를 통한 데이터 분리의 핵심적인 측면입니다. 1.가상 사설 클라우드(VPC): AWS의 가상 사설 클라우드를 사용하면 고객은 자체 가상 네트워크를 설정하고 관리할 수 있습니다. 각 VPC는 논리적으로 분리되어 있어 다른 VPC 간의 네트워크 트래픽이 격리되며, 이는 데이터 간의 침입을 방지하고 보안을 강화하는 데 중요한 역할을 합니다. 2.서브넷(Subnet) 분할: VPC 내에서 서브넷을 사용하여 데이터를 더욱 세분화하고 분리할 수 있습니다. 각 서브넷은 서로 다른 보안 요구 사항을 충족하기 위해 다른 보안 그룹 을 적용하여 데이터를 분리하고 보호합니다. 3.보안 그룹(Security Groups) 및 네트워크 ACL: AWS 보안 그룹과 네트워크 ACL을 사용하여 데이터의 트래픽을 제어하고 필요한 경우 필터링할 수 있습니다. 이를 통해 데이터 간의 통신을 제한하고 민감한 데이터를 보호합니다. 4.AWS IAM Identity Center 및 권한 관리: AWS IAM Identity Center을 사용하여 데이터에 대한 액세스 권한을 세밀하게 제어할 수 있습니다. 데이터에 대한 접근 권한을 필요에 따라 부여하고, 사용자 또는 역할별로 액세스를 제어하여 데이터의 무단 액세스를 방지합니다. 5.데이터 암호화: AWS는 데이터 암호화를 위한 다양한 서비스를 제공합니다. S3 버킷 내의 데이터를 암호화하거나, EBS 볼륨에 대한 암호화를 설정하여 데이터의 기밀성을 보장하고, 무단 액세스로부터 데이터를 보호합니다. 이러한 AWS의 기능들을 통해 데이터를 효과적으로 분리하고 보호함으로써 고객은 민감한 정보를 안전하게 보관하고 규정 준수를 준수할 수 있습니다. AWS는 데이터 분리를 위한 다양한 옵션을 제공하여 고객이 데이터 보안을 최대한 강화할 수 있도록 지원합니다.   데이터 백업(AWS 버전)   AWS를 활용한 데이터 백업은 클라우드 환경에서 데이터의 안전한 보관과 복구를 보장하는 핵심 요소입니다. 다음은 AWS의 데이터 백업에 관한 주요 내용입니다. 1.S3 버킷을 활용한 안전한 저장: AWS의 S3(Simple Storage Service)는 데이터를 안전하게 저장하는 데 가장 널리 사용되는 서비스 중 하나입니다. S3 버킷은 데이터를 여러 가용 영역에 분산하여 안정성과 내구성을 보장하며, 데이터의 무결성을 유지합니다. 또한 버킷 설정을 통해 암호화, 버전 관리 등의 기능을 활용하여 데이터 보안을 강화합니다. 2.AWS Backup 서비스: AWS는 AWS Backup 서비스를 통해 데이터 백업 프로세스를 간소화하고 자동화합니다. 이 서비스를 활용하면 다양한 AWS 서비스에서 데이터를 자동으로 백업할 수 있으며, 백업된 데이터를 쉽게 관리하고 복구할 수 있습니다. 또한 AWS Backup은 보안 및 규정 준수 요구 사항을 준수하여 데이터 보호를 강화합니다. 3.보안 및 규정 준수: AWS는 데이터 보안과 규정 준수를 위한 다양한 기능을 제공합니다. 데이터 암호화, 접근 제어, 감사 로깅 등의 기능을 활용하여 데이터의 기밀성과 무결성을 보호하고 규정 준수 요구 사항을 준수합니다. 이러한 AWS의 데이터 백업 기능은 클라우드 환경에서 데이터의 안전한 보관과 복구를 보장하여 비즈니스 연속성을 유지하고 데이터 손실로부터의 위험을 최소화합니다. AWS의 다양한 백업 서비스 및 기능을 효과적으로 활용하여 데이터 관리 및 보호를 강화합니다.   재해 복구(AWS 버전)   AWS를 활용한 재해 복구는 비즈니스의 연속성을 유지하고 중요한 데이터와 시스템을 보호하는 데 중요한 역할을 합니다. 다음은 AWS의 재해 복구에 관한 주요 내용입니다. 1.다중 가용 영역: AWS는 다중 가용 영역을 통해 재해에 대비하여 데이터와 애플리케이션을 복제하고 분산시킵니다. 이를 통해 하나의 가용 영역에서 장애가 발생해도 다른 지역이나 가용 영역에서 시스템을 계속해서 운영합니다. 2.자동화된 복구 프로세스: AWS는 자동화된 복구 프로세스를 통해 재해 복구 시간을 단축하고 오류 가능성을 줄입니다. 예를 들어, IaC을 사용하여 인프라를 코드화하고 자동으로 복구합니다.  3.선별적 복구: AWS는 선별적인 복구를 통해 필요한 데이터나 서비스만을 우선적으로 복구할 수 있습니다. 예를 들어, Amazon RDS에서는 특정 데이터베이스를 대상으로 복구 작업을 수행합니다. 이를 통해 비즈니스의 핵심 기능을 빠르게 복구하고 중요한 데이터를 보호합니다. 이러한 AWS의 재해 복구 기능은 비즈니스의 연속성을 유지하고 중요한 시스템과 데이터를 보호하는 데 필수적입니다. AWS의 다양한 서비스와 기능을 통해 조직은 재해에 대비하고 신속하게 복구할 수 있으며, 이는 비즈니스의 안정성과 신뢰성을 높이는 데 기여합니다.   권한 부여(AWS 버전) AWS IAM Identity Center 을 활용한 권한 부여는 클라우드 환경에서 데이터 보호와 보안을 강화하는 핵심적인 요소입니다. 다음은 AWS IAM Identity Center 을 통한 권한 관리의 주요 내용입니다. 1.세분화된 권한 관리: AWS IAM Identity Center을 사용하면 세분화된 수준에서 사용자 및 그룹에 대한 권한을 관리합니다. 이를 통해 사용자마다 필요한 작업과 서비스에 대한 액세스를 정확히 제어할 수 있습니다. 예를 들어, 개발자는 개발 환경에만 접근할 수 있고, 운영팀은 운영 관련 작업에만 접근할 수 있도록 권한을 설정합니다. 2.원칙 최소 권한(Principle of Least Privilege): AWS IAM Identity Center 을 활용하여 원칙 최소 권한을 준수합니다. 이는 각 사용자 또는 그룹에게 필요한 최소한의 권한만 부여하여 데이터에 대한 무단 액세스를 방지하고 데이터의 안전성을 유지하는 데 도움이 됩니다. 3.다중 요인 인증(Multi-Factor Authentication, MFA): AWS IAM Identity Center 을 사용하여 다중 요인 인증을 강제화하여 보안을 강화할 수 있습니다. 이는 사용자가 액세스를 시도할 때 추가적인 인증 단계를 거쳐야 하므로, 무단 액세스를 방지하고 사용자 신원을 보호합니다. 4.관리형 정책 및 사용자 정의 정책: AWS IAM Identity Center을 사용하면 관리형 정책을 활용하여 일반적인 보안 요구 사항을 빠르게 적용할 수 있습니다. 또한 사용자 정의 정책을 생성하여 조직의 고유한 보안 정책을 구현합니다. 5.감사 로깅과 모니터링: AWS IAM Identity Center 을 통해 액세스 기록을 감사 로그에 기록하고, CloudWatch 및 AWS CloudTrail을 사용하여 사용자 활동을 모니터링할 수 있습니다. 이를 통해 액세스 패턴을 분석하고 보안 이슈를 탐지하여 대응합니다. 이러한 방법들을 통해 AWS IAM을 활용하여 권한 부여를 효과적으로 관리하고, 데이터의 무단 액세스를 방지하여 클라우드 환경에서 데이터 보호와 보안을 강화합니다.   퍼블릭 클라우드(AWS 버전) AWS의 퍼블릭 클라우드를 통해 보안을 강화하는 것은 현대 기업이 안전한 데이터 관리와 보안 요구 사항을 충족시키는 데 중요한 전략입니다. AWS는 고객이 안전한 클라우드 환경에서 비즈니스를 운영할 수 있도록 다양한 보안 기능과 서비스를 제공합니다. 1.AWS의 다층 보안 모델: AWS는 다층 보안 모델을 채택하여 네트워크, 인프라 및 애플리케이션 수준에서 보안을 강화합니다. 이 모델은, 가상 사설 네트워크, 보안 그룹 등을 통해 외부 공격으로부터 시스템을 보호합니다. 2.강력한 암호화: AWS는 데이터의 기밀성을 보호하기 위해 데이터를 저장 및 전송하는 과정에서 강력한 암호화를 적용합니다. S3 데이터를 포함한 다양한 AWS 서비스에서 데이터 암호화를 제공하여 고객이 안전하게 데이터를 보관할 수 있도록 지원합니다. 3.권한 관리와 AWS IAM Identity Center을 사용하여 사용자 및 그룹에 대한 액세스 권한을 정밀하게 관리할 수 있습니다. 이를 통해 사용자에게 필요한 최소한의 권한만 부여하여 무단 액세스를 방지합니다. 4.감사 및 모니터링: AWS는 CloudWatch, CloudTrail과 같은 서비스를 통해 클라우드 환경에서의 액세스 및 활동을 감사하고 모니터링할 수 있습니다. 이를 통해 보안 사고를 조기에 감지하고 대응합니다. 이러한 AWS의 보안 기능과 서비스를 통해 고객은 안전하고 신뢰할 수 있는 퍼블릭 클라우드 환경에서 비즈니스를 운영할 수 있으며, 보안에 대한 우려를 해결합니다.   결론 Azure와 AWS를 사용하여 클라우드 솔루션 SaaS 서비스를 제공하는 측면에서 물리적 보안, 데이터 분리, 데이터 백업, 재해 복구, 퍼블릭 클라우드 측면에서의 장점과 단점을 비교할 수 있습니다. Azure 및 AWS 모두 전 세계적으로 분산된 데이터 센터를 보유하고 있으며, 엄격한 보안 및 접근 제어를 시행하여 물리적 침입으로부터 데이터를 보호합니다. 두 플랫폼 모두 ISO, SOC 및 PCI DSS와 같은 규정 준수를 준수하여 데이터 센터 수준의 보안을 보장합니다. 그러나 물리적 보안은 고객이 직접 제어할 수 없으므로 이러한 제어권 부재로 인한 신뢰 문제가 발생할 수 있습니다. Azure 및 AWS 모두 VPC(Virtual Private Cloud)와 같은 가상 네트워크를 통해 데이터를 분리하고 격리할 수 있습니다. 서브넷, 보안 그룹 등을 통해 세밀한 데이터 분리 및 보호를 제공합니다. 올바른 구성이 필요하며, 잘못된 설정은 데이터 노출 가능성을 야기할 수 있습니다. 두 플랫폼 모두 자동화된 백업 서비스를 제공하여 데이터 손실을 최소화하고 비즈니스 연속성을 보장합니다. 다중 리전 복제 및 버전 관리를 통해 데이터의 안정성과 가용성을 강화합니다. 그러나 추가 비용이 발생할 수 있으며, 잘못된 구성으로 인해 데이터 손실 가능성이 있습니다. AWS 및 Azure 모두 다중 가용 영역 및 리전을 활용하여 재해 시스템의 연속성을 보장합니다. 자동화된 복구 프로세스를 통해 복구 시간을 최소화합니다. 그러나 데이터 센터 간의 복제 및 복구 프로세스가 복잡할 수 있으며, 추가 비용이 발생할 수 있습니다. 높은 확장성과 유연성을 제공하여 사용자는 필요할 때 리소스를 증가 또는 축소할 수 있습니다. 더 낮은 초기 비용과 유연한 요금 체계를 제공합니다. 그러나 보안 문제로 인한 우려가 있을 수 있으며, 고정된 네트워크 대역폭에 따른 제약이 있을 수 있습니다. 결론적으로, Azure와 AWS는 클라우드 솔루션 SaaS 서비스를 제공하는 데 있어서 많은 유사한 기능을 제공합니다. 그러나 내부적으로는 다르게 작동할 수 있지만 고객은 두 플랫폼 중 하나를 선택하여 안전하고 안정적인 클라우드 환경에서 비즈니스를 운영할 수 있습니다. 따라서 두 플랫폼은 큰 관점에서는 비슷한 방식으로 클라우드 솔루션을 제공하지만 내부적으로는 다른 방식을 채택합니다.  ]]> Tue, 26 Mar 2024 14:53:28 +0000 서버 설계 <![CDATA[Azure Cloud service(클래식)에 대한 회고]]> Reflections on retirement of azure cloud service(Classic) Azure Cloud service에 대한 회고 Azure Cloud Service retirement Announcemet. https://azure.microsoft.com/ko-kr/updates/cloud-services-classic-retirement-announcement-feb2024/?WT.mc_id=AZ-MVP-5002667   Azure Cloud 서비스(클레식)에 대한 업데이트를 보고 시간이 많이 흘렀음을 인지했습니다. 이서비스가 이제 퇴역한다고 합니다. 아직도 Azure Cloud 서비스(클레식)를 누군가 쓰고 있고 이를 지원이 되고 있었구나 라는 생각이 들었습니다. 예전 클라우드 서비스의 첫 포털은 AWS에 익숙한 필자에겐 매우 UI 적이며 파격적이었습니다.그러나 이 서비스는 2010년, Microsoft가 Azure Cloud 서비스를 선보인 지 어느덧 10년이 넘은 세월이 흘렀습니다. 그 당시 클라우드 컴퓨팅은 기업들에게 새로운 가능성을 제시했고, Azure는 그 첨단 기술과 혁신적인 아이디어로 이를 이끌었습니다. 그러나 이렇게 혁신적인 아이디어라도 당시에는 클라우드 컴퓨팅이란 개념 자체가 여전히 생소했습니다. 더구나, Platform as a Service(PaaS) 중심의 서비스는 더욱 그렇게 느껴졌습니다. Azure가 처음 출시되었을 때, 이는 단순히 하드웨어나 인프라를 제공하는 것을 넘어, 애플리케이션을 구축하고 배포하며 관리할 수 있는 전용 플랫폼을 제공했습니다. 이는 당시에는 매우 진보된 개념으로 다가왔습니다. 그러나 그 혁신적인 아이디어에도 불구하고, Azure의 도입은 많은 기업들에게는 길고 어려운 여정이었습니다. 그들은 기존의 데이터 센터 시스템을 유지하면서도 클라우드의 장점을 활용하는 방법에 대해 많은 고민을 해야 했습니다. 그리고 2015년, Azure가 한국에 진출하였습니다. 이는 당시에는 그저 새로운 클라우드 서비스의 등장이라고만 생각했지만, 나중에는 이것이 우리의 비즈니스에 큰 전환을 가져올 것임을 깨달았습니다. 당시에는 Infrastructure as a Service(IaaS) 중심의 서비스가 주를 이뤘고, PaaS 중심의 서비스는 아직까지는 그 활용도가 제한적으로 느껴졌습니다. 그러나 Microsoft는 한국 시장에 PaaS의 가치를 알리고 확산시키는 데 열정적으로 노력했습니다. 이러한 과거의 역사를 돌아보면서, 나는 우리가 얼마나 빠르게 변화하고 적응할 수 있는지를 느낄 수 있습니다. 그리고 이 변화의 한 시점은 바로 Azure Resource Manager(ARM)이 도입된 시기입니다. 이는 Microsoft가 PaaS 중심의 Azure Cloud 서비스가 기존의 대규모 변경과 함께 AWS와의 대규모 경쟁에서 실패한 경험을 극복하고자, 전체 서비스를 ARM 기반으로 업그레이드한 시점입니다. 이 결정은 우리에게 더욱 강력하고 유연한 인프라를 제공할 수 있게 하였으며, 이는 클라우드 컴퓨팅의 발전을 촉진하는 중요한 단계였습니다. 이를 통해 우리는 Azure가 기술적 혁신 뿐만 아니라 비즈니스 전략의 중요성을 인지하고 있음을 알 수 있습니다. Azure는 지속적으로 변화하고 성장하여 고객들에게 더 나은 서비스를 제공하기 위해 노력하고 있으며, 이는 우리의 디지털 세상을 더 나은 방향으로 이끌어 나가는 데 큰 역할을 하고 있습니다.   Azure Resource Manager(ARM)의 도입은 Microsoft에 있어서 엄청난 전환점이었습니다. 이는 당시 Azure 클래식 서비스를 퇴역시키고, 새로운 통합형 관리 및 배포 모델을 도입하는 것을 의미했습니다. 그리고 이러한 결정은 그 어느 때보다도 고난과 역경의 시기였습니다. 많은 이들이 Azure 클래식 서비스의 UI에 익숙해져 있었고, 이에 대한 업데이트는 처음에는 혼란과 불만을 일으켰습니다. 더구나, Azure가 AWS와의 경쟁에서 실패한 경험을 겪은 후에 이런 대규모 변경은 더욱 중요한 결정이었습니다. 그리고 이에 따른 고객들의 반응은 예상보다 훨씬 더 격렬했습니다. 하지만 Microsoft는 이러한 도전에 뒤쳐지지 않았습니다. 그들은 Azure의 성공을 위해 필요한 것은 무엇이든 감수하고, 클라우드 컴퓨팅의 미래를 위해 끊임없이 노력했습니다. ARM의 도입은 그들의 열정과 헌신의 결정적인 증거였습니다. ARM은 이전의 클래식 서비스 모델에서의 제한을 극복하기 위한 획기적인 시도였습니다. 이제 사용자들은 리소스를 논리적으로 그룹화하고 템플릿을 사용하여 리소스를 정의하고 배포할 수 있었습니다. 이는 개발자들에게는 더 큰 유연성과 편의성을 제공했으며, 관리자들에게는 더 효율적인 리소스 관리를 가능케 했습니다. ARM의 도입은 많은 어려움을 겪었지만, 그 결과는 더 큰 성공을 가져왔습니다. Microsoft는 이를 통해 Azure를 더욱 강력하고 효율적인 클라우드 플랫폼으로 만들었으며, 이는 전 세계적인 사용자들에게 큰 혜택을 주었습니다. 이러한 경험은 우리에게 두려움과 실패의 중요성을 깨달았으며, 동시에 역경을 극복하고 혁신적인 아이디어를 실현시킬 수 있는 힘을 보여주었습니다. ARM의 도입은 단순히 기술적인 측면뿐만 아니라 조직의 문화와 비전에 대한 결정적인 영향을 끼쳤습니다. 이는 Microsoft의 역량과 결단력을 보여주는 중요한 사례였습니다.   결론 지난 몇 년간, Microsoft의 제품 이름 통합 및 변경은 우리에게 수많은 변화를 가져왔습니다. 이러한 과정은 때로는 혼란스러울 수 있었지만, 기존의 제품을 보다 효율적으로 통합하고 발전시키기 위한 중요한 단계였습니다. 그러나 이러한 과정에서 파격적이고 혁신적인 요소가 줄어들고 있음을 인지하면서 아쉬움이 남습니다. 특히 ARM 도입과 같은 이전의 파격적인 결정은 기술적 혁신과 비즈니스 전략의 중요성을 다시 한번 강조해 주었습니다. DevOps 엔지니어로서, 저는 수많은 제품과 기술 혁신을 경험해 왔습니다. 그러나 최근의 업데이트가 기대에 미치지 못하는 것은 아쉬운 점입니다. AI 시대에는 기존의 제품 뿐만 아니라 새로운 기술과 제품도 더 많은 변화와 혁신이 일어날 것을 기대합니다. 이는 우리가 더욱 효율적이고 지능적인 솔루션을 개발하고, 더 나은 디지털 세상을 만들어 나갈 수 있도록 도와줄 것입니다. Microsoft와 같은 기업들은 끊임없는 혁신과 변화를 통해 우리의 디지털 시대를 이끌어 나가고 있습니다. 우리는 이러한 변화에 개방적이고 적응하며, 더 나은 미래를 위해 계속해서 전진해 나갈 것입니다. AI 시대에는 이러한 혁신과 발전이 더욱 가속화될 것이며, 우리는 그 변화의 중심에 서서 함께 성장하고 발전할 것입니다. 예전에 Microsoft Ignite 가 돌아오면 인프라 부분의 업데이트를 recap 만 읽는데도 오래 걸렸지만 지금은 예전보다 1/5수준으로 낮아지고 AI 부분으로 늘어난 것은 시대의 흐름인 듯 합니다.]]> Tue, 05 Mar 2024 10:43:51 +0000 서버 설계 <![CDATA[Azure network 암호화 기능 업데이트]]> What is Azure Virtual Network encryption? - Azure Virtual Network | Microsoft Learn 이번에 Azure 에서 새로운 업데이트가 나왔습니다. 요즘 추세에 맞게 보안을 강화하고 있는 Azure  트랜드 답게 이런 보안 업데이트는 AWS와 매우 차별성 있는 세계관을 Azure 에서 생성하고 있습니다.현대 비즈니스 환경에서 기업들은 더 많은 데이터를 수집, 저장 및 공유하며 클라우드 서비스의 이용이 증가함에 따라 정보 보안은 이전보다 더 중요한 주제로 떠오르고 있습니다. 특히, 클라우드 기술과 서비스의 발전으로 인해 기업들은 그들의 데이터를 안전하게 보호하고 관리하는 방법을 고민하고 있습니다. Azure, Microsoft의 클라우드 플랫폼,는 이러한 보안 요구를 충족시키기 위해 다양한 기능과 서비스를 제공하고 있습니다.그 중에서도 네트워크 보안은 기업의 IT 인프라에서 핵심적인 부분을 차지하며, 데이터의 안전한 이동과 저장을 보장합니다. 이에 따라 Azure에서는 네트워크 트래픽을 안전하게 보호하기 위한 다양한 암호화 기술을 제공하고 있습니다. Azure 네트워크 암호화의 필요성: 데이터 기밀성 보장: 기업은 민감한 정보를 안전하게 전송하고 저장해야 합니다. Azure 네트워크 암호화는 데이터를 암호화하여 무단 접근을 방지하고 기밀성을 유지합니다. 최신 보안 표준 준수: Azure는 국제적인 보안 표준 및 규정을 준수하고 있습니다. 따라서 Azure에서 제공하는 네트워크 암호화 기술을 사용함으로써 기업은 최신 보안 표준을 준수할 수 있습니다. 클라우드 환경에서의 안전한 데이터 이동: 기업들은 클라우드 환경에서 데이터를 안전하게 이동시켜야 합니다. Azure의 네트워크 암호화는 클라우드 네트워크 환경에서 안전한 데이터 이동을 가능하게 합니다. Azure에서 제공하는 네트워크 암호화 기술:   Azure Virtual Network 암호화 : Azure Virtual Networks의 핵심 기능 중 하나로, 이를 통해 가상 머신 간의 트래픽이 안전하게 전송됩니다. 이 기능은 Microsoft가 IEEE 802.1AE MACsec(MAC Security) 표준을 사용하여 데이터 링크 계층에서 암호화를 수행함으로써 보안성을 제공합니다. 특히, 이 암호화는 데이터 센터 간에 Azure 고객 트래픽이 이동할 때 적용되며, 물리적 경계를 넘어서 Microsoft 또는 Microsoft를 위임하지 않은 환경에서 발생하는 트래픽을 보호합니다. 가상 네트워크 암호화는 네트워크 하드웨어 전반의 지점 간에 적용되어 가상 머신 및 가상 머신 스케일 세트 간의 트래픽을 효과적으로 암호화합니다. 또한, 지역적으로 피어링된 가상 네트워크와 전역적으로 피어링된 가상 네트워크 간의 트래픽까지도 암호화합니다. 이는 Azure의 기존 전송 중 암호화 기능을 향상시켜 기업들이 클라우드 환경에서의 데이터 보안을 높일 수 있도록 도와줍니다. 이러한 가상 네트워크 암호화 기능은 Azure 고객이 자사의 가상 네트워크에서 데이터를 안전하게 전송하고 저장할 수 있도록 돕는 중요한 도구 중 하나입니다. Azure의 기술적인 혁신은 보안과 성능을 겸비하여 클라우드 환경에서의 비즈니스 요구 사항을 충족시키며, 가상 네트워크 암호화는 이러한 기능 중 하나로 안전한 데이터 통신을 실현합니다.   VPN(Virtual Private Network) 암호화: Azure VPN은 인터넷을 통해 연결되는 여러 지점 간의 통신을 안전하게 만들기 위해 암호화 기술을 사용합니다. 이를 통해 기업은 분산된 지점 간의 안전한 통신을 구축할 수 있습니다. Azure Disk 암호화: Azure Disk 암호화는 가상 머신의 디스크를 암호화하여 데이터의 안전성을 확보합니다. 이는 데이터 유출을 방지하고 중요한 비즈니스 정보를 보호하는 데 중요한 역할을 합니다. Azure Firewall 및 Network Security Groups(NSG): Azure에서 제공하는 방화벽 및 네트워크 보안 그룹은 네트워크 트래픽을 감시하고 필요한 경우 암호화를 통해 보안을 강화합니다.   결론 암호화를 적용하면 일반적으로 레이턴시가 올라 갑니다. 그러나 클라우드는 기존의 온프레미스보다 훨씬 위험에 노출이 쉽게 되어 있습니다. 보안을 그래서 필수라고 할수 있습니다. 만약 방화벽이나 앞단이 완벽하게 되어 있다면 제 개인 의견으로는 네트워크 내부에서 보안 암호화는 해제 해서 레이턴시를 더 빠르게 하는 것이 맞다고 생각합니다. 그러나 실제적으로 방화벽 구성이 없다거나, 방화벽 우회해서 스포크가 오픈되어 있는 일부 서비스등에는 이 기술이 꼭 필요합니다. HIPAA, ISO, GDPR와 같은 보안 인증을 따르는 것은 현대 기업에게 매우 중요한 책임입니다. 이러한 규정과 인증은 개인 정보 보호와 데이터 보안에 대한 엄격한 기준을 제시하며, 이를 준수함으로써 고객 신뢰를 유지하고 법적 책임을 충실히 수행할 수 있습니다. 이러한 규정을 따르기 위해서는 다양한 보안 기술을 종합적으로 적용해야 합니다. Azure의 네트워크 암호화 기술은 데이터 기밀성을 확보하고 최신 보안 표준을 준수하는 데 필수적입니다. 또한, VPN 암호화, Azure Disk 암호화, 그리고 Azure Firewall과 Network Security Groups(NSG)와 같은 기술은 네트워크 통신과 데이터 저장소에서의 보안을 강화하는 데 기여합니다. 더불어, 보안 규정을 준수하기 위해서는 강력한 접근 제어, 감사 로깅, 모니터링 및 위협 인지 기능 등과 같은 추가적인 보안 조치가 필요합니다. 이러한 다층적이고 종합적인 보안 전략을 통해 기업은 규정 및 인증을 준수하면서 고객의 개인 정보를 안전하게 관리할 수 있습니다. 최종적으로, Azure의 다양한 보안 기능과 서비스는 기업이 HIPAA, ISO, GDPR와 같은 규정을 적극적으로 따를 수 있도록 지원하고 있습니다. 이를 통해 기업은 클라우드 환경에서 안전한 데이터 관리와 고객 신뢰를 구축하며, 동시에 전 세계적인 개인 정보 보호 요구 사항을 충족시킬 수 있습니다.]]> Sat, 20 Jan 2024 18:51:46 +0000 Azure 클라우드 <![CDATA[Azure Trusted launch VM]]> 클라우드 컴퓨팅은 현대 기업 및 기관들이 데이터를 저장하고 처리하는 데에 있어서 혁명적인 변화를 가져왔습니다. 그러나 이러한 혜택을 누리기 위해서는 보안과 신뢰성에 대한 새로운 도전에 대응할 필요가 있습니다. 특히, 가상 머신은 클라우드 환경에서 주요한 역할을 수행하고 있으며, 이러한 가상 머신이 안전하게 운영되고 관리되어야 합니다. Azure Trusted VM은 Microsoft Azure 클라우드 플랫폼에서 제공되는 고급 보안 기능 중 하나로, 가상 머신 환경에서의 신뢰성과 보안을 강화하는 데 중점을 둔 기술입니다. 이 기술은 기업 및 기관들이 민감한 데이터와 비즈니스 애플리케이션을 안전하게 실행하고 보호하기 위한 강력한 보안 수단을 제공합니다. Azure Trusted VM은 다양한 신뢰성 기능을 포함하고 있습니다. 예를 들어, 하이퍼바이저 수준에서의 강력한 보안 기능을 통해 가상 머신 간의 격리를 강화하고, 신뢰할 수 있는 부팅 메커니즘을 제공하여 악의적인 변경으로부터 시스템을 보호합니다. 또한, 신뢰할 수 있는 인증 및 액세스 제어를 통해 사용자 및 자원에 대한 엄격한 보안 정책을 적용할 수 있도록 지원합니다. Azure Trusted VM의 핵심 기능과 이점에 대해 자세히 살펴보겠습니다. 높은 수준의 신뢰성과 보안이 요구되는 비즈니스 환경에서 Azure Trusted VM은 어떻게 혜택을 제공하며, 클라우드 환경에서 안전한 가상 머신 운영을 위한 핵심 도구로 어떻게 떠오르고 있는지에 대해 다룰 것입니다.   기존에 trusted vm 은 2세대 VM 에서만 적용이 되었는습니다. 그러나 현재 Private Preview로 업데이트 됐습니다. 이에 따라 기존의 VM 들도 적용할수 있을것으로 보입니다. 여러가지 제약 사항이 있었는데 점점 제약 사항도 없어질듯 합니다. Private Preview: Upgrade existing Azure Gen1 VMs to Gen2-Trusted launch | Azure 업데이트 | Microsoft Azure 제가 먼저 하기 그림001처럼 신청해서 해보았습니다. azure그림001 장점 Azure Trusted VM은 다양한 기술적 기능과 전략을 결합하여 클라우드 환경에서의 가상 머신 보안과 신뢰성을 강화합니다. 이러한 강점들은 기업 및 기관들이 민감한 데이터와 업무 애플리케이션을 안전하게 운영하고 보호할 수 있도록 지원합니다. 1.하이퍼바이저 수준의 격리 및 보안 강화: Azure Trusted VM은 하이퍼바이저 수준에서의 강력한 보안 기능을 제공하여 가상 머신 간의 격리를 강화합니다. 이는 가상 머신들 간의 보안 경계를 확립하고, 악의적인 공격으로부터 시스템을 보호하는 역할을 합니다. 이를 통해 가상 머신 간의 상호 작용이 안전하게 이루어지면서도 성능 손실을 최소화합니다. 2.신뢰할 수 있는 부팅 메커니즘: Trusted VM은 부팅 과정에서의 신뢰성을 강조하고, 악의적인 변경으로부터 시스템을 보호하는데 중점을 둡니다. 안전한 부팅 절차를 통해 가상 머신이 안정적으로 기동되며, 부팅 과정에서의 보안 위협에 대한 방어를 제공합니다. 3.신뢰할 수 있는 인증 및 엑세스 제어: Azure Trusted VM은 사용자 및 자원에 대한 엄격한 보안 정책을 적용하기 위한 신뢰할 수 있는 인증 및 엑세스 제어 기능을 제공합니다. 이를 통해 민감한 데이터에 대한 접근을 제한하고, 권한이 없는 사용자로부터의 보안 위협을 방지할 수 있습니다. 4.가상 네트워크 보안 강화: 클라우드 환경에서의 가상 네트워크 보안은 매우 중요합니다. Trusted VM은 네트워크 트래픽을 감시하고 통제하여 보안 정책을 준수하도록 도와줍니다. 또한, 가상 네트워크 간의 안전한 통신을 촉진하여 데이터 이동 시의 보안 문제를 해결합니다. 5.최신 보안 업데이트 및 컴플라이언스 지원: Azure Trusted VM은 최신 보안 업데이트를 지속적으로 제공하며, 규제 및 규정 준수를 촉진하는데 기여합니다. 이는 기업이 새로운 보안 위협에 대응하고, 산업 표준을 준수하는 데에 도움이 됩니다. 6.성능 최적화 및 확장성: Trusted VM은 안전성을 강화하면서도 성능 최적화에 중점을 둡니다. 이는 안전한 환경에서도 높은 성능을 유지하면서 비즈니스 애플리케이션을 운영할 수 있게 해줍니다. 또한, 확장성을 갖추어 기업의 변화하는 요구에 대응할 수 있도록 지원합니다. 이러한 다양한 장점들을 통해 Azure Trusted VM은 클라우드 환경에서의 가상 머신 보안을 새로운 수준으로 끌어올리며, 기업들이 안전하게 클라우드 리소스를 활용할 수 있도록 지원합니다. 7.보안 부팅 보안부팅이 가능해서 루트킷 부팅키트에 멀웨어 설치가 불가능합니다. 8.vTPM 가능 VM에 자체 전용 TPM 인스턴스를 제공하여 VM의 손이 닿지 않는 보안 환경에서 실행됩니다 9.Microsoft Defender 통합 신뢰할 수 있는 시작은 클라우드용 Microsoft Defender와 통합되어 VM이 제대로 구성되었는지 확인합니다.    단점 Azure Trusted VM은 강력한 보안 및 신뢰성 기능을 제공하지만, 몇 가지 단점과 고려해야 할 측면도 있습니다. 이러한 단점들을 살펴보면 다음과 같습니다: 1.복잡성과 학습 곡선: Trusted VM은 고급 보안 기능을 많이 포함하고 있어 구성 및 관리가 복잡할 수 있습니다. 새로 도입하는 조직에서는 이러한 기능들을 올바르게 설정하고 관리하기 위한 학습 곡선이 필요할 수 있습니다. 2.비용 증가: 고급 보안 기능은 추가 비용이 발생할 수 있습니다. Trusted VM을 사용하면 일반적인 가상 머신에 비해 추가적인 비용이 들 수 있으며, 이는 일부 기업에게는 부담이 될 수 있습니다. 3.일부 성능 손실: Trusted VM은 보안을 강화하기 위해 일부 성능 최적화를 포기할 수 있습니다. 따라서 특히 성능에 중점을 둔 애플리케이션을 실행하는 환경에서는 일부 성능 손실이 발생할 수 있습니다. 4.호환성 문제: 일부 응용 프로그램 및 시스템에서는 Trusted VM의 일부 기능이 호환되지 않을 수 있습니다. 특히 특정 소프트웨어나 라이브러리의 요구 사항이 있는 경우 호환성 문제가 발생할 수 있습니다. 유지보수 및 업데이트 어려움: 5.고급 보안 기능을 갖춘 시스템은 유지보수 및 업데이트가 어려울 수 있습니다. 신규 버전이나 보안 업데이트를 적용하는 과정에서 시스템의 다운타임이 발생할 수 있고, 이는 비즈니스 운영에 영향을 미칠 수 있습니다. 6.리소스 사용 증가: Trusted VM은 일부 고급 보안 기능을 수행하기 위해 추가 리소스를 사용할 수 있습니다. 따라서 특히 자원이 제한된 환경에서는 이러한 리소스 사용 증가가 중요한 고려 요소가 될 수 있습니다. 7.호환성 문제: 일부 응용 프로그램 및 시스템에서는 Trusted VM의 일부 기능이 호환되지 않을 수 있습니다. 특히 특정 소프트웨어나 라이브러리의 요구 사항이 있는 경우 호환성 문제가 발생할 수 있습니다. 8.현재 지원되지 않는 기능 Azure Site Recovery 는 아직 사용 할수 없습니다.  관리되는 이미지는 아직 미지원 ( Azure Gallery를 사용해야함) 중첩된 가상화를 전체 사용할수 없습니다.(대부분의 v5 VM 크기 패밀리가 지원됨) 2세대 VM 만 사용 가능   이러한 단점들은 특정 조직이나 프로젝트의 요구에 따라 다르게 평가될 수 있으며, 이러한 측면들을 고려하여 Azure Trusted VM을 도입할 때는 신중한 검토가 필요합니다.   결론 결론적으로, Azure Trusted VM은 고급 보안 기능을 제공하여 클라우드 환경에서의 가상 머신 보안을 강화하는 데 중요한 역할을 합니다. 그러나 이러한 강력한 기능들과 함께 몇 가지 고려해야 할 단점들도 존재합니다. 따라서 기업이나 기관이 Azure Trusted VM을 도입할 때에는 장단점을 균형 있게 고려하고 신중한 계획을 수립해야 합니다. Azure Trusted VM의 강점 중 하나는 하이퍼바이저 수준에서의 격리와 보안을 강화하여 가상 머신 간의 신뢰성을 높이는 데에 있습니다. 이로써 기업은 민감한 데이터와 비즈니스 애플리케이션을 안전하게 운영할 수 있습니다. 또한, 신뢰할 수 있는 부팅 메커니즘과 엄격한 인증 및 액세스 제어를 통해 보안 정책을 강화하고 데이터 접근을 통제할 수 있습니다. 그러나 이러한 강점들과 함께, Azure Trusted VM의 도입은 몇 가지 단점과 고려해야 할 사항이 있습니다. 복잡성과 학습 곡선, 추가 비용 부담, 일부 성능 손실, 호환성 문제 등은 실제 도입 전에 고려해야 할 중요한 측면입니다. 또한, 보안 업데이트와 유지보수 과정에서 발생할 수 있는 어려움도 고려해야 합니다. 따라서 Azure Trusted VM을 선택하고 도입하는 기업은 강력한 보안 기능과 단점을 고려하여 전략을 수립해야 합니다. 비즈니스 요구에 따라 최적의 보안 솔루션을 선택하고, 유연하게 조정하여 클라우드 환경에서 안전하고 효율적으로 운영할 수 있도록 해야 합니다. Azure Trusted VM은 클라우드 보안을 강화하는 강력한 도구로서 기업들에게 새로운 가능성을 제시하고 있지만, 이를 최대한 활용하기 위해서는 신중한 계획과 실행이 필요합니다.  ]]> Fri, 19 Jan 2024 17:42:14 +0000 Azure 클라우드 <![CDATA[Azure 가상머신 복구지점 (Azure vm restore points)]]> Azure VM Restore Point   Azure 가상머신 복구 포인트  2022년 7월에 해당 기능이 GA된 이후에 저는 일반적으로 이런 기능은 PaaS 제품에만 있는 기능인데 가상머신까지 이 기능이 나오는 것을 보고 매우 고무적이라고 생각했습니다. IaaS 와 PaaS의 경계선이 점점 없어지는것이라 생각했으나 AWS 의 경우는 이런 흐름이 보이지 않았지만 Azure 경우는 이런 흐름이 이 기능이 이외에서 점점 늘어나고 있습니다. 클라우드 컴퓨팅은 현대 기업과 조직에게 엄청난 유연성과 효율성을 제공합니다. 그 중 하나가 Azure Virtual Machines(가상 머신)을 이용한 데이터 관리 및 보안입니다. Azure VM은 중요한 데이터를 안전하게 보호하고, 장애나 오류 시에도 복원할 수 있는 기능을 제공하는데, 그 중요한 기능 중 하나가 복원 지점입니다. 복원 지점은 데이터의 안정성과 회복력을 보장하는 핵심적인 도구로서, Azure VM의 효율적인 관리와 데이터 복구에 필수적입니다. 이를 통해 사용자는 예상치 못한 데이터 손실로부터 보호되며, 시스템 장애 시에도 빠르게 복구할 수 있습니다. Azure의 VM 복원 지점은 일정한 간격으로 스냅샷을 찍어 중요한 데이터와 설정을 저장합니다. 이를 통해 사용자는 이전의 안정적인 상태로 시스템을 복원하거나 복구할 수 있습니다. 이러한 스냅샷은 가상 머신의 상태를 정기적으로 기록하여 데이터 손실을 최소화하고 업무 중단을 방지합니다. 이와 같은 기능을 통해 Azure VM의 복원 지점은 비즈니스 연속성을 유지하고 데이터 관리를 보다 안전하게 유지하는 데 큰 도움을 줍니다. 이를 통해 사용자는 데이터 손실 및 장애로부터의 복구를 빠르게 진행할 수 있으며, 중요한 비즈니스 작업을 지속할 수 있습니다. azure그림001 1.그림001은 복구 포인트의 구조를 보여줍니다. 기본적으로 Restore Collection 이라는 복구 모듬이란 이름으로 제품이 구성됩니다. 가장 상단에 큰 껍데기는 이 Collection 모듬이며 이 모듬의 하위계층은 VM 포인트와 VM 의 하위 구조인 Disk 복구 포인트로 구성됩니다.  그러므로 가장 먼저 Azure Portal 안에서는 복구 모듬을 만들어야 합니다. 해당 방법을 스크린샷으로 보여주면서 설명하겠습니다. azure그림002 2.그림002 에서 보는 것 처럼 해당 리전을 선택하면 연결 가능한 소스 가상머신리스트를 볼수 있습니다. https://learn.microsoft.com/en-us/azure/virtual-machines/virtual-machines-create-restore-points 링크에서 보면 제한 사항이 잘 나와있으므로 제한된 울트라 디스크 이런거는 리스트에 올라 오지 않습니다. azure그림003 3.그림003을 보면 OS Disk 와 DataDisk 까지 컬랙션 생성과 동시에 최초 리스토어 포인트가 생성이 됩니다. azure그림004 4.그림004처럼 리스토어 컬렉션에 리스토어 포인트 빨간 박스 부분이 생성되어 있습니다. +생성 복원지점 을 클릭을 하면 다시 추가적으로 생성하는 블래이드가 나옵니다. azure그림005 5. 그림005는 +버튼을 누르면 생성되며 이번2023년 12월에 업데이트 된 Consistency mode가 현재는 비활성화 되었지만 이부분을 신청하면 사용할 수 있을것으로 보이면 현재는 제가 신청중입니다.  아직 포털에서는 사용할 수 없다는 Product Team 에 답변을 받았습니다. 곧 업데이트 되기를 기대 해봅니다. azure그림006 6. 그림006에서는 현재 가상머신에 연결된 디스크를 보여주며 선택을 할수 있습니다. azure그림007 7. 선택을 하고 나면 2번째 리스토어 포인트가 보입니다. azure그림008 8.해당 리스토어 포인트를 선택하면 빨간색 박스처럼 복원지점에서 가상머신을 생성할수 있는 페이지로 이동하고 복원지점에 가상머신을 만들수 있습니다.   장점: 1.데이터 보호 및 안전성: 복원 지점을 통해 데이터는 일정한 간격으로 백업되어 저장되므로 2.시스템 장애나 데이터 손실 시에 안전하게 복구할 수 있습니다. 3.빠른 시스템 회복: 스냅샷을 이용하면 이전의 상태로 빠르게 시스템을 회복할 수 있어 업무 중단을 최소화할 수 있습니다. 4.유연성과 효율성: 필요한 시점으로 시스템을 복원할 수 있으므로 비즈니스 요구에 따라 유연하게 데이터를 관리할 수 있습니다. 5.간편한 관리: 자동화된 백업 프로세스로 복원 지점을 관리하기 용이합니다. 단점: 1.저장 공간과 비용: 많은 양의 스냅샷이 저장되면 저장 공간과 비용이 증가할 수 있습니다. 2.주기적 백업의 필요성: 지속적인 백업이 이루어져야만 최신 데이터를 보존할 수 있어 관리와 유지에 노력이 필요합니다. 주기적 백업은 Azure Backup으로 설정해서 커버할 수 있습니다. 3.복구 시간과 지연: 큰 규모의 시스템에서는 스냅샷을 복구하는 데 시간이 걸릴 수 있고, 이는 업무 중단으로 이어질 수 있습니다. 이러한 장단점을 고려하여, 복원 지점을 효과적으로 활용하려면 적절한 백업 주기와 저장 정책을 설정하고, 비즈니스 요구사항에 맞게 데이터 관리 전략을 수립하는 것이 중요합니다. 결론 AWS 에서는 없는 Azure 에서 장점이 점점 작은 부분에서 많이 생기는 부분은 매우 고무적이며 이것이 Microsoft의 큰 그림으로 가는 작은 그림의 하나로 생각하고 있습니다. 복원 지점은 현대 클라우드 환경에서 데이터 관리와 보안을 강화하는 데 중요한 수단입니다. 그러나 장점과 함께 고려해야 할 몇 가지 단점도 존재합니다. 장점으로는 데이터의 안전한 보호와 빠른 시스템 회복을 강조할 수 있습니다. 이를 통해 업무 연속성을 유지하고 중요한 데이터 손실을 방지할 수 있습니다. 또한, 유연성과 효율성을 향상시켜 비즈니스 요구에 맞춰 데이터를 관리할 수 있습니다. 하지만 저장 공간과 비용 문제, 주기적 백업의 필요성, 복구 지연 등의 단점도 염두에 두어야 합니다. 이러한 단점을 극복하기 위해서는 적절한 백업 정책과 데이터 관리 전략을 마련하고, 비즈니스 목표에 부합하는 방식으로 복원 지점을 활용해야 합니다. 결과적으로, 복원 지점은 클라우드 환경에서 데이터 손실로부터 보호받을 수 있는 필수적인 도구이며, 적절한 관리와 전략 수립을 통해 그 효과를 극대화할 수 있습니다. 비즈니스 연속성과 데이터 보안을 고려할 때, 복원 지점은 중요한 요소로 자리매김하고 있습니다.
]]> Thu, 28 Dec 2023 14:05:53 +0000 Azure 클라우드 <![CDATA[Intel TDX를 활용한 Azure의 기밀 가상 머신: 보안의 새로운 차원]]> Intel TDX를 활용한 Azure의 기밀 가상 머신: 보안의 새로운 차원 이번에 intel TDX 기술을 활용한 Azure “기밀(confidential)” 가상머신이 Preview 로 나왔습니다. https://azure.microsoft.com/ko-kr/updates/public-preview-intel-tdx-based-confidential-vms-now-available-in-the-azure-portal-azure-cli-and-arm-templates/?WT.mc_id=AZ-MVP-5002667 근래에 Microsoft 는 기존의 인프라에 대한 한단계 높은 보안이 아닌 전체적으로 모든 부분에서 보안을 강화화기 위한 방법으로 다양한 제로트러스트 보안을 내새우고 있습니다. 그 방법 중에 하나로 Azure 기밀(confidential) 가상머신이 새로 Preview 로 나왔습니다. 기존의 Trusted launch 가상머신과 차이점도 알아보면서 요즘 가장 핫한 보안 이슈를 보도록 하겠습니다.    Azure는 기업들이 클라우드 환경에서 안전하고 신뢰할 수 있는 인프라를 구축하는 데 중요한 역할을 합니다. 이제 Intel TDX의 혁신적인 보안 기능이 Azure 가상 머신에서 제공되면서 클라우드 보안에 새로운 차원이 부여되었습니다. 이 기술은 기밀성이 요구되는 민감한 데이터와 작업 부하를 보호하기 위해 설계되었습니다. 이 글은 Intel TDX가 Azure 가상 머신에서 어떻게 활용되고 있는지에 대해 알아보려합니다. Intel TDX는 하드웨어 기반의 보안 메커니즘으로, 가상 머신 간에 격리된 신뢰 구역을 설정하여 데이터 유출 및 보안 위협으로부터의 강력한 방어를 제공합니다. Azure의 Confidential VMs를 통해 이러한 보안성이 제공되며, 클라우드 환경에서의 기밀성과 신뢰성을 높여줍니다. 이 글에서는 Intel TDX의 핵심 원리와 Azure Confidential VM, 이로 인해 얻는 보안 이점, 그리고 기업들이 이러한 기술을 채택함으로써 어떻게 민감한 데이터를 보호하고 클라우드 환경에서의 신뢰성을 향상시킬 수 있는지에 대해 탐구합니다. Azure의 Intel TDX를 기반으로 하는 Confidential VMs는 보다 안전한 클라우드 경험을 제공함으로써 기업들에게 혁신적인 보안 솔루션을 제공합니다.   Intel TDX Intel의 Total Memory Encryption (TME)과 관련된 기술 중 하나인 Intel TDX (Trust Domain Extensions)는 기밀성이 매우 중요한 가상 환경을 위한 보안 솔루션입니다. 이 기술은 CPU에 내장된 하드웨어 기반 보안 매커니즘으로, 기밀성이 높은 가상 머신(VM)을 보호하는 데 사용됩니다. 이를 통해 민감한 데이터를 안전하게 처리하고 저장할 수 있습니다. TDX는 CPU의 보안 기능을 확장하여 가상 머신 사이의 격리를 강화하고 보안 위협으로부터 시스템을 보호합니다. 특히, Intel TDX를 활용하는 Confidential VMs는 클라우드 환경에서 중요한 역할을 합니다. 이 VM은 메모리 내용을 암호화하여 가상 머신 간에 노출되는 정보를 최소화하고, 높은 수준의 보안성을 제공합니다. 이것은 데이터 유출과 같은 보안 위협으로부터 클라우드 환경의 민감한 작업 부하를 보호하는 데 도움이 됩니다. azure그림001 그림001은 인텔 공식문서에서 가져온 그림입니다.   인텔 Trust Domain Extensions (TDX)는 기존 SGX 기술을 뛰어넘어 VMX(가상화 확장) 기능을 확장하여, 신뢰할 수 없는 하이퍼바이저 환경에서도 하드웨어의 지원을 통해 VM을 안전하게 실행하고, VMM과 다른 도메인으로부터 분리하여 작동할 수 있도록 하는 기술입니다. 이를 위해 Intel TDX는 Trust Domain이라고 불리는 보호 도메인을 활용합니다. 이 도메인은 기밀성, 무결성, 메모리 변환 무결성, CPU 상태의 기밀성 및 무결성, 안전한 인터럽트 전달, 그리고 원격 증명(Attestation) 등을 제공하여 보호합니다. 인텔 TDX는 소프트웨어 및 하드웨어 기반의 대부분의 공격으로부터 시스템을 보호할 수 있지만, 플랫폼의 메모리를 직접 캡처하는 등의 물리적인 공격 방법에 대해서는 방어하기 어려운 한계가 있습니다. 이러한 한계를 갖고 있음에도 불구하고, 인텔 TDX는 기밀성과 보안성을 강화하며 신뢰할 수 있는 가상 환경을 제공하여 다양한 보안 위협으로부터 시스템을 보호하는 데 기여합니다. 소프트웨어가 TD내부에서 충분한 Security체크를 통해서 돌아간다는 것을 클라우드 플랫폼 이용자에게 전달하기 위한 외부 인증 기법(Remote attestation)을 Intel TDX는 제공하고 있습니다.   Azure 기밀 가상머신 선택 azure그림002 그림002 처럼 Azure Portal에서 프리뷰이므로 현재는 East US2 등등에서 만 선택 가능합니다. 또한 이미지도 small disk 로 된 윈도우 2019만 선택 가능하며 DCedsv5-series 나 ECedsv5-series 처럼 C라는 문자가 들어간 타입만 선택할수 있습니다. azure그림003 그림003 은 Portal에서 가상머신을 선택할때 3가지 타입의 보안타입을 이제 선택할 수 있습니다.   TDX의 단점은?  1.물리적 공격에 취약: TDX는 하드웨어 수준에서 가상 머신 간에 격리를 제공하지만, 물리적인 공격으로부터 완전히 보호하지는 못합니다.  플랫폼의 메모리를 직접 캡쳐하는 메모리 스니핑이나 플랫폼 레벨에서의 물리적 접근과 같은 물리적 공격은 TDX가 해결하기 어려운 부분입니다. 2.하드웨어 요구 사항과 호환성: TDX를 사용하려면 특정 하드웨어 지원이 필요하며, 이는 모든 시스템이나 플랫폼에서 사용 가능하지 않을 수 있습니다. 또한 이 기술을 활용하기 위해서는 하드웨어 및 소프트웨어 측면에서의 호환성을 고려해야 합니다. 성능 영향: 하드웨어 기반의 보안 기술은 종종 일부 성능 영향을 초래할 수 있습니다. TDX도 예외는 아니며, 가상 머신 간의 격리와 보안을 위해 추가적인 작업을 수행하므로 성능에 약간의 영향을 미칠 수 있습니다. 3.복잡성과 구현 난이도: 하드웨어 기반의 보안 기술은 구현이 복잡하고, 관리와 유지보수에 있어서도 더 많은 노력과 전문 지식을 요구합니다. 이로 인해 초기 설정과 관리가 어려울 수 있습니다. 4.최신 기술의 적용 속도: 하드웨어 기반의 보안 기술은 시스템 업데이트나 최신 기술 적용에 따른 시간 지연이 발생할 수 있습니다. 이로 인해 최신 보안 취약점에 대한 대응이 다소 느릴 수 있습니다. 이러한 단점들은 TDX의 보안성을 제한하지만, 여전히 많은 보안 위협으로부터 시스템을 보호하는 데 효과적인 수단으로 인정되고 있습니다.   Trusted Launch 와 Confidential VMs 차이   Trusted Launch와 Confidential VMs는 모두 보안을 강화하기 위한 기술이지만, 목적과 기능에서 약간의 차이가 있습니다. Trusted Launch (신뢰할 수 있는 부팅): 이 기술은 시스템이 부팅될 때부터 시작하여 플랫폼의 신뢰성을 보장하는 데 중점을 둡니다. Trusted Launch는 하드웨어 루트 신뢰성 기반의 부팅 프로세스를 보장하여 시스템의 각 구성 요소가 신뢰할 수 있는지를 확인합니다. 이를 통해 BIOS 또는 펌웨어로부터 OS와 애플리케이션의 실행까지 연결된 모든 단계에서 시스템의 무결성을 보호합니다. Confidential VMs (기밀 가상 머신): 이는 클라우드 환경에서 민감한 데이터를 보호하기 위한 것으로, Intel TDX와 같은 하드웨어 기반의 기술을 사용하여 가상 머신 간에 격리된 보안 영역을 생성합니다. Confidential VMs는 메모리 내용을 암호화하여 민감한 정보가 노출되는 것을 방지하고, 클라우드 환경에서의 데이터 보안을 강화합니다. Trusted Launch는 하드웨어와 플랫폼 레벨에서의 신뢰성을 강화하는 데 초점을 맞추고, Confidential VMs는 클라우드에서 가상 머신 간 보안을 강화하여 민감한 데이터를 보호하는 데 주력합니다. 둘 다 하드웨어 보안을 기반으로 하지만 다른 측면의 보안을 강화하는 데 사용됩니다.   AWS Nitro Enclaves 와 Azure TDX 기밀 컴퓨팅 차이   AWS Nitro Enclaves와 Azure TDX는 클라우드 환경에서 보안을 강화하기 위한 기술이지만, 약간의 차이가 있습니다. AWS Nitro Enclaves: 이는 AWS의 Nitro 가상화 기술을 기반으로 하는 솔루션으로, 가상 머신 내부에 격리된 안전한 환경(Enclave)을 생성합니다. 이 Enclave는 민감한 데이터나 보안 감시가 필요한 워크로드를 안전하게 실행할 수 있도록 해주는데, 이러한 Enclaves는 완벽히 격리되어 있어 해당 가상 머신의 다른 부분과 분리되어 있습니다. 데이터 처리를 위한 격리된 환경을 제공하여 외부에서의 접근을 방지하고 보안성을 높입니다.   Azure TDX (Trust Domain Extensions): 이는 Intel의 하드웨어 기반의 기술로, 기밀성이 요구되는 가상 머신 간에 격리된 보안 영역을 생성합니다. 이것은 메모리 내용을 암호화하여 데이터 노출을 방지하고, 클라우드 환경에서의 민감한 작업 부하를 보호합니다. Azure의 Confidential VMs를 통해 TDX를 활용하여 데이터 보호 및 격리를 강화합니다.   주요한 차이점 중 하나는 Nitro Enclaves가 특정 AWS 인프라에서 실행되는 반면, Azure TDX는 Intel의 하드웨어 기반으로 작동하며 Azure의 Confidential VMs와 같이 사용됩니다. 둘 다 보안을 강화하기 위해 하드웨어 기반의 격리와 보호를 제공하지만, 구현 방식과 특정한 클라우드 서비스와의 통합에서 차이가 있습니다. Azure 기밀 가상머신과 보안 규제 법 Intel TDX를 기반으로 하는 Azure의 기밀 가상 머신은 GDPR 및 HIPAA와 같은 규정 및 규제 준수를 강화하는 데 도움이 될 수 있습니다. GDPR(일반 개인정보 보호법): 데이터 보호: 기밀 가상 머신은 메모리 내용을 암호화하여 민감한 정보의 노출을 방지하고, 데이터에 대한 엄격한 접근 제어를 제공합니다. 이는 GDPR에서 요구하는 개인 데이터 보호에 부합하며, 데이터 노출 위험을 줄일 수 있습니다. 기술적 보호조치: Intel TDX는 하드웨어 기반의 보호 수준을 높여 안전한 데이터 처리 환경을 제공하여 GDPR에서 요구하는 적절한 보호 조치를 충족시킬 수 있습니다. HIPAA(건강보험 이동성과 책임법): 개인 건강 정보 보호: 기밀 가상 머신은 민감한 건강 정보를 안전하게 저장하고 처리할 수 있는 환경을 제공합니다. 이를 통해 HIPAA 규정에서 요구하는 개인 건강 정보 보호에 부합할 수 있습니다. 데이터 암호화 및 보안성: Intel TDX는 데이터의 기밀성을 유지하기 위해 메모리 암호화를 제공하며, 민감한 건강 정보에 대한 액세스 제어를 강화하여 HIPAA에서 요구하는 보안성을 강화합니다. 이러한 기술적 보안 조치는 GDPR 및 HIPAA와 같은 규정 준수를 위한 한 부분일 뿐입니다. 따라서 조직은 여전히 데이터 처리 및 관리 과정에서 적절한 정책 및 절차를 시행하여 전반적인 규정 준수를 보장해야 합니다.   결론  Intel TDX를 기반으로 하는 Azure의 기밀 가상 머신은 뛰어난 보안성을 제공합니다. 이 기술은 하드웨어 기반의 보호 도메인을 활용하여 기밀성, 무결성, 메모리 변환 무결성, CPU 상태의 기밀성 및 무결성, 안전한 인터럽트 전달, 그리고 원격 증명과 같은 다양한 보안 측면을 강화합니다. 기밀 가상 머신은 클라우드 환경에서 민감한 데이터를 보호하기 위해 메모리 내용을 암호화하고, 격리된 보안 영역을 구축하여 가상 머신 간에 안전한 환경을 제공합니다. 이는 클라우드에서 작동하는 비즈니스에 중요한 역할을 합니다. 민감한 정보를 안전하게 보호하고 클라우드 환경의 신뢰성을 향상시키는 데 기여하여 보안적으로 더욱 강력한 솔루션을 제공합니다. 그러나 물리적 공격과 같은 일부 공격 형태에 대한 완벽한 방어를 제공하지는 않을 수 있습니다. 이러한 한계를 고려하더라도, Intel TDX를 활용한 기밀 가상 머신은 클라우드 환경에서의 데이터 보호와 보안을 강화하는 데 중요한 역할을 하며, 신뢰할 수 있는 환경을 구축하는 데 큰 도움이 됩니다.   Reference 프리뷰 https://azure.microsoft.com/ko-kr/updates/public-preview-intel-tdx-based-confidential-vms-now-available-in-the-azure-portal-azure-cli-and-arm-templates/?WT.mc_id=AZ-MVP-5002667 DCesv5 및 DCedsv5 시리즈 기밀 VM https://learn.microsoft.com/en-us/azure/virtual-machines/dcesv5-dcedsv5-series?WT.mc_id=AZ-MVP-5002667 다자간 컴퓨팅 아키텍처 설계 https://learn.microsoft.com/en-us/azure/architecture/guide/blockchain/multiparty-compute?WT.mc_id=AZ-MVP-5002667 TDX 란https://junhoahn.kr//noriwiki/index.php/Trust_domain_extensions#:~:text=10%20References-,%EA%B0%9C%EC%9A%94,%EC%88%98%20%EC%9E%88%EB%8F%84%EB%A1%9D%20%ED%95%98%EB%8A%94%20%EA%B8%B0%EC%88%A0%EC%9D%B4%EB%8B%A4. 인텔 TDX https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html Azure trusted Launch vm https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch?WT.mc_id=AZ-MVP-5002667?WT.mc_id=AZ-MVP-5002667  ]]> Mon, 18 Dec 2023 15:03:47 +0000 서버 설계 <![CDATA[AKS 백업]]> General Availability - Azure Backup for AKS | Azure updates | Microsoft Azure   Azure Kubernetes Service(AKS)는 Microsoft Azure에서 제공하는 관리형 Kubernetes 서비스로, 개발자 및 운영팀이 컨테이너화된 애플리케이션을 손쉽게 배포, 확장 및 관리할 수 있도록 지원합니다. AKS를 사용하는 조직은 높은 가용성, 확장성, 보안 및 간편한 관리를 통해 현대적인 애플리케이션을 구축할 수 있습니다. AKS에서 실행 중인 애플리케이션과 데이터의 안전한 보호 및 관리를 위해 AKS 백업이 도입되었습니다. 경쟁사의 AWS 는 이 기능이 없으므로 더 돋보이는 기능입니다. 이는 클러스터의 상태와 애플리케이션 데이터를 예약된 백업을 통해 저장하고, 필요한 경우에 이를 복원할 수 있는 클라우드 네이티브한 프로세스를 제공합니다. 이 백업 솔루션은 CSI 드라이버 기반 Azure Disk Storage의 영구 볼륨을 활용하여 클러스터의 데이터를 안전하게 저장하고 관리합니다. AKS 백업은 여러 측면에서 강력한 기능을 제공합니다. 먼저, 백업은 Blob 컨테이너 및 디스크 스냅샷을 활용하여 로컬로 저장됩니다. 이는 데이터의 안전한 보호를 보장하면서도 필요 시 빠르고 효율적인 복원을 가능케 합니다. 더불어, 백업은 세분화된 컨트롤을 제공하여 특정 네임스페이스나 전체 클러스터를 대상으로 한 백업 및 복원을 선택할 수 있습니다. 이는 운영 복구, 개발자 및 테스트 환경 복제, 그리고 클러스터 업그레이드 시나리오와 같은 다양한 엔드투엔드 시나리오에서 활용할 수 있습니다. 뿐만 아니라, AKS 백업은 Azure의 Backup 센터와 통합되어 대규모 백업을 효과적으로 제어, 모니터링, 운영 및 분석할 수 있는 단일 보기를 제공합니다. 이는 대규모 환경에서도 백업 관리를 간편하게 할 수 있도록 도와줍니다. 마지막으로, AKS 백업은 Azure Portal의 AKS 인스턴스에 대한 리소스 메뉴에서 직관적으로 설정할 수 있습니다. 이를 통해 사용자는 사용자 친화적인 인터페이스를 통해 백업 구성을 관리하고 모니터링할 수 있습니다. 이와 같이 AKS 백업은 AKS 클러스터에서 실행되는 애플리케이션과 데이터를 안전하게 보호하고, 효과적으로 관리할 수 있는 강력한 도구로서, 운영 신뢰성과 개발자 경험을 향상시키는 데 기여하고 있습니다.   AKS 백업은 AKS 클러스터에 배포된 워크로드와 해당 클러스터의 영구 볼륨을 안전하게 보호하고, 필요한 경우에는 원활한 복원을 가능케 하는 중요한 기능을 제공합니다. 이를 위해 AKS 클러스터에서는 Backup 확장을 설치하고, 이를 통해 통신하는 Backup 자격 증명 모음을 구성해야 합니다. 아래는 AKS 백업이 어떻게 동작하는지 상세하게 설명한 내용입니다. 1.Backup 확장 설치: AKS 클러스터에는 백업 확장을 설치해야 합니다. 이 확장은 클러스터 내에서 백업 및 복원과 관련된 작업을 수행합니다. Backup 확장은 AKS 클러스터의 노드 풀에 설치되며, 각 노드에서 백업 및 복원 작업을 조율합니다. 2.Backup 자격 증명 모음 구성: 백업 확장과 통신하기 위해 AKS 클러스터 내에 Backup 자격 증명 모음을 구성해야 합니다. 이 모음에는 백업이 저장될 Blob 컨테이너와 관련된 정보들이 포함됩니다. 또한, 해당 Backup 자격 증명 모음은 AKS 클러스터의 리소스 그룹에 사용자 ID(확장 ID)를 생성하고, 이 ID에 Storage 계정 기여자 역할을 할당합니다. 3.스토리지 계정 및 Blob 컨테이너 설정: AKS 백업을 구성할 때, 백업 데이터가 저장될 스토리지 계정과 Blob 컨테이너에 대한 값을 추가합니다. 이는 백업된 데이터를 안전하게 저장하고 필요한 경우에는 복원할 수 있도록 합니다. 4.신뢰할 수 있는 액세스 설정: AKS 클러스터와 Backup 자격 증명 모음 간에는 신뢰할 수 있는 액세스를 설정해야 합니다. 이는 클러스터의 신뢰성 있는 액세스를 보장하여 백업 작업을 위해 할당된 특정 권한 덕분에 Backup 자격 증명 모음이 AKS 클러스터에 안전하게 액세스할 수 있도록 합니다. 5.클러스터의 IP 기반 액세스 관리: AKS 백업은 공용, 프라이빗 및 권한 있는 IP 기반 클러스터를 지원하려면 클러스터와 Backup 자격 증명 모음 간에 신뢰할 수 있는 액세스를 활용해야 합니다. 이를 통해 특정 IP 주소 또는 IP 범위를 신뢰하도록 설정하여 보안을 강화하고, 백업 작업을 위한 안전한 통신을 보장합니다. 이와 같은 구성을 통해 AKS 백업은 신속하고 안전한 방식으로 클러스터의 워크로드 및 데이터를 보호하며, 필요한 경우에는 신속하게 복원할 수 있는 강력한 솔루션으로 작동합니다. 이러한 백업 및 복원 프로세스는 운영 복구, 개발자/테스트 환경 복제, 클러스터 업그레이드 등 다양한 시나리오에 대응하여 AKS 클러스터의 안정성과 신뢰성을 높이는 데 기여합니다.   단점 1.현재 Azure Backup은 CSI 드라이버 기반 Azure Disk Storage에서 영구 볼륨만 지원합니다. 백업하는 동안 솔루션은 Azure 파일 공유 및 Blob과 같은 다른 영구 볼륨 유형을 건너뜁니다. 또한 영구 볼륨의 크기가 1TB보다 작거나 같은 경우 백업을 자격 증명 모음으로 이동할 수 있습니다. 2.백업 또는 복원하려는 Backup 자격 증명 모음 및 AKS 클러스터는 동일한 지역 및 구독에 있어야 합니다. 3.Backup 자격 증명 모음 스토리지 중복 설정(LRS/GRS)은 자격 증명 모음 계층에 저장된 백업에만 적용됩니다. 재해 복구에 백업을 사용하려면 지역 간 복원을 사용하도록 설정된 GRS로 스토리지 중복성을 설정합니다.   결론 AKS 백업은 AKS 클러스터에서 애플리케이션 및 데이터를 안전하게 보호하고, 필요할 때 효과적으로 복원할 수 있는 강력한 기능을 제공합니다. 그러나 이러한 솔루션에는 몇 가지 고려해야 할 단점이 존재합니다. 첫째로, 백업 확장 설치 및 구성은 초기 설정에 시간과 노력이 필요한 작업입니다. 특히, 사용자 ID 및 권한 설정과 같은 보안 구성은 정확하게 수행되어야 하며, 이는 사용자들에게 높은 수준의 기술적 지식과 주의가 필요하다는 점입니다. 초기 설정에 오류가 발생하면 백업 및 복원 프로세스의 안정성에 영향을 미칠 수 있습니다. 둘째로, 백업 작업이 실행되는 동안 클러스터의 성능에 영향을 미칠 수 있습니다. 특히, 대규모 애플리케이션 및 데이터의 경우, 백업 작업이 실행되는 동안 리소스 사용량이 증가할 수 있어서 다른 워크로드에 영향을 줄 수 있습니다. 이는 프로덕션 환경에서의 백업 스케줄링에 대한 신중한 계획이 필요하다는 것을 의미합니다. 또한, 백업 데이터의 저장 및 관리에는 추가적인 비용이 발생할 수 있습니다. 특히, Blob 컨테이너 및 스토리지 계정의 사용량에 따라 비용이 발생하게 되므로, 이를 고려하여 예산을 계획해야 합니다. 마지막으로, 백업 및 복원 프로세스는 전반적으로 기술적인 복잡성을 동반합니다. 클러스터의 변화나 업그레이드와 관련된 상황에서 예상치 못한 문제가 발생할 수 있습니다. 이에 대비하기 위해서는 정기적인 테스트 및 갱신이 필요하며, 이는 팀 내에서 별도의 시간과 리소스를 필요로 합니다. 결론적으로, AKS 백업은 강력한 기능을 제공하지만, 설정과 관리에 따른 복잡성 및 초기 설정에 소요되는 노력, 성능 영향, 추가 비용 부담 등을 고려해야 합니다. 이러한 단점을 극복하면서도 안정성과 신뢰성을 유지하기 위해서는 명확한 계획과 지속적인 관리가 필요합니다.]]> Sat, 25 Nov 2023 20:25:08 +0000 Azure 클라우드 <![CDATA[Azure Firewall vs AWS Firewall 의 비교]]> Azure Firewall vs AWS Firewall 의 비교 AWS가 2020년 11월에 Network Firewall을 발표한 직후, 2021년 2월부터 공개 미리 보기로 제공되는 프리미엄 방화벽 제품과 함께 Azure가 출시되었습니다. 가장 큰 2개의 클라우드 회사가 NGFWaaS 제품을 내놓은지 이제 3년 됬으며 초기의 품질에서 3년간의 변화로 인해 클라우드 네이티브 제품으로 과연 이젠 어떤지 비교해 봅시다. 클라우드 컴퓨팅은 현대 기업이 비즈니스 운영에 필요한 IT 인프라를 제공하는 데 있어서 혁신적인 변화를 가져왔습니다. 이러한 클라우드 플랫폼은 기업들이 더욱 효율적이고 유연하게 자원을 활용하고 관리할 수 있도록 지원하며, 그 중에서도 Microsoft Azure와 Amazon Web Services (AWS)는 가장 널리 사용되는 클라우드 서비스 중 하나로 꼽힙니다. 그러나 클라우드 환경에서는 보안이 중요한 이슈로 부상하게 되었고, 이에 대응하기 위한 다양한 보안 서비스가 제공되고 있습니다. 그 중에서도 클라우드 네트워크 보안의 핵심 요소로 꼽히는 것이 바로 네트워크 방화벽(Firewall)입니다. 이 서론에서는 Microsoft Azure와 AWS의 각각의 클라우드 환경에서 제공되는 방화벽 서비스, 즉 Azure Firewall과 AWS Firewall 서비스를 비교해보고자 합니다.    Azure Firewall과 AWS Firewall은 각각의 클라우드 플랫폼에서 제공되는 네트워크 보안 서비스로, 이 두 서비스는 기업들이 클라우드 네트워크를 안전하게 관리하고 보호할 수 있도록 지원합니다. 각각의 특징과 기능, 그리고 장단점을 비교하여 어떤 상황에서 어떤 서비스를 선택해야 하는지에 대해 알아보겠습니다. 클라우드 환경에서의 방화벽 서비스인 Microsoft Azure Firewall과 AWS Firewall을 비교하는 동시에, 전통적인 방화벽 솔루션으로 알려진 Palo Alto Networks나 F5와의 비교도 빠짐없이 고려해야 합니다. 전통적인 방화벽 솔루션과 클라우드 네이티브 방화벽 사이에는 기능, 관리, 유연성 등 다양한 측면에서 차이가 있으며, 기업은 자체적인 요구사항과 환경에 적합한 솔루션을 선택해야 합니다.   전통적인 방화벽 솔루션 (Palo Alto Networks, F5 등)의 장점: 우선 전통 방화벽 솔루션들은 온프레미스 시절부터 다양한 기능과 제어로 이미 시장을 선점한 제품들이 많이 있습니다. 클라우드에서도 이런 제품들은 온프레미스처럼 그대로 사용할수 있습니다. 1.폭넓은 기능과 정책 제어: 전통적인 방화벽 솔루션은 고급 보안 기능과 정책 제어를 제공하여 더욱 세밀한 보안 설정이 가능합니다. 2.다양한 배포 옵션: 전통적인 솔루션들은 클라우드 내부뿐만 아니라 온프레미스 환경에서도 사용 가능하며, 하이브리드 환경에서 유연한 배포가 가능합니다. 3.심층적인 트래픽 분석: 일반적으로 전통적인 솔루션들은 심층적인 트래픽 분석을 수행하여 정교한 보안 정책을 적용할 수 있습니다. 4.멀티 클라우드이고 온프레미스 방화벽도 있고 이 모든 방화벽 간에 보안 정책을 동기화해야 하는 경우 단일 솔루션을 사용하지 않는 한 어려움을 겪을 것입니다   Azure Firewall의 장점: 1.클라우드 네이티브 통합: Azure Firewall은 Microsoft Azure 플랫폼에 특화된 클라우드 네이티브 서비스로, Azure의 다양한 기능과 서비스와의 원활한 통합을 제공합니다. 이는 네트워크 보안 정책을 설정하고 관리하는 데 편의성을 제공하며, 클라우드 리소스 간의 통신을 쉽게 모니터링할 수 있도록 합니다. 2.스케일링 및 유연성: Azure Firewall은 신속한 스케일링을 통해 트래픽 증가에 대응할 수 있습니다. Azure의 자동화 및 유연한 확장 기능을 활용하여 필요에 따라 인프라를 조정하고 비용을 효율적으로 관리할 수 있습니다. 3.보안 인텔리전스 기능: Azure Firewall은 고급 보안 기능과 함께 풍부한 보안 인텔리전스를 제공하여 현대적인 위협에 대응할 수 있습니다. Microsoft의 보안 서비스와 연동하여 향상된 탐지 및 대응 기능을 활용할 수 있습니다. 4.간편한 관리 및 모니터링: Azure Portal을 통한 직관적인 사용자 인터페이스와 Azure Monitor와 통합된 로깅 및 모니터링 기능을 통해 운영 팀은 효율적으로 방화벽 정책을 관리하고 시스템 상태를 감시할 수 있습니다. 5.애플리케이션 수준의 정책 제어: Azure Firewall은 FQDN (Fully Qualified Domain Name) 기반의 애플리케이션 레벨의 정책을 통해 미리 정의된 애플리케이션 그룹에 대한 트래픽을 제어할 수 있습니다. 6.AWS 대비 방화벽이 가격 정책이 3가지로 나누어져 있습니다. Basic , Standard, Premium   AWS Firewall의 장점: 1.네이티브 AWS 서비스 통합: AWS Firewall은 Amazon Web Services의 다양한 서비스와 원활하게 통합되어 클라우드 환경에서의 보안 정책을 쉽게 관리할 수 있도록 지원합니다. 특히, AWS 자원과의 간편한 연동으로 네트워크 보안을 효과적으로 구성할 수 있습니다. 2.자동화 및 스케일링: AWS에서 제공하는 자동 확장 기능을 활용하여 트래픽의 변동에 따라 자동으로 확장되며, 이는 유연성과 효율성을 제공합니다. AWS Auto Scaling과 통합하여 리소스를 효과적으로 확장 및 축소할 수 있습니다. 3.리소스 관리의 용이성: AWS Firewall은 AWS Resource Access Manager (RAM)을 통해 여러 계정에서 리소스를 중앙에서 관리할 수 있는 기능을 제공합니다. 이는 복잡한 다중 계정 구성에서 효율적인 리소스 관리를 지원합니다. 4.네트워크 ACL 및 보안 그룹과의 통합: AWS Firewall은 VPC 내부의 Network ACL 및 보안 그룹과 연동하여 네트워크 레벨에서의 보안을 향상시킵니다. 이로써 전통적인 방화벽 기능과의 조합으로 다채로운 네트워크 보안 정책을 설정할 수 있습니다. 5.웹 어플리케이션 방화벽 (WAF) 기능: AWS Firewall은 AWS WAF 서비스와 통합되어 웹 어플리케이션 보안을 강화할 수 있습니다. 이는 애플리케이션 수준의 공격으로부터 보호하고 웹 트래픽을 감시할 수 있는 기능을 제공합니다.   각각의 클라우드 플랫폼에서 제공되는 Firewall 서비스는 특정 환경에 맞게 선택되어야 하며, 기업의 비즈니스 요구사항과 보안 정책에 부합하는 서비스를 선택하는 것이 중요합니다.   Azure Firewall의 단점: 1.비용 측면의 고려: Azure Firewall의 비용은 트래픽 처리량에 따라 부과되므로, 높은 트래픽을 처리해야 하는 경우 비용이 증가할 수 있습니다. 대규모 트래픽이 예상되는 경우에는 비용 계획을 신중하게 수립해야 합니다. 2.제한된 프로토콜 지원: Azure Firewall은 현재 기본적인 프로토콜만을 지원하며, 모든 프로토콜이나 고급 정책 설정이 필요한 경우에는 다른 솔루션을 검토해야 할 수 있습니다. 3.애플리케이션 레이어의 세밀한 제어 부족: Azure Firewall은 주로 네트워크 레이어에서의 보안을 다루기 때문에, 애플리케이션 레이어에서의 세밀한 정책 설정이 제한적일 수 있습니다. 4.전통적인 기능 부족: 몇몇 전통적인 방화벽 솔루션에 비해 고급 기능이나 세밀한 설정 옵션이 부족할 수 있습니다.   AWS Firewall의 단점: 1.완전한 대체불가 서비스 부재: AWS Firewall이 전통적인 방화벽 솔루션을 완전히 대체할 수 있는 기능을 제공하지 않을 수 있습니다. 특정 기업이나 환경에서는 추가적인 보안 솔루션의 도입이 필요할 수 있습니다. 2.복잡성 및 다양성: AWS 환경에서의 다양한 서비스와 기능들은 초기 설정과 관리에 일정 수준의 복잡성을 유발할 수 있습니다. 이는 초기에는 설정이 복잡할 수 있으나, 익숙해지면 관리가 수월해집니다. 3.기능의 확장성 한계: AWS Firewall이 제공하는 기능이 네트워크 레벨에서 주로 집중되어 있어, 특정 애플리케이션 레벨의 보안 기능이나 세밀한 제어가 필요한 경우 추가적인 솔루션을 도입해야 할 수 있습니다. 4.제한된 프로토콜 및 애플리케이션 지원: AWS Firewall은 현재 일부 프로토콜 및 애플리케이션에 대한 세밀한 제어가 부족할 수 있습니다. 특히, 고급 애플리케이션 레이어의 보안이 필요한 경우 완벽한 해결책이 아닐 수 있습니다.   결론 Azure Firewall 과 AWS Firewall 의 가장 장점은 클라우드 네이티브 이며 매우 다양한 설계를 통해 맞춤으로 디자인 설계 할수 있습니다. 설계에 대한 자유도가 매우 넚으며 언제든지 다른 솔루션으로 변경할수 있는 부분은 최대 장점입니다. 예를들어 동-서 디자인 , 북-남 디자인 , 싱글 방화벽 디자인 설계, 중앙집중식 디자인 설계 등등 , 자유도가 매우 높습니다. Azure Firewall은 Azure 생태계와의 강력한 통합성을 제공하며, Azure에서의 자동 스케일링 및 유연성을 통해 높은 효율성을 약속합니다. 보안 인텔리전스 기능과 Azure Portal을 통한 직관적인 관리는 운영 팀이 효율적으로 작업할 수 있도록 돕습니다. 그러나 비용 측면에서 트래픽 양에 따라 비용이 증가할 수 있고, 일부 전통적인 방화벽 솔루션에 비해 세부적인 기능이 한정적일 수 있습니다. AWS Firewall은 AWS 서비스와의 강력한 통합을 통해 클라우드 환경에서의 유연하고 효과적인 보안 정책을 설정할 수 있습니다. 자동화된 스케일링 및 AWS의 다양한 서비스와의 통합은 확장성과 다양성을 제공하며, AWS WAF와의 통합으로 웹 어플리케이션 보안을 강화할 수 있습니다. 그러나 초기 설정 복잡성과 몇몇 프로토콜 및 애플리케이션에 대한 제한이 존재합니다. 또한, 전통적인 방화벽 솔루션인 Palo Alto Networks나 F5와의 비교를 통해 클라우드 네이티브 솔루션과 전통적인 솔루션 간의 차이를 이해할 수 있습니다. 전통적인 솔루션은 다양한 기능과 정교한 정책 제어를 제공하지만, 클라우드 네이티브 솔루션은 클라우드 특화 기능과 통합성을 강조하며 클라우드에서의 운영을 용이하게 만듭니다. 최종적으로, 기업은 자체의 비즈니스 요구사항, 클라우드 전략, 보안 정책 등을 고려하여 Azure Firewall, AWS Firewall, 또는 전통적인 방화벽 솔루션 중 어떤 것이 최적의 선택인지를 신중하게 평가해야 합니다. 클라우드 환경에서의 보안은 지속적인 변화와 발전 속에 있으므로, 적시에 적합한 솔루션을 선택하여 안정적이고 효과적인 클라우드 보안을 구축하는 것이 중요합니다.   Reference Link Azure Firewall AWS Firewall  ]]> Tue, 10 Oct 2023 14:08:10 +0000 서버 설계 <![CDATA[Azure bastion vs AWS SSM]]> Azure bastion vs AWS SSM Azure와 AWS는 각각 Azure Bastion과 AWS Systems Manager (SSM)이라는 서비스를 통해 클라우드 환경에서의 원격 관리 및 접근을 강화하는 솔루션을 제공하고 있습니다. 클라우드 네이티브하게 엔터프라이즈에서 이런 기술을 도입하기 위해서는 많은 장벽이 있지만 가능합니다.Azure Bastion과 AWS SSM은 각각의 클라우드 플랫폼에서 원격 관리와 보안에 중점을 둔 서비스로, 기존의 방식보다 효율적이고 안전한 환경을 제공합니다. 이 두 서비스를 비교하여 어떻게 동작하며 각각의 장단점은 무엇인지 살펴보겠습니다. Azure Bastion이란: Azure Bastion은 Azure 가상 머신에 대한 안전한 원격 액세스를 제공하는 서비스로, 보안 그레이트라인(GreatLine)을 통해 RDP(Remote Desktop Protocol) 또는 SSH(Secure Shell) 프로토콜을 사용하여 원격으로 가상 머신에 연결할 수 있습니다. 이는 일반적인 원격 데스크톱 또는 SSH 클라이언트를 사용하여 직접 가상 머신에 액세스하지 않고도 안전한 접근을 제공함으로써 보안을 강화합니다. AWS Systems Manager (SSM)이란 : AWS SSM은 AWS 클라우드에서 인프라 및 애플리케이션을 원격으로 관리하기 위한 통합 서비스입니다. SSM은 EC2 인스턴스 및 온프레미스 서버와 같은 다양한 환경에서 원격 명령 실행, 데이터 수집, 자동화, 보안 및 규정 준수를 지원합니다. SSM은 Agent 기반으로 동작하며, 암호화된 통신을 통해 관리 대상에 접근합니다. Azure Bastion의 장점: 1.안전한 원격 액세스: Azure Bastion은 표준 원격 데스크톱 또는 SSH 클라이언트를 사용하여 가상 머신에 직접 연결하지 않고도 안전한 액세스를 제공합니다. 이를 통해 일반적인 원격 액세스에 비해 보안이 강화됩니다. 2.Azure Active Directory 통합: Azure Bastion은 Azure Active Directory와의 통합을 통해 사용자 관리 및 인증을 용이하게 합니다. 기존의 사용자 인증 시스템과의 연계성을 유지할 수 있습니다. 3.프로토콜 지원: 현재 RDP와 SSH 프로토콜을 지원하며, 이는 다양한 운영체제 및 환경에서 사용될 수 있습니다. 표준화된 프로토콜을 지원하여 다양한 시나리오에 대응할 수 있습니다. 4.네트워크 구성 용이성: Azure Bastion은 가상 네트워크에 직접 연결되므로 별도의 VPN 또는 특수 네트워크 구성이 필요하지 않습니다. 이로써 복잡한 네트워크 설정이나 방화벽 규칙의 관리 부담을 줄일 수 있습니다. 5.로그 및 감사 기능: Azure Bastion은 연결 이력과 세션 정보에 대한 로그를 수집하여 보안 감사를 강화할 수 있습니다. 이는 규정 준수와 보안 요구사항을 충족하는 데 도움이 됩니다. AWS Systems Manager (SSM)의 장점: 1.통합된 관리: AWS SSM은 다양한 서비스를 하나의 통합된 인터페이스에서 관리할 수 있습니다. 이를 통해 인프라 관리, 애플리케이션 배포, 구성 관리 등을 효율적으로 수행할 수 있습니다. 2.자동화 기능: SSM은 자동화된 작업 및 스크립트 실행을 지원하며, 이를 통해 반복적이고 복잡한 작업을 간편하게 자동화할 수 있습니다. 예를 들어, 패치 관리, 구성 변경 등이 자동으로 수행될 수 있습니다. 3.암호화된 통신: SSM은 암호화된 통신을 통해 대상 인스턴스와 통신하므로 보안 통신을 지원합니다. 이는 데이터의 기밀성을 유지하면서 안전한 원격 관리를 가능케 합니다. 4.권한 및 접근 제어: AWS Identity and Access Management (IAM)을 통한 권한 관리를 통해 각 사용자 및 역할에 대한 세분화된 권한 부여가 가능합니다. 이는 보안적인 측면에서 효과적인 접근 제어를 제공합니다. 5.다양한 플랫폼 지원: SSM은 Windows 및 Linux 기반 인스턴스를 모두 지원하며, 다양한 운영체제 및 환경에서의 사용에 유리합니다.   Azure Bastion의 단점: 1.비용: Azure Bastion은 사용량에 따른 비용이 부과되며, 더 많은 가상 머신에 대한 액세스가 필요할수록 비용이 증가할 수 있습니다. 대규모 환경에서는 비용 측면에서 고려가 필요합니다. 2.한정된 프로토콜 지원: Azure Bastion은 현재 RDP와 SSH 프로토콜만 지원하고 있습니다. 다양한 프로토콜을 사용하는 환경에서는 이를 고려해야 합니다. 3.제한된 사용자 지원: 현재 Azure Bastion은 Azure Active Directory에 의해 인증된 사용자에게만 액세스를 제공하며, 다른 인증 방식을 지원하지 않습니다. 이는 특정 사용자 그룹에 대한 확장성 문제를 일으킬 수 있습니다. 4.네트워크 제약: Azure Bastion은 가상 네트워크에 연결되어야 하며, 특정 네트워크 구성이 요구됩니다. 이로 인해 복잡한 네트워크 구성이 필요한 경우 유연성이 제한될 수 있습니다. AWS Systems Manager (SSM)의 단점: 1.Agent 설치 필요: AWS SSM은 대상 시스템에 SSM 에이전트를 설치해야 합니다. 이는 초기 구성 및 관리 측면에서 번거로울 수 있습니다. EC2의 경우 많은 수의 EC2를 가지고 있을 경우 운영중에 agent 를 모두 설치하기는 매우 귀찮은 작업입니다. 2.유지보수와 호환성: SSM 에이전트의 주기적인 업데이트 및 호환성 문제에 대한 관리가 필요합니다. 에이전트 버전이 서비스와 호환되지 않을 경우 기능의 일부가 작동하지 않을 수 있습니다. 3.지역 제약: SSM은 모든 AWS 지역에서 동일한 기능을 제공하지 않을 수 있습니다. 특정 지역에서는 일부 기능이 지원되지 않을 수 있으므로 이를 고려해야 합니다. 4.권한 관리 복잡성: SSM은 IAM(Identity and Access Management) 권한을 효과적으로 관리해야 합니다. 올바른 권한이 없는 경우 일부 기능에 액세스할 수 없는 문제가 발생할 수 있습니다. 일반적으로 IAM으로 다수의 계정을 가지고 있다면 이 부분 관리는 거의 지옥이 되게 됩니다. 그러므로 이전에 AWS SSO로 통합된 상태에서 AWS SSM 을 사용해야지 다수 계정 컨트롤를 할수 있습니다.  5.인터넷 연결 요구: SSM은 대상 시스템이 인터넷에 연결되어 있어야 합니다. 완전히 오프라인 환경에서는 사용이 제한될 수 있습니다. Azure Bastion 과 AWS의 SSM의  Enterprise 보안 규정 (SOC 2 및 ISO)  Azure Bastion: Azure Bastion은 Microsoft Azure의 통합 보안 솔루션으로서 SOC 2 및 ISO 27001과 같은 엔터프라이즈 보안 규정을 준수하는 데 강력한 기능을 제공합니다. 1.데이터 암호화 및 보호: Azure Bastion은 데이터의 기밀성을 보장하기 위해 암호화된 통신을 사용하며, 클라이언트 및 서버 간의 안전한 데이터 전송을 보장합니다. 이러한 기능은 ISO 27001과 SOC 2에서 요구하는 데이터 보호 관련 규정을 충족합니다. 2.인증 및 접근 제어: Azure Bastion은 Azure Active Directory를 기반으로 사용자의 신원을 확인하고 접근 제어를 통해 최소한의 권한을 부여합니다. 이는 SOC 2 및 ISO 27001에서 강조하는 인증 및 접근 관리 요구 사항을 충족합니다. 3.로그 및 감사 기능: Azure Bastion은 사용자의 활동에 대한 로깅 및 감사를 수행하여 보안 이벤트를 추적하고 조사할 수 있습니다. 이는 SOC 2 및 ISO 27001에서 요구하는 감사 트레일 및 로깅에 대한 규정을 충족합니다. 서버 접근제어에 대한 부분을 충족하므로 3rd 파티 제품을 제거하는 비용적으로 매우 효율을 가지고 올수 있습니다. 4물리적 보안: Microsoft Azure의 데이터 센터는 엄격한 물리적 보안 조치를 적용하고 있으며, 이는 SOC 2 및 ISO 27001의 물리적 보안 규정을 만족시키기 위한 핵심적인 요소입니다.   AWS Systems Manager (SSM): AWS SSM은 AWS 클라우드에서 엔터프라이즈 보안 규정을 충족시키는데 강력한 특징을 제공합니다. 1.자동화된 보안 업데이트 및 패치 관리: SSM은 자동화된 보안 업데이트 및 패치 관리를 통해 시스템의 취약성을 최소화합니다. 이는 ISO 27001 및 SOC 2에서 요구하는 보안 관리 및 조치에 대한 규정을 충족합니다. 2.IAM을 통한 권한 관리: AWS Identity and Access Management (IAM)은 SSM에서의 권한을 효과적으로 관리하는데 사용됩니다. 각 사용자 및 역할에 대한 세분화된 권한 제어는 SOC 2와 ISO 27001에서 강조하는 권한 관리 규정을 충족합니다. 3.로그 및 감사 기능: AWS CloudTrail과 함께 사용되는 SSM은 사용자 및 리소스의 활동을 로깅하고 감사합니다. 이는 SOC 2와 ISO 27001에서 요구하는 로깅 및 감사에 대한 규정을 충족합니다. 서버 접근제어에 대한 부분을 충족하므로 3rd 파티 제품을 제거하는 비용적으로 매우 효율을 가지고 올수 있습니다.   4.데이터 암호화 및 트랜지트 암호화: AWS는 데이터 암호화 및 트랜지트 암호화를 강화하고 있습니다. 데이터의 기밀성을 보장하기 위한 이러한 보안 기능은 SOC 2와 ISO 27001에서 요구하는 데이터 보호 규정을 충족합니다.   결론: 모든 클라우드 환경은 고객이 엔터프라이즈 보안 규정을 준수하는 데 필요한 강력한 도구와 기능을 제공하고 있습니다. Azure Bastion과 AWS Systems Manager는 각각 Microsoft Azure와 AWS의 보안적인 특징을 통해 SOC 2 및 ISO 27001과 같은 업계 표준 보안 규정을 충족시키는데 기여합니다. 선택은 조직의 요구 사항, 클라우드 전략, 및 환경에 따라 이루어져야 하며, 양쪽의 솔루션은 엔터프라이즈 보안에 필요한 요구 사항을 대부분 충족합니다. 두개 제품 모두 네이티브 클라우드이며 Azure Bastion에서는 Azure 만 접속 가능하며 AWS SSM 도 AWS에서만 사용가능합니다. 그러나 두개 제품이 거의 유사하지만 서로 다른 세계관을 보여줍니다. Azure의 경우 MS의 기본 제품들 처럼 좀 더 PaaS 스러운 부분이 있으며 귀찮은 부분을 매우 잘 커버 해줍니다. AWS 제품은 귀찮은 부분이 조금 있지만 기능적인 면에서 큰 차이가 나지는 않습니다. 오래된 한국 엔터프라이즈 시장에서의 보안 감사를 뛰어넘기 위한 도전과제 한국의 전통적이고 오래된 엔터프라이즈 시장에서 네이티브 솔루션을 통한 보안 감사를 뛰어넘기 위해서는 여러 가지 도전적인 장벽들이 존재합니다. 1.전통적 보안 관행의 유지: 오랜 기간동안 한국의 기업들은 전통적인 방식으로 IT 보안을 관리해왔습니다. 이에 대한 업계 내의 관행과 기존의 보안 솔루션에 대한 의존이 크며, 네이티브 클라우드 솔루션에 대한 도입이 꺼려질 수 있습니다. 2.비용 및 리소스 부족: 기존의 시스템을 업그레이드하고 클라우드 네이티브 솔루션을 도입하는 것은 초기 투자와 리소스를 필요로 합니다. 많은 기업들은 이러한 비용 부담과 리소스 투자에 대한 주저감이 큽니다. 3.기술적 이전과 교육 부족: 한국의 일부 기업들은 새로운 기술에 대한 이전과 교육이 부족한 상태입니다. 클라우드 네이티브 솔루션을 활용하기 위해서는 기존의 시스템에서의 마이그레이션과 직원들에 대한 교육이 필요한데, 이는 일부 기업들에게는 막대한 부담이 될 수 있습니다. 4.법률 및 규정 준수의 어려움: 한국의 법률 및 규정 준수 요구사항은 계속해서 강화되고 있습니다. 네이티브 솔루션을 도입하는 과정에서 새로운 규제 및 준수 요구에 대한 대응이 필요하며, 이는 기업들에게 추가적인 어려움을 제공할 수 있습니다. 5.보안 인식의 부족: 클라우드 컴퓨팅 및 네이티브 보안 솔루션에 대한 인식이 부족한 경우가 있습니다. 보안의 중요성을 충분히 이해하지 못하거나 새로운 기술에 대한 신뢰가 낮아 네이티브 솔루션 도입이 늦어질 수 있습니다. 이러한 도전과제들을 극복하기 위해서는 기존의 업계 관행에 도전하는 용기와 리더십이 필요합니다. 또한, 적절한 교육 및 인프라 개선을 통해 클라우드 네이티브 솔루션을 효과적으로 활용할 수 있는 인력을 양성하는 것이 중요합니다. 클라우드 기술을 통한 보안 감사의 효율성과 효과를 보여줌으로써, 기업들은 새로운 시대에 높은 수준의 보안과 효율성을 달성할 수 있을 것입니다.]]> Sat, 30 Sep 2023 18:42:38 +0000 Azure 클라우드 <![CDATA[나에게 맞는 Azure 디스크 찾기]]> 나에게 맞는 Azure 디스크 찾기   클라우드 컴퓨팅은 현대 비즈니스 환경에서 필수적인 역할을 하고 있습니다. 특히 Azure는 그 중에서도 널리 사용되는 클라우드 플랫폼 중 하나로, 강력한 기능과 다양한 옵션을 제공하고 있습니다. 이 중에서도 Azure 디스크는 가상 머신의 데이터 저장을 위해 핵심 역할을 수행합니다. 그러나 Azure에서 사용할 디스크를 선택하는 것은 쉽지 않을 수 있습니다. 다양한 유형과 크기, 성능, 비용 등을 고려해야 하기 때문입니다. 따라서 이 블로그에서는 여러분이 자신에게 맞는 Azure 디스크를 찾는 데 도움이 되는 지침과 팁을 제공하고자 합니다. 클라우드 디스크의 기본 개념과 중요성에 대해 간략히 살펴보겠습니다. 그런 다음 Azure에서 제공하는 다양한 디스크 유형과 이를 효과적으로 활용하기 위한 방법에 대해 논의할 것입니다. 오라클 Azure AWS GCP 등등의 다양한 클라우드 사업자들은 너무나 다양한 Disk 를 각자 회사에 맞게 내놓고 있고 이른 정확하게 비교하기는 매우 쉽지 않습니다.    필자는 선사시대 Azure 부터 사용을 해왔습니다. 예전 Basic이라는 기본 Disk 가 있었으나 지금 없어졌기때문에 이제는 가장 낮은 Tier는 Standard HDD 입니다. 예전에 Basic Disk 시대는 Azure 의 선사시대이므로 모든것이 잘 작동하지 않을 시절이었는데 현재의 Cloud 시대는 상상할수 없는 느린 하드였습니다. 현재 Azure 에서 사용되는 디스크는 5가지 입니다.    이 5가지 디스크는 하기에 순서대로 출시 되었습니다 1.Standard HDD 디스크: 기존 하드 디스크 드라이브(HDD)와 유사한 형태로, 비용이 낮고 대용량 저장 공간을 제공합니다. 그러나 속도는 느리며 입출력 성능이 상대적으로 낮습니다. 2.Standard SSD 디스크: SATA SSD와 유사한 형태로, 기본적인 성능을 가지면서도 비교적 저렴한 가격으로 제공됩니다. 입출력 성능이 HDD보다 향상되어 있습니다. 3.Premium SSD 디스크: 높은 성능을 제공하는 SSD 디스크로, 프리미엄 가상 머신에 사용하기 적합합니다. 낮은 레이턴시와 높은 IOPS를 제공하여 요구 사항이 높은 응용 프로그램에 적합합니다. 4.Ultra Disk: 초고성능을 제공하는 디스크로, 고성능 데이터베이스 및 기타 응용 프로그램에 이상적입니다. 높은 IOPS와 낮은 레이턴시를 제공하여 대규모의 트랜잭션 및 데이터 처리에 적합합니다. 5.Premium SSD v2 디스크 낮은 대기시간과 높은 IOPS 및 처리량을 지속적으로 요구하는 성능 민감 워크로드에 적합합니다.   이 5가지 디스크는 위에 순서대로 출시 되었습니다.  성능과 용량
Standard HDD Standard SSD Premium SSD Ultra Disk Premium SSD v2
최대용량 32767GiB 32767GiB 32767GiB 65536GiB 65536GiB
최대IOPS 2000 6000 20000 160000 80000
최대처리량 500MB/sec 750MB/sec 900MB/sec 4000MB/sec 1200MB/sec
  최대 용량은 한개 디스크에서 최대 용량입니다.  최대 IOPS 의 경우 최대 입출력 수치이지 고정 수치가 아닙니다. 실제로 FIO 테스트나 디스크 성능 테스트를 했을경우 속도가 최대가 나오지는 않습니다. 그냥 나오느 것이 아니라 하기에 링크처럼 최적화 고성능을 위한 방법 을 적용해야 최대 IOPS 랑 비슷하게 나옵니다. 온프레미스 절에 물리 디스크가 아니므로 완전 성능을 보장하지는 않습니다. 다른 디스크와 다르게 울트라 디스크의 경우에는 최소 처리량을 제공합니다. 최소 처리량을 각 IOPS에 대해 4kb/sec 이며 전체 기준 최소 값은 1MB/s 입니다. 울트라 디스크 이외에는 최소 보장 처리량은 제공하지 않고 있습니다. 일반적으로 GCP 나 AWS 도 마찬가지로 최소 보장 처리량이나 평균 IOPS에 대한 SLA나 보장은 없으며 이런 방법은 클라우드에서 일반적입니다.  https://learn.microsoft.com/en-us/azure/virtual-machines/premium-storage-performance   울트라디스크 최고 성능 최고 처리량 디스크 입니다. VM을 다시 시작 하지 않고도 변경이 가능합니다. SAP 나 데이터베이스에 디스크로 사용하기 매우 좋습니다.  단점 데이터디스크로만 사용가능합니다. OS 영역에는 미지원 합니다. 모든 Azure 지역에서 사용할 수 없습니다.  물리적 섹터를 4k만 지원합니다. 512 바이트는 미지원합니다. 가상머신이 보통 v3 이후 세대만 지원합니다. 비용이 비쌉니다.   Premium SSD v2 가장 최신 디스크 입니다 AWS GP3 와 비교 대상입니다. 전용크기가 따로 없으며 가동중지 시간 없이 변경 가능합니다. Host캐싱을 지원하지는 않지만 기본적으로 낮은 대기시간을 쓸수 있으며 IOPS 와 처리량 크기를 자유롭게 변경할수 있으므로 디스크를 LVM 과 같은 방법으로 스프라이트 해야 하는 관리 부분은 없어졌다고 생각 하면 됩니다. 단점 OS 영역은 사용 불가 합니다. 디스크만 사용 가능합니다. 가용성 집합의 VM 에 연결 불가능 호스트 캐싱 미지원 모든 Azure 지역에서 사용할 수 없습니다. 기본 물리섹터는 4k   Premium SSD 이제는 거의 표준 디스크처럼 사용 되는 프리미엄 ssd 이며 물리 섹터를 512를 지원합니다. 가장 일반적이고 짧은 대기시간과 고성능입니다. 버스팅 기능도 제공합니다. 고성능입니다. 단점 기본으로 VM을 생성하면 OS가 30GiB 인데 IOPS 기반 SSD이므로 30GiB에서는 표준 SSD 보다 IOPS가 느리다.  비용이 높음 용량 제한   표준 SSD 이제는 가장 낮은 수준의 홈페이지에서만 사용 하는 디스크로 전향되었습니다. OS 영역이 32GiB이어도 디스크 기본 IOPS가 500이므로 프리미엄 디스크 보다 낮은 용량에서는 효과적인 이상한 디스크입니다. 버스팅도 제공합니다. 저렴한 가격을 제공합니다. 다른 디스크보다 용량이 적습니다. IOPS가 고정 성능입니다. 단점 느린 레이턴시로 응답시간 느립니다.   표준 HDD 개발이나 테스트 시나리오에서만 사용하는 10ms 미만 의 대기시간 20ms 의 읽기 대기시간 제공하는 디스크 단점 느린 레이턴시로 응답시간 느립니다. 저성능입니다.   결론:  1.비용과 성능의 균형 찾기: 비용 민감성: 프로젝트 예산이 제한적인 경우 Standard HDD 또는 Standard SSD 디스크가 경제적인 선택일 수 있습니다. 고성능 요구: 성능이 중요한 응용 프로그램에는 Premium SSD 또는 Ultra Disk가 높은 성능을 제공하여 효과적일 수 있습니다. 2.데이터 처리량과 안정성 고려: 데이터 처리 요구: 대규모 트랜잭션 및 데이터 처리가 필요한 경우 Ultra Disk가 뛰어난 성능을 제공합니다. 안정성 및 관리 편의성: Managed Disks는 안정성과 관리 편의성을 강조하며, 백업 및 스냅샷을 통한 데이터 보호를 강화합니다. 3.용량과 확장성을 고려: 대용량 요구: 대용량 데이터 저장이 필요한 경우, Standard HDD 또는 Premium SSD를 고려할 수 있습니다. 용량의 중요성: 특정 용량 범위에서만 제공되는 Premium SSD 또는 Ultra Disk의 경우, 용량의 중요성을 고려해야 합니다. 4.향후 확장 가능성 고려: 향후 성장 예측: 프로젝트의 향후 성장을 고려하여, 디스크 유형의 유연성을 고려해야 합니다. 리소스 조정 가능성: 향후에 리소스를 조정해야 할 경우, Managed Disks의 자동화된 관리 기능을 고려할 수 있습니다. 5.종합적인 고려와 테스트: 다양한 요소 종합 고려: 비용, 성능, 안정성, 용량 등 다양한 측면을 종합적으로 고려하여 최적의 선택을 찾아야 합니다. 테스트 및 최적화: 선택한 디스크 유형을 테스트하고 필요에 따라 최적화를 수행하여 프로젝트 성공에 기여할 수 있습니다. 최종적으로, Azure 디스크 선택은 프로젝트의 성공과 안정성에 큰 영향을 미칩니다. 따라서 주어진 상황과 요구 사항을 정확하게 평가하고, 신중한 비교 및 테스트를 통해 나에게 맞는 Azure 디스크를 선택하는 것이 핵심입니다. 이를 통해 클라우드 환경에서 최상의 성능과 효율성을 달성할 수 있을 것입니다. Azure에서 제공하는 다양한 디스크 유형은 각각의 장점과 한계를 가지고 있어, 사용자가 자신의 프로젝트 요구 사항과 예산에 맞게 선택해야 합니다. 지속적인 업데이트로 인하여 항상 디스크에 대한 부분을 평가 하면 매번 다른 결과가 나옵니다. 기능도 계속적으로 추가되며 기존에 있던 디스크 새로운 기능을 넣기에는 기존 프로덕션 제품에 영향을 줄수 있기 때문에 새로운 이름으로 항상 디스크가 나옵니다. 다음 차세대 디스크는 볼트 디스크라고 제가 이름을 지어 보겠습니다. 양자역학의 기술로 초스피드 디스크에 모든 기능을 다 탑제한 끝판왕이 나오길 기대 해보기로 합니다.  ]]> Mon, 18 Sep 2023 11:18:18 +0000 Azure 클라우드 <![CDATA[AKS SLA vs EKS SLA 비교하기]]> AKS SLA vs EKS SLA 비교하기 정밀한 클라우드 관리와 안정성은 현대 기업의 핵심입니다. 특히, 서비스 운영을 위해 Microsoft Azure Kubernetes Service(AKS)를 선택한 기업들은 신뢰성과 안정성을 보장하기 위해 SLA(Service Level Agreement)에 큰 관심을 가지고 있습니다. AKS SLA가 어떻게 기업의 운영에 도움을 주며, 신뢰성을 높이는 데 어떤 역할을 하는지에 대해 탐구해보려 합니다.  클라우드 서비스에서 SLA는 높은 가용성과 안정성을 보장하기 위한 핵심적인 계약입니다. AKS의 SLA는 어떻게 운영의 안정성과 연속성을 보장하며, 기업의 비즈니스에 어떤 영향을 미치는지에 대해 살펴보겠습니다. 또한, AKS SLA의 기술적인 측면과 함께, 이 SLA가 비즈니스 목표 달성에 미치는 영향, 실제 사례와 성공적인 적용 사례들을 살펴보며 어떻게 AKS SLA가 기업의 경쟁력을 높이고 혁신을 이끄는 데 도움을 주는지에 대해 분석하고자 합니다.’ 여기서 AKS SLA에 대한 관심을 높이고, 이를 통해 클라우드 네이티브 환경에서의 안정성과 성능을 향상시키는 방법을 탐구해보려 합니다. 그럼, 이 블로그를 통해 AKS SLA가 기업의 IT 인프라에 미치는 영향과 혜택에 대해 자세히 알아보도록 하겠습니다. 또한 추가적으로 AWS EKS 의 SLA 와 비교하며 어떤 차이가 있는지 소비자 입장에서 좀 더 구분 해서 전달 하겠습니다.   쿠버네티스 클러스터의 경우 2개의 부분으로 나눌 수 있습니다. 한개는 컨트롤플레인와 애플리케이션 노드로 나눠질수 있습니다. SLA 도 두개 부분으로 나뉩니다.   1.컨트롤 플레인  2.노드   1번 컨트롤 플레인은 AKS 의 PaaS 부분이며 관리되는 부분입니다.  2번 노드 가용성은 Virtual Machines SLA 의 적용 받습니다 예를들어 VM 의 가용성 조건을 맞춘다면 VM 의 SLA가 적용됩니다. AKS(Azure Kubernetes Service) 클러스터를 만들면 컨트롤 플레인이 자동으로 생성되고 구성됩니다. 제어 플레인에는 기본 Kubernetes API를 노출하는 API 서버가 포함되어 있습니다.   SLA 계산식 1.월간 전체 작동 시간(Monthly Maximum Available Time/Min)  2.작동 중지 시간(Service Downtime/Min)  3.월간 가동 시간(Monthly Uptime/Min) = 1-2 4.월간 작동 시간 비율(Monthly Uptime Percentage) = ((1-2)/1)*100   가용성 영역은 Azure 지역 내의 오류 격리 영역으로, 중복 전원, 냉각 및 네트워킹을 제공합니다.

가용성 영역을 사용하는 AKS 클러스터에 대한 월간 가동 시간 계산 및 서비스 수준을 계산해보면 최대 사용 가능 시간(분)은 고객이 청구 월 동안 AKS 클러스터를 중지하거나 삭제하는 작업을 시작한 시간까지 가용성 영역 지원 AKS 클러스터의 총 누적 시간(분)입니다. 가동 중지 시간은 해당 지역의 프로비저닝된 가용 영역 지원 AKS 클러스터에서 Kubernetes API 서버에 연결되지 않은 최대 사용 가능 시간(분)의 일부인 총 누적 시간(분)입니다.

가용성 영역이 활성화된 AKS 클러스터에 대한 "월간 가동 시간 백분율"은 지정된 Microsoft Azure 구독에 대해 청구 월의 최대 사용 가능한 시간(분)에서 가동 중지 시간을 뺀 최대 사용 가능한 시간(분)으로 계산됩니다. 월별 가동 시간 비율은 다음 공식으로 표시됩니다. 월별 가동 시간 % = (최대 사용 가능한 시간(분) - 가동 중지 시간) / 최대 사용 가능한 시간(분) X 100 가동 중지 시간은 프로비전된 AKS 클러스터가 Kubernetes API 서버에 연결되지 않은 최대 사용 가능 시간(분)의 일부인 총 누적 시간(분)입니다. 쉽게 말해서 Kubernetes 의 API 서버에 엔드 포인트에 대한 부분 외는 SLA 범위가 아닙니다. 이는 생각보다 중요한 부분입니다. AKS 의 업데이트 시 가동 중지 , 사용 불가, 일시 중지 등에 따라 API 서버의 엔드 포인드가 죽지 않고 살아만 있다면 된다라는 의미입니다. AKS 의 모든 부분에 대해서 SLA 를 보장하지 않는 다는 내용입니다. 대부분의 고객은 AKS 클러스터 SLA라고 하면 AKS에 모든 부분에 대해서 SLA 보장이 되는 것이라 믿고 있을것 입니다. 그러나 https://azure.github.io/PSRule.Rules.Azure/en/rules/Azure.AKS.UptimeSLA/ 이 SLA 공식 문서를 보면 하기 처럼 정확한 AKS의 범위가 적혀 있습니다. 가동 시간 SLA는 가용 영역을 사용하는 클러스터에 대해 Kubernetes API 서버 엔드포인트의 99.95% 가용성을 보장합니다. 라고 쓰여 있으므로 이부분은 매우 중요한 부분입니다. azure그림001 그림001 에서 보면 AKS SLA 보장은 Standard 티어 부터 가능하다고 써있으므로 이부분도 확실히 잘 인지 해야 합니다. AWS 의 EKS 는 어떨까요?  https://aws.amazon.com/ko/eks/sla/ 여기에 있는 AWS EKS SLA 공식 문서 입니다. 당연하게 Azure 와 똑같은 SLA를 보장합니다. AWS EKS 문서를 봅시다. 특정 EKS 클러스터에 대한 "월간 가동 시간 백분율"은 EKS 클러스터 엔드포인트를 사용할 수 없는 월별 청구 주기 동안 5분 간격의 백분율을 100%에서 빼서 계산됩니다. 해당 EKS 클러스터를 한 달 중 일부 기간 동안만 실행한 경우 EKS 클러스터는 해당 달 중 실행되지 않은 부분에 대해 100% 사용 가능한 것으로 간주됩니다.  -> 이말은 엔드포인트만 보장한다는 의미입니다. 결론 어쩜 이렇게 Azure 와 AWS 가 완전히 같은 SLA를 보장할까요? EKS 엔드포인트를 사용할수 없는 시간만 빼줍니다. 범위가 엔드포인트 까지 입니다. 필자의 직접 경험을 비출때 엔드포인트 이외의 장애 말고는 보상해주지 않습니다. AKS와 EKS는 각각의 클라우드 제공 업체의 강점과 약점을 가지고 있습니다. SLA 보상 범위는 Azure 든 AWS 든 고객을 완전히 만족시키는 SLA를 아닌것으로 보입니다. SLA 부분 보시면 범위 뿐만아니라 가동 시간이 월 클러스터 비용의 퍼센트를 제공해주므로 AKS 나 EKS 를 많이 쓰는 고객 아니라면 비용적으로 의미가 있는 보상은 아니라는 제 개인적 생각입니다. 실제로 많이 사용하는 고객이라면 서비스가 장애가 났다면 비용으로 이를 매꿀수 있는 수준은 아니며 단순히 증빙용이 아닐까 생각이 듭니다.     ]]> Tue, 08 Aug 2023 14:13:59 +0000 서버 설계 <![CDATA[Azure DNS 위임 (Azure DNS Delegations)]]> 클라우드가 있기 전에 시절인 공룡시절에는 IIS 와 같은 DNS 서버나 DNS 서버를 직접 구축 해서 도메인 위임 (Domain delegation) 을 했던 시절이 있었습니다. 아직도 올드 스쿨한 온프레미스에서 운영하고 있는 회사에서는 매우 일반적으로 도메인 위임이 되어 있습니다. 그러나 클라우드 시절로 넘어오면서 AWS 의 Route53 이나 Azure DNS 와 같은 PaaS 형 Domain 서비스가 쉽게 적용 되어 있는 현재에 도메인 위임은 사실 엔터프라이즈 회사가 아니면 쉽게 쓰이지 않습니다. 사실 공룡시절 예를들어 클라우드 계정이 여러개이며 소유권이 다르기 때문에 DNS 아키텍처와 분배가 필요하다거나 DNS 서버를 다양한 용도로 사용할때 이 DNS 위임은 필수로 필요하게 됩니다.  Azure DNS 위임은 클라우드 기반의 환경에서 DNS(Domain Name System) 이름 해결을 관리하는 핵심적인 매커니즘 중 하나입니다. DNS 위임은 하나의 DNS 존에서 다른 DNS 서버로 일부 또는 전체 권한을 위임하는 프로세스를 의미합니다. Azure DNS 위임은 이러한 원리를 활용하여 Azure 환경 내에서 호스팅되는 DNS 존의 권한을 외부 DNS 서버에 위임함으로써, DNS 이름 공간을 유연하게 관리하고자 하는 사용자 및 관리자들에게 유용한 기능을 제공합니다. 이를 통해 Azure 사용자는 자체 도메인 이름을 Azure에서 호스팅하는 동안, 필요에 따라 특정 DNS 영역의 권한을 다른 DNS 서비스로 손쉽게 위임할 수 있습니다. 예를 들어, 회사의 도메인을 Azure DNS로 호스팅하면서 일부 서브도메인을 다른 DNS 서비스 업체에 위임하여 관리할 수 있습니다. 이러한 위임은 사용자가 효율적으로 DNS 관리를 조정하고 다양한 서비스를 통합하는 데 도움이 됩니다. Azure DNS 위임은 클라우드 기반의 유연성과 함께, DNS 이름 해결을 위임하여 관리할 수 있는 기능을 제공하여, 사용자가 Azure 환경 내에서 DNS 구성을 더욱 효과적으로 관리하고 최적화할 수 있도록 지원합니다. azure 그림001   그림001은 DNS 도메인에 대한 모든것을 설명합니다. 이 그림 하나로 모든것을 이해 할 수 있습니다. 1.User 가 1번의 DNS Resolver 에게 먼저 물어봅니다.DNS resolver는 일반적으로 인터넷 서비스 제공업체(ISP)나 네트워크 서비스 제공업체에서 제공하는 서버입니다. 이 resolver 서버들은 물리적으로 전 세계에 분산되어 있습니다. 사용자의 장치(컴퓨터, 스마트폰 등)는 일반적으로 ISP에서 제공하는 DNS resolver를 사용하거나 특정한 공공 DNS resolver(예: Google Public DNS, Cloudflare DNS 등)를 사용합니다. 여기서 예제를 image.kakayo.com 이미지.카카요 닷컴이라는 도메인이 있다고 가정합니다.이미지. 카카요 닷컴을 유저가 브라우저에서 입력 하면 먼저 KT DNS 리졸버에게 물어봅니다. 이미지. 카카요 어딧냐? 라고 물어보면 그림의 2번 숫자처럼 Root name server에게 물어봅니다.   2.2번에서 Root name server 는 또다시 난 레코드가 없다라고 답변하고 대신 나는 .com 주소는 알아 라고 DNS Resolver에게 대답해줍니다. 3.3번에서 DNS Resolver 는 TLD .com 서버에게 물어봅니다. 어 너 이미지. 카카요닷컴 어딧는지 알어? 응 알아? 난 kakayo.com 만 알아 이미지는 어딧는지 몰라.라고 DNS resolver에게 답변 합니다.    4.DNS Resolver 는  이미지. 카카요닷컴 어딧냐 라고 물어보면 이제 Azure DNS에 등록 되어 있는 카카요닷컴 주소를 DNS Resolver 에게 답변합니다. 5.DNS Resolver는 이제 카카요 닷컴이 있는 Azure DNS 에게 물어봅니다. 이미지.카카요는 어딧냐? 라고 물어보면 어 이미지.카카요는 다른 Azure DNS 에 있어 라고 합니다 그래서 그 두번째 Azure DNS 에 이미지.카카요닷컴의 주소를 DNS Resolver에 줍니다. 이야.. 그래서 유저는 드디어 image.kakayo.com 에 주소를 받게 됩니다. 그래서 그 주소가 있는 웹서버에 접속합니다. 이 resolver 서버들은 사용자가 웹 브라우저에 도메인 이름을 입력했을 때, 해당 도메인 이름을 IP 주소로 해석하는 작업을 수행합니다. 그러기 위해선 이 resolver 서버들은 DNS 계층 구조를 따라 동작하여 루트 DNS 서버, 톱레벨 도메인(TLD) 서버, 그리고 해당 도메인의 Authoritative Name Server까지 쿼리를 보내고 응답을 받습니다.따라서 DNS resolver는 사용자와 도메인의 실제 물리적 위치 사이에서 중간 역할을 하며, DNS 서비스를 통해 도메인 이름을 IP 주소로 해석하는 과정에서 중요한 역할을 수행합니다. 이 resolver 서버들은 분산되어 있어 전 세계 어디에서나 빠르고 효율적인 DNS 해석을 제공할 수 있도록 구축되어 있습니다. DNS Resolver는 그러면 매번 이 과정을 수행 하냐? 아닙니다. 한번 불러 온 일을 미리 캐싱해서 2번3번4번5번을 반복하지 않습니다.   6.그림에서 6은 .com 인지 .net 인지 최상위 Root 주소만 알고 있습니다. 그 주소를 .com 주소에게 자동적으로 위임이 되어 있습니다.    7.그림에서 7번은 도메인을 구입한 곳에서 Name server를 직접 제공한다거나 Nameserver를 변경할수 있도록 해줍니다. 반약 변경을 한다면 이 도메인에 대한 소유권을 Azure DNS로 옴기는 작업이 필요하며 그 방법은 단순이 Nameserver을 Azure DNS 에 생성하고 Nameserver 4개의 주소를 Azure DNS 에 DNS Record를 적으면 됩니다. 그러면 이 도메인은 kakayo.com 까지 주소의 하위주소까지 전부 소유 합니다.   8.그림에서 8번은 도메인은 7번의 Azure DNS 는 kakayo.com 을 소유 하지만 8번에 image.kakayo.com의 소유권을 넘기는겁니다. 이말은 소유권을 넘긴다라는 말은 image.kakayo.com은 8번에서 관리한다는 의미입니다. 자 그러므로 7번과 8번의 Azure DNS 의 Azure 텐던트나 구독이 다른곳에서 만들수 있다는 의미입니다. 이말은 내가 .만약 7번을 가지고 있는 kakayo.com 의 DNS 루트관리자와 image.kakayo.com 의 루트 관리자를 다른 계정, 다른 구독, 다른 회사, 다른 자회사에게 해당 도메인만 줄수 있다는 장점이 있습니다. 마약 카카요닷컴에 자회사가 경매 사업을 시작했습니다. 카카요옥션 이라고 해보죠. 카카요옥션은 auction.kakayo.com 도메인을 사용하고 싶습니다. 이때 바로 우리는 다른 자회사의 DNS 관리자에게 소유권을 부분 이전해줄수 있다라고 생각하시면 됩니다.   결론 DNS 위임은 네트워크에서 도메인 이름을 IP 주소로 해석하는 프로세스를 관리하는 중요한 방법 중 하나입니다. 위임의 장점 중 하나는 계층화된 구조로 인해 도메인 네임 시스템이 유연하고 확장 가능하다는 것입니다. 그러나 위임은 몇 가지 단점과 함께 제약사항도 가지고 있습니다. 장점 중 하나는 확장성입니다. DNS 위임은 도메인 이름 공간을 분할하고, 관리하고, 분산하여 조직의 필요에 맞게 맞춤 설정할 수 있게 합니다. 이는 대규모 네트워크 환경에서 유용합니다. 또한, 위임은 오류나 문제가 발생했을 때 일부 영역만 수정하고 관리할 수 있는 장점이 있습니다. 이는 유연한 관리와 유지보수를 가능하게 합니다. 그러나 이러한 장점과는 별개로, 위임은 몇 가지 단점도 가지고 있습니다. 주요 단점 중 하나는 오류 발생 시 트러블슈팅이 어려울 수 있다는 점입니다. 도메인 이름 해석에 문제가 발생하면, 이를 해결하기 위해 위임 구조를 탐색해야 할 수 있습니다. 또한, 위임된 영역 간의 일관성 유지와 관련된 어려움도 있을 수 있습니다. 또한, DNS 위임은 인프라 구조가 조직 내에서 제대로 설정되어야 합니다. 올바르게 구성되지 않으면 위임된 영역의 관리나 보안 문제가 발생할 수 있습니다. 요약하자면, DNS 위임은 유연성과 확장 가능성을 제공하는 데 도움을 줍니다. 그러나 잠재적인 오류와 관련된 복잡성, 그리고 적절한 구성과 관리의 필요성이 있는 단점도 고려해야 합니다. 올바르게 구성하고 유지보수하는 한, DNS 위임은 효과적인 도메인 이름 관리 방법 중 하나로 여겨질 수 있습니다.  ]]> Thu, 06 Jul 2023 08:42:00 +0000 서버 설계 <![CDATA[Azure NAT gateway 와 AWS NAT gateway 비교]]> 클라우드에서 AWS와 Azure는 표면적으로는 같은 서비스처럼 보이지만 내부적으로는 매우 다른 알고리즘으로 구성되어 있습니다. 클라우드에서 특징들과 기능은 끊임없이 변화하는 상태이며 오늘 다르고 내일 또 업데이트 되는 탄력적 진화 시스템입니다. 심지어 지금 이순간도 클라우드 기술이 변하고 있으며 그 단위가 일주일 이하도 있습니다. 세부적인 기능은 언제 바뀌었는지 조차도 어려울정도로 지속적으로 테스트하고 연구하지 않으면 점점 뒷쳐지며 심지어 엔지니어로서, 개발자로서 자신의 영역을 줄 여야만 하는 시대에 살고 있습니다. 클라우드 컴퓨팅은 현대 기업이 디지털 변혁과 확장을 위해 선택하는 주요 전략 중 하나로 자리 잡았습니다. 특히, Microsoft Azure와 Amazon Web Services(AWS)는 그 중에서도 선도적인 클라우드 플랫폼으로 전 세계적으로 널리 사용되고 있습니다. 이러한 클라우드 서비스는 기업들이 자원을 효율적으로 활용하고 유연하게 스케일링할 수 있는 기회를 제공하며, 그 중에서도 네트워킹은 클라우드 인프라의 핵심 구성 요소 중 하나입니다. 많은 기업들이 클라우드로의 이전을 고려할 때, 네트워킹을 어떻게 구성하고 외부와의 통신을 관리할지에 대한 결정이 중요한 주제가 됩니다. 이에 따라 NAT(Network Address Translation) 게이트웨이는 내부 네트워크와 외부 리소스 간의 통신을 효율적으로 관리하고 보안을 강화하는 데에 중요한 역할을 합니다.    Azure NAT Gateway는 현대적이고 강력한 NAT(Network Address Translation) 서비스로, 클라우드 네트워킹의 핵심 기능 중 하나를 담당합니다. 이 서비스를 통해 프라이빗 서브넷 내의 모든 인스턴스가 완벽한 프라이버시를 유지하면서도 필요에 따라 안전하게 인터넷에 연결할 수 있습니다. 이를 통해 기업들은 클라우드 환경에서 안전하게 네트워킹을 구성할 수 있습니다. Azure NAT Gateway의 주요 특징 중 하나는 외부와의 통신에서 발생하는 인바운드 연결을 허용하지 않는다는 점입니다. 이는 보안 측면에서 매우 중요한데, 원치 않는 인바운드 연결을 차단함으로써 악의적인 공격으로부터 클라우드 리소스를 보호할 수 있습니다. 또한, NAT 게이트웨이는 아웃바운드 연결을 자동으로 확장하고, 동적 SNAT 포트 기능을 통해 SNAT(Source Network Address Translation) 포트 소모의 위험을 최소화합니다. 이는 효율적인 네트워크 리소스 사용과 성능 향상에 기여합니다. Azure NAT Gateway의 중요한 특징 중 하나는 외부로부터의 응답 패킷에 대해서만 NAT 게이트웨이를 통과시킨다는 점입니다. 이는 보안 정책을 강화하면서도 외부 서비스와의 효율적인 통신을 지원합니다. 요약하면, Azure NAT Gateway는 클라우드 환경에서 안전하고 효율적인 네트워킹 솔루션을 제공하는데, 완전히 관리되고 복원력이 뛰어난 특징을 가지고 있습니다. 클라우드 기반 인프라를 구성하는 기업들에게는 이러한 강력한 NAT 서비스가 안정성과 보안성을 강화하는 데에 큰 도움이 될 것입니다.   AWS VPC와 Azure VNet은 모두 클라우드 환경에서 가상 네트워킹을 제공하는데 중요한 역할을 하는데, 이 두 플랫폼 간의 차이점과 특징을 살펴보겠습니다. 1.주소 할당과 CIDR 블록: AWS와 Azure는 모두 RFC 1918에 명시된 비공개 IPv4 주소 범위의 CIDR 블록을 사용하여 가상 네트워크를 생성합니다. 이는 클라우드 환경에서 내부 네트워크를 안전하게 구성할 수 있도록 해주며, 고객은 필요에 따라 다른 공용 IP 주소를 계속 사용할 수 있습니다. Azure VNet은 지정된 CIDR 블록의 개인 IP 주소에 VNet에 연결된 리소스를 할당합니다. 최소 서브넷 크기는 /29이고 최대는 /8입니다. AWS는 최소 주소 블록을 /28, 최대 주소 블록을 /16로 권장합니다. 2.인터넷 액세스와 게이트웨이: AWS는 현재 공개 IP 블록에서 직접 인터넷 액세스를 지원하지 않고, 가상 사설망(VPN)을 통해서만 접근할 수 있습니다. AWS VPC는 Egress-Only Internet Gateway (EGW)를 제공하여 아웃바운드 트래픽은 허용하고 인바운드 트래픽은 차단합니다. Azure VNet에서는 Azure NAT Gateway를 사용하여 프라이빗 서브넷의 인스턴스가 안전하게 인터넷에 연결할 수 있습니다. 인터넷에서의 인바운드 연결은 NAT 게이트웨이를 통해 차단됩니다. 3.IPv6 지원: AWS VPC는 2017년 1월 현재 중국을 제외한 모든 지역에서 IPv6을 지원하고 있습니다. Azure는 IPv6 지원이 제한적이지만, VNet은 고정 크기인 /56 (CIDR 표기법)을 사용하며, 서브넷 크기는 /64로 고정됩니다. IPv6에서는 모든 주소가 기본적으로 인터넷 라우팅이 가능하며, AWS에서처럼 특별한 게이트웨이가 필요하지 않습니다. 4.IP 주소 변경 및 관리: Azure VNet은 서브넷의 IP 주소를 초기 설계 후에도 변경할 수 있지만, 현재 서브넷의 리소스는 마이그레이션되어야 합니다. AWS에서는 서브넷 IP 주소를 변경하기 어렵고, IP 주소를 쉽게 관리할 수 있는 기능인 IPAM 과  비슷한 기능은  Azure에서는 제공되지 않습니다. 5.확장성과 성능  NAT 게이트웨이는 생성 시 스케일 아웃되며, 램프 업이나 스케일 아웃 작업은 사용자가 직접 관리할 필요가 없습니다. Azure는 NAT 게이트웨이 작업을 관리하여 사용자에게 편의성을 제공합니다. 서브넷에 NAT 게이트웨이를 연결하여 해당 서브넷의 모든 프라이빗 리소스에 아웃바운드 연결을 제공하며, 가상 네트워크의 모든 서브넷은 동일한 NAT 게이트웨이 리소스를 공유할 수 있습니다. 최대 16개의 공용 IP 주소나 /28 크기의 공용 IP 접두사를 할당하여 아웃바운드 연결을 확장할 수 있습니다. Azure NAT Gateway는 소프트웨어 정의 네트워킹 서비스로, 최대 50Gbps의 데이터 처리 성능을 제공합니다. 각 NAT 게이트웨이는 컴퓨팅 리소스의 네트워크 대역폭에 영향을 주지 않습니다. 이로써 안정적이면서도 고성능의 아웃바운드 및 반환 트래픽을 처리할 수 있습니다. 6.영역 격리의 중요성: 영역 격리는 한 영역에서 발생할 수 있는 장애나 문제가 다른 영역에 영향을 미치지 않도록 하는 핵심 개념입니다. 이를 통해 시스템이 지역적인 장애에 강하게 대응할 수 있고, 전체적인 가용성을 향상시킬 수 있습니다. 영역 격리를 강조하는 이유 중 하나는 지리적 분산 및 자연 재해 등에 대비하여 전략적으로 서비스를 운영할 수 있는 데에 있습니다. 7.NAT 게이트웨이와 가상 머신 인스턴스: 각 가용성 영역에는 NAT 게이트웨이 리소스와 해당 공용 IP 주소를 사용하는 가상 머신 인스턴스로 구성된 "영역 스택"이 형성됩니다. 이것은 영역 간에 서로 독립적으로 운영되며, 장애 발생 시에도 영역 간에 영향을 최소화할 수 있도록 합니다. 가상 머신 인스턴스가 NAT 게이트웨이 리소스와 동일한 영역에 위치하면 영역 격리의 이점을 최대한 활용할 수 있습니다. 8.안정성과 가용성: 이러한 구성은 영역 간 장애 시에 자동으로 다른 영역으로 트래픽을 전환하여 지속적인 서비스 제공을 가능하게 합니다. NAT 게이트웨이 리소스는 분산되어 있으며, 영역 간의 상호 운영이 강화되어 전체적인 클라우드 인프라의 안정성과 가용성이 향상됩니다. 허브-앤-스포크 네트워크 아키텍처와 NAT Gateway 허브엔 스포크에서  NAT(Network Address Translation)의 필요성은 여러 측면에서 나타납니다. 특히, 이 아키텍처에서 NAT는 네트워크 보안, 주소 공간 관리, 그리고 트래픽 제어 등 다양한 측면에서 중요한 역할을 수행합니다. 1.보안 강화: IP 주소 은폐: 허브-앤-스포크 구조에서는 스포크 네트워크의 내부 시스템이 허브를 통해 외부와 통신해야 할 경우가 있습니다. NAT를 통해 내부 시스템의 실제 IP 주소를 외부에 노출시키지 않고, 대표적인 공용 IP 주소로 변환함으로써 보안을 강화할 수 있습니다. 2.주소 공간 관리: 사설 주소 사용: 허브-앤-스포크에서는 각각의 스포크 네트워크가 독립된 IP 주소 공간을 가질 수 있습니다. NAT를 사용하면 사설 주소 공간을 할당하고, 이를 공용 IP 주소로 변환하여 중복을 방지하고 주소 공간을 효율적으로 활용할 수 있습니다. 3.트래픽 제어: 인터넷 트래픽 관리: NAT를 사용하면 허브에서 관리되는 트래픽을 통제할 수 있습니다. 내부에서 나가는 트래픽은 NAT 게이트웨이를 통과하며 허브의 네트워크 정책에 따라 필터링될 수 있습니다. 이로써 허브에서는 트래픽을 감시하고 보안 정책을 적용할 수 있습니다. 4.스포크 간 통신 제어: 스포크 간 통신 조절: NAT를 사용하면 스포크 간에 직접 통신하는 것을 제어할 수 있습니다. 허브에서는 필요한 경우 특정 스포크 간 통신을 허용하고 다른 스포크 간 통신을 차단할 수 있습니다. 5.유연성 및 확장성: IP 주소 변경 용이성: NAT를 사용하면 내부에서 사용되는 IP 주소를 변경하지 않고도 외부와의 통신이 가능합니다. 이는 내부 네트워크 구조를 변경하지 않고도 확장이나 업그레이드를 수행할 때 유용합니다. 허브-앤-스포크 네트워크에서 NAT는 내부 시스템을 외부와 안전하게 연결하고, 주소 공간을 효과적으로 관리하며, 트래픽을 제어하여 보안을 강화하는 핵심 요소로 작용합니다. 이를 통해 전체 네트워크 구조가 안정적이고 효율적으로 운영될 수 있습니다. 결론 최종적으로, NAT 게이트웨이를 영역 스택 패턴으로 구성함으로써 클라우드 환경에서 안정성과 가용성을 강화할 수 있습니다. 이 패턴은 각 가용성 영역에 고유한 NAT 게이트웨이 리소스와 관련된 가상 머신 인스턴스를 구성하여 영역 간 격리를 강화하며, 장애 시에도 지속적인 서비스 제공을 가능하게 합니다. 영역 간에 분산된 NAT 게이트웨이 리소스는 안정성을 확보하면서도 확장성과 성능 면에서 클라우드 인프라의 최적화를 도모합니다. 이러한 설계 접근은 클라우드 환경에서의 신뢰성 있는 네트워크 인프라를 구현하고자 하는 기업들에게 중요한 고려사항입니다. 영역 스택 패턴은 영역 간의 독립성과 안정성을 강조하며, 클라우드 기반 서비스의 운영 효율성과 안전성을 향상시키는 데에 기여합니다. 따라서 NAT 게이트웨이와 가상 머신 인스턴스를 조율한 이러한 설계는 안정적이고 신뢰성 있는 클라우드 네트워크 환경을 제공하기 위한 핵심 전략 중 하나로 부각되고 있습니다. 사실 AWS 의 NAT Gateway와 거의 일치하며 AWS 의 NAT Gateway 는 매우 오래전에 나왔으나 Azure 에서는 AZ 영역과 함께 나온지 얼마 안되서 항상 필요했던 제품입니다. 조금 늦게 나오긴 했지만 AZ와 함께 더 높은 보안 그리고 안정성 을 위한 아키텍처를 또다시 만들수 있습니다. AZ와 NAT 게이트웨이로 기존의 네트워크 아키텍처는 완전히 새롭게 변경할수 있으며 자유도가 매우 높아졌습니다.  간단히 테스트 할때는 AZ 하나에 NAT 를 만들어도 작동하지만 기본적으로 AZ 당 NAT 를 사용하는것은 매우 일반적입니다. 그러나 쉽게 지나칠수 있는 부분입니다.   Reference Link Azure NAT GATEWAY]]> Tue, 20 Jun 2023 21:40:34 +0000 Azure 클라우드 <![CDATA[Azure 에서 엔터프라이즈 DevOps 란?]]> DevOps 란 이제 DevOps 라는 문화가 시작된것은 80년대 90년대 초반입니다. 철학과 개념은 이렇게 오래 되었으면 이미 이론적으로 개발과 운영 사이에 협업에 대한 룰과 중요성은 오래전부터 대두되었습니다. 실제적으로 한국 이외에 지역에서도 이제는 매우 쉽게 접할수 있는 문화이며 역활입니다.  누군가는 DevOps 는 문화이지 역할이 아니라고 반문하는 사람도 있으며 단어에 대한 정의가 어려울만큼 범위가 넓습니다. 딱 한가지 Definition 과 범위가 넓다보니깐 평가와 범위가 제각각이며 각 조직 문화에서 쉽게 흡수 하기 어렵습니다. 제 개인적인 범위는 문화입니다. 범위는 조직 내에서 R&R 을 직접 만들어가는 부분입니다. 이것이 답이다 라는 것은 세상에 없습니다. 그러나 일반적으로 통용되는 부분은 있으며 그 일반화의 첫걸음은 Agile 입니다. 애자일과 DevOps 는 둘다 소프트웨어 개발 방법론 입니다.서로 다른 측면에서 조직의 작업 방식을 개선하는 데 초점을 맞추고 있습니다. 이 두 가지는 상호 보완적이며 협력적인 요소가 많아, 현대적인 소프트웨어 개발에서 더 나은 결과를 얻는 데 도움이 됩니다. 개발 프로세스를 유연하고 적응 가능하게 만들기 위한 철학으로, 소프트웨어를 조금씩, 반복적으로 개발하고 배포하는 방식을 강조합니다. 작은 단위의 작업을 계속해서 완료함으로써 빠르게 피드백을 받고, 변경사항을 수용하여 최종 제품을 개선합니다. 애자일은 고객 요구사항의 변화에 빠르게 대응하고, 개발 과정을 지속적으로 향상시킬 수 있는 프레임워크를 제공합니다. DevOps는 소프트웨어 개발과 운영(Operation) 사이의 경계를 허물고, 두 영역 간의 협업과 소통을 강조합니다. 개발과 운영 팀 간의 경계를 줄이고, 자동화 및 지속적 통합/지속적 전달 (CI/CD) 같은 도구를 사용하여 소프트웨어 개발과 배포 프로세스를 향상시킵니다. DevOps는 더 빠르고 안정적인 제품 출시를 목표로 하며, 개발과 운영 팀 간의 협력을 강조하여 문제를 신속하게 해결하고 지속적으로 제품을 향상시킵니다. 이 둘의 상관 관계는 개발 주기의 다양한 단계에서 협력하고 통합하여 소프트웨어 제공을 향상시키는 데 있습니다. 애자일은 빠른 개발과 변화에 초점을 맞추고, DevOps는 더 빠르고 안정적인 배포를 가능하게 함으로써 함께 작동합니다. 두 방법론을 통합하면 개발과 운영 간의 장벽을 줄이고 팀 간의 협력을 강화하여 소프트웨어 제공 과정을 더욱 효율적으로 만들 수 있습니다.   DevOps 범위   이글은 대기업 엔터프라이즈 기준으로의 DevOps 의 범위입니다. 제가 기준으로 잡는 Enterprise 회사에서 구직 시장에서 수많은 이력서를 리뷰 하는 입장에서 보면 DevOps라고 하면 k8s CI/CD 가 부각되고 이것이 DevOps 라고 생각하는 무지한 사람이 많습니다. 전혀 잘못된 이해 입니다.소규모 게임 회사에서는 다를수 있습니다. 이 글에서는 소규모 회사의 DevOps 를 다루지 않습니다. DevOps는 범위가 매우 넓습니다. DevOps는 소프트웨어 개발과 운영(Operation) 사이의 경계를 허물고, 두 영역 간의 협업과 소통을 강조합니다. 개발과 운영 팀 간의 경계를 줄이고, 자동화 및 지속적 통합/지속적 전달 (CI/CD) 같은 도구를 사용하여 소프트웨어 개발과 배포 프로세스를 향상시킵니다. DevOps는 더 빠르고 안정적인 제품 출시를 목표로 하며, 개발과 운영 팀 간의 협력을 강조하여 문제를 신속하게 해결하고 지속적으로 제품을 향상시킵니다. 라는 데피니션을 Wiki 에서 가져와 봅니다. 정의에 대한 내용만 보면 DevOps 는 개발도 하고 운영도 하고 다하라는 말입니다. 예전에 유행하던 풀스택 엔지니어 랑 비슷합니다. 이력서에 풀스택 엔지니어라고 써있는 분은 믿거(믿고 거른다) 합니다. 이거저거 주서서 해봤어요라는 뜻입니다.물론 정말 높은 수준에 풀스택 엔지니어를 본적 있지만 예외사항입니다. 대부분 수준 낮게 범위 넓은 경우가 대부분이므로 일반화 할수 있다고 생각합니다. 그러면 DevOps 에 정의의 범위는 개발과 운영 팀 간의 경계를 줄이고 이말에서 초점을 맞출 필요가 있습니다. Devops란 단어는 2개로 쪼개 질수 있습니다. 1번 : 개발 | DevOps | SRE 3개의 조직 2번 : 개발 | DevOps 2개의 조직 대부분 2번의 조직으로 쪼개지는 방향으로 가고 있습니다.그렇다면  기존의 SRE 가 하던 모든 구축 부분에 모든 부분을 포함 합니다. 2번 조직에서는 DevOps 란 단어에서 이미 SRE와 DevOps는 분리될수 없습니다. SRE 가 하던 모든 부분을 포함 해야합니다. 일부회사에서는 1번 조직 처럼 SRE 와 DevOps 가 분리된 회사도 있지만 실제적으로 DevOps 부분과 SRE 에 대한 R&R을 나누기 매우 애매합니다. 예를들어 SRE 와 DevOps 가 분리 되어 있다면 DevOps 의 일이 Dev에 맞춰 집니다. 또한 구축과 운영을 보통 SRE 가 한다면 DevOps는 CI/CD 에 중점 할수 있습니다. K8s의 경우 인프라면 SRE가 한다면 k8s 내부 helm은 DevOps가 관리 할수 있습니다.   제 개인적인 의견은 2번이 올바른 방법이라고 생각 할 수 있습니다. 그러나 이런 부분이 R&R이 정확히 나누어 지지 않는다면 DevOps 는 잡부처럼 이거저거 다하는 잡부 로 취급 당하기 일수 입니다.  그러므로 이 범위는 매우 중요합니다. 또한 이 범위에 함께 인원수가 충분히 확보되어야 합니다. 대부분 회사는 인원수가 충분히 확보되는 회사는 없습니다. 그러므로 여러가지 방법을 통해 잘 R&R를 나누어야 합니다.    엔터프라이즈 DevOps 범위   개인적인 제가 경험한 것은 이렇습니다. 인원수가 충분히 확보되지 않는 상황이 었으며 2번 조직이었습니다. 2번 조직은 SRE 가 없기 때문에 이거저거 다해야됩니다. 그러므로 개발자와 R&R을 정확히 나누었습니다. 예를들어 실제 개발자가 많은 부분을 도와줬습니다. 도와줬다는 것은 R&R 을 잘 나눠줬다는 뜻입니다. DevOps 팀은 개발과 운영을 위한 팀이며 지원 조직입니다.이를 위해서 개발과 운영을 한번에 할수 있는 팀을 만들면 안됩니다. 왜냐면 기본적으로 프로젝트나 스크럼 별로 운영될 것입니다. 그러므로 각 스크럼과 프로젝트에 DevOps 엔지니어가 각각 존재하게 됩니다. 조그만 회사에서는 이런 부분이 충분히 장점이 될수 있습니다. 그러나 엔터프라이즈 회사에서 조그만 회사에 각 스크럼 마다 Devops 거버넌스 없이 개발에 초점을 맞춰서 만들은 적이 있습니다. 대 환장의 개판이 만들어집니다. 개발에 초점을 맞춰서 보안과 거버넌스 없이 항상 예외상황만 존재하게 됩니다. 거버넌스는 항상 예외로 빠지게 됩니다. 무조건 엔터프라이즈에서는 DevOps 팀이 따로 존재하고 컨트롤 타워가 있어서 거버넌스를 관장하고 보안을 유지시켜야 합니다. DevOps 문화가 만들어지려면 엔터프라이즈 회사는 뿌리부터 변경되어야합니다.    단점 자 장점만 있나요? 잠깐 보기에는 완벽한 문화이며 단점이 없을까요? 제가 직접 경험한 DevOps 문화에대해서 좀더 자세히 말해보겠습니다.  예를들어 CI/CD 부분에서 여러가지 방법이 있겠지만 우리는 최신 GitHub Action으로 통일 했습니다. 그리고 action에 대한 스크립트에 기본 템플릿은 DevOps가 진행하고 나머지 빌드 과정은 개발자 맡아줬습니다. 처음부터 끝까지 CI/CD 를 DevOps가 하기에는 너무 일이 많았기때문에 개발자들의 도움으로 정확히 R&R을 나눌수 있었습니다 쿠버네티스 부분은 DevOps 부분에서 구축 운영에서 모든 부분을  DevOps 가 맡았습니다. 만약 SRE가 나누어진 조직이었다면 SRE 는 쿠버네티스 인프라 구축을 테라폼으로 하고 나머지 k8s의 내부는 DevOps 가 하면 될수 있습니다. 가상머신의 경우 여러 의견이 달라질수 있습니다. 그러나 보통 엔터프라이즈에서 가상머신 내부는 개발자의 영역으로 합니다. SRE 나 DevOps 는 가상머신 바깥부분의 테라폼이나 IaC를 맡게 됩니다. 예전에는 WAS WEB 서버의 경우 는 SRE가 많이 커버를 했으나 근래에는 개발자의 영역으로 편입되는 추세입니다. 컨테이너가 일반화 되면서 이런 트렌드가 변화됬습니다.    애자일과 DevOps 의 상관관계 DevOps는 소프트웨어 개발과 운영을 통합하고 더 빠르고 신속한 배포를 가능하게 하는 문화와 방법론입니다. DevOps 운동의 정확한 시작일을 특정하기는 어려운데, 2009년에 Patrick Debois와 Andrew Clay Shafer가 개최한 "DevOpsDays" 행사가 이 개념을 널리 알린 계기로 여겨집니다. 이 행사 이후에 DevOps가 점차적으로 산업 전반으로 확산되고 발전해왔습니다. 그러나 DevOps의 철학과 개념은 이전부터도 개발과 운영 사이의 협업을 강조하는 원칙들은 존재했습니다. 협업이란 말을 통해 R&R을 정하긴 어렵습니다. 서로 내일 아니야 라는 마인드가 생긴다면 이런 문화는 쉽게 적응 할 수 없습니다. DevOps는 소프트웨어 개발과 운영(Operation) 사이의 경계를 허물고, 두 영역 간의 협업과 소통을 강조합니다. 개발과 운영 팀 간의 경계를 줄이고, 자동화 및 지속적 통합/지속적 전달 (CI/CD) 같은 도구를 사용하여 소프트웨어 개발과 배포 프로세스를 향상시킵니다. DevOps는 더 빠르고 안정적인 제품 출시를 목표로 하며, 개발과 운영 팀 간의 협력을 강조하여 문제를 신속하게 해결하고 지속적으로 제품을 향상시킵니다. 이 둘의 상관 관계는 개발 주기의 다양한 단계에서 협력하고 통합하여 소프트웨어 제공을 향상시키는 데 있습니다. 애자일은 빠른 개발과 변화에 초점을 맞추고, DevOps는 더 빠르고 안정적인 배포를 가능하게 함으로써 함께 작동합니다. 두 방법론을 통합하면 개발과 운영 간의 장벽을 줄이고 팀 간의 협력을 강화하여 소프트웨어 제공 과정을 더욱 효율적으로 만들 수 있습니다.   DevSecOps VS DevOpsSec   DevSecOps는 개발, 보안, 운영을 통합하여 소프트웨어 개발 과정에 보안을 포함하는 개념입니다. 벌써부터 이거저거 전부하는 느낌이 들죠.이 방법론은 소프트웨어 개발 초기부터 보안을 고려하고, 보안 요소를 지속적으로 통합하여 개발과 배포 단계에서 보안 문제를 빠르게 식별하고 해결합니다. DevSecOps는 보안 테스트, 취약점 분석, 보안 정책 준수 등의 작업을 개발 프로세스의 일부로 채택하여, 개발 속도와 보안을 균형있게 유지하려는 노력을 강조합니다.   DevOpsSec는 DevOps와 비슷한 개념이지만, DevOpsSec는 DevOps 방법론의 중심에 보안을 추가하는 개념입니다. 이는 보안을 주요한 요소로 간주하며, DevOps 프로세스의 중요한 부분으로서 보안을 통합하는 것을 강조합니다. 따라서 DevOpsSec는 보안을 개발과 배포 프로세스에 중점을 두고 이를 포함시키는 것을 강조합니다. 이 둘의 차이점은 주로 보안을 어떻게 통합하고 강조하는지에 있습니다. DevSecOps는 보안을 개발 프로세스의 일부로써 내재화하고 강조하는 반면, DevOpsSec는 보안을 DevOps의 중심에 위치시켜 소프트웨어 제공과정에서 보안을 더 강조합니다. 결국 두 용어 모두 보안을 소프트웨어 개발의 핵심으로 내재화하고, 보안 측면을 지속적으로 강화하려는 노력을 대변하지만, 그 강조 방식에 있어서 약간의 차이가 있습니다. 선조치 와 후조치의 차이입니다.   Azure를 활용한 DevSecOps 는 어떻게 할수 있을까요? DevSecOps는 개발, 운영 및 보안을 통합하여 소프트웨어 제공 과정에서 보안을 강화하는 방법입니다. Azure는 클라우드 기반의 다양한 서비스와 도구를 제공하여 DevSecOps를 적용하기에 이상적인 환경을 제공합니다. 일반적인 방법은 마이크로 소프트 공식 문서에 잘나와있습니다. 저는 좀 다른 시각에서 생각해봤습니다. 예를들어 공식문서에서는 Azure DevOps 를 활용한 CI/CD 로 구축하는 것을 가이드합니다. 그러나 제 의견은 조금 다릅니다.  Azure DevOps 는 매우 훌륭한 툴이지만 아직 다른 오래된 탄탄한 툴을 커버하기에는 약합니다. 예를 들어 아틀라시안 제품과 비교하면 몇몇 제품은 Azure 제품이 인테그레이션 부분에서는 무조건 강점을 가집니다. 그러나 Jira 나 Confluence 부분은 Azure DevOps 의 기능보다 훨씬 앞서 있는 것이 사실입니다.  1.Security Center 활용 Azure Security Center를 사용하여 클라우드 인프라와 애플리케이션의 보안 상태를 모니터링하고 관리합니다. 보안 정책 준수를 강화하고, 취약점을 식별하고 보안 위협에 대응합니다. 기본적으로 이를 대체할수 있는 3rd 파티의 툴은 비용 천문학적으로 비쌉니다. 엔터프라이즈 급에서 사용할수 있는 툴은 매우 비싸지만 이에 비해 Azure Security Center는 극단적으로 비용이 싸기 때문에 기능적 부족함은 다른 툴들과 혼합해야 합니다.2Azure Key Vault를 통한 보안 관리 2.Azure Key Vault를 활용하여 보안에 민감한 정보(비밀, 인증서 등)를 안전하게 저장하고 관리합니다. 애플리케이션에서 필요한 보안 자격 증명 및 비밀을 중앙 집중화하여 보안을 강화합니다. 3.Azure Policy를 사용한 규정 준수 강화 Azure Policy를 사용하여 클라우드 리소스의 구성 및 운영을 규정 준수에 맞게 제어합니다. 보안, 규정 준수, 리소스 관리 등을 자동화하여 보안을 강화합니다. 4.Azure 자동화 및 템플릿화 Azure Resource Manager 템플릿을 사용하여 인프라 및 리소스 배포를 자동화합니다. 인프라 구성을 코드로 관리하여 보안 설정을 표준화하고 반복 가능하게 만듭니다. ARM 템플릿은 암에 걸릴수 있습니다. Bicep은 아직 미성숙입니다. 테라폼을 추천 드립니다. 5.Azure Monitor 및 보안 로그 분석 Azure Monitor와 Log Analytics를 활용하여 클라우드 리소스의 상태와 보안 로그를 모니터링하고 분석합니다. 이를 통해 보안 위협을 식별하고 대응합니다. Azure 모니터로 다른 서드파티 툴과 정식으로 비교하긴 조금 어렵습니다. 예를들어 DataDog 이나 NewRelic 과 같은 모니터링 툴은 비용이 매우 비싸기 때문에 저는 개인적으로 Azure Monitor 가 기능은 조금 부족하지만 결과물은 만족스럽습니다. 6.Identity 및 Access Management Azure Active Directory를 활용하여 Identity 및 Access Management를 통합 관리하고 보안을 강화합니다. 다단계 인증, 역할 기반의 액세스 제어 등을 구현합니다. AAD 는 이제 Microsoft Entra ID로 이름이 변경 됬습니다. 사실 이 제품을 다른 어떤 엑세스 툴과 비교한다는 것은 저는 불가능하다고 생각합니다. 이부분은 MS 가 타의 추종을 불허 합니다.    결론 DevSecOps를 성공적으로 구현하기 위해서는 지속적인 개선과 자동화를 추구하며 문화를 바꿔야 합니다. 그래서 엔터프라이즈 회사에 매우 어울리지 않습니다. 그러나 천천히 적용하고 만들어 간다면 불가능한 일이 아닙니다. 가장 중요한 부분은 하이 레벨의 인원들의 인식의 변화가 필요하며  변화된 조직을 만드는 의지가 가장 중요합니다. DevSecOps  는 소규모 회사에 어울리지만 엔터프라이즈 대기업에서 분명 가능합니다. 회사 내부의 팀간의 의지와 협력이 매우 중요하지만 실제 회사 내부에서 팀간의 R&R 싸움은 쉽지 않습니다. 서로 다른 KPI와 입장차가 있기 때문입니다. DevOps 문화는 분명 새로운 문화이므로 저항하는 사람도 많고 쉽게 되는 것은 아닙니다.   참고 자료들 Atlassian DevOps https://www.atlassian.com/devops/ Puppet DevOps https://www.puppet.com/blog/what-is-devops-engineer Microsoft DevOps https://clouddamcdnprodep.azureedge.net/gdc/gdcmW7pGh/original Datadog DevOps https://www.datadoghq.com/ko/resources/devsecops-maturity-model/]]> Tue, 06 Jun 2023 17:56:20 +0000 서버 설계 <![CDATA[Azure + DataDog 연동하기]]> Azure + DataDog 연동하기 Azure 에서 데이터독을 사용하는 방법은 매우 여러가지가 제공됩니다.그중에 가장 쉽게 제공하는 방법은 Azure Entre ID(구 Azure Active Directory)에서 데이터독을 앱을 등록 해서 권한을 가진 앱등록을 하면 Azure 의 모니터링을 통해서 DataDog 에서 Azure API를 사용해서 모든 모니터링 정보를 가져올수 있습니다.  기본적으로 이 hand-on 은 사용 가능한 Azure 계정과 Datadog 계정이 필요합니다. 빠르게 바뀌는 Azure 및 Datadog 의 공식문서는 너무 오래전 방법이며 최신 업데이트가 안되어 있습니다. 사실 클라우드 세상에서 UI는 일주일이나 2-3주 사이에도매번 변화하는 세상이라서 공식문서의 스크린샷이 내가 필요한 시점에서 맞는 방법으로 가이드를 하는 경우는 없습니다. 예를들어. Azure Active Directory 는 이제 Azure Entre ID 로 바뀌었고 포털 안에 들어가서도 UI는 매번 바뀌게 됩니다. 기본적으로 공식문서는 가이드의 큰 틀만 주지 세부 사항은 친절하게 주지 않습니다. Azure 도 마찬가지 이며 DataDog 도 마찬가지 입니다. 기능도 매번 변경되서 관심에서 잠깐 멀어지면 새로운 Digging 이 필요합니다. 기본적으로 여러가지 방법중에서 Azure 의 경우 이런 3rd Party의 경우 앱 등록을 하고 그 앱에 대한 유효성 및 권한을 자체를 Service Principal 로 권한을 부여합니다. 앱에 대한 방법은 매우 현대적이고 권한 부여 및 최소 권한 원칙과 디폴트로 유효기간을 설정해야 하므로 보안적에서 매우 매력적입니다. AWS 의 경우 IAM 으로 Datadog 이 권한을 가져오기 때문에 수동으로 IAM 을 관리 해야 하며 유효기간 설정도 수동으로 해야 합니다. 이런 조그만 부분이 보안에 구멍을 만드므로 AWS 도 방식이 바뀌어야 한다고 생각합니다. AWS 의 경우 CloudFormation 으로 설정을 자동으로 하게 해주는 방식을 Datadog에서 제공하며 Azure 의 경우 Azure ARM Template 으로 자동 설정을 해주는 방식입니다. 요즘은 AWS CDK 나 Azure Bicep 도 지원해야하는 것이 아닌가? 하는 생각도 듭니다. Azure 의 경우 매우 독특하게 Azure native ISV service 란 제품으로 도 가능합니다.이기능은 Azure 포털 안에서 DataDog 을 바로 연결해서 Datadog organization을 만들거나 연동할수 있는 기능인데.. 매우 편한 기능이긴 한데 아직 West US2 만 지원을 해서 아직은 반쪽짜리 제품입니다. DataDog 은 ORG 의 위치에 따라 독립적이기 때문에 West US2 만 지원되는 것은 곧 업데이트 되어야 할것으로 보입니다. CLI 로 하는 방법이 가장 변화가 적기 때문에 CLI로 하는 방법을 하고 싶지만 포털에서 해보겠습니다.   1.데이터독에 접속 해서 왼쪽 빨간 창에 Integrations 을 선택합니다. 그리고 Azure 라고 서칭창에 쓴후 Azure Integrations을 시작 해 봅니다. 다양한 방법으로 Datadog 에 연동하는 방법이 있지만 가장 쉬운 방법을 먼저 해보겠습니다. azure 그림001 2. 그림002 처럼 Azure 의 경우 매우 독특하게 Azure native ISV service 란 제품으로 도 가능합니다. 이기능은 Azure 포털 안에서 DataDog 을 바로 연결해서 Datadog organization을 만들거나 연동할수 있는 기능인데.. 매우 편한 기능이긴 한데 아직 West US2 만 지원을 해서 아직은 반쪽짜리 제품입니다. DataDog 은 ORG 의 위치에 따라 독립적이기 때문에 West US2 만 지원되는 것은 곧 업데이트 되어야 할것으로 보입니다. azure 그림002 3. Azure Portal 의 서칭 창에서 Azure Entre ID 를 서칭 합니다. 이 제품이 구 Azure Active Directory입니다. 이름이 변경 됐지만 이부분이 업데이트 된 공식문서는 그리 많지 않습니다. azure 그림003 4. Entra ID 에서 App registrations 를 선택하고 + New Registration 을 선택합니다. azure 그림004 5.애플리케이션을 등록 해서 Datadog 이 앱으로 서 권한을 가지게 만들어야 합니다. 하기 정보 입력 앱 이름 Datadog Thanos 계정 유형 Accounts in this organizational directory only (Default Directory only - Single tenant) 리디렉션 URL : https://app.datadoghq.com azure 그림005 Application (client) ID 어딘가에 이 스트링을 적어놓아야 데이터독에 등록 가능 Object ID 필요없음 Directory (tenant) ID 어딘가에 이 스트링을 적어놓아야 데이터독에 등록 가능 Value 필요없음 Secret id 어딘가에 이 스트링을 적어놓아야 데이터독에 등록 가능 이 3개의 정보를 기록 해놓고 Datadog 에 연동해야 합니다.   6.Azure 포털에서 Subscription 구독을 선택하고 권한을 줘야 합니다. 하기 그림처럼 구독-> IAM -> +Add 를 선택하고 Role Assignment 를 선택합니다. azure 그림006 7. 역할을 추가 하는데 이중에 integration 만 할 예정이므로 monitoring Reader 를 선택하고 Next 를 선택합니다. azure 그림007 8.맴버 탭에서 애플리케이션에서 등록한 Datadog Thanos 를 찾습니다. azure 그림008 9.Datadog Thanos 를 선택합니다. azure 그림009 10. 다시 Entra ID로 돌아가서 그림010 처럼 Certificates & secrets 를 선택하고 새로운 키를 만듭니다. azure 그림010 11.새로운 키에 대한 유효기간을 설정합니다. 이부분이 매우 좋은 프로세스입니다. 최소 권한 원칙 및 유효기간을 설정할수 있는 부분이 보안에 매우 좋은 예라고 할수 있습니다. azure 그림011 12.데이터독 포털로 돌아가서 Integrations 탭을 선택하고 Configuration을 선택하면 2가지 선택지가 나옵니다. 한개는 Azure ARM Template으로 하는 방법과 수동으로 하는 방법이 나옵니다. ARM 이 더 쉽지만 우리는 수동 유저이므로 어려운길을 택했습니다. 사실 Bicep 도 선택지가 추후에는 있어야 할듯 합니다. 윗단계에서 적어놓은 3가지 값을 카피해서 넣으면 연동이 마무리 됩니다. azure 그림012 13.인테그레이션 탭을 확인하면 테스트용도의 2개의 Azure VM 이 연동된것을 볼수 있습니다. azure 그림013 14.당연하게도 Datadog 에 제공한 Azure 모니터링 Reader 권한이므로 딱 거기까지만 보입니다. 예를들어 RAM 이나 더 많은 메트릭을 보기 위해서는 Agent를 설치 해야 합니다. DataDog 이 연동안한 정보까지는 볼수 없습니다. azure 그림014 azure 그림015 15.DataDog 대시보드 탭에서 보면 디폴트 Azure 인프라 모니터링 을 보면 하기 그림015처럼 여러가지 다양한 대시보드를 원하는대로 커스텀이 가능합니다.   결론  AWS 에 비해 Azure는 예전보다는 많은 제품을 커버해주긴 하지만 아직도 많은 제품이 연동 안되는 부분이 있습니다. 인테그레이션만 보여준 기초이지만 다양한 기능을 연동하기 위해서 다양한 방법을 사용해야 합니다. Datadog은 모니터링 및 분석 도구로 클라우드에서 유명합니다. 시스템의 성능을 실시간으로 모니터링하고 문제를 신속하게 해결하는 데 도움을 줍니다. 다양한 데이터 소스를 통해 종합적인 시각화와 분석을 제공하여, 운영 효율성을 높이고 문제 발생을 최소화하는 데 도움이 됩니다. 하지만 어떤 도구를 선택할지는 사용하는 상황과 필요에 따라 다를 수 있습니다. 조직의 요구 사항, 기술 스택, 비즈니스 목표 등을 고려하여 적합한 도구를 선택하는 것이 중요합니다. 어떤 도구를 사용하는, 적절한 구성과 사용법을 이해하고 효과적으로 활용하는 것이 성공에 중요한 포인트입니다. 또한 가장 중요한 포인트는 Datadog은 기본적으로 비싸기때문에 잘 옵티마이즈 해서 필요한 부분만 사용하는 것이 필요합니다. 다른 툴에 비해 현재는 매우 상위권 제품은 확실합니다. 근래에는 데이터독이 보안에 초점을 맞춰서 다양한 제품을 내놓고 있으며 이에 따라  모니터링 솔루션만으로는 더 큰 비전을 볼수 없기 때문에 새로운 도전을 하는 듯 합니다.]]> Thu, 18 May 2023 10:39:21 +0000 Azure 클라우드 <![CDATA[Azure Blob Cold 티어 (프리뷰) - Azure Blob Storage Cold Tier Preview]]> Azure Blob Cold 티어 (프리뷰) 드디어 Azure 에도 Cold 티어가 추가 됩니다. 매우 오랫동안 기다려 왔습니다.현재는 프리뷰이며 Azure Blob Storage의 Cold 티어에 대한 프리뷰에 대한 글을 쓰려고 합니다. Azure Blob Storage은 클라우드 기반의 객체 스토리지 서비스로, 대용량의 데이터를 안정적으로 저장하고 관리할 수 있도록 도와줍니다. 그 중 Cold 티어는 자주 액세스하지 않는 데이터를 저장하기에 적합한 옵션으로, 더 낮은 비용으로 데이터를 보관할 수 있습니다. 이번 블로그에서는 Azure Blob Storage의 Cold 티어가 어떤 특징을 가지고 있는지, 어떤 경우에 사용하는 것이 적합한지, 그리고 주의해야 할 사항 등을 다룰 예정입니다. 함께 Azure Blob Storage의 Cool 티어에 대해 알아보도록 하겠습니다. 현재는 프리뷰 입니다. 스토리지 클래스는 의료 이미지 또는 뉴스 미디어 자산과 같이 거의 액세스하지 않고 밀리초 검색이 필요한 수명이 긴 데이터를 위한 저비용 스토리지를 제공합니다. 티어가 낮은 저장소인데 밀리초로 검색이 가능합니다. 기존의 의료 이미지와 같은 이미지의 경우 거의 접속하지 않지만 Archive 티어에 넣으면 검색이 밀리초 단위로 되지 않는 단점이 있어서 Cool 티어에 저장 해야 했습니다.  물론 티어 마다 장단점이 있고 정확히 사용처가 전부 다릅니다. 경쟁사인 AWS에 S3 Glacier Instant Retrieval 는 2022년도에 출시 되었으므로 조금 늦게 프리뷰가 된것입니다. 물론 늦게 출시된 만큼 더 많은 선택과 옵션을 제공합니다. AWS 에서는 Cold 티어가 없지만 S3 Glacier Instant Retrieval 이 Azure Cold 티어와 거의 일치 합니다. 2023 현재 사용 가능한 지역 캐나다 중부, 캐나다 동부, 프랑스 중부, 프랑스 남부 및 한국 중부 지역에서 사용 가능합니다. Cold 티어가 나온 이유 Azure Cold 티어은 거의 액세스하지 않는(평균적으로 분기에 한 번) 데이터가 있고 밀리초 검색 시간이 필요한 경우에 이상적입니다. Cool 티어와 동일한 짧은 지연 시간과 높은 처리량 성능이 필요한 데이터용으로 특별히 구축된 스토리지이지만 Cool 티어보다 데이터 액세스 빈도가 낮고 스토리지 가격이 낮고 데이터 액세스 요금이 약간 더 높습니다. 쉽게 말하면 티어 보다 저장 비용은 낮고 액세스 할때 API 비용이 더 높다는 말로 해석됩니다. 가용성과 내구성은? 99.9% 의 가용성을 가지며 가용성이 99% 미만인 경우는 SLA 따라 보상됩니다. 어떤 성능을 기대할 수 있나요? Azure Blob Storage의 Azure Cold 티어 티어는 보관 중인 데이터에 대한 액세스 빈도가 낮은 경우에 최적화된 스토리지 계층입니다. 따라서 Azure Cold 티어를 사용하면 더 저렴한 비용으로 데이터를 보관할 수 있습니다. Azure Cold 티어는 주로 데이터를 저장하는 데 사용되며, 데이터를 검색하거나 변경하는 데는 일반적으로 더 오랜 시간이 소요될 수 있습니다. 이는 주로 디스크 회전 속도가 느리기 때문입니다. 그러나 일반 티어와는 다르게 Cool 티어는 데이터를 읽는 데 더 높은 처리량(throughput)을 제공합니다. 이는 데이터가 저장되어 있는 디스크의 큰 블록 단위로 읽기 때문입니다. 따라서 Azure Cold 티어를 사용할 때에는 데이터를 자주 액세스하지 않는 것이 중요합니다. 주로 장기 보존을 목적으로 사용되며, 적은 비용으로 데이터를 안정적으로 보관할 수 있는 장점이 있습니다. 그러나 빠른 액세스가 필요한 경우에는 일반 티어나 Hot이나 Cool 티어를 사용하는 것이 더 적합합니다. 요금 Azure Cold 티어은 월별 스토리지, 요청 유형에 따른 요청 및 데이터 검색에 대해 요금을 부과합니다. 한 달에 청구되는 스토리지 볼륨은 월간 기가바이트(GB-월)로 측정된 한 달 동안 사용된 평균 스토리지를 기반으로 합니다. PUT, COPY 및 GET과 같은 요청 유형에 따라 요청에 대한 요금이 부과됩니다. 또한 반환된 데이터의 모든 기가바이트에 대해 GB당 요금을 지불합니다. 현재는 프리뷰이므로 비용이 공식 홈페이지에 나오지 않고 있지만 제가 생각하는  예상 가격으로는 Cool 티어(LRS) 가 기가당 East US 에서0.01 불 정도 되므로 0.004 불 의 가격으로 나올 것입니다 . AWS에 S3 Glacier Instant Retrieval 가격이 그정도 이므로 제 예상이 거의 맞을 것으로 보입니다. 기가당 58원(현재 환율) 이면 매우 매력적인 가격이며 Archive로 가기 직전에 쓰기 매우 좋은 티어 입니다. 최소 권장 데이터 보존 기간 Hot 티어 - 최소 보존 기간 없음 Cool 티어 - 30일 Cold 티어 - 90일 Archive 티어 - 180일 최소 권장 데이터 보존 기간 전에 삭제 하면 남은 기간을 고려해서 삭제 비용이 추가 됩니다. 장점
  1. 비용 Archive 단계로 가기 전까진 최저 가격입니다.
  2. Cold 티어이면서도 복원 시간이 없으며 검색 시간이 빠르다. 
단점 (현재) 1.현재 포털에서만 된다. 2.Storage Explorer에서는 변경후 보이기만 한다. 3.여전히 포털에서 동시에 여러개 파일을 티어 변경이 안된다. (파워쉘로만 가능) 4.현재 비용은 나와있지 않지만 검색 비용이 Cool 티어보다 높을것이다. 5.현재 비용은 나와있지 않지만 트렌젝션 비용이 Cool 티어보다 높을것이다. 6.변경 피드는 아직 콜드 계층과 호환되지 않습니다. 7.시점 복원은 아직 콜드 계층과 호환되지 않습니다. 8.개체 복제 는 아직 콜드 계층과 호환되지 않습니다. 9.계정의 기본 액세스 계층 설정은 콜드 계층으로 설정할 수 없습니다 10.AzCopy를 사용하여 Blob을 콜드 계층으로 설정할 수 없습니다. 미리 보기 중에 Azure Portal, PowerShell 또는 Azure CLI를 사용하여 Blob의 계층을 콜드 계층으로 설정할 수 있습니다. 사용하는 방법 1.현재 프리뷰 이므로 https://forms.office.com/pages/responsepage.aspx?id=v4j5cvGGr0GRqy180BHbRxW65f1VQyNCuBHMIMBV8qlUN1IwWDBXQ1BDQ0ZIT1RRMlVHTldBTFFaRi4u 링크에서 폼을 제출하고 Cold Tier 팀이 허락하는 메일을 줘야 합니다. 하기의 스크린샷 처럼 답변이 옵니다. azure 2. 포털에 접속합니다. 3.스토리지 어카운트의 Blob에 컨테이너를 하나 만들고 동영상 mp4 파일을 업로드 합니다. 하기의 스크린샷 처럼 Hot 티어 입니다 azure 4. 하기의 스크린샷 처럼 Change Tier 를 클릭 하면 Cold 티어가 보입니다. azure 5. Cold 티어로 변경되었습니다. azure 6. Storage Explorer 에서는 티어 변경이 아직 안됩니다. azure 7. 포털에서 변경하고 나면 Cold 계층으로 변경은 됩니다. azure 8. Cold 티어이지만 URL로 접근하면 하기 스크린샷 처럼 바로 스트리밍이 됩니다. azure   결론 Azure Archive 티어는 는 긴 기간 보존할 필요가 있는 데이터에 이상적인 비용 효율적인 스토리지 서비스입니다. 하지만 데이터를 검색하는 데 소요되는 시간이 오래 걸리기 때문에 긴급한 데이터 복구 시나리오에서는 사용하기 어려웠습니다. 이를 해결하기 위해 Azure는 Azure Cold 티어을 도입했습니다. Azure Cold 티어은 기존의 Azure Archive 티어보다 빠른 검색 시간과 높은 가용성을 제공합니다. 이를 통해 긴급한 데이터 검색과 복구가 가능해졌습니다. 또한, Azure Cold 티어은 Azure Archive 티어보다 높은 가격대를 가지고 있지만, 비용을 최소화하기 위해 수명 주기 규칙과 조정 가능한 검색 수준 등을 제공합니다. 하지만, Azure Cold 티어을 사용할 때는 여전히 불리한 점이 있습니다. 가장 큰 단점은 높은 비용입니다. Azure Cold 티어은 검색된 데이터 양과 검색 횟수에 따라 비용이 결정되기 때문에 검색이 더 빈번하게 발생할수록 더 많은 비용이 발생할 수 있습니다. 또한, 검색 시간이 다른 스토리지 클래스보다 느리다는 것도 단점 중 하나입니다. 결론적으로, Azure Cold 티어은 긴급한 데이터 검색과 복구 시나리오에서 매우 유용합니다. 그러나 검색 속도와 가용성이 중요하지 않은 경우에는 기존의 Azure Archive 티어나 다른 티어를 사용하는 것이 더 경제적일 수 있습니다. 따라서 사용자는 자신의 요구 사항과 예산에 맞게 적절한 스토리지 클래스를 선택하는 것이 중요합니다. Reference Link Blob 데이터를 위한 액세스 계층    
]]> Mon, 08 May 2023 15:16:51 +0000 Azure 클라우드 <![CDATA[ChatGPT + Azure + Terraform 쳇gpt를 사용한 Azure 테라폼 해보기]]> chatgpt +terraform +azure 사용기 Chatgpt 에게 Azure 에서 테라폼을 사용하는 예시를한번 물어봤습니다. 얼마나 잘되는지 어디까지 되는지 한번 알아보려합니다. 나온지 얼마 안되서 어떤 오류가 있고 어떻게 오류를 해결하고 잘 실행 되는지 보고 문제를 해결해보겠습니다. 한글로 물어보면 잘 원하는 대답이 잘 나오지 않아서 영어로 물어보는게 좋습니다. 물어보는 질문의 단어가 조금씩 다르면 다른 답변을 줍니다. 코드를 물어보는 것이므로 다른 코드를 줍니다. please write a terraform code to create vm in azure 라고 입력했습니다. Azure에서 vm을 생성하는 terraform 코드를 작성하십시오.라고 입력했습니다. azure 그림001 azure 그림002 코드 링크 https://github.com/thanoslee369/chatgpt-terraform-azure/blob/main/gptoriginal001.tf 상단의 코드 링크에 코드는 chatgpt가 준 코드입니다.이 코드는 만약 테라폼을 아신다면 매우 낯익을수 있습니다. https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/virtual_machine 링크에 있는 코드와 유사합니다. 조각조각을 붙여서 만들어온 느낌의 답변입니다. 잘 실행 될까요? 실행이 안됩니다. 그래서 왼쪽 코드는 에러가 나지 않게 고친 코드입니다.   azure 그림003 어떻게 고쳤는지 과정을 알아볼까요? 그림003에서 1번 빨간 박스를 보면 버전 부분이 이 너무 예전 버전입니다. 최신버전이 3.43인데 이버전은 너무 낮은 버전입니다. 버전을 삭제 하면 자동으로 디폴트 버전을 사용할수 있습니다.  2번 빨간박스를 보면 address_prefix 는 주소값을 한개만 받는 예전 코드입니다. address_prefixes로 바꾸고 배열 [] 로 바꿔줍니다. 이건 예전에만 사용되던 코드입니다. 3번 빨간빡스는 dynamic 을 Dynamic으로 변경해줍니다.  4번 빨간박스는 스토리지 어카운트 이름이므로 URL이 되므로 이미 선점된 이름은 사용할 수 없습니다.그러므로 뒤에 숫자를 붙여서 유니크한 URL을 만들어 줍니다. azure 그림004 그림004에 1번 빨간 박스는 현재는 사용되지 않는 예전 코드에서만 존재하는 코드입니다. 그래서 주석 처리 했습니다. 2번 빨간 박스는 어떤 부분이  잘못되었을까요? 이름이 다른 이미지라 실행되지 않습니다. 우분투 16.04로 변경해봤습니다. azure 그림005 다고치면 이렇게 그림005처럼 잘 실행되고 리소스가 만들어 집니다. 다고쳐진 코드 링크 https://github.com/thanoslee369/chatgpt-terraform-azure/blob/main/fixedmain001.tf   azure 그림006 Azure portal에서도 잘 만들어집니다.  지금 실험은 단순히 예제를 실험한 한것입니다. Chatgpt 가 이렇게 허술한 예제만 준다면 사람들이 열광할까요? 예전코드라 실행이 안되며 여러가지 오류도 있습니다.  자 좀더 심화된 테스트를 해보겠습니다.  Chatgpt에게 좀더 여러가지 질문을 한번에 해보고 코드를 짜달라고 해보겠습니다. Can you write a terraform code to create followings A Virtual network with a cidr block of 18.2.0.0/16  Regions in korea central A subnet with cidr block 18.2.0.0/24 with vnet, and no public IP A nsg that allows incoming traffic on 22(SSH), 80(http), from 18.2.0.0/16 Virtual machine type = Standard DS1 v2 (1 vcpu, 3.5 GiB memory) Operating system is ubuntu 20.04 LTS  가상네트워크의 주소는 18.2.0.0/16이고 한국 중부에 서브넷은 18.2.0.0/16 주소이고 퍼브릭 아이피는 없이 만들어 주고 이서브넷의  22번과 80번 포트 열어주고 Standard DS1 v2 로 만들고 우분투 20.04 LTS 를 만드는 코드를 써줘 라고 질문했습니다. azure 그림007 azure 그림008 azure 그림009 그림007 008 009가 chatgpt의 답변입니다. 답변 코드 링크 https://github.com/thanoslee369/chatgpt-terraform-azure/blob/main/gptoriginal002.tf 이렇게 자세하게 원하는것을 넣었는데도 답변이 나오다니 chatgpt는 놀랍습니다. 잘 실행 될까요? 실행이 안됩니다. azure 그림010 첫번째 빨간박스에 버전은 2.0이므로 오래된 버전이므로 해당 부분은 삭제 했습니다. 삭제하면 디폴트 버전이 실행됩니다 2번 빨간박스를 보면 address_prefix 는 주소값을 한개만 받는 예전 코드입니다. address_prefixes로 바꾸고 배열 [] 로 바꿔줍니다. 이건 예전에만 사용되던 코드입니다. azure 그림011 그림011에서 이미지 이름이 다르기 때문에 이를 16.04 버전 이름으로 변경했습니다. azure 그림012 그림012에서 비밀번호는 다른 비밀번호로 변경했습니다. Chatgpt가 준 코드에서 오류를 고친 코드 링크 https://github.com/thanoslee369/chatgpt-terraform-azure/blob/main/fixedmain002.tf azure 그림013 고친 코드를 실행했습니다. 매우 잘 실행이 됩니다 azure 그림014 Azure 포털에서도 리소스가 잘 생성되었습니다. 결론 매우 간단한 테스트이지만 내가 원하는 변수를 코드에 넣어서 코드를 주는 부분이 매우 인상적입니다. 오래된 코드와 현재 코드를 섞어서 만들어 주는 부분도 인상적이며 결과 값이 무조건 실행이 되지는 않는 부분이 약간 아쉽습니다. 그러나 활용도는 매우 높을 수 있습니다. 질문에 따라서 매우 좋은 코드의 결과도 가져올 수 있으며 안되는 코드를 고쳐 주는 부분도 존재합니다. 아직 초기 품질은 약간 오류도 있고 문제도 있으며 단어 하나하나에 따라 결과 값이 좀 다른 부분도 있습니다. 그러나 확실한 건 기존에 없던 파격적 기술이라는 것은 의심이 필요 없습니다. Chatgpt로 인해 직업을 잃거나 일자리가 줄어들 수 있다는 말은 거짓이며 개발자가 코딩에서 많은 부분을 도움을 받을 수 있다 라고 표현하면 정확합니다.구글 서칭도 처음부터 완벽하진 않았습니다. 점점 발전해 나가는 부분은 기대할 만 합니다. 테라폼 모듈을 만드는 부분을 해볼 예정이며 결과가 궁금합니다. 쓰는 사람이 아주 코딩을 할 줄 모르면 디버깅이 안되기 때문에 어려울 수 있지만 테라폼을 중급만 되어도 쉽게 chatgpt를 응용 할 수 있을 듯 합니다. ]]> Thu, 16 Feb 2023 16:01:34 +0000 Azure 클라우드 <![CDATA[Azure Load Testing 가이드 2023년]]> Azure Load Testing 가이드 - Azure Load Testing guide 2023년 2월 1일 Azure 에서 로드 테스트를 진행 하는데 여러가지 가상머신위에 구축해서 사용할수 있는 방법으로 로드 테스트를 진행 할 수 있습니다. PaaS 형태나 SaaS 형태로 완전관리형 로드 부하분산 테스트를 하기 위해서 여러가지 조건을 만족시켰던 제품은 없었습니다. AWS에서도 이를 만족하는 로드 테스트 제품은 현재도 없습니다. Azure 안에서도 이런 니즈를 해결하기 위해서 Azure DevOps Jmeter 로드 테스팅이 있었으나 생각보다  기능이 부족하고 여러가지 시나리오를 다양하게 사용할 수 없었습니다. 그후에 새롭게 나온 Azure Load Testing 이라는 제품은 Azure Devops 제품안에 있는 제품이 아닌 별도의 제품으로 Azure Portal 안에서 독립된 제품입니다. 물론 DevOps와 연결도 됩니다. 깃허브랑 연동해서 엑션으로 CI/CD 를 연동하는 시나리오도 제공 됩니다. GitHub - Azure/load-testing: Automate azure load test through github actions 초보자에게 매우 쉽게 단순하게 고급 부하분산 로드테스트를 제공한다는 점에서 매우 매력적입니다.   Azure Load Testing 가장 쉬운 방법으로 사용해보기 
  1. 애저 포털 로그인하고 리소스 만들기
  2. 검색창에서 Azure Load Testing 으로 찾습니다
  3. Create 선택
  4. 리소스 그룹 만들기 rg-azure-load-testing
  5. 인스턴스 이름 azure-load-testing001
  6. 지역 east-asia 선택
  7. 만들기
  8. 빠른 테스트 만들기 선택
  9. 테스트 하고 싶은 URL 선택  cloud.syncrofusion.com
  10. 가상 사용자수를 300으로 선택 하면 2개의 인스턴스에서 테스트 가능
  11. 테스트 시간 및 테스트의 증가 시간 업데이트
  12. 테스트 후 시작
  13. 결과 보기
유튜브로 따라해보기 링크 결론 이 제품은 개발자에게 더 적은 노력으로 쉽게 로드 테스트를 할수 있도록 초점을 맞춘 제품이며 단순 URL 하나만으로 대규모 부하를 생성하고 완전 관리되는 부하 테스트를 위함입니다. 물론 Jmeter 스크립트로 자세한 결론적으로 자체적으로 로드테스트를 Jemter나 다른 툴들로 구축 할수 있는 능력을 가진 팀이나 사람이 원하는데로 커스텀 으로 결론을 도출하고 부하분산 테스트를 할수 있는 툴은 아닙니다. 쉽게 접근하고 SaaS 와 PaaS를 섞어서 사용할수 있는 부하분산 테스트 툴입니다. 목적성이 다름을 혼동해서는 안됩니다. 난는 이미 부하분산 툴을 잘 다룰지 알고 원하는 결론에 시나리오를 직접 잘 구축 할수 있다 라고 생각 되는 전문가 용이 아닙니다. 쉽게 접근 할 수 있는 제품입니다. 또한 이런 장점과 회귀 테스트 자동화 + 고급 부하 테스트 + SDK 부하 테스트 라이브러리도 제공합니다. 개인적으로 수많은 부하분산 툴들을 경험하고  커스터마이즈 해서 써본 경험이 있지만 매우 간단하고 쉽고 개발자 중심으로 쉽게 만들어져있음에 높은 점수를 줄수 있습니다. 물론 더 복잡한 시나리오와 원하는 결과값은 내기 위해 커스터마이즈는 약간 한계가 있는 것은 PaaS 제품이므로 감안해야 합니다. ]]> Mon, 06 Feb 2023 22:15:29 +0000 Azure 클라우드 <![CDATA[Terraform 명령어 terraform 를 테슬라로 바꾸는 방법]]> Terraform 명령어 terraform 를 테슬라로 바꾸는 방법

배경 하루에 몃번이나 Terraform 명령어를 치는 데 terrafrom으로 오타를 쓴것이 약 250만번쯤 되는데 이를 Tesla 로 변경하는 방법 bash 를 사용한다고 가정

bash 는 Bourne Again Shell의 약자로 유저의 Command를 받아서 장치와 연결되는 작업을 실행 할수 있는 인터프리터 입니다. 소스 코드를 직접 실행 하면서 소스코드를 변환 한것을 바로 생행 합니다. 코드를 기계어로 번역하는 컴파일러와 차이점을 가지고 있습니다.

적용 방법 Bash의 Run Commnad 인 bashrc의 위치는 다릅니다.

  1. home Directory 로 간다
  2. nano .bashrc 로 .bashrc를 편집
  3. alias tesla="terraform" 테슬라로 테라폼에 별칭을 준다.
]]> Wed, 18 Jan 2023 10:27:04 +0000 일반 게시판 <![CDATA[9개의 Azure Blob 에 숨겨진 비용]]> 9 Hidden cost of Azure Blob Storage  9개의 Azure Blob 에 숨겨진 비용 Blob 에 대한 배경 개인적으로 클라우드에서 가장 매력적이고 가장 쉽게 PaaS를 접할수 있는 제품은 저장소라고 생각을 하고 있습니다. 어떤이들은 오브젝트 스토리지는 PaaS 가 아니라 이제 기본 제품이라고 하는 의견이 있을정도로 이미 오브젝트 스토리지는 널리 사용되고 있습니다. Blob의 장점 단점 “클라우드 디스크에 비해 싼 가격” 이란 것은 필자가 온프레미스와 Blob Storage 를 비교한것이 아니며 일반적인 VM이나 EC2에 붙은 디스크와 비교해서 싼 가격이라고 언급한것입니다. 개인적으로 Pysical Hard 디스크인 SSD와 Blob Storage에 대한 비교를 하는 Cloud을 덜 이해 하신 분(?) 들은 가격이 왜 이렇게 비싸냐? 라는 소리를 많이 들어왔는데 이 부분을 이렇게 표현하고 싶습니다. 현재는 전기차가 나오는 시대이며 ADAS 및 자율주행을 기본으로 탑재한 자동차가 나오는 시점에서 1990년대에 나온 소나타가 굴러가는데는 문제가 없으며 가격이 싸다라고 비교하는 것은 비교 관점에서 아주 잘못되어 있다고 생각하며 단순 가격만 비교했기 때문이라고 생각합니다.  Blob Storage는 Cloud를 사용한 필자의 경험에서 가장 덜 고장나는 제품이며 가장 안정적이며 심지어 SDK를 제공하여 단순 코드 몇줄로 수많은 기능을 제어할수 있으며 다양한 프로그래밍 언어를 지원하는 자율주행급 차량이라고 생각하며 단순한 Physical SSD 와는 비교 자체가 되지 않는다고 생각됩니다.. 2번의 “부하 분산 설계로 대용량 트레픽”을 커버라는 말은 이미 많은 Use Cases 들이 증명하고 있으며 실제 AWS의 S3와 Azure Blob은 현재는 부하 분산에 최적화 되어 있는 PaaS 중에서 가장 좋은 제품입니다. 여러가지 부하서버를 만들어서 다양한 방법과 다양한 툴로 이 Blob과 S3을 수천번 테스트 해본 결과로 필자는 이 제품들이 가장 안정적이며 가장 안전하다고 생각을 가지고 있습니다. 물론 S3와 Blob이 장애가 난적이 없진 않지만 그 또한 HA 구성으로 설계 되어 있고 분산되었다면 당연히 막을수 있는 설계한다면 비용을 제외하고는 현존하는 끝판왕 PaaS라고 생각을 가지고 있습니다. 심지어 분산처리까지도 가능하므로…. 또한 엄청난 트래픽에서는 이 또한 분산을 위한 Blob 저장소 자체의 Sharding과 Partitioning 이 필요하며 이또한 구현되어 있습니다. 3번의 “기본 3개 복제” 는 엄청난 장점이지만 많은 사람들이 잘못 이해 하고 있는 점은 기본적으로 3개가 자동복제되며 언제나 백업처럼 쓸수 있는 기능이 Azure에서 제공하고 있다고 “굳게” 믿고 있지만 전혀 그렇지 않습니다. 이 기본 3개 복제는 LRS, GRS,  RA-GRS 로 나누어 지며 LRS는 같은 데이터센터의 어딘가 지역에 3개가 랜덤으로 복제되어 있으며 이는 리얼타임으로 3개가 복제 되는것이 전혀 아닙니다. 첫번째로 우선 리얼타임으로 복제 되지 않으며 그 레이턴시를 보장하지 않습니다.. 두번째로 백업처럼 쓸수 없다. 예를들어 GRS는 다른 데이터 센터에 복제본이 저장되며 읽을수 없다. 예를 들어 한국 남부에 저장된 GRS의 경우 데이터센터가 핵폭탄 받았을 경우 일본이나 다른 데이터센터로 자동으로 연결이 되는것이지 3개의 복사본에 접근이 되는것이 아닙니다. 또한 RA-GRS 는 읽을 수 는 있지만 리얼타임으로 저장이 되는것이 아닙니다. 그러므로 복제본이 있으며 데이터센터가 문제가 생겼을때의 복제본이 존재하는 것이지 백업이 아닙니다. 먼가 단점만 말 한거 같지만 사실 이 부분을 고려하고도 개인적으로는 최고의 객체 저장소라고 생각됩니다. “SDK를 사용하여 API로 컨트롤 가능” 대부분의 많은 언어를 지원하며 저장소 자체를 SDK로 컨트롤 할수 있으며 다양한 기능을 SDK로 제공합니다. 어떤 비 개발자들은 이렇게 물어보는 경우가 있습니다. “이거 쓰면 모두 자동인가요?” 웃긴 소리입니다. SDK까지만 제공하고 나머진 본인이 코드에 집어 넣어야하며 숟가락에 밥을 떠서 주었는데 씹어 주라는 말과 비슷하다고 생각합니다. SDK가 제공이 되어 컨트롤 할수 있는것이지 모두 자동으로 버튼만 누르면 되는것이 아니며 이 제품은 SaaS가 아닌 PaaS 입니다. 요즘 이도 저도 다 SaaS 서비스를 한다고 하는데 개인적으로 보았을때 SaaS에 대한 이해가 부족한것이 아닌가라는 극히 “개인적으로” 생각이 듭니다. 그냥 대부분에 SaaS 라는 제품들이 부하분산은 거녕 예전에 만든 앱에 로그인 붙이고 버튼 몇개 만들어 자동화 하면 모두 SaaS 인 것처럼 포장을 하는데 SaaS는 기본이 Office365처럼 부하분산은 기본으로 되어야 하며 로그인만 하면 모든것은 사용자가 처리하는 것이 기본이지 예전처럼 앱만들어서 자동화되니 SaaS라고 하는것은 어불성설입니다. “다른 PaaS에 비하여 슈퍼 안정적” 이란 말은 개인적으로 생각할때 가장 “덜” 문제가 된다는 말입니다. 슈퍼 안정적이어서 SLA 100%보장으로 절대 죽지 않는다가 아니고 “덜” 죽는다고 생각을 하고 있으며 개인 경험상 그렇습니다.. 또한 클라우드에서 SLA 보장이란 단어는 믿지 말길 바랍니다. SLA 보장은 서비스 시간 보장이지 나의 서비스가 잘못되어서 비지니스 측면에서 보장까지는 “전혀” 아니므로 이 부분에 현혹되지 않기를 바랍니다.. 그러나 다른 모든 상품보다 확실히 SLA 측면에서 좋습니다.   숨겨진 Blob 스토리지의 비용 비용
  1. 데이터 용량
  2. 다운로드 네트워크 트래픽(데이터센터 바깥으로 나가는 트래픽이며 업로드는 무료)
  3. 운영 및 데이터 전송
  4. 로그 비용
  5. 예약 용량 가격
  6. GRS 의 비용
  7. Archive 계층에 검색 비용
  8. SFTP 비용
  9. Blob 인덱스 비용
  10. 암호화 Key 볼트 비용
  11. Blob 변경 피드 비용
  Azure Blob은 10개로 비용을 정의 할 수 있습니다.  azure그림001 1.데이터 용량은 1기가의 Blob을 계층은 표준 v2 이며 핫에 LRS 를 사용하면 한달 동안 쓰면 25.34원이 나가는 부분입니다. 매우 간단하며 1기가에 대한 저장 용량 이므로 매우 직관적으로 알 수 있는 부분입니다. azure그림002 2.다운로드 네트워크 트래픽(데이터센터 바깥으로 나가는 트래픽이며 업로드는 무료) 은 계산기에 없는 내용입니다. 네트워크 트래픽을 완벽히 예측 할 수 있는 방법은 없습니다. 만약 웹서비스를 하는 입장이라면 고객이 몇 명 얼마나 들어올지 정확히 예측 할 수는 없습니다. 그러나 근사값을 예측 하는 것은 가능하며 이 부분이 근사값으로 정해 져야 하지만 Azure 계산기에서는 입력 하는 부분이 존재 하지 않습니다. 그러면 Bandwidth라는 추가 프로덕트를 선택해야 합니다 그림002는 추가로 선택한 부분입니다. 자 100기가 이하는 무료이므로 0원이 입니다. 101 기가부터는 139.38원을 부과 합니다. 101기가 마다 139.38원이 아니라 1기가에 139.38원입니다. 그러나 같은 지역에 Blob이 있고 같은 지역에 Hosting되는 VM이 있다면 그부분은 무료입니다.. 내부 Transactions은 무료라는 뜻입니다.. 그러나 만약에 서울 중부에 VM이 있고 서울 남부에 Blob이 있다면 이건 무료가 아닙니다..  3.운영 및 데이터 전송 3번은 아주 애매하며 클라우드 이전시대인 사람(1990식 소타나 세대)은 이해 하기 쉽지 않습니다.  “Rest 요청” 즉 파일에 대한 읽기, 쓰기, 불러오기, 에 대한 요청 수당 에 비용이 청구 됩니다. 어 이거 머야? 라고 생각할 수 있습니다.. 결론적으로 읽고 쓰고 하는 비용까지 청구 한다고? 생각할 수 있으며 그 부분이 정확히 맞는 것입니다. 아 피곤하게 파일을 읽고 쓰고 하는 부분까지 과금한다고? 라고 생각할 수 있으며 정확히 맞는 것입니다. 자 그러나 같은 지역에 Blob이 있고 같은 지역에 Hosting되는 VM이 있다면 그 부분은 무료입니다.. 내부 Transactions은 무료라는 뜻입니다.. 그러나 만약에 서울 중부에 VM이 있고 서울 남부에 Blob이 있다면 이건 무료가 아닙니다.. 
  • A single GetBlob request to the blob service = 1 transaction
  • PutBlob with 1 request to the blob service = 1 transaction
  • Large blob upload that results in 100 requests via PutBlock, and then 1 PutBlockList for commit = 101 transactions
  • Listing through a lot of blobs using 5 requests total (due to 4 continuation markers) = 5 transactions
오호~! 공식 문서에서 찾아본 Transaction 공식 입니다.  Blob에 있는 파일 하나를 불러오기만 해도 1 transaction이며 100개 요청의 큰 Blob 을 올린다면 한번 의 List 를 불러오므로 101번의 Transactions이라고 할 수 있습니다. 파일은 Block 단위(Max 4MB)이며 4MB 단위로 끊어져서 전송되므로 4MB 이하로 파일 관리가 되어야 더 빠르게 업로드나 다운로드 될수 있습니다. 테스트 결과 확실히 Block 단위에 따라 속도가 다릅니다. 그러므로 설계 시 이 부분을 간과해서는 안됩니다. 4MB 언더로 잡어야 되며 이 부분에 따라 속도가 많이 차이 납니다. 예를 들어 파일을 업로드 할때  Blob에 32MB짜리 파일을 업로드 한다면 라이브러리가 Blob을 각각 Block으로 짜른 후 업로드 하고 PutBlocklist를 커밋하는것입니다. 결론은 PutBlock을 1번 Transaction으로 잡고 PutBlocklist를 한번 Transaction으로 잡습니다. 이 또한 숨겨진 비용입니다. 4.로그 비용 Azure Blob 로그 비용은 기본적으로 http://<accountname>.blob.core.windows.net/$logs 에 저장되는 로그를 활성화 한다음에이에 대한 로그비용은 Blob 비용에 추가가 됩니다.이또한 숨겨진 비용입니다. 5.예약 용량 가격 기본적으로 예약 용량은 1PB 나 100TB 단위로만 예약이 가능하므로 적게 쓰시는 분은 예약 용량을 사용할 수 없습니다. 이 또한 숨겨진 비용입니다. 예약 용량 가격의 비밀 절약 옵션으로 3년을 선택하면 1PB 나 100TB 단위로만 예약을 할 수 있습니다. 6.GRS 의 비용 GRS 옵션을 선택하면 하기에 계산기 처럼 1GB 당 101.368원이 전송 비용으로 추가 됩니다. azure그림003 보통은 GRS 비용에 이 부분을 잘 보기 힘들지만 계산기에서 주의 깊게 보아야할 부분입니다. 7.Archive 계층에 검색 비용 azure그림004 그림처럼 Archive 계층에서는 검색 비용이 1GB 당 27.876으로 검색 비용이 추가 되며 이 부분을 놓치기 쉽습니다. azure그림005 8.SFTP 비용 SFTP 기능을 사용하면 시간 당 0.3달러가 추가 비용이 생깁니다. azure그림006 Blob에 인덱스를 생성하는 것은 만개 태그 당 0.03달러입니다. 10.암호화 볼트 키 비용 azure그림007 암호화 키볼트 사용시 월 1불 이 발생합니다.   11.Blob 변경 피드 비용 azure그림008 블롭에서 발생하는 변경 내용에 트랜젝션 로그에 대한 비용이 추가 비용이 생깁니다. 변경 피드 비용과 스토리지 분석 로깅의 차이점은 분석로그는 모든 작업에서 기록이 있지만 변경피드는 변경된 작업에서만 저장되는 로그입니다.   결론 11개의 비용에서 보통 계산기에서는 3개만 확인 할 수 있으며 나머지 8개는 비용이 매우 많이 사용하는 유저가 아니면 크게 비용이 나오지 않기 때문에 간과 할수 있으나 매우 많이 사용하는 유저일수록 다른 비용들도 고려 대상이 된다는 사실을 간과해서는 안됩니다. 보통은 새로나온 SFTP 와 같은 비용들은 새로나온 기능이며 Preview 때는 비용을 알지 못하므로 모를수 있으나 GA된 이후에 비용이 보통 나오기때문에 알기 어려운 비용들 입니다. 또한 업데이트가 매우 빠르고 계속된 업데이트에 따라서 계산기가 업데이트가 되지 않으므로 이런 부분은 놓치기 쉬운 부분입니다. 클라우드는 계속 진화 합니다. 그러므로 비용부분도 항상 체크해야 합니다. ]]> Fri, 06 Jan 2023 17:04:38 +0000 서버 설계