시뻘건 개발 도전기

지금까지 캐시가 I/O에 미치는 영향에 대해서 알아 보았다. (학교에서 language를 배울 때 캐시를 전혀 알려주지 않고 컴퓨터 개론 등의 수업에서만 캐시를 간략하게 언급하고 지나갔던 기억이 난다. 정작 현업에서는 캐시를 아주 잘 사용하고 있고 꼭 필요한 부분에서 어떤 방식으로 캐시를 사용할지에 대해 명확하게 정의하여 사용한다.) 데이터 처리 시 압축해서 저장해두면 디스크 내용을 그대로 캐싱할 수 있고, 데이터의 규모보다 물리 메모리가 더 클 때 전부 캐싱할 수 있다는 사실을 알게 되었다. 그렇다고 메모리를 대규모에 따라 계속해서 늘리기만 할 수 없다. (경제적인 비용과 밸런스 등 고려) 이럴 때 "복수 서버 확장"이 필요할 수도 있다. 어느정도 성장한 기업의 서버는 대부분 이 방안을 채택하여 사용할..

트래픽이 증가하게되면서 우리는 장비의 성능을 끌어올리거나 개수를 늘릴 수 있고, application의 캐시 등 성능개선, DB서버의 I/O 최소화 등 작업을 진행하면서 기본적으로 알아야할 사항들이 상당히 많다. 일전에 언급했던 스케일업과 스케일아웃이 많이 볼 수 있는 대응 방법인데, 보통은 스케일아웃을 많이 채택한다. 그 이유는 많은 것들이 있을 수 있지만 웹 서비스에 적합하고 비용이 저렴하며 시스템 구성에 유연성이 있다는 점이 높게 평가되고 있다. 스케일아웃의 특징은 하드웨어를 횡으로 전개해서 CPU 부하의 확장성을 확보하기 쉽다. 하지만 DB 서버 측면에서는 I/O 부하가 잦게 일어난다. [그림 1]을 보면 알 수 있듯이 프록시의 요청이 AP 서버를 거처 DB에 도달해서 DB측에 I/O가 발생한다...

대규모 데이터의 처리는 왜 소규모 데이터보다 어려운가? 데이터는 디스크에서 로드해서 메모리에 저장한다고 이전 토픽에서 언급한 바있다. 속도를 따지고 보자면 메모리가 디스크보다 훨신 빠르기 때문에 메모리에서 계산해야 빠른 결과를 볼 수 있는 것이다. 이 부분이 포인트가 된다. 메모리는 비교적 디스크보다 크기가 작기 때문에 대규모 데이터를 처리하기엔 적합하지 않다. 그러나 속도 측면에서 볼 때는 디스크보다 메모리에서 계산하는 것이 효율적이다. 이 사실에서 알 수 있는 부분은 메모리 내에서 계산할 수 없는 정도의 데이터라면 디스크에 두고 특정 데이터를 검색한다는 것이다. 디스크는 왜 메모리보다 느린가? 디스크는 물리적인 탐색을 통해 검색하기 때문에 속도에 영향이 있을 수 있다. 디스크에는 헤드라고 하는 녀석과..

동기 지난번에 개발자라면 누구나 꿈꾸지만 높은 연봉만큼 일이 너무 많다는 소문이 자자한 기업 xx에서 오퍼가 왔다. 그 곳으로 이직할 생각은 없었으나, 해당 기업 면접을 한 번도 본적이 없었기 때문에 그 기업은 어떤 것에 관심이 있고 어떤 인재를 추구하는지 궁금해서 면접을 보았다. 약 1시간 30분동안 대용량 트래픽과 그에 따른 WAS 혹은 DB서버, 앱서버 관리 및 장애대응에 대한 이야기로 가득했다. 개발 경력 4년동안 운영업무와 DB관리를 해본적이 없는 나는 굉장히 창피할정도로 무식(?)했다. 해당 포지션이 데브옵스가 아닌데도 개발적인 내용보다 운영 내용이 많았던 것 같다. 면접이 끝나고 운영 지식을 쌓아볼까 해서 책을 구매하여 매일 한 챕터씩 읽기로 했다. 본 도서는 일본기업 "하테나"에서 근무했던..

달달달 외우는 것을 싫어하고 암기력도 좋지 않아서 이과를 선택했다. 뭘 외우고 있는가? 외울 시간에 이해를 하려고하고 적용을 해보려고 해보자. 이전 글을 참고하자. 꼭. #1 : RESTful API 개발자라면 RESTful에 대해 한 번이라도 들어 보았을 것이라 생각이 든다. 그러나 정작 "RESTful이 뭐야?"라고 물었을 때 진정으로 정답을 말하기 애매한 것 같다. 실제로 사내 프로젝트로 서버 개발을 했을 때 R.. dotori.ga 위 내용에 덧붙여 더 깊게 알아보자. REST의 구성 요소는 다음과 같다. 표현방식 : HTML 등 식별자 : URI 행위 : HTTP REST architecture style Server - Client 자원 제공을 server, 요청을 client가 한다. ser..