eBPF가 우리가 알고 있는 관찰 가능성을 어떻게 변화시키는가 🕵️‍♀️🐝

eBPF 관찰 가능성 디코딩: 지난 2년 동안 클라우드 네이티브 커뮤니티에서는 eBPF에 관해 많은 대화가 있었습니다. eBPF는 KubeCon의 이었고, 과 의 인기가 급속히 높아지고 있으며 Google 및 Netflix와 같은 회사는 수년간 왔으며 새로운 사용 사례가 항상 등장하고 있습니다. 특히 관찰 가능성 측면에서 eBPF는 게임 체인저가 될 것으로 예상됩니다. 중심 eBPF 시절 eBPF 서밋 eBPF를 사용해 그럼 eBPF를 살펴보겠습니다. 기술은 무엇이며, 관측 가능성에 어떤 영향을 미치고, 기존 관측 가능성 관행과 어떻게 비교되며, 미래에는 어떤 영향을 미칠까요? https://www.youtube.com/watch?v=KhPrMW5Rbbc&embedable=true eBPF란 과연 무엇인가? eBPF는 커널 코드를 변경하지 않고도 Linux 커널에서 샌드박스 프로그램을 안전하게 실행할 수 있게 해주는 프로그래밍 프레임워크입니다. 원래는 Linux용으로 개발되었지만(현재 기술이 여전히 가장 성숙한 부분임) Microsoft는 빠르게 발전시키고 있습니다. Windows용 eBPF 구현을 eBPF 프로그램은 설계상 매우 효율적이고 안전합니다. 운영 체제의 안정성이나 보안을 위험에 빠뜨리지 않도록 커널에서 검증됩니다. 그렇다면 eBPF가 왜 중요한가요? 이를 이해하려면 사용자 공간과 커널 공간을 이해해야 합니다. 사용자 공간은 모든 애플리케이션이 실행되는 곳입니다. 커널 공간은 사용자 공간과 물리적 하드웨어 사이에 위치합니다. 사용자 공간의 애플리케이션은 하드웨어에 직접 액세스할 수 없습니다. 대신 커널에 시스템 호출을 한 다음 하드웨어에 액세스합니다. 모든 메모리 액세스, 파일 읽기/쓰기 및 네트워크 트래픽은 커널을 통과합니다. 커널은 동시 프로세스도 관리합니다. 기본적으로 모든 것이 커널을 통과합니다(아래 그림 참조). 그리고 eBPF는 커널 기능을 확장하는 안전하고 안전한 방법을 제공합니다. 역사적으로 분명한 이유로 커널 소스 코드나 운영 체제 계층의 내용을 변경하는 것은 매우 어렵습니다. Linux 커널에는 있으며 아이디어에서 널리 사용 가능한 변경 사항이 적용되는 데 몇 년이 걸립니다. 첫째, Linux 커뮤니티가 이에 동의해야 합니다. 그런 다음 공식 Linux 릴리스의 일부가 되어야 합니다. 그런 다음 몇 달 후에 Red Hat 및 Ubuntu와 같은 배포판을 통해 더 많은 사용자에게 제공됩니다. 3천만 줄의 코드가 커널 모듈을 자신의 커널에 로드하고 직접 변경할 수 있지만 이는 위험이 높고 복잡한 커널 수준 프로그래밍이 포함되므로 거의 보편적으로 피합니다. 기술적으로 매우 eBPF가 등장하여 이 문제를 해결하고 커널에 프로그램을 연결하고 실행할 수 있는 메커니즘을 제공합니다. 안전하고 효율적인 eBPF가 어떻게 보안과 성능을 모두 보장하는지 살펴보겠습니다. 높은 보안 - eBPF 프로그램을 커널에 로드하기 전에 에 의해 검증되어 코드가 절대적으로 안전한지 확인합니다(예: 하드 루프 없음, 유효하지 않은 메모리 액세스, 안전하지 않은 작업). 엄격한 검증 eBPF 검증자 - eBPF 프로그램은 다른 커널 구성 요소와 별도로 커널 내의 메모리 격리된 샌드박스에서 실행됩니다. 이는 커널 메모리, 데이터 구조 및 커널 소스 코드에 대한 무단 액세스를 방지합니다. 샌드박스 - eBPF 프로그램은 일반적으로 C 언어의 작은 하위 집합(제한된 명령어 세트)으로 작성되어야 합니다. 이는 eBPF 프로그램이 수행할 수 있는 작업을 제한하여 보안 취약성의 위험을 줄입니다. 제한된 작업 고성능/경량 - eBPF 프로그램은 CPU에서 기본 기계 명령어로 실행됩니다. 이로 인해 실행 속도가 빨라지고 성능이 향상됩니다. 기본 기계어 코드로 실행 - 일반 애플리케이션은 리소스를 많이 사용하는 사용자 공간과 커널 공간 간에 정기적으로 컨텍스트 전환을 수행합니다. eBPF 프로그램은 커널 계층에서 실행되므로 커널 데이터 구조와 리소스에 직접 액세스할 수 있습니다. 컨텍스트 전환 없음 - eBPF 프로그램은 일반적으로 특정 커널 이벤트에 대한 응답으로만 실행되고 항상 실행됩니다. 이는 오버헤드를 최소화합니다. 이벤트 중심 - eBPF 프로그램은 실행 직전에 커널의 JIT(Just-In-Time) 컴파일러에 의해 기계어 코드로 컴파일되므로 코드는 실행되는 특정 하드웨어에 최적화됩니다. 하드웨어에 최적화 따라서 eBPF는 프로그래밍을 위해 커널에 안전하고 효율적인 후크를 제공합니다. 그리고 모든 것이 커널을 통과한다는 점을 고려하면 지금까지 불가능했던 몇 가지 새로운 가능성이 열립니다. 이게 왜 에서야 큰일이 되는 걸까요? 지금 eBPF 관련 기술은 오랜 시간에 걸쳐 발전해 왔으며 제작에만 약 30년이 걸렸습니다. 지난 7~8년 동안 eBPF는 여러 대기업에서 대규모로 사용되었으며 이제 eBPF 사용이 주류가 되는 시대에 접어들고 있습니다. Linux의 공동 창시자이자 eBPF의 공동 유지관리자 시청하세요. 인 Alexei Starovoitov가 eBPF의 진화에 대해 설명하는 이 비디오를 eBPF - 간략한 역사 1993년 - 로렌스 버클리 국립 연구소의 에서는 패킷 필터링을 위한 커널 에이전트 사용을 탐구합니다. 여기서 BPF("Berkeley Packet Filter")라는 이름이 유래되었습니다. 논문 1997 - BPF는 Linux 커널(버전 2.1.75)의 일부로 공식적으로 도입되었습니다. 1997-2014 - BPF 기능을 개선, 안정화 및 확장하기 위해 여러 기능이 추가되었습니다. 2014 - "확장 버클리 패킷 필터"(eBPF)라는 중요한 업데이트가 도입되었습니다. 이 버전은 BPF 기술을 크게 변경하여 더 널리 사용할 수 있도록 합니다. 따라서 "확장"이라는 단어가 사용됩니다. 이 릴리스가 큰 이유는 커널 기능 확장이 졌기 때문입니다. 쉬워 프로그래머는 일반 애플리케이션처럼 코딩할 수 있으며 주변 eBPF 인프라는 낮은 수준의 검증, 보안 및 효율성을 관리합니다. eBPF 주변의 전체 지원 생태계와 비계가 이를 가능하게 합니다(아래 그림 참조). 출처: https://ebpf.io/what-is-ebpf/ 더 좋은 점은 eBPF 프로그램을 다시 시작하지 않고도 커널에서 로드 및 언로드할 수 있다는 것입니다. 이 모든 것이 갑자기 광범위한 채택과 적용을 가능하게 했습니다. 생산 시스템에 널리 채택됨 eBPF의 인기는 지난 7~8년 동안 폭발적으로 증가했으며 여러 대기업이 이를 대규모 생산 시스템에 사용했습니다. 2016년까지 Netflix는 추적을 위해 eBPF를 널리 사용했습니다. 이를 구현한 는 인프라 및 운영 분야에서 eBPF의 권위자로 널리 알려졌습니다. Brendan Gregg 2017 - Facebook은 eBPF 기반 로드 밸런서인 오픈 소스로 공개했습니다. 2017년 이후 으로 전송되는 모든 단일 패킷은 eBPF를 통과했습니다. Katran을 Facebook.com 2020 - Google은 eBPF를 Kubernetes 제품의 일부로 만들었습니다. 이제 eBPF는 GKE의 강화합니다. 이제 및 와 같은 회사에서도 광범위한 기업 채택이 이루어지고 있습니다. 네트워킹, 보안, 관측 가능성 레이어를 Capital One Adobe 2021 - Facebook, Google, Netflix, Microsoft, Isovalent가 함께 모여 eBPF 기술의 성장을 관리하기 위한 발표했습니다. eBPF 기반을 이제 eBPF를 사용하는 수천 개의 회사가 있으며 매년 다양한 사용 사례를 탐색하는 수백 개의 eBPF 프로젝트가 등장하고 있습니다. eBPF는 이제 이를 지원하는 광범위한 커뮤니티가 있는 Linux 커널 내의 별도 하위 시스템입니다. 기술 자체는 몇 가지 새로운 추가 기능을 통해 상당히 확장되었습니다. 그렇다면 eBPF로 무엇을 할 수 있을까요? eBPF의 가장 일반적인 사용 사례는 3가지 영역입니다. 네트워킹 보안 관찰 가능성 보안 및 네트워킹은 과 같은 프로젝트에 힘입어 더 폭넓게 채택되고 적용되었습니다. 이에 비해 eBPF 기반 관측 가능성 제품은 진화 초기 단계에 있으며 이제 막 시작되었습니다. Cilum 먼저 보안과 네트워킹 분야의 사용 사례를 살펴보겠습니다. 보안 보안은 eBPF의 매우 인기 있는 사용 사례입니다. eBPF를 사용하면 프로그램은 커널 수준에서 발생하는 모든 것을 관찰하고 이벤트를 고속으로 처리하여 예상치 못한 동작을 확인하고 다른 경우보다 훨씬 빠르게 경고를 발생시킬 수 있습니다. 예를 들어 - 대규모 침입 감지를 위해 eBPF를 사용합니다. Google은 eBPF를 사용하여 컨테이너 보안을 구현합니다. Shopify는 이제 여러 데이터 수집 및 모니터링을 위해 eBPF를 사용합니다. 타사 보안 제품에서 네트워킹 네트워킹은 널리 적용되는 또 다른 사용 사례입니다. eBPF 계층에 있으면 소스 및 대상 IP와 함께 모든 홉을 포함한 전체 네트워크 경로에 대한 가시성과 같은 포괄적인 네트워크 관찰이 가능합니다. eBPF 프로그램을 사용하면 매우 낮은 오버헤드로 커널 내에서 직접 대용량 네트워크 이벤트를 처리하고 네트워크 패킷을 조작할 수 있습니다. 이를 통해 로드 밸런싱, DDoS 방지, 트래픽 조절, 서비스 품질(QoS)과 같은 다양한 네트워킹 사용 사례가 가능합니다. eBPF를 사용하여 DDoS 공격을 탐지 및 방지하고 네트워크 성능에 영향을 주지 않고 처리합니다. Cloudflare는 초당 1천만 패킷을 Meta의 eBPF 기반 Facebook 전체에 대해 로드 밸런싱을 수행합니다. Katran은 관찰 가능성 이제 eBPF가 Observability에서 어떻게 유용할 수 있는지 간단해졌습니다. 모든 것이 커널을 통과합니다. 그리고 eBPF는 커널의 모든 것을 관찰할 수 있는 고성능의 안전한 방법을 제공합니다. 관찰 가능성에 대해 더 자세히 알아보고 이 기술의 의미를 살펴보겠습니다. eBPF는 관측 가능성에 정확히 어떤 영향을 미치나요? 이를 탐구하기 위해 eBPF 세계에서 벗어나 관찰 가능성 세계로 들어가 표준 관찰 가능성 솔루션을 구성하는 요소를 살펴보겠습니다. 모든 관측 솔루션에는 4가지 주요 구성 요소가 있습니다. - 애플리케이션 및 인프라에서 원격 측정 데이터 가져오기 데이터 수집 - 수집된 데이터에 대한 필터링, 인덱싱 및 계산 수행 데이터 처리 - 데이터의 단기 및 장기 저장 데이터 저장 - 사용자가 데이터를 소비하는 방식 결정 사용자 경험 계층 이 중 eBPF가 (현재) 영향을 미치는 것은 실제로 데이터 수집 계층, 즉 eBPF를 사용하여 커널에서 직접 원격 측정 데이터를 쉽게 수집하는 것입니다. 따라서 오늘날 "eBPF 관찰 가능성"이라고 말할 때 의미하는 것은 다른 계측 방법을 사용하는 대신 eBPF를 계측 메커니즘으로 사용하여 원격 측정 데이터를 수집하는 것입니다. 관찰 솔루션의 다른 구성 요소는 영향을 받지 않습니다. eBPF 관찰 가능성의 작동 방식 eBPF 관찰 가능성의 기본 메커니즘을 완전히 이해하려면 후크 개념을 이해해야 합니다. 앞서 살펴본 것처럼 eBPF 프로그램은 주로 이벤트 중심입니다. 즉, 특정 이벤트가 발생할 때마다 트리거됩니다. 예를 들어, 함수 호출이 이루어질 때마다 eBPF 프로그램을 호출하여 관찰 목적으로 일부 데이터를 캡처할 수 있습니다. 첫째, 이러한 후크는 커널 공간이나 사용자 공간에 있을 수 있습니다. 따라서 eBPF를 사용하여 사용자 공간 애플리케이션과 커널 수준 이벤트를 모두 모니터링할 수 있습니다. 둘째, 이러한 후크는 미리 결정되거나 정적이거나 실행 중인 시스템에 동적으로 삽입될 수 있습니다(다시 시작하지 않음!) 4개의 서로 다른 eBPF 메커니즘이 각각을 허용합니다(아래 그림 참조). 사전 결정/수동 동적 핵심 커널 추적점 kprobes 사용자 공간 USDT 가운 사용자 공간과 커널 공간에 대한 정적 및 동적 eBPF 후크 - 커널 개발자가 미리 정의한 이벤트에 연결하는 데 사용됩니다(TRACE_EVENT 매크로 사용). 커널 추적점 - 개발자가 애플리케이션 코드에서 설정한 사전 정의된 추적점에 연결하는 데 사용됩니다. USDT (커널 프로브) - 런타임 시 커널 코드의 일부에 동적으로 연결하는 데 사용됩니다. Kprobes (사용자 프로브) - 런타임 시 사용자 공간 애플리케이션의 모든 부분에 동적으로 연결하는 데 사용됩니다. Urobes 커널 공간에는 eBPF 프로그램을 쉽게 연결할 수 있는 미리 정의된 여러 후크가 있습니다(예: 시스템 호출, 함수 시작/종료, 네트워크 이벤트, 커널 추적점). 마찬가지로 사용자 공간에서도 많은 언어 런타임, 데이터베이스 시스템 및 소프트웨어 스택은 eBPF 프로그램이 연결할 수 있는 Linux BCC 도구에 대해 사전 정의된 후크를 노출합니다. 하지만 더 흥미로운 것은 kprobes와 uprobes입니다. 프로덕션에서 문제가 발생하고 정보가 충분하지 않아 런타임에 계측을 동적으로 추가하고 싶다면 어떻게 해야 합니까? 이것이 바로 kprobe와 uprobes가 강력한 관찰 가능성을 허용하는 곳입니다. 예를 들어, uprobes를 사용하면 애플리케이션의 코드를 수정하지 않고도 애플리케이션 내의 특정 기능에 연결할 수 있습니다. 함수가 실행될 때마다 eBPF 프로그램이 트리거되어 필요한 데이터를 캡처할 수 있습니다. 이를 통해 디버깅과 같은 흥미로운 가능성이 가능해졌습니다. 런타임에 라이브 이제 eBPF의 관측 가능성이 어떻게 작동하는지 알았으니 사용 사례를 살펴보겠습니다. eBPF 관측 가능성 사용 사례 eBPF는 거의 모든 일반적인 기존 관측 가능성 사용 사례에 사용될 수 있으며, 추가로 새로운 가능성을 열어줍니다. eBPF를 사용하면 CPU 사용량, 메모리 할당, 디스크 I/O, 네트워크 트래픽과 같은 시스템 수준 이벤트를 심층적으로 모니터링할 수 있습니다. 예를 들어 . 시스템 및 인프라 모니터링: LinkedIn은 모든 인프라 모니터링에 eBPF를 사용합니다 Kubernetes 관련 지표, 리소스 사용량, 개별 컨테이너 및 포드 상태에 대한 가시성을 제공합니다. 컨테이너 및 Kubernetes 모니터링: 사용자 공간 애플리케이션에 대한 세밀한 관찰 가능성과 애플리케이션 처리량, 오류율, 대기 시간 및 추적에 대한 가시성을 제공합니다. 애플리케이션 성능 모니터링(APM): 사용자 정의 코드를 작성하지 않으면 쉽게 사용할 수 없는 애플리케이션 또는 인프라와 관련된 사용자 정의 측정항목에 대한 가시성을 제공합니다. 사용자 정의 관찰 가능성: eBPF는 , , 과 같은 고급 관찰 가능성 사용 사례에 사용할 수 있습니다. 고급 관찰 가능성: 라이브 디버깅 낮은 오버헤드 애플리케이션 프로파일링 시스템 호출 추적 Observability 분야에서 eBPF의 새로운 애플리케이션이 매일 등장하고 있습니다. 이는 오늘날 관찰 가능성이 수행되는 방식에 대해 무엇을 의미합니까? eBPF가 기존 형태의 계측을 대체할 가능성이 있습니까? 기존 옵션과 비교해 보겠습니다. eBPF와 기존 계측 방법 비교 오늘날 eBPF 외에도 관찰 가능성을 위해 애플리케이션과 인프라를 계측하는 두 가지 주요 방법이 있습니다. 원격 측정 데이터를 수집하기 위해 애플리케이션 코드 또는 인프라 노드에 통합된 독립 소프트웨어 SDK/라이브러리입니다. 에이전트 기반 계측: : 사이드카는 애플리케이션 또는 서비스와 함께 실행되는 가볍고 독립적인 프로세스입니다. 이는 Kubernetes와 같은 마이크로서비스 및 컨테이너 기반 아키텍처에서 널리 사용됩니다. 사이드카 프록시 기반 계측 eBPF 기반 계측을 에이전트 및 사이드카와 비교하는 방법에 대한 자세한 비교는 . 아래는 요약 보기입니다 - 여기를 참조하세요 eBPF 자치령 대표 사이드카 1. 데이터 가시성/세분성 (그러나 약간의 격차) 높음 높은 낮은 2. 침입성 (대역 외) 낮음 (인라인) 높음 (인라인) 높음 3. 성능 오버헤드 낮은 중간 높은 4. 안전 및 보안 높은 중간 중간 5. 구현 용이성 높은 낮은 중간 6. 유지 관리 및 업데이트의 용이성 높은 낮은 중간 7. 확장성 높은 중간 낮은 보시다시피 eBPF는 거의 모든 매개변수에서 기존 계측 방법보다 성능이 뛰어납니다. 여러 가지 이점이 있습니다 - (인프라, 애플리케이션) 모든 것을 한 번에 처리 가능 - eBPF는 워크로드가 실행될 때마다 실행되는 코드 에이전트와 같은 실행 워크로드의 인라인이 아닙니다. 데이터 수집은 대역 외 및 샌드박스 방식으로 수행되므로 실행 중인 시스템에 영향을 주지 않습니다. 덜 방해적임 - eBPF는 기본 기계어 코드로 실행되며 컨텍스트 전환이 없습니다. 낮은 성능 오버헤드 - 확인과 같은 내장된 보안 조치로 인해. 더욱 안전함 . 코드를 변경하거나 다시 시작하지 않고도 바로 설치할 수 있습니다. 설치가 간편합니다 . 코드를 변경하거나 다시 시작할 필요가 없습니다. 유지 관리 및 업데이트가 쉽습니다 - 손쉬운 구현 및 유지 관리, 낮은 성능 오버헤드를 통해 구동됩니다. 확장성 향상 단점 측면에서 오늘날 eBPF 관측 가능성의 주요 격차는 분산 추적에 있습니다( 하지만 사용 사례는 아직 초기 단계입니다). 실행 가능 균형적으로 eBPF가 기존 계측 방법에 비해 제공하는 상당한 이점을 고려할 때 eBPF가 기본 차세대 계측 플랫폼으로 등장할 것이라고 합리적으로 기대할 수 있습니다. 관측 가능성에 대한 시사점 이것이 관측성 산업에 어떤 의미가 있나요? 어떤 변화가 있나요? 관찰 가능성 솔루션을 상상해보세요. 5분 안에 커널에 들어갈 수 있다는 것 코드 변경이나 재시작 없음 인프라, 애플리케이션, 모든 것을 한 번에 처리 오버헤드가 거의 0에 가깝습니다. 매우 안전하다 이것이 바로 eBPF가 가능하게 하는 것입니다. 이것이 바로 기술에 대한 관심이 그토록 많은 이유입니다. 차세대 관측 솔루션은 모두 코드 에이전트 대신 eBPF를 사용하여 계측될 것으로 예상할 수 있습니다. Datadog 및 NewRelic과 같은 기존 플레이어는 이미 코드 기반 에이전트 포트폴리오를 강화하기 위해 eBPF 기반 계측 구축에 투자하고 있습니다. 한편 와 모두 해결하는 eBPF를 기반으로 구축된 여러 차세대 공급업체가 있습니다. , 틈새 사용 사례 복잡한 관찰 가능성을 기존 플레이어는 수년에 걸쳐 언어별, 각 인프라 구성 요소에 대해 개별 코드 에이전트 언어를 구축해야 했지만 신규 플레이어는 eBPF를 사용하여 몇 달 만에 동일한 수준의 적용 범위를 확보할 수 있습니다. 이를 통해 데이터 처리, 사용자 경험, 심지어 와 같은 더 높은 가치 사슬을 혁신하는 데 집중할 수도 있습니다. 또한 데이터 처리 및 사용자 경험 레이어도 새로운 사용 사례, 볼륨 및 빈도를 지원하기 위해 기본적으로 구축되었습니다. AI 이 모든 것이 이 분야에서 많은 혁신을 주도하고 향후 몇 년 동안 관찰 가능성을 더욱 원활하고 안전하며 쉽게 구현할 수 있도록 해야 합니다. eBPF 관측성은 누가 사용해야 합니까? 첫째, 최신 클라우드 네이티브 환경(Kubernetes, 마이크로서비스)에 있는 경우 eBPF 기반 접근 방식과 에이전트 기반 접근 방식 간의 차이점이 가장 눈에 띕니다(성능 오버헤드, 보안, 설치 용이성 등). 둘째, 대규모로 운영하는 경우 eBPF 기반 경량 에이전트는 현 상태보다 극적인 개선을 가져올 것입니다. 이는 LinkedIn, Netflix, Meta와 같이 막대한 규모의 기술 기업에서 eBPF 채택이 가장 높은 이유 중 하나일 것입니다. 셋째, 기술이 부족한 경우. 설치 및 유지 관리에 거의 노력이 필요하지 않은 관찰성 솔루션을 찾고 있다면 바로 eBPF 기반 솔루션을 선택하세요. 요약 요약하자면, 훨씬 더 나은 계측 메커니즘을 제공함으로써 eBPF는 앞으로 몇 년 동안 관찰 가능성에 대한 접근 방식을 근본적으로 바꿀 수 있는 잠재력을 가지고 있습니다. 이 기사에서는 주로 데이터 수집/계측에서 eBPF의 애플리케이션을 살펴보았지만 향후 애플리케이션에서는 데이터 처리 또는 데이터 저장 계층에서도 eBPF가 사용되는 것을 볼 수 있습니다. 가능성은 광범위하지만 아직 탐구되지 않았습니다. 참고자료 https://www.oreilly.com/library/view/learning-ebpf/9781098135119/ch01.html https://ebpf.io/ https://ebpf.io/summit-2022.html https://github.com/microsoft/ebpf-for-windows https://events.linuxfoundation.org/wp-content/uploads/2022/10/elena-zannoni-tracing-tutorial-LF-2021.pdf 여기에도 게시되었습니다.

eBPF가 우리가 알고 있는 관찰 가능성을 어떻게 변화시키는가 🕵️‍♀️🐝

너무 오래; 읽다

@zerok

Credibility

관련 기사