Backlogのカンバンボードの技術 / Architecture of Backlog Kanban Board

2020年12月5日(土)に開催されたNuConの登壇資料です。

▼NuCon2020 公式サイト
https://nucon.nulab.com/2020/

▼発表アーカイブ
https://www.youtube.com/watch?v=KXogZS5awbc&t=679s

Transcript

1. NuCon 2020 Backlogカンバンボードの技術 カンバンボードの技術
2. 自己紹介 自己紹介 藤田正訓（ふじた　まさのり） ヌーラボ入社6年目 Backlog開発チーム kanbanプロジェクト　リーダー Scalaとか書けます 福岡市に住んでます
3. ・メインはタスク管理 タスク管理 ・プロジェクト管理に必要、便利な機能いろいろ ・IT強くない人にも優しいUIやコンテンツ 「チームではたらく、すべての人に」 「チームではたらく、すべての人に」 2004年ローンチ… 16年！ 小さい開発チームが たくさんあります
4. 久々の新機能「カンバンボード」 久々の新機能「カンバンボード」 ガントチャート以来11年 ぶり新メニュー ※Wikipedia調べ 開発コードネーム 「kanban」 この間プルリクエスト機能とかデ ザインリニューアルとか、大きな 変更も沢山してます！ コラボレイティブな「カンバン」 　SPA的な素早い動作 　他のユーザーにもリアルタイムで変更が伝わる（WebSocket）
5. Backlogの技術スタック の技術スタック フロントエンド バックエンド ミドルウェア・インフラ Amazon EC2 Amazon Aurora Java+Seasar2から移行 RDSから移行 Luceneから移行 カーネルアップデート 2016年のデザイン変更では 変更しなかった 実はチョット HTML返す & REST API 少しだけ残ってる （主要なもののみ抜粋）
6. Backlogの技術スタック の技術スタック フロントエンド バックエンド ミドルウェア・インフラ Amazon EC2 Amazon Aurora モノリシック モノリシック 単一レポジトリ 単一実行イメージ 多機能のためかなり巨大
7. kanban、どう作るか 、どう作るか 既存スタックの延長線 普通 ・モノリス巨大化 ・古い技術のJSコード ・運用コスト微増 ・キャッチアップの手間無し 別レポジトリ、別サービス 挑戦 ・最近の技術でフロント開発 ・将来のマイクロサービス化への布石 ・システム構築＋運用コスト大 ・キャッチアップ大変
8. 考えた結果 考えた結果 「挑戦」コースを選択 「挑戦」コースを選択 やりきれる「強い」チーム内外メンバーの存在 社内事情もちょっと コスト増については「ごめんなさい」 ・最近の技術でフロント開発 ・将来のマイクロサービス化への布石
9. kanbanの技術スタック の技術スタック フロントエンド バックエンド ミドルウェア・インフラ Amazon Aurora emotion Amazon EKS HTTP Backlog初 今どきの構成 本体ロジックをライブラリ として使える設計 DBは共有 （主要なもののみ抜粋） Backlog初 Backlog初 Backlog初 Backlog初
10. kanbanの技術スタック の技術スタック フロントエンド バックエンド ミドルウェア・インフラ Amazon Aurora emotion Amazon EKS HTTP （主要なもののみ抜粋） Backlog初 Backlog初
11. { hero { name } } { "data": { "hero": { "name": "R2-D2" } } } レスポンス クエリ { hero { name friends { name } } } { "data": { "hero": { "name": "R2-D2", "friends": [ { "name": "Luke Skywalker" }, { "name": "Han Solo" } ] } } } クエリ レスポンス Scalaの実装がイケてる（n+1問題回避） フロントエンド開発者が レスポンスの型を調整できる ＝圧倒的自由 Jalalさん スーパーScala人 Strasbourg（サセボ）出身
12. 複数Dockerコンテナの ローリングデプロイ 死活監視 ネットワーク構成管理 ロードバランシング オートスケーリング セキュア設定値 Fabric Amazon EC2 秘伝のタレと人力 Amazon EKS やってたことの大部分を 高クオリティで置き換え ・簡単ではないが構築できればクオリティ劇的向上 ・Backlogでは専門チームで継続的改善 マネージド 運用つらみを大幅軽減 吉岩さん EKS関係全部やった人 愛犬：ころも
13. 既存インフラの横に 既存インフラの横にEKS Amazon Aurora kanban 通知サービス 通知サービス Amazon EKS パスで分岐 kanbanだけ独立 極力本体に手を付けない 本体 本体 開発期間中、本体の開発や運用に影響を与えず頻繁にリリース 納得行くまで負荷試験等をできた
14. 既存 既存UIの上に の上にReact kanbanフロントエンド (React) 本体 (HTML + jQuery) ローカルで重い本体を起動せず開発できた ティーザーサイトで「カンバンボードお試し体験」を提供できた
15. 数え切れないほどの 数え切れないほどの 課題、問題を乗り越えた 課題、問題を乗り越えた
16. コンテナで コンテナでJVMを動かすのに を動かすのに 最適なスペック？ 最適なスペック？
17. JVM on K8S kanban 通知サービス 通知サービス Amazon EKS JVMアプリケーション アプリケーション ・起動、Hotspotの暖機運転に数十秒 ・起動オプションのベストプラクティスは無さそう 　　-XX:+UseContainerSupport は必須 コンテナのリソース設定 ・CPU ・メモリ 負荷試験して決めよう それほど心配ない
18. ・ ・ストーリー言語がScala ・ ・負荷かけ方のパターンが多彩 ・レポート ・レポートHTMLが綺麗で見やすい が綺麗で見やすい
19. 1回目試行 コンテナ構成、JVM起動パラメータ等変更しながら 何度も何度も何度も試行 少しずつ成功レスポンスを返し始めて いるが半分くらいエラー パラメータを決定するまで パラメータを決定するまで Backlog課題リクエストの 頻度、傾向を調査 過剰気味の目標負荷 （約100参照/sec・約1更新/sec） Gatlingストーリー実装 負荷かけ始めてすぐ落ちてしまう エラーレスポンスが時々返るだけ 吉岩さん EKS関係全部やった人 愛犬：ころも
20. ついに ついに 10日目のある瞬間 さらに見直し続け… ついに全リクエストが成功！ レスポンス時間も2sec以内 pod数は最大12まで増えてる JVMオプション オプション -XX:+UseContainerSupport -XX:MaxRAMPercentage=35.0 -XX:+UseSerialGC -XX:GCTimeRatio=19 その時点での その時点での 最適構成！ 最適構成！ 負荷をより厳しくしても安定 レスポンス時間0.8sec以内 pod数6のままスケールせず捌き切る リソース設定 リソース設定 CPU: 500m (Burstable) Memory: 768 Mi (Guaranteed) 現在は運用しながら徐々にスペック落としてコスト減
21. プッシュ通知の問題 プッシュ通知の問題
22. プッシュ通知 プッシュ通知 他の人が更新すると kanbanにリアルタイム反映 ❤ WebSocket でサーバー→クライアントにプッシュ通知する必要
24. プッシュ通知 プッシュ通知 通知サービス 通知サービス 本体 本体 Amazon Elasticache Redis Amazon Elastic Load Balancing PUBLISH 更 新 P U S H SUBSCRIBE WebSocket 歴史的事情で 8環境中1環境だけALBでなく Classic Load Balancer (WebSocket通らない) どうにかしなきゃ！
25. 困ってたら 困ってたら Goの のsocket.ioライブラリ良いのがなかった ライブラリ良いのがなかった ので のでNode.JSで作ってみますね。 で作ってみますね。 しかも次の日にはだいたい出来てた socket.ioならWebSocketダメな時ロングポーリ ングに切り替わるからいけそう なるほど。Goでsocket.io使う方法あるのかな。 神！！？ 渡邊さん 他チーム。別件の作業を手 伝ってもらってた
26. プッシュ通知 プッシュ通知 通知サービス 通知サービス 本体 本体 Amazon Elasticache Redis Amazon Elastic Load Balancing PUBLISH 更 新 P U S H SUBSCRIBE WebSocket ここが
27. プッシュ通知 プッシュ通知 通知サービス 通知サービス 本体 本体 Amazon Elasticache Redis Amazon Elastic Load Balancing PUBLISH 更 新 P U S H SUBSCRIBE WebSocket 通知サービス 通知サービス こうなった EKS上に構築していたモニタリングの仕組みを流用 → 負荷も問題なし Classic Load Balancerでも問 題なく動作
28. UIのちょっとした工夫 のちょっとした工夫
29. 本体 本体HTML→メイン部分 メイン部分React React描画 GraphQL通信 フロントエンドJS ロード kanbanフロントエンド (React) 本体 (HTML + jQuery) 本体HTMLロード
30. 本体 本体HTML→メイン部分 メイン部分React React描画 GraphQL通信 フロントエンドJS ロード 本体HTMLロード この状態で1～2秒待たされるとストレス
31. 本体 本体HTML→メイン部分 メイン部分React React描画 GraphQL通信 フロントエンドJS ロード 本体HTMLロード 最初のHTMLがこうなってると安心して待てる 福田さん デザインもできてReactコードも 書ける（ようになった）
32. 本体 本体HTML→メイン部分 メイン部分React React描画 GraphQL通信 フロントエンドJS ロード 本体HTMLロード 待ち時間用のHTMLをReact描画部で置き換える
33. kanbanチームの挑戦のほんの一部をご チームの挑戦のほんの一部をご 紹介しました。 紹介しました。 ご清聴ありがとうございました 上から下までとても多くの挑戦ができ、頼りになる 仲間たちにサポートされて楽しく開発できました。