Go to Qiita Advent Calendar 2024 Top
LoginSignup
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@sugimount(sugi mount)

[Oracle Cloud] Traffic Management Steering Policies を使って、地球規模のフェールオーバーをやってみた

Posted at

はじめに

Oracle Cloud Infrastructure (以下OCI) には、Traffic Management Steering Policies という名前の DNS 名前解決をイイ感じに制御する機能があります。(名前が長い・・・)
Traffic Management Steering Policies の主なユースケースは以下のとおりです

  • フェイルオーバー
  • クラウド移行
  • 地域を基にしたトラフィック管理
  • 名前解決の重みづけで、カナリアリリース

今回の記事では、地域を基にしたトラフィック管理を行う手順を書きます。アクセス元のユーザーにより近い位置の名前解決機能を提供が出来ます。
具体的には、ユーザーが東京からアクセスしてきた場合は東京リージョンのサービスへ名前解決して、アメリカからアクセスしてきた場合は Ashburnリージョン(アメリカ) のサービスへ名前解決することが出来ます。
ユーザーはより近い位置へアクセスが出来、サービスへの接続速度を上がり、ユーザー体験を上げるメリットがあります。
また、東京リージョンに障害が発生した時には、自動的にアメリカリージョンへフェールオーバーすることも可能です。
世界規模でサービスを提供する時に非常に便利な機能です。

Traffic Management Steering Policies の動作概要

  • OCI DNS 管理している DNS Zone が必要。他の DNS サービスで Zone の管理を行っている場合は、Traffic Management Steering Policies は利用できない
  • Traffic Management Steering Policies を作成すると、DNS Zone 内でトラフィック管理されたレコードが生成される (OCI DNS の画面では確認出来ない)
  • トラフィック管理されたレコードで名前解決することでトラフィック制御を行う

事前準備

Traffic Management Steering Policies を動かすために、事前準備を行います。

OCI 環境構築

  • OCI DNS で DNS Zone sugioci.tokyo の管理をする。具体的な方法は、こちら を参照してください

1575110239599.png

  • Tokyo Region と Ashburn Region で、Compute Instance を 1台ずつ構成
    • Tokyo Compute1
      • 名前 : tokyo01
      • Global IP : 158.101.150.19
    • Ashburn Compute1
      • 名前 : ash01
      • Global IP : 150.136.138.41

Nginx導入

以下のコマンドで適当に Nginx 導入します

Firewalld停止

sudo systemctl stop firewalld
sudo systemctl disable firewalld

Nginx インストール

sudo yum install -y nginx

HTML ファイルを生成
東京とアッシュバーンで、表示する HTML を変更します。

sudo su -
cat <<'EOF' > /usr/share/nginx/html/index.html
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {        width: 35em;        margin: 0 auto;        font-family: Tahoma, Verdana, Arial, sans-serif;    }</style>
</head>
<body>
<h1>I am tokyo01 or ash01</h1>
</body>
</html>
EOF
systemctl restart nginx
systemctl enable nginx

Traffic Management Steering Policies

Traffic Management Steering Policies の設定をします。

OCI のメニューから、Networking > Traffic Management Steering Policies へ移動して、Create を押します

1575098456531.png

表示された画面で各種パラメータを入力し Create ボタンを押します。いくつかの重要なパラメーターを説明します

  • Answer Pool : トラフィック管理対象のエンドポイントを、IPアドレス or FQDN で指定して、Pool として定義。
  • Geolocation Steering Rules : アクセス元の地域を基に、どの Pool に紐づけをして名前解決するか指定。Global Catch-all を指定することで、アクセス元がルールに該当しない時の、トラフィック管理が可能。
  • Attach Health Check : トラフィック管理対象のエンドポイントをヘルスチェックする方法を指定。ADD NEWを選択すると新たに Health Check が新規作成される。新規作成された Health Check は、OCI 管理コンソールで確認が可能。
  • Attached Domains : 画面上だと (Optional) と表示されるが、トラフィック管理する上で指定が必須な項目。OCI DNS で管理している Zone と紐づけを行い、トラフィック管理された DNS レコードを生成する。画面の例では、SUBDOMAIN を空白にして、ZONE sugioci.tokyo を指定している。この結果、sugioci.tokyo でトラフィック管理された名前解決が出来るようになる。SUBDOMAIN を test と指定すると、test.sugioci.tokyo で名前解決が可能

screencapture-console-us-ashburn-1-oraclecloud-dns-steering-policies-2019-11-30-18_26_29.png

作成後、自動的に詳細画面に飛びます

1575107520194.png

Attached Domain 画面は、このような表示となります

1575107554731.png

OCI DNS 画面は以下の表示となります。Traffic Management Steering Policies で指定したレコードは表示されないため、注意しましょう

1575110239599.png

自動作成された Health Check は以下の画面となっています。
Health Check 自体の Vantage Point(アクセス元) は、AWS West EU3 Azure South Central US Google West US の3か所です。Editで変更が可能なので、必要な場合は適宜変更しましょう

1575110885494.png

Health Check の Metric には、運用に便利な Metric が収集されています。

1575110982850.png

日本からアクセス

手元のPC(東京)からWeb ブラウザを開いて http://sugioci.tokyo/ へアクセスを行うと、I am tokyo01 と表示されます。

1575107640834.png

dig コマンドの結果、東京で作成した Global IP 158.101.150.19 で名前解決されています。アクセス元を自動的に判断して、Tokyo 側へルーティングされています。

> dig +dnssec @8.8.4.4 sugioci.tokyo. A 

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> +dnssec @8.8.4.4 sugioci.tokyo. A 
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63067 
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;sugioci.tokyo.                 IN      A

;; ANSWER SECTION:
sugioci.tokyo.          9       IN      A       158.101.150.19

;; Query time: 62 msec 
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Sat Nov 30 18:58:25 DST 2019
;; MSG SIZE  rcvd: 58

アメリカからアクセス

GUI 環境を準備するのが面倒なので、Ashburn リージョンに作成した仮想マシンから、curl でアクセスを行います。
結果、I am ash01 と表示されています。アクセス元を自動的に判断して、Ashburn 側へルーティングされています。

$ curl -XGET http://sugioci.tokyo/ 
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {        width: 35em;        margin: 0 auto;        font-family: Tahoma, Verdana, Arial, sans-serif;    }</style> 
</head>
<body>
<h1>I am ash01</h1>
</body>
</html>

dig コマンドで名前解決を行うと、Ashburn で作成したWebサーバーの Global IP 150.136.138.41 で名前解決されています。

$ dig +dnssec @8.8.4.4 sugioci.tokyo. A   

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> +dnssec @8.8.4.4 sugioci.tokyo. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13364
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;sugioci.tokyo.                 IN      A

;; ANSWER SECTION:
sugioci.tokyo.          9       IN      A       150.136.138.41

;; Query time: 4 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Sat Nov 30 09:56:57 GMT 2019
;; MSG SIZE  rcvd: 58

フェールオーバーの動作確認

Tokyo - Ashburn で地域間のトラフィック制御を行うことが確認できました。次に、Tokyo Region の Webサーバーを停止して、フェールオーバー時の動作を確認しましょう。
どれくらいの時間にフェールオーバーが必要か確認するために、以下のコマンドを bash 上で実行します。

while true; do date; curl -m 3 -XGET http://sugioci.tokyo/; echo ""; sleep 1s; done

結論から記載すると、約1分30秒でフェールオーバーが出来ました。

  • Tokyo の Webサーバー停止時刻 : Sat Nov 30 19:03:44 GMT 2019
  • Ashburn 側に名前解決された時刻 : Sat Nov 30 19:05:23 DST 2019

実行例

$ while true; do date; curl -m 3 -XGET http://sugioci.tokyo/; echo ""; sleep 1s; done 
Sat Nov 30 19:05:01 DST 2019 
curl: (28) Connection timed out after 3000 milliseconds 

Sat Nov 30 19:05:05 DST 2019 
curl: (28) Connection timed out after 3001 milliseconds 
 
Sat Nov 30 19:05:10 DST 2019 
curl: (28) Connection timed out after 3001 milliseconds 

Sat Nov 30 19:05:14 DST 2019 
curl: (28) Connection timed out after 3001 milliseconds 

Sat Nov 30 19:05:18 DST 2019 
curl: (28) Connection timed out after 3001 milliseconds 

Sat Nov 30 19:05:23 DST 2019 
<!DOCTYPE html> 
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {        width: 35em;        margin: 0 auto;        font-family: Tahoma, Verdana, Arial, sans-serif;    }</style>
</head>
<body>
<h1>I am ash01</h1> 
</body>
</html>

Sat Nov 30 19:05:24 DST 2019 
<!DOCTYPE html> 
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {        width: 35em;        margin: 0 auto;        font-family: Tahoma, Verdana, Arial, sans-serif;    }</style>
</head>
<body>
<h1>I am ash01</h1>
</body>
</html>

なお、フェールオーバーの動作中はアメリカ側の名前解決には何も影響していないです。

フェールバック確認

Tokyo の Webサーバーを復旧すると、自動的に数十秒後にフェールバックが完了することを確認しました。

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?