https://blogs.oracle.com/cloud-infrastructure/getting-started-with-traffic-management
先月の間に、Oracle Cloud InfrastructureではDynでの研究開発により、われわれの第二世代クラウドのネイティブ・エッジマネジメント能力に重要な機能強化をもたらすいくつかの新サービスをリリースしました。それらのサービスには以下が含まれています：
- Traffic Management Steering Policies
- Health Checks (Edge)
本日お話ししたいのは、エンタープライズ用途のグローバルに分散したアプリケーションサービスをTraffic Managementを使ってどのように構成し、制御し、最適化するかです。
前提条件
Traffic Management Steering Policiesを使う前提として、ドメイン（またはサブドメイン）をOracle Cloud Infrastructure DNSサービスの管轄下に置く必要があります。多くの組織ではサブドメインを特にソースサービスのグローバルロードバランシングを行わせる用途で管理させています（例：<service>.glb.domain.com）。詳細な情報はOverview of the DNS Serviceをご覧ください。
このポストでは例としてDNS経由で応答する pheatsols.com.au ドメインを使っています。
また、例の中ではふたつのApacheインスタンスをAshburnとLondonのリージョンに置いており、インスタンスの地理的な場所を記したシンプルなHTMLページを応答します。
直接IPアドレスを打ち込むと以下のメッセージが返ってきます：
シナリオ
上述のセットアップはふたつの地理的に分散した場所にサーバーがある（とても）ベーシックなWebアプリケーションを例としたものです。従来のDNSの構成では、ユーザーをこれらのアプリケーションにダイレクトする方法は限られており、また、それぞれ以下の制約がありました：
- エントリーを分ける：サービスポイントごとにDNSエントリーを分けて作成（たとえばlondon.pheatsols.com.auとashburn.pheatsols.com.au）してユーザーに近いほうを選ぶよう指示するやり方です。この方法では正しいサーバーを選ぶ責任をユーザー側に負わせるということになりますが、ユーザーエクスペリエンスは水準以下になってしまうでしょう。障害の際には、ユーザーに直接コミュニケーションしなければならないえすし、プログラムからのサービスアクセスも書き換えなければなりません。
- 単一のエントリー：単一のDNSエントリーを作成（たとえばapplication.pheatsols.com.au）してこれをプライマリーサイトに向けておき、障害時や切り戻しの際にエントリーをマニュアルで更新するという方法です。この方法ではワークロードのバランシングはできません、つまり、Active-Passiveモードでの運用になります。障害時にDNSエントリーを更新しても伝播には多少時間がかかりますので、接続不能時間が伸びてしまうかもしれません。
- ラウンドロビン：同じアドレスに対して複数のDNSエントリーを作成しておき、大まかに言うとルックアップごとに向けるサーバーを変えるDNSラウンドロビンを行わせる方法です。この方法ではノード障害が起きた場合、提供する接続がとぎれとぎれになってしまいます（リクエスト2回に1回は死んでいるノードにトラフィックを送ってしまう）。アプリケーションアーキテクチャによっては、ラウンドロビンではセッションの中で以前に接続していたサーバーとは違うサーバーに回されてしまい問題が起きるかもしれません。
理想としては、単一のDNSエンドポイントが、ユーザーリクエストをもっとも近いサーバーに自動的に転送し、しかしノード障害時には別の機能しているサーバーにシームレスにフェイルオーバしてくれることが望ましいでしょう。Traffic Management Steering Policiesにより（および密接に連携したHealth Checksサービスにより）まさにそれが実現できるのです。
Traffic Management Steering Policyの作成
まず始めに、Oracle Cloud Infrastructureのコンソールにログインします。ナビゲーションメニューからEdge Servicesを選択し、そしてTraffic Management Steering Policiesを選びます。
Create Traffic Management Steering Policyをクリックします。
Traffic Steering Policyの種類が表示されます。送信元の地理的な条件に応じて動的にリクエストをルーティングするGeolocation Steeringを選択しましょう（他の種類のPolicyについてはこのポストの後の章「Other Policy Types」で説明します）。
Policyの名前を入力し、TTL（Time To Live）を設定します。TTLはDNSサーバーが返信があったエントリーをキャッシュしておく期間を定義するものです。この値をアプリケーションのクリティカル性（TTLを低くすると、応答がないサーバーアドレスがキャッシュされている期間も短くなります）と、DNSサーバーの応答速度（TTLが短すぎるとDNSサーバーおよびクライアントはいつもクエリを名前解決しなければならなくなります）のバランスで決めます。この例ではデフォルトの60秒のままにしておきます。
次に、（この例においては）地理的な場所にもとづくサーバーグループであるAnswer Poolを定義していきます。この例では2つのプール、ashburnとlondonがありそれぞれひとつのサーバーが属しています。もしそれぞれの場所に複数のサーバーがある場合は、あるサーバーがメンテナンス中でありトラフィックを流したくない際などに、そのサーバーを不適合としてマークしておくことができます。
いよいよここでGeolocation Steering Policyの設定をしていきます。ルールは上から下の順序でパースされます。この例では、Rule 1はNorth America、South America、OceaniaおよびAntarcticaからのトラフィックをAshburnにまずダイレクトし、Londonにフェイルオーバします（Geolocationは国のレベル、またUSとカナダについては州のレベルでも設定できます）。Rule 2ではAfrica、AsiaおよびEuropeのトラフィックをLondonにまずダイレクトします。Glocal Catch-all（いずれのルールもマッチしなかった場合に適用）はRule 1と同様の動きをさせます。
Health Checkを設定していきます。Health Checkはアクティブでないサーバーをプールから取り除き（また、オンラインに復帰した際にはプールに戻し）、"always available"アーキテクチャをサポートします。この例ではホストのルートアドレスの80番へのGETというベーシックなやり方ですが、追加のポート、パス、ヘッダやメソッドは定義可能です。
ポリシーをDNSエントリーに紐づけます。この例ではポリシーをapplication.pheatsols.com.auに適用しています。当該アプリケーションへの既存のスタティックなエントリーはこのダイナミックなポリシーによって置き換えられます。
最後に、Create Policyをクリック。ポリシーのサマリが表示されます。例ではPolicy Answer Dataセクションに両方のサーバーの状態がHealthyと表示されていますね。
ポリシーが作成できたので、テストしてみましょう。
私はオーストラリアに住んでいるので、application.pheatsols.com.auをブラウズする際にAshburnにダイレクトされるべきですが、その通りになっています。
フェイルオーバをテストするために、AshburnのApacheサービスを停止してみます。
すると、Policy Answer DataセクションにはAshburnがUnhealthyと表示されました。
そしてapplication.pheatsols.com.auをブラウズすると、シームレスにLondonにダイレクトされました。
大成功でした！
他のPolicy Typeについて
このポストではGeolocation Steeringにフォーカスしましたが、以下のTraffic Management Steering Policiesも利用可能です：
- Load Balancer: バックエンドの複数のノードあるいはサーバー間で、重みづけした、Health Check付きのロードバランシングを行うことができます
- Failover: シンプルな高可用性アーキテクチャをサポートするためのシーケンシャルな、Health Checkベースの応答を構成します
- ASN Steering: トラフィックをその送信元のASNによって判別します（BGPルーティングで使われます）
- IP Prefix Steering: 送信元のIPアドレス、レンジによってトラフィックを振り分けます
ユースケース
Traffic Management Steering Policiesのユースケースの実践は単純な高可用性構成やロードバランシングにとどまりません。今や以下のようなシナリオは、われわれの第二世代クラウドによって、よりシンプルにあるいはより強力に実現できます：
- クラウドへの移行：重みづけされたロードバランシングにより、お客様データセンターからOracle Cloud Infrastructureサーバーへのコントロールされた移行をサポートします。まず少量のトラフィックをクラウドにダイレクトし、全てが想定通り動作していることを確認します。そしてトラフィックの割合を心配ない程度に増やしていき、最終的にすべてのトラフィックをクラウドに移行します。
- ハイブリッド環境のサポート：Traffic Management Steering Policiesを使って、他のクラウドプロバイダやエンタープライズデータセンターなどパブリックな（インターネット上に公開され名前解決可能な）リソースであればいずれのものに向けてもトラフィックを転送することができます。
- パイロットユーザーテスト：IP Prefix Steering Policyを使うことで、内部ユーザーと外部ユーザーに向けて異なるレスポンスを返すよう設定できます。
- 地理による制限とパートナー限定アクセス：サービスへのリクエストをある地域に限定したり、パートナー組織に限定したりすることができます。catch-allとして「このコンテンツはお住まいの地域からは利用できません」を表示するよう設定する、などもできますね。
一連の統合されたEdgeサービスについてもっと知りたい場合は、ドキュメントとリリースアナウンスメントを読んでみてください。
0 件のコメント:
コメントを投稿