イベント詳細
日 時：2016/11/14(月) 19:30 〜 21:30
会 場：イベント＆コミュニティスペース dots.
住 所：東京都渋谷区宇田川町20-17 NMF渋谷公園通りビル 8F
主 催：株式会社レコチョク
1. 国内最大級の音楽配信サービスでスクラム開発やってみた
全面リニューアルやったよ
もともとはweb viewベースのアプリだった
どうやって？
dヒッツ x スクラム
なぜスクラムを使用したか？
既存の問題点 - 遅れが発生したらリカバリープランなど細かいタスク管理がされてた（ステークホルダーがいた - 大きな手戻りがあった（アプリならでは - 開発に効率化を（定常化された残業やめよう
弊害あった？
- DocomoはすんなりOK リスク管理だけはさせてね♪
- 1週間ごとにアプリを触ってもらった
大きな手戻りがなくなった
- ソコープアウトの調整もスムーズ
- 開発領域を超えた会話が増えた
チームの自立
- 18週間終えたあともみんなが勝手に持続しはじめた
- 定時に帰り始めた！
KPTのKの半分が残業しなかったー！
これから
- 対外的には良かったけど内部の企画担当がよく見てなかった
- 終盤には追い込みが..
KPTのT がんばる・住む Pは靴を左右間違えた・頭が回らない
2. OracleからAuroraへfeat. 開発しかやってこなかったエンジニア
クラブレコチョク？
レコチョクが展開するサービスへ会員機能を提供する 会員1000万 1億レコード以上
なんでAurora??
- 高い可用性
提供サービスが多いのでメンテとかいれられない
- Oracle RACつかってたから
- 運用工数を抑えたい
でもでも、Oracle RACも捨てがたい・・・。 EC2上にデプロイできるけど運用コストがかかる。
実際になにをしたか
- Oracle→MySQLのエンジンの違いを埋める
- - パフォーマンスチューニング
検索用のテーブルを新規に作ったよ もともとOracleだと数秒だったのがな何分もかかるようになったから（後方一致
移行方法
- 一ヶ月ぐらい前からデータをバックグラウンドで移行した
引っかかった点
- トランザクション分離レベルが違う
- YEARの扱いが違う
運用やってみてAuroraで気付いたこと
- CPUが比較的高め
Auroraはパフォーマンスをがっつり使うタイプなので正常ではある（95％超えても普通とか
- 大型のメンテをたまにやられる
結果どうだった？
- Auroraは障害0
- 性能問題なし
- DBは工数ほぼなし（チューニングもそんなに
- たまにメンテくらうよ（AWSあるある
これからやろうと思ってる人へ、使い所
- か尾津中で割と不可のあるDBは移行しやすい
- 小さいインスタンスタイプがなくてちょっとこまる（DB-Largeとか
- PostgreSQL互換はないよ
まとめ
- Oracle RACとほぼ同じ性能
- 運用経験なくてもAuroraに任せて仕舞えばいいので、開発に集中できるよ
3. CloudSearchでレコチョク検索の実現を目指して
背景
- オンプレからAWSに！という全社の流れで。
技術要件
- SolrからCloudSearchに
検索要件
多種多様な文字列・記号を含む検索 シノニムとストップワードの適応 検索文字列の正規化 特定の情報でヒットした情報（アーティスト名とか）を上位に優先付けする
CloudSearchとは？
AWSクラウド環境に検索基盤を構築してデータの登録・検索ができる
特徴
- インフラ構築がいらない
- 数クリックで構築できるのはいいけど、検索が複雑だとちょっと無理（提供されてるものだけー
なぜCloudSearchを選んだの？
- コスト
EC2 + Solrよりコストが低い
- スケールアウト・インが自動
- せっかくなので新しいものに！
どうやって実現した？
- 記号での検索ができない！
CloudSearchは記号を含む検索ができない！ 記号は区切り文字として取り扱われて削除されるため、単語登録した時に記号だけ落ちる ベッキー♪# -> ベッキー
全てのひらがな、カタカナを全角カタカナに寄せる ひらがなが余るので、記号をひらがなで表現する
ベッキー♪# -> ベッキーあい
ベッキー♪# -> ベッキーあい
文字種の違いでもインデックスが別れる EうGirls(E-Girls)) → E う Girlsってなる 文字種が変わってしまったから
英字の大文字も使ってなかったので、うー＞U く→Kのように2つのマッピングを作った
E-Girls -> EうGirls -> EUGirls
E-Girls -> EうGirls -> EUGirls
まとめ
比較的簡単な検索ならおすすめ
0コメント