일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Elasticsearch
- 엘라스틱서치
- 개발
- 코딩
- 자바
- API
- Baekjoon
- 그리디알고리즘
- 코드
- 알고리즘
- framework
- 애자일
- 개발자
- cleancode
- 코딩테스트
- db
- ES
- 애자일프로그래밍
- 그리디
- 클린코드
- JPA
- 백준
- 읽기쉬운코드
- database
- Java
- 데이터베이스
- Spring
- 스프링
- 애자일기법
- 프레임워크
- Today
- Total
목록전체 글 (139)
시뻘건 개발 도전기
Oracle에서 제공하는 java 1.8 docs를 살펴보면 상당히 많은 interface가 있다. 그 중에서 Function interface를 살펴보자. @FunctionalInterface public interface Function { R apply(T t); // ... } 이 인터페이스는 apply라는 하나의 abstract method(FunctionalInterface annotation)를 가진다. 보면 알 수 있겠지만, T 타입의 parameter를 받아 R 타입의 값을 리턴하는 메소드다. public class Exercise { public static void main(String[] args) { Function myEx = new Func(); System.out.print..
나는 java를 공부하고 사용할 때 "객체지향적으로 코딩해야한다!"(OOP)라는 생각으로 접근한다고 주입식 교육(?)을 받아왔다. 그런데 java1.8 부터 바뀐 많은 부분 중에 가장 대표적으로 "함수형 프로그래밍 기법"이 도입되었다. 차이점을 예를들어 이야기 하자면 아래와 같다. ex) 각 유저의 정보를 갖고 있는 유저 리스트가 있을 때, unvalified email을 추출한다. OOP 이메일을 담을 리스트 A 선언 반복문을 돌면서 email validation check unvalified email를 A에 추가 함수형 프로그래밍 user list에서 unvalified email을 갖고있는 유저만 추출 추출된 user list에서 email만을 리스트로 추출 접근 방식에 차이점이 보인다. OOP의..
앞서 언급한 분산의 포인트는 OS 캐시 활용과 인덱스(색인) 사용 그리고 확장을 고려하여 시스템을 설계하는 것이다. (MySQL은 물론이고 RDBMS는 인덱스를 생성하고 그로 인해 빠르게 데이터를 검색할 수 있는 구조가 마련되어 있다.) 보통 신규 프로젝트를 개발하게 될 때면 테이블 스키마를 그려하고 create table 쿼리로 테이블을 생성할 수 있다. 이 부분이 큰 규모일 수록 중요한 부분이 생기는데, 스키마를 얼마나 고려했는지, 분산과 확장성을 얼마나 고려했는지에 따라서 데이터가 큰 차이로 증감할 수 있다는 것을 이전 포스팅을 통해 알게되었다. 따라서 대량의 데이터가 저장되는 테이블일 수록 래코드가 최대한 작아지도록 컴팩트하게 설계되어야 한다. MySQL의 인덱스 경우에는 빠른 탐색을 위해 B트리..
지금까지 캐시가 I/O에 미치는 영향에 대해서 알아 보았다. (학교에서 language를 배울 때 캐시를 전혀 알려주지 않고 컴퓨터 개론 등의 수업에서만 캐시를 간략하게 언급하고 지나갔던 기억이 난다. 정작 현업에서는 캐시를 아주 잘 사용하고 있고 꼭 필요한 부분에서 어떤 방식으로 캐시를 사용할지에 대해 명확하게 정의하여 사용한다.) 데이터 처리 시 압축해서 저장해두면 디스크 내용을 그대로 캐싱할 수 있고, 데이터의 규모보다 물리 메모리가 더 클 때 전부 캐싱할 수 있다는 사실을 알게 되었다. 그렇다고 메모리를 대규모에 따라 계속해서 늘리기만 할 수 없다. (경제적인 비용과 밸런스 등 고려) 이럴 때 "복수 서버 확장"이 필요할 수도 있다. 어느정도 성장한 기업의 서버는 대부분 이 방안을 채택하여 사용할..
데이터를 보다 효율적으로 처리하기 위한 많은 방법이 있지만 그 중에서 OS 캐시를 살펴보려한다. OS캐시는 어떻게 동작하며 만약 제대로 처리되지 않았을 때 분산에 대해서 어떻게 고려해야하는지 알아본다. OS는 메모리를 이용해서 디스크 액세스를 줄이는데, 그 원리가 OS 캐시다. 리눅스의 경우에는 페이지 캐시나 파일 캐시, 버퍼 캐시라고 하는 캐시 구조를 가지고 있다. OS는 가상 메모리 구조를 가지고 있으며 이는 흔히 말하는 '스왑'과 다른 말이다. 스왑은 물리 메모리가 부족할 때 2차 기억장치를 메모리로 간주해서 외형상의 메모리 부족을 해소하는 원리를 말한다. 가상 메모리 구조를 기반으로하는 페이징 구조는 논리 어드레스를 물리 어드레스로 변환한다. 물리적인 하드웨어를 OS에서 추상화하기 위해서 '가상 ..
트래픽이 증가하게되면서 우리는 장비의 성능을 끌어올리거나 개수를 늘릴 수 있고, application의 캐시 등 성능개선, DB서버의 I/O 최소화 등 작업을 진행하면서 기본적으로 알아야할 사항들이 상당히 많다. 일전에 언급했던 스케일업과 스케일아웃이 많이 볼 수 있는 대응 방법인데, 보통은 스케일아웃을 많이 채택한다. 그 이유는 많은 것들이 있을 수 있지만 웹 서비스에 적합하고 비용이 저렴하며 시스템 구성에 유연성이 있다는 점이 높게 평가되고 있다. 스케일아웃의 특징은 하드웨어를 횡으로 전개해서 CPU 부하의 확장성을 확보하기 쉽다. 하지만 DB 서버 측면에서는 I/O 부하가 잦게 일어난다. [그림 1]을 보면 알 수 있듯이 프록시의 요청이 AP 서버를 거처 DB에 도달해서 DB측에 I/O가 발생한다...
대규모 데이터의 처리는 왜 소규모 데이터보다 어려운가? 데이터는 디스크에서 로드해서 메모리에 저장한다고 이전 토픽에서 언급한 바있다. 속도를 따지고 보자면 메모리가 디스크보다 훨신 빠르기 때문에 메모리에서 계산해야 빠른 결과를 볼 수 있는 것이다. 이 부분이 포인트가 된다. 메모리는 비교적 디스크보다 크기가 작기 때문에 대규모 데이터를 처리하기엔 적합하지 않다. 그러나 속도 측면에서 볼 때는 디스크보다 메모리에서 계산하는 것이 효율적이다. 이 사실에서 알 수 있는 부분은 메모리 내에서 계산할 수 없는 정도의 데이터라면 디스크에 두고 특정 데이터를 검색한다는 것이다. 디스크는 왜 메모리보다 느린가? 디스크는 물리적인 탐색을 통해 검색하기 때문에 속도에 영향이 있을 수 있다. 디스크에는 헤드라고 하는 녀석과..
동기 지난번에 개발자라면 누구나 꿈꾸지만 높은 연봉만큼 일이 너무 많다는 소문이 자자한 기업 xx에서 오퍼가 왔다. 그 곳으로 이직할 생각은 없었으나, 해당 기업 면접을 한 번도 본적이 없었기 때문에 그 기업은 어떤 것에 관심이 있고 어떤 인재를 추구하는지 궁금해서 면접을 보았다. 약 1시간 30분동안 대용량 트래픽과 그에 따른 WAS 혹은 DB서버, 앱서버 관리 및 장애대응에 대한 이야기로 가득했다. 개발 경력 4년동안 운영업무와 DB관리를 해본적이 없는 나는 굉장히 창피할정도로 무식(?)했다. 해당 포지션이 데브옵스가 아닌데도 개발적인 내용보다 운영 내용이 많았던 것 같다. 면접이 끝나고 운영 지식을 쌓아볼까 해서 책을 구매하여 매일 한 챕터씩 읽기로 했다. 본 도서는 일본기업 "하테나"에서 근무했던..