wwwave'sTechblog |ウェイブのエンジニアブログ

株式会社ウェイブのエンジニアによるテックブログです。会社の話や Ruby、Vue.jsについてなど技術的な話をしていきたいと思います。

株式会社ウェイブの人事部ブログです。社内の雰囲気やイベント、福利厚生などについてお伝えいたします!

株式会社ウェイブのエンジニアブログです。 エンジニアの目線から会社の話や技術的な話をしていきます。

ウェイブハッカソン 当日レポート

2021年12月22日(水)ウェイブ初のハッカソンが開催されました。

このイベントはエンジニア同士の交流と相互理解を深めることを目的に開催されたもので、普段は違うサービスを担当しているエンジニア同士が複数の班に分かれ、社内ツールを制作しました。技術の指定なし、実用性のあるものに限らずなんでもOKのハッカソン。和やかな雰囲気の元、相互に意見を出し合いながら社内ツールを生み出しました。

プロローグ

 少し早めに会場へ到着。会場となる池袋のレンタルスペースは思ったよりもフランクでした。木製のテーブルと調理ができそうなキッチン、隅にはダーツ台が設置されています。いち早く到着したメンバーが会場を見てびっくり。雑居ビルの屋上スペースでハッカソンがいよいよ始まります!

f:id:sys_wwwave:20220202115815j:plain

まずはじめにハッカソンを主催する内山マネージャーより、簡単に趣旨の説明がありました。今回が初めてとなるハッカソン。うやうやしくスタートすると思いきや、会場同様フランクにはじまりました。各班思い思いの課題をエンジニアリングの力で解決すべく実作業に入ります。

新卒ならではの課題を解決

f:id:sys_wwwave:20220202115846j:plain

一口に開発スタートといってもいろいろな方法があるらしいというのは、エンジニアではない筆者が思ったこと。社員のスケジュールが確認できるbot開発を目指すチーム名「ポテトどーなつ寿司」は、仕様確認の打ち合わせからスタートしました。業務でComicFestaを引っ張る内田マネージャーと新卒入社のお二人、今回唯一の参加となった女性エンジニアのベテランとルーキーが混合したチームです。

「チャットで名前を送るとその人のスケジュールがわかるbotの開発を目指しています!企業の規模が大きくなって人も多くなったので、電話をとった時にその人が何をやってるかすぐにわかるようになれば便利だと思うんです。」

そう教えてくれたのは、新卒社員として2019年に入社した石川。電話をとった時にスケジュールを知りたいというニーズに気づけたのは、新卒社員ならでは。電話をとる機会も多い筆者としては一刻も早く導入してほしい社内ツールです。

新入社員でも制度を利用しやすく

f:id:sys_wwwave:20220202115859j:plain

一方、ウェイブの部活制度を円滑に運用するWebサービスの開発を目指すチーム名「ぷくぷく新ぷく」は、ホワイトボードを積極的に活用して構成から検討を始めた様子。ウェイブの部活制度は活動時に募集をかける設計となっていますが、日々、業務を行う中、部活動に関わる諸手続きを行うのは一苦労。技術の力で簡略化できたらという想いがあるようです。

「部活動をスムーズに行うためのサービスを開発しています。募集や告知、新規の部活申請といった部活動制度に関わるすべてを包括的に網羅するサービスですね。現在は、部活に関わるすべての手続きの頭出しを行っています。」

そう教えてくれたのは、普段はSREとして業務を行っている白戸。自身も昨年バドミントン部を立ち上げ運営しています。

「ウェイブは新しく入ってくださる社員も多いですが、部活に参加してくださる方が少ないように思うんです。情報を集約することで部活を活性化していきたいです。」

運営する側として課題把握が完璧な様子。ちなみにこのチームには、主催の内山マネージャーも所属。内山は、麻雀部、競馬部を運営しており、普段から部活制度に積極的なメンバーが集まりました。

筆者も2つほど部活を主催しているので、せひ開発してほしいと思っています!

社内募集で迷わないツールを作る

f:id:sys_wwwave:20220202115910j:plain

「集まれシステム」と名付けた社内で気軽に人を集められるサービスの開発を目指すチーム名「秋山さんは旅行も好き」は一つのパソコンを見ながら案を出し合っています。社内のコミュニケーション活動が盛んなウェイブでは、公式非公式を問わず人を集めることがあります。

「社内で、人を集めたいときに何のツールをどう使うのが効果的か迷うことがあります。このサービスでそういった課題を解決したいです。」

そう教えてくれたのは、Coolmicのエンジニアとして活躍する岡本。

「募集が一覧になっていて、参加がボタンでできて、規定の人数や期限で実施可否も検討できる。そんなサービスにしたいと思っています。今は実施を決めてからお声がけという流れですが、実施可否を検討できることで運営側の負担が減ると思うんです。」

仕様通り作るのではなく、いかにユーザーファーストの機能にするか。常にCoolmicで行っている思考ですね。ちなみに岡本は「直近のイベントで人が集まって無くて困ってます。」とのことでした。これも見ている社員の方、ぜひ参加を!

電子コミック扱う当社だからこそ

f:id:sys_wwwave:20220202115918j:plain

業務で多くの画像を使うウェイブならではのツール作成を目指すのは、チーム名「Team. DAI 自然」。指定の画像が膨大なフォルダのどこにあるのかすぐに検索可能なツール開発を目指して作業をしています。このチームは、各々が過去に開発したことのあるシステムを利用してツールを作ることにチャレンジ。大枠の議論を数分で終えたのち作業に入っていきました。

「古くからいる方はどこに画像があるかすぐわかるんですけど、新しく来た人はわからない。IDだったりタイトル名といった命名規則が部署によって違うので。このツールができると『ほしい画像はわかるけど、どこにあるの』ってところを解消できると思います。」

そう語るのは、社内ツールの開発を担う社内開発グループの奥山マネージャー。普段から画像の取り扱いが多い編集チームとお仕事しています。

うーん。画像の命名ルールって迷いますよね。これが開発されたら他部署の命名規則とかもなんとなくわかりそう。他部署のことを参考にできる面でもいいかもしれないですね!

エピローグ

f:id:sys_wwwave:20220202115926j:plain

真剣ながらも笑い声も聞こえ、和やかな雰囲気で進む、ウェイブ初のハッカソン。 どのチームも社内課題を捉えていて「あるある、その悩み」と思いました。

普段関わりがなかなか持てないエンジニア同士、技術を提供しあいながら課題克服を目指す姿は、個人的にもたくさんの刺激をもらえました。課題を持てる技術で解決する。チームで解決する。初のハッカソンは、当たり前のことながらそれを手応えとして感じられるイベントになったのではないでしょうか。筆者も明日から頑張ろう…。以上ハッカソンレポートでした。

  

 

Amazon CloudWatch RUM と Grafana で Web Vitals の監視

f:id:sys_wwwave:20211213155908p:plain

ウェイブSREの白戸です!

今回は、AWS re:Invent 2021(11月29日)にて発表された Amazon CloudWatch RUM を Coolmic に導入、及び Grafana での監視を行いましたので、ご紹介いたします!

↓ Amazon CloudWatch RUM の存在を知った時の白戸。

f:id:sys_wwwave:20211213153558p:plain

はじめに

本記事では、CloudWatch RUM の導入前に知りたかった情報を主に記載しております。
▫ CloudWatch RUM の料金は、10万イベントごとに1USDだが、1度のサイトアクセスで何イベント発行される?
▫ CloudWatch Logs に収集されるデータサイズは何GBになる?
▫ etc

また、『ウェイブSREが普段どんな実務をしているのか?』を読者の方に少しでもお伝えできればと思います😚

目標

以下の2つが目標ですが、まずは①を達成するべく、RUM を導入しました。
①フロントエンドパフォーマンス悪化自動検知
②フロントエンドパフォーマンスが売上へ与える影響の可視化

アーキテクチャ

CloudWatch RUM 用のスクリプトはGTMから配信しました。

f:id:sys_wwwave:20211213152438p:plain

CloudWatch RUM 設定

コスト削減のため、以下の設定を行いました。
▫ 測定対象を、Performance telemetry のみ有効
▫ 測定対象ページを、主要ページのみ有効
▫ 集計サンプル数を、1 / 100 にして間引き対応

上記すべて、CloudWatch RUM で設定できます。
ただ、/titles/[:id] みたいな Path を正規表現で設定する方法がわからなかったので、GTMで対応しました。

CloudWatch RUM イベント数

Google Chrome の DevTools で確認可能でした。
(以下、1回のアクセスで11イベント発行された例)

f:id:sys_wwwave:20211213113915p:plain

実際に発行されるイベント数は、導入してみないとわからないので、集計サンプル数を間引きして初期導入することをオススメします。

CloudWatch Log データサイズ

あくまで目安ですが、50万イベントで、60MBくらいでした。
サイズが小さかったので、長期保存もできそうです🙌

CloudWatch Log データ構造

event_type ごとに関連情報が含まれております。
例えば、LCPの場合、event_type が com.amazon.rum.largest_contentful_paint_event となっており、event_details.value に実際の数値(ms)が含まれていました。
以下、ログの詳細です(一部省略)

{
    "event_type": "com.amazon.rum.largest_contentful_paint_event",
    "metadata": {
        "browserName": "Chrome",
        "browserVersion": "96.0.4664.92",
        "osName": "Android",
        "osVersion": "11",
        "deviceType": "mobile",
        "domain": "coolmic.me",
        "pageId": "/episodes/1111",
    },
    "event_details": {
        "version": "1.0.0",
        "value": 1010.299
    }
}

Grafana ダッシュボード

主要ページごとにWeb Vitals(LCP, FID, CLS)を可視化しました。
かなり改善し甲斐のある数値でした😇

f:id:sys_wwwave:20211213120048p:plain

Grafana アラート

LCPのアラートを例にすると、『LCPの75パーセンタイルが、5秒以上を5分間継続した場合、アラート発行』にしました。
現状のパフォーマンスが良いとは言い切れない事実を受け入れつつ、悪化を防ぐための設定です。
最終的には、『LCPの75パーセンタイルが、2.5秒以上を5分間継続した場合、アラート発行』にできれば理想です💪

75パーセンタイルにした理由としては、Googleの指標と合わせました。
Googleが閾値を75パーセンタイルにした背景などは、公式記事をご参照下さい。

まとめ

今回の対応によりフロントエンドのパフォーマンス悪化を防ぐことはできそうです。
展望として、フロントエンドパフォーマンスが売上へ与える影響の可視化も行うことで、パフォーマンスに対する意識をチーム全体で底上げできればと思います!

トップに戻る