AWS만 썼던 사람이 Azure 쓰는 이야기 마지막 편으로 컨테이너 관련 서비스를 살펴 보겠습니다.

컨테이너가 나오기 전에는 서버에 필요한 것들을 세팅하고, 애플리케이션 소스나 실행 파일을 올리는 형태로 서비스를 제공했습니다. 관리해야 할 서버 개수가 늘어나면서 서버 관리 방법이 복잡해졌는데요. Ansible, Chef와 같은 구성 관리 툴 덕분에 많은 서버에 같은 설정을 쉽게 수행할 수 있게 되었습니다.

그러다가 Docker와 같은 컨테이너 빌드 툴이 나왔습니다. Dockerfile을 작성하고, 빌드만 하면 애플리케이션에 필요한 의존성과 애플리케이션을 컨테이너 이미지로 배포할 수 있게 되었습니다. 그리고 컨테이너 개수가 급격하게 많아지면서, 컨테이너 기반 애플리케이션을 어떻게 운영해야 할 지 고민하게 되었죠. 그동안 다수의 컨테이너를 운영하기 위한 많은 방법이 나왔지만, 결국 Kubernetes로 수렴하는 것 같습니다. 일단 AWS, Azure 외에도 많은 클라우드 서비스들이 Kubernetes는 기본적으로 지원하는 것만 봐도 알 수 있습니다.

1편, 2편에 이어서 AWS만 써 온 사람이 Azure를 사용해 보는 이야기를 이어가겠습니다. 저는 인프라의 가장 중요한 구성요소는 네트워크, 컴퓨팅 리소스, 스토리지라고 생각하는데요. 이번 글에서는 인프라의 가장 중요한 요소 중 하나인 스토리지에 대한 이야기를 해 보겠습니다.

Azure의 스토리지 서비스 비교하기

파일을 저장할 곳을 생각한다면 다음과 같은 기준으로 선택을 하지 않을까 싶습니다.

• 서버 내 파일 시스템에 마운트 하는 HDD/SSD → 블록 스토리지
• 서버에 마운트하지 않고, 자유롭게 업로드/다운로드 하는 스토리지 → 객체 스토리지
• 여러 서버에서 동시에 연결할 수 있는 스토리지 → 네트워크 스토리지 (NFS/SMB 프로토콜 기반)

AWS와 Azure에서 각각의 용도에 맞는 서비스를 비교해 보면 다음과 같습니다. 하나씩 살펴보시죠.

지난 글에 이어서 AWS만 써 온 사람이 Azure를 사용해 보는 이야기를 계속하겠습니다. 이번 글에서는 AWS와 비교해서 Azure에서 가상 머신을 관리하는 방법을 이야기 해 보려고 합니다. 이번 글에서는 Azure CLI와 Terraform을 사용하는 경우가 많아서 이러한 툴이 설치되어 있으면 좋습니다.

글이 길어서 이번 글에서 다루는 내용을 간단하게 요약하겠습니다. 아래 내용을 참고해 주세요.

• EC2 vs 가상 머신
  • 서버 크기 선택
  • OS 이미지 선택
  • 네트워크 설정
  • SSH 키 페어 관리
• 오토 스케일링 그룹 vs VMSS(가상 머신 확장 집합)

가상 머신

AWS의 EC2와 같은 서비스로 Azure의 가상 머신(Virtual Machines) 서비스가 있습니다. 포털에서 가상 머신을 만드는 방법을 전부 알려드리지 않고, 차이점 위주로 설명해 보겠습니다.

제 커리어를 되돌아 보니, 저는 인프라를 구축하고 운영할 때 AWS만 사용해 왔습니다. AWS가 국내 뿐만 아니라 전세계에서 가장 시장 점유율이 높은 서비스임이 분명하지만, 실제로 인프라를 운영하는 입장에서는 다른 클라우드를 사용하는 경우도 많습니다. 게다가 많은 기업들은 여전히 데이터 센터에 서비스 인프라를 구축하기도 합니다. 현재 재직 중인 회사에서 개발한 솔루션은 다양한 인프라 환경에 배포하는 것을 전제로 하고 있는데요. 그러다가 최근 회사에서 Azure를 사용해 볼 수 있는 기회가 생겨서 Azure를 사용해 보았습니다. 만약 다른 클라우드 환경을 사용하게 된다면, 어떤 부분에 집중해서 인프라를 구성할 지에 대해 기록해 보려고 합니다.

들어가며

제가 살면서 처음으로 구매한 음반은 Green Day의 베스트 앨범인 International Superhits! 입니다. 중학교 2학년 때 제가 살던 동네의 월마트에서 테이프를 샀던 기억이 있습니다. 그로부터 20여 년이 지났는데요. 지금까지 본가와 서울 집에 있는 CD와 테이프를 모두 합쳐보니 150장이 넘더라구요. (참고로 예전에 핫뮤직이라는 락 음악 전문 잡지가 있었는데, 부록으로 주는 샘플러를 빼고 계산했어요. 실제로는 좀 더 많지 않을까 싶습니다)

지금도 가끔씩 “이건 CD로 갖고 있어야겠다"는 앨범이 있어서, 알라딘 중고서점과 같은 곳을 뒤져 볼 때가 있습니다. 검색을 하다 보면 “이거 예전에 샀던 건가?” 라는 생각이 들 때가 있어요. 그래서 제가 지금까지 구매한 앨범을 검색할 시스템이 필요하다고 생각했습니다. 예전에 Django로 만들고 방치했던 것이 있었는데, 이걸 완전히 바꿔서 진행해 보려고 했습니다.

컨테이너 이미지의 크기는 기본적으로 이미지를 저장하는 비용과 관련 있습니다. AWS의 ECR은 private repository에 저장된 이미지에 월 GB 당 0.1 USD를 부과합니다. (출처) 한편 컨테이너 이미지를 실행하는 환경에서도 컨테이너 이미지 크기가 중요할 수 있는데요. 예를 들어 EC2와 같은 서버에서 컨테이너 이미지를 실행한다고 했을 때, 이미지의 크기가 작을수록 다운로드에 걸리는 시간이 줄어들 것이고, 이는 서버에서 컨테이너를 처음으로 실행하는 데 걸리는 시간에도 영향을 줄 수 있습니다. 그리고 ECR의 경우 동일 리전에서는 전송 비용을 받지 않지만, 리전이 달라지면 전송 비용을 받기도 하니 네트워크 비용도 고려하면 좋지 않을까 싶습니다.

인프라 구성을 하다 보면, 네트워크 설정 때문에 문제를 겪는 일이 많습니다. “Connection timeout"과 같은 네트워크 관련 오류가 갑자기 발생하면, 어디서부터 원인을 찾아야 할 지 막막한데요. AWS를 사용하신다면 네트워크 문제를 겪을 때 VPC Reachability Analyzer라는 서비스를 이용하여 원인을 찾을 수 있습니다. 출발하는 지점부터 도착지까지 어떤 과정으로 트래픽이 도달하는 지 상세하게 확인할 수 있는 서비스입니다. 네트워크 문제가 발생한다면 한 번 사용해 보시기 바랍니다.

VPC Reachability Analyzer

VPC Reachability Analyzer는 2020년에 소개된 기능으로, 소스와 타겟 리소스를 지정하여 내가 의도한 대로 네트워크를 구성하였는지 확인할 수 있습니다. 다만 AWS에 구성한 네트워크 기준으로만 확인할 수 있기 때문에, 애플리케이션 내부에서 트래픽을 차단하는 경우는 감지하지 못합니다. 애플리케이션에서 특정 포트를 차단하는 경우가 있다면 서버 내의 설정을 확인하거나, 애플리케이션 코드를 확인해 보아야 합니다.

예전에 여러 단계가 있는 작업을 해야 할 때 AWS의 Step Functions를 이용한 적이 있었습니다. Step Functions의 경우, Lambda 함수를 연결해서 쓴 적이 많았고, 오래 걸리는 작업은 다른 방법으로 구축할 수 있습니다. (이전에 올렸던 Python으로 Step Functions 활동 만들기 문서를 참고해 주세요)

한편, 다른 방법은 없나 찾아보다가 Airflow를 알게 되었습니다. 그래서 Airflow도 테스트한 적이 있었는데요. (이전에 올렸던 데이터 분석 워크플로우를 처음부터 만들어 보기 1편, 2편을 참고해 주세요)

최근 우연하게 Kubernetes에서 Workflow를 관리할 수 있는 Argo Workflow에 대해 알게 되었습니다. 그래서 이번 글에서는 Argo Workflow의 사용법을 알아보고자 합니다.

배경

어떤 애플리케이션이든 민감한 정보를 관리할 필요가 있습니다. DB에 연결하기 위한 사용자 정보 및 비밀번호가 필요할 것이고, 외부 API를 호출하기 위해 API 키가 필요할 수도 있죠. 이러한 정보를 관리하는 방법에는 여러 가지가 있는데요. 이번에는 EKS 클러스터가 있다고 가정하고, AWS의 Parameter Store, Secrets Manager에 있는 값을 어떻게 Pod에 넣을 수 있을지 살펴 보겠습니다.

준비하기

• AWS CLI 설치
• kubectl, helm 설치
• EKS 클러스터: 콘솔에서 생성하거나 eksctl과 같은 툴로 생성해 주세요. (테스트 후 비용 문제로 클러스터는 꼭 삭제해 주시기 바랍니다.)

Secrets Store CSI Driver & ASCP(Amazon Secrets Manager and Config Provider) 설치

Kubernetes에서는 Secret Store CSI Driver라는 것이 있습니다. 민감한 정보를 CSI Volume으로 관리할 수 있도록 하는 도구입니다. 즉, 민감한 정보를 특정 볼륨에 마운트 하는 방식으로 관리하는 것입니다. 이 도구는 여러가지 외부 Secret store provider를 지원하는데요. Azure, GCP, Vault 뿐만 아니라 AWS도 지원합니다.

배경

인프라를 관리하다 보면, 수동으로 하는 일을 자동화 할 수 있는 방법을 고민할 것입니다. 그래서 인프라 구성을 코드로 관리하기도 하고, 간단한 스크립트나 프로그램을 만들기도 합니다. 그 중에서도 “스크립트로 제공하는 것들을 API로 만들어 보면 어떨까?” 라는 생각을 했는데요. DevOps나 SRE 분야에서 사용하는 도구들이 Go(Golang)으로 만든 경우가 많아서 Go를 선택하였습니다. 찾아 보니 Go를 이용한 웹 프레임워크로는 Gin과 같은 것들이 있더라구요. 이를 활용해서 간단한 API를 만들어 보려고 합니다. (에디터로는 Visual Studio Code를 이용합니다)