はじめに
こんにちは。食べログシステム開発本部 ウェブ開発1部 システム運用改善チームの@4palaceです。
今回は、私の所属するシステム運用改善チームで取り組んだサブドメインの廃止について事例を紹介します。 取り組みを通じて得られた学びなどを紹介します。 同じような課題に取り組むエンジニアにとって参考になれば幸いです。
目次
食べログにおける不要なSSLサブドメインとは
なぜSSLサブドメインが生まれたのか
食べログは2005年3月にサービスを開始し、今年20周年を迎えました。
これまで様々なWeb技術の変化とともにサービスを提供し続けてきました。
そのWeb技術の変化の一つとして、SSL通信があります。
現在では食べログ全てのページでSSL通信を適用していますが、過去は全ての画面でSSL通信を利用していたわけではなく、より通信をセキュアにしたい部分だけSSL通信を利用していた時代がありました。 このとき、SSL通信を利用する部分だけサブドメインとして切り出していました。
このサブドメインこそが、今回のテーマであるssl.tabelog.com(以下、SSLサブドメイン)です。
SSLサブドメインはSSL通信を適用するリクエストを受け付けるためWebサーバーを分けたものです。 Webサーバー通過後のアプリケーションサーバー側の処理は他のサブドメインと分けずに処理されてきました。
以下の図に簡単な処理の流れを示します。
PC・スマホともに、SSLサブドメインはSSLサブドメインを扱うWebサーバー、そうでないサブドメインは別のWebサーバーを経由します。
Webサーバー通過後のRails側のサーバー(アプリケーションサーバー)はどちらのWebサーバー経由であるかを気にせず、同じ処理を実行します。
Railsアプリケーション側の処理は共通化されており、Railsの実装ではSSLサブドメインのことを意識することなく実装できていました。
なぜいらなくなったのか
時は流れ、Webサービスをとりまく技術は変化してきました。
そのなかで、ある時期から全ての通信をSSL通信にすべき(常時SSL化)という風潮が優勢となりました。
食べログも例に漏れず、食べログ内のリンクURLをすべてhttpsのリンクに切り替え、常時SSL化しました。
このとき、SSLサブドメインで区別する必要はなくなり、SSLサブドメインやそれに対応するWebサーバーは不要になりました。
ですが変更影響が大きかったことや、残っていることでユーザーに対する悪影響があるものではなかったことから、
SSLサブドメインは生き残り続けていた、というのが実情です。
食べログが常時SSL化しても長らくSSLサブドメインは残った状態でした。
あると何が困るのか
不要なものが残り続けることで、エンジニア観点だと少しずつストレスになるような困るポイントがありました。
- SSLサブドメイン経由と、経由しない場合のアクセスログが分散してしまい、ログ調査の際に手間が増える
- アクセス数/レスポンスタイムの計測がSSLサブドメイン経由は別で集計されるので、計測値を集約しないと全体としての数値がわからない
- SSLサブドメイン経由のリクエストを実現するためのサーバー設定がカオスになっている
エンジニア側では明らかな課題であっても、企画側には見えにくく、なかなか案件化されませんでした。
そこで、エンジニア側から廃止を提案し、SSLサブドメイン撲滅プロジェクトが始動しました。
このような、機能開発に直接繋がらないシステムの改善活動も、食べログではエンジニアが起点となって取り組むことができます。
安全にサブドメインをクローズする
さて、このプロジェクトが成功するためには、なによりも「安全に」終わることが肝要です。
食べログは大量のトラフィックを処理しており、常時ユーザーからのリクエストがやってくるサービスで、 ひとつのサブドメインへのアクセスをなくすだけでも、大きなインシデントになりえます。
では「安全に」とはどういうことでしょうか？
ここでは、以下の2つの観点が担保されていることを「安全」と定義しました。
- 重要な機能が利用できない状態にならないこと
- 食べログのビジネスを止めないこと
重要な機能が利用できない状態にならないこと
食べログの機能の柱はいくつかありますが、その中でも特に重要な機能としたのは以下の3つです。
- お店探し(店舗の検索、お店の情報の確認)
- 口コミの確認(登録/閲覧含む)
- お店の予約(ネット予約)
修正によって、一時的にでもこれらの機能が利用できない状態になることは、 食べログの価値を直接的に毀損することに直結します。 このため、これらの重要機能を利用する画面の修正の場合は、リリース単位をテスト可能な単位に分割したうえで、 入念な結合テストを行いリリースすることを心がけました。
食べログのビジネスを止めないこと
食べログの一部機能は、利用者さまや店舗さまから料金を頂戴して提供しています。
具体的には以下のような機能が挙げられます。
- ネット予約
- プレミアムユーザーの課金登録(クレジットカード決済などを含む)
- 有料契約している店舗さまに提供している管理画面へのアクセス
こういった機能は食べログのビジネスを支える根幹であるため、サービスの運用上特に重要なものとして位置付けています。
今回の修正においても同様で、エラーが起きないように注意する必要があります。
移行前の準備と検証
対象の総量を把握
最初に取り組んだのは、具体的にSSLサブドメイン経由でアクセスのあったURLのリストアップです。
毎日大量にアクセスされるものから、滅多にアクセスされないものまで、そのアクセス頻度は差があります。
低頻度のアクセス経路を見逃さないようにするため、1日だけでなく一定期間のアクセスログを確認し候補をリストアップします。
アクセス種別ごとの工夫
アクセスログから、リファラーやアクセス時のIPからアクセス元を調べます。
アクセス元の種別で大きく分けて、以下8種類に分類できます。
- アクセス元が食べログサイト内 : 食べログサイト内での遷移
- アクセス元が食べログアプリ : 食べログアプリからWeb画面への遷移
- アクセス元がログイン連携先や決済提供サービス : 外部のサイトを経由して食べログに戻ってくる場合の遷移
- アクセス元が食べログのユーザーヘルプ : 食べログのユーザーヘルプからの遷移
- アクセス元が外部提携先 : 外部の提携先リンクからの流入
- アクセス元が食べログから送付したメール : メール内リンクからの遷移
- アクセス元が検索エンジン : 検索エンジンからの流入
- アクセス元がそれ以外 : ブックマークや個人ブログなどのその他経路からの流入
それぞれで工夫したポイントを紹介します。
1. アクセス元が食べログサイト内部のプログラム
サイト内部のプログラム間の遷移の場合は、基本的には通常の機能開発作業と大きく変わりません。
リクエスト元のプログラムで明示的にSSLサブドメイン経由でのURLを生成しているところがあれば、それを修正した上で問題なく動くことを確認します。
通常のサイト内遷移であれば、URL生成部分の修正を進めていくことで、SSLサブドメインの撤廃は進めることができます。
2. アクセス元が食べログアプリ
最新バージョンの食べログアプリの実装では、基本的にはほとんどがSSLサブドメイン経由のアクセスはありませんが、 アプリ独特の課題として、「修正前の過去バージョンからのアクセスをいつまでサポートするか」の観点があります。
もちろん、対応後のバージョンに全て置き換われば問題はないのですが、ユーザー側のサポートOSなどとの兼ね合いもあり、 「いつ・どのバージョンまでをサポートとするか」「どのバージョン以前は強制アップデート対象とするか」という問題はアプリ開発チームと連携をとって進める必要があります。
3. アクセス元がログイン連携先や決済の提供サービス
食べログは価格.comIDだけでなく、Yahoo! JAPANやXアカウント、LINE IDやApple Accountなど、 様々な外部連携ログインを利用してログインできます。 また、プレミアムサービスの支払い方法としてキャリア決済の手段を提供しています。
決済やログイン処理そのものは外部サービス側で行われるため、一度食べログの外部にリクエストが出た後、食べログに戻ってくる構造になっています。
こういったサイトはもともとHTTPS通信を前提としてログインを実現する必要があったため、SSLサブドメインが利用されたままになっていました。
同じサイト内の遷移であっても、このパターンでは外部連携先に設定画面を持っていてURLを設定する必要があったり、
戻り先のコールバックURLを生成してAPIに渡す必要があります。
このため、外部サイト側の各種設定画面を全て確認して必要なコールバックを登録したり、
APIに設定するURLを切り替えて正しく外部連携が機能するかを確認します。
外部連携や決済連携は開発環境だけで確認できないことも多いため、本番環境に近いステージング環境を確保して確認したり、
キャリア決済は実機での確認が必要になります。
こういった細かなテストの積み重ねを行なった上で、なるべく全ケースのログイン/決済をカバーし、
SSLサブドメインの利用撤廃を進めました。
食べログにおいて、外部決済周りは特にビジネス上重要なため、 「食べログのビジネスを止めない」という観点で気を付けるべきポイントです。
4. アクセス元が食べログのユーザーヘルプ
同じ食べログサイト内部での遷移ではありますが、食べログのユーザーヘルプに記載されている内容はエンジニアが触ることはできず、
CS部門の管理となります。
https://help.tabelog.com/
ヘルプサイトには、ログインやキャリア決済などの説明も記載されており、
その中でSSLサブドメインのURLを含んだヘルプ内容が記載されていることもありました。
これに対しては、CS部門に記載内容の全内容の出力をしていただき、置き換える必要があるURLを精査しました。
その上で変更内容をCS部門の方に再度連携し、データを修正をしてもらうことで対応しました。
5. アクセス元が外部連携先(業務委託先など)
食べログは当社グループのサービスだけでなく、社外のサービスやWebサイトにリンクを貼ってもらっていたり、業務を委託しているケースがあります。 その委託先からアクセスするときのURLがSSLサブドメイン経由となっており、かなりの数のアクセスが記録されていました。
また、外部連携サービスから食べログの特定のWebAPIを呼び出しているケースがあり、そのWebAPIの指し先がSSLサブドメインとなっていたことがありました。
このケースでは社内のエンジニアだけでは対応できないため、社外のサービスと連絡が取れる方に相談したうえで連絡をとっていただき、アクセス先の変更を依頼しました。
API連携のケースなど、いきなり本番に向けたアクセスを切り替えるのはリスクがあるため、ステージング環境を提供して切り替えアクセスできるか確認をしていただきながら対応します。
社外の業務が止まってしまうと問題なので、ここは慎重に行います。
これも「食べログのビジネスを止めない」ために気を付けるべきポイントです。
6. アクセス元が食べログから送付したメール
食べログがかつて送信したメールには、SSLサブドメイン入りのURLを本文に含んでいたケースがあります。 新規に送付するメールには含まれないようにしつつ、過去に送ってしまったメールに関しては関与できないので、一定期間経過後の古いメールに含まれていたものは仕方がないとして切り替えました。
7. アクセス元が検索エンジン
実は食べログは検索エンジンからの流入が強く、SEOの強みがそのまま食べログの強みとなっています。 この事情を踏まえると、できる限り検索エンジンの流入に悪影響を与えないようにする必要があります。
悪影響を防ぐために、よりSEO観点で重要な店舗一覧画面や、店舗詳細画面に関しては、 SSLサブドメイン経由でのアクセスがあった場合は正しいURL(SSLサブドメインなしのURL)にリダイレクトさせる処理を一定期間設けることとしました。 正しいURLを検索エンジンに伝えるリダイレクト期間を設けることで、検索エンジンからのSSLサブドメイン流入は減少していきました。
とはいえ、完全にゼロにすることは難しいので、ある程度のリダイレクト対応期間を経た上でそれでも残った検索エンジンのアクセスは大勢に影響なしと判断し切り替えることとしました。
8. アクセス元がそれ以外
最後に残るのは直リンクやブックマーク経由など、リファラを持たないアクセスでした。
どうしてもリクエスト元が特定できないものは、最終的にはそのまま切り替えるしかありません。 これも大勢に影響なしと判断し切り替えることとしました。
切り替え全体における工夫
アクセス元の種類ごとに気を付けるポイントを述べてきましたが、共通する注意点は「一度のリリースで大きく切り替えない」ことです。
全てを一気に切り替えると、それだけでテストも大きくなるため、テストで修正したあとの再テスト工数も無視できません。
コードチェック側の負担も大きくなるため、コードのミスを見逃す可能性も高くなります。
また、意味のある機能ごとにリリース単位をまとめることで、企画や外部連携先などのステークホルダーとの調整コストも下がります。
リリース後確認なども調整がしやすいため、意味のある小さな単位ごとにリリースすることを心がけました。
この段取りを最初にうまく設定しておくことで、後からの手戻りが発生しづらく、また着実に進めることができました。
移行
こうして入念な下準備と段取りを元に段階的に切り替えを進めた結果、目立った事故なくSSLサブドメインの廃止を完遂できました。
懸念されていた「重要な機能が利用できない状態にならないこと」「食べログのビジネスを止めないこと」という事故も発生せず、安定的にサービスを提供し続けることができました。
結論だけ言えばひとつのサブドメインをなくしたにすぎませんが、エンジニア観点ではメリットが大きく、 調査やインフラ管理コストの軽減など、長期的にはメリットの大きな改修となりました。
おわりに
食べログは本年で20周年を迎えます。
長期に渡りご愛顧いただけるWebサービスの開発に携わることができることはそれだけで幸せなことですが、
その信頼を得るためには、安定的なサービス提供を実現できるような継続的なシステム改善が欠かせません。
エンジニア視点でシステムの改善点を見つけ、提案し、企画を巻き込んで主体的に進めることができるのも、食べログエンジニアの1つの魅力だと感じています。
振り返ってみると、自チームのエンジニアだけでは成功できませんでした。
他チームのエンジニアだけでなく、企画や外部の連携先など、多くの方々をうまく巻き込んで進められたことが影響しています。
最後に、食べログでは一緒に働く仲間たちを募集しています！
食べログは、よりよいサービスを提供するためなら技術的な挑戦ができる環境です。
食べログで働いてみたいと感じてくださった方は、以下の採用情報のリンクから是非応募してみてください！！
