株式会社MIXIで
みてねは2017年より海外でもサービス展開していまして、1,500万人を超えるユーザに175の国と地域でサービスを提供しています。そのうち3割以上が海外ユーザになります
事業としても市場規模の大きさから海外ユーザをもっと伸ばしていくことに注力しており、その中でSREグループは
本記事では、世界中の家族が快適に使うために行ってきたことの一部を紹介させていただきます。
これまでの改善の歴史
2017年：海外展開スタート
2015年のサービスリリース当時、みてねのバックエンドインフラはAWSの東京リージョンで構築していました。
そして2017年より海外展開を開始しましたが、当時はまだ開発チームがインフラの構築や運用も行っていたこともあり、海外向けの特別な対策は殆ど行われておりませんでした。まずはリリースするという当時の判断は正しかったと思いますが、海外から利用されるユーザにとっては相当ストレスのかかるアプリだったに違いありません。
2018年～：SREチーム設立後、海外本格対応
みてねにSREチームが
この頃からユーザの近くにインフラを構えるという構想はありましたが、非常に難易度も高く当時は現実的な案ではありませんでした。
この当時に整理した課題として、海外展開はネットワークレイテンシとの戦いであると結論づけましたが、それは今も続いています。
現実的に可能だった改善方法として、主にネットワークの最適化とAPIリクエスト回数を減らす施策を行ってきました。とくにCloudFrontを経由する構成に変更することで、SSL/
当時取り組んだ施策については資料として公開していますので参考にしていただけますと幸いです。
とはいえ、それでも地理的に距離が遠い地域では日本と比べるとまだまだストレスを感じるのは否めませんでした。
2019年～：初期本格対応による改善効果
依然として海外のアクセス改善は課題としてありましたが、2018年に取り組んだ施策である程度は改善できたということもあり優先度は一旦下げつつ、他の様々な施策・
2022年～：マルチリージョン化完了、現在
このころには組織上ではSREグループとなり、人数も6人まで増えました。
2021年にEKSへの移行が完了してかつ安定的に運用できており、マルチクラスタによるマルチリージョン化が比較的容易に実現できそうという期待がSREグループ内で沸き起こり、6月よりプロジェクトが始まりました。
ブログでも紹介していますが、プロジェクト開始から約4ヵ月後の10月にマルチリージョン化が完了し、物理的にサーバから近くなった海外ユーザのAPIレスポンスは劇的に向上しました。
そして、マルチリージョン化によって前提条件が変わったことで、打ち手も増えてさらなる改善を進められるようになりました。
ここからその事例をいくつか紹介させていただきます。
リージョン振り分けのルーティングの効率化＆コストダウン
マルチリージョンのリリース時点では、ブログ記事に紹介しているようにLambda@Edgeでユーザのネットワーク情報から緯度経度を元にルーティングしていました。
しかし、精度の問題やLambda@Edgeのコストが高いという問題がありました。
これを解決する方法として、AWSの弊社担当ソリューションアーキテクトの方に相談させていただいたところ、Route53を用いたルーティングを提案いただき、
- CloudFrontを使うことによりAWSの高速なネットワークを経由しつつ
- Route 53のレイテンシールーティングポリシーでユーザから近いリージョンにルーティングする
というまさにみてねが望んでいたものが実現できました。
ただし、現時点ではDBへの書き込みは東京リージョンでしか対応していない構成になっているので、すべてをルーティングするわけにはいきませんでした。
そこはCloudFrontはBahaviorでパスパターン毎にOriginを指定できるので、下記の3種類のBehaviorを設定することで、必要なリクエストだけをバージニア北部に送る構成を実現しています。
- マルチリージョン対応のAPI→レイテンシベースでルーティング
- 同じパスでGET/
POSTを受けるがGETのみマルチリージョン対応のAPI→Lambda@Edgeでリクエストメソッドを判定 - GET→レイテンシベースでルーティング
- POST→東京リージョンに固定
- それ以外のAPI→東京リージョンに固定
マルチリージョン化のリリースからレイテンシベースのルーティングへの変更までのレスポンスタイムの変化はこちらになります。
- 10/
12にマルチリージョン化をリリースしたタイミングでUSのレスポンスが大きく改善したがJPのレスポンスは20msほど悪化 - 10/
26にレイテンシベースのルーティングに変更したタイミングでUS/ JP共にレスポンスが改善
ということがグラフから読み取れます。ここでは具体的な数字も出しませんが、Lambda@Edgeの実行回数を減らした分、コストもかなり下げることができました。
そしてレイテンシベースで自動的に振り分けてくれるので、今後さらにリージョンを増やす機会があったとしても、ルーティングに悩む必要がなくなったという点でも良い改善だったと言えるでしょう。
写真・動画データのDLの高速化
APIの速度は非常に改善できました。しかしそれだけではまだ不十分です。
みてねというアプリの特性として、大量の写真・
サムネイル画像のS3レプリケーション
みてねではサムネイル画像を数種類用意しており、そのうち一番小さなサムネイル画像についてマルチリージョン化しようと考えました。
これは最もアクセスの多い画像ですので、ユーザの体感に一番影響があると考えたためです。
リクエストの振り分けについても、APIでマルチリージョン化が実現できているので容易に可能です。
しかし、何十億という画像ファイルがありそれらすべてをS3の複数バケットにコピーするだけでも相当なコストがかかります。
海外ユーザのサムネイル画像だけをコピーするなど、様々な方法を検討しましたが結局コストやシステムの複雑さに対して効果が薄いとの判断で断念しました。
CloudFront Origin Shield導入
別の方針として、AWSの弊社担当ソリューションアーキテクトの方からOrigin Shieldを試してみると良いとの提案をいただきました。
CloudFront Origin Shieldとは、2020年10月に発表された、キャッシュレイヤをさらに一層追加して、キャッシュヒット率を高めることができるものです。オリジンのあるリージョン
CloudFront Origin Shieldの公式ドキュメントによると
ネットワークパフォーマンスの向上オリジンに対するレイテンシーが最も低い AWS リージョンで Origin Shield を有効にすることで、最良のネットワークパフォーマンスが得られます。AWS リージョン内のオリジンの場合、CloudFront のネットワークトラフィックは、オリジンに到達するまで高スループットの CloudFront ネットワーク上に留まります。
とありましたが、すでにCloudFrontを使っており、キャッシュレイヤーが増えるからと言っても地理的な距離が変わらないのでそれほど効果があるとは思っていませんでした。
しかし実際に検証してみたところ、思った以上にパフォーマンスが上がることがわかり、本当に驚きました。
とくに地理的に遠い地域からのレスポンスが劇的に向上したのがグラフから見て取れると思います。
90パーセンタイルで計測したグラフですが、イギリス
今さらの話ではありますが、この改善についてはマルチリージョン化とは関係ないため、もっと早くから取り組めばよかったなと思っているのが正直な感想です。
改善後のヒアリング
数値上の改善がどれだけ見られても、結局はユーザの体感が向上したかどうかが一番重要です。
以前みてねを開発していた元同僚がたまたまイギリス在住でしたので、これらの改善をリリースした後ヒアリングしたところ、非常に良い反応を頂きました。
こういった反応を頂けることが、エンジニアとして頑張ってきてよかったなと思える瞬間です。
まとめ
日本語でサービスを運営していると日本国内に住んでいるユーザが殆どなのであまり意識することはありませんが、グローバルサービスの体験向上には、ネットワークレイテンシを意識することが非常に重要です。
とくにマルチリージョン化は構築・
一方で、マルチリージョン化せずとも改善する方法はあります。本記事で紹介したCloudFront Origin Shieldなどまさに有効ですので、状況に合った方法で少しずつ改善していくことが大切です。
この記事を読んでいただいた方の参考になりましたら幸いです。