LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

Blog


静的リソースをCDN配信する社内サービス『Abyss』のフロントエンドを作り直した話

こんにちは、LINEフロントエンド開発センターDev7チームの白畑です。主にUITで使用している社内サービスの新規開発から運用・保守等を行なっています。
この記事ではDev7チームが開発・運用しているAbyssと呼ばれる社内システムのフロントエンドを作り直した話をしたいと思います。

画期的なCDNデプロイツール「Abyss」

LINEは様々なサービスを展開しており、それらのプロジェクトで個別にCDN配信を行なってしまうと以下のような問題があります。

・リソースの管理がしづらい
・独自の配信基盤が乱立する
・独自の配信基盤を構築するための開発・運用コストがかかる
・プロジェクトメンバーが参加した際や異動した際に学習コストがかかる

このような問題をなくすため、CDN配信の標準サービスとしてAbyssが誕生しました。

開発者は以下の最低2つの手順のみで静的リソースをCloudFront配信することができます。

1. Abyssのフロントエンド(Orth)でプロジェクトを作成
2. AbyssのCLI(reg)を使ってローカル環境もしくはCI上からリソースをアップロード

構成

Abyssは3つのサービス・アプリケーションで構成されています。

フロントエンドのOrthはプロジェクト管理や、配信中のリソース管理などの主にリソース管理を担当し、CLIのregはリソースのアップロードを担当しています。
バックエンドのidofrontはプロジェクト情報の管理やCDNへのDeployなどを担当しています。

詳細な仕組みについては下記のYouTubeをご確認ください。

旧フロントエンドの問題点と対処方法

Abyssをリリースしてからデザイン含めた大規模な修正は行なっておらず、フレームワークもNuxt2をJavaScriptで使用していたため、以下の問題がありました。

・型の不一致によるレビューコストの増加
・ファイルパスや日付のフォーマットが最適化されていないため、使いづらい
・他の社内サービスと比べるとUIが古く感じる

特にJavaScriptで実装されている事で、新規機能を実装する際や不具合修正を行う際に想定している値が入っているのかが分からず、検証するためのバリデーションを入れたりして行数が増えてしまったり、想定していない型の不一致によってエラーが発生したりと実装・レビューのコストが高くなっていました。
際に型の不一致によるエラーは本番環境に反映させた後に発覚し、hotfixとして緊急リリースしたこともあるため、TypeScriptへの移行はMustです。

新フロントエンドの技術選定と環境移行

旧フロントエンドをベースにTypeScriptへ少しづつ移行するより、書き直した方が実装コストがかからず、any型の多用といったTypeScriptのアンチパターンが発生しづらいと考えたため、今回は環境を含め全てを作り直すことにしました。
作り直すと決まれば次は採用するフレームワークとデザインシステムの選定です。

フレームワーク選定

フレームワークはNuxt3を採用し、デザインシステムは社内で開発されているAstroを採用しました。

Nuxt3はビルドにViteを採用したことによるビルドの高速化や、Vue3のscript setup構文、設定不要でTypeScriptが使えることに開発当初から興味を持っていました。
もちろん当時のバージョン(rc3)はコンテナ環境で正常に動作しないことや、SSGが使えないなどの開発するサービスによっては致命的な不具合や、既存のプラグインも殆ど対応していなかったりと、Nuxt2からの移行はもちろんプロダクション環境での使用も厳しいような状態でした。

今回はバックエンドのidofrontへAPI用のProxyを張るために、SPAモードかつ開発時はコンテナを使用せず、定期的にバージョンを上げていくことで不具合の回避ができると考えたため採用をしています。

AstroはBootstrapをベースに社内で開発されている社内システム向けのデザインシステムです。
Vueのコンポーネントも別パッケージとして存在しており、実装コストを掛けずに見た目や動きをprivateNPMIU Webなどの他の社内システムと統一できるため導入しています。

環境の移行

旧フロントエンドではLINEのプライベートクラウドであるVerdaでVMを複数台動かし、AnsibleでDeployする運用をしていました。
この運用には、PrimaryのVMを手動で指定してDeployする点やAnsibleのDeployに時間が掛かり、失敗した際の復旧に時間が掛かる点など、いくつか問題ありました。

VerdaにはVKSと呼ばれるKubernetesのマネージドサービスがあり、VM管理が不要かつスケールアウト、ローリングアップデート等ができる為、移行先の環境として採用しました。
Ingressコントローラーはチーム内で導入実績のあるTraefik Proxy使用し、ログはfluentdを使用してElasticsearchへ転送するようにしています。

フロントエンドのコンテナイメージはCI上でビルドし、社内のDocker Registryへpushしています。
そのため、Deploy後に問題が発生しても直ぐにロールバックできるため、Ansible運用の課題であった復旧に時間が掛かる問題を解決しています。

新フロントエンドのリリース

開発中は大きな問題が発生することはなく、事前に予定していたスケジュール通りにリリースすることができました。

今回のプロジェクトではベータ期間を設けて、ユーザからの機能要望や不具合のフィードバックがもらえるようにしたため、リリース後も致命的な不具合が発生することもなく、安定した運用を行うことができています。
旧フロントエンドで発生していた問題はTypeScriptとAstroの導入で全て解決することができ、Ansible運用で課題になっていた反映とロールバックに時間がかかる点もVKS移行によって解消しました。
また、実際の使用感についても社内Slackやシャッフルランチにて、以前に比べて使いやすくなったと
高評価を頂くことができました。

スクリーンショット


ログイン画面(サービスのメイン機能であるCDNへのDeployを意識したデザインへ変更)


プロジェクト一覧画面の新旧比較(一覧を3カラムから1カラム表示にし、目的のプロジェクトを探しやすいデザインへ変更)


プロジェクト画面の新旧比較(カードを1カラムで表示するレイアウトにし、ボタンを押さなくてもプロジェクトに関する情報が見えるよう変更)


ファイル一覧画面の新旧比較(ファイル名のみを表示し、日付も見やすいフォーマットへ変更)

最後に

このプロジェクトは勉強を兼ねた個人的なものとして始まりましたが、チームプロジェクトへの昇格を得て、チームメンバーを巻き込みつつリリースすることができました。
このように、Dev7チームは自ら問題点を見つけて作り直すこともできるため、フットワークが非常に軽いのが特徴です。

Dev7チームは古い技術に囚われることなく、新しいフレームワークやライブラリなどを取り入れ、既存サービスの改修や新規サービス開発を行なっていますので、次の記事もご期待ください!

UIT 新春 Tech blog 2023記事一覧

1. Git submoduleを使ってマルチリポジトリなMonorepoを管理する
2. LINEドクターフロントエンド開発の流れ
3. 静的リソースをCDN配信する社内サービス『Abyss』のフロントエンドを作り直した話
4. LINE NEWS フロントエンドの自動テストの改善