<div id="readability-page-1" class="page"><div><p><h2 id="1172">신뢰할 수 있고, 확장 가능하며, 유지보수하기 쉽도록</h2></p><p id="d142">‘데이터 중심 애플리케이션 설계 by Martin Kleppmann’ 책의 1장을 읽고 정리한 글입니다. 부족하다고 생각되는 부분은 내용을 덧붙였으며 제 개인적인 생각이 중간중간 첨가되어 있습니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/0*k4vWVNQNcU6A4sBF.png" width="700" height="445" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="eager" role="presentation"></p></div></figure><blockquote><p id="603b"><em>The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free?</em></p><p id="f1ce"><em>인터넷이 문제없이 너무 잘 동작하고 있다 보니 대부분의 사람은 이게 무슨 태평양 같은 천연 자연인 줄 안다. 이정도 규모의 기술이 이토록 오류가 없었던 적은 언제가 마지막일까?</em></p><p id="f014">- Alan Kay, <a href="https://link.springer.com/content/pdf/bbm%3A978-3-319-90008-7%2F1.pdf" rel="noopener ugc nofollow" target="_blank">Dr.Dobbs 저널 인터뷰에서(2012)</a></p></blockquote><p id="cc95">신뢰성, 확장성, 유지보수성의 의미가 무엇인지 명확히하고, 우리가 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 데이터 시스템을 구축하기 위해 할 수 있는 기초적인 노력들은 어떤게 있을지 살펴보자!</p><h2 id="89e3">신뢰성</h2><p id="5743">애플리케이션이 사용자가 기대한 기능을 수행하는 것을 ‘올바르게 동작함’이라 부른다면, 신뢰성이란 <strong>“무언가 잘못되더라도 지속적으로 올바르게 동작함”</strong> 정도로 이해할 수 있다.</p><p id="0faa">무언가 잘못될 수 있는 일을 결함(fault)이라 부르는데, 이 결함을 예측하고 대처할 수 있는 시스템을 <strong>내결함성(fault-tolerant) 또는 탄력성(resilent)</strong>을 지녔다고 말한다. 그리고 결함은 장애(failure)와는 다른 의미이다. 결함은 사양에서 벗어난 시스템의 한 구성 요소로 정의되지만, 장애는 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우이다.</p><h2 id="5068">하드웨어 결함</h2><p id="10a4">하드웨어에 문제가 생기는 경우는 생각보다 흔하다. 하드디스크의 평균 장애 시간(mean time to failure, MTTF)은 약 10 ~ 50년으로 보고됐는데, 이말인 즉슨 10,000개의 디스크로 구성된 클러스터는 평균적으로 하루에 한 개의 디스크가 죽는다는 뜻이다.</p><p id="1e3f">이러한 하드웨어 결함에 대응하기 위한 노력으로 각 하드웨어에 중복성(redundancy)을 추가하는 방법이 일반적이다. 예시로 디스크는 RAID 로 구성하고 핫 스왑 가능한 CPU 그리고 예비 전원용 디젤 발전기를 갖추는 방법 등이 있다.</p><p id="16b9">하지만 데이터의 양과 애플리케이션의 계산 요구가 늘어남으로 인한 장비 수의 증가는 하드웨어 결함율의 증가를 유발했고, 최근에는 하드웨어 중복성과 더불어 소프트웨어 내결함성 기술을 사용하여 중단시간을 최대한 줄이고 있다.</p><h2 id="4872">소프트웨어 오류</h2><p id="5f88">소프트웨어 결함을 유발하는 버그는 특정 상황에 의해 발생하기 전까지 오랫동안 나타나지 않는다. 특히나 예상하기 어려운 체계적 오류같은 경우 신속한 해결책이 없다. 소트프웨어 결함에 대응하기 위해 우리는 아래와 같은 <strong>여러가지 작은 일들</strong>에 많은 노력을 기울여야 한다.</p><ul><li id="bb4c">시스템과의 상호작용에 대해 주의 깊게 생각하기</li><li id="9be0">빈틈없는 테스트</li><li id="8e50">프로세스 격리(process isolation)</li><li id="56e1">죽은 프로세스의 재시작 허용</li><li id="1216">시스템 동작의 모니터링과 분석</li></ul><h2 id="2bf3">확장성</h2><blockquote><p id="e631"><em>시스템이 현재 안정적으로 동작한다고 해서 미래에도 안정적으로 동작한다는 보장은 없다.</em></p></blockquote><p id="2ded">애플리케이션의 성능 저하를 유발하는 흔한 이유 중 하나는 부하 증가이다. 확장성은 이렇게 <strong>증가한 부하에 대처하는 시스템의 능력</strong>을 의미한다. 하지만 “X는 확장 가능하다” 거나 “Y는 확장성이 없다” 와 같은 질문은 크게 의미가 없고, 대신에 “시스템이 특정 방식으로 커지면 이에 대처하기 위한 선택을 어떤 것이 있을까?” 와 “추가 부하를 다루기 위해 계산 자원을 어떻게 투입할까?” 와 같은 질문을 고려해보자.</p><h2 id="7921">트위터가 부하를 해결했던 방법</h2><p id="d6b1">시스템의 현재 부하를 간결하게 기술하기 위해 보통 <strong>부하 매개변수(load parameter)</strong>를 사용한다. 적합한 매개변수는 시스템의 설계에 따라 달라지지만 웹 서버의 초당 요청 수, DB 의 읽기 대 쓰기 비율, 동시 활성 사용자 수, 캐시 적중률 등이 있다.</p><p id="c5ff">이에 대한 구체적인 예시로 2012년 11월에 공개된 트위터의 데이터를 살펴보자. 트위터의 주요 동작은 다음 두개이다.</p><pre><span id="fe49"><strong>트윗(tweet) 작성</strong><br>사용자는 팔로워에게 새로운 메시지를 게시할 수 있다.(평균 초당 4.6k 요청, 피크 시 초당 12k)</span><span id="a60a"><strong>홈 타임라인(timeline)<br></strong>사용자는 팔로우한 사람이 작성한 트윗을 볼 수 있다.(초당 300k 요청)</span></pre><p id="54d0">이 두가지 동작의 구현법은 크게 두가지다.</p><ol><li id="164b">사용자가 자신의 홈 타임라인을 요청하면 자신이 팔로우하는 모든 사람을 찾고, 이 사람들의 모든 트윗을 찾아서 합친 후 보여준다.</li></ol><pre><span id="34bb">SELECT tweets.*, users.* FROM tweets<br>JOIN users ON tweets.sender_id = users.id <br>JOIN follows ON follows.followee_id = users.id <br>WHERE follows.follower_id = current_user</span></pre><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/0*zToYZPMNoaX0iXC4.png" width="700" height="303" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div></figure><p id="48b9">2. 각 사용자는 자신의 우편함처럼 개별 홈 타임라인 캐시를 유지한다. 사용자가 트윗을 작성하면 자신을 팔로우하는 사람들의 캐시에만 새로운 트윗을 삽입한다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/0*aVQtwTm92HmEJQge.png" width="700" height="327" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div></figure><p id="0049">초창기 트위터는 1번 접근 방식을 사용했지만 점점 커져가는 홈 타임라인 질의 부하를 견디기위해 고군분투하다가 2번 접근 방식으로 전환했다. 평균적으로 <strong>트윗 게시 요청량이 홈 타임라인 읽기 요청량에 비해 수백 배 적기 때문에</strong> 2번 접근 방식이 훨씬 효율적이다.</p><p id="70d6">하지만 2번 접근 방식은 트윗 작성이 부가 작업을 필요로 하고 이는 대부분의 사용자에게는 문제가 안되겠지만 팔로워가 굉장히 많은(3천만 이상) 특정 사용자의 경우 문제가 된다. 한번의 트윗 게시가 3천만 건의 쓰기 요청을 유발하기 때문이다.</p><p id="b5de">이 때문에 트위터는 1번 접근 방식과 2번 접근 방식을 혼합한(hybrid) 방식으로 바꾸고 있다. 대부분의 사용자는 2번 방식으로 타임라인 캐시에 쓰지만 팔로워 수가 많은 소수의 사용자는 팬 아웃에서 제외하고 1번 방식을 사용한다.</p><h2 id="3f44">성능을 기술하는 방법</h2><p id="d8a5">시스템에 부하가 증가했을 때 어떤 일이 일어나는지를 설명하려면 성능을 수치화 해야한다.</p><p id="3b99">보통 서비스 응답 시간의 산술 평균(arithmetic mean)을 살피지만 이는 그다지 좋은 지표가 아니다. <strong>얼마나 많은 사용자가 실제로 지연을 경험했는지 알려주지 않기 때문이다.</strong></p><p id="28fe">그래서 일반적으로 <strong>백분위(percentile)</strong>을 사용하는 편이 더 좋다. 응답 시간 목록을 시간이 짧은 순으로 정렬한 후 산위 백분위를 살펴보자. 보통 95분위, 99분위, 99.9분위를 사용한다. 요청의 95%, 99%, 99.9% 가 특정 기준치 보다 더 빠르면 해당 특정 기준치가 각 백분위의 응답 시간 기준치가 된다. 예를 들어, 95분위 응답 시간이 1.5초라면 100개의 요청 중 95개는 1.5초 미만이고 5개는 1.5보다 더 걸린다는 뜻이다.</p><h2 id="255a">부하 대응 접근 방식</h2><p id="bf97">부하 매개변수가 어느 정도 증가 하더라도 좋은 성능을 유지하려면 어떻게 해야 할까?</p><p id="ce27">보통 확장성과 관련해 다음 두 가지로 구분한다.</p><ul><li id="6d7d">용량 확장(scale up)(= 수직 확장(vertical scale)) : 좀 더 강력한 장비로 이동하는 것</li><li id="e5b7">규모 확장(scale out)(= 수평 확장(horizontal scale)) : 다수의 낮은 사양 장비에 부하를 분산하는 것</li></ul><p id="e276">강력한 고사양 장비는 매우 비싸기 때문에 대개 규모 확장을 피하지 못한다. 현실적으로 좋은 아키텍처는 실용적인 접근 방식의 조합이 필요하다.</p><p id="0e83">일부 시스템은 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가할 수 있는데, 이를 탄력적(elastic)하다고 말한다.</p><pre><span id="46e1"><strong>resilient 와 elastic 은 다른 의미이다. </strong></span><span id="1ffe">두 영단어는 한글로는 '탄력적' 이라는 한 단어로 번역되지만 그 의미는 전혀 다르다. resilient 는 외부의 충격에 모양에 변형이 생겨도 금새 제 모양으로 돌아올 수 있음을 의미하고, elastic 은 자신의 모양을 자유롭게 늘리고 줄일 수 있음을 의미한다. </span><span id="f576">예를 들면, 축구공은 resilient 하지만 elastic 하지는 않고 슬라임 장난감의 경우 elastic 하지만 resilient 하지는 않다고 말할 수 있겠다.</span></pre><h2 id="c715">유지보수성</h2><blockquote><p id="e24e"><em>간단하고 이해하기 쉬운 시스템은 대개 복잡한 시스템보다 수정하기 쉽다.</em></p></blockquote><p id="2713">소프트웨어 시스템상에서 일하는 많은 사람들은 소위 레거시 시스템 유지보수 작업을 좋아하지 않는다. 다른 사람의 실수를 고치거나 한물 간 플랫폼에서 작업해야하는 등의 불편하고 성가신 일이기 때문이다.</p><p id="1058">이런 유지보수에 들어가는 고통을 최소화하고 레거시 소프트웨어를 직접 만들지 않게끔 소프트웨어를 설계해야한다.</p><h2 id="2d9e">단순하게 만들자</h2><p id="57ab">프로젝트가 커짐에 따라 시스템은 매우 복잡하고 이해하기 어려워진다. 보통 아래와 같은 사례들이 복잡도를 급속도로 증가시키는 원인이다.</p><ul><li id="b1ff">모듈 간 강한 커플링, 복잡한 의존성</li><li id="09c2">일관성 없는 naming</li><li id="017d">임시 방편으로 문제를 해결한 특수 사례</li><li id="700f">상태 공간의 급증</li></ul><p id="7afe">복잡도는 개발자가 시스템을 이해하고 추론하기 어렵게 만들고 이는 곧 의도치 않는 결과 및 예기치 않은 상호작용을 간과하게 만든다. 우리는 <strong>복잡도를 줄이기 위해 노력</strong>해야하고 복잡도의 반대인 단순성을 시스템의 핵심 목표로 잡아야한다.</p><p id="f91e">단순하게 만들라는 말은 <strong>기능을 줄이라는 말이 아니다.</strong> 우발적(우연한) 복잡도(accidental complexity)를 줄이라는 말이다.</p><p id="49c7">우발적 복잡도를 제거하기 위한 최상의 도구는 <strong>추상화</strong>(abstraction)다. 좋은 추상화는 깔끔하고 직관적인 인터페이스 아래로 많은 세부 구현을 숨긴다.</p><p id="f58a">고수준 프로그래밍 언어는 기계언어, 시스템 호출을 숨긴 추상화이며 SQL은 디스크에 기록하고 메모리에 저장하는 복잡한 데이터 구조를 숨긴 추상화다. 물론 우리가 고수준 프로그래밍 언어를 쓴다는 것이 기계언어를 안쓴다는 말은 아니다. <strong>단지 직접 사용하지 않을 뿐이다.</strong> 직접 사용하지 않는 것은 우리 애플리케이션의 복잡도를 상당히 낮춰준다.</p><h2 id="88d7">변화에 쉽게 대응하게 만들자</h2><p id="1a74">새로운 지식을 배우거나, 비즈니스 우선순위가 바뀌거나, 새로운 기능 요청이 갑자기 들어오거나, 법적 또는 규제 요구사항이 변경되거나, 시스템 성장으로 인한 아키텍처 변화는 빈번하다.</p><p id="8b75">조직 프로세스 측면에서 애자일(agile) 작업 패턴은 위와 같은 잦은 변화에 적응하여 대응하기 쉽게 만들어준다. 이와 더불어 <strong>테스트 주도 개발(TDD)과 리팩토링(refactoring) 같이 자주 변화하는 환경에서 소프트웨어를 개발할 때 도움이 되는 기술 도구와 패턴</strong>을 같이 사용하자.</p></div><p id="c0ec">안타깝게도 애플리케이션을 신뢰할 수 있고 확장 가능하며 유지보수하기 쉽게 만들어주는 간단한 해결책은 없다. <strong>하지만 여러 애플리케이션에서 계속 재현되는 특정 패턴과 기술이 있다.</strong> 이후 이러한 데이터 시스템 몇 가지를 예제로 살펴보고 어떻게 작동하는지 분석해보자!</p></div>

Stories by allocProc on Medium

jaeyeong

‘데이터 중심 애플리케이션 설계 by Martin Kleppmann’ 책의 1장을 읽고 정리한 글입니다. 부족하다고 생각되는 부분은 내용을 덧붙였으며 제 개인적인 생각이 중간중간 첨가되어 있습니다.
The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free?
인터넷이 문제없이 너무 잘 동작하고 있다 보니 대부분의 사람은 이게 무슨 태평양 같은 천연 자연인 줄 안다. 이정도 규모의 기술이 이토록 오류가 없었던 적은 언제가 마지막일까?
- Alan Kay, Dr.Dobbs 저널 인터뷰에서(2012)
신뢰성, 확장성, 유지보수성의 의미가 무엇인지 명확히하고, 우리가 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 데이터 시스템을 구축하기 위해 할 수 있는 기초적인 노력들은 어떤게 있을지 살펴보자!
신뢰성
애플리케이션이 사용자가 기대한 기능을 수행하는 것을 ‘올바르게 동작함’이라 부른다면, 신뢰성이란 “무언가 잘못되더라도 지속적으로 올바르게 동작함” 정도로 이해할 수 있다.
무언가 잘못될 수 있는 일을 결함(fault)이라 부르는데, 이 결함을 예측하고 대처할 수 있는 시스템을 내결함성(fault-tolerant) 또는 탄력성(resilent)을 지녔다고 말한다. 그리고 결함은 장애(failure)와는 다른 의미이다. 결함은 사양에서 벗어난 시스템의 한 구성 요소로 정의되지만, 장애는 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우이다.
하드웨어 결함
하드웨어에 문제가 생기는 경우는 생각보다 흔하다. 하드디스크의 평균 장애 시간(mean time to failure, MTTF)은 약 10 ~ 50년으로 보고됐는데, 이말인 즉슨 10,000개의 디스크로 구성된 클러스터는 평균적으로 하루에 한 개의 디스크가 죽는다는 뜻이다.
이러한 하드웨어 결함에 대응하기 위한 노력으로 각 하드웨어에 중복성(redundancy)을 추가하는 방법이 일반적이다. 예시로 디스크는 RAID 로 구성하고 핫 스왑 가능한 CPU 그리고 예비 전원용 디젤 발전기를 갖추는 방법 등이 있다.
하지만 데이터의 양과 애플리케이션의 계산 요구가 늘어남으로 인한 장비 수의 증가는 하드웨어 결함율의 증가를 유발했고, 최근에는 하드웨어 중복성과 더불어 소프트웨어 내결함성 기술을 사용하여 중단시간을 최대한 줄이고 있다.
소프트웨어 오류
소프트웨어 결함을 유발하는 버그는 특정 상황에 의해 발생하기 전까지 오랫동안 나타나지 않는다. 특히나 예상하기 어려운 체계적 오류같은 경우 신속한 해결책이 없다. 소트프웨어 결함에 대응하기 위해 우리는 아래와 같은 여러가지 작은 일들에 많은 노력을 기울여야 한다.
시스템과의 상호작용에 대해 주의 깊게 생각하기
빈틈없는 테스트
프로세스 격리(process isolation)
죽은 프로세스의 재시작 허용
시스템 동작의 모니터링과 분석
확장성
시스템이 현재 안정적으로 동작한다고 해서 미래에도 안정적으로 동작한다는 보장은 없다.
애플리케이션의 성능 저하를 유발하는 흔한 이유 중 하나는 부하 증가이다. 확장성은 이렇게 증가한 부하에 대처하는 시스템의 능력을 의미한다. 하지만 “X는 확장 가능하다” 거나 “Y는 확장성이 없다” 와 같은 질문은 크게 의미가 없고, 대신에 “시스템이 특정 방식으로 커지면 이에 대처하기 위한 선택을 어떤 것이 있을까?” 와 “추가 부하를 다루기 위해 계산 자원을 어떻게 투입할까?” 와 같은 질문을 고려해보자.
트위터가 부하를 해결했던 방법
시스템의 현재 부하를 간결하게 기술하기 위해 보통 부하 매개변수(load parameter)를 사용한다. 적합한 매개변수는 시스템의 설계에 따라 달라지지만 웹 서버의 초당 요청 수, DB 의 읽기 대 쓰기 비율, 동시 활성 사용자 수, 캐시 적중률 등이 있다.
이에 대한 구체적인 예시로 2012년 11월에 공개된 트위터의 데이터를 살펴보자. 트위터의 주요 동작은 다음 두개이다.
트윗(tweet) 작성
사용자는 팔로워에게 새로운 메시지를 게시할 수 있다.(평균 초당 4.6k 요청, 피크 시 초당 12k)
홈 타임라인(timeline)
사용자는 팔로우한 사람이 작성한 트윗을 볼 수 있다.(초당 300k 요청)
이 두가지 동작의 구현법은 크게 두가지다.
사용자가 자신의 홈 타임라인을 요청하면 자신이 팔로우하는 모든 사람을 찾고, 이 사람들의 모든 트윗을 찾아서 합친 후 보여준다.
SELECT tweets.*, users.* FROM tweets
JOIN users ON tweets.sender_id = users.id 
JOIN follows ON follows.followee_id = users.id 
WHERE follows.follower_id = current_user
2. 각 사용자는 자신의 우편함처럼 개별 홈 타임라인 캐시를 유지한다. 사용자가 트윗을 작성하면 자신을 팔로우하는 사람들의 캐시에만 새로운 트윗을 삽입한다.
초창기 트위터는 1번 접근 방식을 사용했지만 점점 커져가는 홈 타임라인 질의 부하를 견디기위해 고군분투하다가 2번 접근 방식으로 전환했다. 평균적으로 트윗 게시 요청량이 홈 타임라인 읽기 요청량에 비해 수백 배 적기 때문에 2번 접근 방식이 훨씬 효율적이다.
하지만 2번 접근 방식은 트윗 작성이 부가 작업을 필요로 하고 이는 대부분의 사용자에게는 문제가 안되겠지만 팔로워가 굉장히 많은(3천만 이상) 특정 사용자의 경우 문제가 된다. 한번의 트윗 게시가 3천만 건의 쓰기 요청을 유발하기 때문이다.
이 때문에 트위터는 1번 접근 방식과 2번 접근 방식을 혼합한(hybrid) 방식으로 바꾸고 있다. 대부분의 사용자는 2번 방식으로 타임라인 캐시에 쓰지만 팔로워 수가 많은 소수의 사용자는 팬 아웃에서 제외하고 1번 방식을 사용한다.
성능을 기술하는 방법
시스템에 부하가 증가했을 때 어떤 일이 일어나는지를 설명하려면 성능을 수치화 해야한다.
보통 서비스 응답 시간의 산술 평균(arithmetic mean)을 살피지만 이는 그다지 좋은 지표가 아니다. 얼마나 많은 사용자가 실제로 지연을 경험했는지 알려주지 않기 때문이다.
그래서 일반적으로 백분위(percentile)을 사용하는 편이 더 좋다. 응답 시간 목록을 시간이 짧은 순으로 정렬한 후 산위 백분위를 살펴보자. 보통 95분위, 99분위, 99.9분위를 사용한다. 요청의 95%, 99%, 99.9% 가 특정 기준치 보다 더 빠르면 해당 특정 기준치가 각 백분위의 응답 시간 기준치가 된다. 예를 들어, 95분위 응답 시간이 1.5초라면 100개의 요청 중 95개는 1.5초 미만이고 5개는 1.5보다 더 걸린다는 뜻이다.
부하 대응 접근 방식
부하 매개변수가 어느 정도 증가 하더라도 좋은 성능을 유지하려면 어떻게 해야 할까?
보통 확장성과 관련해 다음 두 가지로 구분한다.
용량 확장(scale up)(= 수직 확장(vertical scale)) : 좀 더 강력한 장비로 이동하는 것
규모 확장(scale out)(= 수평 확장(horizontal scale)) : 다수의 낮은 사양 장비에 부하를 분산하는 것
강력한 고사양 장비는 매우 비싸기 때문에 대개 규모 확장을 피하지 못한다. 현실적으로 좋은 아키텍처는 실용적인 접근 방식의 조합이 필요하다.
일부 시스템은 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가할 수 있는데, 이를 탄력적(elastic)하다고 말한다.
resilient 와 elastic 은 다른 의미이다. 
두 영단어는 한글로는 '탄력적' 이라는 한 단어로 번역되지만 그 의미는 전혀 다르다. resilient 는 외부의 충격에 모양에 변형이 생겨도 금새 제 모양으로 돌아올 수 있음을 의미하고, elastic 은 자신의 모양을 자유롭게 늘리고 줄일 수 있음을 의미한다. 
예를 들면, 축구공은 resilient 하지만 elastic 하지는 않고 슬라임 장난감의 경우 elastic 하지만 resilient 하지는 않다고 말할 수 있겠다.
유지보수성
간단하고 이해하기 쉬운 시스템은 대개 복잡한 시스템보다 수정하기 쉽다.
소프트웨어 시스템상에서 일하는 많은 사람들은 소위 레거시 시스템 유지보수 작업을 좋아하지 않는다. 다른 사람의 실수를 고치거나 한물 간 플랫폼에서 작업해야하는 등의 불편하고 성가신 일이기 때문이다.
이런 유지보수에 들어가는 고통을 최소화하고 레거시 소프트웨어를 직접 만들지 않게끔 소프트웨어를 설계해야한다.
단순하게 만들자
프로젝트가 커짐에 따라 시스템은 매우 복잡하고 이해하기 어려워진다. 보통 아래와 같은 사례들이 복잡도를 급속도로 증가시키는 원인이다.
모듈 간 강한 커플링, 복잡한 의존성
일관성 없는 naming
임시 방편으로 문제를 해결한 특수 사례
상태 공간의 급증
복잡도는 개발자가 시스템을 이해하고 추론하기 어렵게 만들고 이는 곧 의도치 않는 결과 및 예기치 않은 상호작용을 간과하게 만든다. 우리는 복잡도를 줄이기 위해 노력해야하고 복잡도의 반대인 단순성을 시스템의 핵심 목표로 잡아야한다.
단순하게 만들라는 말은 기능을 줄이라는 말이 아니다. 우발적(우연한) 복잡도(accidental complexity)를 줄이라는 말이다.
우발적 복잡도를 제거하기 위한 최상의 도구는 추상화(abstraction)다. 좋은 추상화는 깔끔하고 직관적인 인터페이스 아래로 많은 세부 구현을 숨긴다.
고수준 프로그래밍 언어는 기계언어, 시스템 호출을 숨긴 추상화이며 SQL은 디스크에 기록하고 메모리에 저장하는 복잡한 데이터 구조를 숨긴 추상화다. 물론 우리가 고수준 프로그래밍 언어를 쓴다는 것이 기계언어를 안쓴다는 말은 아니다. 단지 직접 사용하지 않을 뿐이다. 직접 사용하지 않는 것은 우리 애플리케이션의 복잡도를 상당히 낮춰준다.
변화에 쉽게 대응하게 만들자
새로운 지식을 배우거나, 비즈니스 우선순위가 바뀌거나, 새로운 기능 요청이 갑자기 들어오거나, 법적 또는 규제 요구사항이 변경되거나, 시스템 성장으로 인한 아키텍처 변화는 빈번하다.
조직 프로세스 측면에서 애자일(agile) 작업 패턴은 위와 같은 잦은 변화에 적응하여 대응하기 쉽게 만들어준다. 이와 더불어 테스트 주도 개발(TDD)과 리팩토링(refactoring) 같이 자주 변화하는 환경에서 소프트웨어를 개발할 때 도움이 되는 기술 도구와 패턴을 같이 사용하자.
안타깝게도 애플리케이션을 신뢰할 수 있고 확장 가능하며 유지보수하기 쉽게 만들어주는 간단한 해결책은 없다. 하지만 여러 애플리케이션에서 계속 재현되는 특정 패턴과 기술이 있다. 이후 이러한 데이터 시스템 몇 가지를 예제로 살펴보고 어떻게 작동하는지 분석해보자!

신뢰할 수 있고, 확장 가능하며, 유지보수하기 쉽도록

댓글