Automate Geo-Failover with Prepared Queries(준비된 쿼리로 지역 장애 조치 자동화)

Automate Geo-Failover with Prepared Queries(준비된 쿼리로 지역 장애 조치 자동화)

Within a single datacenter, Consul provides automatic failover for services by omitting failed service instances from DNS lookups and by providing service health information in APIs.

단일 데이터 센터 내에서 Consul은 DNS 조회에서 실패한 서비스 인스턴스를 생략하고 API에서 서비스 상태 정보를 제공하여 서비스에 대한 자동 장애 조치를 제공합니다.

When there are no more instances of a service available in the local datacenter, it can be challenging to implement failover policies to other datacenters because typically that logic would need to be written into each application. Fortunately, Consul has a prepared query API that provides the capability to let users define failover policies in a centralized way. It's easy to expose these to applications using Consul's DNS interface and it's also available to applications that consume Consul's APIs.

로컬 데이터 센터에서 더 이상 사용할 수 있는 서비스 인스턴스가 없는 경우 일반적으로 해당 논리를 각 애플리케이션에 작성해야 하기 때문에 다른 데이터 센터에 대한 장애 조치 정책을 구현하는 것이 어려울 수 있습니다. 다행히 Consul에는 사용자가 중앙 집중식으로 장애 조치 정책을 정의할 수 있는 기능을 제공하는 준비된 쿼리 API가 있습니다. Consul의 DNS 인터페이스를 사용하여 애플리케이션에 이를 쉽게 노출할 수 있으며 Consul의 API를 사용하는 애플리케이션에서도 사용할 수 있습니다.

Failover policies are flexible and can be applied in a variety of ways including:

장애 조치 정책은 유연하며 다음과 같은 다양한 방식으로 적용할 수 있습니다.

●Fully static lists of alternate datacenters.

대체 데이터 센터의 전체 고정적 목록입니다.

●Fully dynamic policies that make use of Consul's network coordinate subsystem.

Consul의 네트워크 조정 하위 시스템을 사용하는 완전히 동적 정책입니다.

●Automatically determine the next best datacenter to failover to based on network round trip time.

네트워크 왕복 시간을 기반으로 장애 조치할 다음으로 가장 좋은 데이터 센터를 자동으로 결정합니다.

Prepared queries can be made with policies specific to certain services and prepared query templates can allow one policy to apply to many, or even all services, with just a small number of templates.

준비된 쿼리는 특정 서비스에 특정한 정책으로 만들 수 있으며 준비된 쿼리 템플릿을 사용하면 적은 수의 템플릿으로 하나의 정책을 많은 서비스 또는 모든 서비스에 적용할 수 있습니다.

This tutorial shows how to build geo failover policies using prepared queries through a set of examples. It also includes information on how to use prepared query templates to simplify the failover process

이 자습서에서는 일련의 예제를 통해 준비된 쿼리를 사용하여 지역 장애 조치(failover) 정책을 구축하는 방법을 보여줍니다. 또한 이것은 (자습서)장애조치의 과정을 단순화하기 위하여 준비된 쿼리 템플레이터을 사용하는 방법에 관한 정보를 포함합니다

Note: To complete this tutorial, you must have WAN gossip federation configured.

 

»Prepared query introduction

준비된 쿼리 소개

 

Prepared queries are objects that are defined at the datacenter level. They only need to be created once and are stored on the Consul servers. This method is similar to the values in Consul's KV store.

준비된 쿼리는 데이터 센터 수준에서 정의된 개체입니다. 한 번만 생성하면 되며 영사 서버에 저장됩니다. 이 방법은 Consul의 KV 저장소에 있는 값과 유사합니다.

Once created, prepared queries can then be invoked(호출하다) by applications to perform the query and get the latest results.

생성된 준비된 쿼리는 애플리케이션에 의하여 적용되어  쿼리를 수행하고 최신 결과를 얻을 수 있습니다.

Here's an example request to create a prepared query:

다음은 준비된 쿼리를 만들기 위한 요청의 예입니다.

This creates a prepared query called "banking-app" that does a lookup for all instances of the "banking-app" service with the tag "v1.2.3". This policy could be used to control which version of a "banking-app" applications should be using in a centralized way. By updating this prepared query to look for the tag "v1.2.4" applications could start to find the newer version of the service without having to reconfigure anything.

이것은 v 1.2.3.테그를 사용하여 뱅킹앱서비스의 모든 사레를 조회을 하는 뱅킹앱이라는 준비된 쿼리를 형성합니다 

 

Applications can make use of this query in two ways.

애플리케이션은 두 가지 방법으로 이 쿼리를 사용할 수 있습니다.

 

○ Since we gave the prepared query a name, they can simply do a DNS lookup for "banking-app.query.consul" instead of "banking-app.service.consul". Now with the prepared query, there's the additional filter policy working behind the scenes that the application doesn't have to know about.

준비된 쿼리에 이름을 지정했기 때문에 "banking-app.service.consul" 대신 "banking-app.query.consul"에 대한 DNS 조회를 수행할 수 있습니다. 이제 준비된 쿼리를 사용하면 애플리케이션이 알 필요가 없는 이면에서 작동하는 추가 필터 정책이 있습니다

 

○ Queries can also be executed using the prepared query execute API for applications that integrate with Consul's APIs directly.

 

Consul의 API와 직접 통합되는 애플리케이션을 위해 준비된 쿼리 실행 API를 사용하여 쿼리를 실행할 수도 있습니다.

 

»Failover policy types
»장애 조치 정책 유형

 

Using the techniques in this section you will develop prepared queries with failover policies where simply changing application configurations to look up "banking-app.query.consul" instead of "banking-app.service.consul" via DNS will result in automatic geo failover to the next closest federated Consul datacenters, in order of increasing network round trip time.

 DNS를 통해 "banking-app.service.consul"대신 단순히 "banking-app.query.consul"를 조회할 응용 프로그램 구성을 단순히 변경하는 장애조치 정책을 사용하여 준비된 쿼리를 개발할 이 부분에서 기술을 사용하는 것은  네트워크 왕복 시간이 증가하는 순서대로 다음 가장 가까운 연방 영사 데이터 센터에로 자동 지역 장애조치가 발생합니다.

Failover is just another policy choice for a prepared query, it works in the same manner as the previous example and is similarly transparent to applications. The failover policy is configured using the Failover structure, which contains two fields, both of which are optional, and determine what happens if no healthy nodes are available in the local datacenter when the query is executed.장애 조치는 준비된 쿼리에 대한 또 다른 정책 선택이며 이전 예와 동일한 방식으로 작동하며 애플리케이션에 유사하게 투명합니다. 장애 조치 정책은 두 개의 필드가 포함된 장애 조치 구조를 사용하여 구성되며 둘 다 선택 사항이며 쿼리가 실행될 때 로컬 데이터 센터에서 사용할 수 있는 정상적인 노드(접속점)가 없는 경우 어떤 일이 발생하는지 결정합니다.

 

★NearestN (int: 0) - Specifies that the query will be forwarded to up to NearestN other datacenters based on their estimated network round trip time using network coordinates.

•NearestN (int: 0) - 네트워크 좌표를 사용하여 예상되는 네트워크 왕복 시간을 기준으로 쿼리를 NearestN 다른 데이터 센터로 전달하도록 지정합니다

 

★Datacenters  - Specifies a fixed list of remote datacenters to forward the query to if there are no healthy nodes in the local datacenter. Datacenters are queried in the order given in the list.

★데이터 센터 - 로컬 데이터 센터에 정상적인 노드가 없는 경우 쿼리를 전달할 원격 데이터 센터의 고정 목록을 지정합니다. 데이터 센터는 목록에 지정된 순서대로 쿼리됩니다.

The following examples use those fields to implement different geo failover policies methods.

다음 예에서는 이러한 필드를 사용하여 다양한 지역 장애 조치 정책 방법을 구현합니다.

Static policy

정적 정책

 

A static failover policy includes a fixed list of datacenters to contact once there are no healthy instances in the local datacenter.

정적 장애 조치(failover) 정책에는 로컬 데이터 센터에 정상적인 인스턴스가 없는 경우 연결할 데이터 센터의 고정 목록이 포함됩니다.

Here's the example from the introduction, expanded with a static failover policy:

다음은 정적 장애 조치 정책으로 확장된 소개의 예입니다.

 

When this query is executed, such as with a DNS lookup to "banking-app.query.consul", the following actions will occur:"banking-app.query.consul"에 대한 DNS 조회와 같이 이 쿼리가 실행되면 다음 작업이 발생합니다.

 

※ Consul servers in the local datacenter will attempt to find healthy instances of the "banking-app" service with the required tag.

로컬 데이터 센터의 영사 서버는 필수 태그가 있는 "banking-app" 서비스의 정상적인 인스턴스를 찾으려고 시도합니다

 

※ If none are available locally, the Consul servers will make an RPC request to the Consul servers in "dc2" to perform the query there.

로컬에서 사용할 수 없는 경우 영사 서버는 "dc2"에 있는 영사 서버에 RPC 요청을 보내 그곳에서 쿼리를 수행합니다.

 

※ If none are available in "dc2", then an RPC will be made to the Consul servers in "dc3" to perform the query there.

 

Finally an error will be returned if none of these datacenters had any instances available

마지막으로 이러한 데이터 센터에 사용 가능한 인스턴스가 없으면 오류가 반환됩니다.

 

»Dynamic policy

동적인 정책 

 

In a complex federated environment with many Consul datacenters, it can be cumbersome to set static failover policies, so Consul offers a dynamic option based on Consul's network coordinate subsystem.

Consul 데이터 센터가 많은 복잡한 연합 환경에서는 정적 장애 조치 정책을 설정하는 것이 번거로울 수 있으므로 Consul은 Consul의 네트워크 좌표 하위 시스템을 기반으로 하는 동적 옵션을 제공합니다.

 

Consul continuously maintains an estimate of the network round trip time from the local datacenter to the servers in other datacenters it is federated with. Each server uses the median round trip time from itself to the servers in the remote datacenter. This means that failover can simply try other remote datacenters in order of increasing network round trip time, and if datacenters come and go, or experience network issues, this order will adjust automatically.

영사는 로컬 데이터 센터에서 연합된 다른 데이터 센터의 서버까지 네트워크 왕복 시간의 추정치를 지속적으로 유지합니다. 각 서버는 자체에서 원격 데이터 센터의 서버까지의 중간 왕복 시간을 사용합니다. 즉, 장애 조치는 네트워크 왕복 시간이 증가하는 순서대로 다른 원격 데이터 센터를 간단히 시도할 수 있으며 데이터 센터가 오가거나 네트워크 문제가 발생하면이 순서가 자동으로 조정됩니다

 

Here's the example from the introduction, expanded with a dynamic failover policy:

다음은 동적 장애 조치 정책으로 확장된 도입부의 예입니다.

 

This query is resolved in a similar fashion to the previous example, except the choice of "dc1" or "dc2", or possibly some other datacenter, is made automatically.

이 쿼리는 "dc1" 또는 "dc2" 또는 일부 다른 데이터 센터의 선택이 자동으로 이루어진다는 점을 제외하고 이전 예와 유사한 방식으로 해결됩니다.

 

»Hybrid policy

하이브리드 정책

 

It is possible to combine Datacenters and NearestN in the same policy. The NearestN queries will be performed first, followed by the list given by Datacenters.

동일한 정책에서 Datacenters와 NearestN을 결합하는 것이 가능합니다. NearestN 쿼리가 먼저 수행된 다음 Datacenters에서 제공한 목록이 수행됩니다.

Note, a given datacenter will only be queried one time during a failover, even if it is selected by both NearestN and is listed in Datacenters. This is useful for allowing a limited number of round trip-based attempts, followed by a static configuration for some known datacenter to failover to.

지정된 데이터 센터는 NearestN에서 선택하고 Datacenters에 나열되어 있더라도 장애 조치 중에 한 번만 조회됩니다. 이것은이 제한된 수의 왕복 기반 시도에 이어서,,  일부 알려진 데이터 센터에 대한 정적구성이 장애조치에 유용합니다  

 

»Prepared query template

준비된 쿼리 템플릿

For datacenters with many services, it can be challenging to define a geo failover policy for each service. To relieve this challenge, Consul provides a prepared query template that allows one prepared query to apply to many, and even all, services.

서비스가 많은 데이터 센터의 경우 각 서비스에 대한 지역 장애 조치 정책을 정의하는 것이 어려울 수 있습니다. 이 문제를 해결하기 위해 Consul은 하나의 준비된 쿼리를 많은 서비스, 심지어 모든 서비스에 적용할 수 있는 준비된 쿼리 템플릿을 제공합니다.

Templates can match on prefixes or use full regular expressions to determine which services they match.

템플릿은 접두사와 일치하거나 전체 정규식 표현을 사용하여 일치하는 서비스를 결정할 수 있습니다.

Below is an example request to create a prepared query template that applies a catch-all policy of dynamic geo failover to all services accessed by query lookup. By specifying the name_prefix_match type and an empty name, this query template's policy will be applied to any name that doesn't match a higher-precedence query.

다음은 쿼리 조회로 액세스하는 모든 서비스에 동적 지역 장애 조치의 포괄 정책을 적용하는 준비된 쿼리 템플릿을 만들기 위한 요청의 예입니다. name_prefix_match 유형과 빈 이름을 지정하면 이 쿼리 템플릿의 정책이 우선 순위가 더 높은 쿼리와 일치하지 않는 모든 이름에 적용됩니다.

Note: If multiple queries are registered, the most specific one will be selected, so it's possible to have a template like this as a catch-all, and then apply more specific policies to certain services.

참고: 여러 쿼리가 등록된 경우 가장 구체적인 쿼리가 선택되므로 이와 같은 템플릿을 포괄하여 특정 서비스에 보다 구체적인 정책을 적용할 수 있습니다.

With this one prepared query template in place, simply changing application configurations to look up banking-app.query.consul instead of banking-app.service.consul via DNS will result in automatic geo failover to the next closest federated Consul datacenters, in order of increasing network round trip time.

이 자리에 있는 하나의 준비된 쿼리 템플릿을 사용하면 DNS를 통해 뱅킹 앱.service.consul 대신 뱅킹 앱.query.consul을 검색하도록 응용 프로그램 구성을 변경하면 네트워크 왕복 시간이 증가하는 순서대로 다음 가장 가까운 연방 영사 데이터 센터로 자동 지오 페일 오버가 발생합니다.

Next steps

다음단계

In this tutorial, you learned how to use prepared queries for failover when integrating Consul with other applications. You can now configure your policies to failover to the nearest federated datacenter or to a list of secondary datacenters. You can also create a prepared query template which will help you reduce some complexity of creating policies for each individual service.이 자습서에서는 Consul을 다른 애플리케이션과 통합할 때 장애 조치를 위해 준비된 쿼리를 사용하는 방법을 배웠습니다. 이제 가장 가까운 연합 데이터 센터 또는 보조 데이터 센터 목록으로 장애 조치하도록 정책을 구성할 수 있습니다. 또한 각 개별 서비스에 대한 정책 생성의 복잡성을 줄이는 데 도움이 되는 준비된 쿼리 템플릿을 생성할 수 있습니다