第 2 章 - インフラストラクチャ
キャッシュインフラストラクチャの設定
このシリーズの第 1 章では、パブリッシュシステムと Dispatcher の基本的なトポロジを紹介しました。 一連のパブリッシュサーバーと Dispatcher サーバーは、予想される負荷、データセンターのトポロジ、および必要なフェイルオーバープロパティに応じて、様々なバリエーションで設定できます。
最も一般的なトポロジの概要、およびその利点とその欠点を説明します。 もちろん、リストは包括的なものではありません。 唯一の制限は、あなたの想像力です。
「レガシー」設定
初期の頃は、潜在的な訪問者数が少なく、ハードウェアが高価で、web サーバは現在のようにビジネスクリティカルではないと見なされていました。 一般的な設定では、1 つの Dispatcher がロードバランサーおよびキャッシュとして機能し、2 つ以上のパブリッシュシステムの前に配置されていました。 Dispatcher のコアにある Apache サーバーは非常に安定しており、ほとんどの設定で妥当な量の要求に対応できます。
「レガシー」Dispatcher の設定 - 現在の標準ではあまり一般的でない
Dispatcher がこのような名前になったのはこれが理由です。基本的にリクエストをディスパッチしていました。 この設定は、現在必要なパフォーマンスと安定性に対する高い要求を満たすことができないため、現在はあまり一般的ではありません。
マルチレッグ設定
最近では、やや異なるトポロジがより一般的です。 複数のレッグを持つトポロジでは、パブリッシュサーバーごとに 1 つの Dispatcher が存在します。 AEM インフラストラクチャの前には、専用（ハードウェア）のロードバランサーが配置され、次の 2 つ以上のレッグにリクエストがディスパッチされます。
最新の「標準」Dispatcher の設定 - 扱いやすく、保守が容易
この種の設定を行う理由は次の通りです。
-
Web サイトは平均して、以前よりも多くのトラフィックを提供します。 したがって、「Apache インフラストラクチャ」を拡張する必要があります。
-
「レガシー」設定では、Dispatcher レベルで冗長性が提供されていませんでした。 Apache サーバーがダウンした場合、web サイト全体に到達できませんでした。
-
Apache サーバーは安価です。 オープンソースに基づいており、仮想データセンターがあれば、非常に高速にプロビジョニングできます。
-
この設定により、「ローリング」または「スタッガー」の更新シナリオを簡単に実行できます。 パブリッシュ 1 に新しいソフトウェアパッケージをインストールする際に、Dispatcher 1 をシャットダウンするだけです。 インストールが完了し、十分にスモークテストされたパブリッシュ 1 を内部ネットワークから取得したら、Dispatcher 1 のキャッシュを削除し、パブリッシュ 2 のメンテナンスを行うために Dispatcher 2 を停止して Dispatcher 1 を新しく開始します。
-
この設定で、キャッシュの無効化が非常に簡単で決定的なものになります。 1 つのパブリッシュシステムのみが 1 つの Dispatcher に接続されているので、無効にする Dispatcher は 1 つだけです。 無効化の順序とタイミングもあまり重要ではありません。
「スケールアウト」設定
Apache サーバーは安価でプロビジョニングが容易なので、そのレベルをもう少し拡大してみましょう。 各パブリッシュサーバーの前に 2 つ以上の Dispatcher を配置してみます。
「スケールアウト」設定 - いくらかのアプリケーション領域があるものの、制限事項や注意事項もある
これは確実な方法です。そして、多くの有効なアプリケーションシナリオがあります。 しかし、考慮すべきいくつかの制限や複雑さもあります。
無効化
各パブリッシュシステムは多数の Dispatcher に接続されており、コンテンツが変更された場合は、それぞれを無効にする必要があります。
メンテナンス
言うまでもなく、Dispatcher システムとパブリッシュシステムの初期設定はもう少し複雑です。 しかし、「ローリング」リリースの取り組みも、もう少しレベルが高いことにも注意してください。 AEM システムは実行中にアップデートでき、そうする必要があります。しかし、それらが積極的にリクエストに応えている間は、避けたほうが賢明です。 通常は、パブリッシュシステムの一部のみを更新します。他のシステムは引き続きトラフィックを積極的に提供し、テスト後に別の部分に切り替えます。 運が良く、デプロイメントプロセスでロードバランサーにアクセスできる場合は、メンテナンス中のサーバーへのルーティングをここで無効にできます。 直接アクセス権のない共有ロードバランサーを使用している場合は、更新するパブリッシュの Dispatcher をシャットダウンします。 あればあるほど、より多くシャットダウンする必要があります。 数が多く、頻繁なアップデートを計画している場合は、自動化を推奨します。 自動化ツールがない場合、スケールアウトは良くないアイデアです。
以前のプロジェクトでは、ロードバランサー自体に直接アクセスすることなく、パブリッシュシステムをロードバランシングから削除する別の方法を使用しました。
ロードバランサーは通常、特定のページを「ping」して、サーバーが起動して実行されているかどうかを確認します。簡単な選択は、通常、ホームページに対して ping を実行することです。 しかし、ping を使用してロードバランサーにトラフィックのバランスを取らないように伝えたい場合は、他のものを選択します。 "up" または "down"（本文または http 応答コードとして）で応答するように設定できる専用のテンプレートまたはサーブレットを作成します。 もちろん、そのページの応答は Dispatcher にキャッシュしてはいけません。したがって、このページは常にパブリッシュシステムから新しく取得されます。 次に、このテンプレートまたはサーブレットを確認するようにロードバランサーを設定すると、パブリッシュにダウンしている「ふり」を簡単にさせることができます。ロードバランシングに含まれず、アップデートできます。
ワールドワイド配布
「ワールドワイド配布」は、各パブリッシュシステムの前に複数の Dispatcher が配置され、お客様に近づいてパフォーマンスを向上させるために世界中に配布される「スケールアウト」設定です。 もちろん、このシナリオでは、中央のロードバランサーではなく、DNS および geoIP ベースのロードバランシングスキームを使用します。
NOTE水平スケーリング
ローカルデータセンターでも、各パブリッシュシステムの前に複数の 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 部でいくつかの高度なアイデアを参照してください。
