Istio

menu icon

Istio

개발자가 다양한 마이크로서비스의 네트워크를 완벽하게 연결, 관리 및 보호할 수 있는 방법을 제공하는 Istio 오픈 기술에 대해 자세히 알아봅니다.

Istio란?

Istio는 컨테이너의 연결, 모니터 및 보안을 Kubernetes 클러스터에서 실행하는 구성 가능한 오픈 소스 서비스 메시 계층입니다. 이 문서에서 Istio는 기본적으로 Kubernetes에서만 작동하지만, 오픈 소스 특성 덕분에 모든 사용자는 Istio가 어떤 클러스터 소프트웨어에서든 실행할 수 있도록 하는 확장 기능을 만들 수 있습니다. 지금은 가장 널리 사용되는 유스케이스인 Kubernetes에서 Istio를 사용하는 방법에만 집중합니다.

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

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

다음 동영상에서 Istio 기초에 대해 자세히 알아보세요(5:13).

네트워크 서비스 메시

마이크로서비스로 이동하는 경우, 기업들은 수십 또는 수백 개의 특정 애플리케이션을 지원해야 합니다. 해당 엔드포인트를 별도로 관리하는 것은 수요를 포함하여 다수의 가상 머신 또는 VM을 지원하는 것을 의미합니다. Kubernetes 등의 클러스터 소프트웨어는 팟(Pod)을 작성하고 이를 확장할 수 있지만, Kubernetes는 라우팅, 트래픽 규칙 또는 강력한 모니터링이나 디버깅 툴을 제공하지 않습니다.

서비스 메시에 진입합니다.

서비스의 수가 증가함에 따라 통신을 위한 잠재적 방법의 수는 기하급수적으로 증가합니다. 두 서비스에는 오직 두 개의 통신 경로만 있습니다. 3개의 서비스에는 6개가 있는 한편, 10개의 서비스에는 90개가 있습니다. 서비스 메시는 통신을 위한 정책을 작성하여 이러한 통신 경로를 구성하는 단일한 방법을 제공합니다.

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

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

Istio 및 Kubernetes

앞서 언급했듯이 Istio는 Kubernetes 위의 계층이며, 프로그래머와 관리자에게는 기본적으로 보이지 않는 컨테이너를 추가합니다. "사이드카" 컨테이너라고 하는 이는 "중간자" 역할을 수행하며, 트래픽을 지시하고 컴포넌트 간의 상호작용을 모니터링합니다. 이 둘은 구성, 모니터링 및 관리의 세 가지 방법을 조합하여 작동합니다.

구성

Kubernetes에서 명령 설정의 기본 방법은 "kubectl -f <filename>"이라고 하는 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 오류가 계속 발생함). 또는 전혀 응답이 없을 수도 있습니다.

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

이 예제에서 나타나지 않는 것은 데이터 센터 내에서 발생하는 일(콜백 =parselLotamaAudiences가 4개의 기타 웹 서비스를 호출하는 방법 및 더 느리게 응답하는 서비스)입니다. 나중에 우리는 이와 매우 유사한 다이어그램에서 함수 호출을 추적하는 툴을 Istio가 제공하는 방법을 볼 수 있습니다.

모니터링 및 관측성

DevOps 팀과 IT 관리자는 트래픽을 관찰하여 대기 시간, 서비스 시간, 오류(트래픽 백분율로서) 등을 확인하고자 할 수 있습니다. 종종 이들은 대시보드를 보고자 합니다. 대시보드에서는 아마도 특정 노드, 서비스 또는 팟(Pod)으로 "드릴다운"하는 기능을 통해 시간의 흐름에 따라 해당 메트릭 또는 합계 또는 평균의 시각화를 제공합니다. Kubernetes는 이 기능을 기본적으로 제공하지 않습니다.

정책

기본적으로 Kubernetes는 모든 팟(Pod)이 다른 모든 팟(Pod)에 트래픽을 전송할 수 있도록 허용합니다. Istio를 사용하여 관리자는 서로 간에 작업할 수 있는 서비스를 제한하는 정책을 작성할 수 있습니다. 따라서 예를 들어 서비스는 진정한 종속 항목인 다른 서비스만 호출할 수 있습니다. 서비스 구동을 유지하는 다른 정책은 속도 제한적이며, 이는 과잉 트래픽이 서비스를 방해하지 못하게 하고 서비스 거부 공격을 차단합니다.

라우팅 및 로드 밸런싱

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

이의 가장 간단한 예는 파란색/녹색 배치일 수 있습니다. 이 경우에 소프트웨어는 프로덕션 사용자를 이에 보내지 않고도 프로덕션에서 완전히 새 버전의 애플리케이션을 구축할 수 있습니다. 새로운 버전을 프로모션한 후에 회사는 장애 발생 시의 빠른 스위치백을 위해 기존 서버를 계속 유지할 수 있습니다.

Istio를 사용하면 이는 구성 파일에서 태깅을 사용하는 것처럼 간단합니다. 또한 관리자는 헤더에 기반하여 규칙를 구축하고 연결할 서비스의 유형을 표시하기 위해 레이블을 사용할 수도 있습니다. 예를 들어 베타 사용자는 최신의 가장 큰 빌드를 사용하여 ‘canary’ 팟(Pod)을 라우팅하는 한편, 일반 사용자는 안정된 프로덕션 빌드로 이동할 수 있습니다.

서킷 브레이킹

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

보안

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

관리의 단순화

기존 애플리케이션에서는 Istio에서 제공하는 ID, 정책 및 보안 기능이 여전히 필요합니다. 여기에는 모든 서비스에 대해 동일한 보안 규칙을 반복하여 재구현하면서 잘못된 추상 레벨에서 작업하고 있는 프로그래머와 관리자가 있습니다. Istio를 사용하여 이들은 단일 제어 패널을 통해 클러스터에 대한 올바른 레벨 설정 정책에서 작업할 수 있습니다. 이와 동시에, 아래에서 설명하는 Istio의 액세스 제어, 대시보드 및 디버깅 툴을 사용하여 사용자는 웹 페이지로 이동하는 대신 명령행에서 플러그인을 손쉽게 추가할 수 있습니다.

예제

서비스 시각화

Istio 1.1에는 웹 기반 시각화를 제공하는 Kiali라고 하는새 추가 기능이 포함되어 있습니다. 이를 사용하여 사용자는 서비스 요청을 추적하고 상세 정보를 드릴다운하거나, 심지어는 서비스 요청 히스토리를 JSON으로 내보내서 자체 방식으로 조회 및 형식화할 수 있습니다. 아래의 워크로드 그래프는 실제로 서로 간에 종속되는 서비스를 기반으로 실시간 생성된 종속 항목 그래프를 제공합니다. 이는 실제 트래픽 관찰에서 생성된 것입니다.

웹 기반 시각화를 제공하는 Kiali라고 하는 신규 추가 기능의 이미지

추적 서비스 호출

Istio의 컴포넌트인 Jaeger 서비스는 주어진 서비스에 대한 추적을 제공합니다. 이 예제에서는 제품 페이지를 추적했습니다. 첫 번째 이미지의 모든 도트는 서비스 호출을 나타냅니다. 도트를 클릭하여 정확한 서비스 요청과 응답을 따르기 위해 폭포 다이어그램으로 "드릴다운"할 수 있습니다.

Istio의 컴포넌트인 Jaeger 서비스의 이미지는 제공된 서비스에 대한 추적을 제공합니다.  이 예제에서는 제품 페이지를 추적했습니다.  첫 번째 이미지의 모든 점들은 서비스 호출을 나타냅니다.

또한 제품 페이지를 좀 더 자세히 살펴볼 수 있습니다. 제품 페이지 자체에 오류가 있음을 확인할 수 있습니다. 해당 세부사항이 성공적으로 리턴되었습니다.

제품 페이지의 이미지.  제품 페이지 자체에 오류가 있음을 확인할 수 있습니다. 해당 세부사항이 성공적으로 리턴되었습니다.

대시보드

Istio에서는 시스템 상태와 성능을 모니터하기 위한, 바로 사용 가능한 여러 대시보드를 제공합니다. 이는 CPU 및 메모리 활용도, 트래픽 수요, 400 및 500 오류의 수, 요청 처리 시간 등을 측정할 수 있습니다. 무엇보다도, 이는 Istio를 설치 및 실행하고 Grafana(포함된 Istio용 오픈 소스 대시보드 툴 중 하나)를 추가하여 사용할 수 있습니다. Istio는 또한 다음 두 개의 대시보드도 제공합니다: Kiali 및 Jaeger.

시스템 상태와 성능을 모니터하기 위한 Istio의 많은 대시보드(즉시 사용 가능)의 이미지.

Istio vs. Envoy

Istio는 Envoy 버전(비록 매우 확장되었지만)을 사용하여 모니터링, 관리 및 로깅을 수행합니다. 모든 팟(Pod)은 추적이 필요하며, Istio는 모든 팟(Pod)에 대한 정보를 집계하고 제공해야 합니다. Istio 사용의 한 가지 가능한 대안은 Envoy를 Kubernetes 클러스터에 직접 배치하고 관리 코드를 작성하는 것입니다. 그러나 이에 대해 생각해 보면, 이는 커스텀 개발 프로젝트의 연관된 모든 비용과 버그와 함께 Istio가 무엇인지에 대해 근본적으로 재정의하는 것입니다.

튜토리얼

Istio 웹 사이트(IBM 외부 링크)에는 Istio를 시작하기 위한 많은 유용한 문서와 지시사항이 포함되어 있습니다. 

Istio 및 IBM

관리형 IstioIBM Cloud Kubernetes 서비스의 일부로서 사용 가능합니다. 이 서비스는 Istio의 원활한 설치, 제어 플레인 구성요소의 자동 업데이트 및 라이프사이클 관리, 플랫폼 로깅 및 모니터링 툴과의 통합을 제공합니다. 새 클러스터 또는 기존 클러스터에 관리형 Istio 통합을 추가하고 지금 바로 마이크로서비스를 다시 제어할 수 있습니다. Knative에 대해 자세히 알아보려면 "Knative: 핵심 안내서"를 확인하세요.

IBM Cloud Kubernetes 서비스의 관리형 Istio 자세히 보기

관리형 Kubernetes가 클라우드 여정에서 사용자를 지원하는 방법의 개요를 알아보려면 "관리형 Kubernetes의 장점" 동영상을 확인하세요.

프로덕션 환경에서 컨테이너 배치를 활성화하고 신속히 처리하는 우수 사례에 대해 자세히 알아보려면 "프로덕션에서 컨테이너 및 Kubernetes 실행의 우수 사례" 보고서를 참조하세요.

실무 안내서인 "Istio 설명: 서비스 메시 시작하기"(PDF, 4.1MB)를 통해 서비스 메시가 애플리케이션에서 서비스 간의 상호작용을 제어하는 데 어떤 도움이 되는지 알아봅니다.

지금 바로 IBM Cloud 사용을 시작할 준비가 되었다면 여기서 등록하세요.