今回、プロジェクトチームのうち吉田悟氏(外部サービスとの連携部分を担当)、河津正和氏(スマートフォンアプリ用のAPIを担当)、櫻井雄介氏(インフラを担当)の3名に集まっていただき、Yahoo! JAPAN年賀状のサービス開発や運用の裏側を語ってもらった。とくにエキスパートによるサーバーオペレーションと、印刷データの管理とチューニングを掘り下げ、 プロジェクトの中で若いエンジニアがどのような業務に携わりどんな仕事をこなしていったかにも焦点をあてる。
クリエイティビティを活用する場としての年賀状サービス
Yahoo! JAPAN年賀状は直近のサービス提供が4年目をむかえ、事業規模も成長を続けている。そもそも、同社はなぜ年賀状のサービスを始めたのか。
年賀状というのは人々の生活の中でだれもが経験するクリエイティブ活動である。近年は年賀状を出す人が減っているというが、それでも34億枚(2014年)の年賀状が発行されている。このうちネット利用のものは市場を拡大しているとはいえ、全体から見れば1%に満たない。ならば、逆に同社の技術とクリエイティビティを活用すれば、この市場を掘り起こすことができるのではないか。なにより、日本のクリエイティブ文化を新しい形で将来へつなぐことができる。
事業を始めた背景には、自社事業という目的の他にこのような同社の想いもある。
今年はスマホ対応――API開発は入社2年目のエンジニアが担当
例年、プロジェクトは前年の6月くらいからスタートするという。2014年の年賀状サービスのためのプロジェクトが始まったとき、新機能としてスマートフォン対応を決定すると、そのスマートフォンアプリのためのAPI開発に抜擢されたのが、新卒入社2年目のエンジニア河津氏だ。
まず、APIの仕様を考えライブラリの設計をするわけだが、河津氏は「スマートフォンのアプリ向けということで、まずいかに通信量を下げるかが重要なポイントでした」と語る。APIはiOS、Androidの両方に対応するが、遅い回線でも使えるように無駄な通信やデータのやり取りは極力抑えなければならない。
具体的には「画像のやりとりにはサムネイルを使ったり、非同期通信の利用やデータベースクエリーのチューニングを行ったりして工夫しました。(河津氏)」とのことだ。またAPIは、ネイティブアプリを対象とするため、ブラウザのクッキーは使えない。そのため、セッションIDを管理するAPIなども実装した。
開発中は、アプリ開発チームとのAPI仕様のすり合わせやデバッグも発生する。サーバーやネットワークなどインフラを管理・運用するチームとの連携も必要だ。河津氏は、これらの作業をチームの先輩たちの協力を得ながらこなしていった。
インフラ担当はサーバーオペレーションのエキスパート
年賀状サービスのローンチは11月1日からだ。APIやスマートフォンアプリはそれまでにリリースできるように開発が進み、実際のサーバーもこれに合わせて準備される。サーバーなどのインフラを担当したのは櫻井氏だ。
櫻井氏は入社2年目だが、その前はデータセンターのオペレーションセンターでの勤務経験がある。サーバーの監視や運用については中堅として活躍している。Yahoo! JAPAN年賀状のサービスは4年目なので、インフラの土台や運用ノウハウが蓄積されていた。しかも2014年度版からは、プライベートクラウドを構築し、昨年の構成などを生かしやすい環境を整えた。それまで毎年スクラッチで構成していたが、クラウド活用によりセットアップコストを下げ、ピーク時のスケーラビリティを向上させた。ちなみに、Yahoo! JAPAN年賀状のピークアクセスは100万PV/日に達する。
とはいうものの、Yahoo! JAPAN年賀状のサーバーは一般的なWebサイトと違い、利用者が年賀状のデザインを作る操作が必要なので、セッション数や扱うデータ量が多くなる。櫻井氏は「サーバーの構成管理やチューニングは難しいです。メモリはすぐになくなるし、CPUも喰います。ピーク時はリソース状況を確認しながら対応していました。また、今回はスマートフォン対応が追加されたりと、Yahoo! JAPAN年賀状の利用者も年々増えているので、トラフィックパターンなど予想が困難な面もありました」と、運用の難しさを語る。
実は2013年末に、Yahoo! JAPAN年賀状がテレビに取り上げられたことがあった。通常Webサービスがテレビで紹介されると、管理者はアクセス集中で悲鳴を上げるものだ。しかし、櫻井氏は「想定内の範囲」として、サーバーダウンなどトラブルなしでこの波を乗り切ったという。
そのサーバー構成は、ロードバランサー、Webサーバー、DBサーバーといった基本的な構成にストレージサーバー、管理サーバー、キャッシュサーバー、バッチサーバーを加えたかなり可用性の高いものとなっている(図参照)。このうちWebサーバーが6台からピーク前に12台、DBサーバー(参照系)が3台から同7台、バッチサーバー(印刷ジョブなど対応)が2台から同3台というスケーラブルな構成となっている。
これらをプライベートクラウドで構築しているため、自社管理のファイアウォール、ルータなどの内側に展開でき、セキュリティも高い。プライベートクラウドを導入しての構成は、同社が自社事業やサービスに対する本気度が表れている。