MSA란?

가장 작은 단위의 서비스로 나눈 독립적으로 배포 가능한 서비스들로 구성하는 구조

MSA 장점

• 필요 서비스만 배포 가능
• 서비스 확장 가능 (Scale-out) + cloud
• 신기술 적용 용이

MSA 단점

• 성능하락  - 서비스간 통신에 많은 비용이 들어감
• 트랜잭션 - MS간의 통신으로 인한 트랜잭션 관리 힘듦

Monolithic -> MSA 로 바꾼 이유

• 플랫폼 사업 - 필요한 기능만 묶어서 제공  => 다양한 제품군으로 적용 가능
• 그로 인한 장점은 테스트/배포가 빨라지고, 추후 사업 진행 상황에 따른 scale-out 용이 (=cloud 장점)

MSA 의 구성

• 가장 작은 / 독립된 MS들로 서비스 구성 => DDD(도메인 주도 설계)
• MS가 많아서 찾기/관리 어려움
  • API Gateway (Zuul,Kong,nginx) : 외부에서 하나의 Endpoint만 알면 접근/관리 가능해서 편리 (+서비스 디스커버리,라우팅, 로드밸런싱, 보안)
    
    • Non java 서비스는 sidecar로 등록(polyglot) => Eureka는 java 어플
    • Sidecar :  MS의 트래픽을 관리하는 컨테이너를 생성해서 관리
• MS간의 통신
  • Service Mesh (Istio) : MS간 통신 담당,  API GW와 같은 역할이지만 MSA 내부에서 접근용도
    
    • API GW와 같은 역할이지만 둘 다 있는 게 효과적 : GW에 먼저 라우팅(인증,에지 라우팅) -> MESH 라우팅(관찰/제어) 점점 통합되는 중...
    • Backing Service (Kafka, RMQ, AMQ) :  큐를 이용한 비동기 통신
• 개발
  • CI/CD (Jenkins, Gitlab) : 개발 후 소스 통합/배포 자동화
  • 컨테이터 환경 (Docker, k8s) : 서비스들을 실행하는 환경을 관리
• 모니터링 및 서비스 관리
  • Telemetry (Zipkin+ Sleuth, Grafana, Prometheus, EFK, ELK ) : 서비스 모니터링 및 log/프로세스 추적 가능

Java에서 HashMap에 각각 a,b,c,d 순서대로 넣는다고 해서

a,b,c,d 순서대로 접근할 수는 없다

대신 순서대로 사용하려면 LinkedHashMap를 사용하자.

=> 순서가 있는 MAP

(상황)

jsp에서 스타일 적용확인후 ext-all.css에 적용했는데 적용이 안 됨

(해결 방법)

css를 참조하는jsp파일에서 link 경로를 캐싱해서 써서

-> ext.css?1234 이런식으로 수정

1. MSA 란?

"The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery."

small services(작은 서비스)
each running in its own process(스스로 실행 가능)
independently deployable(독립적 배포 가능)

-> 작고, 독립적으로 배포가능한 기능을 마이크로 서비스로 나누어, 독립적인 배포/ 다른 기술 스택을 사용 가능

2. 기존 Legacy(Monolithic)의 문제점

1. 조금만 수정해도 전체 배포 => (경험담) 배포&재시작만 10분
2. 서비스를 유연하게 가져가기 힘들다 (scale-out : 서버의 대수를 늘려 처리 능력 향상, scale-up은 서버 자체 용량등을 늘림)
3. 부분의 장애 -> 전체 장애
4. 서비스가 커질수록 영향도 파악, 시스템 구조 파악이 어려움

3. MSA의 장점 (독립+별도 배포)

1. 서비스별 배포 가능 (전체 서비스 중단 X )
2. 특정 서비스 확장 가능 (특히 클라우드 사용에 적합)
3. 장애 - 부분적 장애에 대한 격리가 수월
4. 신기술 적용에 유연
5. 서비스를 polyglot 하게 개발/운영 (=여러 언어를 사용)

사실상, 독립적으로 배포 할 수 있는게 가장 중요

• 독립 배포 가능 -> 전체 서비스 중단X없이 서비스별 배포 or 확장 가능
• 독립된 서비스라 장애가 격리되고, 신기술 적용하기 좋음

4. MSA의 단점

문제 설명

배열 array의 i번째 숫자부터 j번째 숫자까지 자르고 정렬했을 때, k번째에 있는 수를 구하려 합니다.

예를 들어 array가 [1, 5, 2, 6, 3, 7, 4], i = 2, j = 5, k = 3이라면

1. array의 2번째부터 5번째까지 자르면 [5, 2, 6, 3]입니다.
2. 1에서 나온 배열을 정렬하면 [2, 3, 5, 6]입니다.
3. 2에서 나온 배열의 3번째 숫자는 5입니다.

배열 array, [i, j, k]를 원소로 가진 2차원 배열 commands가 매개변수로 주어질 때, commands의 모든 원소에 대해 앞서 설명한 연산을 적용했을 때 나온 결과를 배열에 담아 return 하도록 solution 함수를 작성해주세요.

나의 풀이 (java)

import java.util.Arrays;
class Solution {
    public int[] solution(int[] array, int[][] commands) {
        int[] answer = new int[commands.length];

        for (int i = 0; i < commands.length; i++) {
            int[] tempArray = Arrays.copyOfRange(array, commands[i][0]-1, commands[i][1]);
            Arrays.sort(tempArray);
            answer[i] = tempArray[commands[i][2]-1];
            System.out.println("### result !!  i : "+i+"  ,answer  : "+answer[i]);
        }
        return answer;
    }
}

내가 사용한 방법

Array library를 이용한 array 복사 후 정렬 

문제를 보자마자 들었던 생각은 array를 복사하는 method가 생각나서 해당 method를 검색 (copyOfRange)

그리고 그 array를 정렬할 수 있는 method(sort)가 있는 것도 알고 있었기에 풀이 방법은 어렵지 않았으나,

for문에서 필요한 data를 꺼내올때 index에서 -1 하는 부분에서 좀 헷갈렸음

• copyOfRange() - array의 index를 통한 범위만큼 복사
• Arrays.sort() - array 정렬

다른 사람의 풀이

• 나와 같이 Array 라이브러리를 이용해 문제를 해결한 사람이 가장 많아 보임 (대부분 콘셉트가 비슷함)
• 거의 유일하게 다른 풀이법은 직접 퀵 정렬을 구현하는 풀이가 남달랐음
  • 실무에서의 문제풀이라면 대다수가 풀었던 방식이 좋았겠으나, 연습하는 동안은 이렇게 직접 sort를 구현해서 문제를 푸는 게 점수도 많이 받고, 진짜 알고리즘 연습도 될 것 같다  다시 풀어보자

느낀점

몇 년 만에 제대로 하려다 보니, 감도 익힐 겸 가벼운 마음으로 시작했는데, 생각보다 잘 기억나지 않는다..

• 정렬 별 개념과 시간 복잡도 공부하기 (버블, 선택, 퀵, 힙) - https://yabmoons.tistory.com/250

개발하다 보면 마음속으로 믿고 보는 블로거들이 몇몇 생기기 마련이다.

출근길에 우연히 유튜브에서 '기억보단 기록'을 이라는 기술 블로그의 주인의 인터뷰영상을 보았다.

매일 자면서 가던 출근길이었지만 잠이깨고, 머리를 한대 맞은것 처럼 많은 생각이 들게 됐다.

개발자로서의 성장

1. 지방대, 무스펙, 비전공자였지만 2년간 국비 학원을 다녀서 SI 직장에서 다니다가 한계를 느끼고 이직을 결심
2. 매일 아침 2시간동안 공부하고 주말에도 알고리즘, 전공지식에 대해 꾸준하게 공부해서 ZUM 검색포털로 이직
3. 거기서 혼자힘으로 만든 서비스의 코드 리뷰를 하는데, 기능이나 화면이 아닌 내부 성능(로직)을 가지고 평가를 받으면서 공부 방향이 많이 바뀌었고, 더 좋은 개발에 대해 고민을 많이 하셨다고 함.
   = 화면은 빨리 만드는건 당연한 거고, 더 좋은 구조로, 더 확장성 있는 구조로 만들 수 있을지에 대한 고민
4. 회사에서 강의를 하면서 해당 내용을 스터디, 블로그로 정리하면서 활동하다가 배달의 민족으로 스카우트
5. 원래는 트래픽이 많은 포털 사이트로 가기를 선호했지만, 한창 배민에 좋은 사람들이 많이 모이던 시절에 같이 일하고 싶어서 이직해서 오셨고 결국 배민이 짱 먹음ㅎㅎ

요즘들어 업무를 하다보면, 업무적인 실력은 좀 늘었지만, 과연 개발 실력은 ? 하는 생각이 든다
일인 만큼 업무처리는 당연히 빠르게 하고! 공부를 해야겠다는 생각이 부쩍 든다

더 좋은 소스& 확장하기 좋은 구조로 만들어야 겠다는 고민은 항상 가지고 개발하자!

전에는 원노트에 혼자만 정리했는데, 블로그에 쓰면서 한번 더 정리하고, 스터디도 병행하면서 더 내것으로 만들자

생각

1. 무라카미 하루키의 생활패턴 
   : 무조건 하루 4시간만 작업하는 게 꾸준히 오래 할 수 있는 습관을 만들기 좋다
2. 처음엔 5분짜리 시스템이 트래픽이 늘어서 16시간짜리 시스템이 됨
   그때는 그 방식이 맞았을 수도..
   이전 방식으로는 해결할 수 없을 때는 새로운 기술, 새로운 구조로 아예 새로 만들어야 함.
3. 그전까지의 무기로는 싸울 수 없는 상황 = 전쟁의 판도가 너무 빨리 바뀌므로
   또 언제 전쟁의 상황이 바뀔지 모르니 남는 시간에 다른 무기에 대해 항상 공부
4. 잡담이 경쟁력 : 옆에 자리가 있으면 항상 의자를 두고 누가 오든 대화를 해야 함
   처음엔 힘들었는데 바로 피드백이 오기 때문에 훨씬 생산성이 좋다

IT업계는 전쟁의 무기가 계속 바뀌기 때문에, 꾸준히 개인적으로 공부하는 시간을 가져야만 한다!!

집념

1. 1일 1 커밋 운동
   : 업무시간외에도 사이드 프로젝트로 개인 공부를 하고 있음을 증명
   심지어 갑상선암으로 입원하는 기간에도 예약을 걸어서 3년 동안 유지
2. 하루에 80% 정도의 목표치만 채우고 나머지 20%는 내가 하고 싶은걸 하자
   그게 쉬지 않고 스트레스를 크게 받지 않고, 번아웃이 오지 않는다
3. 개발을 잘하는 유형은 2가지
   사냥개처럼 어떻게든 결과를 물어오는 집요함
   or
   글 잘 쓰는 사람처럼 당연히 있어야 할 곳에 누구나 이해할 수 있게 코드를 작성
4. 전체적인 인생은 제멋대로! 그때그때 하고 싶은걸 저지르자! 그게 좋은 기회가 될 수 있다
   목표는 내 범위에서만 나옴 => 목표를 정하면 다른 델 안 보니까 내가 생각 한길만 가게 됨

이 영상을 보고 매일 업무 처리만 급급하게 할게 아니라
여유가 있다면 20%의 남은 시간에 능동적으로 필요한 서비스를 개발&적용할 수 있도록 고민하자

소스코드는 누가 봐도 이해할 수 있게! 당연한 위치에 당연하게 위치할수 있게!!

너무 재지말고 하고싶은걸 하면서! 목표도 계속 수정하면서 재밌게 살자

끝.

멀리서 유튜브도 같이 응원하겠읍니다. 화이팅!

오라클에서 특정 날짜 사이가 며칠인 구하는 방법

1. Contract 테이블의 StartTime과 오늘 사이에 며칠이 지났는지 확인

SELECT
	TRUNC(SYSDATE - TO_DATE(StartTime,'YYYYMMDDHHMISS'))
FROM
	CONTRACT

2. Contract 테이블의 Duration에 지정한 날짜가 얼마나 남았는지 확인

(ex. Duration:30일, StartTime이 7일전 => 유효기간은 23일 남음 )

SELECT
	Duration - TRUNC(SYSDATE - TO_DATE(StartTime,'YYYYMMDDHHMISS')) Remaining_Days
FROM
	CONTRACT

데이터가 많아질수록 해당 데이터를 검색해서 출력해주는 퍼포먼스가 중요합니다.

같은 내용을 가져오더라도, 쿼리를 어떻게 작성했는지에 따라 쿼리의 성능이 차이가 생기겠죠.

데이터가 많아질수록 그 영향은 더 커질 겁니다.

그렇다면 쿼리를 작성할 때 기본적으로 고려하면 좋은 점들을 쿼리 초보자 입장에서 정리해보았습니다.

1. Select * 보다는 필요한 컬럼만 불러온다
   => 서비스에서 나중에 쓰일 것 같은 컬럼을 일단 가져오고 서비스에서는 쓰지 않는 경우가 종종 있습니다.
   => 하지만, 모든 컬럼을 조회하면 그만큼 DB에 부담을 주기 때문에 필요한 컬럼만 가져오는 게 성능에 좋습니다.
2. Index를 타고 있는지 확인하자
   => 정의된 index가 있는지, 있다면 index를 탈수 있도록 where절의 조건과 순서를 조정해서, index를 활용하는 편이 당연히 성능이 좋겠죠.
3. 쿼리의 실행 순서를 기억하자.
   => From, On, Join, Where, Group, Having, Select, Order by 순서대로 실행됩니다.
   => 따라서 From, On, Join, Where, Having 순으로 Query가 확장될 때, 해당하는 대상을 줄여줄 수 있도록 작성해야 합니다.
   => 같은 조건이라도, having에 적용할 때보다, where절에서 필요한 만큼만 가져오는 게 성능이 더 좋다고 합니다.
   그리고, 쿼리의 실행 순서가 ALIAS 순서이니까 알아두는 게 좋겠죠,
   (From 절에서 alias 하면 where절에서 사용 가능, Select에서 alias하면 where 절에서 사용 불가능)
4. Join 되는 결과 테이블의 크기를 줄여야 한다.
   => JOIN시 on절에 의해 추려지는 데이터는 메모리에서 관리하게 되므로, on으로 추릴 때 이왕이면 데이터의 중복이나, 양을 최대한 줄일 수 있도록 설정해야 성능에 도움이 된다고 합니다.
   =>그래서 Left outer join 보다는 inner join을 사용하자
   같은 데이터를 뽑아낼 거면 Left outer join으로 null로 join 되는 걸 가져온 후 다시 제외하는 것보다,
   한 번에 inner join을 사용하는 게 성능상 좋겠죠.
5. Where절에서 데이터 타입을 일치해야 한다.
   => Where id = '1'과 Where id = 1 이 있는데, id의 데이터 타입이 문자형이라면 인덱스를 활용할 수 있으므로 더 성능이 좋다고 합니다.
6. Distinct는 자제하자
   =>  Distinct는 정렬에 따른 성능에 하락이 발생하기 때문에 필요한 경우에만 사용하는 게 좋다고 합니다.
7. Union 보다 Union all을 사용하자
   => Union 은 중복 검사를 하기 때문에 성능 차이가 꽤 크게 납니다... 참고!

다시 한번 정리하면서 느낀거지만..

DB도 결국 프로세스 대로 실행이 되기 때문에.

필요한 만큼만, 최대한 사이즈를 줄여서 가져오는게 성능상 좋은것 같네요.

이상입니다 :)