7月15日に開催された【オンライン】Hatena Engineer Seminar #14 〜魔法のiらんど編〜に参加した。
内容の一部紹介
魔法のiらんどは、1999年から続く女性向けの小説投稿サイト。それまでのはてなのサービスのユーザー層と異なるため、まずはユーザー理解を徹底するため、3度にわたるユーザーインタビューを行った。グループインタビューをメインにすることで、インタビュアーが知らないことも引き出せた。
デザインの全面リニューアルや機能廃止はユーザーが戸惑いやすいため、事前の告知などコミュニケーションを大事にしながら進めたとのこと。
GraphQL
構成：デザイン => Next.js => GraphQL => データベース
クライアント・サーバー間のインターフェースとしてGraphQLを採用。GraphQL とは、APIのためのクエリ言語とクエリに応じたデータを返すランタイム。クライアントからクエリを受け取ったサーバーがクエリと同じ形のJsonを返す。
SPA（シングルページアプリケーション）＋API の構成にすることで、モダンなアプリ的な体験を実装しやすくなる点や、クエリ言語が画面の変更に強いこと、モダン技術を採用することによるエンジニアのモチベーション向上などの理由から、GraphQLを採用した。
GraphQLはネストが深いデータも簡単に取得できる。スキーマファーストの開発をすることで、並列開発（最大8人）が可能となった。
魔法のiらんどは、月間3億PV、毎秒350リクエスト（ピーク時）。GraphQLはキャッシュが難しいという問題があった。「推測するな、計測せよ」という言葉に従い計測したところ、かなり遅かった。修正したところ、キャッシュなしでも耐えられることがわかった。
フロントエンド
ユーザー体験の向上のため、ページ遷移時に全体を再読み込みせずネイティブアプリのような操作感を実現できるSPAにしたい。カプセル化された部品を組み合わせてUIを構築する React のフレームワークである Next.js を採用。
アクセスはモバイル端末からが大半を占める。レスポンシブ（2010年に出た）はコンポーネントベースの思想が広まる前の時代の考え方。見た目以外の差分が多くスタイルシートだけでの調整は困難だった。
端末ごとにコンポーネントを出し分ける方法を考えたが、SSR（サーバーサイドレンダリング）とCSR（クライアント側）に相違があると、SEO的にペナルティをくらうことがある。最終的にUserAgent 文字列内に "Mobile"という文字列が存在するか確認するという単純なロジックで解決。UserAgent が使用できなくなった場合にも修正しやすいようにした。
データ移行
20年分のデータは膨大な量。データベースのスキーマ定義の変更を伴い、小説の記法が変わるため全エピソードの書き換えが必要。データ間の依存関係を解決しながら移行する必要がある。「想定していないデータが存在する」という前提を持ち続けて作業にあたった。
N+1問題などがあり普通に実行するとデータ処理に1ヶ月以上かかることがわかった。AWSを利用することで解決。AWS Batch は、リソースに余裕がある限りジョブを並列実行してくれる。
感想
企画からフロント、デザイン、プロジェクトマネージャーまでさまざまな立場の方の話を聞けてよかった。はてなが受託をやっていることを知らなかった。規模の大きい開発になると、それぞれにたくさんの課題があり、さらに大人数でやるからこそのコミュニケーションなど工夫しなければならない点も多いことがわかった。
プロジェクトマネージャーの方の「最後にものをいうのはモチベーション」という言葉も印象的だった。技術の選定にあたってもエンジニアのモチベーションを高められるモダンなものを選ぶようにしているということだった。
新しいものより前から知っているものでやった方が楽そうなのに、やはりエンジニアというのは勉強好きということなのか。やっぱりエンジニアになりたい！
