ライブドアブログが15年かけて積み上げた技術的負債への挑戦––LINEのブログサービスのエンジニアが明かす、光と影

15年熟成された技術的負債と戦う

大森貴博氏：こんにちは。今回は「Inside of Blog」というタイトルで発表させていただきます。サブタイトルを日本語に直すと「15年熟成されたサービスの光と影、カオスとレガシーへの挑戦」となっております。

今回スピーカーを務めさせていただく大森と申します。よろしくお願いします。

現在はブログサービスのリードエンジニアをやっていて、エンジニアの領域としてはサーバサイドエンジニアです。社歴はそこそこ長いんですが、ブログ開発に携わったのは4〜5年前からです。ふだんはPerlを書いています。

さて、今回の主役であるブログですが、LINEには2つのブログサービスが存在します。1つは2003年リリースの「ライブドアブログ」。もう1つが2014年にリリースされた「LINE BLOG」です。

では、まず、15年以上の歴史を持つ老舗サービス、ライブドアブログから見ていこうと思います。

ライブドアブログとは、日本最大級のブログサービスで多くのユーザー・多くコンテンツを抱えています。歴史が長いだけあって高機能で安定したサービスが売りです。

構成は昔ながらのLAMP構成（Linux・Apache・MySQL・Perl）で、フレームワークは、ライブドア時代の自社製フレームワークであるSledgeが採用されています。

簡略化していますが、ライブドアブログのシステム構成はこの様になってます。上のほうがインターネットだと思ってください。

前段にCDN・ロードバランサーがあり、その先にユーザーのブログやコンテンツを管理するCMSと、ポータルサイトなどいくつかのコンポーネントに分かれています。更にその中にはwww(Apache)とPerlで書かれたアプリケーションがあり、それぞれ通信しています。

そして一番奥にあるのが、データベースやキャッシュやストレージサーバです。これは一般的なWebサービスの構成なので、それほど変わったことはしていません。

スライドに「Blog Core」と書いていますが、これがどういうことかというと、こういうことです。

先ほどの構成図は、真ん中のBlog Coreの部分です。そこから線でつながっているものはサブシステムと呼ばれ、すべて合わせると30近く存在します。これらが合わさることでライブドアブログのシステムを形成しています。

ライブドアブログが15年かけて積み上げたもの

これでぼんやりとシステムの全体像が見えてきたと思うので、次は別の角度から眺めてみよう思います。

「数字で見るライブドアブログ」ということで、ライブドアブログ15年の歴史を感じてもらおうと思って数字を出してみました。

ここに70から41万までの数字を並べてみましたが、これが何を表しているか想像できますか？　わからないと思うので順に見ていきます。

まずは70から。これは歴代の開発者数です。バージョン管理がCVSからSubversion、Git、GitHubと何度も変わっているので正確な集計はできませんでしたが、確認できた数字で最低70人、これだけのエンジニアが入れ替わり立ち替わりブログ開発に携わってきました。

さて、次の750というのはサーバ台数ですね。先ほど見たブログシステム全体のサーバ台数を合わせると750台以上。うち200台がDBサーバで、その中でも一番巨大なものはブログの記事を保存している記事クラスタDBというもので、それだけで120台あります。

次の550、これはテーブル数ですね。テーブル数といっても実テーブルの数ではなくて、テーブル定義の数です。多いのか少ないのかわかりませんが、少なくはないと思います。

43,500というのはリポジトリに登録されているファイルの数です。細かい画像やパーツも含みますが、全体として4万3,000以上のファイルがGit上で管理されていることになります。これは日々増えています。

3,800というのは、プログラムファイルの数です。正確に言えばPerlのプログラムなので、プログラムを記述してある .pm ファイルの数が3,800。このあたりは言語の違いもあって判断しにくいと思うので、参考までに社内のほかのPerlプロダクトを見てみたところ、多いものでも1,000〜1,500ファイルだったので、その2〜4倍以上と、だいぶ多いですね。

最後の41万というのは、コードの行数です。

先ほどのプログラムファイルをwcコマンドで調べると、41万行書かれていました。Perlというのは比較的短く書ける言語なので、それで41万というのはだいぶ多いと思います。

サーバ移転プロジェクトは今年で3年目、しかし…

ここまで数字から見てきましたが、15年でどれほどの蓄積があったのかわかっていただけたかと思います。

次は、ライブドアブログで現在進行中のプロジェクトについて紹介します。大きなプロジェクトが2つ走っていて、1つはサーバ移転プロジェクトです。

ライブドアが経営統合されてLINEになったあと、旧ライブドアのインフラとLINEのインフラの2つに分離していたものを1つに統合するためにサーバの論理移転を行っているプロジェクトです。先ほど説明した750台以上のサーバとすべてのサブシステムを移動する必要がありました。この作業は、2017年から開始して現在で3年目、まだ終わっていません。

もう1つは常時HTTPS化プロジェクトです。世界的にHTTPSが必須になりつつあるので、それを受けてブログのシステム全体をHTTPS対応させるというものです。これについてはユーザーさんからのリクエストも多いので、気になっている方も多いと思います。このプロジェクトはサーバ移転の1年後の2018年から開始して、現在2年目。これもまだ終わっていません。

この2つのプロジェクトですが、サーバ移転が進まないとHTTPS対応が行えないという技術的な制約もあったので、密接に関わりながら進んでいるものです。

でも、ちょっとおかしいと思いません？　サーバ移転とHTTPS化だけでこの数年かかる？　普通はかからないですよ。では、なぜそんなことになっているのかというと、ライブドアブログに存在する闇の部分が関連しています。

ライブドアブログのダークサイドを振り返る

ということで、この先はライブドアブログのダークサイド、カオスとレガシーについて実例を挙げながら紹介していこうと思います。

まずケース1。ドキュメントがない。これはあるあるです。みなさんも経験があると思いますが、引き継いだはいいけどいざ作業しようとするとドキュメントがない。なにをしていいかわからないというあれです。30近くのサブシステムがあるブログなので、それのひどい版だと思ってもらえれば大丈夫です。

想像してほしいんですが、期待を持ってクリックしたドキュメントの先がこれだったときを……。

これはだいぶ絶望です。「情報ない。なにしていいかわからない」と、なります。

これは、Blog Coreではなくふだん手を入れることがないマイナーなサブシステムでよく起きます。デプロイ方法が謎だったり、セットアップ方法が謎だったり、開発環境が謎だったりと、わりと致命的なことが多いです。ちなみにドキュメントにウソが書いてあったりもするので、古いドキュメントだと素直に信じられません。

開発サーバが存在しない

次のケースです。開発にあたってなくてはならないものは何だと思いますか？　それはもちろん開発サーバ、開発環境なんですが、開発サーバがない、もしくは使い物にならないという状況が存在しました。

これはもちろんBlog Coreのように比較的メンテされてるシステムなら心配無いんですが、サブシステムの中には誰からも忘れられていて、かつ安定して動いているという、良いのか悪いのかわからないものが存在しています。それらに手を入れようとしたときに発覚するパターンが多くありました。

イメージしにくいと思うので、「開発環境の難易度チェック用フローチャート」を作ってみました。

まずは正常な状態から確認してみます。左上の「START!!」から開始して「開発サーバは存在するか？」。まずはYesですね。次に「それは正常に動作しているか？」も普通はYesです。次、「本番環境との差分が少ないか？」ももちろんYesですね。最後に「本番環境のデータを使っていないか？」も普通はYesのはずです。

これらすべてがYesなら困ることなく開発が行えるので、つまり開発環境の難易度はイージーモードです。常にこうあるべきです。

では、このどこかにNoがあるパターンを考えてみましょう。右から2つ目、「開発環境との差分がないか？」がNo。つまり、開発環境と本番環境に差分があると、うっかりデプロイできないことになるので、危ないですね。

もう1つ、「本番環境のデータを使っていないか？」がNoの場合は、開発環境で本番のデータを参照していることになります。不思議ですね。こんなことは普通ならありえませんが、ブログでは当たり前の様にありました。

まだこのぐらいならちょっとがんばれば直せるので、ノーマルモードくらいにしておきます。では、ほかのパターンを見てみましょう。

フローチャートの最初「開発サーバが正常動作しているか？」がNoの場合は、つまり開発サーバ、開発環境が壊れているということなので、環境の再構築が必要になります。とても面倒くさいですね。

「開発サーバが存在するか？」がNoの場合、ここでも1つ分岐が発生して「昔、開発サーバが存在したか？」。これがYesであれば、なんとかなります。昔あったものをもう1回作ればいいので。

これは両方ともハードモードとしておきます。面倒な感じになってきました。

残るのはただ1つ。これは「過去に開発サーバが存在したことがない」という場合なんですが、これは悪夢です。

最初から開発環境が存在しなかったので、開発環境を開発するところから始めなければいけません。これはほかと次元が違います。そもそもどうやって開発したのか謎ですが、考えないでおきます。

ブログでは、このすべてのパターンを実際に経験しました。その都度作業が止まって計画が崩壊していくので、だいぶつらかったです。これが移行作業が長引いた原因。サーバ移転とHTTPS化において、本当にこれで大きくつまずいたというのが真相です。

300存在したDNSレコードのうち、7割は不要だった

では、気を取り直して次の事例を見てみましょう。

カッコよく「カバレッジが低い」と書いてあるんですけど、ぶっちゃけ、ぜんぜんテストがありませんでした。なので、タイトルを変えておきます。

テストがない……まあ、ないものはないので、これ以上話すことはないですね。

では次にいきます。DNSのレコードが多すぎる。これはHTTPS化に関連した作業で証明書の取得などを行う必要があったので、対象範囲の調査のためにドメインを整理したところから始まったのですが、調べてみると、ライブドアブログのサービスで管理しているDNSレコードが300以上もありました。

ちなみに、この数にユーザーが設定している独自ドメインは入らないので、純粋にサービスが管理しているドメインだけです。

さすがにこれはちょっと多すぎだろうということになって、全部チェックしました。その結果、なんと230が不要なレコードでした。

4分の3、77パーセントがゴミですね。もちろん全部削除しました。

このゴミの内容は、古い機能で使ってたドメインや過去のキャンペーンですね。ライブドア時代はキャンペーンをすごくたくさんやっていて、その都度ドメインを作っていたのですが、そのあと誰も掃除しなかったので、まさに15年分の蓄積がこれです。

ちなみに、この調査と削除で数ヶ月を要したわけですが、HTTPS対応の基礎調査だけでこれなので、だいぶつらかったです。

トラックバック機能廃止の舞台裏

数が多いと言えば、ライブドアブログは歴史が長いだけあって機能も多いんです。そのため、サーバ移転などを機に古い機能の整理も行いました。ここ2〜3年で、目に見えるもので10以上、目に見えないものではもっと多くの機能を削除しています。これは単純に削除しているというよりは、次の開発をしやすくするための準備作業でもあります。

例えばレガシー機能の代表であるガラケー版。ユーザーの減少もありますが、そもそもHTTPS対応が難しかったり、新規機能改修のときに実機を使って検証する必要があるのでわりと大変だったり、さまざまな面で足を引っ張っていたのが現状でした。なので、これは廃止の方向に向かっています。

また、覚えている方もいると思いますが、数年前、トラックバックというブログを代表する1機能を廃止しました。この機能はかなり前からスパムの温床になっていたのでどうにかしたかったのですが、ブログ同士をリンクさせるオープンな規格なので、廃止するのは迷いがありました。しかし、サーバ移転があるので廃止を検討しなければいけない時期には入っていました。

ちょうどその頃、Googleさん主催の「Advanced Hosting Meetup 」という会議に参加していました。そこではスパムの情報共有や大規模コンテンツの管理方法について議論されていたのですが、その場に日本のブログサービスの担当者が多く集まっていたので、そこで「古い機能であるトラックバックとかを終了しませんか？」という提案をして、そこで賛同していただいた事業者さんと一緒に、タイミングを合わせてトラックバック機能をやめた、という裏話もあったりします。