TwitterクローンのWebアプリを開発・運用した場合に最も困るのは負荷である。またキーワードやハッシュタグで検索の仕組みを入れるのは当然で、最低限のユーザビリティを確保するためにも必要。他にも重要な機能はどんなサービスにするかで変わってくるが、匿名掲示板２ちゃんねるでも検索の仕組みで困ったとひろゆきが言っていたような気がする。
膨大なテキストデータからユーザが必要な情報を拾い出すのは規模が大きくなればなるほど至難というか高コストになってしまう。これを低コストにできないか？低コストにすることでどうマネタイズするかはさておき、サービスの損益分岐点が下げられるだろう。で、その検索の仕組みの低コスト化は「制約はあるができるんじゃね？」と思ういに至ったので書いてみたい。
仕組み自体はシンプルで非常に原始的である。似たような仕組みでインデックスを生成する検索の仕組みがある気がしないでもない。デスクトップアプリケーションにおけるカードデーターベースもこれと同様の索引手法で高速に検索する仕組みを保っていたりするのでは。Twitter風（X風）なアプリを作る前提で説明すると…
ユーザの投稿データはすべてテキストファイルへ書き込まれてS3に格納される。投稿データにはハッシュタグをつけることができる（想定では１投稿あたり５個以下のハッシュタグをつけられる）ハッシュタグごとに投稿内容を時系列にテキストファイルへ格納する。
ユーザは検索窓にキーワードを入れてサジェストにて選択する。ハッシュタグ検索の処理は、サーバへ検索パラメータがポストされた時、ハッシュタグがつけられたテキストファイルを単純にリターンする（S3がテキストファイルを探し出す仕組みを利用する）。サジェストで選択するハッシュタグのリストは何らかのNoSQLなどに格納して管理するか、投稿データに付与したサジェストの数をカウントし、優先度を決めて重複を除いてリストファイルを都度前もって生成するような仕組みでもいいかもしれない。
Twitterの投稿データは時系列にInsertされるものでUpdateされるような性質ではない。だから、ハッシュタグの検索におけるデータの取り出しやすさ、ハッシュタグのサジェスト出力リストの生成しやすさ、この２つを考慮したインデックス生成を投稿時にすれば済む。
…というか、インスタは忘れたがTiktokは投稿した動画を削除することができないから、このような仕組みになっているのではないだろうか？と思ったのだ（後で調べてみる）。
現時点で想定される問題というか弱点として、S3からのデータ書き込みや読み込みは意外に遅いのではないか？と懸念している。テキストデータをCDNでキャッシュ化する手もあるが、テキストファイルの更新頻度が高い場合にあまり効果的ではない気がする。
細かいところはいろいろと欠点はあるかもしれないし制約も多いが、これでサーバレスで低コストなTwitter風アプリつくれるんじゃない？なお、テキストファイルの取得（検索処理データの取得）はAWS Lambdaを使用することで安定性と運用の低コスト化が実現できないだろうか。
コメント