X-Tech JAWS 【第8回】～時代を突き抜けるX-Tech企業の真髄～を聞いてきた。
本日のイベント参加レポート。
X-Tech JAWS 【第8回】～時代を突き抜けるX-Tech企業の真髄～
https://xtechjaws.doorkeeper.jp/events/93165
LT 『オンデマンドインスタンスを極限まで減らしたらこうなった』
田中 一樹
登壇資料
https://www.slideshare.net/NavitimeJapan/ss-154830746
AWS利用が増えるにつれ費用が増加
バックエンド構成：アプリサーバ→APIサーバ→データ、地図など
サーバ系はECSで運用＝EC2費用が増加
- よくある話
ECSからFargate使ってみたら楽になった
- ところが、ナビタイムジャパンでは使えない
ストレージが10Gまで→地図・経路等のデータでそれぞれ数十G必要
ECSのときと必要な台数が変わらない
障害時の調査においてクラウドネイティブになっていない、運用工数増えそう
→EC2の費用を下げるしかない。
RI Utilization 90%~
RI Coverage:80%~
- SpotFleetで管理
管理が面倒、うまくスケーリングしないこともあった
- EC2フリートの採用
AutoScalingGroupでオンデマンドもスポットも起動
オンデマンドの台数、割合を指定できる
インスタンスタイプも複数指定可能
- オンデマンドをゼロにできないか？
CPUベースでスケールアウトするので、同じコア数のインスタンスを並べる
先頭はRI購入したインスタンスタイプ（先頭から起動する
オンデマンドベース＝RI購入台数
オンデマンド割合０％、RI購入分以外すべてスポット
→現在、オンデマンドインスタンス0台達成！
→従来に比べてオンデマンドインスタンスを激減させることができた！
- 極力先頭のインスタンスタイプで起動しようとする
起動できないと後続のインスタンスタイプ使う
RI購入していないインスタンスタイプでオンデマンド起動する可能性ある
- まとめ
EC2フリートを使うと簡単にオンデマンドインスタンスを減らすことができる
予想外のオンデマンドインスタンス起動に注意！
ECSのDraining処理は入れておく
※スポットインスタンスはよく落ちる
『コミュニケーション最適化プラットフォーム「SYNALIO」を支えるAWS』
1: 株式会社ギブリー 取締役、株式会社Resola 代表取締役社長
奥田 栄司
- 株式会社Resolaについて
小さなエンジニアたちの会社
在籍者の半分が外国人
- SUNALIOについて
マーケティング向けのチャットボットツール
インターネットでの「企業～消費者間」情報伝達方法をアップデートしたい
ビジョン：新しい感動体験を創る
ツール自体はBtoB
消費者の感動体験を作る、企業が儲かる、自分たちも潤う
- ツールについて
従来のデジタルマーケティングで行われる顧客理解方法
サイト訪問者の行動解析を行うことで「興味のある分野」「検討フェーズ」を分析
- 問題点：
行動しないユーザはターゲティングできない
非観測要因が見えないため、ユーザが意思決定しにくい
- 解決方法：
行動データに対して「会話データ」を加える
サイト訪問者全ての行動/会話データを取得、分析、活用する
会話データ：サイト内でチャットボットと会話した内容
→グループに応じて配信内容を変更することで最適な接客に。
→行動データに合わせて会話を展開することで、最適なコンテンツを提示する
- アーキテクチャについて
行動データ/会話データの利用周りに着目して説明
- データの使い道
ダッシュボードおよび各種レポート
ポップアップおよびチャットウインドウの出しわけ
- 行動データの種類
ページビュー
どのチャネルから訪問したか
どのページに何分滞在したか
何度目の訪問か
デバイス・OS・ブラウザの種類
→基本的にはGAのデータに近づけるようにしている
※顧客がGA使う傾向が多いため
イベントデータ
チャットボットを表示した
チャットボットを使った/意図的に閉じた
ポップアップを表示した
- 会話データの種類
会話内容
ユーザが押したチャットボット内のボタン
ユーザが入力した文字列
特定の会話へ到達した時に付与するラベル
予算○○円以上
決裁権あり
- アーキテクチャについて
データが多いためS3に保持
分析したデータはRDSへ保持
SageMakerで学習させ、学習済みモデルをS3へ
EC2からS3に保存されたデータを読み出す
機械学習の前処理：学習処理～学習済みモデルの使用
- 目指したいところ
自動運転レベル3
特定の場所でシステムが全てを操作、緊急時はドライバーが操作
- 現状行うこと
ラベルの自動付与
クロスカンパニーデータの利用
システムによる自動改善
『1万枚の写真の中から我が子を見つける顔検索の裏側』
2: 千株式会社
吉田 健太
登壇資料
- はいチーズ！の紹介
撮影・印刷・掲示・代金回収の手間から解放される
写真購入がいつでも・どこでも・手軽に
全国の幼稚園・保育園中心に6000団体以上が利用
- 「園児一人一人が主人公の写真」を撮る
園の規模にもよるが、1万枚以上の写真からわが子の写真を探すのは大変。
共働き世帯も多い。
→顔検索ができないか？
- Amazon Rekognitionによる顔検索機能の実現
学習済みのAIをサービスとして利用可能
できること（一例）
画像の物体、シーン、顔の検出
表情の分析
顔と顔が似ているかどうかの判定 →これで顔検索できるのでは？
いいところ
安い：初期費用が不要、従量課金（使った分だけ払う）
速い：処理速度が高速
高精度：試作品を開発・検証したところ、十分な精度
→導入を決定してから1ヵ月程度でリリース！
- 実現できた購入フロー
わが子の写真をアップロードすると、即座に対象が映っている写真を返す
注文履歴から、おすすめ写真としてユーザに表示
（事前にバッチ処理で子どもの顔を分析している）
- デモ
※撮影不可。実際のサービスでの顔検索を実演。
→顔検索の導入によりコンバージョン率向上！
- テクニカル編
アクセス毎にイベント全ての写真と比較するのはレスポンスに影響がある
複数枚のアップロードが行われたときの計算量は？
- 「コレクション内での顔の検索」
特徴ベクトルをあらかじめIndexできる
- 顔検索に必要なAPIは3つ
CreateCollection 顔コレクションを作成
IndexFaces 顔メタデータを追加
SearchFacesByImage
- まとめ
簡単に顔検索機能できる
システム構築不能、サーバレスなので保守コスト不要
安い・速い・高精度！
『GovTech を加速させる AWS』
3: 株式会社 one visa
馬場 敏気
登壇資料
https://speakerdeck.com/tobb422/govtech-wojia-su-saseru-aws-c32f214c-22b1-4325-9ea1-d513f19a900a
- GovTechとは
Government × Technology
- 株式会社 one visaについて
ビジョン：世界から国境をなくす
物理的・心理的なハードルをなくす
- one visa
ビザ取得が簡単に行えるSaaS
書類作成→添付書類の選定→理由書の作成→書類の提出
これを
自動生成→自動判別→自動生成→申請取次
※実際は質問に答えるかたちで自動生成。フォームを埋めていく。
- プロダクトの展望
日本語の無償教育
仕事の紹介
→ビザ情報を軸に不動産、保険、勤務先、銀行口座などと連携しあらゆるサービス提供を目指す
- プラットフォーム化への取り組み
あらゆる手続きをイージーモードに変換することが必要
＝技術的要因で妨げてはいけない！
パスポート登録
画像解析、日本語化
役所届出
必要な情報の外部API連携
クレカ発行
与信発行
→拡張性のあるアーキテクチャが必要
- HerokuからAWSへの移行を決めた
選択肢が多そう
大きなプラットフォーム
フロント：ALB+EC2
バックエンド：コンテナ化
- サービスのマイクロ化
GO言語で分散処理
Rubyは管理処理
デプロイの簡易化
サーバ構築をテンプレート化
CloudFormation
- インフラまわり
Fargate
Aurora
→エンジニア一人雇うより安くすむ
技術的な選択肢を増やすことに成功！！
『帳票も今や HTML でつくる時代！？日本の税理士を支えるサーバーレス帳票基盤』
4: アカウンティング・サース・ジャパン株式会社
土田 拓也
- 帳票の語源
帳票＝帳簿＋伝票
事業内容 税理士・会計事務所の普段の業務を支える
税理士の仕事とは
税務顧問
財務顧問
経営顧問
- 会計情報をもとに顧客（社長）との打ち合わせ
紙で持っていくことが多い
中小企業だとWiFiがないことが多い
データで渡しても見てくれない
紙の方が見やすい
＝紙による顧客体験
→可読性の高い帳票
Javaによる開発
帳票：L字型の枠にタテ・ヨコ文字を入れるとき
→HTML,CSSなら簡単に実現できるのではないか
- ブラウザで頑張る！シングルページアプリケーション
Headless Chrome
レンダリングしたものをPDF化すればいい？
node.js×Puppeteer×Chrome
で開発したが変換遅い
- Lambdaでサーバレスにしよう！
@severless Lambda
50MB制限はギリギリクリア
ところが、日本語でない
Noto Sans CJK + Chrome
50MB超えるのでLambdaに乗らない
- S3からデプロイすれば展開時250MBまでOK
サーバレス帳票基盤完成！
柔軟なHTML帳票作成
『タイムバンクでのアクセススパイク対応の話 ALBからNLBの移行』
5: 株式会社タイムバンク
田中 ゆういち
- タイムバンクとは？
スマホ向けアプリ
ユーザ：ひまなスキマ時間⇔お店・ホテル：客のいない時間アイドルタイム
のマッチング
- タイムバンクの構成（一部）
NLB⇔EC2+ElastiCashe+Aurora
オーソドックスな構成
- パフォーマンス周りの話の背景
最近、アプリが重い/読み込みが遅いなどパフォーマンス問題が発生
- タイムバンクセールのハナシ
タイムバンクが売ってるMax99%OFFの商品
毎日2～4回の頻度で発生
ゲリラ的発生パターン/時間帯告知パターン
数量限定の先着制
家電・ゲームなど少量のものも
- タイムバンクのスパイク
時間帯告知パターンのタイムセールの場合
アプリのリロードが大量発生（参照負荷）
一斉に購入（更新負荷）
→RDSへの負荷増大
- キャッシュ層での対応
ユーザ単位のキャッシュ
モデルキャッシュ
商品情報単位のキャッシュ
モデルキャッシュ
商品一覧などのキャッシュ
ページキャッシュとフラグメントキャッシュ
→DBへの負荷低減
しかし商品数・ユーザ数の増加・商品のバリエーション追加により
キャッシュ落ちる、DB負荷増大、アクセス詰まる
過去に障害発生事例あり
- Scale-out/Scale-in
アクセス増に応じてインスタンス数を増減
しかしインスタンスの起動が間に合わない
- スポットインスタンス
平常時のサイズを通常のインスタンスN台
ピーク時のアクセス部分をスポットインスタンスM台
合計N+M台を常時
コスト圧縮できたが
セール時にスポット部分が刈り取られる時間が発生
→スポットインスタンス使用は諦め。
- ALBからNLBへ
人気のセール時に繋がりにくい事象あり
→暖気申請対応
- Pre-warm申請は面倒
開始時刻、終了時刻を申請時に記載しなければならない
- 負荷によるwarm-up
申請を諦めてabコマンドで擬似的にアクセスを増加（！）
Jenkinsとbotで自動化
→自動で意図通りに動かないときがあった、手動で賄う、運用やめたい
- NLBへの移行
一部アプリからのGETrequestが返ってこない事象が発生
アプリ側でコードを変更した
- パフォーマンスどうなっているか
またパフォーマンス悪化してきている
スケールしづらいWriteがつまる問題、今後の課題
