No content

アジェンダ - ⾃⼰紹介 - Eightの簡単な紹介 - Meetsでのイベント運営への取り組み - 運⽤パート：急激な時代の変化に合わせて⾏った柔軟なチーム体制 - 技術パート：インタラクティブなコンテンツの仕組みとその実装について

2 ⿑藤 実 (Minoru Saito) Sansan株式会社 Eight事業部@名古屋⽀店 WEBエンジニア Sier・ベンチャー企業を経て、2020年にSansan株式会社へ⼊社、 名古屋⽀店に配属。 Eight事業部で主にビジネスイベント「Meets」や、Eightの広告事 業に関する開発・運⽤に携わる。 最近では、参加型オンラインイベント 「Meets Online Live」の⽴ ち上げに関わり、技術調査、インフラ構築からフロントエンド開発 までを担当。 新しいサービスを考えることが⼤好き。

Eight 3

名刺でつながる、ビジネスのためのSNS

オンラインでも専⽤のバーチャル背景で繋がりを

イベント事業への展開 Meets Eight ONAIR Climbers

Meetsにおけるイベント運営の取り組み

運⽤パート：急激な時代の変化に合わせて⾏った柔軟なチーム体制

Meetsは元々オフラインによるビジネスマッチングイベントとして運営

急速なオンラインシフト

11 めまぐるしく開発が進む中での課題感 💦 開発途中で仕様が変わったり、中⽌になることもしばしば。 💦 💦 PMとの仕様の合意 他チームとの連携 技術的課題の改善 プロジェクトの スケジューリング プロジェクト単位での 振り返りの実施 FWのバージョンアップの スケジューリング チームのプロセスの改善

12 プロジェクトの進捗、技術的改善、チームビルディングに 同じレベルで全員がアテンション張るのは厳しい。 さらに今はフルリモートという状況で共有もしにくい。 どうしたものか。。。

13 スイッチスリーリード制 の導⼊

- プロダクトリード、アーキテクトリード、チームリードの役割を各メンバー にアサイン。⼀ヶ⽉ごとにその役割を交代する。 - プロダクトリード： 健全なスプリント計画をリードする - アーキテクトリード： 健全な開発をリードする - チームリード： チームビルディング をリードする スイッチスリーリード制 14 アーキテクト リード プロダクト リード チーム リード 1ヶ⽉で役割交代

15 結果どうなった？

16 アテンションを張るべきポイントが絞られることで、 集中して改善に動けるようになった! FWのバージョンアップは アーキテクトリードが管理 PMとのやりとりのIFは 常にプロダクトリード プロジェクト終了時の振り返りは チームリードがセッティング

17 リードをローテーションすることで多視点からの改善が進んだ！ Aさんはこういうアプローチを取り⼊れてい たけど⾃分はこうしてみよう プロダクトリードをやっていたときはこのあたりに課題があったか らアーキテクトリードではこういうサポートする動きをしてみよう プロダクトリードは負荷が⾼いので 他リードでフォローしてもらおう

18 それぞれが各リードを経験することで相互理解が深まり、 認識齟齬が減った! この課題はいつまでに何をゴールに してやればいいんだな この機能の実装は このやり⽅で作ればいいんだな この技術的負債はこんな影響が あるから、優先しなくてはいけないんだな

19 • やる事が絞られるため動きやすい • 役割を交代することで相互理解が高まり、フォローがしやすくなる • 違う視点からも改善を図ることができる • 役割を与えられることで、リモートでのモチベーションの維持につながる まとめ

20 技術パート：インタラクティブなコンテンツの仕組みとその実装について

MISSION: Meets Online Liveを実装せよ！

セールスピッチ配信 デモ選択画⾯ デモ配信 アンケート表⽰ A B C D デモ1 デモ1 デモ2 デモ4 デモ1を選択 デモ1を選択 デモ2を選択 デモ4を選択 運営 運営 オンラインイベントの流れ 運営

リアクション機能 拍⼿をクリック 他のユーザの画⾯に 即時に表⽰される

技術選定 特にインタラクティブなインターフェース部分の実装⽅法 - ポーリング or WebSocket - 工数削減のためインフラの作業はなるべく減らしたい - インタラクティブな機能で必要となる情報は、ユーザIDとリアクション情 報のみ

API Gateway(WebSocket版)を使おう

構成 追加

WebSocket接続確⽴までの流れ

リアクション時の流れ

運営サイドからユーザ宛への通知の流れ

いざ本番

実績 - 同時最⼤接続数：180 - リアクション数：1,000/H - Push通知に要した最⼤の時間：7s - 負荷テストでの計測値どおり - 料⾦： - API Gateway ≒ $0.1〜0.2, Lambda ≒ $0.01, DynamoDB ≒ $0.02 - ∴1開催あたり、50円もかかっていない - ⼩規模なら、API Gatewayを使った実装で問題ない

今後の課題 - 接続をより確実に - 配信に時間がかかっているため、並列化等をして⾼速化できないか - より⼤⼈数での配信を可能にする - APIを複数⽤意して、ALBでのバランシング

TIPS - SAMのWebSocket対応はまだ未定 - https://github.com/aws/aws-sam-cli/issues/896 - API Gateway WebSocket クォータは事前に確認しておく - Lambda Authorizer関連 - 呼び出しは接続時のみなので返すポリシーに注意 - contextオプション便利 - コンソールでの接続確認はwscat, awscurlが便利

負荷テスト - 使⽤ツール > artillery（ https://artillery.io/ ） > 簡単な設定を書くイメージでテストが書ける

AWSの技術サポートを最⼤限活⽤しよう - サービス規模等を伝えることで懸念点をフィードバックしてもらえる - 実装⽅法や参考事例を紹介してもらえることも - 以前もGlueで⼤変お世話になりました

参考⽂献 - https://aws.amazon.com/jp/serverless/sam/ - https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/limits.htm l#apigateway-execution-service-websocket-limits-table - https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/api- gateway-lambda-authorizer-output.html - https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigatew ay-how-to-call-websocket-api-wscat.html - https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigatew ay-how-to-call-websocket-api-connections.html - https://artillery.io/

No content

No content

No content