Alfresco Content Servicesのアーキテクチャとスケーラビリティ – リックソフト公式ブログ（Ricksoft Blog）

HOME

2017/06/23
Alfresco Content Servicesのアーキテクチャとスケーラビリティ

Author

青地芳彦Yoshihiko Aochi

青地芳彦

こんにちは。リックソフトの青地です。今回は先進的なAlfrescoのアーキテクチャーとそのスケーラビリティの一端について触れてみたいと思います。
Alfrescoは2005年に設立された、他のECMプレーヤーに比べると新しい参入者ですが、それゆえに当時の新しい技術を豊富に取り入れることができたために、従来のECM製品にはない拡張性とスケーラビリティを発揮します。AlfrescoはAWSのリッチなサービスを活用し、10億ドキュメントものコンテンツをサポートできることを実証しています。
こういったAWSプラットホームの資源をフル活用できるのはAlfrescoだけです。

アーキテクチャ

Alfresco Content Services （以下Alfresco）は大きく分けて３つのJava Webアプリケーションで構成されます。最小構成では１台のサーバ、同一アプリケーションサーバ上で運用することができます（図１）。

図１シングルサーバ構成

３つのWebアプリケーションは、Web UIのShare（緑色）と、バージョン管理、権限管理などのコンテンツ管理の中心として機能するリポジトリのAlfresco Repository（青色）、そして検索サーバのSolr(黄色）です。これらそれぞれ独立して動作し、アプリケーション間はRESTで結びつけられています。そのため、それぞれを負荷に応じてスケールアウトして拡張することが可能です。コンテンツの実体はファイルシステムに格納され、関連するメタデータやシステムの設定情報、監査証跡はデータベースに格納されます。Alfresco Repositoryは、これらのファイルシステムとデータベースに対して直接アクセスし、コンテンツやユーザを管理します（図２）

図２　アプリケーションをアクセスレイヤで分けた構成図

スケーラビリティ

一般的にECMはコンテンツの格納形式について、

リレーショナルデータベースに全て格納されるタイプ
ファイルシステムとデータベースに分けて格納されるタイプ

に二分され、しばしば議論されるところです。前者のタイプは全てデータベースに格納されるために、コンテンツの格納ポイントがデータベースに対する１箇所になり、バックアップ・リストアはデータベースの管理手法を使って簡単に行えますが、コンテンツを可変長バイナリデータ(blob)として格納するために、ファイルのI/Oはファイルシステムのファイルに対する直接的な読み出しに対して遅くなります。そのため、小規模なシステム構成には運用面では向いていますが、大量のコンテンツ、ファイルサイズの大きなコンテンツ、また同時アクセスユーザ数が増えた場合のスケーラビリティに制限が出てきます。一方で、ファイルシステムとデータベースに分けてコンテンツを格納するタイプは、バックアップ時にファイルシステムとデータベースのバックアップの静止点を揃えて、それをセットとして保持する必要がある反面、コンテンツ量やユーザ数増加に対する、ファイルI/Oのスケーラビリティがあります。Alfrescoは後者の構成をとっています。

同時にアクセスするユーザ数が増えてきたり、取り扱うコンテンツの量が増えた場合には、下の例のようにサーバをスケールアウトさせることができます。

図３２台構成

図４ N台構成

上の２つの図では、alfrescoとshareが同じサーバに入っていますが、当然、これらのアプリケーションも分離して、それぞれ別のサーバで稼働させることができます。ただし、Alfrescoではshareの負荷はほとんどない（ブラウザからのAJAXリクエストを処理するぐらい）ので、これらを分離することはほとんどありません（詳しく知りたい方はAlfrescoから出ているホワイトペーパーをご覧ください。ベンチマークデータと、その時のサーバの負荷などの情報が掲載されています）。ただし、solrに関しては分離させるケースがあります。単位時間当たりの文書の更新数が多い場合や、検索が多い場合です。その場合には、下のような構成をとることができます。

図５インデックスサーバを外部にした構成

図５の構成の場合、左のAlfresco Index Serverにsolrのコンポーネントが分離されています。Alfresco Index Serverのオプションには、インデックス作成のためのalfrescoがライセンスされるので、このAlfresco Index Serverに含まれるalfrescoが、ファイルシステムやデータベースにアクセスして、Solrがインデックスを作成することをサポートします。一方で、右側のAlfresco Serverの中にあるalfrescoは、share経由で送られるユーザからのリクエストを処理することに専念し、検索については、Alfresco Index Serverに問い合わせることで、検索に関する負荷をオフロードすることができます。図６は、複数でインデックスサーバを構成する例です。この場合、インデックスサーバ群の上部にロードバランサを入れて、検索の負荷を分散できる構成になっています。

図６インデックスサーバとAlfrescoサーバの複数台構成例

この図の中には含まれていませんが、当然ながらインデックスサーバのSolrには検索のためのインデックス情報を格納しておく必要があります。インデックス情報はそれぞれのインデックスサーバで保持します(Solr4の場合）。しかしながらAlfresco 5.2よりSolr 6とSharding機能を利用することができるようになったので、それぞれのSolrサーバでインデックスを分散、保持し、負荷を分散することができるようになりました。

クラスタリング

（注：Alfresco Community Editionはクラスタリングをサポートしていません）
図３において、alfrescoとshareのところにそれぞれ点線が書かれていますが、これらのコンポーネント間ではHazelcastの分散キャッシュによってクラスタを設定することができます。このクラスタはalfrescoに対してはL2キャッシュを、shareに対してはコンテンツ、プレビューやダッシュレット設定などのキャッシュ共有を提供します。このようにAlfrescoをクラスタリングする際には、以下の点について注意が必要です。

・ロードバランサーのセッションの振り分け方法としてSitcky Sessionを使うようにします。一旦セッションがクライアントとAlfrescoの間で張られたら、同一のalfrescoサーバを利用するようにする。もしこの設定をしていない（例えばラウンドロビンに設定してしまった場合）と、別のサーバにセッションが渡されてしまうために、セッションが切れてしまいます。
・上記に関連しますが、Hazelcastはセッションフェールオーバを持ちません。ほとんどのケースではセッションフェールオーバーは必要としないはず（クリティカルなトランザクションを必要とするケースは少ない）ですが、もし必要な場合には、アプリケーションサーバ側で行います。

より実践的なシステム構成

Alfrescoはオープンスタンダードを利用したWebアプリケーションがベースとなったアーキテクチャになっています。このため、最新のWebテクノロジーと組み合わせてシステムをパワーアップさせることが可能です。より実践的な１つの例としては、Nginxを組み合わせたシステムです。リバースプロキシとしてNginxを導入して、静的コンテンツのキャッシュをここに置くようにすることで、レスポンスタイムを短縮させることを狙ったコンフィグレーションを行うことができます。

図７ Nginxを含めたシステム

上の図では、NginxとAlfrescoサーバ(share/alfresco)間は１対１（実線）で結ばれていますが、Nginxではロードバランサの機能も持つので、それを利用して、もう１つのAlfrescoサーバと接続して負荷分散を図ることもできます。また、セッションレプリケーションのためにNginxにmemcachedを追加することも可能です。その他、クライアントとの間のレスポンスデータを可能な限り小さくするために、pagespeedを入れることもできます。下はAlfrescoとNginxをAWS上に構築し、Webサイトのパフォーマンスを計測してくれるGTmetrixというサイトを使ってパフォーマンステストを行った結果ですが、pagespeedがある場合には、ない場合と比べると、40% Request-responseを減らすことができ、ページをローディングする時間が1.6秒小さくなりました。１セッションあたりのレスポンスタイムを下げる施策としては、簡単な設定で効果を得られることがわかります。