포토/동영상 (1)
|
몇 번의 클릭만으로 확장 가능한 우수한 인프라를 활용하여 개발에만 집중할 수 있는 시대가 왔다. 서버리스, 클라우드, 데브옵스 등은 이런 것들을 가능하게 해주는 개념이다. 언제나 그렇듯 개발자에게 많은 것을 몰라도 서비스를 가능하게 해주는 기술들의 장점 이면에는 단점도 숨어있다. 보이지 않는 블랙박스는 때로는 신경쓰지 않아도 되는 편리함을 주지만 다른 한 편으로는 그 내부의 동작방식을 알 필요가 있게 되었을 때 답답함이라는 단점을 선물한다. 분산 환경으로 마이크로서비스가 유행하는 요즘은 특히 각 서비스들이 바로 이런 문제점을 해결하고자 내부적으로 운영 환경에서 어떠한 일들이 벌어지고 있는지를 쉽게 추적하고자 노력하는 과정에서 관찰 가능성이 대두되었고 이 기술의 대표적인 오픈소스로 OpenTelemetry가 자리매김 하고 있다. 결론부터 말하자면 이 책은 관찰 가능성과 OpenTelemetry의 구축 및 활용법을 다룬 책이다. 개인적으로는 5년 전 즈음 사내 빅데이터 분석 환경을 구성하기 위해 빅데이터 생태계의 다양한 오픈 소스들을 직접 설치하고 운영할 기회가 있었다. 그 중 Fluentd, 로그스태시, 플럼 같은 것들을 활용하면서 로그 수집이 매우 편리해짐을 느꼈다. 언젠가 사내의 레거시 시스템들을 통합 로그 관리할 수 있는 별도 레이어를 구축해봐야겠다는 구상을 했고 업무 우선 순위에 밀려 완성시키지는 못했지만 구축 시도 과정에서 관련 지식들을 다양하게 습득할 수 있었다. 덕분에 본 도서를 한층 깊게 이해하는 데 도움이 되었고 통합된 로그 분석 환경을 구축하고자 개인적으로 골머리 앓았던 많은 부분들을 OpenTelemetry가 어떻게 현명하게 대처하고 있는지 엿볼 수 있었기에 이 책을 더욱 흥미롭게 읽을 수 있었다. 이 책에서는 구축, 연동, 활용 방법을 다루지만 OpenTelemetry을 어떻게 구현했는지는 다루고 있지 않기에 내부 동작 방식을 정확히는 알 수 없다. 다만 구축 및 활용 과정의 가이드를 보며 개인적으로 했던 고민들을 오픈소스 기여자들이 어떤 접근 법으로 해결했는지를 엿볼 수 있어 관찰 가능성과 OpenTelemetry에 대한 배움 외에도 설계 측면에서 소득이 많아 즐거웠다. 이 책을 읽기에 앞서 여러 사전 지식들이 필요하다. 주 언어로 Python의 기본 문법 및 웹 관련 기술들을 알아 두어야 OpenTelemetry를 연동하는 방법이 수월하게 읽힐 것이다. 더불어 도커나 쿠버네티스와 같은 오늘날의 마이크로서비스를 가능하게 만들어준 인프라 기반 지식들이 필요하고 실제로 OpenTelemetry의 다양한 기능을 살펴보는 것 보다는 아래 그림과 같은 grocery-store는 특히 OpenTelemetry의 다양한 기능을 확인할 수 있도록 다양한 조작을 걸치며 변화시킨다는 점을 미리 알면 도움이 될 것이다. 프로메테우스, 예거, 그라파나와 같은 또한 OpenTelemetry 환경에서 아래 그림은 실제 Python 환경에 어떻게 이러한 대략적인 과정들을 거쳐 OpenTelemetry를 구축하고 레거시와 연동에 성공했다면 이렇게 수집한 데이터를 어떻게 활용할지도 중요한 부분이 된다. 전자의 내용이 파트2에, 후자의 내용이 파트3에 담겨있다. 참고로, 파트1은 관찰가능성의 개념과 관련 기술이 그동안 어떻게 발전해왔는지를 소개한다. OpenTelemetry의 아래 그림은 정리하자면 이 책은 OpenTelemetry를 구축, 활용하는 과정을 통해 관찰가능성이 무엇인지 확실하게 이해하고 마이크로서비스의 블랙박스 이슈로 골치 썩어본 경험이 있거나, 운영 환경의 분리 및 무지로 인해 고통을 겪고 있거나, 관찰 가능성에 관심 많은 독자에게 꼭 추천하고 싶은 책이다. 어려운 개념보다는 OpenTelemetry를 직접 만지고 다뤄봄으로써 관찰 가능성의 개념을 쉽게 익힐 수 있음은 물론 실무에 바로 적용하여 편리함을 만끽할 수 있기 때문이다. |
마이크로서비스 아키텍처의 성격상 여러개로 나누어진 서비스들을 통과하는 여러 메시지나 상태등에 대한 모니터링과 추적에 대한 중요성은 굉장히 중요하다.
관찰 가능성은 시스템의 외부 출력에 대한 결과 값(지식)으로부터 시스템의 내부 상태를 얼마나 잘 추론 할 수 있는지를 나타내는 척도입니다. 출력 값 측정으로부터 시스템의 상태를 추정하도록 설계된 동적 시스템을 상태 관찰 가능성 또는 단순히 해당 시스템의 관찰 가능성이라 합니다. ? 위키피디아
이 책은 모니터링의 상위 개념인 관측 가능성(observability)에 대한 개념등에 대한 내용을 다루며, 오픈소스인 OpenTelemetry를 이용한 예제를 제공하고 있는데, 굉장히 다양한 예제를 제공하고 있어 실무에 적용하기 위한 참고서로도 적합한 것으로 보인다.
한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. |
|
서비스를 개발할 때 관찰이 중요합니다. 관찰이 중요한 이유는 잘못된 상황을 바로잡기 위함입니다. 서비스를 개발할 때 개발과 테스트를 같이 진행하는 회사가 있습니다. 미리 테스트를 코드를 짜면서 코드 개선과 리팩토링을 안전하게 진행이 가능합니다. 서비스 품질 향상에 도움을 주는 책을 소개해 드리겠습니다. 소개해 드릴 책은 ‘관찰 가능성 엔지니어링’입니다. 서비스는 개발한 후 배포하고 운영하게 됩니다. 운영 중 오류가 발생하면 대비하지 않으면 오류를 찾을 때 애를 먹을 수 있습니다. 잠재적인 오류도 미리 알고 사전에 방지할 수 있다면 효과적으로 운영할 수 있을 것입니다. 운영을 어떻게 효과적으로 운영하는지 같이 살펴보겠습니다.
과거에 모니터링으로 답을 찾아왔지만, 복잡한 환경에서는 역부족입니다. 복잡한 환경에서도 효과적인 방법이 있는데요. 관찰 가능성 엔지니어링은 소프트웨어 시스템의 작동 및 성능을 모니터링하고 분석해 문제를 찾고 해결하는 과정을 가리키는 개념입니다. 시스템을 운영하면서 문제가 발생했을 때 실시간으로 파악을 가능하게 해줍니다. 모니터링은 많이들 접한 용어이지만 관찰 가능성 엔지니어링의 개념부터 실무방법 팁도 잘 소개되어 있습니다.
◆ OpenTelemetry를 활용한 신뢰성 확보와 성능 최적화 관찰 가능성 개념은 시스템에서 발생하는 데이터를 수집, 분석한 후에 시각화하여 동작합니다. 시각화된 정보를 통해 동작을 이해하고 성능이 향상됨을 확인할 수 있습니다. 관찰 가능성을 할 수 있도록 도와주는 오픈소스 프로젝트가 있는데요. OpenTelemetry는 분산된 애플리케이션 환경에서의 추적(tracing)과 메트릭(metrics) 데이터 수집이 가능합니다. 추적은 분산 시스템에서의 작업 흐름과 병목 현상을 파악하는 데 사용됩니다. 메트릭은 성능 지표를 모니터링하여 시스템의 상태와 동작을 파악할 수 있습니다. OpenTelemetry는 개발자들이 애플리케이션의 복잡한 동작과 성능을 이해하고 최적화하는 데 도움을 줍니다. 이를 통해 시스템의 문제를 빠르게 식별하고 대응이 가능합니다. 또한 모니터링과 디버깅을 향상시켜 시스템 운영 및 유지보수의 효율성을 극대화할 수 있습니다.
끝으로 이 책은 식료품 주문 웹 애플리케이션을 예시로 설명해 줍니다. 관찰 가능성 엔지니어링에 대해 예시를 통해 계측부터 이벤트 포착도 배울 수 있습니다. 설계, 코딩, 테스트, 배포, 운영 등 소프트웨어 개발 주기 내에서 어떻게 적용할 수 있는지 잘 알려줍니다. 관찰 가능성이 왜 필요한지와 어떻게 적용할 수 있는지 궁금한 개발자, 엔지니어, 시스템 운영자라면 이 책이 도움 될 것입니다.
"한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다." |
Author: 알렉스 보텐 지음 / 노승헌 옮김 출판사: 한빛미디어 Score /5: 5 엔터프라이즈 환경에서 분산 컴퓨팅 및 마이크로 서비스라는 용어가 많이 들린다. 분산 컴퓨팅은 정말 오래된 용어 이고 마이크로서비스는 비교적 최근에 많이 들리기 시작한 용어인 것 같다. 이러한 분산 환경에서 나의 서비스가 정상적인지, 데이터는 어떤식으로 흘러가는지, 문제가 생겼을 때 문제를 어떻게 해결할지에 대한 의사결정에 대한 부분의 근거는 항상 데이터가 되어야 한다. '그럼? 기존의 모니터링만으로 충분한걸까?' 답은 여러분들도 알다시피 No 이다. 그럼 모니터링에 어떤 개념을 더해야할까? 책에서 필자가 말했듯이 모니터링 + 로깅 + 추적의 3가지 개념을 아우르는 개념이다. 생각보다 많이 복잡하고 어떻게 구현을 해야할지 막막하다. 그런 상황 또는 관찰 가능성에 대한 이해를 필요로하는 독자들은 이 책이 많은 도움이 될 것 같다. 오픈 소스인 OpenTelemetry를 기반으로 설명을 이루어가고 있고 각각의 관찰가능성 요소에 대한 이해를 명확히 할 수 있도록 가이드를 제공한다. 또 다른 장점은 친절함이다. 필자의 눈높이와 독자의 눈높이는 아무래도 경험 및 지식의 차이로 인해 다를 수 밖에 없는데 필자가 눈높이를 독자 수준에 맞춰서 친절히 원인 및 결과 기준으로 자세히 설명하고 있다. 마지막 장점은 코드를 기반으로 설명한다는 점이다. 요즘 가장 핫한 기술중 하나인 쿠버네티스라든가 Helm등 다양한 최신 기술을 모니터링 관점에서 코드 기반으로 이해하는 시간을 가질 수 있다. 관찰가능성은 이제는 놀랍지도 새롭지도 않지만 공부해야할 부분이 많고 실무에 가장 강력한 영향을 미치는 분야중 하나다. 이 책을 통해서 기존 엔지니어분들이 도움을 받았으면 좋겠다. "한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평임." |
|
Chapter 1 관찰 가능성의 역사와 개념 Chapter 2 OpenTelemetry 시그널 - 분산 추적, 메트릭, 로그 Chapter 3 자동 계측 Chapter 4 분산 추적 - 코드 실행 추적 Chapter 5 메트릭 - 측정값 기록 Chapter 6 로그 - 이벤트 포착 Chapter 7 계측 라이브러리 Chapter 8 OpenTelemetry 컬렉터 Chapter 9 컬렉터 배포 Chapter 10 백엔드 시스템 설정 Chapter 11 문제점 분석 Chapter 12 샘플링
관찰 가능성과 계측부터 오류 추적과 분석까지 이 책에 담아 있습니다. 소프트웨어 개발 주기내에서 다양한 역할을 수행하는 개발자나 엔지니어, 시스템운영자분들이 참고하시면서 보면 좋은책입니다.
|
|
항상 배포 전날은 긴장이 된다. 개발자는 아니지만 아니 개발자가 아니라서 더 긴장이 된다. QA팀을 거쳐 일반적으로 발생하지 않는 케이스들 까지 모두 확인을 한 뒤라도 항상... 배포 전날은 굉장히 신경이 쓰이고 배포하는 시간이 언제든 상관없이 배포 직후에는 기본적인 테스트를 빠르게 수행해본다. 내 직무가 아님에도 불구하고..
개발에 버그가 없을 순 없지만 개발팀 친구들과 이야기를 나눌 때 종종 물어보던 부분이 모니터링에 대한 부분이다. 막상 문제가 터지기 전에 미리 알 수 있는 방법은 없나? 분명 문제가 될 것으로 예측이 되는데 왜 우리는 특정 기능에 대해서만 로드 및 밸런스 테스트 정도만 진행하는가. 여러번 배포 이후 라이브 서버에서 문제가 되었거나 문제 발생의 소지가 있어서 급하게 작업했던 기억이 있지 않나..
라는 질문에 대한 일종의 해답을 제시하는 책을 만났다.
결론 부터 말하자면 모니터링의 상위 개념인 옵저버빌러티(Observability) 에 대한 이야기이고 보다 라이브하게 말하자면 OpenTelemetry 사용법이다. 사용법에 가깝다! 가 아니라 그냥 대 놓고 사용법이다.
물론 사용법만 있는 것은 아니고 나처럼 Observability에 대한 개념이 생소한 사람을 위한 개론적인 설명도 충분히 있다.
그래 읽어보니 모니터링 그 이상인 것도 알겠고 필요하다는 것도 알겠다.
또한 책의 구성 역시 시각적인 자료의 구성부터 챕터 말미의 요약 섹션까지 나무랄데 없었으나 아무리 간단하고 아무리 쓸모 있어도 계측시스템을 OpenTelemetry 사용법 및 추천도서 하나만 보고 실제 서비스에 적용하기에는 무리가 있다고 판단이 되었다.
물론 독립적인 신규 서비스를 테스트 할 때 적용은 한 번 해볼 것 같긴한데 일단 내가 하고 싶다고 바로 적용할 수 있는 것도 아니니 개발팀장님부터 해서 이 책을 선물하며 우리도 신문물 적용좀 해보자고 잘 꼬드겨 봐야겠다.
책의 서두에서 밝히듯 모니터링 시스템 구축 및 Observavility 관련 스트럭쳐 구성은 이야기만 꺼내도 개발팀에서는 발작버튼과 같은 역할을 해 온터라 쉽지는 않겠지만 그래도 내가 집요하게 설득하느니 슬쩍 이 책을 한 번 들이밀어보고 이야기를 꺼내 볼까 한다.
잘.... 안될 것 같긴한데....
물론 이건 책이 부족해서가 아니라 밤잠을 줄여가며 작업하는 개발팀에서 새로운 무언가를 쉽사리 받아들여주지 않을 것 같다는 느낌적인 느낌 때문이다..
모니터링의 도입으로 문제 발생의 빈도가 확 줄어들거나 예측 가능성이 비약적으로 높아진다면 아니 높아져서 단 한번이라도 등골서늘한 경험을 피할 수 있다면 그 다음 부터는 잘 도입해서 쓸 것 같지만 아직은 미지수다... 특히 오픈소스 하나에 의존해서 모니터링 시스템을 구축한다..... 음.... 잘 모르겠다.. 요즘엔 개발이라는 것이 대부분 외부 리소스의 조합으로 진행되지만 모니터링의 디펜던시가 유일한 오픈소스 솔루션에 걸린다면... 고민을 많이 하게 될 것 같다.
다만 이러한 Observability 관련 소스나 경험들이 더 많이 확산되어 개발팀의 야근이 줄어들고 긴급 상황 발생이 더 많이 줄어들길 바란다!
"한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다."
|