Yahoo!メールのバックエンドシステムのリニューアル

こんにちは、ヤフーの大阪オフィスでメールサービスを担当しているエンジニアの城下です。

2015年から進めてきたYahoo!メールのバックエンドシステムの大規模リニューアル（以下、BEリニューアル）によって、どのように耐障害性を強化できたか、どんなメリットを得られたか、などを紹介します。
こちらの話は、先日、2019/9/6（金）に弊社で開催されたMix Leap Study「CTO Night KANSAI Vol.3」のブレイクアウトセッションでも登壇発表させていただきました。

Yahoo!メールの概要説明

まず本題に入る前に、Yahoo!メールの概要について説明いたします。

Yahoo!メールは1999年より始めたメールサービスで、毎月2300万人以上のユーザーにご利用いただいております。※1
フィッシングメールをはじめとする迷惑メール対策に力を入れて取り組んでおり、iPhone版アプリで他社メールサービスのアカウントを追加できる機能や、予約メールをカレンダーに自動登録する機能を新しく追加しました。

以上がYahoo!メールの簡単な概要説明でした。
ではいよいよBEリニューアルについて紹介していきます。

BEリニューアルの経緯

まずはBEリニューアルの経緯についてです。
サービスの成長に伴い利用ユーザーが増加してきましたが、以下の価値を提供し続けるためにBEリニューアルプロジェクトを始動しました。

• 今後もスピーディーにユーザーが求めるものを提供するため
• より安定したシステム稼働を実現するため

BEリニューアルプロジェクトは、計画から2年半かけてリリースを行いました。

• 2015年10月に計画開始
• 2016年は設計、開発、テスト
• 2017年夏頃から社内で検証開始
• 2018年2月に一般ユーザー向けリリース

BEリニューアルのポイント

BEリニューアルで対応したポイントを2つ説明いたします。

• 疎結合なシステム
• DR（災害復旧）対策を強化

1つは疎結合なシステムにすること、もう1つはDR対策を強化することです。
これらについて一般的なシステムを例に、それぞれ内容を説明いたします。

1.疎結合なシステムとは

システム間の関係性や依存関係が弱く、独立性が高い状態のシステムです。メリットとしては下記の点が挙げられます。

• 機能開発がしやすい
• 不具合が起きた際の影響範囲が狭い

具体的なシステム例がこちらで、疎結合と対象になる密結合なシステムと比較いたします。

密結合のシステム（図左）では1つのサーバーが複数の機能を保持しているのに対して、疎結合のシステム（図右）では機能ごとにサーバーを分けています。
これによって下記の利点があります。

• 機能Aの開発をする際は機能Aを保持する一番上のサーバーだけをリリースすることが可能
• 機能Cに不具合があった場合も機能Aと機能Bには影響しないので、密結合と比べて影響範囲を狭くできる（影響が出るのは機能Cを保持する一番下のサーバーのみ）

この仕組みをメールシステムに取り入れることで、機能ごとのリリースが容易になり開発がしやすくなりました。
また、障害が起きた際の影響範囲が狭くなり、復旧までの時間も短くすることができました。

2.DR（DisasterRecovery）とは

自然災害によるシステム損害を未然に防いだり、早期復旧に備える仕組みのことです。
具体的なシステム例がこちらで、システムを東西で冗長になるように構成しておきます。

このような構成にしておくと、仮に西日本で大規模災害が発生して西日本側のサーバーがダウンしてしまった場合でも、 東日本側のサーバーでサービスを継続して稼働できます。

以上の2つ、疎結合なシステムにすることとDRを強化することがBEリニューアルのポイントです。

システムの運用設計

ここからは筆者が担当したもののうち、システムの運用設計について紹介いたします。 BEリニューアルのシステムで障害が発生した時に、その状況を迅速に把握するためにSplunkを導入しました。

Splunkとは

システムが出力するログデータを高速かつ効率的に収集し、検索・分析するツールです。 ログの利用例としては下記などが挙げられます。

• ITシステムのアプリケーションのログを収集して、障害検知時に迅速に調査
• 工場機械のセンサーログを日々観測することで、機器故障の事前検知に役立てる

その他の利用例：https://www.splunk.com/ja_jp/customers.html

では障害状況の把握とSplunkの関係について、Splunk導入の前後で比較して説明いたします。

Splunk未導入のシステムで障害状況の把握

まずはSplunkを導入していないシステムで障害を検知した際に状況を把握する場合の例です。

機能Aでの障害発生を検知した場合、ユーザーがサービスを正常に使えているかを確認するために、下記の点を調査する必要があります。

• 機能Aの他のサーバーでは発生していないか
• 他の機能に影響が出ていないか

Splunkを導入していない場合は、それぞれのサーバーにログインして該当ログを1台ずつ確認する必要があり、調査にはかなり時間がかかってしまいます。

Splunk導入済みのシステムで障害状況の把握

次にSplunkを導入済みのシステムで障害を検知した際に状況を把握する場合の例です。
前提として、常に各サーバーからログを転送してSplunkで収集している状態です。

機能Aでの障害発生を検知した場合、調査としては検知した障害のログをSplunkのUIで検索するだけで機能Aの他のサーバーでの発生状況や他の機能への影響を一括で検索することが可能です。
よって先ほどのようにサーバー1台ずつログを調査する必要がなく、障害が発生した際に迅速に状況把握ができるようになります。

Splunkを導入するメリット

ログを収集するだけであれば自前でサーバーを用意する方法もありますが、Splunkの導入は比較的容易で、検索や集計で役立つ機能がデフォルトで用意されていることが特徴です。
下記に示すSplunkの特徴を組み合わせることで、不具合が起きた際の影響や原因を迅速に調査することが可能となります。

1. SQLライクなコマンドとパイプ「|」を合わせた文法で検索文の自由度が高い
2. apacheやnginxなど代表的なログフォーマットは、ログに含まれる項目をSplunk側でフィールド（検索・集計時のフィルターとして利用）へ自動で変換してくれる
3. 合計値や平均値、最大値や頻出値の集計関数が用意されている
4. タイムチャートによる時系列での集計ができる
5. 円グラフや折れ線グラフの描画機能が用意されている

以上、筆者が担当したSplunk導入によるメリットについて紹介いたしました。

BEリニューアルで達成したこと

改めて、Yahoo!メールのバックエンドシステムのリニューアルで達成できたことについてまとめます。

• 疎結合化
  • 機能開発がしやすくなった
  • 不具合が起きた際の影響範囲が狭くなった
  • 復旧する際の正常動作の確認作業も早くなり、障害からの復旧時間が圧倒的に短くなった
• DR強化
  • 大規模な自然災害が発生した際、サービスを継続稼働できるシステムになった

終わりに

筆者はBEリニューアルを通して設計・開発・テスト・運用に携わり、大規模なリニューアルのリリースに貢献できました。
また、大量のリクエストを捌いて大量のデータを扱う技術のノウハウを得ることができ、BEエンジニアとしての知見を高めることができました。

運用設計ではSplunkについて紹介しましたが、ログの発生推移から障害の予知をできるようにするなど、今後もより安定したサービス稼働を目指していきたいと思います。

※1 1カ月に1回以上「Yahoo!メール」にログインした利用者数の年間平均値。1つのYahoo! JAPAN IDにつき1人の利用者とした場合（2019年3月現在）