大規模な美容メディアの フロントエンドを支えるサーバー技術 2024/03/26 フロントアーキテクチャ改善 NIGHT with Takepepeさん muratak@SWE Youtube版: https://www.youtube.com/watch?v=z8eI0bgzPTM&t=285s

大規模な美容メディアのフロントエン ドを支えるサーバー技術 ~ 大規模なシステム刷新プロジェクト「 Reborn」を通じての学び ~ 2024/ 3/26 フロントエンドアーキテクチャ改善Night 株式会社アイスタイル ソフトウェアエンジニア muratak

istyle/@cosmeについて ・主にビューティ領域 において メディア、ECサイト、 店舗(国内外で35店舗) etc などさまざまなサービスを展開 ・今年で創設25周年を迎えた

今日のLTで皆さんにお伝えしたいこと ・大規模なメディアの負荷を支える技術 はどうなっているのか？ 月3億PV/MAU1900万/ 10000↑rps(一部API ・フロントエンドの開発とリアーキを支える堅牢なサーバーサイド基盤 →これらをお伝えするために、 サーバーサイド からインフラ、フロント改善の工夫 まで15分でお伝えする

自己紹介 by muratak ・@cosmeを運営するistyle社で働くSWE/ DevRel 現在はRebornというシステム刷新の複数プロジェクトリード DevRelとしては今回のイベントの運営やサムネ作成担当だったり(次は4/18開催) ・技術領域としてはTypeScriptと Go, AWSあたりが多め ・Node.jsが好きでExpress.js, React.js, Next.js, Goだとechoだったり Qiita:https://qiita.com/muratak-dev

自己紹介2 ・色々な技術記事を書いてます ・とにかく言語化するのが好き

@cosmeの技術構成 ・＠cosmeでの開発にはフロント/バックでTypeScriptを採用 インフラに関してはオンプレミスとパブリッククラウド(AWS, GCP)が混合 ・RebornではオンプレミスのシステムをAWSで設計構築し直したり、 既存コードをNode.js/ TypeScriptに変えていく作業をメンバー総出で行う カジュアル面談はこちらから！

@cosmeのシステム群 ・社内は600を超えるサブシステムが存在する (2024/03/22計測, githubでのレポジトリ単位) ・それらが@cosmeを含む複数のサービスを作り上げる ・25年間の事業発展の負荷に耐え続けるアーキテクチャ が望まれてきた →それぞれを正しく連携させ、最大のパフォーマンスを発揮するために、 Webサービス全体を束ねるUWGというサービスが生まれてきた カジュアル面談はこちらから！

UWG ・＠cosmeメディア全体の APIを束ねる役割を持つ (TypeScriptで記述されておりフロントへレスポンスと型を提供) ・一つの役割としてはBFF(Backend For Frontend) →APIをプロキシする中間層として各フロントにBFF APIを提供 ・もう一つの役割としてはモジュラモノリス として振る舞う →UWGレポジトリーの中にディレクトリを切ってドメインで分けてAPI実装 カジュアル面談はこちらから！

BFFとしてのUWG ・各サービスのAPIをプロキシして最適なレスポンスや型を返す ・この層でキャッシュを行うこともできる ・CORSや認証処理などを一括して担うことで処理を集約する カジュアル面談はこちらから！

モジュラモノリスとしての UWG ・各ドメイン(モノリスサービス)をモジュラモノリスとして構築 ・そうすることで既存のそれぞれのモノリスサービス特有の辛みを解消する ・モノリスサービスの辛みとして、密結合、コードの肥大化など ・将来的にあるかもしれない、マイクロサービス化にも対応できる構成として、モジュ ラーモノリスの形態をとっている カジュアル面談はこちらから！

UWGの負荷対策 ・多くのフロントからAPIが呼び出されるため負荷対策が必要 ・memcached, kafkaなどさまざまな技術を駆使して対策をおこなっている ・インフラはAWS ASGを使って負荷に応じてサーバー台数を増減して対応 カジュアル面談はこちらから！

UWGでの負荷対策① Memcached ・memcachedを用いてAPIレスポンスキャッシュを行う ・キャッシュを参照すれば良いので直接APIを叩く必要がなくなる UWG Memcached 各種API カジュアル面談はこちらから！ ・TTLは APIに応じて適切な長さを設定しておく

UWGでの負荷対策② Memcached x Kafka ・会員APIなど呼び出し数が顕著(目安: 10000rps↑)ならKafkaをかます ・例) 会員statusに変更があったらkafkaにイベント発火→それを合図にキャッシュクリア UWG Memcached Kafka 会員API カジュアル面談はこちらから！ ・TTLを長めにとる(例: 1month) ・基本的にUWGはMemcachedを参照してAPIコール数を減らす

UWGでの負荷対策③ ASG Auto Scaling Group カジュアル面談はこちらから！ FrontA FrontB Front-C DB UWG 各種API ALB A ECS A ECS ECS ECS ・基本対策としてはASG 負荷に応じてサーバー台数を増減 ・FrontAで局所負荷が起きたら Aモジュール専用 ASGによって対応 Aモジュール専用ASG

UWGが支えるフロントアーキテクチャの刷新 @cosmeの場合 ・モノリスでフロント/バックのコードが複雑に絡み合う ・事業発展によりフロントシステムが増えに増え管理が大変 UWGを新たなサーバーサイド基盤 として、 モノリス のフロントエンドコードを日々 新規フロントシステム (cosme-front)に日々刷新 →フロント /バック双方を TypeScriptで書くことによって、型定義の恩恵を受け刷新を加速 カジュアル面談はこちらから！

UWGが支えるフロントアーキテクチャの刷新 2 @cosmeの分解からcosme-frontへの移行へ ・前述のコードが肥大化した モノリスシステム保守による痛みの解消 ・リバースプロキシーで端末によって PCとSPサーバーそれぞれに振り分けるとともに、 フロントエンドでは端末のチェックを行って PC/SPそれぞれの画面を出す ・PCとSPでは返すべきレスポンスが違うので UWG/cosme-frontで連携して最適化を行う ・PCとSPで共通の処理として使えそうな部分は併用して使っていくことができる カジュアル面談はこちらから！

@cosmeではカジュアル面談を募 集中！ご気軽にご応募下さい