IBM Cloud Docs
最適な信頼性を確保するための CIS デプロイメントの管理

最適な信頼性を確保するための CIS デプロイメントの管理

IBM Cloud® Internet Services デプロイメントの信頼性を最適化するために、有用な DNS 構成やグローバル・ロード・バランサーをセットアップできます。 信頼性をさらに高めるために、ページ・ルールを使用することも可能です。そうすれば、起点サーバーやキャッシュに問題があっても、Web コンテンツを顧客に確実に配信できます。 この資料では、CIS デプロイメントの信頼性を最適化するためのベスト・プラクティスの詳細情報を取り上げます。

弊社で推奨している一般的なベスト・プラクティスは以下のとおりです。

  • DNS をセットアップして、CIS のプロキシー・サーバーや他の機能を活用します。
  • 1 つ以上のグローバル・ロード・バランサーを使用して、サイトのトラフィックを均等に分散させます。
  • ページ・ルールをセットアップして、キャッシングなどのオプションを管理します。

それぞれの項目に、信頼性の高い CIS デプロイメントを作成するための機能が含まれています。

CIS インターフェースは、セキュリティー、信頼性、パフォーマンスというセクションに編成されています。

DNS のセットアップ

DNS 構成のセットアップを始めるために、ナビゲーション・メニューから**「DNS」**を選択します。

信頼性のためのDNSの設定と管理については、 ドメインネームシステムの設定（ CIS ）を参照してください。

グローバル・ロード・バランサーのセットアップ

グローバル・ロード・バランサーのセットアップを始めるために、ナビゲーション・メニューから**「グローバル・ロード・バランサー」**を選択します。

グローバルロードバランサーの設定と管理については、 グローバルロードバランサーの概念を 参照してください。

ページ・ルールを使用して信頼性を高める方法

以下のリストは、サイトの信頼性を最大限に高めるために推奨されるページ・ルール設定を示しています。

  • 起点キャッシュ制御
  • 転送用 URL

不整合コンテンツの提供

サーバーがダウンした場合、 Serve Stale Content 設定を使用してサイトの限定バージョンをオンラインに保つことができます。

Serve Stale Contentを使用すると、サーバーがダウンした場合でも、 CIS、キャッシュからページを提供します。 ページの上部に、オフライン表示モードになっているという趣旨の訪問者向けのメッセージが表示されます。 「不整合コンテンツ対応」では HTTP 状況 503 が返されますが、503 は他の多くの Web アプリケーションでも使用されています。 サーバーがオンライン状態に戻ると、CIS ユーザーの表示モードが通常モードにシームレスに切り替わります。

要求対象のページが CIS のキャッシュに入っていない場合は、その Web サイト・ページがオフラインになっているという趣旨のエラー・ページが訪問者に表示されます。

不整合コンテンツ対応のセットアップ

Serve Stale Content を有効にするには、次の手順を実行します。

  1. ナビゲーション・メニューを使ってパフォーマンス >キャッシュに進みます。
  2. Serve Stale Content を切り替えます。

不整合コンテンツの制限事項

  • 「Stale Content（古いコンテンツ）」の表示は Internet Archiveと統合されています。 CIS は過去5時間以内に 200 HTTP ステータスが付与された最も人気の高いURLをクロールします。 したがって、起点サーバーがダウンした時に表示可能になるのは、サイトのごく一部のページだけになります。

  • 最近追加されたサイトは、そのサイトの大規模なキャッシュが利用できない。 つまり、Serve Stale Content は、数日前にサイトを追加したばかりの場合は機能しない可能性があります。

  • CIS では、サーバーがダウンすると、プライベート・コンテンツやハンドル・フォーム送信 (POST) が表示されません。 訪問者には、error on checkoutページまたはitems require a login to viewが表示されます。

  • **「不整合コンテンツ対応」**を起動するには、Web サーバーが 502 や 504 のタイムアウトに関する標準 HTTP エラー・コードを返すことが必要です。 Serve Stale Contentは、 CIS、オリジンとの連絡に問題が発生した場合（エラー521と523）、タイムアウト（522と524）、SSLエラー（525と526）、または不明なエラー（520）にも機能します。 **「不整合コンテンツ対応」**は、他の HTTP 応答コード (404、500、503、データベース接続エラー、内部サーバー・エラー、サーバーからの空の応答など) では起動しません。

  • 「すべてをキャッシュ」ページ・ルールが有効になっていて、「エッジ・キャッシュ有効期限 TTL (Edge Cache Expire TTL)」がキャッシング頻度よりも小さい値になっていると、**「不整合コンテンツ対応」は機能しません。「不整合コンテンツ対応」**のキャッシュの内容は、「エッジ・キャッシュ有効期限 TTL (Edge Cache Expire TTL)」に対応する間隔で消去されるからです。

起点キャッシュ制御

**「起点キャッシュ制御」**ページ・ルール設定を使用して、起点からキャッシュに入れるコンテンツの種類やコンテンツの更新頻度を指定できます。こうした設定は、信頼性とパフォーマンスに影響を与えます。 設定を変更せずに、キャッシングを禁止するヘッダーを起点サーバーから送信しなければ、デフォルトでは、CIS のキャッシュにすべての静的コンテンツと一部の拡張子のコンテンツが入るようになります。 該当するのは、画像、CSS、JavaScript などのタイプのコンテンツです。 このようなキャッシングを行うのは、主にパフォーマンス上の理由によります。

**「起点キャッシュ制御」**をセットアップするには、ページ・ルールを使用して、コンテンツのリソースごとに望ましい動作を指定した該当ヘッダーをオンにします。 **「起点キャッシュ制御」の使用方法を理解するには、CIS のページ・ルールとキャッシング動作全体をコンテキストに沿って取り上げた一般的な説明が必要です。この後のいくつかのセクションには、そのような説明が記載されています。 一般的に言えば、キャッシングを制御するには 3 つの方法があり、「起点キャッシュ制御」**は、そのうちの 2 番目です。

**「起点キャッシュ制御」を設定すると、主に再検証に関連したインターネット・ベスト・プラクティスと RFC にできるだけ準拠したキャッシング・ルールが起動します。 例えば、CIS の max-age=0 のデフォルトの動作では、何もキャッシュに入りませんが、「起点キャッシュ制御」**の設定では、常に再検証を前提としてキャッシュにデータが入るようになります。

起点キャッシュ制御のセットアップ

Originキャッシュコントロールを有効にするには、以下の手順に従います。

  1. ナビゲーション・メニューで**「パフォーマンス」の下にある「ページ・ルール」**を選択します。
  2. ドメインを参照する URL パターンを使用してページ・ルールを作成します。
  3. **「起点キャッシュ制御」**設定を追加してオンに切り替えます。
  4. **「リソースのプロビジョン (Provision Resource)」**を選択します。

ページ・ルールの優先順位

これらの特定のページ・ルールは、全体的なキャッシュに優先します。

  • ページ・ルールの キャッシュ・レベル が Bypassに設定されている場合、そのページ・ルールに一致するリソースはキャッシュされません。 CIS は引き続きプロキシーとして機能し、その他のパフォーマンス機能はアクティブのままです。 ただし、コンテンツはキャッシュから提供されるのではなく、起点サーバーから直接取り出されます。

  • ページ・ルールで**「キャッシュ・レベル」**をCache everythingに設定すると、そのページ・ルールに合致するリソースはすべてキャッシュに入ります。 このページ・ルール設定を使用することは、 CIS が静的と見なすもの（HTMLを含む）以外のリソースをキャッシュするよう、 CIS に指示する唯一の方法である。

ページルールが設定されていない場合、CISはリソースの拡張に基づく Standard キャッシュモードを使用します。CISは静的リソースのみをキャッシュします。

起点の Cache-Control ヘッダー

CIS が何をキャッシュするかを変更する 2 番目の方法は、オリジンから送信されるヘッダーをキャッシュすることです。 CIS はこれらの設定を尊重しますが、 エッジ・キャッシュ TTL ページ・ルール設定を指定することによってオーバーライドできます。 オリジンからキャッシュするリソースを決定する際に、 CIS が考慮するヘッダーは以下のとおりです：

  • Cache-Control ヘッダーを、private、no-store、no-cache、max-age=0 のいずれかに設定した場合や、応答に Cookie がない場合は、CIS のキャッシュにリソースが入りません。 機密性の高い資料をキャッシュに入れるべきではないので、そのような場合はこうしたヘッダーを使用できます。

  • Cache-Control ヘッダーを public に設定し、max-age を 0 より大きい値に設定した場合や、Expires ヘッダーを将来の任意の時刻に設定した場合は、そのリソースがキャッシュされます。

RFC のルールでは、Cache-Control: max-age のほうが Expires ヘッダーよりも優先されます。 両方が存在し、整合していない場合は、max-age のほうが優先されます。

s-maxage ヘッダーの使用

3 番目の方法では、s-maxage Cache-Control ヘッダーを使用してキャッシングの動作とブラウザー・キャッシュの動作を一緒に制御できます。

通常CISは max-age ディレクティブを尊重します。

Cache-Control: max-age=1000

しかし、ブラウザとは異なるキャッシュタイムアウトを指定したい場合は、 CIS、 s-maxage。 以下の例では、 CIS に200秒間、ブラウザに60秒間オブジェクトをキャッシュするよう指示している。

Cache-Control: s-maxage=200, max-age=60

基本的に、s-maxage はリバースプロキシにのみ従うことを意図しており（そのため、ブラウザは無視すべきです）、一方（CIS）は s-maxage が存在する場合、それを優先します。CISは、ブラウザのキャッシュ設定と max-age ヘッダのどちらか高い方の値を尊重します。

信頼性を高めるためのキャッシュ制御ヘッダーとページ・ルールのまとめ

キャッシングに関して信頼性を高める時に検討すべき主な分野を以下にまとめます。

  • 起点のキャッシング・ヘッダーをチェックして、キャッシュ可能なリソースの優先ヘッダー (Cache-Control と Expires) がないかどうかを確認します。

  • CIS では、デフォルトで常に静的コンテンツがキャッシュに入ります。戻りコードごとの TTL は以下のとおりです。

    200 301    120m;
302 303    20m;
403        5m; for reliability
404        5m;
any        0s;

  • さらに多くのリソースをキャッシュに入れる場合は、URL に対して**「キャッシュ・レベル」**を「Cache everything」に設定したページ・ルールを作成します (その URL を要求した場合に Web サーバーから 404 が返されると、その結果が 5m だけキャッシュされます)。

  • URL でのキャッシングを避ける場合は、**「キャッシュ・レベル」**を「Bypass」に設定したページ・ルールを作成します。

転送用 URL

コンテンツを常に利用できるようにするために、サイトが使用不可になった場合に使用される**「転送する URL」**設定を組み込んだページ・ルールを作成します。

**「転送する URL」**を有効にすると、他のすべての設定が無効になります。すべてのトラフィックを別の URL に送信することになるからです。

転送する URL のセットアップ

**「転送する URL」**を有効にするには、以下の手順を実行します。

  1. ナビゲーション・メニューで**「パフォーマンス」の下にある「ページ・ルール」**を選択します。
  2. ドメインを参照する URL パターンを使用してページ・ルールを作成します。
  3. **「転送する URL」**設定を追加します。
  4. 転送のタイプを選択し、宛先の URL を入力します。
  5. **「リソースのプロビジョン (Provision Resource)」**を選択します。

転送する URL の例

訪問者を以下の URL に簡単に誘導するための方法を取り上げます。

*www.example.com/+

*example.com/+

このパターンに合致するのは、以下のようなサイトです。

http://example.com/+
http://www.example.com/+
https://www.example.com/+
https://blog.example.com/+
https://www.blog.example.com/+

以下のようなサイトは合致しません。

http://www.example.com/blog/+  [extra directory before the +]
http://www.example.com+  [no trailing slash]

該当するマッチング・パターンを作成したら、**「転送用 URL (Forwarding URL)」**設定を追加し、転送のタイプを選択し、宛先の URL を入力します。 以下に例を示します。

https://plus.google.com/yourid

**「リソースのプロビジョン (Provision Resource)」**を選択します。 数秒すると、リダイレクト指定に基づいて、そのパターンに合致する要求が新しい URL に転送されます。

拡張転送オプション

ルート・ドメインを www.yourdomain.com に転送するといった基本的なリダイレクトでは、URL に含まれている他の要素が失われます。 例えば、以下のパターンをセットアップするとします。

example.com

転送先は以下のとおりです。

http://www.example.com

しかし、以下の指定の場合はどうなるでしょうか。

example.com/some-particular-page.html

リダイレクト先はこうなります。

www.example.com

次のようにはなりませんでした。

www.example.com/some-particular-page.html

解決策は、変数を使用することです。 それぞれのワイルドカードが、転送用アドレスで参照できる変数に対応します。 変数は、$ の後に数字を付けた形式で表記します。 最初のワイルドカードを参照する場合は $1 を使用し、2 番目のワイルドカードを参照する場合は $2 を使用する、といった具合です。 前の例のような、ルートから www への転送を修正する場合も、同じパターンを使用します。

example.com/*

トラフィックの転送先 URL を以下のようにセットアップします。

http://www.example.com/$1

その場合、アクセス先が以下のページだとしましょう。

example.com/some-particular-page.html

リダイレクト先はこうなります。

http://www.example.com/some-particular-page.html