Monolithic – Dreaming for the Future 영원한 개발자를 향해서. 월, 13 1월 2025 13:44:09 +0000 ko-KR hourly 1 https://wordpress.org/?v=4.7 108384747 개발 모델: 프로젝트 조직 vs. 서비스 조직 /index.php/2021/12/03/project-vs-service/ Fri, 03 Dec 2021 10:23:21 +0000 /?p=884

Continue reading ‘개발 모델: 프로젝트 조직 vs. 서비스 조직’ »]]> 시스템을 개발하는 방식에는 여러가지가 있을 수 있다. 가장 크게는 남이 개발해주는게 있고, 내가 개발하는게 있겠다. 우리나라에서 소위 SI(혹은 외주)라고 부르는 방식이 남이 개발해주는 방식이다. 이런 개발을 “프로젝트” 방식이라고 한다. 대체로 요구 사항과 기간을 개발사에게 전달한다. 물론 돈과 함께. 개발사는 최대한 맞춰 개발하고 그 결과를 전달한다. 물론 필요하면 설치와 운영에 필요한 사항까지 잘 마무리해야지. 그리고 남은 돈을 받는다! 돈을 받으면? 끝이지! 개발하는 사람의 책임은 여기서 끝난다. (물론 구질구질하게 붙잡고 늘어지는 경우가 매우 빈번하다는…)

 

내(회사)가 직접하는 시스템 개발 방법은 다른가?

내(회사)가 개발해서 내(회사)가 사용할 시스템을 만드는 개발 그 자체는 남이 만들든 내가 하든 비슷하다. 다름은 개발이 끝난 후 사용하고 고치기 시작할 때 생긴다.

자체적으로 개발할 진행할 때도 마찬가지로 남이 하는 프로젝트 방식을 쓸 수 있다. 이 방식은 앞서 언급한 바와 같이 “끝”이 있다. 끝나면 개발을 진행하던 사람들은 보통 흩어지고, 시스템은 운영 전담 조직이 맡는다. 운영 과정에서 생기는 자잘한 수정 사항들은 운영 선수들이 직접 고치기도 한다. 하지만 시간이 흐르고 자잘하지 않은 문제점들이 쌓이면? 결국 남들이 하듯이 “고도화” 프로젝트 후, “차세대” 프로젝트에 돌입한다. 대체로 새로운 선수들이 새로운 마음 가짐으로 “고도화” 혹은 “차세대”를 진행한다. Original 프로젝틀 진행했던 사람들이 참여할 수 있다면 운이 좋은 편이다.

현재 사용중이지만 과거에 끝나버린 프로젝트를 새로운 마음으로 다시 한다는 건 생각 이상의 비용을 요구한다. 혹자는 소스도 가지고 있고, 개발자도 있는데 그게 왜 문제인지 질문할지 모른다. 신이 내려주신 “망각”이라는 재능을 잊지 말자. 이외에도 개발하던 환경이 홀라당 날라가버렸을 수도 있다. 혹은 믿었던 소스가 알고보니 스파게티 짜장이었을 수도! 사실 이게 더 큰 비용 유발자일수도 있다. 끝내는데 급급한 경우가 많을수록 파스타/짜장면 잔치가 벌어질 가능성이 더 많으니까.

 

남이 아닌 내가 하는 방식은 그럼 뭘까?

개발하면서 운영하고, 운영하면서 또 개발하는 방식이다. “끝”없이 계속 개발하는 것이다.

개발이 끝없이 이어지는 경우에는 다른 관점이 필요하다. 어제 작성한 코드를 가지고 오늘 작업하고 내일 또 이어져야 한다. 결국 코드가 이뻐야 한다. 지속 가능하고 관리 가능한 코드를 뽑아야 한다. 마찬가지로 이번주에 고친 코드를 배포해야하고, 또 다른 개발이 이어져야 한다. 손쉽게 배포할 수 있는 환경이 있어야 한다. 분리된 독립적인 개발 환경을 사용할 수 있어야 하고, 또 손쉽게 개발 환경을 만들 수 있어야 한다. 나만 개발하는게 아니니까.

고치다보면 고장나기 쉽다. 어찌되든 실수는 피할 수 없다. 그리고 실수는… 비난하지 말자. 사람은 실수를 통해서 배우고, 성장한다. 그럼에도 서비스는 계속되어야 하는데… 가장 좋은 방법은 고장의 영향도를 최소화하는 것이다. 서비스 전체가 죽어버리는 것보다도 절반은 살아남는게 그나마 다행이지 않을까? 그래서 요즘 마이크로 서비스 아키텍처가 대세가 된게 아닐까 싶기도 한다. 잘게 쪼갠 협력 모델이면 그나마 장애의 영향 범위를 제한시킬 수 있으니까.

그럼 “끝”없는 개발은 언제 끝나는 거지? 마침표를 찍는 지점은 더 이상 이 기능(서비스)를 사람들(고객)이 찾지 않을 때다. 이 지점에서 서비스는 종료되고, 시스템은 폐기된다. 버뜨… 서비스는 없어지는 경우는 그닥 없다. 다만 마이크로한 기능이 사라질 뿐이지. 소위 현대적인 방법으로 시스템이 만들어졌다면, 없어지고 새로 태어나는게 일상 다반사여야 한다.

어떤게 더 좋은 모델일까?

사실 정답은 없다. 다만 서비스를 제공하는 회사/조직 안에 답이 있는 것 같다. 규모가 있고 결과론을 중시하는 조직 스타일이라면 프로젝트 방식이 적합한 개발 모델일 수 있다. 능력있는 개발 집단을 구성하고 수행해야할 프로젝트를 빠른 속도로 개발한다. 안정화 후 별도 팀이 이를 넘겨 받아 이후 운영한다. 능력자들로 구성된 강력한 개발 파워를 최대화할 수 있고, 적절한 운영 조직을 갖춘다면 안정된 체계를 완성할 수 있다.

그러나 도메인에 대한 지식을 개발자의 쌓을 수 없다는 치명적인 단점이 있다. 또 개발이 기획서 중심으로 나갈 수 밖에 없다. 개발하는 사람들이 그 도메인에 대해서 모르니 “상세한 과업 지시서“가 있어야 개발이 가능하다. 때문에 중간에 뭔가가 바뀌는 걸 극히 싫어할 뿐만 아니라 이런 경우가 발생하면 차세대 시스템용 기획서가 나와야 할지도 모른다. 능력자분들이 개발만을 특히 좋아하는 개발자들이라면, 되려 이 방식을 매우 선호할 수 있다. 이 방식에서 마이크로 서비스 아키텍쳐? 명확하다면 Monolithic이 답이 아닐까? 굳이 쪼갤 필요가…

서비스 방식의 개발은 그래서 소규모 조직에서 작게 시작해서 점진적으로 성장하는 환경에서 활용될 수 있다. 작은 조직에서 작은 규모로 개발을 시작한다. 고객의 피드백에 따라 빠르게 변화를 가져간다. 빠른 변화를 위해서 제품의 핵심을 명확히 한다. 각각의 구성 요소들을 개별적인 소규모 서비스로 정의하고 개발한다. 이래야 빠른 피벗(Pivot)을 위해 뭘 가져가고, 뭘 버릴지 빠르게 판단할 수 있기 때문이다.

문제가 없는 건 아니다. 이 방식도 많은 중복이 있다. 마이크로 서비스 구조라고 하더라도 각각이 독립적인 어플리케이션이 되야하기 때문에 Server, Application Framework, CI/CD 등등의 중복 투자가 필요하다. 이런 Redundancy를 관리하기 위한 Governance 조직도 필요하다. 그래야 어느 정도의 일관성이라는 것을 유지할 수 있으니까. 또한 잘게 쪼개져있다보니 서비스적으로 업무적으로 조율이 있어야 한다. 누가 어느 기능을 개발하지, 혹여라도 이미 다른 마이크로서비스에서 개발된 기능을 중복해서 개발하고 있는건 아닌지 역할에 따른 기능을 매번 확인하고 확인해야 한다. 개발자 입장에서 또 다른 문제는 하나의 도메인에 개발자가 종속된다는 것이다. 좀 다른 일좀 해보고 싶더라도 업무에 깊숙히 들어가있으면 빠져나갈 도리가 없는 경우가 왕왕 있다.

그래서 나는?

나한테 질문한다면 “고객/사용자“를 먼저 생각할 것이다. 그럼 서비스 중심 개발이 답이다. 고객과 사용성에 빠르게 반응할 수 있기 때문이다.

끝없는 단거리 경주를 언제까지 해야할지 모르지만, 사용자에게 사용자를 위한 서비스 시스템을 만든다면 이 방법이 정답이다!

– 끝 –

]]> 884 Spring batch를 Parallel로 돌려보자 /index.php/2017/12/19/spring-batch-parallel-execution/ Mon, 18 Dec 2017 22:52:00 +0000 /?p=489

Continue reading ‘Spring batch를 Parallel로 돌려보자’ »]]> Monolithic 아키텍처 환경에서 가장 잘 돌아가는 어플리케이션 가운데 하나가 배치 작업이다. 모든 데이터와 처리 로직들이 한군데에 모여있기 때문에 최소한의 비용으로 빠르게 기능을 돌릴 수 있다. 데이터 존재하는 Big Database에 접근하거나 Super Application Server에 해당 기능의 수행을 요청하면 된다. 끝!!!

하지만 요즘의 우리가 개발하는 어플리케이션들은 R&R이 끝없이 분리된 Microservices 아키텍처의 세상에서 숨쉬고 있다. 배치가 실행될려면 이 서비스, 저 서비스에 접근해서 데이터를 얻어야 하고, 얻은 데이터를 다른 서비스의 api endpoint를 호출해서 최종적인 뭔가가 만들어지도록 해야한다.  문제는 시간이다!

마이크로서비스 환경에서 시간이 문제가 되는 요인은 여러가지가 있을 수 있다. 배치는 태생적으로 대용량의 데이터를 가지고 실행한다. 따라서 필요한 데이터를 획득하는게 관건이다. 이 데이터를 빠르게 획득할 수 없다면 배치의 실행 속도는 느려지게 된다. 다들 아는 바와 같이 마이크로서비스 환경이 일이 돌아가는 방식은 Big Logic의 실행이 아니라 여러 시스템으로 나뉘어진 Logic간의 Collaboration이다. 그리고 이 연동은 대부분 RESTful을 기반으로 이뤄진다.

RESTful이란 뭔가? HTTP(S) over TCP를 기반으로 한 웹 통신이다. 웹 통신의 특징은 Connectionless이다. (경우에 따라 Connection oriented) 방식이 있긴 하지만, 이건 아주 특수한 경우에나 해당한다. TCP 통신에서 가장 비용이 많이 들어가는 과정은 Connection setup 비용인데, RESTful api를 이용하는 과정에서는 API Call이 매번 발생할 때마다 계속 연결을 새로 맺어야 한다. (HTTP 헤더를 적절히 제어하면 이를 극복할 수도 있을 것 같지만 개발할 때 이를 일반적으로 적용하지는 않기 때문에 일단 스킵. 하지만 언제고 따로 공부해서 적용해봐야할 아젠다인 것 같기는 하다.)

따라서 Monolithic 환경과 같이 특정 데이터베이스들에 연결을 맺고, 이를 읽어들여 처리하는 방식과는 확연하게 대량 데이터를 처리할 때 명확하게 속도 저하가 발생한다. 그것도 아주 심각하게.

다시 말하지만 배치에서 속도는 생명이다. 그러나 개발자는 마이크로서비스를 사랑한다. 이 괴리를 맞출려면…

  1. 병렬처리를 극대화한다.
  2. 로직을 고쳐서 아예 데이터의 수를 줄인다.

근본적인 처방은 두번째 방법이지만, 시간이 별로 없다면 어쩔 수 없다. 병렬 처리로 실행하는 방법을 쓰는 수밖에…
병렬로 실해시키는 가장 간단한 방법은 ThreadPool이다. Springbatch에서 사용 가능한 TaskExecutor 가운데 병렬 처리를 가능하게 해주는 클래스들이 있다.

  • – 필요에 따라 쓰레드를 생성해서 사용하는 방식이다. 연습용이다. 대규모 병렬 처리에는 비추다.
  • – 쓰레드 제어를 위한 몇 가지 설정들을 제공한다. 대표적으로 풀을 구성하는 쓰레드의 개수를 정할 수 있다!!! 이외에도 실행되는 작업이 일정 시간 이상 걸렸을 때 이를 종료시킬 수 있는 기능들도 지원하지만… 이런 속성들의 경우에는 크게 쓸일은 없을 것 같다.

제대로 할려면 ThreadPoolTaskExecutor를 사용하는게 좋을 것 같다. 병렬 처리 가능한 TaskExecutor들은  인터페이스 페이지를 읽어보면 알 수 있다.

@Bean(name = "candidateTaskPool")
public TaskExecutor executor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(CORE_TASK_POOL_SIZE);
    executor.setMaxPoolSize(MAX_TASK_POOL_SIZE);
    return executor;
}

이 메소드 정의를 Job Configuration 객체에 반영하면 된다. ThreadPool을 생성할 때 한가지 팁은 Pool을 @Bean annotation을 이용해서 잡아두는게 훨씬 어플리케이션 운영상에 좋다. 작업을 할 때마다 풀을 다시 생성시키는 것이 Cost가 상당하니 말이다. 어떤 Pool이든 매번 만드는 건 어플리케이션 건강에 해롭다.

전체 배치 코드에 이 부분이 어떻게 녹아들어가는지는 아래 코드에서 볼 수 있다.

@Configuration
@EnableBatchProcessing
    public class CandidateJobConfig {
    public static final int CORE_TASK_POOL_SIZE = 24;
    public static final int MAX_TASK_POOL_SIZE = 128;
    public static final int CHUNK_AND_PAGE_SIZE = 400;

    @Bean(name = "candidateTaskPool")
    public TaskExecutor executor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(CORE_TASK_POOL_SIZE);
        executor.setMaxPoolSize(MAX_TASK_POOL_SIZE);
        return executor;
    }

    @Bean(name = "candidateStep")
    public Step step(StepBuilderFactory stepBuilderFactory,
                     ItemReader<User> reader,
                     ItemProcessor<User, Candidate> processor,
                     ItemWriter<Candidate> writer) {
        return stepBuilderFactory.get("candidateStep")
                                 .<User, Candidate>chunk(CHUNK_AND_PAGE_SIZE)
                                 .reader(candidateReader)
                                 .processor(candidateProcessor)
                                 .writer(candidateWriter)
                                 .taskExecutor(executor())
                                 .build();
    }

이렇게 하면 간단하다.

하지만 이게 다는 아니다. 이 코드는 다중 쓰레드를 가지고 작업을 병렬로 돌린다. 하지만 이 코드에는 한가지 문제점이 있다. 살펴보면 Chunk라는 단위로 작업이 실행된다는 것을 알 수 있다. Chunk는 데이터를 한개씩 읽는게 아니라 한꺼번에 여러 개(이 예제에서는 CHUNK_AND_PAGE_SIZE)씩 읽어 processor를 통해 실행한다. 배치의 실제 구현에 대한 이해나 고려가 필요하다.

Chunk를 사용해서 IO의 효율성을 높이는 방법은 흔하게 사용되는 방법이다. 하지만 입력 데이터를 Serialized된 형태로 읽어들여야 하는 경우라면 좀 더 고려가 필요하다. MultiThread 방식으로 배치가 실행되면 각 쓰레드들은 자신의 Chunk를 채우기 위해서 Reader를 호출한다. 만약 한번에 해당 Chunk가 채워지지 않으면 추가적인 데이터를 Reader에게 요청한다. 이 과정에서 쓰레드간 Race condition이 발생하고, 결국 읽는 과정에서 오류가 발생될 수 있다. 예를 들어 입력으로 단순 Stream Reader 혹은 RDBMS의 Cursor를 이용하는 경우에는.

문제가 된 케이스에서는 JDBCCursorItemReader를 써서 Reader를 구현하였다. 당연히 멀티 쓰레드 환경에 걸맞는 Synchronization이 없었기 때문에 Cursor의 내부 상태가 뒤죽박죽되어 Exception을 유발시켰다.

가장 간단한 해결 방법은 한번 읽어들일 때 Chunk의 크기와 동일한 크기의 데이터를 읽어들이도록 하는 방법이다. Tricky하지만 상당히 효율적인 방법이다.  Cursor가 DBMS Connection에 의존적이기 때문에 개별 쓰레드가 연결을 따로 맺어서 Cursor를 관리하는 것도 다른 방법일 수 있겠지만, 이러면 좀 많이 복잡해진다. ㅠㅠ 동일한 크기의 데이터를 읽어들이기 위해 Paging 방식으로 데이터를 읽어들일 수 있는 JDBCPagingItemReader 를 사용한다. 관련된 샘플은 다음 두개의 링크를 참고하면 쉽게 적용할 수 있다.

이걸 바탕으로 구현한 예제 Reader 코드는 아래와 같다. 이전에 작성한 코드는 이런 모양이다.

Before

public JdbcCursorItemReader<User> itemReader(DataSource auditDataSource,
                                                @Value("#{jobExecutionContext['oldDate']}") final Date oldDate) {
    JdbcCursorItemReader<User> reader = new JdbcCursorItemReader();
    String sql = "SELECT user_name, last_login_date FROM user WHERE last_login_date < '%s'";
    SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    reader.setSql(String.format(sql, sdf.format(elevenMonthAgoDate)));
    reader.setDataSource(auditDataSource);
    ...
}

After

public JdbcPagingItemReader<User> itemReader(DataSource auditDataSource,
                                             @Value("#{jobExecutionContext['oldDate']}") final Date oldDate) {
    JdbcPagingItemReader<User> reader = new JdbcPagingItemReader();

    SqlPagingQueryProviderFactoryBean factory = new SqlPagingQueryProviderFactoryBean();
    factory.setDataSource(auditDataSource);
    factory.setSelectClause("SELECT user_name, last_login_date ");
    factory.setFromClause("FROM user ");
    factory.setWhereClause(String.format("WHERE last_login_date < '%s'", new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(oldDate)));
    factory.setSortKey("user_name");

    reader.setQueryProvider(factory.getObject());
    reader.setDataSource(auditDataSource);
    reader.setPageSize(CHUNK_AND_PAGE_SIZE);

    ...
}

여기에서 가장 핵심은 CHUNK_AND_PAGE_SIZE라는 Constant다. 이름에서 풍기는 의미를 대강 짐작하겠지만, Chunk에서 읽어들이는 값과 한 페이지에서 읽어들이는 개수가 같아야 한다는 것이다. 이러면 단일 Cursor를 사용하더라도 실행 Thread간의 경합 문제없이 간단히 문제를 잡을 수 있다. 하지만 명심할 건 이것도 뽀록이라는 사실.
이렇게 문제는 해결했지만 과연 마이크로서비스 환경의 배치로서 올바른 모습인가에 대해서는 의구심이 든다. 기존의 배치는 Monolithic 환경에서 개발되었고, 가급적 손을 덜 들이는 관점에서 접근하고 싶어서 쓰레드를 대량으로 투입해서 문제를 해결하긴 했다. 젠킨스를 활용하고, 별도의 어플리케이션 서버를 만들어서 구축한 시스템적인 접근 방법이 그닥 구린건 아니지만 태생적으로 다음의 문제점들이 있다는 생각이 작업중에 들었다.

  • SpringBatch가 기존의 주먹구구식 배치를 구조화시켜서 이쁘게 만든건 인정한다. 하지만 개별 서버의 한계를 넘어서지는 못했다.  한대의 장비라는 한계. 이게 문제다. 성능이 아무리 좋다고 하더라도 한대 장비에서 커버할 수 있는 동시 작업의 한계는 분명하다. 더구나 안쓰고 있는데도 장비가 물려있어야 하니 이것도 좀 낭비인 것 같기도 하고…
  • Microservice 환경의 Transaction cost는 기존 Monolithic에 비해 감내하기 힘든 Lagging effect를 유발시킨다. 그렇다고 개별 개별 서비스의 DB 혹은 Repository를 헤집으면서 데이터를 처리하는건 서비스간의 Indepedency를 유지해야한다는 철학과는 완전 상반된 짓이다. 구린 냄새를 풍기면서까지 이런 짓을 하고 싶지는 않다. Asynchronous하고, Parallelism을 충분히 지원할 수 있는 배치 구조가 필요하다.

한번에 다 할 수 없고, 일단 생각꺼리만 던져둔다. 화두를 던져두면 언젠가는 이야기할 수 있을거고, 재대로 된 방식을 직접 해보거나 대안제를 찾을 수 있겠지.

]]> 489