Istio는 Kubernetes 클러스터에서 컨테이너를 연결, 모니터링, 보호하는 구성 가능한 오픈 소스 서비스-메시 계층입니다. 이 문서에서 Istio는 기본적으로 Kubernetes에서만 작동하지만, 오픈 소스 특성 덕분에 모든 사용자는 Istio가 어떤 클러스터 소프트웨어에서든 실행할 수 있도록 하는 확장 기능을 만들 수 있습니다. 오늘은 가장 대표적인 유스 케이스, Kubernetes에서 Istio를 사용하는 방법을 자세히 살펴봅니다.

Kubernetes는 컨테이너 오케스트레이션 툴입니다. Kubernetes의 핵심 단위 중 하나가 노드입니다. 노드는 파일 시스템 또는 기타 컴포넌트와 함께 하나 이상의 컨테이너로 구성되어 있습니다. 마이크로서비스 아키텍처는 12개의 노드를 보유할 수 있는데, 노드마다 각기 다른 마이크로 서비스를 대표합니다. Kubernetes는 노드의 가용성과 리소스 이용을 관리하며, 팟(Pod) 오토스케일러를 통해 수요 증가에 따라 팟(Pod)을 추가합니다. Istio는 추가 컨테이너를 팟(Pod)에 삽입하는 방식으로 보안, 관리, 모니터링 기능을 추가합니다.

Istio는 오픈 소스이므로, 이를 지원하는 모든 퍼블릭 클라우드 제공자, 그리고 적극적인 관리자가 있는 어떤 프라이빗 클라우드에서도 실행할 수 있습니다.

Istio의 기초를 다루는 다음 동영상에서 자세히 알아보세요.

마이크로서비스로 전환하는 기업에서는 수십, 또는 수백 개의 특정 애플리케이션을 지원해야 합니다. 이러한 엔드포인트를 개별 관리하려면, 수많은 가상 머신(VM)을 (그 요구 사항까지) 지원해야 합니다. Kubernetes와 같은 클러스터 소프트웨어에서는 팟(Pod)을 생성하고 확장할 수 있으나, Kubernetes는 라우팅, 트래픽 규칙 또는 강력한 모니터링/디버깅 툴을 제공하지 않습니다.

서비스 메시(service mesh)를 소개합니다.

서비스의 수가 증가함에 따라 잠재적 통신 방법의 수도 기하급수적으로 증가합니다. 두 서비스에는 오직 두 개의 통신 경로만 있습니다. 3개의 서비스에는 6개가 있는 한편, 10개의 서비스에는 90개가 있습니다. 서비스 메시는 통신에 대한 정책을 마련함으로써 하나의 방식으로 이러한 통신 경로를 구성할 수 있게 합니다.

서비스 메시는 사전 정의된 구성에 따라 서비스를 측정하고 통신 트래픽의 방향을 지정합니다. 이는 실행 중인 컨테이너를 구성(또는 이렇게 하도록 코드를 작성)하는 대신, 관리자가 서비스 메시에 구성을 제공하고 여기서 해당 작업을 완료하도록 함을 의미합니다. 예전에는 웹 서버 및 서비스 간(service-to-service) 통신이 항상 이런 방식이었습니다.

클러스터에서 이를 수행하는 가장 일반적인 방법은 사이드카 패턴을 사용하는 것입니다. 사이드카는 팟(Pod) 안의 새로운 컨테이너이며, 서비스와 컨테이너 간의 통신 트래픽을 라우팅하고 관찰합니다.

앞서 말한 대로 Istio는 Kubernetes의 상위 계층을 이루면서 컨테이너를 추가하는데, 이는 프로그래머와 관리자에게 보이지 않는 것이 기본입니다. 이 "사이드카" 컨테이너는 트래픽의 방향을 지정하고 컴포넌트 간 상호작용을 모니터링하는 "중간자"의 역할을 합니다. 이 두 요소는 구성, 모니터링, 관리의 세 가지 방식으로 연동합니다.

구성

Kubernetes에서 구성 설정의 기본 방법은 "kubectl -f"라고 하는 kubectl 명령인데, 여기서 파일은 YAML 파일입니다. Istio 사용자는 kubectl을 사용하여 새롭고 다양한 유형의 YAML 파일을 실행하거나, 새로운 선택적 ioctl 명령을 사용할 수 있습니다.

모니터링

Istio를 사용하면 Kubernetes에서 실행 중인 애플리케이션의 상태를 손쉽게 모니터링할 수 있습니다. Istio의 측정 기능으로 애플리케이션의 상태를 관리하고 시각화할 수 있습니다. 즉, Kubernetes에서 제공하는 일반적인 클러스터/노드 모니터링 기능보다 더 많은 인사이트를 제공할 수 있습니다.

관리

Istio의 인터페이스가 본질적으로 Kubernetes와 같기 때문에 별도의 관리 작업은 거의 없습니다. 실제로 Istio를 사용하면 Kubernetes 클러스터 전체에 적용되고 이를 관리하는 정책을 작성할 수 있습니다. 따라서 맞춤형 관리 코드가 불필요해지며, 각 클러스터를 관리하는 시간도 단축됩니다.

서비스 메시의 대표적인 이점으로는 더 효과적인 디버깅, 모니터링, 라우팅, 보안, 레버리지 기능을 들 수 있습니다. 즉, Istio를 사용하면 더 광범위한 서비스 그룹을 더 용이하게 관리할 수 있습니다.

개선된 디버깅

하나의 서비스에 여러 개의 종속 항목이 있다고 가정해보겠습니다. 한 보험 회사의 pay_claim 서비스는 deductible_amt 서비스를 호출하며, 이는 is_member_covered 서비스를 호출합니다(이렇게 계속 진행됨). 복잡한 종속 항목 체인에는 10개 또는 12개의 서비스 호출이 있을 수 있습니다. 이 12개 중 하나가 실패하면 연쇄적으로 실패가 일어납니다. 이를테면 500 오류나 400 오류가 발생하거나, 아예 응답이 없을 수도 있습니다.

이 호출 모음을 디버깅하기 위해 스택 추적과 같은 기능을 사용할 수 있습니다. 프론트 엔드에서 클라이언트측 개발자는 웹 서버에서 어떤 순서로 어떤 요소가 풀백되었는지를 확인하고 이를 검사할 수 있습니다. 프론트 엔드 프로그래머는 폭포 다이어그램을 가져와 디버깅에 활용할 수 있습니다.

이 예제에서는 데이터 센터 내부에서 벌어지는 상황, 즉 callback=parselLotamaAudiences가 다른 4개의 웹 서비스를 어떻게 호출하고, 그 중 어떤 서비스가 더 느리게 응답하는지를 보여주지 않습니다. 나중에 이와 매우 유사한 다이어그램을 통해 Istio가 함수 호출 추적 툴을 어떻게 제공하는지 알아볼 것입니다.

모니터링과 관측성

DevOps 팀과 IT 관리자가 대기 시간, 서비스 소요 시간, 오류(트래픽 비율로 표시) 등을 확인하기 위해 트래픽을 관찰하려는 경우가 있습니다. 이를 위해 대개는 대시보드로 이동합니다. 대시보드는 합계, 평균 또는 시간 흐름에 따른 메트릭을 시각화하여 보여줍니다. 아마도 특정 노드, 서비스 또는 팟(Pod)으로 "드릴 다운"하는 기능도 제공할 것입니다. Kubernetes는 기본적으로 이러한 기능을 제공하지 않습니다.

정책

기본적으로 Kubernetes는 모든 팟(Pod)에서 다른 어떤 팟(Pod)으로도 트래픽을 전송하는 것을 허용합니다. Istio를 사용하여 관리자는 서로 간에 작업할 수 있는 서비스를 제한하는 정책을 작성할 수 있습니다. 따라서 예를 들어 서비스는 진정한 종속 항목인 다른 서비스만 호출할 수 있습니다. 중단 없이 서비스를 제공하기 위한 또 다른 정책은 속도 제한입니다. 이는 과도한 트래픽에 의한 서비스 장애 및 서비스 거부(DoS) 공격을 막는 효과가 있습니다.

라우팅과 로드 밸런싱

기본적으로, Kubernetes는 라운드 로빈(round-robin) 로드 밸런싱을 제공합니다. 마이크로서비스를 제공하는 여섯 개의 팟(Pod)이 있는 경우, Kubernetes는 오름차순으로 각 팟(Pod)에 요청을 전송하는 로드 밸런서, 즉 "서비스"를 제공한 후 다시 시작합니다. 그러나 한 회사의 프로덕션 환경에 같은 서비스의 서로 다른 버전을 배치하는 경우도 있습니다.

가장 간단한 예로 파란색/녹색 배치를 들 수 있습니다. 이러한 경우에 이 소프트웨어는 프로덕션 사용자를 프로덕션의 기존 애플리케이션에 보내지 않고 이 애플리케이션의 완전히 새로운 버전을 빌드합니다. 이 새 버전을 승격한 다음에는 기존 서버를 계속 운영하면서 장애 발생 시 신속하게 전환할 수 있습니다.

Istio를 사용하면 구성 파일에서 태깅을 쓰는 것만큼 간단하게 이를 처리할 수 있습니다. 또한 관리자는 연결할 서비스 유형을 나타내고 헤더를 기반으로 규칙을 빌드하는 데에도 레이블을 사용할 수 있습니다. 예를 들어 베타 사용자는 최신 버전의 가장 큰 빌드를 사용하여 'canary' 팟(Pod)으로 라우팅하고, 일반 사용자는 안정된 프로덕션 빌드로 이동할 수 있습니다.

서킷 브레이킹

서비스가 과부하 상태가 되거나 멈출 경우, 시스템 과부하가 계속되는 동안에는 추가 요청이 있더라도 실패합니다. Istio가 오류와 지연을 추적하기 때문에, 이는 정책에 의해 설정된 특정 수의 요청 이후 일시정지를 강제 실행하여 서비스의 복구를 허용할 수 있습니다. 작은 텍스트 파일을 작성하고 이를 새 정책으로 사용하도록 Istio에 지시함으로써 전체 클러스터에서 이 정책을 시행할 수 있습니다.

보안

Istio는 인증, 권한 부여 및 감사(AAA)와 더불어 ID, 정책 및 암호화를 기본 제공합니다. 기타 대상과 통신하는 관리 중인 모든 팟(Pod)은 암호화된 트래픽을 사용하여 관찰을 방지합니다. ID 서비스는 암호화와 연계하여 인증되지 않은 사용자가 서비스 호출을 위조 또는 "도용"할 수 없게 합니다. AAA는 보안 및 운영 전문가가 모니터링하는 데 필요한 툴을 제공하며, 오버헤드가 적습니다.

관리 간소화

기존 애플리케이션에서는 Istio에서 제공하는 ID, 정책 및 보안 기능이 여전히 필요합니다. 여기에는 모든 서비스에 대해 동일한 보안 규칙을 반복하여 재구현하면서 잘못된 추상 레벨에서 작업하고 있는 프로그래머와 관리자가 있습니다. Istio를 사용하면 단일 제어 패널을 통해 클러스터에 적합한 레벨 설정 정책을 적용받으면서 작업할 수 있습니다.