6-4-13. One Big User

Big, popular forums start out as small forums. One day we will find that one shard in our shared index is doing a lot more work than the other shards, because it holds the documents for a forum that has become very popular. That forum now needs its own index.

거대한 인기 있는 포럼은 작은 포럼으로 시작한다. 어느 날, 공유 index의 어떤 shard가 다른 shard보다 훨씬 더 많은 작업을 하고 있는 것을 발견했다. 왜냐하면, 해당 shard가 매우 인기 있는 포럼의 document를 가지고 있기 때문이다. 해당 포럼은 자신의 index를 필요로 한다.

The index aliases that we’re using to fake an index per user give us a clean migration path for the big forum.

사용자 별 index인 것처럼 속이기 위해 사용하는 index alias는 거대한 포럼에 대한 확실한 이전(migration) 경로를 제공한다.

The first step is to create a new index dedicated to the forum, and with the appropriate number of shards to allow for expected growth:

첫 번째 단계는 포럼에 대한, 예상되는 성장을 고려한, 적절한 수의 shard 설정으로, 새로운 전용 index를 생성하는 것이다.

PUT /baking_v1
{
  "settings": {
    "number_of_shards": 3
  }
}

The next step is to migrate the data from the shared index into the dedicated index, which can be done using a scroll query and the bulk API. As soon as the migration is finished, the index alias can be updated to point to the new index:

다음 단계는, scroll query와 bulk API 를 사용하여, 공유 index에서 전용 index로 데이터를 이전하는 것이다. 이전이 완료되면, index alias는 새로운 index를 가리키도록 업데이트될 수 있다.

POST /_aliases
{
  "actions": [
    { "remove": { "alias": "baking", "index": "forums"    }},
    { "add":    { "alias": "baking", "index": "baking_v1" }}
  ]
}

Updating the alias is atomic; it’s like throwing a switch. Your application continues talking to the baking API and is completely unaware that it now points to a new dedicated index.

alias를 업데이트하는 것은, 스위치를 누르는 것처럼, 원자성(atomic)을 가진다. 응용프로그램은 bakingAPI와 계속 통신하고, 그것이 이제 새로운 전용 index를 가리킨다는 것을 전혀 알지 못한다.

The dedicated index no longer needs the filter or the routing values. We can just rely on the default sharding that Elasticsearch does using each document’s _id field.

전용 index는 filter나 routing값이 더 이상 필요 없다. Elasticsearch가 각 document의 _id filed를 이용하는, 기본 sharding에 의존할 수 있다.

The last step is to remove the old documents from the shared index, which can be done by searching using the original routing value and forum ID and performing a bulk delete.

마지막 단계는 공유 index에서 기존 document를 제거하는 것이다. 이것은 원래의 routing 값과 forum ID를 사용하여 검색하고, bulk delete를 수행함으로싸 가능하다.

The beauty of this index-per-user model is that it allows you to reduce resources, keeping costs low, while still giving you the flexibility to scale out when necessary, and with zero downtime.

이 사용자 별 index(index-per-user) 모델의 장점은 resource를 감소시켜 비용을 낮게 유지한다는 점이다. 반면에 필요시에 수평확장의 유연성을 여전히 가지면서도, downtime이 없다는 점이다.