AVAFIT Pro Architecture

OSや開発言語に依存しない接続環境

AVAFIT Pro は、ウェブサービス技術である SOAP（Simple Object Access Protocol）通信及び、ダイレクト接続を支援しているので、どの言語・どの環境のサイトにも組み込むことができます。

SOAP通信といっても難しい処理を覚える必要はありません。レファレンスとサンプルソースコードを参考にしながら簡単に実装できます。 サンプルコードは、必要な機能が一通り搭載されており、そのまま利用していただいても何の遜色もありません。



大規模サイト対応のマルチサーバー環境支援

AVAFIT Pro はお客様のご希望に合わせて１台から数台の構成として提供しております。本来アバター開発キットは大規模アバターコミュニティーサイト（数百万人以上）に対応する目的として作られましたので、サイトの規模に合わせて分散処理が可能になっております。
大規模サイトでは機能ごとに制限なくサーバーを増やすことができ、完璧なマルチサーバー環境をサポートすることで、強力なアバターシステム基盤をご提供いたします。
下記は大規模サイトで AVAFIT Pro を導入した場合のサーバー構成になります。 もちろん、１台に纏めることも可能です。

AVAFIT Pro のマルチサーバー構成例

IMAGEプロセスサーバー／DBサーバー／管理サーバー／UI搭載のお客様番組サーバーのすべてのサーバー群はAPIサーバーだけに接続する独立基盤設計を採用することで優れた拡張性を発揮します。 例えば、管理サーバーをIMAGEプロセスサーバーと統合することも、管理サーバーをマルチ化することもできます。１つのサーバーにAPI機能・IMAGE機能を両方持たせるとして複数サーバー合成することもできます。また、既にサービスを稼働している場合でもサービスを止めることなくAPIサーバーを増設したり、IMAGEプロセスサーバーを増設したり、管理サーバーを増設したりすることができます。

API Server

大規模環境において複数のAPIサーバーを使う場合、すべてのAPIサーバーは同じ処理を行い、APIサーバー内には何のデータも保存しないため、外部からは複数のAPIサーバーを区分しなくアクセスすることができます。 そのために、万が一APIサーバーの１台が壊れた場合は、APIサーバーを参照する管理システム及びUIの設定ファイルから対象のAPIサーバーを外すだけで障害を解消できます。

ロードバランシングを行う環境では一つのドメイン・IPで複数のAPIサーバーに振り分けることができますので、複数あるAPIサーバーの一つが故障しても自動的に他のサーバーを利用してサービスが継続できます。 また、サービス中においても、サービスを停止することなく増設することも可能です。APIサーバーは下記のような特徴を持ちます。

  • AVAFITシステムにおいてのエンジン役割
  • 他のサーバー群はすべてAPIサーバーのみを経由するので拡張性が優れている。
  • 複数のAPIサーバーを導入したシステムにおいて、UIからAPIサーバーを参照する際に、APIサーバーが同じドメインである必要はないので L4 Switchなどの装置を使わなくてもマルチ構成が可能
  • ロードバランシングを行う場合は、一台が故障してもサービスの継続が可能
  • 構造的に台数制限のないAPIサーバー
IMAGE Process Server

IMAGEプロセスサーバーはアイテム画像ファイルを保管し、アバター及びアルバムなどの合成ファイル生成、アバター画像の配信を担当するサーバーです。

管理画面よりアバターのアイテムを登録すると、管理サーバーはアイテムの画像ファイルを画像サーバーに送ります。 画像サーバーを複数導入したシステムであれば、アイテムを登録する度に自動的に全画像サーバーにアイテムを送ることになります。 そのため、複数の画像サーバーがある場合は、１台が壊れても他の画像サーバー上にあるアイテム画像ファイルをコピーすることで復旧が可能になります。

  • アイテム保管（全画像サーバー共通）
  • アバター及びアルバムの作成・保管（ユーザー毎に一つの画像サーバーに保存）
  • サービスを停止せずに増設可能
  • アバターまたはアルバム画像がなくなった場合は、再作成可能
  • 複数の画像サーバーのどのサーバーにアバターを作るかを自動決定。 指定することも可能
  • 複数の画像サーバーがある場合、同一ドメインを使う必要がないのでL4 Switchなどの装置を使わなくてもマルチ構成が可能
  • 構造的に台数制限のない画像サーバー

アイテムの合成で作られたアバター画像及びアルバム画像は、アイテムそのものとは異なり、ユーザー毎に配置される画像サーバーは一つだけになります。 アバター作成・着替えなどの処理を行う際に、複数の画像サーバーで同時に同じ処理を行うのは負荷がかかるためです。

もし、画像サーバーが壊れた場合、アバター画像及びアルバム画像は完全に無くなってしまうのではといった心配をされるかもしれませんが、アバター画像及びアルバム画像は、元のアイテム画像さえあれば再生することができるのでご心配は要りません。 API関数の中にはアバターを再作成する関数が用意されていますのでユーザー分実行するだけでアバターが再作成されます。 また、サーバー単位で再作成するバッチもご用意しています。

DB Server

本システムは、MySQLデータベースを利用しています。 複数のデータベースを利用する場合は、マスタ・スレーブといったレプリケーション構造を利用することになります。 データベースにデータが追加される際には、まずマスタサーバーに情報が書き込まれ、ほぼリアルタイムでその情報がスレーブサーバーにコピーされる仕組みです。 マスタサーバーは新規データの追加や変更の処理を担当し、スレーブサーバーはその内容の参照を担当することになります。

  • MySQLデータベースを利用し、画像以外の全てのデータを保存・管理するサーバー
  • マルチ構成の場合は、レプリケーション構造を利用する。
  • 複数のスレーブサーバーを利用する場合、各スレーブサーバーの処理割合を指定することが可能
  • マスタサーバーもスレーブの役割を担当させることが可能
  • データベースの増設・故障などの時は、サービスの停止が必要
MANAGEMENT Server

管理サーバーはAPIサーバーのみに接続します。 データベースサーバーや画像サーバーに対する情報を保管する必要がなく、すべての処理をAPI経由で行いますので、UIと同様に設置に制限がありません。

  • APIサーバーだけ接続するので設置制限なし（UIと同様）
  • 管理サーバーが壊れてもサービスへの影響を回避
  • 管理機能は負荷がかからないのでAPIサーバーあるいは画像サーバーに設置可能

アバターに関する情報以外の管理ツール独自の情報（担当者情報・権限情報など）は独自のデータベースで管理しています。 そのデータベースは、アバター用データベースと統合することも独自に持たせることも可能になります。