import { Injectable } from '@nestjs/common';
import { Worker } from 'worker_threads';
import { once } from 'events';

@Injectable()
export class SomeService {
	async execute() {
		const worker = new Worker('./worker.js', { workerData: {} });
		
		await once(worker, 'exit');
	}
}

import { isMainThread, workerData, parentPort } from 'worker_threads';

if (!isMainThread) {
	async function main() {
		// do something here
		parentPort.postMessage('ready');
	}
	main();
}

Nest.js는 ts-node를 사용하지 않기 때문에 번들링 툴 등을 사용하지 않는 이상 상대경로가 바뀔일은 없으므로 이에 대해서는 염려하지 않아도 된다. 그러나 상대경로가 하드코딩 된다는 것이 맘에 들지 않는다. 따라서 다음과 같이 바꿔본다.

import run from './worker';

@Injectable()
export class SomeService {
	async execute() {
		await run({});
	}
}

import { Worker, isMainThread, workerData, parentPort } from 'worker_threads';
import { once } from 'events';

export default async function run(params: any) {
	const worker = new Worker(__filename, { workerData: params });

	const [exitCode] = await once(worker, 'exit');

	return exitCode as number;
}

if (!isMainThread) {
	async function main() {
		// do something here
		parentPort.postMessage('ready');
	}
	main();
}

__filename이라는 CommonJS의 module wrapper를 통해 제공되는 변수를 이용하여 파일 이름을 하드코딩 하지 않고도 worker를 사용할 수 있다. 다만, 한 가지 문제가 있다.

파일이 실행될 때에 이것이 import 로 인한 모듈 로딩에 의해 실행된 것인지, Worker 생성으로 인해 실행된 것인지가 구분되지 않기 때문에 이런 식으로 구현된 worker에서 같은 방식으로 구현된 다른 worker를 실행한다면 해당 과정에서 발행하는 import 구문으로 인해 자칫하면 쓰레드 무한 생성이 가능하기 때문이다.

따라서 한 가지 규칙을 정해 이를 막아본다. workerData에 항상 쓰레드가 어느 파일에서 시작되었는지 해당 파일의 경로를 전달하는 것이다.

import run from './worker';

@Injectable()
export class SomeService {
	async execute() {
		await run({});
	}
}

import { Worker, workerData } from 'worker_threads';
import { once } from 'events';

export default async function run(params: any) {
	const worker = new Worker(__filename, {
		workerData: {
			entryFile: __filename,
			params,
		},
	});

	const [exitCode] = await once(worker, 'exit');

	return exitCode as number;
}

if (workerData?.entryFile === __filename) {
	async function main(_params: any) {
		// do something here
		parentPort.postMessage('ready');
	}
	main(workerData.params);
}

이렇게 하면 어느 파일을 통해서 쓰레드가 시작되었는지 확인이 가능하기 때문에 worker 내에서 안전하게 같은 방식으로 구현된 다른 worker를 실행할 수 있다.

workerData는 어찌됐든 worker thread로 생성된 경우에만 존재하는 객체이므로 isMainThread 변수는 이 상황에서는 딱히 쓸모는 없다.

2. Nest.js IoC 컨테이너 활용하기

아직은 thread 내에서 Nest.js의 IoC 컨테이너를 활용할 수 없다. NestFactory.createApplicationContext 함수를 활용하여 쓰레드 내에서도 IoC 컨테이너를 활용할 수 있도록 하자.

import { Worker, workerData } from 'worker_threads';
import { once } from 'events';
import { AppModule } from './app.module'
import { Injectable, Module, Inject } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';

export default async function run(params: any) {
	const worker = new Worker(__filename, {
		workerData: {
			entryFile: __filename,
			params,
		},
	});

	const [exitCode] = await once(worker, 'exit');

	return exitCode as number;
}

@Injectable()
class WorkerService {
	constructor(
		private readonly configService: ConfigService,
		@Inject('whatever-you-want')
		private readonly someClient: SomeClient,
	) {}

	async run(params: any) {
		// do something here
	}
}

@Module({
	imports: [AppModule],
	providers: [WorkerService],	
})
class WorkerModule {}

if (workerData?.entryFile === __filename) {
	async function main(params: any) {
		const app = await NestFactory.createApplicationContext(WorkerModule);
		
		app.enableShutdownHooks();
		
		const service = app.get(WorkerService);
		await service.run(params);
		
		await app.close();
	}
	main(workerData.params);
}

몇 가지 주의해야 할 점은 AppModule를 import해서 사용할 것이기 때문에 사용하고 싶은 global이 아닌 서비스가 있다면 AppModule에서 꼭 export를 해주어야 한다. 또, 쓰레드 내에서도 Nest.js의 lifecycle hook이 동일하게 실행되므로 onModuleInit 등에서 단순히 자원 할당이 아닌 호스트 컴퓨터에서 단 한번만 실행하고 싶은 작업의 경우 아까는 쓸모 없다고 했던 isMainThread 변수를 활용하여 메인 쓰레드에서만 동작하도록 해주면 된다. 혹은 해당 작업을 onModuleInit 에서 호출하는 것이 아닌, Nest.js app이 생성되는 bootstrap 함수에서 직접 참조하여 실행시켜 주는 것도 괜찮겠다.

// ...
@Injectable()
export class FooBarService implements OnModuleInit {
	async onModuleInit() {
		if (!isMainThread) return;
		
		// do something here
	}
}

// ...
async function bootstrap() {
	const app = await NestFactory.create(AppModule);
	// ...
	await app.get(SomeService).init();
	// ...
	await app.listen(3000);
}

또, 쓰레드 내에서 ModuleRef를 사용할 경우 ModuleRef는 기본 동작이 strict: true 이므로, 원하는 인스턴스를 inject할 수 없을수도 있다. 따라서 strict: false 옵션을 주어 해결한다.

위와 같은 방법으로 간편하게 custom provider를 Nest.js의 IoC 컨테이너에 제공할 수 있다. 가령, redis 라이브러리에서 생성한 redis 클라이언트를 제공할 수 있다.

import { createClient } from 'redis';
import { ConfigService } from '@nestjs/config';

@Module({
	providers: [
		{
			provide: 'redis-client',
			useFactory: async (configService: ConfigService) => {
				const client = await createClient({
					url: configService.get('REDIS_URL'),
				}).connect();
				return client;
			},
			inject: [ConfigService],
		},
	],
})
export class AppModule {}

그런데 이렇게만 제공하면 SIGTERM 등으로 종료 시그널을 받아 shutdown hook이 동작할 때에 커넥션이 정리되지 않으면서 어플리케이션이 알아서 종료되지 않는다. 이에 관하여 dispose 기능을 프레임워크 레벨에서 추가할 것을 요구하는 GitHub issue가 있다.

• https://github.com/nestjs/nest/issues/9497

위 이슈는 Scope.REQUEST 등 스코프가 종료될 때에 provider 자원을 반환하도록 하는 추상화 레이어를 추가해 달라는 요청이기는 하나, 아무튼 이런식으로 provider를 제공할 때에 어떤 식으로 자원을 정리해야 하는지에 대해서는 공식 문서에서도 마땅히 설명되어있는 바는 없다. 좀 간단한 방법을 인터넷에서 찾아보았다.

1. Module에서 dispose 시키기

provider를 제공한 모듈 클래스에서 lifecycle hook을 구현하여 리소스를 정리하는 방법이다.

@Module({
	providers: [
		{
			provide: 'token',
			useFactory: async () => {
				const someClient: unknown;
				
				return someClient;
			},
		},
	],
})
export class AppModule implements OnApplicationShutdown {
	constructor(
		@Inject('token')
		private readonly someClient: SomeClient,
	) {}

	async onApplicationShutdown() {
		await this.someClient.close(); // or something similar
	}
}

간단하기는 하나, 한 자원에 대한 코드가 한 파일 내에서 서로 떨어져있어 썩 맘에 들지는 않는다. (다른 provider 코드가 더 많아진다면 더더욱이)

• https://stackoverflow.com/questions/63753467/how-to-close-database-connection-in-nestjs-service

2. Provider 객체에 lifecycle hook 추가하기

객체에 직접 onApplicationShutdown 함수를 삽입하는 방법이다. TypeScript 환경이기 때문에 object['onApplicationShutdown'] = async () => { return; };과 같은 불편한(?) 방법 말고 조금 더 괜찮은 방법이 있다.

@Module({
	providers: [
		{
			provide: 'token',
			useFactory: async () => {
				const someClient: unknown;

				(someClient as unknown as OnApplicationShutdown)
					.onApplicationShutdown = async () => {
						// do something here

						return;
					};
				
				return someClient;
			},
		},
	],
})
export class AppModule {}

이번에는 코드가 한 군데 몰려있어 깔끔하다.

@nestjs/bullmq 라이브러리에서 해당 패턴을 확인할 수 있다.

• https://github.com/nestjs/bull/blob/ec3443cf5bca407455a9dd1770f2e4f41098b8ac/packages/bullmq/lib/bull.providers.ts#L67

node.js를 이용해서 http 서버를 운영 중인 경우 안전하게 어플리케이션을 종료하기 위해서는 기본적으로 아래와 같은 과정을 거쳐야 한다.

1. 서버의 listening 소켓을 닫는다.
2. 새로운 요청을 모두 거절한다.
3. 기존 요청이 완료될 때 까지 기다린다.
4. 기타 나머지 작업을 처리한다. (DB 연결 종료 등)

일단, shutdown 신호를 받기 위해 SIGINT를 이용한다. PM2 등에서 rolling update를 위해 프로세스로 먼저 이 시그널을 보내기도 한다. 터미널에서는 보통 Ctrl+C로 이 SIGINT를 보낼 수 있다. (필요에 따라 SIGINT 말고 SIGUSR1, SIGUSR2 등을 이용해도 되겠다)

let isTerminating = false;

process.on('SIGINT', () => {
    isTerminating = true;
});

먼저, server.close 함수를 통해 listening 소켓을 닫아 새로운 연결을 막도록 하자.

process.on('SIGINT', () => {
    isTerminating = true;
    
    server.close((err) => {
        if (err) {
	        console.error(err);
            process.exit(1);
        } else {
            process.exit(0);
        }
    });
});

http.Server의 close 함수는 listening하고 있는 소켓만 닫을 뿐, 이미 열려 통신하고 있는 소켓들은 손대지 않고 모두 종료될 때 까지 기다린 후 callback 함수를 호출한다.

listening 소켓은 닫았더라도 클라이언트와 서버 사이에서 http keepAlive를 사용하게 될 경우 기존 소켓들이 계속 열려있어 새로운 요청이 들어올 수 있기 때문에 이를 거절해야 한다. 따라서 idle 소켓을 임의로 모두 끊어준다.

idle인지 아닌지 판단하는 방법은 단일 요청이 시작되고 끝날 때 마다 idle 여부를 체크하는 것이다.

server.on('request', (req, res) => {
    const socket = req.socket;
    
    socket.$$idle = false;
    
    res.on('finish', () => {
        socket.$$idle = true;
    });
});

HTTP 1.1 에서는 커넥션 당 요청과 응답의 순서가 보장되는 통신을 하므로 위와 같이 idle 유무만 확인하더라도 큰 문제는 없다. 하지만 HTTP 2.0를 사용하게 된다면 idle 유무가 아니라 처리 중인 요청 수를 세어야 하겠다. ^{1 2}

node.js의 Server 클래스에는 현재 연결된 소켓 목록 따로 제공하고 있지 않으므로 idle 소켓을 모두 끊기 위해서는 현재 소켓들을 직접 추적해야 한다.

const connections = new Set();

server.on('connection', (socket) => {
    if (isTerminating) {
        socket.destory();
        return;
    }

    connections.add(socket);
    
    socket.$$idle = true;
    
    socket.on('close', () => {
	    connections.delete(socket);
    });
});

만일 http.Server가 아니라 https.Server를 사용할 경우 connection이 아니라 secureConnection을 사용해야 한다.

후에 이 Set을 이용해서 일괄 종료를 할 수 있다.

for (const socket of connections) {
    if (isTerminating && socket.$$isIdle) socket.destroy();
}
connections.clear();

idle이 아닌 소켓에 대해서는 마지막 요청 처리를 마친 후 끊어질 수 있도록 다음과 같이 코드를 수정한다.

server.on('request', (req, res) => {
    const socket = req.socket;
    
    socket.$$idle = false;
    
    res.on('finish', () => {
        socket.$$idle = true;
        
        if (isTerminating) socket.destroy();
    });
});

다른 방법으로 새로운 요청 시 응답 헤더에 Connection: close를 달아주는 방법이 있다. express 라이브러리 등을 사용한다면 middleware로 손쉽게 추가할 수 있겠다.

const app = express();

app.use((req, res, next) => {
    if (isTerminating && !res.headersSent) {
	    res.set('Connection', 'close');
    }
    
    next();
});

특정 프레임워크에 종속되길 원치 않는다면 아래와 같은 방법으로 헤더를 추가할 수 있다.

server.on('request', (req, res) => {
    if (isTerminating && !res.headersSent) {
	    res.setHeader('Connection', 'close');
	}
});

그런데 이 방법만을 사용 시에는 새로운 요청이 들어오지 않는다면 소켓 close가 트리거 되지 않는다. 따라서 명확하게 idle 소켓을 확인하여 destory 하는 것이 좋아보인다.

구현된 패키지

이런 식으로 이미 구현된 패키지가 많이 있다. 다운로드 수가 좀 있어보이는 패키지를 몇 살펴보았다.

• https://www.npmjs.com/package/http-shutdown
  • 소켓 커넥션을 관리하기 위해서 Set이 아니라 일반 Object 및 단조 증가하는 정수 변수 하나를 이용한다.
    • 이 경우, 보통의 경우 왠만하면 그럴 일은 없겠지만 Number의 표현의 최대값에 도달할 경우 더 이상 값이 증가하지 않기 때문에 문제가 생길 수 있어보인다. (문제가 생기기 전에 서버가 재시작 될 확률이 더 커보인다)
    • https://stackoverflow.com/questions/19054891/does-javascript-handle-integer-overflow-and-underflow-if-yes-how
  • 응답 헤더에 Connection 헤더를 따로 추가하지는 않는다.
• https://www.npmjs.com/package/http-graceful-shutdown
  • 위와 동일하게 소켓 커넥션 관리를 위해 일반 Object 및 단조 증가하는 정수 변수 하나를 이용한다.
  • res.headersSent를 확인하여 필요 시 Connection: close 헤더를 달아준다.
• https://www.npmjs.com/package/@gquittet/graceful-server
  • 소켓 커넥션 관리를 위해 Set 자료구조를 사용한다.
  • res.headersSent를 확인하여 필요 시 Connection: close 헤더를 달아준다.
  • 소켓 idle을 따로 체크하지는 않는다. 그냥 소켓을 부숴버린다.
• https://www.npmjs.com/package/@moebius/http-graceful-shutdown
  • 소켓 커넥션 관리를 위해 Object를 사용한다.
  • 응답 헤더에 Connection 헤더를 따로 추가하지는 않는다.

KafkaJS의 heartbeatInterval은 consumer가 group coordinator에게 보내는 heartbeat의 주기가 설정된 값보다 빠르지 않도록 제한할 뿐이다.

발생하는 문제

해당 시험에 사용된 라이브러리와 Kafka의 버전은 다음과 같다.

• KafkaJS: 2.2.4
• Kafka: confluentinc/cp-kafka:7.4.1.arm64 Docker Image

KafkaJS에서 consumer를 만들 때 다음과 같이 heartbeatInterval 옵션을 지정해 줄 수 있다.

const { Kafka } = require('kafkajs');

const kafka = new Kafka({
  clientId: 'test-app',
  brokers: ['localhost:9092', 'localhost:9093', 'localhost:9094'],
});

const consumer = kafka.consumer({
  groupId: 'test-group',
  heartbeatInterval: 3000,
});

이 값의 기본값은 3000ms이며, 문서에는 다음과 같이 적혀있다.

https://kafka.js.org/docs/consuming#a-name-options-a-options

The expected time in milliseconds between heartbeats to the consumer coordinator. Heartbeats are used to ensure that the consumer's session stays active. The value must be set lower than session timeout

동작 시간을 보장한다고 적혀있진 않다. 그 외에 정확히 어떻게 동작하는지에 대한 구체적인 설명은 없다.

const consumer = kafka.consumer({
  groupId: 'test-group',
  sessionTimeout: 1000, // broker의 group.min.session.timeout.ms도 1000으로 낮춰주었다
  heartbeatInterval: 333,
});

이렇게 옵션을 설정한다면 기대하기로는 session time-out 시간인 1초 내에 333ms마다 heartbeat를 보내기 때문에 아무런 이상이 없을 것 같다. 하지만 이렇게만 설정하면 계속해서 rebalancing이 일어남을 알 수 있다.

어째서?

아래는 heartbeatInterval값이 쓰이는 코드이다.

• https://github.com/tulios/kafkajs/blob/ff3b1117f316d527ae170b550bc0f772614338e9/src/consumer/consumerGroup.js#L132

	// ...
    this[PRIVATE.SHARED_HEARTBEAT] = sharedPromiseTo(async ({ interval }) => {
      const { groupId, generationId, memberId } = this
      const now = Date.now()

      if (memberId && now >= this.lastRequest + interval) {
        const payload = {
          groupId,
          memberId,
          groupGenerationId: generationId,
        }

        await this.coordinator.heartbeat(payload)
        this.instrumentationEmitter.emit(HEARTBEAT, payload)
        this.lastRequest = Date.now()
      }
    })
    // ...

여기서 interval 매개변수로 위에서 설정한 heartbeatInterval값이 들어가는데, 함수를 호출할 때 마다 마지막으로 heartbeat를 보낸 시점에서 해당 interval 만큼 지났는지 여부를 확인한다.

KafkaJS에서는 fetch 요청을 보낼 때 같이 heartbeat를 보내는 식으로 naive하게 구현되어 있다.

• https://github.com/tulios/kafkajs/blob/ff3b1117f316d527ae170b550bc0f772614338e9/src/consumer/runner.js#L378

  async handleBatch(batch) {
    // ...

    const onBatch = async batch => {
      if (batch.isEmptyDueToFiltering()) {
        // ...

        await this.heartbeat()
        return
      }

      if (batch.isEmpty()) {
        await this.heartbeat()
        return
      }

      // ...

      await this.autoCommitOffsets()
      await this.heartbeat()
    }

    await onBatch(batch)
  }

그리고 무한 루프를 돌면서 fetch 요청을 보내는 데, 이 속도는 maxWaitTimeInMs에 의해 제한된다. 해당 옵션은 fetch 요청을 서버가 받은 직후 바로 응답을 하는 것이 아니라, max.poll.records만큼의 데이터가 쌓여 있으면 바로 보내고 그렇지 않으면 해당 시간 만큼 기다린 후에 응답을 보낸다.

• https://kafka.js.org/docs/consuming#a-name-options-a-options

The maximum amount of time in milliseconds the server will block before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement given by minBytes

그리고 KafkaJS에서 이 값의 기본값은 5000ms이다.

즉, 아무것도 하지 않는 상태에서 연결만 한다면 heartbeat는 기본값인 3000ms가 아닌 5000ms 주기로 보내진다.

const { Kafka, logLevel } = require('kafkajs');

const kafka = new Kafka({
  clientId: 'test-app',
  brokers: ['localhost:9092', 'localhost:9093', 'localhost:9094'],
  logLevel: logLevel.DEBUG,
});

const consumer = kafka.consumer({
  groupId: 'test-group',
});

async function main() {
  await consumer.connect();
  await consumer.run({
    eachMessage: async ({ topic, partition, message }) => {
      console.log({ topic, partition, value: message.value });
    },
  });
}
main();

log level을 DEBUG로 변경하고 연결만 한 상태에서 로그를 확인해 보면 5초 주기로 heartbeat를 보내고 있음을 확인할 수 있다. 여기서 maxWaitTimeInMs를 100ms로 변경하고 다시 실행시키면 주기가 3초로 짧아짐을 볼 수 있다.

const consumer = kafka.consumer({
  groupId: 'test-group',
  maxWaitTimeInMs: 100,
});

이 상태에서는 heartbeat 주기를 더 빠르게 변경할 수 있다.

const consumer = kafka.consumer({
  groupId: 'test-group',
  maxWaitTimeInMs: 100,
  heartbeatInterval: 500,
});

다른 Node.js Kafka Client들

Node.js 생태계에서 Kafka Client의 다른 구현체를 찾으면 KafkaJS외에 다음 두 가지가 있다.

1. node-rdkafka
   • 블리자드에서 만든 패키지
   • librdkafka의 nodejs wrapper 버전이라고 한다
     • librdkafka는 Confluent에서 만든 것으로 보인다.
   • Confluent 홈페이지에서 Node.js에서 설명할 때 이 패키지를 사용하는 것 같다.
     • https://developer.confluent.io/get-started/nodejs/
2. kafka-node

글 작성 시점 기준으로 kafka-node는 마지막으로 업데이트 된지 몇 년 되었고 KafkaJS도 6개월이 지났는데 node-rdkafka는 1개월 전에도 업데이트 이력이 있다.

https://npmtrends.com/kafka-node-vs-kafkajs-vs-node-rdkafka

그래서 node-rdkafka를 사용해보기로 한다. 해당 라이브러리를 설치하여 비슷한 설정 값을 넣고 테스트를 해보았다.

const Kafka = require('node-rdkafka');

const consumer = new Kafka.KafkaConsumer(
  {
    'session.timeout.ms': 1000,
    'heartbeat.interval.ms': 333,
    'group.id': 'rdkafka',
    'metadata.broker.list': 'localhost:9092,localhost:9093,localhost:9094',
    debug: 'consumer,topic,fetch,cgrp',
  },
  {}
);

consumer.connect();

consumer
  .on('ready', () => {
    consumer.subscribe(['test-topic']);
    consumer.consume();
  })
  .on('data', (data) => {
    console.log(data);
  })
  .on('event.log', (event) => {
    console.log(event.fac, new Date().toISOString());
  });

기대하는 대로 동작한다! 몇 가지 다른 값을 넣어서 테스트해보았는데, 대체로 입력한 값보다 약간 느리게 작동하지만 의도한 대로 작동함을 알 수 있었다.

전체 구조

GitHub Action에는 cron으로 작업을 스케줄링 할 수 있다.

on:
  push:
    branches:
      - main
  schedule:
    - cron: "0 0-9 * * *"

시간대는 UTC를 따르기 때문에 위 cron 식에서는 한국 시간대 기준으로 오전 9시부터 오후 6시 까지 동작한다. 동작하는 것 까지는 좋은데 제시간에 동작하지 않는다는 문제가 있다. 심할때는 1시간 넘게 작업이 지연될 때도 있는데 시간이 정확해야 하는 작업은 아니니 괜찮다.

cron으로 작업이 실행될 때 마다 공지사항을 크롤링 한 뒤 rss 생성 및 Discord Webhook 알림을 보낸다.

크롤링 및 RSS 만들기

기존 RSS에서 마음에 들지 않았던 것은 내용을 미리 볼 수 없었던 것이다. 물론 RSS 리더 마다 웹사이트 링크가 있는 경우 해당 페이지를 읽어와 바로 볼 수 있게 되어있는 경우도 있다. 아래는 Thunderbird에 RSS를 구독한 경우다.

그냥 제목만 딸랑 달려있다. 그래서 아래처럼 보이게 만들었다.

물론 이렇게 하려면 공지사항 별로 크롤링을 한 번씩 더 해야 한다. cheerio를 사용했다.

Discord Webhook

https://discord.com/developers/docs/resources/webhook

처음에는 디스코드 봇을 따로 만들까 했는데 알림만 보낼건데 너무 귀찮았다.

웹훅은 URL을 POST로 호출만 하면 되기 때문에 간편하다. 한 가지 문제는 다른 사람이 알림을 받아보기 위해서는 동적으로 웹훅을 등록하고 읽어올 수 있어야 한다는 것이다. 돈 들이지 않고 이를 구현하려면 utterances처럼 GitHub Repository의 issue 혹은 discussion등을 이용해 볼 수도 있겠으나 사용자 친화적이지 않다. 마침 인턴 중에 AWS Lambda를 사용해볼 일이 있어서 Lambda와 DynamoDB를 이용했다.

Lambda와 DynamoDB의 장점은 Always Free Tier에 속해있기 때문에 이런 토이 프로젝트에서는 충분히 쓰고도 남는 스펙을 제공한다. (이것이 serverless…?)

배포에는 Serverless Framework를 이용했다. serverless.yml에 필요한 자원(Lambda function, DynamoDB 등)을 적어놓기만 하면 Cloudformation으로 생성까지 알아서 해준다.

functions:
  subscribe:
    handler: index.subscribe
    events:
      - httpApi:
          path: /subscribe
          method: post
  unsubscribe:
    handler: index.unsubscribe
    events:
      - httpApi:
          path: /unsubscribe
          method: post

resources:
  Resources:
    AjouBotDiscordDynamoDbTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ${self:custom.tableName}
        ProvisionedThroughput:
          ReadCapacityUnits: 1
          WriteCapacityUnits: 1
        AttributeDefinitions:
          - AttributeName: webhook-id
            AttributeType: N
          - AttributeName: webhook-token
            AttributeType: S
        KeySchema:
          - AttributeName: webhook-id
            KeyType: HASH
          - AttributeName: webhook-token
            KeyType: RANGE

알림을 보내려면 마지막으로 알림을 보낸 게시물이 무엇인지 알아야 한다. 해당 게시물의 id를 저장하는 것은 GitHub Repository Variable을 이용했다.

GitHub API를 이용하면 해당 변수를 갱신할 수 있다.

async function setDiscordLastArticleNo(value: string) {
  await octokit.request(
    "PATCH /repos/{owner}/{repo}/actions/variables/{name}",
    {
      owner: "rlj1202",
      repo: "ajou-bot",
      name: "DISCORD_LAST_ARTICLE_NO",
      value: `${value}`,
      headers: {
        "X-GitHub-Api-Version": "2022-11-28",
      },
    },
  );
}

변수의 값을 이용할 때는 GitHub Action 실행 시 환경변수로 넣어줄 수 있다.

      - name: Run Discord Script
        run: npm run start:discord
        env:
          GITHUB_TOKEN: ${{ steps.generate_token.outputs.token }}
          DISCORD_LAST_ARTICLE_NO: ${{ vars.DISCORD_LAST_ARTICLE_NO }} # <- 여기!
          DISCORD_WEBHOOK_TEST: ${{ secrets.DISCORD_WEBHOOK_TEST }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        continue-on-error: true

웹훅 구독 페이지

APIGateway 주소가 있으니 이걸 간편하게 호출할 간단한 웹페이지가 있으면 된다. 그래서 그냥 군대에서 상황보고 유틸 페이지를 메모장으로 만들던 향수를 느끼며 쌩 html 파일 하나를 작성해서 GitHub Pages로 배포했다.

링크

• https://github.com/rlj1202/ajou-bot

SSL은 Secure Sockets Layer의 약자로, 컴퓨터 네트워크에 통신 보안을 위해 설계된 암호 규약입니다. https 프로토콜에 사용됩니다. 이 글에서는 실제 hand-shaking과정 또는 메세지 포맷 등 구체적인 작동 절차에 대한 내용은 포함하지 않습니다. 이러한 절차가 어떠한 필요로 인해 생겼는지, 어떻게 해서 실제로 네트워크 상에서 양단의 두 사용자가 안전하게 정보를 주고받을 수 있었는지 등의 내용을 공부하면서 정리해본 글입니다.

비밀 편지를 주고받고 싶어요

철수와 영희가 안전하게 비밀 편지를 주고받고자 합니다. 따라서 편지의 내용을 암호화 하고 복호화 할 수 있는 방법을 찾아야 합니다. 암호화 방식에는 크게 대칭키 방식과 비대칭키 방식이 있습니다. 대칭키 방식은 하나의 키로 암호화 및 복호화를 모두 할 수 있는 방식을 말하고, 비대칭키 방식은 하나의 키로는 암호화를 하고 다른 키로 복호화를 해야하는 방식을 말합니다. 이 때 두 키를 공개키, 비밀키(혹은 개인키)라고 합니다. 철수와 영희가 편지로 비밀을 주고받기 이전에 대면으로 먼저 만나서 서로 대칭키 혹은 비대칭키를 한 번만 교환하고 나면 그 후부터는 서로 안전하게 비밀 편지를 주고받을 수 있을 것입니다. 둘 중 어떤 방식을 선택하는 것이 좋을까요?

비대칭키 방식은 대칭키 방식과 비교해서 암호화 및 복호화를 하는데 더 많은 시간과 비용이 소모됩니다. 편지의 내용이 많으면 많아질수록 더욱 그렇습니다. 매번 이 방식으로 편지를 주고 받는다면 두 사람 모두 금방 지칠 것입니다. 그래서 비대칭키 대신 대칭키를 사용해서 서로 편지의 내용을 암호화하여 주고받기로 결정합니다. 여기까지 정한 절차는 이렇습니다.

1. 철수는 대칭키로 편지를 암호화하여 영희에게 보낸다.
2. 영희는 대칭키로 편지를 복호화한다.

반대로 영희가 철수에게 편지를 보낼 때도 마찬가지입니다.

대칭키는 무엇으로 정하지?

철수와 영희가 서로 사전에 대면으로 만나서 키를 하나 정하고 나면 서로 비밀 편지를 주고 받는데 아무런 문제가 없을 것입니다. 하지만 과연 그럴까요? 우리는 항상 우리가 주고받는 편지를 제3자가 훔쳐볼 수 있음을 유의해야 합니다.

제3자가 철수와 영희가 주고받는 편지를 우체국에서 훔쳐보고 있다고 생각해 봅시다. 물론 어느 경우에서든 제3자가 메세지를 해독할 수는 없을겁니다. 대신 제3자는 동일한 내용의 편지를 똑같이 보내어 두 사람을 괴롭힐 수 있습니다. 예로, 제3자가 재미로 철수가 적은 어떤 편지를 매일 똑같이 영희에게 보낸다고 해봅시다. 그런데 편지의 내용이 내일 3시에 만나자는 내용이었다면? 이런 식의 장난을 매일 한다면 철수와 영희는 대화의 내용을 다른 사람이 볼 수 없을지언정 제대로된 소통을 할 수 없을 것입니다. 이런 식의 공격 방식을 Man-In-The-Middle, Replay Attack이라고 합니다. (물론 예시를 무엇으로 드냐에 따라 이 공격이 위험할 수도, 위험하지 않을 수도 있겠지만 온라인 쇼핑몰에서 물건을 구매하는 내용이었다면 실제로 재정적인 피해를 입힐 수 있을겁니다.)

여기서 발생하는 문제는 편지를 보내는 사람이 진짜로 영희가 맞는지, 철수가 맞는지 신뢰할 수 없다는 겁니다. 편지를 보낼 때 마다 다른 대칭키를 사용해 본다면 어떨까요? 어떤 규칙을 이용해서 편지를 주고 받을 때 마다 철수와 영희 모두 같은 대칭키를 만들고 편지를 보낸다면 제3자가 편지를 복사해서 보낸다고 하더라도 그 시점에서 그 편지를 암호화 할 때 사용했던 대칭키는 더 이상 의미가 없을테니 애초에 복호화도 할 수 없을 것입니다.

철수가 편지를 보내기 전에 대칭키를 아무거나 하나 정해서 영희에게 알려줄 수 있으면 좋을 것 같습니다. 이 때 비대칭키를 사용하면 좋을 것 같습니다! 대칭키는 편지에 비하면 길이가 짧으니 암호화 및 복호화 하는 데 부담이 없고 한 번만 암호화 및 복호화를 하면 됩니다. 물론 지금은 공개키-비밀키 쌍을 서로 미리 알고 있는 상태라고 가정합니다.

1. 철수는 공개키로 대칭키를 암호화하여 영희에게 보낸다.
2. 영희는 비밀키로 대칭키를 복호화한다.
3. 철수는 편지를 대칭키로 암호화하여 영희에게 보낸다.
4. 영희는 편지를 알아낸 대칭키로 복호화한다.

조금 복잡해지긴 했지만 내용도 암호화 되어있고 누가 보냈는지도 신뢰할 수 있습니다. 그럼 여기서 끝일까요? 사실, 아직 같은 문제가 여전히 존재합니다. 제3자는 편지를 같은 순서로만 보내면 영희는 철수가 편지를 보낸 줄 알겁니다. 제3자가 1번 과정에서 보낸 편지를 영희가 받으면 영희는 그 때 철수가 사용한 대칭키를 알 수 있고, 3번 과정에서 보낸 편지를 영희가 받으면 영희는 여전히 편지의 내용을 복호화 할 수 있습니다. 즉, 편지를 보내는 횟수만 많아지고 위에서 발생한 Replay Attack이 여전히 가능합니다. ^{1 2}

왜 이런 문제가 발생했을까요? 그 이유는 대칭키를 정하는 데 철수만 개입했기 때문입니다. 철수가 대칭키를 만들었으니, 영희는 그냥 그 대칭키를 사용할 수 밖에 달리 도리가 없습니다. 따라서 영희도 같이 대칭키를 만들어야 합니다. 이번에는 추가로 철수와 영희 모두 대칭키를 만들기 위해 값을 아무거나 하나 정해서 서로 알려주도록 합시다.

1. 철수는 영희에게 아무렇게 정한 값을 보낸다.
2. 영희는 철수에게 아무렇게 정한 값을 보낸다.
3. 철수는 공개키로 대칭키를 암호화하여 영희에게 보낸다.
4. 영희는 비밀키로 대칭키를 복호화한다.
5. 철수와 영희는 서로 가지고 있는 두 개의 값 및 대칭키를 이용해서 새로운 대칭키를 만든다.
6. 철수는 편지를 새로 만든 대칭키로 암호화하여 영희에게 보낸다.
7. 영희는 편지를 새로 만든 대칭키로 복호화한다.

이렇게 하면 제3자는 더 이상 편지를 같은 순서로 보내는 것으로는 두 사람을 방해할 수 없습니다. 제3자가 1번 과정에서 보낸 편지를 영희에게 보내면 영희는 이번에는 다른 값을 보낼겁니다. 물론 제3자는 1, 2번 과정에서 두 사람이 서로에게 보낸 값을 알 수 있습니다만 철수가 공개키로 암호화한 대칭키를 알 수 없으니 5번 과정에서 부터는 제3자가 가지고 있는 메세지는 무용지물입니다. 여기서 3번과정에서 철수가 보낸 대칭키를 pre-master secret key, 5번 과정에서 새롭게 만드는 대칭키를 master secret key라고 합니다.

한글로 검색한 자료에서 대부분 pre-master secret key를 두 사람이 보낸 아무렇게 정한 값을 조합해서 만든다는 식으로 모호하게 설명하고 있습니다. ^{3 4 5 6} 그리고 master secret key는 pre-master secret key를 '일련의 과정을 거쳐' 생성한다는 식으로만 되어있습니다. (단순 타 블로그 스크랩 글이 굉장히 많은 것 같습니다.) 영어로 검색한 자료에서는 이렇게 설명하고 있는 글은 없었습니다. ^{7 8 9 10 11} 처음에 SSL에 대해 공부하면서 혼란스러웠던 부분입니다. pre-master secret key를 제3자가 쉽게 알아낼 수 있는 값으로만 생성한다면 의미가 없을텐데 말입니다. 글을 작성하는 시점에서 제가 이해한 바로는, pre-master secret key 또한 랜덤하게 생성되는 데이터입니다.

비대칭키의 공개키는 믿을 수 있는가?

이제 제3자가 철수와 영희의 편지의 내용을 훔쳐볼 수도, 두 사람을 방해할 수도 없습니다. 물론 아직까지는 두 사람이 비대칭키를 서로 알고 있다고 가정한 상태입니다. 사전에 비대칭키를 주고받을 수 없는 상황에서도 안전하게 편지를 주고받을 수 있을까요?

비대칭키이기 때문에 철수와 영희 둘 중 한 명만 키 쌍을 가지고 있어도 편지를 주고받기 시작할 수 있습니다. 영희가 비대칭키 쌍을 가지고 있다고 해봅시다. 영희가 철수에게 공개키를 편지에 적어 보내주는 것은 아무런 문제가 없습니다. 공개키만으로는 암호화만 가능하기 때문입니다. 좋습니다! 일단 그러면 공개키를 편지로 전달하는 과정을 추가해보도록 합시다.

1. 철수는 영희에게 아무렇게 정한 값을 보낸다.
2. 영희는 철수에게 아무렇게 정한 값을 보낸다.
3. 영희는 철수에게 공개키를 보낸다.
4. 철수는 영희가 보낸 공개키로 대칭키를 암호화하여 영희에게 보낸다.
5. 영희는 비밀키로 대칭키를 복호화한다.
6. 철수와 영희는 서로 가지고 있는 두 개의 값 및 대칭키를 이용해서 새로운 대칭키를 만든다.
7. 철수는 편지를 새로 만든 대칭키로 암호화하여 영희에게 보낸다.
8. 영희는 편지를 새로 만든 대칭키로 복호화한다.

간단히 3번 과정을 추가하는 것으로 사전에 만날 필요 없이 안전하게 편지를 주고받을 수 있게 되었습니다. 하지만 이번에는 다른 문제가 발생했습니다. 바로 제3자가 영희를 사칭할 수 있다는 것입니다. 만약 제3자가 3번 과정에서 영희를 사칭하여 자신이 만든 비대칭키 쌍의 공개키를 전달한다면 어떻게 될까요? 제3자는 이후 과정에서 문제없이 철수와 편지를 주고받을 수 있습니다. 이 경우 제3자는 영희와 철수가 서로 안전하게 소통하고 있다고 믿게 하면서 편지의 내용물을 모두 읽어낼 수 있습니다. 4번 과정에서 제3자는 일단 자신의 비밀키로 대칭키를 알아낸 다음, 영희의 공개키로 다시 대칭키를 암호화 하여 영희에게 보냅니다. 새 대칭키를 만드는데 필요한 세 값을 모두 알 수 있으니, 편지의 내용을 모두 까볼 수 있습니다.

이번에는 영희가 보낸 공개키가 정말 영희의 것인지 확신할 수 없다는 문제가 발생했습니다. 누군가 영희의 것이 맞는지 확인해 줄 필요가 있습니다. 그리고 그 누군가는 정말 아무나 신뢰할 수 있을만한 사람이어야 할 것입니다. 여기서는 대충 대통령으로 해봅시다. 한 나라의 대통령이 보증해주는 공개키라면 신뢰할 수 있지 않을까요? 여기서는 전자 서명(Digital Signature) 이라는 방법이 사용됩니다. (전자 서명에 대해서는 여기서 설명하지 않겠습니다.) 대통령은 대통령의 비밀키쌍을 가지고 있고, 공개키는 국민에게 공개되어있다고 해봅시다. 그리고 대통령이 비밀키로 '이 공개키는 영희의 공개키가 맞습니다' 라는 내용 및 공개키가 적힌 문서를 전자 서명하여 영희에게 주었다고 해봅시다. 위 3번 과정에서 영희는 공개키 대신 전자 서명된 문서를 철수에게 준다면 철수는 해당 문서를 대통령의 공개키를 이용해서 검증합니다. 이런 식으로 철수는 영희가 맞음을 확신할 수 있습니다.

여기서 대통령이 서명해 준 문서를 인증서(Certificate) 라고 하고, 대통령 처럼 인증서를 발급해 주는 주체를 CA(Certificate Authority) 라고 합니다. 여기서 부터는 신뢰의 체인 관계가 형성됩니다. 영희의 공개키를 대통령이 보증해 줬다면, 대통령의 공개키는 누가 보증해 줄지에 대한 문제입니다. UN 같은 기관에서 대통령의 공개키를 보증해 주었다면, UN의 공개키는 누가 보증해 줄까요? 결국에는 최종적으로 신뢰할 수 있는 최상위 주체가 필요합니다. 이를 Root CA 라고 합니다.

실제로 각 컴퓨터에는 위 사진처럼 미리 준비된 Root CA의 인증서들이 들어있습니다.

영희가 공개키를 보내는 것이 아니라 공개키 및 전자서명 정보가 담긴 인증서를 보내고, 철수가 이를 검증하는 과정을 추가해 봅시다.

1. 철수는 영희에게 아무렇게 정한 값을 보낸다.
2. 영희는 철수에게 아무렇게 정한 값을 보낸다.
3. 영희는 철수에게 인증서를 보낸다.
4. 철수는 영희가 보낸 인증서를 검증한다.
5. 철수는 영희가 보낸 인증서 내의 공개키로 대칭키를 암호화하여 영희에게 보낸다.
6. 영희는 비밀키로 대칭키를 복호화한다.
7. 철수와 영희는 서로 가지고 있는 두 개의 값 및 대칭키를 이용해서 새로운 대칭키를 만든다.
8. 철수는 편지를 새로 만든 대칭키로 암호화하여 영희에게 보낸다.
9. 영희는 편지를 새로 만든 대칭키로 복호화한다.

물론, 이렇게 하더라도 여전히 제3자가 이 둘 사이를 방해할 방법은 존재합니다. 컴퓨터에 담긴 Root CA 인증서를 바꿔치기 한다거나, Root CA 인증서를 다운로드 받는 주소의 DNS를 교란시키는 등 다양합니다.

참고 자료

• https://ko.wikipedia.org/wiki/전송_계층_보안
• https://en.wikipedia.org/wiki/Man-in-the-middle_attack
• https://en.wikipedia.org/wiki/Replay_attack
• https://www.enea.com/insights/a-new-way-of-detecting-tls-ssl-mitm-attacks/

자연수 $N$이 주어졌을 때, $A$보다 크거나 같고, $B$보다 작거나 같은 수 중에서 $N$과 서로소인 것의 개수를 구하는 프로그램을 작성하시오.

두 정수를 나눌 수 있는 양의 정수가 $1$밖에 없을 때, 두 정수를 서로소라고 한다. 즉, 두 수의 최대공약수가 $1$이면 서로소이다. $1$은 모든 정수와 서로소이다.

풀이

$[A, B]$에서 $N$과 서로소인 것의 갯수는 전체 개수에서 서로소인 것의 개수를 빼주면 된다. $N$과 서로소인 것은 $N$의 소인수 중 하나의 배수이면 된다.

N의 소인수를 $p_1, p_2, p_3, \cdots, p_k$라고 할 때

라고 한다면 포함 배제의 원리를 이용해서 다음과 같이 풀어 쓸 수 있다.

이 때 $N$의 크기가 $10^9$까지 이므로 소인수의 수는 많아봤자 $10$개 정도 밖에 되지 않는다. 따라서 모든 소인수 조합을 돌면서($\approx 2^{10} = 1024$) 포함 배제의 원리를 적용시켜주면 된다.

링크

• https://www.acmicpc.net/problem/9359

분류

• 포함 배제의 원리

문제에서 주어진 문자열을 트라이를 이용해서 저장해 두자. 그리고 아호 코라식을 이용해서 fail 노드까지 만들어 두자.

어떤 문자열 $A$가 다른 문자열 $B$의 이전 문자열 이기 위해서는 $A$가 $B$의 접미사 이거나 $B$의 노드 중 일부 노드의 fail이 문자열 A의 종점 노드를 가리키고 있으면 된다.

예를 들어, an라는 문자열은 ant의 접미사를 이루고 있으므로 ant의 이전 문자열이다.

ant라는 문자열은 cant라는 문자열의 이전 문자열이다. cant에서 t의 fail이 ant를 가리키고 있기 때문이다.

따라서, fail를 만들어 주면서 반대 방향 간선도 기록해 둔다. (나는 inv_fail 이라고 명명했다.) 그러면 trie의 go 변수와 inv_fail 변수를 통해 DAG 그래프가 만들어진다. 이를 위상 정렬을 이용해서 등장하는 단어가 가장 많은 횟수를 세주면 된다.

#include <bits/stdc++.h>

using namespace std;

typedef long long ll;

struct trie {
    vector<pair<char, trie*>> go;
    trie *fail;
    vector<trie*> inv_fails;
    int indegrees;
    int max_value;
    bool output;

    trie() : fail(nullptr), output(false), indegrees(0), max_value(0) {
    }
    ~trie() {
        for (auto [c, node] : go) delete node;
    }

    trie *find(char c) {
        for (auto [cur_c, node] : go) {
            if (cur_c == c) return node;
        }
        return nullptr;
    }

    void insert(const char *str) {
        if (*str == '\\0') {
            output = true;
            return;
        }

        trie *next = this->find(*str);
        if (!next) {
            next = new trie();
            go.push_back({ *str, next });
            next->indegrees++;
        }
        next->insert(str + 1);
    }
};

int main() {
    ios::sync_with_stdio(false); cin.tie(nullptr); cout.tie(nullptr);

    while (true) {
        int N;
        cin >> N;
        if (!N) break;

        trie *root = new trie();

        for (int n = 0; n < N; n++) {
            string word;
            cin >> word;

            root->insert(word.c_str());
        }

        queue<trie*> q;
        q.push(root);
        root->fail = root;

        while (!q.empty()) {
            trie *cur = q.front(); q.pop();

            for (auto [c, next] : cur->go) {
                if (cur == root) {
                    next->fail = root;
                } else {
                    trie *dest = cur->fail;
                    while (dest != root && !dest->find(c)) dest = dest->fail;
                    if (dest->find(c)) dest = dest->find(c);

                    next->fail = dest;
                    dest->inv_fails.push_back(next);
                    next->indegrees++;
                }

                q.push(next);
            }
        }

        // 
        int answer = 0;
        q.push(root);

        while (!q.empty()) {
            trie *cur = q.front(); q.pop();

            answer = max(answer, cur->max_value);

            for (auto [c, next] : cur->go) {
                next->max_value = max(next->max_value, cur->max_value + next->output);
                if (--next->indegrees == 0) {
                    q.push(next);
                }
            }
            for (trie *next : cur->inv_fails) {
                next->max_value = max(next->max_value, cur->max_value + next->output);
                if (--next->indegrees == 0) {
                    q.push(next);
                }
            }
        }

        //
        cout << answer << '\\n';
        delete root;
    }

    return 0;
}

길이 $15$ 이하의 $N$개의 문자열들과, $1000$ 이하의 자연수 $K$가 주어진다. N개의 문자열이 길이가 $K$인 임의의 문자열에서 등장할 수 있는 최대 갯수를 구하시오.

문제 예제를 살펴보면 “ABA”, “CB”, “ABACB”가 주어지고 K는 7이다. 주어진 문자열은 최대 4번 등장할 수 있고, 예로 “ABACBCB”가 있다. “ABA”가 한 번, “CB”가 두 번, “ABACB”가 한 번 등장한다.

5905번: 악당 로봇

USACO

luogu P3041 [USACO12JAN]视频游戏的连击 Video Game Comboslahlah的博客-CSDN 博客

풀이

풀이 자체는 계단 오르기 운동과 비슷하다. 차이점이라면 경우의 수가 아니라 최대 횟수인 점, 고려해야 하는 문자열이 $1$개가 아니라 여러개이기 때문에 KMP가 아니라 아호코라식을 이용한 점이다.

dp 배열은 길이가 $i$인 문자열에서 현재 $j$번 트라이 노드까지 탐색되었을 때 최대값이다. 트라이 노드의 번호를 인덱스로 쓰기 위해서 동적 할당을 쓰지 않았다.

또, 같은 자리에 여러개의 문자열이 동시에 나올 수 있으니 그 수를 헤아리기 위해서 아호코라식에서 output 변수를 boolean이 아닌 int형 변수로 선언하여 insert 및 fail build 시에 값을 계산해주었다.

유사코 공식 풀이가 다 이해가 되지 않았지만 문자열의 수와 길이가 크지 않아 아호코라식을 굳이 쓰지 않고도 계산할 수 있던 것으로 보인다.

#include <bits/stdc++.h>

using namespace std;

typedef long long ll;
typedef pair<int, int> pii;

int last_id = 1;
int go[20 * 15 + 2][3];
int fail[20 * 15 + 2];
int output[20 * 15 + 2];

void insert(const char *str) {
    int cur_id = 1; // 1 = root

    while (true) {
        if (*str == '\\0') {
            output[cur_id]++;
            break;
        }

        int idx = *str - 'A';
        if (!go[cur_id][idx]) {
            go[cur_id][idx] = ++last_id;
        }
        cur_id = go[cur_id][idx];

        str++;
    }
}

int dp[1003][20 * 15 + 2];

int main() {
    ios::sync_with_stdio(false); cin.tie(nullptr); cout.tie(nullptr);

    int N, K;
    cin >> N >> K;
    for (int n = 0; n < N; n++) {
        string str;
        cin >> str;
        insert(str.c_str());
    }

    queue<int> q;
    q.push(1);
    fail[1] = 1;

    while (!q.empty()) {
        int cur_id = q.front();
        q.pop();

        for (int i = 0; i < 3; i++) {
            int next_id = go[cur_id][i];
            if (!next_id) continue;

            if (cur_id == 1) {
                fail[next_id] = 1;
                q.push(next_id);
                continue;
            }

            int dest_id = fail[cur_id];
            while (dest_id != 1 && !go[dest_id][i]) {
                dest_id = fail[dest_id];
            }

            if (go[dest_id][i]) {
                dest_id = go[dest_id][i];
            }

            fail[next_id] = dest_id;
            if (output[dest_id]) {
                output[next_id] += output[dest_id];
            }

            q.push(next_id);
        }
    }

    memset(dp, -1, sizeof(dp));

    dp[0][1] = 0;

    for (int k = 0; k <= K; k++) {
        for (int id = 1; id <= last_id; id++) {
            if (dp[k][id] == -1) continue;

            for (int i = 0; i < 3; i++) {
                int cur = id;

                while (cur != 1 && !go[cur][i]) {
                    cur = fail[cur];
                }
                if (go[cur][i]) cur = go[cur][i];

                dp[k + 1][cur] = max(dp[k + 1][cur], dp[k][id] + output[cur]);
            }
        }
    }

    int answer = 0;

    for (int i = 1; i <= last_id; i++) {
        answer = max(answer, dp[K][i]);
    }

    cout << answer << '\\n';

    return 0;
}

준규가 계단을 오르내리는 운동을 U 와 D로 이루어진 문자열로 표현할 때, U는 계단을 한 칸 오르고 D는 한 칸 내려감을 나타낸다.

처음 위치를 $0$이라고 할 때, 계단의 위치가 음수가 되는 일은 없다.

또한 처음 위치와 도착 위치는 $0$으로 같다.

문자열의 일부가 주어질 때, 만들 수 있는 가능한 문자열의 모든 경우의 수를 $1,000,000,009$으로 나눈 나머지를 구하시오.

13438번: 계단 오르기 운동

풀이

DP 배열을 다음과 같이 정의한다.

⇒ 길이 $n$인 문자열에서 일치하는 부분의 길이가 $l$이고 현재 계단의 위치가 $k$일 때 경우의 수.

따라서 가장 처음 기저값은 $dp[0][0][0] = 1$가 된다.

어떤 dp값이 $dp[n][l][k]$라고 할 때, 이 값 뒤에 U가 오게 된다면 $dp[n + 1][l^\prime][k + 1]$가 된다. $l^\prime$의 값은 $l$을 통해 현재 일치하는 문자열의 길이를 알 수 있으므로 KMP 알고리즘을 이용해서 fail 배열을 통해 구할 수 있다.

다음과 같이 나타내 볼 수 있겠다.

이미 주어진 문자열이 모두 일치하는 경우에는 뒤에 어떤 문자를 붙여도 되므로 U 혹은 D를 붙였을 때 $K$의 값이 변화함만 신경써 주면 되겠다.

#include <bits/stdc++.h>

using namespace std;

typedef long long ll;
typedef pair<int, int> pii;

const ll MOD = 1e9 + 9;

ll pi[102];
ll dp[102][102][102];

int main() {
    ios::sync_with_stdio(false); cin.tie(nullptr); cout.tie(nullptr);

    int N;
    string str;
    cin >> N;
    cin >> str;

    {
        int j = 0;
        for (int i = 1; str[i]; i++) {
            while (j && str[i] != str[j]) j = pi[j - 1];
            if (str[i] == str[j]) pi[i] = ++j;
        }
    }

    dp[0][0][0] = 1;

    for (int n = 0; n <= N - 1; n++) {
        for (int k = 0; k <= N; k++) {
            for (int l = 0; l < str.length(); l++) {
                for (int i = 0; i < 2; i++) {
                    char c = "UD"[i];
                    int delta = c == 'U' ? 1 : -1;

                    if (k + delta < 0) continue;

                    int cur = l;
                    while (cur && str[cur] != c) cur = pi[cur - 1];
                    if (str[cur] == c) cur++;

                    dp[n + 1][cur][k + delta] += dp[n][l][k];
                    dp[n + 1][cur][k + delta] %= MOD;
                }
            }

            dp[n + 1][str.length()][k + 1] += dp[n][str.length()][k];
            dp[n + 1][str.length()][k + 1] %= MOD;

            if (k - 1 >= 0) dp[n + 1][str.length()][k - 1] += dp[n][str.length()][k];
            if (k - 1 >= 0) dp[n + 1][str.length()][k - 1] %= MOD;
        }
    }

    cout << dp[N][str.length()][0] << '\\n';

    return 0;
}