2012년 봄의 ‘90분의 커피 브레이크’를 통해서 클라우드(Cloud) 환경에서의 재해 복구를 직접 보았고, 어떻게 구현했으며, 실제 어떻게 동작 했는 지 체험했었다. 강사는 이러한 전략을 설명하면서 파일럿 라이트 (Pilot Light)라는 용어를 사용했다. 그러면서 이름의 유래에 대해 설명해 주었다. 파일럿 라이트의 기본 개념은 간단한데, 화로나 난로 등의 발열 기구의 불이 타오르도록 하기 위해서 연료에 제공하는 불씨를 말한다. 난로를 “켜게 되면”, 밸브가 열리면서 주입되는 가스(연료)에 파일럿 라이트가 불을 붙여 연소가 시작되는 것이다. 마치 작은 불씨를 이용해서 난로의 연소가 시작되는 과정이 시연을 통해 보여준 재해 복구 전략과 흡사 하기 때문에 파일럿 라이트라는 이름이 붙었다고 설명해 주었다..
2012년 봄, AWS 시애틀의 수석 강사 (Principal Trainer)가 교육을 위해 한국을 찾았다. 한국에는 AWS 교육을 진행해 줄 사람이 없었기 때문에 시애틀에서 직접 방한을 한 것이었다. 일주일의 3일은 수원에서 그리고 2일은 강남에서 AWS 교육을 진행했다. AWS 서비스 기초부터 아키텍처, 동작 방식, 비동기 이벤트 기반 애플리케이션 개발에 이르기까지 다양한 분야에 대해서 알려주었다. 교육 과정은 정말 재미있었으며, 영어로 진행했음에도 불구하고 알기 쉽게 천천히 설명을 해줘서 많은 내용들이 기억에 남았다. 몇 가지 이야기가 기억에 남는데, 하나는 갤럭시 노트를 보여주며, 자기는 손이 커서, 손가락이 뚱뚱해서, 노트를 애용하고 있다고 깨알 어필하는 것이었다. 고객에게 잘보이기위한 아부처럼..
플랫폼 엔지니어링(Platform Engineering)은 소프트웨어 수명주기를 관리하기 위해 개발자가 스스로 개발, 배포, 운영을 할 수 있도록 셀프 서비스 환경을 구축하는 것을 말한다. 내부 사용자, 일반적으로 소프트웨어 개발자 및 엔지니어에게 공유 플랫폼을 제공하여 서비스 운영 효율을 높이는 것이 목적으로 하며, 최종 사용자에게는 드러나지 않는다. 공유 서비스(Shared Service), 데브옵스 툴(DevOps Tool) 또는 단순히 도구(Tool)라고 부르기도 한다. 플랫폼 엔지니어링이 중요한 이유는 개발자가 스스로 무엇인가를 만들고 시도해 볼 수 있는 효율적인 환경을 제공하되, 걸림돌 또는 병목 지점이 되지 않는 다는 것이다. 넒게 보면 이러한 장점은 서비스 개발 및 배포 간격을 짧게 해주며..
삼성과 아마존에서의 경험 그리고 구글, 넷플릭스 엔지니어와의 교류 경험을 바탕으로 대규모 서비스 운영을 위한 사이트 신뢰성 엔지니어링(SRE, Site Reliability Engineering)에 대한 강의를 했다. 오전에는 이론적인 내용 중심으로 전달했고, 오후 강의 때에는 사례 중심의 강의를 진행했다. 질의 응답을 통해 다른 회사들의 서비스 운영 사례를 나눴으며, 이미 공개되어 있는 내용들과 이 전 회사에서 겪었던 사례들을 섞어서 설명했다. 그 과정에서 다양한 질문들을 받았는데, 그 중 가장 기억에 남는 질문이 있었다. 대략적인 질문의 내용은 이러했다. "강의 내용을 보면 이미 알고 있는 내용들을 언급하고 있고, 런북(Runbook)을 만들어서 운영을 잘 하면 될 것 같다. 그런데 온콜(On-cal..
마이클 조던과 시카고 불스는 농구 역사에 전설로 남아있다. 같은 팀이었던, 스코티 피펜, 데니스 로드맨 또한 유명하다. 5명이 한 팀으로 출전하는 농구 경기에서 뛰어난 선수가 3명이나 있다는 것은 매우 놀라운 일이다. 그래서 시카고 불스는 엄청난 기록을 세우며 전설이 되었다. 여기서 시카고 불스 팀이 세운 경이로운 기록이 단 한 번의 경기에만 그친 것이 아니라는 것에 주목해 볼 필요가 있다. 각자 개성도 뚜렸했지만 실력도 좋았다. 하지만, 5명의 주전 선수만으로는 모든 시즌 경기를 소화할 수 없다. 시카고 불스가 시즌을 우승하기 위해서는 전설적인 선수도 필요하지만, 장기전을 끌어가기 위한 예비 선수도 필요하다. 교체 선수가 존재하지 않았다면, 주전 선수에게 부상이 발생했을 때 교체 선수가 없다면 팀에 큰..
포카요케(Poka-yoke)는 일본어이며, 실수를 사전에 방지한다는 의미를 갖고 있다. 이 단어를 처음 들었던 곳은 지속적 전달(Continuous Delivery) 저자인 Jez Humble의 워크샵이었다. 지속적 전달의 개념과 파이프라인, 검증 자동화, 버전 관리, 인프라스트럭처 관리, 안전한 배포방법, 모니터링에 대한 이야기를 들었다. 워크샵이 거의 끝날 때 쯤, 강사였던 Jez는 ATM기기에서 카드 리더기 방향이 한쪽으로만 가능하도록 설계된 그림을 보여주었다. 그림을 설명하면서 소프트웨어 엔지니어링에도 비슷한 설계가 필요하다고 강조했다. 소프트웨어를 개발하고 운영하는 과정에서 시스템이 문제를 일으키는 경우 보다는 사람의 실수에 의해 일어나는 문제들이 많다고 말했다. 그래서 사람이 실수하지 않는 시..
너무 오래 전 있었던, 게으름으로 인하여 기록하지 못했던 이야기를 남겨본다. AWS RDS(Relational Database Service)가 베타 버전이었을 때였다. 당시 우리 팀에서 RDS에 대한 우려가 많았던 시절이었고, 그래서 AWS RDS 엔지니어가 직접 한국을 방문했다. 그래서 우리는데이터베이스 관련한 다양한 질문을 주고 받았다. 그 중에서 기억에 남는 일화를 가져와봤다. RDS 엔지니어를 만났을 때의 첫인상은 다음과 같았다. 젋어보였고 짙은 갈색 머리를 가진 백인이었다. 뽀얀 피부에 수염을 길렀고, 진한 검정색이 매력적인 씽크패드를 들고 왔다. 잘 차려입은 격식있는 모습은 아니었지만 단정하고 깔끔한 인상이었다. 사실 그의 모습이 중요한 것은 아니었지만, 너무 인상깊었기 때문에 언급하고 싶었..
서비스 개발을 하다보면 운영이관을 위하여 시스템 설계 내역과 문제상황에 대한 대처법 등을 자세하게 기록한 문서를 만들어서 운영 담당 부서에 전달해야 하던 때가 있었다. 모든 상황을 가정하여 방대한 지침서를 만들어야 했기 때문에 이러한 운영매뉴얼을 만드는 것은 힘들고 까다로운 작업이었다. 그러던 중 서비스를 직접 개발하고 운영까지 하게된 적이 있었는데 이때는 기존과 다른 형식의 운영매뉴얼을 위키페이지로 만들었다. 처음 접하는 사람이라도 시스템을 이해하고 대응할 수 있도록 실용적이고 간결한 문서를 만들려고 했다. 기존의 다른 운영매뉴얼과 달리 핵심만 뽑아서 문서를 만들었다. 제일 먼저 시스템의 목적을 간단하게 작성하고, 아키텍처를 그림과 함께 간단하게 설명했다. 그리고 API 목록을 작성하고 모니터링 지표를..
블로그에서 설명한 역할기반 접근제어 시스템을 테라폼 (Terraform) 으로 구현하였다. 접근 제어와 권한 관리를 코드로 처리할 수 있기 때문에 이력관리, 자동화, 보안정책 리뷰에 장점이 있다. 이 프로젝트의 이름은 패스포트 (Passport)이며 모던 어플리케이션을 위한 다중 AWS 계정의 역할기반 접근제어 프레임워크이다. 자세한 내용은 저장소(https://github.com/Young-ook/terraform-aws-passport)에서 확인할 수 있다.RBAC (Role-Based Access Control, 역할기반 접근제어)는 엔터프라이즈 (Enterprise)환경에서 각 개인이 시스템에 접근할 수 있는 권한을 역할 기준으로 통제하는 것이다. 간단한 예를 들면, 공항에서, 일반 직원과 관리책..
성능 검증(Performance Test) 방법 중 하나인 스트레스 검증(Stress Test)에 대한 이야기를 해보려고 한다. 시스템의 성능을 가늠하고 측정하는 방법에는 여러 가지가 있을 수 있지만, 대표적으로 많이 활용하는 3가지는 부하 검증(Load Test), 스트레스 검증(Stress Test), 내구성 검증(Endurance Test)이 있다. 클라우드 환경이 널리 퍼지면서 확장성 검증(Scalability Test)도 성능 검증의 범주에 포함되고 있다. 내 주변의 통계는 늘 틀린다는 것을 알고있지만, 실무에서 많은 소프트웨어 개발자들을 만나다보면 시간부족을 이유로 검증과정을 대충 넘기는 것을 자주 볼 수 있었고, 테스트에 대해 잘 모르는 개발자들도 의외로 많았다. 성능 검증과 성능 분석을 혼..