Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

SRE

'마이크로서비스, 모노리포, SRE'…덮어놓고 구글 따라하면 안 되는 기술들

몇 년 전, 구글은 클라우드 제품 홍보 방식을 두고 고민을 거듭했다. 2017년 당시 필자는 구글이 일반 기업이 ‘구글처럼 운영’할 수 있도록 지원해야 한다고 제안했다. 그러나 한 구글 클라우드 제품 담당 고위 임원과의 대화에서 구글이 이 접근 방식을 배제했다는 사실을 알게 됐다. 이유가 무엇일까? 주류 기업의 요구사항이 구글과 달랐을 수도 있고, 구글처럼 하라는 말이 오히려 기업에 지레 겁을 먹게 할 것이라고 생각했을 수도 있다.   일반 기업의 IT 부서에서 일하는 보통 사람들(결국 모든 사람이라는 뜻)이 걱정할 필요 없다. 어차피 이제 구글이 하는 많은 일이 일반 기업의 IT 요구사항과는 맞지 않기 때문이다.   AWS 엔지니어이자 아파치 HTTP 서버를 만든 사람 중 한 명인 콤 맥카타이는 트위터에서 ‘아마존, 구글, 마이크로소프트, 페이스북이 하고 있지만 다른 모든 기업에는 맞지 않는 기술의 예’가 무엇일지를 물었다. 이 질문에 대해 과도한 업타임 보장, 사이트 안정성 엔지니어링, 마이크로서비스, 모노리포 등 여러 유익한 답이 나왔다.   과도한 업타임 보장 피트 엘크는 “99.999%, 또는 그 이상의 가용성 보장은 FAANG으로 불리는 페이스북, 아마존, 애플, 넷플릭스, 구글만한 규모가 아니라면 의료와 911 콜센터 정도를 제외하고 필요한 분야가 없고 ROI도 맞추지 못할 것”이라고 말했다.   필자도 여러 신생 기업과 어도비에서(어도비의 서비스 수준 보장 수치는 99.999%까지는 아니지만 필요 이상으로 높은 경향이 있음) 직접 경험해서 알고 있다. 멀티 플레이어 게임이 다운된다면 문제가 생기지 않을까? 괜찮다. 오피스 365가 몇 분, 심지어 몇시간 동안 다운되면 문제가 크지 않을까?아니, 괜찮다.   사이트 안정성 엔지니어링(Site reliability engineering) 데브옵스보다 먼저 나왔지만 조금 비슷한 면이 있는 SRE(Site reliability engineering, 맥카타이의...

모노리포 마이크로서비스 FAANG 2020.10.14

SRE와 개발자간 이상적인 협업을 위한 5가지 조언

프로세스, 품질, 협업을 개선하기 위한 비판적인 피드백과 조언은 IT 실무자 모두에게 중요하다. 애자일 개발팀은 제품 소유자, 비즈니스 관계 관리자, 이해관계자, 고객, 그리고 현재 개발 및 지원 중인 애플리케이션의 최종 사용자로부터 이런 피드백을 받는 경우가 많다. 애플리케이션이 사용하기 어렵거나 동작 속도가 느리거나 워크플로우의 요구 사항을 해결하지 못하면 애자일팀은 이런 비판적인 피드백을 수용해 백로그 우선순위를 조정해야 한다.   개발, 테스트, 프로덕션 환경의 애플리케이션을 지원하는 운영팀의 피드백을 받는 것 역시 이에 못지않게 중요하다. 사이트 안정성 엔지니어(Site Reliability Engineers, SRE)는 프로덕션 애플리케이션의 안정성과 성능을 최종적으로 책임지는 사람으로, 개발팀이 참고할 권장 사항과 피드백을 제공하는 매우 중요한 직책이기도 하다. 개발자는 동료의 입장이 되어 SRE의 책임과 툴, 활동에 대해 생각해야 한다. 애플리케이션을 개선하는 방법과 개발 프로세스, 성능에 영향을 미치는 툴에 대한 현직 SRE의 조언을 모았다.   하나의 데브옵스팀으로 SRE와 협업하라 기술 부서에서 SRE는 리더의 지시에 따라 하나의 애자일 개발팀 또는 여러 팀과 함께 작업한다. 대체로 개발자와 개발팀의 수가 SRE보다 훨씬 더 많다. 이처럼 SRE는 여러 영역과 팀에 걸쳐 시간을 분배하는 경우가 일반적이므로, 비즈니스와 많은 애플리케이션의 기술적 세부 사항에 대해 잘 알아야 한다. 부서와 팀의 구조와 관계없이 개발자는 SRE를 같은 목표를 향해 움직이는 팀의 일부로 간주해야 한다. 빅판다(BigPanda)의 현장 CTO인 제이슨 워커는 "프로덕션 사고에 대처하고 성능 문제를 조사하는 데 대부분의 시간을 보내는 SRE와, 다음 버전의 신기능을 만드는 데 대부분의 시간을 보내는 개발자가 서로 목표를 일치시켜야 한다. SRE팀을 만들고 이들이 알아서 모든 문제에 대처하기를 기대하는 것으로는 부족하다. 개발자 역시 함께 프로...

SRE 사이트안정성엔지니어 개발자 2020.09.01

'절차 간소화부터 자동화까지' AI옵스란 무엇인가

데브옵스(DevOps)와 SRE(Site Reliability Engineering)는 애플리케이션을 관리 및 유지하는 데 필수적이다. 여기에 더해 AI옵스(AIops)가 효율성을 한 단계 더 높일 수 있다. IT 운영팀은 시스템 및 애플리케이션의 성능 문제를 여러 툴을 사용해 모니터링, 진단, 해결한다. 1,300 명의 IT 전문가를 대상으로 한 ‘모니터링 및 AI옵스의 미래(future of monitoring and AIops)’에 관한 최근 설문조사에 따르면 응답자의 42%가 10가지 이상의 모니터링 툴을, 19%는 25가지 이상의 툴을 사용한다.  단지 시스템을 원활하게 운영하고 애플리케이션 오류를 모니터링, 알림, 조사, 해결하는 데 필요한 데이터를 제공하는 것치고는 너무 많은 도구를 사용하는 것이 아닐까?    여기에는 이유가 있다. 만능 모니터링 툴이 없기 때문이다. 수십 개의 모니터링 툴은 각각 다 하는 역할이 있다. 멀티 클라우드 환경에서 미션 크리티컬 애플리케이션을 구동하는 경우라면 특히 그렇다. 게다가 모바일 앱, 마이크로서비스, 데이터옵스, 데이터 과학에 대한 투자가 진행되면서 도메인별 모니터링 기능을 제공하는 새로운 모니터링 툴까지 등장하고 있다.  AI옵스 플랫폼의 목표는 이런 복잡한 모니터링 툴 환경을 단순화하는 것이다. AI옵스는 높은 수준의 애플리케이션 서비스를 필요로 하는 기업이 모니터링 툴과 IT 운영 워크플로우의 복잡성을 한층 원활하게 처리하는 데 도움을 준다. 이름에서 알 수 있듯 AI옵스는 머신러닝과 자동화 기능을 IT 운영에 제공한다. 이를 통해 오류를 신속하게 해결하고, 성능에 영향을 미치는 운영 추세를 식별하고, 문제 해결에 필요한 절차를 간소화하도록 하기 위해서다.  AI옵스는 새로운 플랫폼이다. 위의 설문조사에서 42%의 응답자가 AI옵스라는 말을 들어본 적이 없거나, IT 운영에 머신러닝을 적용하는 것이 크게 유효하지 않을 것 같다고 밝혔다. 불...

애플리케이션 AI옵스 SRE 2020.05.13

글로벌 칼럼 | 사이트 신뢰성 엔지니어링과 데브옵스가 만나는 곳은 어디인가

클라우드 애플리케이션, 데브옵스, 테스트 자동화, 사이트 신뢰성 엔지니어(site reliability engineers)가 등장하기 이전 시대에는 개발자와 테스터, 시스템 관리자가 웹 및 모바일 애플리케이션을 개발하고 지원했다. 개발자가 애자일 방법론을 추종했다면 시스템 관리자는 ITIL의 사고 관리 및 기타 실천 방안을 채택했다. 당시에는 테스트, 배포, 인프라를 자동화하기 위한 툴의 수도 지금처럼 많지 않았으므로 코드 완성부터 프로덕션 단계에 이르기까지 난관이 많았다. 운영 데이터와 모니터링 툴, 지원 워크플로우가 쉽게 통합되지 않았기 때문에 프로덕션 인프라와 애플리케이션을 모니터링하고 프로덕션 문제의 근본 원인을 찾기 위해서는 기술과 상황 대처 능력, 두 가지 모두 필요했다. 많은 측면에서 지금의 애플리케이션 개발, 테스트, 지원은 예전에 비해 쉬워졌지만 용어와 역할 정의, 실무적 책임을 해석하고 적용하기는 훨씬 더 어려워졌다. 사이트 신뢰성 엔지니어링이 속한 영역은 데브옵스인가, 보완적 서비스인가? CI/CD(지속적 통합/지속적 제공) 파이프라인과 코드형 인프라를 책임지는 사람은 누구인가? 프로덕션 사고가 발생하는 경우 문제를 해결하고 근본 원인을 찾고 최적의 교정안을 구현하기 위한 가장 효율적인 프로세스는 무엇인가? 구글의 문화와 방식, 모든 조직에 맞는 건 아니다 앞서 질문에 대한 보편적인 모범 답안은 없다. 조직의 크기, 규모와 복잡성은 제각기 다르기 때문이다. 10여 명의 엔지니어가 있는 신생 기업에서 통하는 방법과 규제를 받는 업계에서 활동하는 다국적 기업에 적용되는 방법은 다르다.  마찬가지로, 구글, 넷플릭스, 마이크로소프트와 같은 대형 IT 업체에서 효과적인 문화와 관행, 기술이 레거시 시스템과 기술 부채가 많은 다른 산업이나 기업 관점에서는 그림의 떡인 경우가 많다. 그래서 일반적인 이해에 도달하기 위해서는 다음과 같은 5가지 관점에 대한 용어의 정의가 필요하다. - 조직이 지원하는 미션, 문화, 협업, 사고방식 -...

데브옵스 Site Reliability Engineering SRE 2019.12.24

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.