Celery: 기능: Beat는 동시 호출을 피해야 합니다.

이것은 kombu.pidbox 를 사용하여 해결할 수 있으며, 이것은 또한 celeryd 가 동일한 이름의 노드가 이미 실행 중임을 감지하는 방법이기도 합니다. celerybeat 는 중앙 집중식이므로 고정 노드 이름을 사용할 수 있습니다.

부작용으로 원격 제어 명령으로 celerybeat를 제어할 수 있습니다(예를 들어 일정을 다시 로드하거나 가까운 장래에 기한을 확인하는 명령이 있을 수 있음). 당신이 나에게 묻는다면 그것은 꽤 멋진 부작용입니다.

동일한 클러스터에서 여러 인스턴스를 실행하는 사용 사례가 있으므로 더 많은 계획이 필요합니다. 예를 들어 일정을 여러 조각으로 "분할"하는 경우입니다. 최소한 각 인스턴스에 대한 노드 이름을 선택할 가능성이 있어야 합니다. 2.3.0으로 연기.

celerybeat 실행하는 상자가 그 자리를 대신할 새 celerybeat 인스턴스를 시작하기 위한 적절한 대체 없이 오프라인이 되는 문제가 있었습니다. celerybeat 를 실행하는 데 권장되는 HA 방법은 무엇입니까?

kombu.pidbox 접근 방식을 사용하면 고정 노드 이름으로 인스턴스가 이미 실행 중임을 감지하고 폴링하여 활성 상태로 승격하는 것을 감지하면 잠자기 상태가 되는 celerybeat 의 여러 인스턴스를 실행할 수 있습니까? 인스턴스가 다운되나요?

여러 활성 인스턴스를 실행하는 것이 흥미롭게 들립니다. 일정을 공유하는 것 외에 어떤 다른 이점이 있습니까?

+1

+1

이는 일정의 탄력성이 중요하므로 대규모 배포의 경우 실제로 우려되는 사항입니다.

+9999 ;)
kombu.pidbox 솔루션을 사용하는 데 문제가 있습니까? 샤딩과 멋진 기능이 없어도 이것은 훌륭하고 매우 편리할 것입니다. 지금은 다른 호스트에서 celerybeat를 수동으로 시작해야 합니다.

Pidbox를 사용할 수 있지만 문제는 비트가 소비자가 아니라는 것입니다. '여기에 비트 인스턴스가 있습니까?'와 같은 브로드캐스트 메시지에 응답하려면 브로드캐스트 큐의 메시지를 지속적으로 수신 대기해야 하며 현재는 메시지를 예약 중이기 때문에 할 수 없습니다.

기술적으로 두 번째 스레드를 사용할 수 있지만 성능이 저하될 수 있으며 이 기능에만 많은 오버헤드가 발생합니다.

두 번째 해결책은 잠금 장치를 사용하는 것이지만 잠금을 해제해야 하는 단점이 있습니다. 즉, 비트 프로세스가 종료되면 부실 잠금은 새 인스턴스를 시작하기 위해 수동 개입이 필요합니다.

또한 잠금에 대해 2초의 시간 초과가 있을 수 있으며 1초마다 잠금을 업데이트할 수 있습니다. 그러면 잠금이 유지되면 새 인스턴스가 2초 동안 기다려야 함을 의미합니다.

amqp의 잠금은 대기열을 선언하여 만들 수 있습니다(예: `queue_declare('celerybeat.lock', arguments={'x-expires': 2000}``)

+1

나는 이것을보고 싶다

+1

+1

+1도

+1

실제로 kombu.pidbox 솔루션이나 이 문제를 해결하는 다른 메커니즘을 구현한 사람이 있습니까? 그렇다면 공유하십시오. 여전히 최선의 방법이 무엇인지 궁금해하는 사람들이 많습니다.

이것 때문에 셀러리에서 완전히 멀어진 사람이 있습니까? 그것도 알고 싶습니다.

편집하다:

Google 토론(https://www.google.co.in/search?q=celerybeat+lock&aq=f&oq=celerybeat+lock&aqs=)을 통해 이 요지(https://gist.github.com/winhamwr/2719812)를 찾았습니다. chrome.0.57j62l3.2125j0&sourceid=chrome&ie=UTF-8).

또한 누군가가 celerybeat에 대해 공유 pidfile을 직접 사용했는지 궁금합니다. AWS의 EBS 또는 S3 버킷... celerybeat --pidfile=/path/to/shared/volume .

나는 현재 마스터(3.1 dev)에 소비자를 위한 가십 단계가 있다는 것을 알아차렸습니다. 내장된 비트 프로세스를 조정하기 위해 가십 대기열과 리더 선출을 활용할 수 있습니까? 즉, 각 작업자는 포함된 비트 프로세스를 실행하지만 리더만 정기 작업을 대기열에 넣습니다. 이것은 공유 일정 저장을 가정할 수 있습니다.

@mlavin 이것은 작동할 수 있지만 브로드캐스트를 지원하는 브로커 전송에만 해당됩니다.

pidbox 솔루션의 문제는 celerybeat 프로그램이 비동기 I/O를 사용하도록 다시 작성되어야 한다는 것입니다.
스케줄러가 차단하고 있기 때문에 현재 작업을 소비하고 생성할 수 없습니다.

대부분의 프로덕션 배포에는 비트 프로세스를 위한 전용 호스트가 있고 --pidfile 를 사용하면 여러 인스턴스를 시작하지 않아도 되기 때문에 대부분의 경우 이것은 전혀 필요한 기능이 아닙니다.

나는 종종 이 문제의 영향을 받는 사람들이 데몬화에서 -B 옵션을 사용하는 사람들이라는 것을 발견했습니다.
스크립트를 작성한 다음 해당 설정을 다른 호스트에 복제합니다.

그래서 나는 그것이 성가신 것을 이해하지만 그것이 중요하다고 생각하지 않습니다. 진정으로 솔루션을 원하는 사람이 있다면 기여하거나 저를 고용/기부하여 구현하도록 할 수 있습니다.

uWSGI 를 사용하여 다른 노드로 폴백하는 단일 비트 프로세스를 가질 수 있습니다.

+1, 동일한 Amazon EC2 인스턴스를 시작하고 하나의 노드에서만 실행되는 주기적 작업이 있으면 좋을 것입니다. 그 동안 나는 uWSGI를 사용하려고 노력할 것입니다. 제안에 감사드립니다.

+1

+1

저는 직장에서 일정 관리를 위해 Celerybeat를 사용하는 사례를 만들어 왔지만 즉시 HA를 사용하지 않는 것은 매우 어렵게 만들고 있습니다. 사실 이것 때문에 아예 버릴 것 같습니다. 간단히 말해서, 1개의 Celerybeat 인스턴스만 실행하면 단일 실패 지점이 되므로 프로덕션 준비가 되지 않습니다.

@junaidch 이것 때문에 셀러리를 떨어뜨리면 안 된다고 생각합니다. 항상 모든 서버에서 스케줄러를 실행할 수 있으며 주기적인 작업의 경우 일종의 잠금 메커니즘을 사용하여 어떤 식으로든 겹치지 않고 너무 자주 실행되지 않도록 합니다. 또한 스케줄러를 하위 클래스로 지정하고 거기에서 잠금을 수행하거나 작업 수준 잠금을 건너뛰고 대신 스케줄러에서 모든 작업을 수행할 수 있습니다.

이것은 일종의 해결 방법이기 때문에 샐러리에 내장된 기능을 갖는 것이 더 좋을 것이지만 여전히 프로덕션에서 잘 사용할 수 있습니다.

@23doors 감사합니다.

내 작업은 이미 Redis 잠금을 유지하여 작업의 다른 인스턴스가 실행되지 않도록 합니다. 2개의 다른 컴퓨터에서 2개의 비트를 실행하고 작업이 5분 간격으로 예약된 경우 두 비트가 작업을 대기열로 푸시하더라도 작동할 것이라고 생각합니다. 핵심 기능에 대한 해결 방법을 구현해야 할 때 채택 사례를 만드는 것이 더 어려워집니다.

하위 분류 권장 사항을 조사하겠습니다. 그것은 더 깨끗한 접근 방식 일 수 있습니다.

제안에 감사드립니다!

Lulu에서는 간단한 클러스터 싱글톤 관리자(BeatCop이라는 이름)를 작성하여 이 문제를 해결했습니다. 만료되는 Redis 잠금을 사용하여 Celery 작업자의 자동 크기 조정 풀에서 실행되는 Celerybeat가 하나만 있는지 확인합니다. 해당 Celerybeat에 문제가 발생하면(예: 인스턴스가 확장되거나 종료되거나 Celerybeat가 충돌하는 경우) 다른 노드가 자동으로 새 Celerybeat를 생성합니다. 우리는 BeatCop 소스를 공개했습니다 .

@ingmar 우리는 같은 이유로 이 https://github.com/ybrs/single-beat 를 썼습니다. 지난번에 확인했을 때 귀하의 의견을 보지 못했습니다. 우리는 또한 다른 사람들에게 유용할 수 있는 오픈 소스로 출시했습니다. 더 많거나 적은 동일한 작업을 수행합니다.

내가 볼 수 있는 한, beatcop과의 주요 차이점 - 우리는 pyuv를 사용합니다 - 그래서 beatcop이 더 이식성이 뛰어나고 종속성이 덜하다고 생각합니다 - 자식의 stderr 및 stdout을 부모로 리디렉션하고 자식이 동일한 코드로 죽으면 종료하고 다음과 같이 구성합니다. 환경 변수. 그래서 감독자에 추가하기가 조금 더 쉽습니다.

다른 사람에게 유용할 수 있기를 바랍니다.

+1

+1

Consul 키-값을 잠금 컨트롤러로 사용하는 것을 고려 중입니다. 이 접근 방식을 시도한 사람이 있습니까? 따라서 하나의 인스턴스가 작동하는 동안 다른 인스턴스는 잠금이 업데이트되지 않을 때까지 "휴면"한 다음 영사 선거 메커니즘이 타임스탬프가 지정된 키 값을 업데이트할 사람을 결정합니다. 잠금을 업데이트하는 사람이 작동하는 사람입니다.

@ingmar 감사합니다! 내 작업자 클러스터에서 이 작업을 수행하겠습니다.

현재 구현에서 +10은 처음에 분산 대기열을 사용하는 이유에서 벗어나는 단일 실패 지점을 의미합니다.

+1

+1

이것은 v5.0.0에 있을 것 같습니다 https://github.com/celery/celery/milestones/v5.0.0

+1

현재 리소스와 마찬가지로 이 작업을 완료하는 데 10년이 걸립니다.

죄송합니다. 이것은 소위 "분산" 대기열에 심각한 문제입니다. 구현하는 데 시간이 오래 걸리더라도 결국 수정해야 합니다. _지금 당장_ 리소스가 없기 때문에 완벽하게 유효한 문제를 종료하는 것은 옳지 않은 것 같습니다. 다시 열어 현재 우선 순위가 낮음을 나타내는 레이블을 적용할 수 있습니까?

폐쇄 이유가 터무니없이 갑작스러웠다는 것을 알고 있으므로 소프트웨어 사용자로서 귀하의 감정을 이해할 수 있지만 기술적으로 Beat는 추가 기능에 가깝습니다. Celery의 나머지 부분과 완전히 분리되었으며 구현을 단순하게 유지하기 위해 의도적으로 비분산형으로 설계되었습니다. 이미 Celery를 사용하고 있는 사용자를 위한 보너스로 Python에서 cronjob을 정의하는 깔끔한 방법으로 시작했으며 점점 더 많은 사람들이 Celery를 cron 대체품으로 사용했습니다.

이 문제는 6년 동안 공개되었으며, 자주 요청되고 수많은 회사가 이에 의존하고 있지만 아무도 구현 비용을 지불하겠다고 제안한 적이 없습니다.

실제로 회사가 후원하는 것이 흥미로울 것이라고 생각한 문제 중 하나였습니다. 회사가 기능, 버그 수정 또는 프로덕션 문제 해결을 돕기 위해 비용을 지불하는 것은 일반적이지 않습니다. 나는 아마 그것들을 한 손으로 셀 수 있을 것입니다(당신은 굉장합니다), 그래서 이제 저는 그 생각이 얼마나 순진한지 압니다 :)

나는 오늘 이 문제의 복제본을 닫았습니다. #1495를 참조하십시오. 이 문제를 해결하기 위한 풀 리퀘스트가 있었고 몇몇은 유망했지만 주어진 구현이 작동한다는 것을 증명하는 데 필요한 헌신을 감안할 때 아직 제대로 검토할 시간이 없었습니다. 어쩌면 이것은 누군가를 행동에 옮기게 할 수도 있습니다. 그렇지 않더라도 아무도 작업하지 않는 6년 동안 기능 요청을 열어 두는 것보다 낫다고 생각합니다. 이것은 또한 이 문제가 해결되기를 원하는 사용자들에게 일종의 실례입니다.

@ 충분히 공정하게

시간을 내어 이유를 자세히 설명해 주셔서 감사합니다.

@ask 클러스터의 모든 노드에서 공유되는 NFS 볼륨 내에서 celerybeat-schedule 파일( celery.beat.PersistentScheduler )을 찾아 이 문제를 피할 수 있는지 궁금합니다.

PersistentScheduler 클래스는 shelve 를 데이터베이스 모듈로 사용하므로 celerybeat-schedule 파일에 대한 동시 쓰기는 의도적으로 방지되어야 합니다. shelve 문서 에서 발췌한 내용입니다.

선반 모듈은 선반 개체에 대한 동시 읽기/쓰기 액세스를 지원하지 않습니다. (여러 동시 읽기 액세스는 안전합니다.) 프로그램에 쓰기용으로 선반이 열려 있는 경우 다른 프로그램에서는 읽기 또는 쓰기용으로 선반을 열어서는 안 됩니다.

다음과 같이 셀러리 비트를 시작한다고 가정합니다.

celery -A project-name beat -l info -s /nfs_shared_volume/celerybeat-schedule

여기서 /nfs_shared_volume 는 공유 볼륨(예: AWS Elastic File System에서 관리)입니다. 클러스터의 모든 노드에서 하나의 셀러리 비트 프로세스가 실행되더라도 일정이 엉망이 되지 않을 것이라고 기대할 수 있습니까?

@mikeschaekermann 내가 문서를 올바르게 읽고 있다면 shelve 동시 쓰기 액세스를 방지하기 위해 노력하지 않습니다. 그냥 놔두지 말라고 합니다. 인용한 섹션에서는 "Unix 파일 잠금을 사용하여 이 문제를 해결할 수 있지만 이는 Unix 버전에 따라 다르며 사용된 데이터베이스 구현에 대한 지식이 필요합니다."라고 말합니다.

@ze-phyr-us 나는 당신이 옳다고 생각하고 shelve 문서를 잘못 해석했습니다. 그래도 Scheduler 백엔드가 일정에 따라 원자적 작업을 보장한다고 가정하면 문제가 해결될지 궁금합니다. @ask django-celery-beat 패키지 가 문제를 해결하기 위해 원자성을 지원합니까? 일부 업데이트를 수행하기 위해 트랜잭션을 사용하는 것을 보았습니다.

분산/자동 크기 조정 친화적인 셀러리 비트를 검색하는 동안 여기까지 오고 Redis를 백엔드로 사용하게 되어 기쁩니다. 위에서 언급한 BeatCop과 싱글 비트를 모두 시도했지만 결국 RedBeat를 선택

안녕하세요 @ddevlin
저도 비슷한 문제를 겪고 있습니다. 싱글비트를 사용하면서 어떤 문제가 있었나요? 또한 너무 많지 않다면 여러 서버에 대해 redbeat를 구성한 방법에 대한 구현 샘플을 공유할 수 있습니다.

@ankur11 단일 비트는 하나의 celery beat 인스턴스만 실행되도록 보장하지만 인스턴스 간에 일정 상태를 동기화하지 않습니다.

15분마다 실행되도록 의도된 주기적인 작업과 함께 기본 스케줄러를 사용하고 작업이 마지막으로 실행된 후 14분 후에 단일 비트로 장애 조치가 있는 경우 작업은 새 셀러리 비트 이후 15분까지 실행되지 않습니다. 인스턴스가 시작되어 29분 간격이 발생했습니다.

인스턴스 간에 일정 상태를 공유하려면 대체 스케줄러 를 사용해야 했습니다. django-celery-beat 는 Celery 문서에 언급된 대안이지만, 저는 Redis를 Celery 백엔드로 이미 사용하고 있었기 때문에 일정 동기화를 위한 백엔드로 Redis를 사용하는 것을 선호했습니다.

Redbeat는 Redis가 지원하는 공유 일정 상태와 잠금을 모두 포함하여 하나의 인스턴스만 작업을 예약하도록 하므로 단일 비트나 BeatCop을 사용하기 시작한 후에는 필요하지 않았습니다.

우리의 구현에서 celery beat는 모든 인스턴스에서 Supervisord에 의해 시작되며 Redbeat는 스케줄러로 사용됩니다(예: exec celery beat --scheduler=redbeat.RedBeatScheduler --app=myproject.celery:app ). 불행히도 작업 관련 코드를 공유할 수는 없지만 일반적인 구현에 대한 추가 질문에 답변해 드리겠습니다.

@mikeschaekermann 셀러리 비트를 /use/bin/flock으로 감싸서 액세스를 잠글 수 있습니다 ...

flock /nfs/lock.file celery beat ...

NFS 잠금 구현을 신뢰한다고 가정합니다. :)

이렇게 하면 로커가 죽을 때까지 하나만 실제로 실행되고 나머지는 차단됩니다.

@mikeschaekermann 셀러리 비트를 /use/bin/flock으로 감싸서 액세스를 잠글 수 있습니다 ...

무리 /nfs/lock.file 셀러리 비트 ...

NFS 잠금 구현을 신뢰한다고 가정합니다. :)

이렇게 하면 로커가 죽을 때까지 하나만 실제로 실행되고 나머지는 차단됩니다.

나는 이 방법을 시도했다. 불행히도 NFS 잠금을 보유하고 있는 클라이언트가 NFS 서버에 대한 연결을 끊으면 NFS 서버에서 잠금을 취소하고 다른 클라이언트에 제공할 수 있습니다. 원래 잠금 홀더가 연결을 다시 얻었을 때 플록은 잠금이 취소되었음을 깨닫지 못하므로 이제 두 개의 노드가 자신을 '리더'라고 믿게 됩니다.

Postgres에서 자문 잠금을 사용하게 되었습니다. 나는 django_pglocks이 모듈 사용하고 서브 프로세스에 셀러리 비트를 실행하는 장고 관리 명령했다.

Postgres에서 자문 잠금을 사용하게 되었습니다. django_pglocks 모듈을 사용하고 하위 프로세스에서 celery beat를 실행하는 Django 관리 명령을 만들었습니다.

이것은 내가 NFS를 사용할 때 본 것과 동일한 문제에 취약할 수 있는 것 같습니다. 잠금을 보유하고 있는 클라이언트가 Postgres 서버와 연결이 끊기거나 Postgres 서버가 다시 시작되면 어떻게 됩니까?

@swt2c 아, 물론 맞습니다! 일종의 생존이 필요합니다.

지금 내가 하고 있는 일:

def _pre_exec():
    prctl.set_pdeathsig(signal.SIGTERM)

with advisory_lock(LOCK_ID) as acquired:
            assert acquired
            logging.info("Lock acquired: %s", acquired)
            p = subprocess.Popen(
                celery,
                shell=False,
                close_fds=True,
                preexec_fn=_pre_exec,
            )
            sys.exit(p.wait())

advisor_lock 는 재귀를 지원하지만 실제로 db를 확인하는지 여부는 알 수 없습니다.

In [8]:  with advisory_lock('foo') as acquired:
   ...:     print acquired
   ...:     while True:
   ...:        with advisory_lock('foo') as acquired:
   ...:           print acquired
   ...:        time.sleep(1)
   ...:       

# Yes, it does:

True
True
True
<shutdown the instsance>
InterfaceError: cursor already closed

그래서 ... 잠금/폴링을 계속 재획득하고 실패하면 비트를 죽이도록 수정할 수 있습니다. 상호 배제를 보장하지는 않지만 내 목적에 충분할 수 있습니다.

제 경우 동시 비트는 낭비적인 성가심이지만 무결성 문제는 아닙니다. 그렇다면 작업을 권고 잠금으로 래핑할 수도 있습니다. 이 작업은 db가 다운되면 어쨌든 작업이 실패합니다.

나는 또한 비트를 DB에 저장하고 있지만 db가 다운 될 때 비트가 무엇을하는지 테스트하지 않았습니다.

@ddevlin 저도 구현하려고 생각했던 솔루션

그러나 redbeat-2 가 다운될 때 감독자가 redbeat-1 자동으로 다시 시작하는 논리를 공유할 수 있다면 큰 도움이 될 것입니다.

이것은 supervisor 에 대한 이해가 부족하기 때문일 수 있지만 autorestart=True 는 적어도 한 번 RUNNING 상태에 들어간 프로그램에만 효과적인 것 같습니다.

내 문제는 다음과 같습니다.

1. 내 Supervisor.conf에 celery beat redbeat.RedBeatScheduler 두 개의 program 가 있습니다.
2. 시작하는 감독자, 한 beat ( beat-1 ) 잠금을 받고 실행하는 동안 다른 ( beat-2 ) 몇 번 시작을 시도하고 FATAL 상태( Seems we're already running? 오류 포함).
3. 이상적으로는 beat-1 가 중지되면 감독자가 beat-2 시작하기를 원합니다.
4. 그러나 처음부터 RUNNING 상태가 아니므로 발생하지 않습니다. 즉, beat-1 중지하면 중지되고 아무 일도 일어나지 않습니다.

내 머리 꼭대기에서, 해결책은 supervisorctl restart all 매 5초마다 계속하는 cron 를 갖는 것이지만, 어떻게 달성할 수 있었는지에 대한 생각을 얻고 싶었습니다. 감독자와의 중복.

@harisibrahimkv 님 , 문제는 동일한 호스트에서 두 개의 동일한 셀러리 비트 인스턴스를 시작한다는 것입니다. ERROR: Pidfile (celerybeat.pid) already exists. 에 대한 로그에 beat-2 ERROR: Pidfile (celerybeat.pid) already exists. 가 표시될 것으로 예상합니까? 동일한 호스트에서 두 개의 celery beat 인스턴스를 실행하면 이들 간의 장애 조치를 테스트하는 데 유용할 수 있지만 실제 중복성을 위해서는 여러 호스트에서 실행되는 celery beat를 원할 것입니다.

동일한 호스트에서 여러 인스턴스를 실행하려면 감독자가 --pidfile 인수로 인스턴스를 시작하고 별도의 pidfile을 제공하도록 합니다. 예:

# beat-1 
celery beat --scheduler=redbeat.RedBeatScheduler --pidfile="beat-1.pid" ...
# beat-2
celery beat --scheduler=redbeat.RedBeatScheduler --pidfile="beat-2.pid" ...

두 인스턴스 모두 감독자 아래에서 성공적으로 시작되어야 하지만 로그 파일을 확인하면 둘 중 하나만 작업을 예약해야 합니다. 해당 인스턴스를 중지하면 다른 인스턴스가 작업 일정을 인계받는 것을 볼 수 있습니다.

우리의 목표는 셀러리 작업자와 셀러리 비트를 감독하에 실행하는 동일한 호스트의 자동 크기 조정 풀을 갖는 것이었습니다. 각 호스트에는 단일 셀러리 비트 인스턴스가 있습니다. 이 구성에서 celery beat는 모든 호스트에서 성공적으로 시작해야 하지만 잠금을 획득하지 않은 모든 celery beat 인스턴스는 효과적으로 상시 대기 상태가 되며 작업을 예약하지 않습니다(풀의 모든 호스트가 작업을 처리하지만). 잠금이 있는 인스턴스가 중지되면(예: 풀이 축소되거나 풀에서 호스트의 롤링 업그레이드를 수행할 때) 대기 인스턴스 중 하나가 잠금을 획득하고 예약 작업을 인수합니다.

@ddevlin 다시 돌아와서 인터넷을 멋진 곳으로 만들어주셔서

1. pidfile 비트가 작동했고 다른 하나가 중지되었을 때 beat-2 이 작업을 수행하는 것을 보고 너무 기뻤습니다. CELERYBEAT_MAX_LOOP_INTERVAL = 25 비트의 시간을 구성할 수 있습니다(셀러리 3.x에서).

2. 예, 실제 중복성을 위해 이 설정을 다른 인스턴스에 모두 적용할 계획입니다. 사용 중이신 설정을 설명해 주셔서 감사합니다. 지금 작업에 들어갑니다. "동일한 인스턴스의 다중 호스트" 설정은 올바르게 이해했듯이 이 수퍼바이저 설정에서 장애 조치의 개념이 작동하는지 여부를 처음에 검증하는 것이었습니다.

따뜻한 감사,
인도 아대륙 최남단의 작은 마을에서. :)