[북리뷰] 대용량 아키텍처와 성능 튜닝

조대협 지음

프리렉, 2015

 

 

 

대용량 시스템을 개발해야 하는 입장이 되어보면, 설계적 관점에서 향후 스케일링 될 수 있는 부분을 고려하여 확장성있게 계획해야 한다는 점이 중요하다. 그런 의미에서 아키텍처 설계는 개발자들이 세부 설계에 들어가기에 앞서 큰 그림이 되어주는, 방향성을 잡는 중요한 부분이 되겠다. 고객이 무엇을 원하는지 명확하게 모두(고객과 개발자)와 공감할 수있게 하는 좋은 수단이 되는 것이아키텍처 설계이고, 아키텍트의 역할이 그 지점에 있었다. 그런 점에서 저자는 아키텍처가 문서로써 어떻게 구체화 되어져야 하는지도 자세히 설명해 준다.

 

아키텍트의 존재는 회사 내에서도 명확하지 않다. 그냥 누구나 PM 자격이 되면, 도해 3장(어플리케이션, 네트워크, 데이터 아키텍처)을 떡하니 그려낼 줄 알게 되는, 그러면서도 설계는 설계이고 시스템은 시스템일 뿐인 정도로 이해하는 게 다였다. 설계는 언제나 변경될 여지가 많아, 처음에 그려지는 것은 일정부분 밑그림 정도에 그쳐야 했지, 산출물 이상의 큰 의미로 부여되지 않아 왔다. 그런데 이 책은 이처럼 소홀히 여겨졌던 부분의 필요성과 복잡한 현실 코딩 영역을 뒷바침 해줄 인프라 영역의 견고한 전략을 소개한다. 읽는 내내 쉬운 기술 설명과 현장 경험을 담은 조언들을 꼼꼼히 메모하고 싶었다. (다음에 읽을 땐, 또 어떤 문구들이 와 닿을지 모른 일 이다.) 이 책을 읽으며 개인적으로 인상깊었던 내용과 새롭게 알게된 사실을 소개한다.  

 

아키텍트의 역할에 대해서 물어보면 흔히들 시스템을 설계하는 기술자나 엔지니어로 생각하는 경우가 많다. 물론, 시스템의 설계가 아키텍트의 주요 역할임에는 틀림이 없다. 그러나 아키텍트는 단순히 설계뿐만 아니라 좀 더 넓은 범위의 역할을 갖는다. 가장 중요한 역할 중의 하나는 비즈니스(사업 쪽)의 언어를 기술적인 언어로 통역하는 것이다. 비즈니스 요구사항을 기술적인 요구사항으로 변경하여 정의하고 이를 바탕으로 전체적인 시스템을 정의하는 비즈니스와 기술 조직 간의 소통자의 역할을 한다. (63)

 

 

우리는 이들을 컨설턴트라고 부른다. 그런데 컨설턴트는 너무 업무에만 치중한 탓인지, 기술쪽에는 관심이 부족했다. 그만큼 도메인 지식과 시스템 이해를 동시에 갖춘 컨설턴트를 만나는것은 쉽지 않은 일이다. 아키텍트는 그런의미에서 더욱 개발자와 가까운 존재라고 볼 수 있다. 사실 경험 많은 개발자가 전체 비즈니스 업무를 이해하고 접근하였을 때 보여줄 수 있는 가장 이상적인 예가 아닌가 한다. 그런 의미에서 개발자들은 컨설턴트 영역에 대한 공부를 꾸준히 하여야 하겠지.

 

아키텍트는 기술이 전부가 아니라 비즈니스 목표를 한정된 자원을 가지고 구체화 시킬 수 있는 시스템을 설계해야 하며 단순히 기술뿐만 아니라 비즈니스와 팀 관리와 같은 다른 부분에 대한 역량까지 겸해야 한다. (65)

 

작은 개발 회사들은 아키텍트를 별도로 두기 보다는 PM에게 이러한 일들을 위임하는 경우가 많고, 또 아키텍트가 투입된 프로젝트더라도 그들은 개발의 세계와 완벽히 분리되어 서버 설치, 권한부여 등의 철저히 단절된 세계를 향유하는 모습을 보여 줬다. 그때는 그게 본연의 역할인 줄 알았다. 그러나 업무적 관점에서도 얼마나 깊이 있게 개입되는 존재들이어야 하는지를 알게 해줬다.

 

SOA 프로젝트의 실패 원인 중의 하나를 ESB로 꼽는 경우가 많은데, 이는 ESB를 프락시나 게이트웨이처럼 가벼운 연산만이 아니라, 여러 개의 서비스를 묶는 로직에 무겁게 사용했기 때문이다. (사용하면 안된다는 것이 아니라 잘 사용해야 한다는 것이다.) ESB는 메시지를 내부적으로 XML로 변환하여 처리하는데, XML 처리는 생각하는 것보다 파싱에 대한 오버헤드가 매우 크다. 또한, ESB의 고유적인 버스나 게이트웨이로서의 특성이 아니라 타 시스템을 통합하기 위한 EAI적인 역할을 ESB를 이용해서 구현함으로써 많은 실패 사례를 만들어 내었다. 그래서 종종 ESB는 Enterprise Service Bus가 아니라 Enterprise Nighmare Bus로 분리기도 한다. (101)

 

왜 아니겠는가? 통합 작업으로 연루되어 밤에 불려나가거나 주말에 대기해야 하는 상황을 겪어본 경험이 있다면 이 말에 공감할 것이다. 분명히 수많은 서버가 동원되었는데도 성능은 나아질 기미를 보이지 않을 때 오는 좌절감은, 이 조합이 아닌가 하는 회의에 빠지게 만든다.

 

모노리틱 아키텍처는 하나의 프로세스 내에서 서비스 간의 호출에 참조 호출(Call-by-Reference) 모델을 이용한다. 반면 마이크로 서비스 아키텍처는 서비스 간의 호출을 API 통신을 이용하기 때문에 값을 JSON이나 XML 프로그래밍에서 사용하는 데이터 모델(자바 객체 등)로 변환하는 마샬링 오버헤드가 발생하고 호출을 위해서 이 메시지들이 네트워크를 통해서 전송하기 때문에 그만큼 시간이 추가로 소요된다. (103)

 

대용량 아키텍처를 갖추었다고 해서 속도가 빠르게 될 거라는 것은 오산인 것 같다. 이 오버헤드는 절대 무시할 수 없는 괴물이다. 어쩌면 잘못된 설계에서 기인한 것일수도 있겠지만, API 통신의 부담을 잘 설득해야 하는 과제가 있는 셈이다. (지금 여기 프로젝트는 EAI를 ETL처럼 사용한다.)

 

기술에 대한 독립성을 가지려면 구현뿐만 아니라 운영 또한 직접 할 수 있는 능력을 갖춰야 한다. 그래서 개발과 운영을 하나의 조직에 합쳐 놓는 구조를 DevOps라고 한다. DevOps는 개발(Development)와 운영(Operation)을 합성한 단어로, 개발팀과 운영팀이 다른 팀으로 분리되어 있어서 발생하는 의사소통의 문제점을 해결할 수 있다. 개발이 운영을 고려하고 운영에서 발생하는 여러 문제점과 고객으로부터의 피드백을 빠르게 수용하여 서비스 개선에 반영하는 개발 모델이다. (108)

 

예전 프로젝트에서 개발팀과 운영팀간 회사가 달라 "개와 고양이"로 지낸 적이 있었다. 개발팀이 운영을 맡으면 위와 같은 시너지가 나겠지만, 발주기관은 형평성을 고려한 탓인지, 개발팀에게 운영을 맡기지 않았다. 그래서 쉬운길도 돌아가야 하지 않았었나 하는 생각이 든다. DevOps, 이런 용어가 있고, 이런 트랜드가 있다는 것을 진작에 소개했어야 하는 것 아닌가 싶다.

 

분산형 거버넌스 모델에서는 팀원의 영속성을 보장해줘야 하는데, 이를 위해서는 프로젝트가 아니라 프로덕트(즉 상품) 형태의 개념으로 개발 모델이 바뀌어야 한다. 팀은 상품에 대한 책임을 지고 요구 사항 정의 발굴부터 개발 및 운영을 책임져야 한다. 또, 계속해서 상품을 개선해 나가는 활동까지 지속해야 한다. 이를 상품 중심의 개발팀 모델이라고 한다.(109)

 

DevOps 만큼 중요한 개념이라고 보여지는데, 개발 결과를 하나의 제품으로 보고 지속으로 발전시켜 나가도록 하는 모델이다. 개발하고 철수하는 것만이 능사가 아니니, 결국은 누군가를 붙박이로 세워놔야 하는 것이다. 자꾸 인력을 뺑뺑이 돌릴 생각일랑 말고.

 

마이크로 서비스 아키텍처는 서비스의 재사용성, 유연한 아키텍처 구조, 대용량 웹 서비스를 지원할 수 있는 구조로, 많은 장점을 가지고 있지만 운영하는 팀에 대해서 높은 성숙도가 필요하다. (111)

 

결국은 높은 성숙도다.

 

특히 근래의 아키텍처 모델은 시스템에 대한 설계 사상뿐만 아니라 개발 조직의 구조나 프로젝트 관리 방법론까지 영향을 미치기 때문에 단순히 기술적인 관점에서가 아니라 조금 더 거시적인 관점에서 고려해볼 필요가 있다.(112)

 

지당한 말이다. 잘 고려된 아키텍처 하나가 열 손을 절약할 수 있다고 본다. 삽질만 안하게 해도 그게 어디인가 말이다.

 

인터넷이 발전하면서 IT의 흐름이 크게 바뀐 것은 더는 오라클이나 IBM과 같은 대형 벤더 주도의 기술이 아니라 페이스북이나 구글과 같은 거대 B2C 서비스가 IT의 흐름을 이끌기 시작했고 이러한 업체들이 오픈소스를 적극적으로 후원 및 장려하기 시작했다는 점이다. 오픈소스를 통해서 전 세계의 개발자들과 함께 이야기를 할 수도, 일을 할 수도 있고, 또 오픈소스를 잘 하면 구글이나 페이스북과 같은 좋은 회사에도 취직할 수 있다. 그래서 개발자들이 오라클이나 SAP와 같은 엔터프라이즈 제품을 공부하지 않고 오픈소스를 개발하면서 '논다(Enjoy)'. (122)

 

 

뭔가를 새롭게 개발해서 붙이기 보다는 만들어져 있는 것을 잘 활용하는 것도 좋은 개발 방향이라는 거다. 그런데 이 말씀엔 일단 절반만 동의하고 싶다. 오픈소스가 끝까지 책임져 주지 않는 것을 많이 보아온 회의 때문일 것이다.

 

요즘 같이 비즈니스의 변화가 심하고 멀티 롤 개발자가 필요한 시점에 DevOps를 수행할 수 있는 능력을 가진 개발자의 가치는 점점 높아지고 있다. Mashable에 따르면 가장 빠르게 성장하는 IT 직업 중의 하나가 DevOps 엔지니어라고 한다. (132)

 

풀스택 개발자와 뭐가 다를까 싶다. 일정부분 동의하지만, 이또한 생활 개발자들에게는 너무 가혹한 요청사항이라 보여진다.

 

가장 나쁜 디자인 중 하나가 GET이나 POST를 이용한 터널링이다. http://myweb/users?method=update&id=terry 경우가 전형적인 GET을 이용한 터널링이다. 메서드의 실제동작은 리소스를 업데이트 하는 내용인데, HTTP PUT을 사용하지 않고 GET에 쿼리 파라미터로 method=update라고 넘겨서 이 메서드가 수정 메서드임을 명시했다. 대단히 안 좋은 디자인인데, HTTP메서드 사상을 따르지 않았기 때문에 REST라고 부를 수 없고 또한 웹 캐시 인프라 등도 사용할 수 없다.(145)

 

REST의 개념을 덕분에 쉽게 소개받았다. 향후 이 기술에 대해 좀더 깊이 들여다 볼 용기를 얻었고, 실제 타 시스템과 인터페이스 하면서 REST를 이용하곤 했는데 부끄럽지 않은 REST를 설계해야겠다고 생각했다.

 

API 정의에서 중요한 것 중의 하나는 버전 관리이다. 이미 배포된 API의 경우에는 계속해서 서비스를 제공하면서 새로운 기능이 들어간 새로운 API를 배포할 때는 하위 호환성을 보장하면서 서비스를 제공해야 하기 때문에 같은 API라도 버전에 따라서 다른 기능을 제공하도록 하는 것이 필요하다.(151)

 

솔직히 아직 이런 단계까지는 생각해 보지 않았는데, 페이스북이나 선진 페이지의 방식을 예로 설명해 주는 부분이 좋았다. 기업 프로젝트더라도 이 부분은 꼭 필요한 부분이라고 생각한다. 하위호환성, 거의 전무하다 시피 한다. 그냥 뭉게고 새롭게 만드는 것이다.  

 

REST에 대한 잘못된 생각 중의 하나가, HTTP + JSON만 쓰면 REST라고 부르는 경우인데, 앞의 안티 패턴에서도 언급하였듯이, REST 아키텍처를 제대로 사용하는 것은 리소스를 제대로 정의하고 이에 대한 CRUD를 HTTP 메서드인 POST/PUT/GET/DELETE에 대해서 맞춰 사용하며, 에러 코드에 대해서 HTTP 응답 코드를 사용하는 등 REST에 대한 속성을 제대로 이해하고 디자인해야 제대로 된 REST 스타일이라고 볼 수 있다. 수년 전뿐만 아니라 지금에도 이러한 안티 패턴이 적용된 REST API 형태가 많이 있기 때문에 제대로 된 REST 사상을 이해한 후에 REST를 사용하도록 해야 한다. (164)

 

REST는 특별한 표준이 없다시피 해서, 사상에 의존해야 한다고 본다. 그러고 보니 사실 깊이 들여다 보면, 스피링도 의존성이니, AOP 니 하면서 사상을 강조했더랬는데, 이렇듯 겉모습만 스프링인 경우가 많아서 그런가 보다. 외형은 비슷한데 속내는, 사상과 다르게 구현함으로써 본래의 취지와 효과를 살리지 못하기 때문인 것이다.

 

보안에 대해서 말하자면 한도 끝도 없겠지만, 최소한 API 보안에서는 HTTPS를 이용한 네트워크 보안과 함께 API 토큰의 인증 방식을 반드시 사용하기를 권장한다. 보안 처리를 하지 않아도 API 토큰의 인증방식을 반드시 사용하기를 권장한다. 보안 처리를하지 않아도 API의 작동이나 사용에는 문제가 없다. 그러나 보안이라는 것은 한번 뚫려버리면 많은 정보가 누출되는 것은 물론이고 시스템이 심각한 손상까지 입을 수 있기 때문에 시간이 걸리더라도 반드시 주의를 기울여 설계 및 구현할 것을 권장한다. (199)

 

성경에 "우는 사자 같이 두루 다니며 삼킬 자를 찾나니"라는 문구가 있다. 오늘날의 웹생태계가 그런 것 같다. 언제 어디에나 위험이 도라리고 있다. 보안 관점에서 주의해야겠다.

 

근래에 들어 자바스크립트 기술이 발전하면서 SPA(Single Page Application)가 유행하기 시작했다. SPA란 브라우저에서 페이지 간의 이동 없이 자바스크립트를 이용해서 동적으로 페이지를 변경할 수 있는 방식이다. (200)

 

 

 

어제까지의 데이터는 일별 배치로 생성된 테이블을 사용하고 오늘 데이터 부분은 사용자별로 기록된 로그 테이블을 사용하여 두 테이블을 조인하면 오늘 지금 이 순간의 통계 값까지 볼 수 있다. (213)

 

생각해 보지 못한 매우 좋은 아이디어다. 시스템 튜닝관점에서도 좋은 적용 사례로, 꼭 구현해 보고 싶은 부분이다. 이를 '람다 아키텍처'라고 부른다. "람다 아키텍처를 꼭 빅데이터에 적용하거나 또는 하둡을 이요해야 하는 아키텍처가 아니다. RDBMS나 CSV 파일 등 어떤 데이터 형태라도 기본은 배치를 이용한 집계 테이블과 실시간 뷰 테이블을 조인한다는 개념이기 때문에 솔루션에 얽매이지 않고 적절한 시나리오를 찾아서 적용할 수 있도록 해야 한다."(220)

 

비즈니스 로직이 복잡한 서비스의 경우에는 자바 플랫폼을 단일로 사용하는 것이 아니라 복잡하고 중요한 API는 자바를 이용해서 개발하고, 일반적인 API들은 스크립트 언어를 이용해서 개발하는 경우가 많다. (259)

 

요즘 트랜드인가 본데, 따라가기 더럽게 어렵다. 

 

성능 엔지니어링에 대한 경험인데, 대략 시스템의 상태만 봐도 어느 부분이 의심되는지 경험이 많은 엔지니어는 쉽게 접근한다. 성능 문제는 넓어 보이지만 결국 발생하는 패턴이 거의 일정하다. 특정 솔루션에 대한 지식이 없거나 모니터 방법, 도구의 사용법이 다르다 하더라도 문제에 접근하는 방법이나 의미하는 것은 거의 비슷하므로 다른 기술로 구현된 시스템이어도 경험이 있는 엔지니어는 문제에 접근해서 풀어나가는 방식에 매우 익숙하다. (390)

 

문제는 경험이다. 그냥 년수만 보탠 경력자가 아닌, 잘 정리된 지식으로 채화한 경험자가 트러블슈팅의 주인이 된다. 매번 이런 취지로 기록은 해 놓는데.. 어디다 뒀는지를 모르겠다..

 

튜닝은 서문에서도 이야기한 것처럼 엔지니어로서 가장 재미있는 부분 중 하나이지만, 그만큼전문지식부터 문제 접근 방법과 경험까지 많은부분이 필요한 분야이다. 마지막으로 강조하고 싶은 것은 전문적인 기술보다는 논리적인 문제 접근 방법과 문제가 해결될 때까지의 끊임없는 인내심이 필요하다는 점이다. (450)

 

논리적 접근법을 가지려고 한참을 노력중이다. 그리고 역시 튜닝은 많은 시간이 드는 지난한 작업이다.

 

소프트웨어 개발 프로젝트는 고객의 요구 사항만 제대로 파악하고 있어도 80%는 성공한 것이다.(451)

 

지당한 말씀.

 

모든 기계가 그렇듯이 복잡한 기계일수록 고장이 잦다. 소프트웨어도 마찬가지이다. 복잡한 아키텍처일수록 문제가 생겼을 때 디버깅하기가 어렵고 변경 사항이 생겼을 때 반영하기가 어렵다. 디자인 패턴으로 무장한 컨설턴트가 와서 시스템을 온통 디자인 패턴으로 도배해놓을 수도 있다. 그렇지만,그것을 디버깅해야 하는 것은 그 컨설턴트가 아니라 개발자 여러분이다. (디자인 패턴이 나쁘다는 것은 아니다. 불필요한 패턴 사용으로 시스템의 복잡도를 올리는 것에 대한 이야기다.) 가능하면 시스템은 간단하게 설계하자. 고수가 설계한 시스템일수록 단순하고 고장이작다. (453)

 

심플이즈 베스트. 정말 공감가는 말이다. 고객은 늘 우리 시스템이 AI 처럼 각종 상황마다 빠르게 대처해주기를 바라마지 않아, 개발 이후에도 거의 한 번의 고도화를 거치는 마큼의 요구사항을 내놓으신다. 그러고 나면 소스관리가 어느 순간부터 안되고, 스파게티 소스 코딩으로 관리 차원의 비용이 엄청나게 소요되게 한다. 이런 거 우리 하지 말아야 한다.