仮まとめページ - HIMAGINE Wiki

• あちこちに分散しがちな情報を仮にまとめるためのページです。
• HIMAGINE関係の記述などを見つけたら、とりあえずここにぶち込んでください。

---

2010/06/06の12時前後に流れていた話題の仮まとめ。

Twitter上での大まかな流れ

なるさん	AIRを除くFlashアプリではディレクトリ内のファイル一覧が取得できない→サーフェス定義ファイルに記述されていないファイルを取得できないかも？ surface0とかsurface00とかsurface00000とかいろいろあるのはどうしよう？ ※SSPではもっとも桁数が多い物が優先される模様 https://twitter.com/fm7743/status/15525316845
みかげさん	サーバ側でファイルリストを作ってクライアントに渡せばその問題は回避できるかも？ そもそもZIPファイルを展開する前に中身の一覧とか取れないのかな？
なるさん	元々、一つ一つファイルをアクセスして、404かどうかで判定するつもりだった。 でも、サーフェス番号のところに任意の桁数を指定できるとは思わなかった。 ZIPオンリーにしてアーカイブから直接シェルをロードする発想はなかった(遅くなるからやらないと思う)。
みかげさん	個別にファイルにアクセスする場合、アニメーションサーフェスだとサーバに負荷が掛かりそう。 Flashに、ローカルストレージとかローカルキャッシュとかはあるのかな？
なるさん	サーバへのアクセスはWEB起動を念頭に置いていたため。ローカル限定ならどうと言うことはない。 Flashにはキャッシュ的な物しかない。Flashである限り、永続的なファイル保持は絶対無理
なるさん	AIRで組み立てるなら、ZIPで配布、ローカルに展開、ローカルから読み込み、でなんの問題もない。
みかげさん	オンデマンド呼び出しだと、数百枚のアニメーションサーフェスがあった場合にサーバの負荷が凄いことになりそう…… たとえば、1000人が10秒間で100枚DLしたら１万アクセス/秒になる。
なるさん	WEB版は、せいぜい作者の動作プレビュー用なので負荷は問題ないのでは？ エンドユーザはAIR入れて貰わないと大変かも。
みかげさん	一般ユーザ向けにもWEB版も標準装備するのだと思ってた。 AIRインストールできないけどFlashなら大丈夫、と言うような環境を想定。
なるさん	サーバ負荷を気にしないなら可能にしても良いと思います。

2010/06/06の17:30頃～20:00頃のログ仮まとめ

なるさん	シェルフォルダのサブディレクトリに画像が置かれることってありましたっけ？
くーぷらんさん	サブディレクトリに画像を置くことはしません。無視されるはずです。
せきやひろし	基本は無視ですが、サーフェス定義ファイルで指定すれば読みます。 場合によっては上位ディレクトリに遡ってアクセスすることも可能。
なるさん	上位ディレクトリに遡るのはセキュリティ上禁止したい。
みかげさん	あんまり大変そうなら、シンプルにしたSERIKOのサブセットを定義するとか？
なるさん	省略できるところがなかなか見つからない。下手に省略すると、シェル定義ファイルの書き直しの手間が凄いことになる。 プログラマが楽をするためだけに、そう言うことを絵師さんに押しつけたのでは上手くいかないと思う。 そもそも今はアニメーション表示以前の、静止画としての立ち絵を表示するところで躓いている。 たとえば、\s[2024]に相当するサーフェスを定義する方法が何通りもあるのでどうしよう、と。
せきやひろし	SERIKO定義と言えば、水無月さんが公開されてる「れいちぇるのレストラン」が、かなり鬼畜なので、ご参考までにｗ
なるさん	SERIKO定義もだけど、バルーン内部への画面貼り込みの方が脅威(汗)。 ※画像貼り込みは\_bタグ。当面無視される模様。
みかげさん	どうせだからFlashとかも表示できると面白いかも。
noisenoise	フルアニメーションシェルが簡単にできそう？
せきやひろし	Flash使えると時計表示とかが簡単にできますね。今の仕様だと凄くめんどくさいので。
なるさん	SWFをそのまま重ねるだけなら凄く簡単でしょうね。

2010/8月上旬の「ユースケース」欄での仕様議論アーカイブ。

課題

• リスナーにアカウントを要求すると利用者が増えにくいのでは
• Twitter連携の課題
  • 文字数の制限をどうするか
  • ID・パスワード指定での連携はもう無理になるのでOAuthへの対応が必要そう．
  • 作るのが大変．一度システムをくみ上げるところまではできたとしても，その後のTwitter側の仕様変更に追従できるほど時間の確保は難しい．TwitterのAPI仕様はちょくちょく変わっている模様．（この部分を他の人がやってくれるなら大丈夫）
• リスナーの管理のサーバ側リソースの問題
  • リスナー毎にアカウントを管理すると，サーバ側で配信するデータを選ぶ操作が入る上，分散がしにくくなってしまう．
  • リスナーの管理無しの場合，以下のような形でスケールアウトできます．
    • サーバは，投稿が行われるマスターサーバと，メッセージの配信のみを行うスレーブサーバの2種類あります．
    • スレーブサーバはマスターサーバに接続し，配信するメッセージを受け取ります．
    • クライアントは，マスターサーバに接続しますが，その際にスレーブサーバへの再接続を指示されることがあります．その場合，スレーブサーバに繋げ直します．
  • サーバ1台あたり，処理できるユーザ数は数千～1万人程度までです．常時接続なので，通常よりシビアになります．
  • リスナー毎のアカウント管理を行うとした場合，上記のような分散はかなり複雑になってしまいます．
  • リスナーがどのキャラクターを読むのか，といったのはクライアント側で区別して処理する形の場合，以下のように柔軟に対応できます．
    • 最初は全部がデフォルトfollow
    • キャラクターの数が増えて来た場合，デフォルトで著名なキャラクターをセレクトしておき，追加のfollowを手動で行うようにする．
  • クライアント側で購読キャラクターを管理する場合，キャラクターの人気を測定できないので，そこは定期的にサーバに情報を送るなどして，別途集計する必要がありそう

Re:課題 (naruto)

• 2ちゃんやTwitterと違い、1個のメッセージ再生ごとに時間を食うため、SSTP Bottleの100人程度のコミュニティですら、全員同報では再生が追いつかないことが頻繁にありました。その経験から、まともに人間が処理できる購読キャラクターは、Twitterでのそれの1割程度、つまり精々数百キャラクターに留まると思います。サーバ1台で間に合わないほどユーザが増えた時点で、全キャラクターの発言を追いかけるのは到底無理です。
• 仮にユーザが1万人を超え、複数サーバを考慮しないといけない事態になった場合、全員全文同報方式ではほとんど全てのトラフィックが無駄になります。サーバが5台になる頃にはもう、どんなヘビーユーザでも99%、普通のユーザは99.9%のトラフィックを無駄に捨てることになり、ちょっと許容できないレベルではないでしょうか。
• 単純に、あらゆる個別サーバのネットワーク負荷が、全体のユーザ数に正比例して増えるシステムは、正しくスケールアウトできていない気がします。
• 全同報方式の場合、仮にN人のユーザがいて、そのうち5%が5秒の間に「あけましておめでとう!」なり「日本勝った!」なり「バルス!」なりで、ヘッダ込み200バイト程度のメッセージを一斉に送信した場合、サーバ全体からのoutboundの帯域は

200(Byte) * 0.05N * N / 5(s) ≒ 10N^2(Bps)

で、N=10000の場合で1GBps、N=50000の場合で23GBpsです。N^2オーダーで増えるため大変厳しいです。これが「1キャラの発言を受信するリスナーは平均100人」で済むなら、

200(Byte) * 0.05N * 100 / 5(s) ≒ 1000N(Bps)

で、N=10000の場合に76Mbps、N=50000の場合に380Mbpsと、かなり現実的になります。

• 数万キャラと数万人のリスナーとの購読対応テーブルは十分各サーバがオンメモリで持てる範疇と思います(ですよね?)。
• 結論として、N＜1000くらいまでの間は「全リスナーが全キャラの全メッセージ受信」で大丈夫と思います(現状のボトルとほとんど一緒だし、結局永遠にそれで良い可能性もありますし)。が、本当に複数サーバを考えないといけないほど人気が出た場合、何としてもサーバ側で選別処理するのは必要になってくると思います。
• キャラ人気測定にも絡みますが、「ユーザがどのキャラクターを購読しているか」のリストは、ローカルの設定によるフィルタではなく、サーバサイドできちんと管理するのが必須だと思います(実際のフィルタリングをローカルでやるとしても、そのリスト自体はサーバから受信)。上記の様な将来の拡張性を見越す上でも必要ですし、複数箇所でログインする可能性の利便性もありますので。
• リスナーに最初からアカウント登録要求するのは確かに面倒くさいですね。例えば「HIMAGINEスタッフお勧めキャラクター数十人をとりあえず購読できるお試しモードを作る」というのはどうでしょう?
• ていうか、もし1万人を超えるようなら僕の手に負えないので、どっかで事業化考えてくださいw

Re:課題 (mikage)

• 数万人のリスナーはなんとかなったとして，数万キャラはどうにもなりません．キャラクターとして対応できるのは数百程度までだと思います．
  • 1つのシェルが 10MB だったとして，10分以内に1万人に配布しようとしたら，1333Mbps の帯域が必要になります．これはスレーブサーバの協力者がたとえ20人いたとしても無理があります．
  • 1つのシェルが 10MB だったとして，1万キャラクターをHDDに記録するには 10GB の容量が必要です．更にアーカイブを展開したデータも持つならその2倍．マスターサーバ側ではこのくらいの容量は工面できますが，他の方にスレーブサーバの協力をお願いするときに「協力してくださる方はディスクは20GB用意してください．」というのはなかなかハードルが高いと思います．
  • それに比べて会話データは大したボリュームではありません．10秒に1回1KBの発言があり，1万人に配布する場合は 8Mbps の帯域があれば十分です．
    • 1万人のリスナーがいて，発言をする人が100人だとして，その100人が1日20回スクリプトを流すとしたら…というように考えると，実際に帯域が問題になるほどの発言量がでることはずっとずっと先の話だと思います．Twitterやボトルなどと違い，受け取るだけのユーザが大半でしょうし，トークを書く方もさくらスクリプト等で書く必要があるので，発言数もそんなに増えないと予想します．
• 「数万キャラと数万人のリスナーとの購読対応テーブルは十分各サーバがオンメモリで持てる」というのは，それようにサーバを用意すればその通りでしょうが，スレーブサーバを誰かに協力してもらい，リソースを貸してください…ということで対処しようとしたら，難しい容量になると思います．レンタルサーバなどでは512Mなどのところも未だにありますし，自宅サーバでも4Gとか8Gとかのせている方は少ないと思います．1人のキャラと1人のリスナーの対応の保持に16バイト必要だとすれば，1万人×1万人×16バイト＝1.6GB になります．更にこのデータをスレーブサーバとマスターサーバで共有する必要があり，その通信も発生します．
  • ちなみに，わたしの自宅のサーバは1.6Gはなんとかなるかもしれませんが，スレーブに使おうと思っていたレンタルサーバの方は512Mしかメモリがありません．
    • 追記：スレーブサーバは自分が対応しているユーザ数分を持てばいいし，followしているものだけを管理すればいいので，実際には5000人×500フォロー×16バイト＝40MBくらいで済みそう．

• キャラクター数が1万人超え，のような状況になったら，帯域の問題含め対処が必要で，現状のサーバリソースではどうにもなりません．
  • 現状のサーバリソースでできる範囲を考えたら，サーバ側での選別処理は必要ないと思います．

Re:リスナーの動作について (mikage)

• リスナーの新規キャラクターのfollowは自動でされる方が望ましいと思います．
  • 前提として，キャラクターが1万とかの世界ではなく，100程度までの状態をイメージしています．
  • この段階では，興味のあるキャラクターをユーザが探して，それをfollowするという作業自体が面倒なものになります．また，新規にキャラクターを作る立場からすれば，自分のキャラクターを別の経路で宣伝して，リスナーにフォローしてもらわないといけなくなります．フォロワーが少ないと，キャラクターのキャストのモチベーションも上がりにくく，悪循環です．
  • 初期は全リスナーがアカウント登録不要で，全キャラクターを自動受信．不要なキャラクターをblacklist方式で除外する方式がよいと思います．
    • もしそれで破綻するほどの人気が出た場合は，その段階で，インストール時はその時点で活発に会話がある上位○キャラクターを自動follow，その他は手動followにする必要があると思いますが，それまでにはキャラクターを選んで簡単にfollowできるシステムが必要だと思います．
      • フォロワーの数や，最近1週間の発言数などでのランキングがクライアントに表示されて，ワンクリックでfollowできるとか．

• Twitter等に比べて，投稿のハードルが高いので，全キャラクターを自動受信方式で当面は問題が出ないのではないかと思います．むしろその方式でも会話数が少なすぎるのではないかという心配から，ランダムトーク相当の機能を考えていたくらいです．

未検討事項

• 現状ではランダムトークに相当するものがありませんが，これはある前提でOKですか？
  • 今のテストサーバ側ではランダムトーク相当の機能を実装しています．

合意・初期段階実装事項（とりあえずmikage/narutoで）

• シェルに関する部分
• キャラクターに関する部分のうち，SSP・Twitter連携以外の部分
• Web上・AIR版クライアントからのメッセージ投稿