최근 몇 년 새 IT 업계에서 급속도로 떠오른 키워드가 하나 있습니다. 바로 ‘노코드, 로코드(no code, low code)’인데요. 이는 코딩을 최소화하고, 간소화한 것이죠. 노코드, 로코드 도구를 활용하면 코딩할 줄 모르는 비개발자도 소프트웨어를 간단히 개발할 수 있습니다. DevOps 업계에서도 ‘노코드, 로코드를 DevOps에 적용하는 방안’을 모색하고 있는데요. 그 결과물은 노코드, 로코드 기반의 DevOps 플랫폼, CI/CD 파이프라인 에디터 등 서비스로 나오기도 합니다. DevOps 업계는 노코드, 로코드의 어떤 점에 주목해 이를 DevOps에 접목하려는 걸까요? 노코드, 로코드는 DevOps가 발전하는 데 도움이 될 수 있을까요? 이 글에서는 DevOps 업계가 노코드, 로코드를 주목하는 배경과 노코드, 로코드가 DevOps에 미치는 영향, 그리고 둘을 결합할 때 일어날 수 있는 문제를 함께 살펴보려고 합니다.

OpenAI에서 개발한 ChatGPT가 출시된 지 반년이 조금 지났습니다. 반년 동안 ChatGPT를 필두로 여러 인공지능(AI) 모델이 하루가 멀다하고 등장하는 중이며, 다양한 산업에서 파동을 일으키고 있습니다. 우리는 이를 견뎌내기 위해 빠르게 대처하고 있지만, 마치 빠르게 달리는 열차를 쫓는 느낌을 받습니다.

이렇게 끊임없이 학습과 적응이 필요한 상황에서, 생산성 향상을 위해 많은 사람이 ChatGPT를 사용하고 있습니다. 마케팅 팀은 ChatGPT로 새로운 인사이트를 얻고, 고객 서비스(CS) 팀은 ChatGPT를 이용하여 고객 질문에 답변을 더욱 빠르게 제공할 수 있습니다.

DevOps 엔지니어도 ChatGPT를 업무에 활용할 줄 알아야 합니다. 엔지니어는 그 누구보다도 발빠르게 새로운 기술을 학습하고 변화하는 환경에 적응해야 하기 때문입니다. ChatGPT가 바로 그 ‘새로운 기술’입니다. DevOps 엔지니어가 ChatGPT로 효율적이고, 생산적인 작업 흐름을 만들려면 어떻게 해야 할까요?

거의 모든 최신 소프트웨어 인프라에는 필수적으로 모니터링 또는 로깅이 존재합니다. 1980년대에 Unix 시스템에 syslog가 출시되면서 ‘시스템 내부에서 무슨 일이 일어나고 있는지 감사하고 이해할 수 있다’는 가치와 이러한 메커니즘 분리의 아키텍처적 중요성이 모두 확립되었습니다.

그러나 시스템 동작의 가시성의 가치와 중요성에도 불구하고 모니터링과 로깅은 자주 우선순위가 뒤로 밀릴 때가 많습니다. 거기다 중요한 정보를 수집하거나 로그를 분석하지 않고 로그를 내보내는 시스템의 사례는 무수히 많습니다. 또는 레거시 모니터링 시스템이 10년 전에 설치되어 최신 표준으로 업데이트되지 않은 인프라도 있습니다.

최근 운영 환경의 변화로 인해 Observability라는 개념이 등장했습니다. 엔지니어가 정적 측정값을 사용해 애플리케이션의 성능 자체에 가정을 세우는 대신, Observability로 애플리케이션 동작의 전체 그림을 볼 수 있습니다. 아울러 사용자가 성능을 어떻게 인식하는지를 알 수 있습니다.

Observability 란?

Observability의 가치를 이해하려면 먼저 ‘모니터링이 무엇인지’, ‘정보와 콘텍스트 측면에서 모니터링이 제공하는 것과 제공하지 않는 것이 무엇인지’에 대해 이해하는 게 도움됩니다.

모니터링의 핵심은 특정 시스템 또는 소프트웨어 스택의 다양한 값과 출력의 측정 결과를 제시하는 것입니다. 측정의 일반적인 메트릭은 CPU 사용량, RAM 사용량, 응답 시간 또는 Latency 등입니다. 기존 로깅 시스템도 이와 유사하며, 시스템 작동 중에 발생한 이벤트의 정적 정보를 제공합니다.

모니터링은 시스템의 더 큰 문제를 나타낼 수 있는 제한된 콘텍스트 측정값을 제공합니다. 기존 모니터링 도구를 사용하여 집계 및 상관관계를 파악할 수 있지만, 전체적인 관점을 제공하려면 일반적으로 수동 구성 및 튜닝이 필요합니다. 업계가 발전함에 따라 효과적인 모니터링의 개념은 CPU, RAM과 같은 정적인 측정값을 넘어서는 수준으로 발전했습니다. 유명한 사이트 신뢰성 엔지니어링(Site Reliability Engineering·SRE) 책에서 Google은 "Golden Signals"로 알려진 네 가지 주요 지표에 집중해야 한다고 강조합니다.

• Latency: 요청을 처리하는 데 걸리는 시간
• Traffic: 전체 네트워크를 측정한 것
• Errors: 요청이 실패하는 비율
• Saturation: 리소스 사용량을 전체의 일부분으로 측정하는 것, 일반적으로 제한된 리소스에 중점을 둠.

이러한 메트릭은 전반적인 시스템 성능을 더 잘 파악하는 데 도움이 됩니다. 완전한 모니터링 시스템을 설계, 구축, 통합, 구성하려면 적지 않은 엔지니어링 투자가 필요합니다. 장애 상황을 측정하려면 상당한 노력이 필요합니다. 간단한 상황에도 올바른 상관관계를 정의하고 연결하는 데는 많은 시간이 소요될 수 있습니다.

이러한 데이터와 지표를 기반으로 시스템의 내부 상태를 파악하고 추론하는 능력이 바로 Observability입니다. Observability로 빠른 문제 파악, 해결, 의사 결정에 도움을 줘 시스템 안전성이나 확장성에 기여할 수 있습니다. 또한 CI/CD 실행 중에 중요한 성능 피드백을 제공하여 개발자에게 코드 운영 피드백을 제공합니다. 이로써 소프트웨어 개발 수명 주기(SDLC)를 더 확장할 수 있습니다. 궁극적으로 Observability는 더 전체적인 디버깅과 시스템 이해를 지원합니다. Observability가 중요한 '이유'를 더 자세히 알아보기 위해 다음 섹션에서 모니터링만으로는 부족할 경우를 소개합니다.

Observability가 중요한 이유

Observability에 집중하면, 가동 중단을 줄이고 평균 해결 시간(MTTR)을 단축할 수 있습니다. 이로써 애플리케이션 성능을 개선하고 고객 경험을 개선할 수 있습니다. 모니터링이 같은 이점을 제공하는 것처럼 보일 수 있지만, 다음과 같은 사례가 있을 수 있습니다.

Observability는 비기술 분야 이해관계자 및 비즈니스 부서에도 중요합니다. 기술이 주요 수익 사일로와 더욱 밀접하게 얽히면서 소프트웨어 인프라 KPI는 비즈니스 KPI가 되었습니다. Observability는 KPI 성과에 더 나은 인사이트를 제공할 뿐만 아니라 여러 팀용 셀프 서비스 옵션을 제공할 수 있습니다.

한 엔지니어링 조직이 회계 부서에서 이메일을 받았습니다. '클라우드 서비스 청구서가 너무 비싸서 CFO가 이를 알아차릴 정도다.' DevOps 엔지니어는 모니터링 시스템을 면밀히 살펴봤지만 메모리, CPU, 디스크 I/O 등 시스템의 모든 부분이 지속적으로 정상으로 보고되었습니다. 알고 보니 근본 원인은 또 다른 'Unknown' 이벤트였습니다. CI/CD 파이프라인의 DNS 지연으로 인해 빌드 실패율이 높아진 것입니다. 더 많이 빌드를 함으로써 많은 클라우드 리소스를 소모했습니다. 그러나 이러한 영향은 모니터링 시스템에 반영될 만큼 오래 지속되지 않았습니다. Observability 도구를 추가하고 환경의 모든 이벤트 유형을 수집함으로써 운영팀은 문제의 원인을 정확히 파악하고 문제를 해결할 수 있었습니다. 기존 모니터링 시스템에서는 조직이 DNS 지연 문제를 사전에 알고 있어야 했습니다.

최신 소프트웨어와 애플리케이션은 우수한 사용자 경험(UX)을 제공하는 데 크게 의존합니다. 이전 사례에서 알 수 있듯이, 정적 메트릭을 모니터링한다고 해서 UX 또는 시스템 성능의 완전한 이야기를 항상 알 수 있는 것은 아닙니다. 겉보기에 정상적으로 보이는 지표 대시보드 뒤에 심각한 문제가 숨어 있을 수 있습니다.

Observability 메트릭

Observability 도구를 구현하기로 결정한 조직은, 다음 단계로 Observability 의 핵심 목표와 이를 스택 전체에서 가장 잘 구현할 방법을 식별할 수 있습니다. 다은 Observability의 세가지 기본 요소로 시작하는 것이 좋습니다.

• Logs: 정보 및 이벤트
• Metrics: 특정 메트릭 및 성능 데이터의 측정
• Tracing: 런타임 동안 엔드투엔드 성능 요청

이 작업이 부담스러울 수 있습니다. 그러나 OpenTelemetry 같은 프로젝트는 Logs, Metrics, Tracing의 광범위한 표준 수용을 촉진합니다. 이로써 Observability를 구현하는 조직이 OpenTelemetry 표준에 기반한 도구를 사용해 더 일관된 생태계를 구축하고, 가치 실현 시간을 단축하도록 돕고 있습니다

추가적인 Observability 데이터 및 요소는 다음과 같습니다.

• Error 추적: 집계가 포함된 더욱 세분화된 Log
• 지속적인 프로파일링: 세분화된 코드 성능 평가
• 실제 사용자 모니터링(RUM): 실제 사용자의 관점에서 애플리케이션 성능 이해

이러한 요소를 살펴보면 중심 주제가 드러나기 시작합니다. 최신 분산 시스템에서는 더 이상 시간과 공간의 작은 조각을 보는 것만으로는 충분하지 않습니다. 전체적인 10,000 피트 뷰가 필요합니다. 애플리케이션 성능의 이해는 실제 고객이 경험하는 대로 샘플링한 다음, 소프트웨어와 상호 작용할 때 전체 성능과 동작을 추가로 모니터링하는 것에서 시작됩니다.

기존의 애플리케이션 모니터링을 넘어 Observability는 모든 엔지니어링 조직의 운영 환경을 개선하는 데 도움이 될 수 있습니다. 잘 만들어진 알림 및 인시던트 관리 프로그램은 대개 실제 중단을 통해 얻은 혹독한 교훈에서 비롯됩니다. 카오스 엔지니어링을 구현하면 결과가 알려진 통제된 환경에서 실제 장애가 발생하는 동안 Observability 플랫폼을 테스트할 수 있습니다. 프로덕션 워크로드뿐만 아니라 CI/CD 파이프라인, 공급망, DNS 등 'Unknown'이 숨어 있을 수 있는 시스템에 카오스 엔지니어링을 도입하면 운영 기반에서 상당한 이점을 얻을 수 있습니다.

Observability의 중요성

Observability는 데브옵스뿐만 아니라 조직 전체에 매우 중요합니다. Observability는 레거시 모니터링 솔루션의 정적 데이터를 대체하여 애플리케이션 인프라의 전체 스펙트럼을 보도록 지원합니다.

DevOps 팀은 이해관계자와 협력하여 조직 전체에 도움이 되는 방식으로 Observability 메트릭을 공유하고 구현을 개선하는 조치를 취해야 합니다. 앱 계측의 이점을 학습하고 개발 팀에 전파하면 Observability를 더욱 효과적으로 만들 수 있습니다. 또한 DevOps 팀은 프로덕션 인시던트의 근본 원인을 더 빨리 파악할 수 있으며, 잘 계측된 애플리케이션 코드는 인프라 문제와 쉽게 구분할 수 있습니다. 마지막으로, CI/CD 파이프라인을 따라 Observability가 달라집니다. 잠재적인 서비스 수준 목표(SLO) 델타를 프로덕션에 도달하기 전에 발견할 수 있습니다.

애플리케이션 성능과 비즈니스 성과에 의미 있는 개선을 제공하고자 하는 DevOps 팀은 두 가지를 모두 제공하는 방법으로 Observability를 고려할 수 있습니다.

Reference

• Observability vs. monitoring in DevOps

최근 IT 업계에서 마이크로서비스 아키텍처, 클라우드 네이티브와 같은 최신 기술 트렌드가 빠르게 채택되고 있습니다. 그러나 규모가 확장되면서 복잡해진 아키텍처에 대해 사용자들이 어려움을 겪고 있습니다.

오늘날 모든 회사는 소프트웨어 회사이므로 혁신 및 제공 수준이 수익 창출에 직접적인 영향을 미칩니다. 성공하기 위해 기업은 놀라운 디지털 경험을 제공하고, 최신 기술을 따라잡고, 고객이 요구하는 속도로 가치를 제공하고, 중단이나 보안 위반에 대해 무관용으로 모든 작업을 수행해야 합니다. 여기서 Value Stream Management(VSM)이 시작됩니다.

지난 MergeRequest로 개발 협업하기를 끝으로 디자이너, 개발자, PM이 서로 커뮤니케이션하고 협업하는 과정을 배워봤습니다.

하지만 구체적으로 뭐가 좋은지 아직 감이 안 잡히는 분들도 계실 겁니다.
그래서 역할별로 MR(Merge Request)의 장점을 총정리하는 시간을 가져 보겠습니다.

클라우드 시대가 되면서 인프라 엔지니어는 서버실에서 벗어나게 되었습니다. AWS 콘솔에서 클릭 몇 번으로 서버를 배포하고, 명령어 한 줄로 다양한 인프라를 구축할 수 있게 되었습니다. 더 나아가 인프라를 더 빠르고, 안전하게 관리하는 방법이 등장합니다.

지난 MergeRequest 만들기 포스트에서는 PM(Project Manager)이 이슈를 생성하고 디자이너와 협업하며 MR를 생성하는 부분까지 진행하였습니다.

이번엔 MR(MergeRequest)로 개발자와 협업하는 방법에 대해 자세히 알아보겠습니다.

애플리케이션을 Docker 이미지로 만들고, 배포해본 경험 다들 있으신가요? 무거운 이미지를 베이스 이미지로 사용해 한 번 다운받는 데 무척 오랜 시간이 걸리거나, 민감한 데이터를 포함하게 되어 보안상 문제가 생겼던 경험도 다들 있으실 겁니다. 이번 포스팅에서는 더 가볍고, 안전한 이미지를 만들기 위해서는 어떻게 해야 하는지 한 번 알아보겠습니다.

DevOps를 적용한다고 하면, CI/CD를 포함하는 자동화를 제일 먼저 생각하게 됩니다. CI/CD를 완료성있게 구축하고 운영하는 일은 간단하지 않습니다. GitLab과 같이 단일 도구를 사용하면 조금 더 간단해질 수 있습니다. GitLab은 CI/CD 스크립트를 레파지토리에 .gitlab-ci.yml 파일로 소스 코드 관리하는 방식으로 이용됩니다. 소스 코드가 업데이트 되면, 파이프라인 결과를 확인할 수 있습니다. Merge Request 화면에서도 변경에 대한 파이프라인 결과를 확인하면서 자동화 테스트, 보안 테스트, 배포 결과를 확인할 수 있는 피드백을 주고 받을 수 있습니다. 이 과정을 단순화시키고 활용할 수 있는 방법을 DevOps 실무자들이 만들어갑니다. 인포그랩은 GitLab을 사용하는 실무자들이 CI/CD 파이프라인을 쉽게 운영관리할 수 있는 밀키트를 만들기 시작했습니다. 프로젝트마다 CI 스크립트를 복사 & 붙여넣기 하지 않고 템플릿으로 쉽게 관리할 수 있습니다.

지난 'MergeRequest 왜 사용해야 할까?'에서는 협업을 하면서 발생하는 문제점과 MR(MergeRequest)의 이점을 살펴보고 MR을 사용해야하는 이유를 알아보았습니다.

오늘은 본격적으로 MR 사용법을 배워보도록 하겠습니다.

Docker로 애플리케이션을 배포하여 서비스를 운영 중인 Linux 서버에 디스크 용량이 부족하다는 오류나 경고 메시지가 발생한 경험이 있으신가요?

프로젝트 협업 어떻게 하는게 좋을까요?

우리의 삶에서 인터넷을 떼어 놓을 수 없듯이 어떤 서비스를 하든 소프트웨어가 빠지는 곳이 없습니다. 소프트웨어의 사이즈는 거대해졌고, 기술과 사회는 빠르게 변화하고 있습니다. 그래서 보다 빠르게 개발하고 배포하는 것이 중요해졌습니다. 이를 위해 다수의 사람들이 협업하여 개발을 진행하고 있습니다. 그런데 수많은 사람들이 협업을 하는데 문제가 발생하지 않을까요? 여러 사람들과 협업을 하다보면 다양한 문제를 마주치게 됩니다.

클라우드에서 인프라를 구축을 할 때 비용 절감, 배포 속도 향상, 일관성, 안정성 및 재사용성을 고려하여 웹 콘솔로 구축하기보다는 IaC(Infrastructure as Code) 도구를 활용하여 구축하는 것이 좋습니다. 오픈소스이며 IaC 도구 중 가장 많이 사용하는 것이 Terraform입니다. Terraform 코드를 효율적이고 효과적으로 작성하기 위해서는 Terraform에서 제공되는 기능들을 적절하게 사용하는 것이 중요합니다. 그렇지 않으면 예상과 다른 결과가 발생할 수 있습니다. 이번 글에서는 Terraform에서 제공하는 각 반복문의 특징과 차이점을 알아보겠습니다.

GitLab은 유일무이한 진정한 엔드 투 엔드(end-to-end) DevOps 플랫폼입니다. GitLab은 더 높은 수준의 보안을 지원하는 동시에 최신 애플리케이션 개발 이슈를 해결할 수 있도록 지원합니다. GitLab은 SCM과 CI 모두에서 인정받는 리더기업이며, 최근에는 애플리케이션 보안 분야의 유망주이기도 합니다. GitLab은 DevOps 플랫폼에 보안 기능을 구축했으며, 업계 분석가들은 GitLab의 보안 기능을 포인트 타 보안 솔루션과 직접 비교한 다양한 보고서를 작성하였습니다.