대용량 웹 분산 시스템을 위한 운영을 고려한 설계한 내용을 담은 Release의 모든 것을 읽어 보았다.

최근 대용량 웹 분산 시스템은 여러가지 이슈를 거치며 마이크로서비스 아키텍처의 시기를 거치고 있다고 한다.

아무래도 디커플링의 효과가 가장 큰게 아닌가 싶다.

기능 개발 완료는 1차적으로 서비스를 시작할 준비가 되었다는 것을 의미한다. 즉 아직 완성 단계는 아닌것이다. 많은 테스트와 실 운영상의 이슈를 해결하며 시스템을 안정화 시켜야 하는 단계로 생각이 든다. 이 과정에서 가장 최악의 경우는 실 서비스가 어렵다고 판단될 수 있고 그런 경우를 거치지 않기 위해서 대용량 서비스 아키텍처에 대한 지식을 미리 습득하는 것이 어느정도 중요하다 생각이 든다.

실 서비스 시, 서버가 크래시되며 남은 덤프와 로그를 통해 왜 크래시가 났는지 당시 어떤 상황인지를 유추할 수 있다. 위의 경우는 try, finally만 사용했고 예외 상황에서 메모리 누수와 데이터 증가가 빠르게 일어난 상황으로 보인다. 이런 장애 상황에 대한 여러가지 시나리오를 분류해서 소개하고 있다.

중앙 시스템 구조를 모노리스라고 부르는 것으로 보인다. 보통 일정 범위 안의 유저 풀 만이 보장된다면 모노리스 방식은 괜찮은 선택이 될 수도 있을 것이다. 거미줄 패턴은 부하 분산이 이루어 지겠지만 디버깅과 각종 장애 상황의 견고한 구현에 어려움을 겪을 수 있을 것으로 생각된다. 아마 마이크로서비스 아키텍처는 거미줄 패턴에 더 가까울 것으로 생각된다.

대용량 서비스를 구성할 땐, 일어날 것이라 생각되는 소프트웨어 로직 장애 뿐만 아니라 하드웨어와 맞물린 이슈들도 예상하여 작업해야 하는 것으로 보인다. 나열된 서비스들이 상호간에 통신을 하며 계산을 하고 최종적으로 클라이언트에게 적절한 응답을 제공해 줘야하기 때문이다. 이 책에서는 하드웨어 이슈로 인한 대용량 분산 서비스 장애 상황 시나리오와 예방, 극복 예에 대해서도 다루고 있다.

이 글은 해당 출판사로 부터 책을 증정받아 작성되었습니다.

  조금 더 체계적인 소프트웨어 관리를 위해 이 책을 선택했다. 모든 S/W는 현장에서 다시 시작된다. 일반적인 IT 관련 프로그래밍이 아닌 24시간 가동되는 공장에서 작업을 실시하는 자동화 장비를 제작하는 나에게는 S/W는 멋스러움이 아닌 보수적인 것이어야 한다. 그래서 이 책은 기대가 있었다. 결론부터 말하지만 꽤나 어려웠다.

  보통의 책은 만드는 것 자체에 관심을 두지만 현실은 운영일 시작하고부터다. 운영 고려 설계에 초점을 맞춘 이 책은 한빛미디어의 지원으로 읽어볼 수 있었다.

  응용 프로그램을 만드는 일은 복잡하지만 꽤나 즐거운 일이다. 새롭게 뭔가를 만들어내는 일은 즐거운 일이다. 하지만 이렇게 만들어진 프로그램이 고객의 손에 들어가는 순간 악몽이 시작된다. 고객은 개발자의 생각을 넘어선 행동을 마다하지 않는다. 예상하지 못한 행동뿐만 아니라 예상하지 못한 트래픽은 재앙으로 다가오기도 한다. 시간이 곧 돈인 현장에서의 대응은 피 말리는 일이다. 어떻게 하면 좋을까?

  메카닉을 직접 구동하는 나의 업무는 데이터를 처리하는 보통의 IT업무에 비하면 단조로운 편이다. 대신 굉장히 보수적인 접근이 필요하다. 잘못된 동작은 하드웨어의 파손으로 이어지기 때문이다. 하드웨어의 파손은 직접적인 손해가 된다. 그래서 나의 경우는 인터록이 중요하다. 물론 인터넷상에서 처리해야 하는 프로그램도 그 위험성은 존재한다. 은행업무와 같은 보안의 문제라든지 쇼핑몰 이벤트에서의 서버 다운 같은 일은 심각한 손해를 초래하기도 하기 때문이다.

  저자는 운영 환경을 고려한 설계에 대해 얘기한다. 안정성 패턴과 안티 패턴 및 운영 고려 설계와 배치 고려를 얘기한다. 아키텍처와 버전 관련 그리고 카오스 공학까지 두루 이야기보따리를 펼쳐 놓으니 나에게는 버거운 지식이 되어 버렸다. 현장에서 마주하는 문제들을 이야기로 풀어내어 관련 업종에 근무하는 사람들의 공감을 얻어낼 수 있겠지만 나에게는 여전히 생경하는 풍경이었다.

  하지만 프로그램을 안정적으로 설계해 내야 하는 관점은 동의할 수 있었고 여러 환경에 대한 이해도 할 수 있었다. 단순히 잘 설계된 프로그램보다 더 신경 써야 하는 부분이 있음도 동의할 수 있었다. 하나의 에러는 시스템 전반으로 전염되어 시스템을 통째로 마비시키기도 한다. 이에 대응하는 얘기들도 해 주었다.

  이쯤 하면 되겠지라는 생각으로 개발을 완료하곤 하지만 현장은 늘 생각 이상의 것들로 넘쳐 난다. 이 책은 그런 상황에 대한 얘기로 가득하다. 접점이 부족하여 모두를 공감하며 읽을 수 없었고 꽤나 어려운 개념들이 나를 덮쳐 읽어내기 힘들었지만 개발자들에게는 좋은 해결책을 제공해 줄 수 있을 것 같다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

『Release It! 릴리스 잇』은 마이클 나이가드 저자의 풍부한 경험과 전문 지식을 바탕으로 한 소프트웨어 엔지니어링의 베스트셀러입니다. 이 책은 아키텍트, 설계자, 개발자를 위한 필독서로, 소프트웨어를 문제 없이 빠르고 안정적으로 출시하는 방법에 중점을 두고 있습니다. 특히, 이 책은 현대의 소프트웨어 엔지니어링에서 점점 더 중요해지고 있는 데브옵스, 마이크로서비스, 클라우드 아키텍처를 포함한 대규모 웹 분산 시스템의 설계 및 운영 방법에 대해 깊이 있게 다룹니다.

​

책은 네 부분으로 나뉘며 각 부분은 다양한 주제들로 세분화되어 있습니다. 첫 번째 부분 '안정성 구축'은 실제 운영 환경에서의 안정성을 달성하는 방법에 초점을 맞추고 있습니다. 이 부분은 안정성 패턴과 안티 패턴, 시스템 안정화 방법 등을 다룹니다. 두 번째 부분 '운영 고려 설계'는 실제 운영 환경을 고려한 소프트웨어 설계 방법에 대해 설명합니다. 이는 실제 운영 상황에서 마주칠 수 있는 다양한 문제들을 예측하고, 이에 대한 해결책을 제공합니다.

세 번째 부분 '시스템 전달'에서는 배치 고려 설계에 대해 다루며, 소프트웨어가 실제 운영 환경에 효과적으로 전달되기 위한 전략들을 제공합니다. 마지막 부분인 '체계적 문제 해결'에서는 복잡한 시스템에서 발생할 수 있는 다양한 문제들을 체계적으로 해결하는 방법에 대해 다룹니다. 특히, 이 부분에서는 카오스 공학과 같은 현대적인 접근 방법에 대해서도 탐구합니다.

​

저자 마이클 나이가드는 미국 정부와 은행, 금융, 농업, 소매 업계를 위한 시스템을 설계하고 구축한 경험을 가진 전문 프로그래머이자 건축가입니다. 그의 경험과 통찰력이 이 책에 잘 녹아 있어, 실무에서 직면할 수 있는 다양한 문제와 도전에 대해 현실적인 조언과 해결책을 제공합니다. 역자 박성철은 컴퓨터와 소프트웨어 개발 분야에서 40년 이상의 경험을 가진 전문가로, 실무적인 관점에서 이 책을 한국어 독자들에게 소개하고 있습니다.

​

이 책은 여러 실무자와 전문가들의 추천을 받으며, 소프트웨어 개발과 운영의 전반적인 과정에서 발생할 수 있는 문제들을 예측하고 해결하는 데 귀중한 지침을 제공합니다. 클라우드 환경과 시스템 아키텍처, 카오스 공학에 이르기까지 최신 기술 동향을 반영한 이 책은, 소프트웨어 엔지니어링 분야에서 자신의 능력을 한 단계 향상시키고자 하는 모든 이들에게 유용한 자료가 될 것입니다.

장애 경험을 생생하게 느낄 수 있었습니다.

피부로 직접 겪었던 장애를 독자에게도 피부로 전달해줍니다.

다양한 장애 경험을 배울 수 있었습니다.

장애 경험으로 엔지니어로써 중요한 교훈을 얻을 수 있는 책입니다.

과거에 직접 엔지니어가 서버실에 근무하고 원격으로 터미널에 접속해 배포하는 시대는 말만 들어봤습니다.

개인 PC 한 대에서 서버를 가동하고 공유기 설정에서 포트 포워딩으로 서버 포트를 열어 줘 외부 IP 로 접속하는 경험만 있는데요.

대규모로 한 데이터 센터에 여러 서버실에 수 많은 서버들이 있고, 또 다른 데이터 센터에도 배포를 해야 했던 시대는 어땠을지 궁금하네요.

작중 초반부에 항공사 키오스크 서버의 장애를 예를 들었습니다.

조금 전에 언급한 클라우드가 없었던 시절의 이야기였는데요.

예전에는 장애를 어떻게 해결하고 사후 관리를 어떻게 하는지 생생하게 엿 볼 수 있던 장면이었습니다.

단순한 패킷 캡처부터 자바 애플리케이션의 스레드 덤프로 장애를 해결하는 과정도 소개합니다.

항공사와 관련한 몇 시간 동안의 장애는 결국 막대한 비즈니스 손해와 뉴스에까지 나오게 됩니다.

기업 입장에서 어마무시한 파급력을 지닌 이 장애는 결국 어떤 문제였을 지 감이 잡히실까요?

놀랍게도 사소한 자바의 예외처리 였습니다.

그것도 시중의 자바 입문서에도 적혀있는 코드인데요.

대부분의 사람들이 봐도 문제를 알아채리기 힘든 결함이 있는 코드입니다.

		public List lookupByCit(...) throws SQLException, RemoteException {	Connection conn = null;    Statement stmt = null;    try {    	conn = connectionPool.getConnection();        stmt = conn.createStatement();        // 조회 로직 수행        // 결과 리스트 반환    } finally {    	if (stmt != null) {        	stmt.close();        }        if (conn != null) {        	conn.close();        }    }}

평범한 try ... finally 블록을 사용해 자원을 정리하는 의도가 담겨있습니다.

문제가 있는 코드 라인이 보이시나요?

바로 java.sql.Statement.close() 메소드 입니다.

해당 메소드가 SQLException 을 던질 수 있습니다.

대부분 일어나지 않지만, 오라클 드라이버는 연결을 닫으려는 IOException 을 만날 때 작동합니다.

작중에선 데이터베이스 서버를 중간에 다른 대체 서버로 교체하는 작업을 진행했습니다.

이전에 연결된 데이터베이스가 더이상 연결되지 않으므로 소켓에 데이터를 쓰면 IOException 이 발생하는데요.

그러나 놀랍게도 JDBC 연결은 여전히 Statement 객체를 만듭니다.

JDBC Connection 객체에서 Statement 를 생성하는 메소드에선 내부 상태만 확인한다고 합니다.

Statement 를 싱행하면 네트워크 입출력 작업에서 SQLException 이 발생하고, Statement 를 닫을 때도 데이터베이스 서버에 관련된 자원을 해제하도록 요청할 때 SQLException 이 발생합니다.

우리가 흔히 사용하는 표준 API 나, 라이브러리 또한 언제 어디서 결함이 발생할 지도 모른다.

위와 같이 라이브러리를 더욱 더 견고하게 만들었다면 장애가 발생하지 않았을지도 모르지만,

메소드 하나 하나 어떤 예외를 발생시키는지 사용자가 꼼꼼하게 확인하고 이를 적절한 예외 처리를 해야한다는 교훈을 얻었습니다.

Statement 를 닫을 때 예외가 발생하면 연결이 닫히지 않아 자원 누수가 발생하고 자원 풀은 고갈되며 이후 요청의 connectionPool.getConnection() 호출은 모두 블록됩니다.

처리되지 않은 하나의 SQLException 예외로 회사는 이미지 타격을 입었고 억 단위의 손실을 입었습니다.

고객에게 가치를 제공하는 서비스를 운영하고 유지보수 하다보면 이런 일이 비일비재하긴 합니다.

정말 사소한 실수 하나가 장애를 유발하게 되는데요.

라이브러리 버전업을 했을 때 이전과는 다른 동작으로 호환이 되지 않아 외부 서비스 통신에 장애가 생겨 서비스가 마비가 되기도 했습니다.

소규모로 서버를 운영하거나 언어를 배울 때는 몰랐지만, 많은 트래픽을 운영할 때 장애를 경험하고 나면

코드 한 줄, 한 줄을 작성하는 것도 굉장히 의식적으로 신경을 쓰게 되더라고요.

도서에서 이러한 장애 경험을 풍부하고, 또 생생하게 볼 수 있습니다.

선임 개발자들은 어떻게 해결을 했는지, 만약 내가 담당자라면 어떻게 장애를 분석하고 처리할지 고민해보는 맛이 있었습니다.

장애라는 주제는 소프트웨어 엔지니어라면 누구나 흥미있는 주제라고 생각을 합니다.

운영 체제단에서 네트워크 연결이 어떻게 동작하는지 등등 교과서에서만 봤던 CS 지식들을 실무에 맞게 설명한 것도 인상적이었어요.

개념을 설명할 때 삽화와 예시를 많이 들어 서술하는데요. 그래서 이론적인 내용들이 전혀 지루하지 않았었어요.

실제로 일어났던 경험담과 예전 기업에서 장애를 처리했던 경험담으로 지루할 틈이 없었습니다.

앞으로 소프트웨어 엔지니어로써 어떤 점을 고려해야 하는지 배울 수 있었고, 장애를 어떻게 대해야 하는지 교과서보다 더욱 교과서적으로 배울 수 있었습니다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

 IT를 근간으로 하는 제품과 서비스는 출시되고 나서 끝이 아니라 비로소 시작이라고 할 수 있다. 출시 이후에 발생하는 예측 불가한 상황과 다양한 변수, 그리고 이벤트는 비즈니스 영속성을 위협하는 문제를 야기할 수 있을 정도로 커다란 파급을 내재할 수 있기 때문이다. 그렇기 때문에 IT 제품이 출시되는 라이프 사이클 전반의 모든 과정에서 심혈을 기울이지 않는다면 작은 문제 하나가 장애로 비화하고, 이는 곧 기업의 존립 자체를 흔들어 놓을 수 있는 나비효과를 불러일으킬 수 있다.

'Release의 모든 것'은 IT를 기반으로하는 소프트웨어 또는 이를 둘러싼 인프라를 망라한 시스템의 강건성을 주제로한 서적이다. 이 책에서 언급되고 있는 시스템과 관련된 다양한 안티 패턴, 실패 사례 등은 현실에서 실제 발생한 여럿 상황을 반영하고 있다. 그리고 본 서적은 어떻게 하면 신뢰할 수 있고 안정적이며 강건한 시스템을 설계할 수 있는지에 대해 심층적으로 해부하며 실질적인 팁과 노하우를 제공하고 있다. 

지루하게 이론만 구구절절 나열하는 방식이 아니라, 다양한 유형의 사례와 상황을 저자의 풍부한 경험과 인사이트로 유려하게 그려내고 있다는 사실 자체로 이 책에서 배울 수 있는 게 굉장히 많다. 시스템 엔지니어, 소프트웨어 엔지니어, 아키텍트 등 시스템 설계와 직간접적으로 연관성이 있거나 해당 업무를 수행해야 한다면, 반드시 이 책을 필독 대상으로 삼아 일독하길 권고한다. 

시스템 설계는 아무나 할 수 있지만, 강건한 시스템 설계는 결코 누구나 할 수 없으리라. 어떤 환경에서도 어느 여건에서도, 모종의 상황에서도 안정적이고 실뢰할 수 있고 견고한 시스템을 만들고자 하는 이들은, 꼭 이책과 함께하여 소기의 목적을 달성하길 바라 마지않는다. 

P.S 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

실제 웹 서비스를 운영하면서 생기는 다양한 이슈들이 총망라된 책이다. 문제 발생 시 대응할 수 있는 방법은 물론이고, 대규모 아키텍쳐를 설계하는 데 있어서 고려해야 할 많은 사항을 전달해준다. 비즈니스적인 내용부터 스레드 덤프나 네트워크 프로토콜 같은 깊은 내용까지 다루고 있어서, 제목 그대로 Release의 모든 것을 알려준다.

아키텍쳐 설계나 분산 시스템 같은 어려운 내용을 다루기 때문에 읽기 어려울 거라 생각했지만, 실사례를 기반으로 한 유쾌한 문체로 상황을 덤덤하게 풀어나간다. 실제 사례가 기반이라 그런지 배포하고 있는 서비스가 있는 지금, 읽으면서 공감 가는 상황이 많았고 설계에 대한 생각이 한층 깊어진 것 같다. 

예시로 다루고 있는 시스템은 대부분 자바로 된 웹 시스템이지만, 이해하기 위한 코드 예시일 뿐이지 다양한 배포 환경에 적용할만한 상황을 다루고 있다. DevOps나 백엔드 어느 분야에 치우쳐있지 않고, 전반적인 웹 아키텍쳐에 대한 내용이기 때문에, 배포에 대해 막 공부하는 주니어 개발자보다는 시니어 개발자나 직접 서비스를 개발 및 배포하는 1인 개발자에게 적합한 내용인 것 같다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

이 책의 구성은 총 4부로 되어있으며 각 부는 사례 연구로 시작된다. 안정성 구축, 운영 고려 설계, 시스템 전달, 체계적 문제 해결같은 개발자에게 꼭 필요한 내용들로 구성되어있다. 각 부마다 지은이가 겪은 사례들을 소개하며 시작된다. 그래프나 다이어그램을 통해 설명하여 이해를 돕는다. 그리고 중간중간 요점정리를 통해 내용을 요약해서 설명해주고 있다. 이책을 다 읽지 못했다. 이해가 안가서 넘어가기 힘든 내용이 대부분이었고, 필자의 경험을 토대로 풀어낸 것은 좋으나 공감이 가지않아서 계속 읽기 어려웠다. 경험이 부족해서 그런것일 테지만 흥미진진하게 읽기는 어려웠다. 생각날 때 마다 몇번이고 다시 읽어야 할 책인거 같다.

릴리즈는 계획한 날짜에 개발만 다 됐다고 끝나지 않습니다.

내부적으로 테스트하고 그 과정이 통과되면 배포하게 되는 것이죠.

하지만 배포 후 운영하면서 프로그램에 관련된 데이터를 보면서 관찰하는 점이 중요합니다.

35년 경력의 대규모 시스템 경험이 풍부한 미국 개발자의 책이 나왔습니다.

그 책은 ‘Release의 모든 것’입니다.

◇ 새벽 5시만 되면 서버가 정지

저자가 운영한 웹사이트가 새벽 5시만 되면 서버가 죽었습니다.

그 이유는 사용자가 많이 접속 한 점도 있지만 방화벽 문제도 있었습니다.

저자는 애플리케이션 서버의 스레드 덤프를 뜨고 패킷도 덤프를 떴습니다.

그래서 방화벽에 문제가 있는 것을 확인하였고 그 문제를 해결하게 됐습니다.

해결하지 못할 때에는 서버를 끄면 일시적으로 잘 됐지만 매번 그렇게 하게 되면 사용자들에게 민폐이기 때문에 근본 원인 찾아 해결한 것입니다.

◇ 사람의 실수가 아닌 시스템의 장애 

회사에서 일을 하다 보면 실수는 하기 마련입니다.

하지만 그 책을 누군가 지는 게 문제이죠.

개발 회사의 경우에는 실수를 제발 하지 않기 위해서 회고도 하고 같이 공유하는 문화가 있습니다.

이때 잘못한 사람을 추궁하거나 조리돌림을 하지 않습니다.

왜냐하면 실수도 경험이기 때문이죠.

하지만 개발자의 힘이 작은 조직은 책임은 개발자가 져서 퇴사하거나 보직이 변경되는 경우도 본 적 있습니다.

이 책은 아마존에 대한 사례가 자세히 적어져 있어서 시스템 장애에 대한 대처 방법이 잘 적어져 있습니다.

Ps

국내의 정부 프로젝트는 실질적으로 기술 중심 기업에 비해 부족하다는 생각이 많이 듭니다.

SI 식으로 찍어내는 식으로 업체에 맡기는 점 때문이죠.

하지만 이 책의 저자는 미국에서 정부 프로젝트 경험이 많으며 국내와 다르게 사용자가 훨씬 많아서 대규모 웹 분산의 경험이 책을 보면서 많이 느꼈습니다.

이 책은 토이 프로젝트로 심플하게 만든 프로젝트를 전반적으로 운영해 보기 전에 이 책을 통해서 전체 감을 잡을 수 있어서 주니어 개발자나 시니어들도 궁금한 사례들을 경험을 찾아보는 것을 추천해 드립니다.

개발을 하면서 서비스 운영을 위해 아키텍처를 어떻게 효율적으로 설계해야할지 고민이 있어 읽어보게된 책이다.

구성은

- 안정성 구축

- 운영 고려 설계

- 시스템 전달

- 체계적 문제해결

로 되어있다.

정말 세세하게 설명이 되어있고, 그림으로도 설명이 되는 부분들이 있어서 이해하기는 편했다.

이 책은 신입 개발자에겐 많이 어렵다.

CS 지식이 있어야하고 출시를 하기위해 좀 더 깊은 지식이 필요한 사람들에게 추천한다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

“Release의 모든 것”은 다음 책의 번역서로 한국어서는 2판으로 한빛미디어에서 출판되었다.

Release It! Second Edition: Design and Deploy Production-Ready Software by Michael Nygard

이 책은 개발자들이 프로덕션 환경에서 소프트웨어를 디자인하고 배포할 때 마주치는 다양한 문제들을 직관적이고 현실적으로 다루고 있다. 저자가 이야기하는 건 이론적인 얘기가 아니라, 실제 현장에서 겪은 경험을 토대로 한 거라서 경험 많은 사수에게 듣는 꿀팁같은 느낌이다.

뭔가 한 문장으로 표현하자면, “빨리 배우고, 빨리 고쳐라” 라는 말이 떠오르게 하는 책이다. 새로운 기술 도입부터, 배포 전략, 장애 대응, 로깅, 모니터링까지, 이런걸 다루면서 ‘왜 나는 이런 삽질을 했지?’ 라는 경험을 공감하며 읽었다.

이게 뭐 대충 이런 책일 줄 알았는데, 읽다보니까 나의 코드가 얼마나 부실한지를 깨닫게 되더라. 그동안 살면서 나만의 ‘나름대로 규칙’이라고 생각했던 게, 이 책에서는 ‘왜 그렇게 하는 게 좋은지’를 이해시켜주면서 책임감을 심어줬다.

책 내용은 가볍게 볼 수 없는 테크니컬한 내용이 많아서 초급자에게는 조금 어려울 수도 있다. 그래도 실무에서 경험하고 나서 읽으면 더 와닿을 것 같다. 특히, 장애 대응에 관한 부분이 인상적이었다.

대규모 웹 분산 시스템을 설계, 배포 및 운영하는 데 필요한 실질적인 지침과 전략을 제공하고 있다. 이 책은 실제 운영 환경에서 마주치는 문제들과 그에 대한 해결책을 다루며, 고가용성, 견고함, 복원력 있는 시스템을 만드는 방법에 중점을 두고있다. 대규모 웹 분산 시스템의 배포 및 운영에 깊이 관여하는 아키텍트, 시스템 엔지니어, 개발자, 운영 팀에게 유용한 지침을 제시한다. 실제 사례를 바탕으로 한 깊이 있는 통찰력을 통해, 이들은 시스템 설계 및 운영의 다양한 측면에서 나타날 수 있는 문제들을 예측하고 대비할 수 있게 도움을 주는 내용으로 구성되어 있다.

공감할 만한 서비스 장애 이슈

서비스를 운영해 본 개발자라면 다음과 같은 상황을 마주한 적이 있을 것이고 아래 상황들로 장애를 겪고 해결하는 과정을 겪었을 것이다.

• 세션 수가 매우 높음
• 높은 네트워크 대역폭 사용량
• 긴 애플리케이션 서버 페이지 지연 시간(응답 시간)
• 낮은 CPU 사용량 (웹, 애플리케이션, 데이터베이스)
• 검색 서버는 정상적으로 응답
• 요청 처리 스레드 대부분이 바쁘고, 일부는 3분 이상 요청 처리 중

응답 지연 문제

응답 지연이 연계 장애를 유발한다는 점은 서비스를 운영해 본 개발자라면 공감할만한 주제다. 한 시스템에서의 지연이 전방의 시스템에 영향을 주고, 결국 전체적인 성능에 큰 영향을 미칠 수 있다. 이렇게 되면 안정성 문제가 일어나기 쉬워지고, 사용자 경험 또한 떨어지게 된다. 그래서 웹 사이트의 경우 응답 지연이 더 많은 트래픽을 발생시길 수도 있다. 사용자가 페이지를 기다리면서 반복해서 새로고침 버튼을 누르면서 더 많은 트래픽이 몰리면, 이미 과부하된 시스템에 더 큰 부담을 주게 되어 또 다른 문제의 원인이 된다. 응답 지연은 연쇄적으로 심각한 문제를 일으킨다는 것이다. 응답 지연은 시스템의 취약성을 초래하고, 특히 웹 사이트에서는 트래픽 폭증을 야기한다. 사용자가 기다림에 지쳐서 반복적으로 새로 고침을 시도하면서 시스템에 더 큰 부하를 주게된다. 응답 지연이 전체 시스템에 어떤 영향을 미치는지, 그리고 사용자가 어떻게 느끼는지를 생각하면서 설계를 해야한다.

책에서 강조한 빠른 실패 개념도 실용적이다. 시스템이 복구할 수 없는 상태에 이르기 전에 빠르게 오류를 반환하여 장애의 확산을 막는 것이 현명한 판단이라고 생각한다. 이렇게 하면 초기에 문제를 파악하고 대응할 수 있기 때문에 시스템의 안정성을 크게 향상시킬 수 있다. 시스템이 응답성을 모니터링하고, 평균 응답 시간이 허용치를 초과할 때 즉시 오류 응답을 고려하는 것은 안정성을 유지하는 전략이다.

메모리 누수나 자원 경합

메모리 누수나 자원 경합 문제는 성능 저하의 주범이다. 이런 문제를 해결하기 위해서는 효율적인 자원 관리와 코드 최적화가 필수적이다. 그리고 네트워크 프로토콜의 최적화는 네트워크 지연을 줄이는 데에 큰 도움이 된다는 것을 느꼈다. 메모리 누수와 자원 경합을 찾아내는 것도 서비스 운영에 중요한 이슈다. 부족한 데이터베이스 연결이 응답을 느리게 만들고, 메모리 누수는 가비지 컬렉터의 과도한 작업을 유발해 전체 시스템의 성능을 떨어뜨린다. 이런 문제들을 해결하지 않으면 응답 지연은 점점 악화되어 불쾌한 사용자 경험을 낳을 수 있다. 지속적인 모니터링과 성능 테스트를 통해 잠재적인 문제를 사전에 예방하고, 현실적인 부하 테스트를 통해 시스템의 한계를 파악하여 대비책을 마련하는 것이 필요하다. 이러한 대처 방안들은 상황에 따라 달라질 수 있으며, 복합적인 문제의 경우 여러 접근 방식을 동시에 적용할 필요가 있다. 지속적인 모니터링, 로그 분석, 성능 튜닝 등을 통해 문제의 근본 원인을 찾아내고 해결할 필요가 있다.

MSA

요즘은 IT 세계에서 ‘마이크로서비스’라는 용어가 핫하다. 이 책은 마이크로서비스 아키텍처에 대한 조언과 함께 현실적인 문제들을 다루고 있다. 개발의 측면뿐만 아니라 조직적인 측면에서도 마이크로서비스의 도입과 확장에 대한 고려 사항을 짚어주는 것이 특징이다. 마이크로서비스는 큰 시스템에서 발생할 수 있는 다양한 문제에 대한 기술적인 대안으로 소개된다. 특히, 조직이 성장함에 따라 소통 경로와 의존 관계의 복잡성이 증가하는데, 마이크로서비스가 이런 문제를 해결할 수 있다는 점이 강조된다. 책에서는 클래스와 의존 관계의 수가 폭발적으로 증가하는 문제를 설명하며, 마이크로서비스가 이를 해결하기 위한 좋은 대안이라고 주장한다. 특히, 서비스의 크기를 작게 유지하여 개발자 한 명의 머리에 담을 수 있을 정도로 작게 유지해야 한다는 주장이 독특하게 다가왔다. 이런 접근은 소프트웨어의 유지보수성과 변화에 대한 대응 능력을 향상시킬 것으로 기대된다. 하지만 마이크로서비스도 단점이 없는 것은 아니다. 특히, 조직 규모를 줄이는 상황에서는 마이크로서비스가 주인을 잃고 고아가 되기 쉽다는 문제가 제기된다. 서비스의 규모와 업무 부하를 관리하는 것이 중요하며, 단순히 마이크로서비스를 도입한다고 해서 모든 문제가 해결되지는 않는다는 경고가 담겨 있다. 책은 이론적인 부분뿐만 아니라 실제 경험과 사례를 통해 내용을 전달하고 있다. 새로운 기술 도입에 대한 견고한 판단이 필요할 때 조언을 구할 수 있는 책이지 않을까 싶다.

인사이트 가득한 선배에게 배우는 느낌의 책

이 책은 서비스 운영중 발생할 수 있는 문제를 실제적으로 경험한 개발자라면 공감이 가는 내용으로 가득 차 있었다. 개발 현장에서 이런 상황을 마주하면 신경쓰고 대응해야겠다는 지침을 제시해 준다.

이 리뷰는 한빛미디어의 나는 리뷰어다 이벤트를 통해 책을 제공받아 작성했습니다.

이번에 한빛미디어에서 책을 제공받아 'release의 모든 것' 리뷰를 하게 되었다. 스타트업을 개인 시간에 준비하면서 아무리 좋은 서비스를 만들었다고 해서 이를 유지보수하고 돌발 상황에 대비하는 연습을 미리 해볼 수는 없다. 그래서 배포 이후에 발생되는 일들을 미리 공부하고 싶었는데 좋은 기회가 생겼다. 개발과 운영은 아예 다른 카테고리에 있다고 생각한다. 서비스의 본질을 만드는 것과 많은 이용자들의 피드백 또는 서비스를 정상적으로 운영하는 것을 한 사람이 둘 다 해보이는 경우를 찾아 보기 힘들기 때문이다.

책에서는 안정성 구축, 운영 고려 설계, 시스템 전달, 체계적 문제 해결 파트로 나뉘어져 있다. 시스템의 작동을 유지하면서 멈추지 않게 할 필수 조건인 안정성과 제어/투명성/가용성에 좋은 서비스 시스템 운영 환경 패턴, 배치를 고려한 설계와 무중단 배치 그리고 이질적인 서버 간의 버전 관리, 깨지지 않는 시스템을 구축하는 방법을 배울 수 있게 된다.

책 중에서 가장 재미있었던 파트는 오전 5시 문제이다. 필자가 만든 서비스의 점검 시간이 오전 5시인데 이 시간에 30여개의 인스턴스가 모두 중단되면서 점검 후 재시작된다. 문제는 오전 5시가 방문자 수가 늘어나기 시작하는 시간이라는 것이다. 이 때문에 트래픽이 증가하면서 어플리케이션 서버의 연결들이 즉시 잠김 상태가 되는 문제를 찾고 해결해나가는 과정이 적혀있다. 여기서 필자는 문제를 추상화하여 찾아내었지만 문제 해결을 추상화 수준이 아니라 더 파고들어가 해결해야했다는 점이 인상깊었다.

백엔드 현업에서 주로 발생되는 상황을 다루다 보니 종사자가 아닌 이상 한번에 모든 것을 이해하기는 힘들었다. 백엔드 종사자가 아니라면 굳이 책의 모든 지식을 알려고 하지 말고 이런 상황에서는 어떤 것을 점검하고 어떤 해결 방법을 써야겠다는 생각을 정리만 해둔다면 충분한 공부가 될 것이다. 곳곳에 파트와 관련된 이야기가 있어 좀 더 상황에 몰입하여 생각해볼 수 있는 기회가 많아 좋은 부분이라고 생각한다.

소프트웨어 정상적인 작동을 위해 공부하고 연구하는 아키텍트, 설계자, 개발자분들에게 이 책을 추천한다. 한번 읽어둔다면 분명 책 속 내용과 유사한 상황에 재빠르게 대응하여 문제 해결할 수 있는 능력을 키울 수 있다고 생각된다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

매우 유명한 책입니다. 지금 소개드리는 책은 [2판] 입니다.

부제 : 대규모 웹 분산 시스템을 위한 운영 고려 설계

첫버전은 2007년에 나온 아래 "Release It 릴리스 잇 성공적인 출시를 위한 소프트웨어 설계와 배치" 아래 책입니다.

왼쪽에 출간된 책이 초판, 오른쪽이 이번에 출간된 2판의 표지입니다.

정말 오랜만에 다음 개정판이 나온것 같습니다. 

번역을 담당하신 분은 "박성철"님으로 여러 활동들을 통해서 다양한 SW개발에 긍정적인 선한 영향력을 제공해주시는 분이십니다.

세미나를 통해서 들었는지, 어떤 글에서 본것인지는 잘 기억이 나지 않지만, "이책이 너무 좋은 책이라서 바쁘신 와중에 시간을 쪼개어서 번역을 진행하셨다고 들었습니다." 그만큼 애정이 가고, 좋은 책이라는 애정이 느껴졌습니다.

■ 추천사만 보아도 느낌이 다른책

· 서비스를 3년이상 운영해봤다면, 이책의 내용에 공감을 할수 있습니다.

· 번역을 누구나 하고 싶었던 책

· 모든말을 제처두고, 반드시 이책을 읽어야 합니다.

· 필요할때 마다 다시 꺼내서 한번 더 읽으세요

· 소프트웨어 출시 전 검점목록 같은책

· 시니어 개발자로 도약하기 위해 반드시 알아야할 내용

· 현실에서 잘 동작하는 프로그램을 만드는 방법

· 해결할 문제가 무엇이고, 어떻게 그 문제를 해결할수 있는지

■ 책의 구성

· 책은 총 4부로 구성됩니다.

· 1부 : 안정성 구축

 - 시스템이 작동을 유지하면서, 멈추지 않게 할 방법

· 2부 : 운영 고려 설계

 - 1부 안정성 다음에 지속적으로 운영하기 위한 방법

· 3부 : 시스템 전달

 - 배치(deployment)를 뜻하는 의미로 1판과 동일하게 배포가 아닌 배치로 변역하셨습니다.

    고객에 피해를 주지 않고, 배치를 하는 것을 하는 방법

· 4부 : 쳬계적 문제 해결

 - 시간이 지남에 따라 성장하고 유연하게 적응하는 시스템을 만드는 방법

· 운영환경의 현실

내용중에 우리는 QA부서의 테스트를 통화하는 것을 목표로 삼는다.

이 글이 주는 울림이 많이 있었습니다.  실제 QA를 통해서 기능적인 결함을 잘 찾고, 품질을 높이는 것은 분명한 사실입니다.

하지만, 우리가 만드는 서비스에 대해서 목표에 대해서 다시한번 생각해보고, 어떠한 주안점을 가지는 방향이 맞는지 알게 됩니다.

· 4장에서는 "안정성 안티패턴"에 대해서 설명하고 이어서 5장에서는 안티를 제거한 "안정성 패턴"을 설명합니다.

시스템들이 통합의 구성으로 연결되는 구조에서는 데이터의 input의 출처가 다양화 될수 밖에 없다. 이러한 시점에 우리는 장애시 발생될수 있는 연쇄반응에 대해서 고려해야 한다.

사용자가 늘어난다는 것은 트래픽이 늘어난다는 것이고, 이것은 기존에 구성된 시스템의 처리능력이 해당 요청을 처리할수 있는지 명확히 판단할수 있어야 한다. 시간단 처리 최대량에 대해서 알고 있어야 한다는 점이다. 

자연스럽게 물리적인 내부 메모리를 이용하는 방식에서 외부 메모리 시스템(멤캐시드, 레디스)와 같은 데이터 구조 서버를 고려하게 되며

이것은 지나친 서비스 비용이 발생하는 부분은 아닌지 고려해야 되는 부분이다.

· 불쾌한 사용자, 해로운 사용자에 대한 부분은 우리가 어떠한 부분을 고려해야 하는지 안내되어 집니다.

글의 중간중간 현업에서 고민되거나 맹목적으로 좋다고 사용하는 것에 대해서 고려해야 하는 글들이 있습니다.

라이브러리, 자기부정 공격, 공유자원, 처리능력 불균형, 도그 파일, 응답지연등에 대해서 우리가 구성한 시스템에서 나타날수 있는 다양한 현상을 설명합니다.

· 5장에서는 " 안정성 패턴"으로 우리가 시스템, 서비스를 개발할때 주의 깊게 보아야 하는 부분입니다.

시간제한(응답시간에 대한 제한을 적용하라), 회로 차단기(문제가 있으면 호출을 멈추어라), 격벽(유용한 분할 수준을 선정해서, 서비스의 일부분이라도 유지될수 있는 구조를 만들어라), 정상 상태에 대한 데이터, 로그, 캐시에 대한 처리 기준, 빠른 실패(느린 응답에 대한 빠른 노티)

파손방지, 핸드셰이킹, 테스트 하네스, 결하분리 미들웨어 등등 서비스를 운영할때 모두 다를 고려할 필요는 없지만, 서비스 구성에 대한 정의를 내릴수 있고 필요한 부분은 부분적으로 도입을 하는 올바른 방향을 제시합니다.

■ 소스 코드, 실제 분석 내용을 통한 reference

· 실제 필자분의 경험하신 사례를 통해서, 발생한 이슈 및 그에 대한 대응책, 해결방안의 내용을 보면서 실제 사이트 담당자의 입장에서 관련 이슈를 같이 분석해보는 생각이 듭니다. 발생된 사이트 및 관련 이슈는 단순한 범위가 아니고 실제 많은 사용자들이 사용하는 서비스의 이슈에 대해서 설명되어 집니다.

· 코드적으로 분석이 필요한 부분은 코드를 예시로 구성됩니다.

· 이론적인 부분에 대한 설명도 예시를 들어 구성되어 있습니다.

· 개념, 구조가 필요한 부분에 대한 서비스흐름형태가 설명되어 집니다.

■ 운영 고려 설계

· 이 단어가 모두 좋은것 같습니다. 2부의 제목인데 우리는 실제적으로 운영환경에서 장애를 발생안하고, 안정적인 요구사항을 서비스 하기 위해서 고민하고, 개발을 합니다. 단순한 개발이 아니라, "운영을 고려한 설계"는 궁극적으로 우리가 나아가는 방향과 일치하는것 같습니다.

· 실제 일어난 사례를 통해서, 우리도 저자분과 함께 해당 사이트에서 일어나는 일을 경험해보고 우리는 어떠한 fact를 고려하고, 파악할수 있는지 상세하게 느낄수 있습니다.

· 운영고려설계의 개념은 "운영문제를 최우선고려사항"으로 생각한다는 뜻이다.

개발환경과 매우 다른 운영네트워크가 포함되고, 로그, 모니터링, 운영제어, 보안도 포함된다., 운영담당자의 입장의 설계도 포함된다.

7장 "기반" chapter에서는 우리가 아는 데이타센터 IDC와 클라우드도 포함되어서 설명됩니다. 1판에서는 클라우드에 대한 부분이 없었지만 2반에서는 클라우드 환경에서 대해서도 추가되어서 많이 사용하고 있는 AWS등의 서비스를 이용할때의 고려점도 언급되어 있습니다.

- 네트워크 인터페이스와 이름, 다중네트워크 프로그래밍, 물리 호스트, 가상머신, 컨테이너, 클라우드 내 가상머신, 클라우드 내 컨테이너에 대한 부분이 있는데, 우리 소속이 인프라를 담당하는 부서가 아니라고 한다고 해도, 장애의 최초 보고는 사용자 화면을 이용하는 접점인 개발부서로 처음 오기 때문에 대한 부분도 다른 부서의 영역이 아닌, 원인을 찾는 모든 부서의 영역이 된다고 생각합니다.

8장 "프로세스" 부분은 개발 인스턴스 입장에서 초첨을 맞추는데, 이러한 개발젹인 개발의 효과를 높이고, 구성을 어떻게 하고 로그 기록에 대한 위치, 수준에 대해서 고민하게 됩니다.

9장 "상호연결"을 통해서 인스턴스 들이 함께 연결되어 하나의 시시템이 되어야 하는데, 이러한 방법에 대한 해법을 살펴볼수 있습니다. 

DNS를 활용한 연결, 서버 부하 분산, 가용성등 다양한 관점으로 평소 잘 신경쓰지 않았던 부분을 볼수 있었습니다.

사용자가 많아지만 고민하게 되는 부하분산에 대해서, 소프트웨어, 하드웨어 방식으로 부하를 분산할때 사용되는 프록시 서버, 알고리즘등에 대해서, 하드웨어는 상용장비의 예시를 통해서 처리하는 방법등 생각의 폭을 넓혀줍니다.

10장에서는 "제어 평면" 이라고 되어 있어서 어색했는데, 각종 기능 및 서비스들을 올바른 위치에 놓고, 어느정도 일관된 젠체로 엮는 부분을 말합니다. 책에서 언급하는 점검 목록은 아래와 같은 사항입니다.

· 11장 보안 부분에서는 OWASP에서 나온 상위 10개의 개념에 대해서 설명합니다. 보안취약점 검사를 통해서 나온 결과에 대해서 의도를 파악하지 못하고 수정을 하지 말고, 실제 중요한 취약점 공격의 원리를 설명해주고 있어서, 이해가 쉽게 설명되어집니다. AWS클라우드 사용시에 활용하는 방법도 함께 포함되어 있습니다.

■ 시스템 전달

· 3부에서는 우리가 운영환경에서 필수적이 요소들로 구성되어 있습니다. 배치(배포), 버전관리에 대해서 다룹니다.

배치는 서비스를 운영환경에 올리는 과정이기 때문에 고려해야 할 사항이 매우 많고, 그 순서와 구성도 고려할게 많습니다

배치를 하면서 기존 캐시의 전략은?, 장애 발생시 롤백에 대한 계획은? 테이블 스키마가 기존에 있는경우, 없는 경우등에 대해서 고려 하다보면 그 난이도는 매우 높아집니다. 또한 이러한 부분은 언어적인 제약이 있는 부분도 있기 때문에 책을 통해서 좋은 방향성 및 지금 배포시스템에 도입이 필요하거나, 주의해서 추가해야 하는 부분을 파악해볼수 있습니다.

버전관리에 대해서는 git, svn같은 형상관리의 버전을 의미하는 것이 아닌, API의 버전과 같은 버전에 대해서 설명합니다.

■ 체계적 문제 해결

· 4부에서는 평소 업무에 한번은 경험해보았을만한 다양한 사례연구 및 Agent가 제시됩니다. 

최정점검과 출시, QA지향, 부하테스트, 테스트 간극 등등 저도 평소에 고민하던 부분이라서 현실감있게 다가왔습니다.

· 절차와 조직, 팀의 규모, 서비스의 종료, 시스템 아키텍처에 대한 진화적구성, 마이크로서비스에 대한 조언등 선택과 갈등에 대한 부분은 결국 서비스를 잘 릴리즈 하고, 자원은 안정적으로 효율적으로 사용하기 위한 하나의 큰 소프트웨어 라이프사이클에 대해서 느끼게 해주고

카오스 공학적인 내용을 통해서, 앞으로 새로운 분야도 소개됩니다.

좋은 책이라는 의미가 많이 와닿은 책이였습니다.

이 책을 보고 느끼는 바가 모두 다를거 같습니다.

아는 만큼 보이고 한줄의 문장이 더 많은 고민을 하게 된다면

조금 더 나은 Release를 하고 있는 개발자, 엔지니어 분들이라고 생각되어 집니다.

스터디를 해도 좋고, 우선 필요한 부분에 대해서 부분 학습을 해도 좋은 책이라고 생각되어 집니다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

제목이 다소 오만해 보이지만 내용만은 아주 알찬 번역서가 한빛미디어에서 출간되었습니다. 바로 Release의 모든 것 입니다. 책이 세상에 나오기 전에 제목을 추천받기도 했던 것 같은데요. 책을 덮고 나서도 이것 이상의 제목은 떠오르지 않네요.

책에는 아주 많은 내용이 담겨있습니다. 4장 안정성 안티 패턴과 5장 안정성 패턴은 특히 여러 책에 걸쳐 소개되고 있는 내용들이 많습니다. 소프트웨어 아키텍처 101과 같은 책을 본 적이 있다면 아마도 한 번쯤은 접해본 적이 있을 내용일 겁니다. 여기서 다시 정리하는 느낌으로 읽으니 좋았습니다. 기승전결처럼 모든 장이 연결되는 것이 아니라서 책장에 꽂아두고 장을 넘기며 그때그때 흥미가 당기는 부분을 읽어도 상관없습니다. 

결국 이런 버그 하나하나가 모두 제거되기를 기대하는 것은 환상일 뿐이다. 버그는 발생한다. 버그는 말살되기는커녕 반드시 살아남을 것이다. 이 지점에서 가장 심각한 문제는 한 시스템의 버그가 관련이 있는 다른 모든 시 스템으로 전파될 수 있다는 사실이다. 버그를 예방할 방법을 찾는 것보다 더 나은 질문은 '한 시스템의 버그가 다른 시스템에 영향을 미치지 않게 하는 방법은 무엇인가?'이다. 오늘날 모든 기업의 내부에는 상호 연결되고 상호 의존하는 그물망 같은 시스템들이 있다. 이런 환경에서 버그가 연쇄적으로 장애를 일으키도록 허용해서는 안 된다. 

이런 내용을 봐보세요. 모든 버그를 잡고 나서 혹은 모든 경우의 수를 테스트하고 나서 Release를 한다는 건 사실상 말이 안 됩니다. 버그는 발생할 수밖에 없다는 사실을 인정하되, 장애가 전파되지 않도록 막는 것을 최선으로 해야 합니다. 모놀리식 같은 경우에는 특히 더욱 그렇겠지요. 마이크로서비스로 가면서 장애가 전파되지 않도록 막는 여러 가지 수단이 있습니다. 이 책의 5장, 안정성 패턴에서 내용을 살펴보세요. 그렇다고 책에 언급되는 패턴을 많이 적용할수록 안정적인 시스템이 된다는 말은 아닙니다. 이건 책에서도 똑같이 이야기합니다.

이 패턴들을 더 많이 적용한 시스템이 우월하다고 가정하는 실수를 범하지 말자. '적용된 패턴 수'는 결코 좋은 품질 지표가 아니다. 대신 복구 지향(recovery oreoncd) 의식을 길러야 한다. 고장 난 레코드판처럼 보이겠지만 다시 반복하겠다. 장애는 반드시 일어난다고 생각하자! 그리고 이러한 패턴을 현명하게 적용하여 각 장애로 입는 피해를 최소화하자.

개인적으로 요즘 카오스 공학에 관심을 갖고 있었는데 이 부분도 잘 정리가 되어 있습니다. 카오스 공학을 떠올리면 넷플릭스의 카오스 몽키가 먼저 떠오르는 건 어쩔 수 없습니다. 과연 우리 시스템에도 카오스 테스트를 할 수 있을까? 한다면 넷플릭스의 정책을 확인해 보세요. 카오스 테스트를 하지 않기를 원한다면 승인을 받아야 합니다. 그리고 테스트하지 못하는 이유에 대해서 지속적으로 설명해야 할 겁니다. 나아가 그 문제를 해결해야 할 거고요. 

넷플릭스에서는 카오스 테스트를 선택적 탈퇴 방식으로 진행한다. 운영 환경의 모든 서비스는 카오스 멍키의 적용을 받게 된다는 뜻이다. 서비스 담당자는 적용받기를 거부할 수 있지만 승인이 필요하다. 탈퇴 절차는 단순한 요식 행위가 아니다. 면제되는 서비스는 카오스 멍키가 관리하는 데이터베이스에 등록된다. 예외 대상이 되면 낙인이 찍힌다. 기술 책임 경영진은 이 목록을 정기적으로 검토하고 서비스 담당자에게 카오스 멍키를 적용하지 못하는 문제를 해결하도록 권고한다.

좀 더 작은 회사로 넘어가면 슈퍼 개발자 같은 사람들이 존재하는데요. 이 사람들이 빠졌을 때 어떤 혼란이 야기되는지 훈련하는 방법도 있습니다. 좋은 환경이라면 이미 암묵적으로 다 대응이 가능하겠지만 그렇지 않은 곳이라면 분명 필요한 절차입니다. 사실 누구 하나 빠져도 어떻게든 회사는 돌아간다는 생각은 있습니다만, 그렇지 않은 곳도 분명히 있을 테니까요. 불특정 다수의 공백이 어떤 문제를 일으킬 수 있는지 인지하고 있다면 조직을 세팅하는데 분명 도움이 될 겁니다. 

이 훈련을 좀비 아포칼립스 시뮬레이션'이라고 칭해 더 재미있게 만들 수 있다. 구성원의 50%를 임의로 선정해서 좀비로 간주한다. 좀비로 지정된 사람이 다른 사람의 두뇌를 먹을 필요는 없지만 업무를 손에서 놓고 아무런 요청에도 응답하지 말아야 한다.

이렇게 재밌는 내용이 가득한 이 책의 유일한 단점이라면 난이도입니다. 서두에 언급되는 것처럼 이 책의 대상 독자는 "중급"입니다. 적어도 제가 느끼기에 이건 "최소"로 지정된 겁니다. 경험이 많은 아키텍트여야 그나마 책이 재밌게 읽힐 겁니다. 

예를 들어 서버에서 tcpdump로 패킷을 캡처 한 걸 꺼내서 와이어샤크(Wireshark)로 본다거나, 와이어샤크의 옛 이름은 이더리얼(Ethereal)이었다거나(아무도 관심 없겠죠 하하하). 그리고 고수준의 추상화된 코드가 아니라 저수준 소켓 프로그래밍을 본 적이 있어야 좀 더 쏙쏙 박히는 open(), read() 같은 것들. 소켓 연결 과정에서 연결이 끊겼을 때 벌어지는 일들. 하나씩 경험해 본 적이 있다면 분명 아주 재밌게 읽힐 겁니다. 그렇지 않다면 건성으로 넘기게 되는 페이지가 많아질 것 같습니다. 저는 리눅스 커널 위에서 개발을 시작해서 위와 같은 내용들을 어느 정도 경험한 적이 있는데요. 덕분에 오랜만에 추억 여행 하듯이 읽어 내려간 부분이 많았습니다. 특히 와이어샤크는 추억 속에 묻어뒀던 이름인데 10년 만에 만나니 반갑더라고요. 

각설하고 이 책은 쉬운 책은 아니지만, 앞서 언급한 것처럼 모든 페이지를 순서대로 읽을 필요가 없습니다. 어려운 내용은 넘어가고 잘 읽히는 장만 공략하는 것도 좋은 방법입니다. 그런 면에서 5장의 일부와 17장은 모든 개발자들에게 아주 재밌게 내용일 겁니다. 실제 운영서버에 우리 코드가 배포된 이후에 겪게 되는 문제와 그것들을 극복하기 위해 어떤 자세와 대응이 필요한지 궁금하시다면 이 책을 일독하시기를 바랍니다. 

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

모두에겐 장애를 겪기 전에 그럴사한 대책이 있다. 하지만 막상 장애를 겪고 나면 그 대비는 평소 모의 환경과는 사뭇 다름을 깨닫게 된다.

이 책은 실무 환경에서 겪을법한 장애 케이스를 엮어 그에 대한 방안과 강구책을 제시한 책이다.

솔직히 해당 책의 독자로는 학부생이 읽기에는 어려움이 많고, 어느 정도 경력이 있는 5년 차 이상의 개발자들이 해당 책을 학습하길 권장한다.

책의 사례들은 정말 주옥같고 가치 있는 것들이나, 실제로 해당 케이스에 대해서 경험하지 못하고 이를 낭독하거나 학습한다면, 이에 대한 학습 효과가 크게 나타나지 않을 가능성이 크다. (단적인 예로, 다른 사람의 경험이 나의 경험이 되기 어려운 것처럼. 어느 정도 장애 상황에 대해 대면한 경험이 있어야 확실히 책의 내용을 쉽게 기억할 수 있을 것이다.)

또한 규모가 큰 회사에서 근무하는 개발자들보단, 스타트업이나 중견 기업 규모의 회사에서 일하는 개발자들이 이 책을 읽는다면 얻어 가는 바가 클 것이란 생각이 든다. 대형 회사의 경우 내부적으로 장애 대응 프로세스와 이에 상응한 대응책들이 이미 매뉴얼로 구비되어 있는 경우가 태반이다. 그렇기에 같은 실수는 번복하여 발생하기 쉽지 않은 구조이다. (구글은 그해 장애가 크게 났던 경우들에 대해서 따로 문서화하고 이를 사내에 전파한다고 한다.)

【책의 구성】 "Release의 모든 것"의 구성은?

이 책은 크게 4개의 파트로 구성되어 있고 이를 세분하면 17개의 챕터로 구성되어 있다. 이번 리뷰는 1파트 '안정성 구축'에 초점을 두고 리뷰를 진행하였으므로 다른 3개의 파트 (1파트에서 살펴보았던 사례 케이스에 대한 강구책과 이를 보완할 수 있는 방안에 대한 내용)는 해당 책을 통해 직접 참고하시길 권장한다.

2 장 : 사례 연구, 항공사를 멈추게 한 예외

​

이 챕터에서는 어느 대형 항공사?의 장애가 발생하기까지의 과정과 그 원인은 무엇이었으며 이로 발생한 항공사의 피해 규모가 얼마나였는지 등의 세부 분석 과정을 상세히 정리했다.

본 서를 읽다 보면 저자가 이런 표현을 한다. (책과 동일하진 않음) 개발자들은 모든 독립적인 우연들이 겹쳐 장애가 발생한다고들 생각한다.. 하지만 모든 장애의 원인들은 서로 연관관계가 있고 따라서 이들은 독립적 사건의 우연의 충돌에 의해 발생하는 것이 아닌, 서로 연관된 사건들이 연쇄적으로 에러를 일으키며 야기되는 것이다.라는 표현이 있다. 정말 그렇다. IT 업계에 있다 보면 정말 엄청난 확률로 희귀한 장애?를 겪긴 하지만, 그 원인도 자세히 살펴보면 결국에는 서로 연관되어 있었고, 장애가 발생하기 전에 이미 전조 전상이 여럿 관찰된 상태일 가능성이 크기 때문이다.

그렇다. 우리가 겪는 장애, 우리가 설계한 시스템은 충분히 모든 장애 경우를 고려하지 않고 만들어졌다. 또한 그 모든 장애 경우를 절대로 고려할 수도 없다. 따라서 장애는 필연적인 것이며, 이를 사전에 원천 차단한다는 것은 말이 안 되는 이야기이다.

그러하면 우리는 어떻게 이에 대응해야 할까? 우리가 대응해야 하며 초점을 두어야 하는 것은 장애가 발생했을 경우, 최대한 피해를 감소시키는 방향으로 아키텍처를 구성하는 것에 있다.

4~5 장 : 안정성 안티 패턴, 안정성 패턴

4, 5 챕터에서는 안정성에 반하는 패턴과 안정성에 반하는 패턴을 극복할 패턴에 대해서 설명하고 있다. 솔직히 실무에서 10년 이상 경험해 본 사람이라면 다들 어느 정도 경험하고 전해 들었을 법한? 이야기들이 본서에 술 해져있다. 그만큼 대중적이며 흔한 장애들 중심으로 정리한 책이라 할 수 있으나, 저자의 표현이 너무나 재미난 게 많으므로 자세히 들여다보길 권장한다.

단적인 예로 안정성에 반하는 패턴은 연쇄 장애를 들 수 있다. 즉 A라는 컴포넌트가 장애가 발생하게 되면 이와 연계된 B, C 컴포넌트가 장애를 일으키고 급기야는 시스템 전체가 셧다운 되는 그런 장애를 연쇄 장애라고 한다.

이런 장애는 보통은 사소한 설정 혹은 설정 누락, 메모리 누수 따위의 정말 사소한 것들에 의해 쉽게 발생하는 경향이 있다. 따라서 프로젝트를 진행할 때, 이러한 부분에 있어서 실수가 없었는지 자세히 들여다 봐야한다.

그리고 5장인 안정성 패턴의 경우, 앞선 장에서 설명하였던 안티 패턴을 대응하는 방안에 관해 술한 챕터이다. 솔직히 중간중간 약어가 끼어있어서 온전히 이해하는 데에는 약간의 고생이 필요했지만 위의 내용들도 충분히 시간을 들여 살펴볼만한 가치가 있었다. 따라서 시간만 괜찬다면 느긋히 그리고 심도 있게 들여다보시길 권장한다. (이것을 아시는가? 사람은 쉽게 깨우치면 금방 잊어버린다고 한다. 고통이 동반된 학습일 경우, 쉽게 학습한 내용보다 훨신 장기간 기억이 보존된다고 하니, 어렵게 얻은 지식과 배움도 나름의 가치가 있다고 할 수 있겠다.)

이 장에서의 핵심 내용은 장애가 발생할 경우, 그 피해의 구간을 최소한의 부분에 한정해야 한다는 것이다. 가령 배에 누수가 발생하여 물이 차고 있다고 가정해 보자. 이런 경우, 배 내에 격벽이라는 장치가 작동하여 물이 차는 것을 최소화하기 위해 공간을 차단하기 시작한다. 이말인 즉슨, 여러분도 여러분이 구성하는 모든 코드를 이와 같이 커플링은 최소화되고 응집도는 최대화가 되는 그런 코드로 구성해야함을 의미한다.

【 Release의 모든 것을 읽고 나서 】

10수 년 전 최초로 서비스를 배포했던 기억이 난다. 처음이어서 많이 떨리기도 하였고 설레기도 하였지만, 무엇보다 장애가 발생할까 전전 긍긍했던 기억이 있다. 그만큼 그 시대에는 이런 장애에 대한 대처에 있어서 기본 커리큘럼이 많이 미흡했었다. 또한 이를 미연에 방지할 방지책에 대해서도 개발자들 사이에서 말로만 전해져 내려올 뿐, 뭔가 체계가 잡혀있진 않았던 거 같다. 아마 지금도 대다수의 스타트업에서 위와 동일한 현상을 겪고 있지 않을까 싶긴 하다.

따라서 Release에 앞서서 안정적인 서비스를 사용자들에게 제공하기 위해서는 사용자 관점에서의 카오스 테스트가 필요하다. 우리는 온실 안의 화초를 키워 사용자들에게 제공하려는 것이 아니다. 잡초같이 어느 상황에서나 정상적으로 동작하는 서비스를 우리의 사용자는 기대하고 있다. (벼락이 떨어져 서버실이 불이 나도 말이다.!!) 따라서 이러한 서비스를 제공하기 위해, 본인의 서비스를 충분히 망가트릴 수 있는 그런 관점에서의 테스트 능력이 필요하다.

#본 도서는 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

소프트웨어 개발을 처음 시작하는 사람들은 요구사항에 대한 정교한 설계 보다는 어떤 기술을 사용해서 어떻게 구현할 것인지에 대해 고민을 하게 되는데 운용을 포함한 입체적인 관점보다는 구현 자체에만 의미를 두는 경우가 많다. 여기서 정교한 설계는 어떤 시스템과 통합될 것인지 그리고 사용하게될 사용자수는 어떻게 되는지, 안정성을 위해 테스트 시나리오는 무엇일지 그리고 마지막으로 이 모든것을 포함하여 구현해야할 기능들에 대해 일정내 가능할지등 고민하는 것을 말한다.

문제는 실제 제품이나 서비스 운용 경험이 있어야 설계에 여러가지 고려사항들을 포함시킬 수 있다는 점이다. thread safe하지 않는 API를 사용해서 간헐적으로 프로세스가 죽는다던가 또는 책에서도 나오는 예시로 try-catch-finally에서 finally 구문에 close에서 다시 예외가 raise 될 수 있는 것을 고려하지 못해 socket 파일을 닫지 못하는 상황이 발생할 수 있다. 

"Release의 모든 것", 이 책은 제품 및 서비스(대부분 서비스 이야기이지만...) Release 이후의 일어날 수 있는 문제점 요소들에 대해 나열하고 서사 방식의 예시를 통해 몰입을 더한다. 책 표지만 봐서는 Release를 어떻게 해야하는지에 대한 좀 따분한 느낌이 들긴 했지만 말이다.
저자 마이클 나이가드는 미국 정보, 은행, 금융, 농업, 상거래등 시스템을 설계 구축하고 운용한 사람으로써, 이미 2007년에 1판 "Release it ! 성공적인 출시를 위한 소프트웨어 설계와 배치" 책을 다시 가다듬어서 2판으로 낸 것이다.

시니어 개발자라는 이야기를 하게 되면 꼭 대용량 트래픽이 빠지지 않는다. 그만큼 난이도가 있고 시스템적으로 난이도가 있고 컴퓨팅자원뿐 아니라 인정 자원등 고려할 사항이 많기 때문인데 이 책은 그에 대한 힌트 또한 얻을 수 있다. 물론 대용량 트래픽이 아니더라도 복잡한 시스템에 대해 어떻게 운용 관점에서 밤을 새지 않고 새벽에 끌려가지 않게끔 건강한 개발자 그리고 건강한 시스템을 만들어가게 되는 비법을 제공한다. 이 책의 큰 장점이다.

물론 단점 또한 존재하는데 많은 주제를 이야기하다보니 최소 CS(Computer Science) 지식과 서비스 개발 및 출시 경험이 조금이라도 있어야 몰입할 수 있다는 점이다. TCP/IP가 무엇인지 3 hand shaking 과정은 어떻게 되고 TIME_WAIT을 줄일 수 있는 설정은 어떻게 하는지등 자세한 내용은 서술하지 않는다. 당장 구현해야할 기능들을 해결하기 급급하다면 책의 절반 이상은 공감하기 힘들고 다른 세상 이야기로만 느껴질 수 있다. 그럼에도 불구하고 옆에 두고 패턴 부분이나 실제 사례 내용들을 차근차근 읽어보면 1~2년 뒤 개인의 성장과 담당 서비스가 성숙하는데 충분히 도움이 될 것이라 생각한다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

두껍지 않은 편이라, 금방 쉽게 후루룩 읽을 줄 알았는데.. 생각보다 실무 경험이 잘 녹아있고 나에게도 일어날 수 있는 일이다 라는 생각에 하나하나 생각하고, 나라면 어떻게 대처했을까? 생각해보면서 넘기다보니 읽는 속도가 엄청 느렸다. 회사 규모가 작아 FE이지만 서비스를 서버에 직접 올리고 오픈하는 경우도 있는데, 개발할 때부터 서비스 올리기 까지 어떤부분을 고려하면서 작업을 해야하는지 실제 사례를 보면서 깨닫게 되는 부분도 많았다. 또한 큰 규모의 서비스들을 예시로 드는경우가 많아 나중에 이직해서 큰 회사를 가면 나는 이런서비스를 겪을 수 있겠구나 라는 간접경험도 할 수 있어서 도움이 많이됐다. 데브옵스나 설계자가 아니더라도 포트폴리오를 위해 개인서비스를 운영하는, 운영할 예정인 사람들도 꼭 한번 씩 읽어보면 좋을 책이다. 

이 책은 작가가 대규모 웹 분산 시스템을 개발하고 운영하는 동안 마주했던 여러 문제들과 이를 해결했던 경험을 바탕으로, 운영을 고려하여 서비스 설계 시 고민해야할 여러 중요 사항들을 알려줍니다.

특히 작가가 경험한 각종 장애 스토리들을 읽어보면 절로 서비스를 개발할 때 "운영 >고려 설계"를 적용해야 겠다는 생각이 절로 들 정도로 무척 공감이 많이 되는 내용이었습니다. 

이 책은 크게 4부로 구성되어 있습니다.

1부: 안정성 구축

2부: 운영 고려 설계

3부: 시스템 전달

4부: 체계적 문제 해결

각 부에서는 내용의 핵심 내용을 설명하기에 앞서 먼저 작가 자신이 겪은 서비스 장애 및 해결한 이야기를 들려주고 이를 통해 핵심 내용들을 설명하는 구조로 되어 있어서, 핵심 내용들을 좀 더 절실하게(?) 받아들일 수 있어서 좋았습니다. (솔직히 이 책에 포함된 서비스 장애 사례들이 남의 일 같지가 않았습니다.)

이 책을 읽는다고 해서 완벽한 서비스를 만들고 운영할 수는 없습니다. 하지만 장애가 어떤 부분에서 많이 발생하고 이를 신속히 해결하기 위해서는 어떤 것들을 준비해야 하는지는 잘 설명되어 있습니다.

복잡한 코드도 없고 번역도 매끄럽게 되어 있어서 내용을 이해하는데도 큰 문제는 없>었습니다. 대규모 웹 분산 시스템을 개발하고 운영하시는 분들에게 많은 도움이 될 것으로 생각됩니다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

"Release it! 2nd edition"은 2018년에 출간된 실용적이고 현실적인 소프트웨어 개발 노하우를 제공하는 책입니다. 저자 마이클 나이가드는 전문 프로그래머이자 건축가로서, 자신의 35년 경험을 바탕으로 다양한 주제를 다룹니다. 이 책은 4부로 구성되어 있으며, 각 부는 서버의 높은 가용성, 운영 환경에서의 디자인 패턴, 대량 데이터 처리, 체계적 문제 해결 등에 초점을 맞춥니다. 특히, 실제 사례 연구를 통해 안티패턴과 오류를 상세하게 다루며, 보안과 관련된 내용도 포함되어 있습니다. 이 책은 전문 용어에 대한 정확한 번역과 세심한 설명으로 독자들에게 명확한 정보를 전달하며, 특히 용어 사용의 정확성과 재미있는 비유를 통해 개념을 쉽게 이해할 수 있도록 돕습니다. 이 책은 중급 개발자를 대상으로 하며, 각 장은 별도의 책으로 충분할 만큼 풍부한 내용을 담고 있습니다. "Devops Handbook"과 유사하지만 더 현대적인 접근을 제공하는 이 책은 최신 기술 동향에 대한 깊은 통찰을 제공합니다.

더 자세한 리뷰는 아래 링크에 작성하였습니다.

https://dev.sonim1.com/ko/blog/release-it-2nd-edition

 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

※ 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

​

책의 제목에서 유추할 수 있듯이 운영 환경에서의 접할 수 있는 여러 문제 상황들을 유연하게 대응하기 위한 설계 방법을 배워볼 수 있는 책이다.

개발과 테스트를 잘 마무리했다고 해서 운영 환경까지 문제가 없을 거라는 경우는 없을 것이다.

분명 테스트 과정에서 많은 케이스에 대한 검증과 결과를 완료하였다고 하더라도 오류들이 발생할 수 있다.

이런 상황들을 경험하게 되었을 때의 해결 방안에 대한 방안을 빠르게 모색해야 하는데, 이 책은 이런 상황에 대해서 포괄적인 방안을 제시해준다.

특히 테스트 과정에서의 우리가 고려해야 하는 여러 요소들을 예시로 설명해주기 때문에 좀 더 이해할 수 있도록 해준다.

​

이 책은 총 4가지 챕터로 구성되어 있다.

첫번째 챕터에서는 시스템이 멈추지 않고 계속해서 안정적으로 유지할 수 있도록 안정성을 구축하는 기반을 다지는 방법을 살펴본다.

특히 시스템을 안정성있게 유지하기 위한 패턴에 대한 내용을 다루는 내용은 반드시 읽어보기를 추천한다.

두번째 챕터에서는 점점 진화되는 운영 환경에서 복잡하게 이루어진 여러 요소들을 운영시 고려하며 설계하는 방법에 대해 다루는데, 시스템을 안정적으로 운영하기 위한 전반적인 설계 방법을 소개한다.

현재 시스템들이 운영되는 환경에서부터 이 시스템을 이루는 여러 구성 요소들과 보안영역까지의 전반적인 내용이 담겨있다.

세번째 챕터에서는 대용량 데이터를 다루는 배치에 대한 설계와 각 서버 간의 버전 관리 내용을 다룬다.

특히 이 챕터는 배치 설계방법과 무중단 배치에 대해 알아볼 수 있었고, 버전 관리의 중요성을 다시한번 느끼게 되었다.

네번째 챕터는 시스템이 점점 진화하면서 이에 유연하게 적응하는 시스템을 만드는 방법을 알아본다.

특히 여러 장애 상황을 무작위로 가해 시스템을 점점 개선하는 생소할 수 있는 카오스 공학에 대해서도 배워볼 수 있다.

​

개인적으로 이 책은 시스템을 개발하고 운영하는 모든 분들이 한번쯤 꼭 읽어보기를 추천한다.

운영 환경 설계에 대한 고려사항들에 대해 모두 담겨 있다는 점에서 한번 읽고 끝이 아닌 소장해도 좋을 책이다.

애플리케이션을 배포하면서 기도해 보신 적 있으신가요?

열심히 만들었고 정상 작동하는 걸 확인했다면 애플리케이션을 운영 서버에 배포하는 건 아무 문제 될 게 없다고 담대히 말할 수 있는 시간은 아주 잠깐입니다.

개발하고 테스트할 때는 멀쩡히 돌아가던 기능이 운영 서버에서 안 돌아가는 정도가 아니라 전체 애플리케이션을 먹통으로 만드는 상황을 한두 번 겪고 나면 배포할 때마다 긴장하게 됩니다.

배포 일정이 잡히면 관련 있는 사람들이 제발 아무 일없이 지나가기만을 바라는 가운데 배포하게 됩니다.

아직 관련 시스템이 없는 상황이라면 어렵지 않게 만날 수 있는 상황입니다.

사례와 안티 패턴

읽기만 했는데도 손에 땀이 맺히고 머릿속이 하얘지는 내용들을 먼저 만날 수 있습니다.

실제로 있었던 일들이고 충분히 일어날 수 있는 상황이라고 이해되기 때문입니다.

그리고, 문제를 일으킬 수 있는 요인이 얼마나 다양한지 알 수 있습니다.

운영 고려 설계

요구사항에 유연하게 대응할 수 있는 설계를 보며 바람직하다고 단편적으로 생각하면 곤란합니다.

바람직한 설계가 바람직한 게 아닐 수 있다고 합니다.

결합도를 낮추고 응집도를 높인 코드조차도 운영을 고려하여 한번 더 생각해 보아야 합니다.

왜 만드는가

진부한 표현이지만 사용자를 위해 서비스가 존재한다는 사실을 잊지 않게 합니다.

사용자를 지향하는 시스템을 그리고 있습니다.

이를 통해 가치를 창출하고 있는지 답해야 한다고 합니다.

논리와 합리를 바탕으로 하되 심리가 더 크게 작용하는 곳인 것 같습니다.

사람을 위한 시스템을 얘기하고 있습니다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

요즘 개발 도서를 살펴보면 기술적인 내용뿐만 아니라 아키텍처 관련 도서가 더 관심을 끌고 있습니다. 개발에 대한 접근 방식이 단순히 기술의 세부 사항을 공부하는 것을 넘어, 어플리케이션 및 솔루션의 아키텍처를 전반적으로 이해하고 설계하는 방향으로 바뀌고 있습니다.

이런 관점에서 다른 기업과 서비스의 아키텍처를 분석하는 것은 나만의 설계 능력을 향상시키는 데 매우 유용합니다. 이전에 접한 [가상 면접 사례로 배우는 대규모 시스템 설계 기초]와 같은 책들은 서비스 구성과 활용 방법에 대한 풍부한 정보를 제공했고, 이번 서평에서 소개하는 책도 운영 중인 서비스의 아키텍처 설계에 대한 중요한 통찰력을 제공합니다.

해당 책은 저자 마이클 나이가드의 개발 경험을 기반으로 구성되었으며, 독자는 글을 읽는 과정에서 다양한 이벤트와 설계 사례를 통해 흥미로운 내용을 만나게 됩니다.

이 책은 총 4개의 주요 섹션으로 구성되어 있으며, 각 섹션은 저자의 경험 사례로 시작하여 아키텍처 측면에서 고려해야 할 사항을 자세히 다루고 있습니다. 특히 이 책은 독자가 실무에서 자주 사용되는 IT 용어를 사례와 함께 다루어, 독자들이 용어를 보다 정확하게 이해할 수 있도록 도와줍니다 

아키텍처를 공부하고자 하는 개발자들에게 매우 유용한 이 책을 강력히 추천합니다. 나 역시 이 책을 여러 번 읽어보며 더 깊은 이해와 통찰력을 얻고자 합니다.

연차가 쌓여 가면서 개발이 아닌 설계, 관리의 업무도 다루게 되었다.
그런데 평소 그러한 고민 없이 그때그때 임기응변(?)으로 처리하다 보니 항상 무엇인가 부족한 느낌이 있었다.

이 책은 나와 같은 사람에게 도움이 될만한 책이다.
개발자, 아키텍트로 경력을 쌓아온 저자가 본인의 경험을 바탕으로 설계부터 배포까지의 노하우를 전수해준다.
몰랐는데 사실 이 책은 이미 꽤 유명했던 도서였다. 1판 이후 많은 사람들이 여러 번 반복해서 보던 책이라고 하니 이번 2판 도서도 어느 정도 기대가 되는 것이 사실이다.

총 4부로 구성된 도서는 각각에 도서의 경험과 사례를 잘 풀어서 설명을 하였는데, 특히나 '2부. 운영 고려 설계' 부분이 가장 마음에 들었다.
부끄럽지만 고백하자면 가장 마음에 들었지만 한 편으로는 잘 이해가 가지 않았던 부분이기도 하다.

'시니어 개발자로 도약하기 위해 반드시 알아야 할 내용'을 담은 비법서 라고 소개가 되어 있는데, 
아직 나의 내공이 부족한 탓인지 완벽하게 이해가 가지 않아 여러 번 읽어봐야겠다.

다만 책을 읽으면서 용어가 아쉬웠다.
역자 자신도 용어에 대해 많은 고민을 했음을 고백하였지만, 책을 읽다보면 매끄럽게 와닿지 않는 부분이 아쉬웠다. (개인적인 부분이기 때문에 절대적인 것은 아니다.)
예를 들어 '스케일 업', '스케일 아웃' 에 대한 내용을 '수직 확장', '수평 확장'으로 풀어냈는데 영어 용어가 익숙하다보니 읽으면서 다시 의미를 곱씹어 보게 되어 읽을 때 약간(?)의 방해(?)가 되었던 것 같다.

그럼에도 많은 경험을 가지고 있는 저자의 노하우를 간접적으로 알아볼 수 있는 좋은 경험이기 때문에 도서를 추천한다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

35년 경력을 가진 선배 개발자가 직접 겪은 다양한 이슈와 과거 큰 이슈들을 이야기해주면서 실제 프로덕트 환경의 무서움을 알려주는 책이다.

코드를 잘못 작성해서, 요구사항과 다른 구현, 예외처리를 놓쳐서 등 프로그램을 잘못 작성해서 발생하는 문제들은 분명 많다.

많은(거의 모든) 개발자들은 위 사실을 알고 최대한 위와 같은 일들이 일어나지 않도록 테스트 코드를 작성하고, 많은 테스트를 통해 방지를 위해 힘을 쓴다.

하지만, 실환경에서는 문제가 저게 다가 아니다.

테스트 환경에서는 발견할 수 없었던 문제가 실환경에서는 더 많은 서버가 올라가고,

더 많고 무작위인 많은 트래픽(사용자)로 인해 성능 테스트에서 발견하지 못한 문제를 만날 수도 있으며,

많은 사람이 믿고 사용하는 라이브러리를 믿고 가져다 썼다가 버그가 있을 수도 있고,

AWS에 모든 서버를 구축했지만, AWS의 실수로 몇 시간의 장애가 있을 수 있고,

전혀 문제가 없을 것 같은 네트워크조차 문제가 발생할 수 있다.

이 외에도 과거에 겪은 다양한 사례로 조심해야 할 안티 패턴과 문제들이 많지만, 모두 완벽히 방지할 수는 없다.

하지만, 미리 책에서 알려주는 안정성 패턴을 통해 문제가 발생했을 때 빠르게 인지하고, 해결하기 위한 환경을 갖춤으로써 좀 더 안전한 시스템을 구축하여 많은 시행착오를 줄일 수 있을 것이다.

이 책의 내용은 소프트웨어 설계를 어떻게 하면 좋을지에 대한 방법과 실제 서비스를 운영하는 노하우를 알려주는 책이다.

그렇기에 신입보다는 직접 Release를 준비하는 개발자 혹은 어느 정도 경력있는 사람이 읽었을 때 더 많이 와 닿는 게 많을 것 같고,

주니어라면 이 책을 깊게 파기보다는 가볍게 훑으면서 '이런 생각지 못한 상황이 발생할 수도 있구나' 정도로 보면서

책에 나오는 용어들을 보고 알아가는 것만으로도 도움이 될 것 같다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

운영에 배포를 할 때 아무리 테스트 코드를 짰다고 하더라도, QA를 열심히 했다고 하더라도

서비스를 이용하다보면 예기치 못한 장애를 만나기도 한다.

그렇다면 안정적으로 배포를 하기 위해서는 어떤 것을 고려해야 할까?

​

이 책은 4부로 나눠져 있어 각 부가 시작할 때 마다 하나의 사례를 들고 그 사례를 기반으로 서술하고 있다.

1부에서는 운영에서 장애가 발생한 하나의 예시를 설명한다.

그리고 이 장애를 어떻게 처리했는지, 더 나아가 장애를 일으키는 안티 패턴엔 어떤 것들이 있으며

그 안티 패턴을 없애기 위한 안정성 패턴에 대해 설명해준다.

2부에서는 실제 운영 프로세스를 설계할 때 고려해야 하는 것에 대해서 설명해주고 있다.

2부를 읽으면서 내가 한 운영 설계에 대해 반성 타임을 많이 가졌다....ㅠ

​

이 책의 장점은 앞서 말한 것과 같이 사례를 들어 설명한 후

그 것을 개선하는 방식으로 진행하여 이해하기 쉽다는 점이다.

사례 뿐만 아니라 중간 중간 예시도 많아서 머릿속으로 그리면서 할 수 있었고,

매 장마다 요점 정리가 있어 읽은 내용을 한 번 더 리마인드 할 수 있어서 좋았다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

​

두고두고 꺼내 읽어 볼 책

한 번에 이해하기 어렵지만, 출시 및 운영을 해야 한다면 꼭 사서 읽어야 할 필독서.

우리는 가끔 소프트웨어를 개발만 잘 하면 된다라고 착각을 한다. 그래서 운영 이라는 거대한 산을 간과하는 경우가 많이 생긴다. 모든 소프트웨어는 운영에 들어가기 전에 많은 테스트와 검증을 거쳐서 실제 운영에 들어가게 된다. 그래서 이때에 개발할때는 생각하지 도 못했던 버그나 오류들이 발생하게 된다. 검사 방법과 환경에 따라서 다양한 상황들이 발생하기 때문에 어떻게 대처를 해야 하는지 방법을 한참 찾아봐야 할 때도 있다. 그런 면에서 이 책은 포괄적인 가이드라인을 제공 해주고 있다.

책 읽어보면 느끼겠지만 운영전 검증에 필요한 요소들이 다 들어있다. 그리고 사례들을 여러가지 예로 들어줘서 더 현실감이 느껴졌다.

우선 1부에서는 안정적인 어플리케이션을 위한 여러가지 패턴에 대해서 이야기 해준다. 4장에서 안티패턴을 먼저 알려주고 5장에서 적절한 패턴에 대해서 설명을 해준다. 

2부는 특히 내가 경험했던 일들과 연관들이 많아서 더 재미있었다. 부하, 보안, 로그, 모니터링등 개발을 하면서 많이 경험해봤던 내용들이 많이 있었다. 그리고 내가 몰랐던 내용들도 많이 알수 있었다.

3부에서는 배치와 버전관리에 대해서 나온다. 특히 버전관리는 설계시에는 그럴듯하게 만들어놓지만 점점 유명무실 해지는 상황을 많이 경험했는데 역시나 이렇게 하면 안된다는 것을 다시한번 느낄수 있었다. 

각각의 내용들은 챕터에 따라서 나눠져 있기 때문에 굳이 처음부터 읽을 필요는 없고 궁금하거나 관심있는 부분부터 읽어도 아무런 문제가 되지 않는다. 그래서 약간은 백과사전 같은 느낌으로 두고두고 읽어도 좋을 것 같다는 생각이 들었다.

 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

2023년도 마지막 리뷰할 개발 도서를 받았다. 올해도 벌써 다 갔네. 킁.

이름하여, Release의 모든 것.

무려 468 페이지의 굵은 볼륨으로 구성되어 있다.

아키텍트를 지향하고 있다면 '개발자에서 아키텍트로' 라는 도서와 함께, 읽어야 할 도서 목록에 추가해두셔도 좋을 것 같다.

개발 실무를 십수년 하고 있는 입장에서, 이 도서의 수많은 내용들이 대단히 마음에 와닿았다.

몇가지 마음에 와닿는 구절들을 아래 나열해본다. 'ㅅ')

.

‘기능 개발 완료’는 ‘운영 준비 완료’를 의미하지 않는다. 개발, 테스트, 통합, 계획 등 운영 이전 단계에 있는 모든 것은 서곡일 뿐이다.

개발은 QA 테스트를 통과하는 것을 목표로 삼지만, 테스트만으로는 현실에서 소프트웨어가 사용될 준비가 되었다고 증명하기에는 충분하지 않다.

설계와 아키텍처 결정은 재무적인 결정이기도 하다. 따라서, 구현 비용뿐만 아니라 파생 비용까지 고려해서 결정해야 한다.

초기에 내리는 결정은 시스템의 최종 모습에 가장 큰 영향을 미친다.

결함은 결코 완벽히 방지할 수 없다. 결함이 오류가 되지 않게 막아야 한다.

실제 운영 환경의 트래픽을 복제하는 것은 불가능하다. 그래서 트래픽 분석, 경험, 직관을 이용해서 최대한 현실에 가깝게 시뮬레이션해야 한다.

애플리케이션 개발자는 심각한 상황을 차단하는 안전 장치를 구축해야 한다.

출시 절차가 너무 고되면 한 해에 몇번 밖에 시행되지 않는다. 출시는 이발하는 정도의 행사여야 한다.

효율성은 오늘 당장의 작업에 사람들을 더 집중하게 만들 수 있기에, 이는 미래의 변화를 어렵게 만들 수도 있다.

실패가 형태를 결정한다.

마이크로서비스가 우리를 괴롭히는 진짜 문제를 해결하는지 확인하라.

.

위에 몇 문장 늘어놓지 않았는데도, 이 책이 당신에게 줄만한 가치가 느껴지지 않는가? 'ㅅ')

운영과 관련된 광범위한 주제를 두루두루 다루므로 나의 하룻강아지 같은 지식으로 감히 평할 수 없는 도서이며,

서비스를 운영하는 내 주변 개발자들도 얼른 읽고 머리와 무릎을 탁 치고 영향을 받기를 바란다.

.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

.