リーマンショックにも社長の厳命にもめげず、8台のサーバーで数千万ユーザーのデータを回した

執行役員　チーフテクノロジーオフィサー（CTO）として、ヤフーの技術を経営の立場から牽引する藤門千明。彼のキャリアをたどる連載・第4回は、リーマンショックによるサーバーコスト削減の対応策や工夫などの経験談を紹介する。

リーマンショックで予算減。サーバー32台の予定が8台に

ECサイトで何かを購入すると、ポイントが付き、それがたまるとユーザーのランクが上がる。今ではほとんどのECサイトで導入されている会員ランク機能。ヤフーがこれを初めて導入したのは2009年10月のこと。
Yahoo!ショッピング、Yahoo!オークション（現ヤフオク!）のサービス開始から10周年を迎えることを記念した事業の一つ。

当時は「スタークラブ」という名称で、Yahoo!ショッピング、ヤフオク!をはじめ、Yahoo!トラベルやYahoo! JAPANの有料コンテンツ・サービスなどでの利用金額をもとにユーザーのランクを設定し、優待セールや会員ランク別Ｔポイント倍率アップなど、ロイヤルカスタマー向けの特典プログラムを用意した。
このスタークラブのシステムを開発したエンジニアの一人が、当時、SWATチームにいた藤門千明だ。

「Yahoo!ショッピングのチームは今でこそ、ヤフーのカンパニーの一つになっていますが、当時はまだ小所帯。エンジニアたちはいろいろなシステムを実装してサイトを拡充させたいと思っていたけれど、自分たちだけでは限度がある。そこでSWATチームに声がかかったんです」

SWATは社内のシステムのお困りごと全般を引き受ける専任部隊。ちょうど他に火急のプロジェクトがなかった時期で、藤門はショッピングチームのディレクターの「会員ランク制度を作りたい」という要請を二つ返事で引き受けることにした。

「Yahoo!ショッピングやヤフオク！などのサービス側からお客様ごとのアクション頻度や取引金額のデータをバッチ処理で収集し、その頻度や額に応じて、会員種別を判断し、それをサービス側に返すというものです。
最初はYahoo!ショッピングのプレミアム会員700万人を対象にしたサービスのつもりでした。そのつもりでAPIを書いてデータを吸い上げる仕組みを考えました。700万人だからバックエンドのサーバーは32台もあれば十分だろうと見込んでいたんです」

仕様策定が順調に進んでいた頃、世界を揺るがす大事件が持ち上がった。2008年9月15日、アメリカの投資銀行であるリーマン・ブラザーズが破綻したことに端を発して、世界に一気に広がった金融危機。いわゆる「リーマンショック」だ。

「ヤフーは直接その影響を受けたわけではないのですが、世の中は一気に設備投資を控えるムードに転じました。ヤフーでも社内予算の財布の紐が急にきつくなった。不要不急のシステム投資はとりあえず控えようというわけです」

その余波が、藤門らのプロジェクトにも覆い被さった。32台のサーバー予算は削減され、8台購入するのが精一杯。
当時、クラウドはまだ出始めで、ほとんどのシステムは社内オンプレミスのリアルサーバーで動いていた時代。サーバー資源はまだまだ貴重だった。

700万人じゃない、1億人が対象だ

「仕方がないから、8台のサーバーを並べてなんとかやりくりし、サービスのリリース直前というところまで来ました。これでやっていけると、リリースの最終承認を求めに、当時の井上雅博社長にお伺いを立てに行くと、とんでもないことを言われました」

井上社長はこう言ったのだ。

「なんで、700万人なの。それってプレミアム会員の数字じゃないか。ヤフーのサービスはアクティブユーザーだけでも3000万人に使われているんだよ。それ以外も含めたら億単位のお客様がいる。会員ランク制度はすべてのお客様を対象にしなきゃだめじゃないか」

経営者のスケール感は、やはり現場のエンジニアとは根本的に違うものである。700万人の想定がとたんに2桁も跳ね上がったのだ。
しかしただでさえサーバーリソースが最初の仕様の4分の1にまで削減されている。たったの8台で数千万ユーザーのデータをどうやって処理するのか。しかもSWATチームはまだ藤門も含めて5人しかいない時期だ。

「これはまずいことになったと思いました。これまで将来のメンテナンス性を考えて、APIはPHPで書いていました。しかし、当時のPHPは遅く、サーバー処理のパフォーマンスがよくなかった。
これではデータを処理しきれなくなることは目に見えていました。PHPで書いたプログラムは、アプリケーション・サーバーも含めて全部捨てざるを得ない。全部をC言語で書き直すしかないと思ったのです」

PHPをC言語で書き直す作業自体は単調で退屈だ。なんでこんな無駄な仕事をと思いながら、藤門は一人で泣く泣く作業にあたった。
今でこそ、Cのコンパイラが自動的に最適化処理をしてくれるが、当時はまだ不十分だった。コンパイラを正しく動かすためのコード処理にずいぶん時間を取られた。

いったんはC言語に置き換えたものの、そのままではパフォーマンスはなかなか上がらなかった。1億ユーザーを想定してダミーデータを作る。机上で計算する限りはうまくいくが、実装すると動かなくなる。チューニングしてはテストの繰り返しだった。

「膨大なデータをキャッシュして、結果を高速に返す仕組み。Yahoo! Inc.はどんなシステムを使っているのか、相当調べました。一つ、使えそうな技術があった。それを日本サイドに合わせてカスタマイズを重ねました。
サーバーが8台しかないので、1台でも落ちちゃうととたんに負荷が跳ね上がる。だから高速だけれど信頼性も高いシステムにしなければならない。データ分散のテクニックなども私なりに工夫しましたね」

日々、ヤフーの各サービスがどのぐらいのアクセスを受けているのか。時間、曜日ごとの推移をあらためて調べた。
リソースがないならないで、やるべきことはある。頭をフル回転し、手を動かし、そして試行錯誤を繰り返す。

貧乏性のエンジニアは工夫を重ねる

2009年10月「スタークラブ」はなんとかリリースにこぎつけた。

「スタークラブがリリースされた直後、Yahoo!ショッピングのリニューアルを謳うテレビCMを放映したんです。それまでエンジニアとして関わったプロジェクトが、こんなふうに公になることはなかったから、それはうれしかったですね。グッと来ちゃいました」

苦労がなんとか報われた瞬間だった。リーマンショックから1年が経っていた。
当時まだECサイトとしては弱小だったYahoo!ショッピングは、会員ランク制度の導入で、先行他社になんとか追いつく武器を得たことになる。
藤門らSWATチームが構築したスタークラブのシステムは、2014年7月にYahoo!ショッピング専用の優待プログラム「ストアスタンプラリー」として内容を拡充してリニューアルするまで、5年にわたって続くことになる。

「サーバーはその後増えましたが、リソースが大きければいいというものでもない。サーバーのCPUやメモリが潤沢に使えるようになる一方で、アプリケーションのサイズも大きくなる。本来はもっとコンパクトなメモリで動けるようにエンジニアは工夫をすべき。

もちろんメモリが大きければこういう勝負ができるよというテクノロジーもありますが、その時でも、いかにコンパクトに生産性よくサーバーを運用するかという経験があると、いいプログラムを書けるようになります。つまりエンジニアにとっては、ときには貧乏性であることも役に立つんです」

もちろん、貧乏でなければないに越したことはない。いま、クラウドの時代。サーバー単価などその都度計算するのはもはや時代遅れなのかもしれない。
しかし、こんな豊かな時代にも、いついかなるときに、理不尽な制約がエンジニアを襲うかはわからない。そこでめげず、工夫を武器に立ちあがることがエンジニアには求められているのだ。