モバイルコンテンツサーバシステムの標準規格化 Mobile COSMO の紹介 2004/08/26 （株）ドワンゴ岡本征史 1 Mobile COSMO とは • Mobile Common Server Model の略 – （発音：モバイル・コズモ） • モバイルコンテンツに特化した、サーバシステムの標準規格を策定する活動の名称 2 キックオフ・メンバー • 株式会社コネクトテクノロジーズ • 株式会社サイバード • 株式会社ドワンゴ 3 (50音順）携帯電話の普及状況 90,000,000 80,000,000 70,000,000 60,000,000 50,000,000 40,000,000 30,000,000 20,000,000 10,000,000 0 96/1 IP接続サービス契約数３G 98/1 00/1 02/1 04/1 （電気通信事業者協会調べ） 4 モバイルコンテンツ市場 • • • • • 携帯電話の高機能化定額料金制常時接続性ネットワーク規模ユーザ層の多様化新たなビジネスチャンス！！ 5 外から見たモバイルコンテンツ市場 • ８０００万以上のユーザ数 • ユーザの携帯電話の使用頻度 • 非常に安易なアクセシビリティ他業種からの参入！業界間の連携！ 6 問題点 • 各ＣＰが独自のシステムを構築 • コンテンツ制作には高いコスト、高度な技術ノウハウが必要 • 新規参入が困難 • 高品質なコンテンツの制作が難しい • サイト間の連動が難しい（含むセキュリティ） 7 ソリューション • サーバシステムの標準規格を策定 • 運用上の各種レギュレーションを規定無料で広く公開！ＣＰのコンテンツ制作を楽に！コンテンツの多様化、高品質化を促進！煩雑な権利関係、個人情報、セキュリティ管理を保証！ 8 効果 • • • • • • コンテンツの魅力UPによる需要喚起および市場拡大モバイルコンテンツ業界市場の価値が上昇業界への投資の呼び込み新たな雇用の創出人材の流入統一的な教育が可能 9 情報提供者やパートナーとのすみわけ強化産業の信頼感向上コンテンツ・サービスの拡大周辺産業とのコラボレーション強化参入企業拡大開発手法確立・普及新たな投資の呼び込みセキュリティポリシー確立・普及統一レギュレーション策定運営手法確立・普及人材の流入必要な技術スキル明確化各種IFの構築・公開 10 キャリアへの提言端末メーカへの協力体制規格の５つの目標 1. 2. 3. 4. 5. 11 高品質なコンテンツの作成・配信を可能にコンテンツのメンテナンスを容易にサーバ間の柔軟な相互接続性を確保高い信頼性の確保他業種との連携を容易に 1. 高品質なコンテンツ制作 • より複雑で高度なコンテンツの作成・配信を可能に – サーバサイドプログラムの複雑化・大規模化 – データサイズの大きなコンテンツの配信 12 2. コンテンツ・メンテナンス • コンテンツのメンテナンスを容易にする – 規格に則ったインターフェイスを持つことによって、サーバに直接は依存しないプログラムを作成する – モジュール単位の交換が可能 – 常時稼動下でのサーバメンテナンス – ログ出力の使いやすい標準形を提案 13 3. サーバの相互接続性 • サーバ間の柔軟な相互接続性を確保する – 多様な連携を可能にするインターフェイスの策定 – データを保護する機構を用意 14 4. 信頼性 • 高い信頼性の確保 – 明確なセキュリティーポリシー – 個人情報の管理方法 15 5. 業種間の連携 • 他業種との連携を容易にする – 既存の各種サービス間の連動を可能に – 他業種間で新しいサービスを立ち上げる際のソリューションのテンプレートを用意 – 他業種において必要となる権利処理関係のサポート 16 規定項目 17 規定項目概要 1. 2. 3. 4. 5. 6. 7. 18 システムアーキテクチャ Webサーバ標準規格アプリケーション標準規格通信インタフェース機能モジュールセキュリティレギュレーション運用・監視レギュレーション 1.システムアーキテクチャ 1. 2. 3. 4. 19 ハードウェア構成インタフェースログ、エラーコード、性能評価指標システム監視 1-1.ハードウェア構成サービスを提供するために必要なハードウェア関係の要件を規定する。 a. 想定規模(会員数、キャリア数) • 小規模から数百万人規模、複数キャリア(スケーラビリティ) b. ネットワーク要件(必要帯域) • サイズは小 / リクエスト数は大 c. 稼働要件(多重化構成) • ノンストップ稼働が要求される 20 1-2.インタフェース機能コンポーネントの役割および各コンポーネント間の関係を規定する。 – 想定するコンポーネント • FRONT:多重化した軽量フロントエンド(web server, サーバサイドタグ/スクリプト実行) • LOGIC:重量処理バックエンド • DB:データベース • PROXY:セット間連携のための中継サーバ • POINT:共有ポイントサービス 21 1-2.インタフェース (つづき) – 想定するコンポーネント • • • • 22 BACKEND:コンテンツ独自処理サーバ CACHE: コンテンツキャッシュサーバ SORRY: 過負荷時の誘導サーバその他: 1-2.インタフェース(つづき) – 接続パス(通信手順の規格化が想定できる経路) • • • • • • 23 FRONT-LOGIC LOGIC-BACKEND LOGIC-PROXY LOGIC-POINT LOGIC-BACKEND FRONT-CACHE… 1-3.ログ、エラーコード、性能評価指標サービスの稼働状態を把握するために必要な記録項目を規定する。 – ログ – 解析処理の共通化 • ログ格納項目 • ログ格納法(フォーマット、メディア) – Text, XML等 – 共通エラーコード • 3桁で上位桁にシビリティクラス等 – 性能評価項目 (次頁) 24 1-3.ログ、エラーコード、性能評価指標(つづき) – 性能評価項目 • • • • • • スイッチ、ファイヤウォールの総トラフィック Web serverの１秒あたりのレスポンス数 Web serverのリクエスト数あたりの平均レスポンス時間 Web serverの平均レスポンスサイズ各サーバマシンのCPU負荷/メモリ使用量/Swap状態/Disk負荷 Web serverのプロセス数/リクエスト量/レスポンス量/トラフィック/TCP セッション数 • Databaseのリクエスト/セッション数/他多数(DBMS依存) 25 2. Webサーバ標準規格 Webサーバにおいて、モバイル用に運用するための特別な要件を規定する。 26 3.アプリケーション・サーバ標準規格モバイルコンテンツの内部処理を行うサーバ・アプリケーションにおける共通の要件を規定する。 1. 2. 3. 4. 5. 6. 7. 27 会員IDの取り扱い入退会管理機種情報の管理方法データベースメール処理ロジックとプレゼンテーションを分離管理ツール 3-1.会員IDの取り扱いサービスの利用者を識別する情報を会員IDと規定する。ここではこの会員IDの扱いについて規定する。 – 会員IDは機種変更を行っても同一性を維持できるように管理する。 – 会員IDと切り離して論理的なユーザIDを定義するとキャリア間の移動にも対応できる。 28 3-2.入退会管理全サービスに共通的に発生する、会員の入退会に関する手順、要件を規定する。 – 規定のテーブル仕様に基づき、統一的に会員の入退会履歴管理を行う。 29 3-3.機種情報の管理方法端末の機種に関する情報はリリースとともに増加するのみで、共通的に参照される情報となる。この部分の要件を規定する。 – 機種情報は統一テーブルでマスタ管理を行う。 – コンテンツの運用時はDBではなく上記に基づいて変換出力したデータを使ってDB負荷を迂回する 30 3-4.データベースシステム上最も負荷が集中しやすい部分であるDB へのアクセス手段について規定する。 – DB負荷がボトルネックになるため、SQLに関してある程度の規定を行う – ログをとる 31 3-5.メール処理コンテンツサービスに伴うメール処理に関連した要件を規定する。 a. メール配信 b. その他 – キャリアに止められないようにするための条件 – エラーメール対応 – 特定接続サービスを利用する 32 3-6.ロジックとプレゼンテーションを分離コンテンツを実装する際に、ロジックとプレゼンテーションを分離することを推奨する。ここでは分離する場合の項目を規定する。 • 記述例: – スクリプト呼び出し  – 変数の展開  – 条件による有効/無効化ブロック <!—IF VarName==0-->….. <!—ENDIF--> 33 3-7.管理ツール運用者がシステムおよび会員の状態を把握、管理するためのツールの機能的な要求を規定する。 34 4.通信インタフェース通信における共通事項、外部との通信経路、およびその目的と要件を規定する。 1. サービス間連携 a. CP間連携も含む 2. 通信フォーマット a. 会員IDの表記法 35 5.機能モジュール各コンポーネント毎の内容を規定する。 1. モジュール・クラス構成 2. インタフェース 36 5-1.モジュール・クラス構成 • • • • • • 37 FRONT/Template FRONT/Script LOGIC (DB) BACKEND POINT 5-2.インタフェース • • • • • 38 LOGIC用プロトコル(FRONT-LOGIC間) BACKEND用プロトコル(LOGIC-BACKEND間) POINT用プロトコル CP間連携用プロトコル LOGICの機能モジュールのプラグイン・アーキテクチャ 6.セキュリティレギュレーションサービスの安全性を確保する要件を規定する。 1. 2. 3. 4. 素材管理(DRM) 個人情報管理（管理ツール）開発環境の取り扱いネットワーク設定 a. VLAN 39 ７．運用・監視レギュレーションサービスの安定運用にあたって必要な項目および体制を規定する。 1. 運用 1. 運用手順 2. 運用体制 2. システム監視 1. 監視手段 2. 監視項目 3. 監視体制 40 スケジュール 41 Phase 1 (2004/7 ～ 2004/8) • 活動ビジョンの合意 • 活動スケジュールの確定 • 必要な作業項目 – 各技術調査、権利調査 • 規格項目の確定 • MCFへのＷＧ設置 – モバイル標準化分科会内にＷＧを設置 • 8/25 ３社合同プレスリリース • 8/26 mobidecで発表 – 目的、概要、規格項目、達成イメージ 42 Phase 2. (2004/8 ～ 2005/3) 標準規格プレリリース版の策定 – – – – – – 43 期間：７ヶ月規定範囲：全対象項目公開範囲： WG内必須レベルに重点基本策定は、WG内ＭＬにて策定定期的に開かれる定例会議にてヒアリング Phase 2. (2004/8 ～ 2005/3 つづき） • 用語定義 • 参加企業を公募（まずはＣＰ、ＳＰ、ＳＩ、メーカー） • ＷＧのレギュレーションを策定 – 運用規則の規定 • • • • • 44 新規規格案・規格更新案の審査体制を組織審査手順の規定（規格認証を行う場合）メーリングリストの開設 2005/3 規格草案公開（国内）海外はプレスリリースのみ Phase 3. (2005/3 ～ 2005/8) • 標準規格最終版を策定 – Phase2 での公開後のフィードバックを反映 – Phase2 で規定された以外の企業にも公開 • 海外版の作成 • 規格確定、アライアンス詳細確定、運用開始 • 国内外での発表 • 2005/8 mobidec にて発表 45 ＭＣＦでの活動 • モバイル標準化分科会の中に「サーバシステム標準化ＷＧ」を設置 • メーリングリストによる議論 • 定例会議：隔月開催 • ドキュメント管理、サイト運営 • 総合窓口（問い合わせなど） • 発行物の頒布等 46 情報提供者やパートナーとのすみわけ強化産業の信頼感向上コンテンツ・サービスの拡大周辺産業とのコラボレーション強化参入企業拡大開発手法確立・普及新たな投資の呼び込みセキュリティポリシー確立・普及統一レギュレーション策定運営手法確立・普及人材の流入必要な技術スキル明確化各種IFの構築・公開 47 キャリアへの提言端末メーカへの協力体制製造金融流通放送コンテンツコンテンツプロバイダプロバイダ Mobile コンテンツ COSMO プロバイダ販売医療サービス福祉 48 出版教育お問い合わせ： [email protected] 49