“A9共催！ AWSプロダクトシリーズ

よくわかる AWS CloudSearch”

スクーでのCloudSearch利用実例

伊東 弘満 2014-10-17 schoo, inc.

ビジネスクリエイティブ学部

About Me

自己紹介●今年でピッタリ40歳。（今年は前厄ですね…）

● UNIX系のインフラエンジニア。

●受託開発を主体とするソフトハウスで開発業務に9年間ほど従事していたので大概の言語は読めるし書けます。

● 30歳の頃に転職し、GMOにて大規模Blogシステムの運用に2年従事。

●今は無きACCAというインターネット事業者で、今は無きzoomeという動画配信サービスの企画とシステムの設計・構築・運用までを4年間。

●前職はgloopsというSAP（Social Gameのほう）で数千台のサーバを運用する部門の責任者兼Architectや品質管理部門立ち上げを2年半。

● 2014年4月よりスクーに。ポジションは執行役員 インフラ開発部門責任者。

●デジタルガジェットが大好物。

ビジネスクリエイティブ学部

About ‘schoo’

スクーとは・・・

サービス開始以降、過去 1000 以上の講座をインターネット上で無料生放送にて提供中。

過去の授業では、最大 4000 人の受講者が集まったことも。

現在会員数は10万人を超え、既存のe -ラーニングと違う『コミュニケーション』を主体としたインターネットで動画学習できる「学校の新しいカタチ」を目指す。Sorry…Japanese Only.

会社は2011年10月に設立。 2012年1月より’schoo WEB-campas’(https://schoo.jp)を開始。

今日はLTなので、技術的な細かい話は省略してますが、「スクーのシステム構成」については、誰も何処でも話をしていないので、初出しの情報です。

本題のCloudSearchについては、前置きの説明はありますが、利用するにあたってのIndexの設計とかデータの登録とか、スクーでは「どのようにしているのか」を簡単にお話します。

ビジネスクリエイティブ学部

schoo System Diagram

Web Service Hosting

Cloud Search

EC2

EC2

ELB S3RDSElastiCache

Web＆Application Server（EC2） Web ServerとしてNginx、ApplicationはPHPで作成さ れており、php-fpmを利用しHostingしている。

Database（RDS） RDSでMySQLをMulti-AZで構成。 Read Replicaも複数台用意しApplicationサーバから 分散アクセス。

KVS（Redis） ElastiCacheで集計データ（Ranking）等を保持したり、 RDSに毎回重いクエリを投げることがないように Temporary Cacheとして利用。

Storage 授業で表示するSlideや各種Imageファイルを保持。 一部の画像はS3からDirect Hostingしている。

今日の話はココ！

Encoder Batch Server（EC2） S3に配置された動画を、指定フォーマットでエンコードするよう Elastic Transcoderに指示し、エンコードされたファイルをS3に 結果をRDSに保存する。※ 今後で実装予定の機能のため現在は未稼働。

Other Batch Server（EC2） 定期的に処理（定時処理）を実行する。 処理対象はRDSやElastiCacheのデータを処理し、結果をRDSや ElastiCacheに保存する。

PDF-Image Converter Batch Server（EC2） S3に配置されたスライド資料（PDF）を、画像（JPEG）に変換し 変換した画像をS3に、変換結果をRDSへと保存する。 併せて入稿情報を検索用にCloud Searchへと登録する。

Mail Render/Deliver Batch Server（EC2） 指定フォーマット（テンプレート）及び送信先のリストをRDSから 読み込み、作成したメールフォーマットにてメールを送信するよう SESへと指示する。

Batch Processing

Elastic Transcoder

SQS

Cloud SearchEC2

EC2

ELB S3 RDS

SES

EC2 (Batch)EC2 (Encode)

EC2 (Convert) EC2 (Mail)

ElastiCache

ビジネスクリエイティブ学部

Introduction of “CloudSearch" in schoo.

検索機能の導入に至るまで…2012年1月にサービスを開始したが当初から検索機能は用意していなかった。。。

※ 2011年12月当初のTop画面 プレハブ校舎版

検索機能の導入に至るまで…

schooではUX4軸として掲げる目標の一つに

「自分にふさわしいコンテンツと出会える仕組み」

という目標を掲げている。

自由文字列での検索が用意されていない状況下においては、授業毎に設定してあるカテゴリやタグから探す

ことは可能だが、1000を超える授業コンテンツから目的の授業を探すことは非常に困難！！！！

検索機能の導入に至るまで…

2014年8月、満を持しての検索機能の導入！！ｗ

※ 2014年８月当初のTop画面 （本校舎β版）

検索機能の導入に至るまで…

本格的な導入の検討は2014年7月に入ってから。

当初はElasticSearchをEC2で自前運用するつもりだった。

設計と実装を進める中、2014年の7月中盤頃に突如としてCloudSearchへの切り替えを決定ｗ

検索機能の導入に至るまで…

ElasticSearchからCloudSearchへの突然の切り替えについて、「なぜ切り替えたのか？」…

当時の会話を何となく振り返り、何となく再現してみたいと思います。

検索機能の導入に至るまで…

昨日さ、Amazon CTO Nightに行ってきたんだけどさ… CloudSearch良さそうな感じなんだよね…

えっ！ すでにElasticSearchで実装始めちゃってますよ！！

※ 弊社某エンジニアには掲載未確認のため目線を入れております。

検索機能の導入に至るまで…

・・・そう・・・ だよね・・・うん・・・

・・・　・・・　・・・　・・・ ・・・　・・・　・・・　・・・

・・・うん・・・ まぁでも、CloudSearchに変えたいよねｗ

※ 弊社某エンジニアには掲載未確認のため目線を入れております。

検索機能の導入に至るまで…

じゃぁ・・・ 切り替えますか！

いっちゃいますか！ じゃ、今からCloudSearchでｗ

※ 弊社某エンジニアには掲載未確認のため目線を入れております。

検索機能の導入に至るまで…▶設計段階においてAnalyzerとかの設計をする必要がほとんどないので設計工数を削減可能。（ElasticSearchとの比較） ▶現在はAnalysis Schemeに「Japanese」を選べば日本語形態素解析、「Multiple Languages」を選べばN-Gramでの解析になる

▶自前でサーバ構築や運用をする必要がないので、構築/運用での工数削減が可能。（ElasticSearchとの比較）

▶運用開始後に格納ドキュメントが増えてきたりで、パフォーマンスを向上させたいときも勝手にやってくれる。

▶格納ドキュメント数でインスタンスサイズを決められるから、運用時のコストも読みやすい。 ※データOutでも課金されるけど最初の仕切りが10TBからの$0.201（東京リージョン）なので、あまり気にしなくても大丈夫…多分。同一リージョン内であれば転送料は無料！

ビジネスクリエイティブ学部

Index Design and more...

スクーにおけるCloudSearchでの設計

検索対象：授業タイトル、授業詳細、タグ、カテゴリ、 動画チャプター、団体名、団体説明、 先生名、先生説明…etc

検索対象となる項目が多いため、上記全てを検索対象として一括検索して結果を表示しても、表示内容には限度もあるため、ユーザには判断が出来ない場面もあることを想定し、UI設計段階から検索対象の絞込を想定し設計。

CloudSearchでのIndex設計

Indexの設計は以下の様な感じ。（一部抜粋）

Field Field Type Description

index_type text type(class, minute, provider, teacher)

class_id integer Unique ID（Class）

title text Class Title

archive_status integer 0:Open、1:Close

… … …

絞込条件としてindex_typeを用意し、登録/検索するデータがclass（授業[生放送/録画]）、minute（３分授業）、provider（団体）、teacher（先生）と、何なのかを判断できるような設計。

Analysis Schemeは原則「Japanese」で。

API設計 ※ 全ての検索において並び替え（Sort）はScore順を利用▶「すべて」のAND検索

Query例： /search?q=スタートアップ&return=index_type,class_id&start=0&size=25

Return：　JSON {index_type, class_id, minute_id, provider_id, teacher_id}

▶「生放送」のAND検索 Query例： /search?q=‘スタートアップ'&fq=(and index_type:'class' end_date:{,’2013-11-30T21:00:00Z’}) &q.parser=structured&return=index_type,class_id&start=0&size=25

Return： JSON {index_type, class_id}

▶「録画放送」のAND検索 Query例： /search?q=‘スタートアップ'&fq=(and index_type:'class' (or archive_status:2 archive_status:3)) &q.parser=structured&return=index_type,class_id&start=0&size=25

Return：　JSON {index_type, class_id} ▶「3分で学ぶ」のAND検索 Query例： /search?q=‘スタートアップ’&fq=index_type:’minute'&q.parser=structured &return=index_type,class_id,minute_id&start=0&size=25

Return：　JSON {index_type, class_id}

▶「先生/団体」のAND検索 Query例： /search?q=‘スタートアップ'&fq=(or index_type:'teacher' index_type:’provider’) &q.parser=structured&return=index_type,teacher_id,provider_id&start=0&size=25

Return：　JSON {index_type, class_id}

Redisの利用▶検索ワードの保持 ↳「直近の検索ワード」機能での利用

100件を上限としたList型

↳「検索ワードランキング」での利用

保持件数は無制限、Expire Timeを1MonthとしたSorted Set型

▶データ登録の時点でNormalize ↳半角カタカナ→全角カタカナ

↳全角英数字→半角英数字

CloudSearchへのIndexingデータの登録はSQSを利用したパイプライン化されたバッチ処理の仕組みを構築してあるので、授業情報入稿時の処理として登録処理を実行。

SQS

Cloud SearchEC2

ELB S3 RDS

EC2 (Convert)

入稿ツールより投稿された資料(PDF)を S3に配置し、変換要求QueueをSQSに登録

①SQSより変換要求Queueで指定された対象 資料をS3から読み込み、画像(JPEG)に変換

②

画像変換の際に読み取ったテキスト情報と 入稿情報をCloud SearchにIndexingする

④画像(JPEG)に変換したファイルをS3に配置 し、RDS上の入稿データ(Status)を更新

③

ビジネスクリエイティブ学部

Summary

まとめスクーでは教科書通りの標準的な使い方。

Index設計の際には、使う「場面」と、登録する

「内容」をよく考える必要があるけど、データ量と処理

量に合わせてスケーラブルな拡張も容易。

急な仕様変更での導入となったけど、リリースするまでに1週間程度で導入を実現。

入力フォームを設けるならSQL injectionの心配は無いけど、XSSの対策は勿論しないとダメｗ もっと気軽に使えるようなサンドボックス的なもの用意してくれないかな…

ご清聴ありがとうございました！