Blog

クラウドファーストのヘッドレスCMSを構築するには何が必要ですか？未来のヘッドレスCMSであるKenticoCloudを構築するために、Kenticoが数年前に着手した旅と私たちが使用したテクノロジーを見てみましょう。

必要に応じて拡張できるマイクロサービスアーキテクチャに基づくマルチテナントSaaSプラットフォームであるクラウドファーストのヘッドレスCMSを構築することは、簡単な作業ではありません。多くの計画と戦略化は、サービスの設計、設計、および実装のプロセスに入り、ユーザーがどこから来てどこに向かっているかに関係なく、すべてのユーザーに対して確実に機能するようにします。このブログ投稿では、Kentico Cloudアーキテクチャのさまざまな部分を見て、KenticoCloudの内部にあるものを示します。

何か新しいものを作る

私には、元のKenticoCloudチームの一員であるという特権と贅沢がありました。私にとって、ソフトウェアアーキテクトおよび開発者として、興味深いプロジェクトをゼロから構築することは常に夢でした。最初の「イェーイ、やってみよう！」の興奮瞬間に続いて「しかしどうやって？」段階。そして、それがクラウドCMSへの旅が始まったときです。

まず、クラウドファーストのヘッドレスCMSのさまざまな役割と重要なコンポーネントを理解することが重要です。

上の図が示すように、クラウドCMSの概念は、さまざまなタッチポイントとシナリオを考慮する必要がある概念です。プロジェクト管理、コンテンツの制作と管理から公開と配信まで、システムはこれらのシナリオをサポートするサービスと機能を提供する必要があります。

これらすべてをスケーラブルで安全かつ可用性の高い方法で実行できる製品を構築する必要があることはわかっていました。保守が容易で拡張可能な製品が必要であることはわかっていました。これらは、私たちが途中で行ったテクノロジーとアーキテクチャの決定についての議論を推進する重要な要件でした。

分離されたアーキテクチャ

私たちが最初に決定したのは、クラウドプラットフォームとしてMicrosoftAzureを採用することでした。 Kenticoでは、.NET、Azure、およびMicrosoftテクノロジ全般について豊富な経験があり、安定した信頼性の高いテクノロジであることが常にわかっており、非常に満足しています。

最初に、次の場合に、システムを2つの主要なサービスまたは展開ユニットに分割することにしました。

• コンテンツ管理-コンテンツファーストのアプローチでコンテンツを作成および維持します。
• コンテンツ配信-ターゲットのプレゼンテーションコードにコンテンツを配信します。

最初は、共有コンテンツリポジトリは非常に魅力的でした。

しかし、共通のストレージを持つことには欠点があることにすぐに気付きました。

• 管理サービスには書き込み用に最適化されたストレージが必要ですが、配信サービスには読み取りとクエリ用に最適化されたストレージが必要です。
• 双方がすべてのデータを必要とするわけではありません。
• 各サービスには、異なるストレージスケーラビリティターゲットがあります。
• 共有データ構造は、サービス間の緊密な結合を引き起こします。
• DBを保守および更新すると、配信サービスが利用できなくなります。
• 配信サービスには、管理サービスよりも高い可用性のニーズがあります。
• ..。

「短所」のリストが増えるにつれ、私たちは独立した疎結合のサービスアーキテクチャに焦点を合わせ始めました。最も一般的な方法の1つである、キューベースのメッセージングを活用してサービスを分離しました。

つまり、管理サービスは、定義されたコントラクトのデータ状態の変更を表すイベントを公開します。配信サービスは、このようなメッセージを受信して処理し、ストレージに保存します。

このアーキテクチャの利点：

• キューは複数のコンシューマー（サブスクライバー）をサポートし、他の可能なコンシューマーは他の目的（監査ログ、全文索引付け、機械学習など）で同じメッセージを処理できます。
• 開発者チームはより独立しています。
• サービスは独立して展開できます。
• サービスのカスケード障害はありません。一方のサービスのダウンタイムが他方のサービスに影響を与えることはありません。
• そして、前述のすべての欠点を解決します。

このアーキテクチャを採用したのは、事態がさらに複雑になった場合に役立つことを願っています。そして驚き、驚き、彼らは持っています。

イベントキュー

イベントキューは、MicrosoftAzureが提供するAzureEventHubsサービスに基づいています。多くの高度なエンタープライズ機能を提供するAzureService Busメッセージブローカーを検討していましたが、ニーズがわずかに異なり、Service Busはニーズに対して非常に複雑なソリューションになるため、最終的には使用しないことにしました。 Azure Event Hubsは、よりリーズナブルな価格で優れたパフォーマンスを提供し、サービスの価格を低く抑えることができます。私たちは、Event Hubs（およびApache Kafka ）を、分散システムの中核となる基本的なサービスの1つと考えています。

プレビューとライブ

コーディングに楽しく没頭した直後、プレビューの重要性に気づきました。ユーザーは本当に少なくともこれらの環境を必要としています：

• プレビュー-コンテンツ状態の最先端。
• ライブ—一般の視聴者向けのデータ。

ライブ環境の高可用性を実現するには、開発者がコードにバグを作成する可能性があり、必然的に発生するプレビュー環境からライブ環境を分離する必要がありました。このようなバグは、ライブ環境のパフォーマンスを低下させる可能性があります。

これにより、コンテンツ配信サービス全体が複製され（ライブとプレビュー）、独自のAzureサービスに分離されるアーキテクチャが実現します。

物事を速くする

私たちが解決しなければならなかった次の課題は、世界中のユーザーがどこで作業していても、KenticoCloudを高速に応答させる方法でした。配信コンテンツストレージは読み取り操作用に最適化されていますが、リソースを大量に消費する可能性のある複雑なクエリがまだあります。

たとえば、 Delivery APIを使用すると、参照されるアイテム（モジュラーアイテム）の深さを指定し、1回の呼び出しでアイテムのグラフ全体を取得できます。ご想像のとおり、コンテンツを取得することは、処理するのに膨大な作業負荷です。ただし、システムのパフォーマンスは、システムが要求されたコンテンツを取得する速度だけに依存するわけではありません。また、データが宛先に到達するために移動する必要がある距離にも依存します。現在、Kentico Cloud管理インスタンスは、Microsoft Azure US West（カリフォルニア）データセンターでホストされています。ここで、KenticoCloudに保存されているコンテンツを表示するWebアプリがシドニーで実行されているとします。光は、理論上、米国西部からシドニーまで光ファイバーを通過し、約130ミリ秒で戻ることができます。 IPインフラストラクチャによって引き起こされる遅延を追加すると、約165ミリ秒になります。これは、オーストラリア本土への平均ping時間です。

Kentico Cloudのお客様に可能な限り最高レベルのパフォーマンスを提供するために、コンテンツ配信ネットワーク（CDN）をインフラストラクチャの一部にすることにしました。

CDNで次のレベルに引き上げる

各リージョンにKenticoCloudのインスタンスをデプロイし、ローカルキャッシュを使用してパフォーマンスを向上させることで両方の問題に対処できますが、はるかに手間がかかり、運用が複雑になり、率直に言って、活用するよりもはるかに効果が低くなります。そのためのサードパーティのCDNサービス。

Fastly CDNを使用することにしました。これにより、多くのポイントが存在し、非常に高速なキャッシュの無効化が可能になります。 CDNを使用するもう1つの利点は、古いコンテンツを提供できることです。これは、オリジンサーバーがダウンしている場合や遅い場合に非常に便利です。これらのシナリオでは、CDNはコンテンツの少し古いバージョンを返し、KenticoCloudに接続されたデジタルプロパティの操作が中断されないようにします。

パフォーマンステストの結果

上記のアーキテクチャでは、Kentico Cloudが高度にスケーラブルで堅牢なソリューションであり、現在の顧客ベースと近い将来（少なくとも来年）に十分なパフォーマンスを備えていることを前提としています。

仮定を検証するために、MicrosoftAzureパフォーマンステストツールを使用して環境全体のストレステストと負荷テストを行いました。ユーザーの行動をシミュレートした包括的なテストには、最悪のシナリオに関するコンテンツの作成、コンテンツの更新、およびコンテンツの配信が含まれています。

結果：

• 平均応答時間は100ミリ秒でした。
• 現在のDocumentDBパフォーマンス設定（1000 RU / s）を使用すると、近い将来、予想される顧客ベースに対して十分なパフォーマンスが得られます。
• DocumentDBはボトルネックですが、幸いなことに、 RU / sを追加購入するだけで簡単にスケールアップできます。
• 実際のシナリオ（最悪の場合ではない）の平均応答時間は40ミリ秒でした。

これらの結果に非常に満足しています。それは私たちがよりよく眠ることを可能にするだけでなく、パフォーマンスの問題と戦うのではなく、お客様に価値のある機能を提供することに集中することもできます。

監視とトラブルシューティング

パブリッククラウドでアプリケーションをホストするには、監視とトラブルシューティングを行うための体系的かつ衒学的なアプローチが必要です。 Kentico Cloudなどのクラウドサービスが実行されるハードウェアとオペレーティングシステムへのアクセスが制限されているため、適切なインストルメンテーションを導入する必要があります。 Azureは、デフォルトではほとんどのサービスでうまく機能しますが、それでもアプリケーション層でインストルメンテーションが必要です。

私たちのニーズのほとんどは、Azure Application Insightsによって対処されています。これは、ほとんどすべての人に検討することをお勧めします。 ApplicationInsightsをNLogと組み合わせて使用します。 NLogを使用すると、ログをファイルに書き込むことができ、実行時に構成できるため、エンジニアはトラブルシューティング中に、特定のコード領域のログレベルを一時的に向上させることができます。このようなログは、検索と分析を容易にするために、標準のApplication Insightデータ（要求、例外、依存関係）とともにApplicationInsightsに格納されます。また、アラートを構成し、他の測定ツール（ Pingdomなど）を展開して、予防的および事後的な監視を強化し、エスカレーションを発行しました。

あなたのデータは安全です

Azure SQL Server

リレーショナルデータ（ユーザー、プロジェクト、ロール、サブスクリプション）の場合。過去14日間の任意の時点に復元する機能を備えた継続的なバックアップ（トランザクションログ）。

Azureテーブル

コンテンツ管理ストレージとして。 14日間の保存期間での毎日のバックアップ。 MongoDBの使用経験はありますが、Azure Tableの方が安価で、基本的なストレージのニーズには十分であるという結論に達しました。

Azure Blob

アセット（ファイル）ストレージとして。 14日間の保存期間での毎日のバックアップ。コンテンツ管理ストレージはプライベートストレージを使用し、コンテンツ配信サービスはパブリックストレージを使用します（ファイルをCDNでキャッシュできるようにするため）。

DocumentDB

DocumentDBをコンテンツ配信ストレージとして使用します。 DocumentDBストレージをバックアップする必要はありません。緊急の場合、すべてのデータを管理コンテンツストアから再作成できます。コンテンツアイテムをJSONドキュメントとして保存することにはメリットがあり、DocumentDBの優れた機能とスケーラビリティを備えているため、ここではその基盤について説明します。

DocumentDBは、つい最近Azure CosmosDBの一部になりました。

エクスペリエンスの構築

.NET 4.5 MVC Web API 2を使用してバックエンドの開発を開始しました。現在、.NET Coreへの移行を検討しており、ツールと.NET Coreの採用がニーズに十分になった後、最終的には.NETCoreに移行します。 WebJobsを使用してバックグラウンドタスクを実行しています。

Kentico Cloudのフロントエンドは、React.jsを使用してシングルページアプリケーションとして構築されています。 SPAは、必要な柔軟性を提供し、可能な限り最高のユーザーエクスペリエンスを提供するUIを作成する機能を提供します。当初はReact.jsとFluxを使用してKenticoCloud管理UIの構築を開始しましたが、製品が成長するにつれて、代わりにReact.jsとReduxを使用してリファクタリングすることにしました。これは興味深い経験であり、独自のブログ投稿に値します。

また、管理フロントエンドはインターコムカスタマーメッセージングプラットフォームと統合されているため、エンドユーザーはカスタマーサクセスおよび開発チームと通信できます。さらに、ユーザーがアプリケーションをどのように操作するかを追跡することで、製品のどの領域が顧客に最高の価値を提供し、新機能の検証のための潜在的な早期採用者が誰であるかをよりよく理解できます。私たちは顧客の成功を真剣に受け止めており、インターコムはそれを大いに支援してくれます。

要点

ご覧のとおり、分散システムの構築は簡単な作業ではなく、要件に基づいて、その方法は大幅に異なる可能性があります。特効薬はありません。ただし、コードインストルメンテーションやデカップリングサービスなどのベストプラクティスを独立したデプロイメントユニット（またはマイクロサービス）に適用すると、すばらしいスタートを切ることができます。