第 2 章 - インフラストラクチャ

キャッシュインフラストラクチャの設定

このシリーズの第 1 章では、パブリッシュシステムと Dispatcher の基本的なトポロジを紹介しました。 一連のパブリッシュサーバーと Dispatcher サーバーは、予想される負荷、データセンターのトポロジ、および必要なフェイルオーバープロパティに応じて、様々なバリエーションで設定できます。

最も一般的なトポロジの概要、およびその利点とその欠点を説明します。 もちろん、リストは包括的なものではありません。 唯一の制限は、あなたの想像力です。

「レガシー」設定

初期の頃は、潜在的な訪問者数が少なく、ハードウェアが高価で、web サーバは現在のようにビジネスクリティカルではないと見なされていました。 一般的な設定では、1 つの Dispatcher がロードバランサーおよびキャッシュとして機能し、2 つ以上のパブリッシュシステムの前に配置されていました。 Dispatcher のコアにある Apache サーバーは非常に安定しており、ほとんどの設定で妥当な量の要求に対応できます。

「レガシー」Dispatcher の設定 - 現在の標準ではあまり一般的でない

Dispatcher がこのような名前になったのはこれが理由です。基本的にリクエストをディスパッチしていました。 この設定は、現在必要なパフォーマンスと安定性に対する高い要求を満たすことができないため、現在はあまり一般的ではありません。

マルチレッグ設定

最近では、やや異なるトポロジがより一般的です。 複数のレッグを持つトポロジでは、パブリッシュサーバーごとに 1 つの Dispatcher が存在します。 AEM インフラストラクチャの前には、専用（ハードウェア）のロードバランサーが配置され、次の 2 つ以上のレッグにリクエストがディスパッチされます。

最新の「標準」Dispatcher の設定 - 扱いやすく、保守が容易

この種の設定を行う理由は次の通りです。

「スケールアウト」設定

Apache サーバーは安価でプロビジョニングが容易なので、そのレベルをもう少し拡大してみましょう。 各パブリッシュサーバーの前に 2 つ以上の Dispatcher を配置してみます。

「スケールアウト」設定 - いくらかのアプリケーション領域があるものの、制限事項や注意事項もある

これは確実な方法です。そして、多くの有効なアプリケーションシナリオがあります。 しかし、考慮すべきいくつかの制限や複雑さもあります。

無効化

各パブリッシュシステムは多数の Dispatcher に接続されており、コンテンツが変更された場合は、それぞれを無効にする必要があります。

メンテナンス

言うまでもなく、Dispatcher システムとパブリッシュシステムの初期設定はもう少し複雑です。 しかし、「ローリング」リリースの取り組みも、もう少しレベルが高いことにも注意してください。 AEM システムは実行中にアップデートでき、そうする必要があります。しかし、それらが積極的にリクエストに応えている間は、避けたほうが賢明です。 通常は、パブリッシュシステムの一部のみを更新します。他のシステムは引き続きトラフィックを積極的に提供し、テスト後に別の部分に切り替えます。 運が良く、デプロイメントプロセスでロードバランサーにアクセスできる場合は、メンテナンス中のサーバーへのルーティングをここで無効にできます。 直接アクセス権のない共有ロードバランサーを使用している場合は、更新するパブリッシュの Dispatcher をシャットダウンします。 あればあるほど、より多くシャットダウンする必要があります。 数が多く、頻繁なアップデートを計画している場合は、自動化を推奨します。 自動化ツールがない場合、スケールアウトは良くないアイデアです。

以前のプロジェクトでは、ロードバランサー自体に直接アクセスすることなく、パブリッシュシステムをロードバランシングから削除する別の方法を使用しました。

ロードバランサーは通常、特定のページを「ping」して、サーバーが起動して実行されているかどうかを確認します。簡単な選択は、通常、ホームページに対して ping を実行することです。 しかし、ping を使用してロードバランサーにトラフィックのバランスを取らないように伝えたい場合は、他のものを選択します。 "up" または "down"（本文または http 応答コードとして）で応答するように設定できる専用のテンプレートまたはサーブレットを作成します。 もちろん、そのページの応答は Dispatcher にキャッシュしてはいけません。したがって、このページは常にパブリッシュシステムから新しく取得されます。 次に、このテンプレートまたはサーブレットを確認するようにロードバランサーを設定すると、パブリッシュにダウンしている「ふり」を簡単にさせることができます。ロードバランシングに含まれず、アップデートできます。

ワールドワイド配布

「ワールドワイド配布」は、各パブリッシュシステムの前に複数の Dispatcher が配置され、お客様に近づいてパフォーマンスを向上させるために世界中に配布される「スケールアウト」設定です。 もちろん、このシナリオでは、中央のロードバランサーではなく、DNS および geoIP ベースのロードバランシングスキームを使用します。

水平スケーリング

ローカルデータセンターでも、各パブリッシュシステムの前に複数の Dispatcher が存在する「スケールアウト」トポロジにはいくつかの利点があります。 高トラフィック（および良好なキャッシュヒット率）により Apache サーバーでパフォーマンスのボトルネックが発生し、（CPU、RAM、およびより高速なディスクを追加して）ハードウェアをスケールアップできない場合は、Dispatcher を追加してパフォーマンスを向上させることができます。これは「水平スケーリング」と呼ばれます。 ただし、特に、トラフィックを頻繁に無効にする場合には、これには制限があります。次の節で効果を説明します。

スケールアウトトポロジの制限

プロキシサーバーを追加すると、通常はパフォーマンスが向上します。 ただし、実際にサーバーを追加するとパフォーマンスが低下する場合があります。 どうしてでしょうか。新しい記事やページを毎分紹介するニュースポータルがあるとします。 Dispatcher は、「自動無効化」によって無効化します。ページが公開されるたびに、同じサイト上のキャッシュ内のすべてのページが無効化されます。 これは便利な機能です（詳しくは、この連載の 第 1 章でカバーしました）が、web サイトで頻繁に変更を行うと、キャッシュが頻繁に無効になることも意味します。パブリッシュインスタンスごとに 1 つの Dispatcher のみがある場合、ページを最初にリクエストした訪問者は、そのページの再キャッシュをトリガーします。 2 人目の訪問者は、既にキャッシュされているバージョンを取得しています。

2 つの Dispatcher がある場合、2 番目の訪問者は、ページがキャッシュされていない可能性が 50%あり、そのページが再度レンダリングされると、より大きな待ち時間が発生します。 1 つのパブリッシュに対してさらに多くの Dispatcher が存在すると、事態はさらに悪化します。 各 Dispatcher 用にページを個別に再レンダリングする必要があるので、パブリッシュサーバーがより多くの読み込みを受け取っているのです。

キャッシュのフラッシュが頻繁に行われ、スケールアウトシナリオのパフォーマンスが低下しました。

オーバースケーリング問題の軽減

すべての Dispatcher に対して中央の共有ストレージを使用するか、Apache サーバーのファイルシステムを同期して問題を軽減することを検討してください。 限られた直接のエクスペリエンスしか提供できませんが、これによりシステムが複雑になり、まったく新しいクラスのエラーが発生する可能性があることに注意してください。

NFS とはいくらか実験しましたが、NFS は、コンテンツのロックによって大きなパフォーマンスの問題を引き起こします。 これにより全体的なパフォーマンスが低下しました。

まとめ - 複数の Dispatcher 間で共通のファイルシステムを共有することは推奨されていません。

パフォーマンスの問題が発生した場合は、パブリッシュインスタンスのピーク負荷を避けるために、パブリッシュインスタンスと Dispatchers を均等にスケールアップします。 パブリッシュ／Dispatcher の比率に関するゴールデンルールはありません。比率は、リクエストの配布と、パブリケーションおよびキャッシュの無効化の頻度に大きく依存します。

訪問者の待ち時間も問題となる場合は、この連載の第 1 章で説明されているように、コンテンツ配信ネットワーク、キャッシュの再取得、プリエンプティブなキャッシュウォーミング、猶予時間を設定することを検討する、または、第 3 部でいくつかの高度なアイデアを参照してください。

「クロス接続」設定

時折見かけてきた別の設定は、「クロス接続」設定です。この設定ではパブリッシュインスタンスに専用の Dispatcher がありませんが、すべての Dispatcher がすべてのパブリッシュシステムに接続されます。

クロス接続トポロジ：より冗長になり複雑さが増大。

一見すると、これは比較的低い予算でさらに冗長性を確保できるようです。 いずれかの Apache サーバーがダウンしても、2 つのパブリッシュシステムでレンダリングを実行できます。 また、いずれかのパブリッシュシステムがクラッシュした場合でも、キャッシュされた読み込みを提供する Dispatcher が 2 つあります。

しかし、ここには代償が伴います。

まず、保守のために 1 つのレッグを取り出すのは非常に面倒です。 実際、これはより柔軟で、出来る限りあらゆる手段で常に稼働し続けることを目的に設計されています。 これに対応する取り組みについては、複雑な保守計画を目にしてきました。 最初に Dispatcher 2 を再設定し、クロス接続を削除します。 Dispatcher 2 を再起動します。 そして、Dispatcher 1 のシャットダウン、パブリッシュ 1 のアップデートなどを行います。 2 本以上のレッグまで拡大する場合は注意が必要です。 実際に複雑さとコストが増し、人的ミスが多発する原因になる、という結論になるでしょう。 ベストな方法は、これを自動化することです。 この自動処理タスクをプロジェクトのスケジュールに含める人材がいるかどうか、確認するとよいでしょう。 これにより、ハードウェアのコストをいくらか削減できますが、IT スタッフに 2 倍のコストを割り当てることになります。

2 つ目は、AEM 上で何らかのユーザーアプリケーションを実行していて、ログインが必要な場合です。 スティッキーセッションを使用すると、1 人のユーザーが同じ AEM インスタンスから提供され、そのインスタンスでセッション状態を維持できます。 このクロス接続設定を使用する場合は、ロードバランサーと Dispatcher でスティッキーセッションが正しく動作していることを確認する必要があります。 不可能ではないものの、設定とテスト時間が増加することを認識しておく必要があります。ここでも、ハードウェアの節約で見込まれるコスト削減が相殺される可能性があります。

まとめ

このクロス接続スキームをデフォルトオプションとして使用することはお勧めしません。 ただし、使用する場合は、リスクと隠れたコストを慎重に評価し、設定の自動化をプロジェクトに組み込む計画を立てたほうがよいでしょう。

次の手順