おはようございます、技術部 中野です。
シナプスでは、2011年10月1日から提供していた「シナプスWi-Fiスポット」を2024年2月29日をもって提供終了しました。
私にとってこのサービスは、企画から設計・開発まで担当しサービスをゼロから立ち上げたものだったため、思い入れも深いものでした。
サービスは終了となりましたが、その足跡を残すためにも今回はこの「シナプスWi-Fiスポット」の裏側について、書いてみます。
「シナプスWi-Fiスポット」とは
シナプスWi-Fiスポットは、いわゆる公衆無線LANサービスで、以下のようなものでした。
- Wi-Fiスポットの利用者
- 事前登録なく、利用開始時の利用規約への同意のみで無料で利用可能
- 利用規約の次のページで、設置先の店舗等の情報(テキストと画像によるPR情報など)が閲覧可能
- 無線アクセスポイントの設置先
- 光回線をご契約されているカフェや美容室などに、シナプスが用意した無線アクセスポイントを設置
- 設置先においては、お客様に対してフリーWi-Fiの提供が可能となり、集客力向上として利用
- Wi-Fiスポットの利用者に対して、設置先の情報(テキストと画像によるPR情報など)を提供
無線アクセスポイントについて
シナプスWi-Fiスポットの無線アクセスポイントは、市販されている家庭用のWi-Fiルータを採用していまして、そのメーカーに依頼してシナプスWi-Fiスポット用のカスタムファームウェアを開発していただきました。
無線アクセスポイントはサービスの肝となる部分でしたので、サービスの企画開始時より、自由度が高く、より安価なものを探しまして、たくさんのメーカーに打診をして、ようやく1社より快諾をいただき開発いただきました。
スペックなど
ベースとなった無線アクセスポイントは2011年当時に市販されているもので、今となってはスペック不足が否めませんが、12年の間、想定よりも低い故障率で頑張ってくれていました。
| 項目 | 内容 |
|---|---|
| 対応規格 | IEEE802.11n、IEEE802.11g、IEEE802.11b |
| 周波数帯 | 2.4GHz帯 |
| 伝送速度 | 最大300 Mbps |
| セキュリティ | WEP(64/128bit)、WPA-PSK(TKIP/AES)、WPA2-PSK(TKIP/AES) |
カスタムファームウェア
前述のとおりシナプスWi-Fiスポットに必要な機能について追加実装したカスタムファームウェアを、メーカーに依頼して開発していただきました。
追加した主な機能は、以下のとおりです。
- 無線アクセスポイント設定をサーバから取得してアクセスポイント本体に反映する機能
- ファームウェアをサーバから取得してアップデートする機能
- 無線アクセスポイントとサーバ間で連携して、無線端末の認証を行う機能
- ブラウザ認証
- MACアドレス認証
- 無線アクセスポイントに接続中の無線端末の情報をサーバに通知する機能
- 無線端末の強制切断機能
この中の「無線アクセスポイントとサーバ間で連携して、無線端末の認証を行う機能」について説明します。
無線アクセスポイントは「接続情報収集サーバ」「認証確認サーバ」「Web認証サーバ」「MACアドレス認証サーバ」と4つのサーバと連携して、無線アクセスポイントに接続してきた無線端末の認証可否の制御を行っていました。
ただし、実際にはこの4つのサーバ群は、将来、負荷を分散させるために分割可能にしておいたもので、実際には1つのサーバに混在させていました。
認証の流れは以下のとおりとなります。
- 無線アクセスポイントは、無線端末にDHCPにて割り当てていないIPアドレスについては、初期状態ではアクセス制限状態となっている
- 無線端末が無線アクセスポイントに接続し、無線アクセスポイントはDHCPにてIPアドレスを割り当てつつ、無線端末のMACアドレスが許可されたものかを確認するために「MACアドレス認証サーバ」に問い合わせ。MACアドレス認証がとおればアクセス制限を解除し、とおらなければアクセス制限を維持
- 無線端末は、OSの「Captive Portal Detection」の仕組みにより、OSのミニブラウザにて「Web認証サーバ」のページを表示する。無線アクセスポイントは、「認証確認サーバ」にHTTPでアクセスし、無線端末のWeb認証の完了を確認のため、ロングポーリングして応答を待つ
- 無線端末が「Web認証サーバ」で認証を終えると、「認証確認サーバ」から無線アクセスポイントに応答が戻り、無線端末のIPアドレスのアクセス制限を解除する
- 無線端末はインターネットへのアクセスが可能となる
サーバ側の構成について
サーバ側の構成は、以下のとおりとなっています。
前述の「接続情報収集サーバ」「認証確認サーバ」「Web認証サーバ」「MACアドレス認証サーバ」の4つの機能を1つのAppサーバ内に実装しています。
各サーバの用途としては、以下のとおりです。
| サーバ | 用途 |
|---|---|
| ロードバランサ | HTTP(80/tcp, 443/tcp)とsyslog(514/udp)のトラフィックをAppサーバに振り分ける。DSR(Direct Server Return)方式のため、戻りパケットはAppサーバから直接応答 |
| Appサーバ | 無線アクセスポイントとの認証連携や、利用者のWeb認証、 設置先の情報(テキストと画像によるPR情報など)を配信 |
| DBサーバ | 無線アクセスポイントの設定情報や、認証情報、無線端末の接続ログを保管するデータベース |
今回は、このAppサーバの中の設置先の情報(テキストと画像によるPR情報など)の画像を配信する仕組みについて解説します。
無線AP設置先のお客様が画像をアップロードする仕組み
まずは、無線アクセスポイントの設置先のお客様がPR情報の画像をアップロードする仕組みから。
- 無線アクセスポイントの設置先のお客様は、お客様ポータルにログインし、PR画像ファイルをお客様ポータルにHTTP POSTにてアップロード
- お客様ポータルは、ロードバランサを経由して、特定の1台のAppサーバのApacheに対して、PR画像ファイルをWebDAVにてPUT
- AppサーバのApacheは、WebDAVにて受信したPR画像ファイルを指定されたファイルシステムに保存
このようにしてAppサーバ上にPR画像ファイルがアップロードされますが、この時点では1台のAppサーバにしかファイルが存在しないことになるため、次のPR画像ファイルを共有する仕組みで、複数台のAppサーバに展開されます。
複数のAppサーバ間でPR画像ファイルを同期する仕組み
1台のAppサーバにアップロードされたPR画像ファイルは、GlusterFSと呼ばれる分散ストレージにより、他のAppサーバに同期をします。
この環境ではReplicated Volumeを用いて全てのAppサーバ上に同じPR画像ファイルが配置されるようにしていました。
実際のGlusterFSは、サーバ・クライアント・Brick・Volumeなどの概念に基づいて分散ストレージが構成されていますが、簡略化して説明すると以下のような流れになります。
- GlusterFSは、ファイルシステムの更新状態(追加・変更・削除)を監視
- アップロードされたPR画像ファイルは、GlusterFSにて検知される
- GlusterFSは、他のGlusterFSのノードにファイルを転送
- ファイルを受け取ったGlusterFSは指定されたファイルシステムに保存
画像ファイルを動的にリサイズして配信する仕組み
アップロードされたPR画像ファイルは、Wi-Fiスポットの利用者の利用開始時に無線アクセスポイントの設置先の情報(テキストと画像によるPR情報など)として表示されるようになっています。
Wi-Fiスポットを利用する際のデバイスは、パソコン/スマートフォン/タブレットなどに分類され、そのデバイスに応じてPR情報はレイアウトを変更し、またPR画像ファイルはデバイスやページに応じて、指定した画像サイズにApacheのモジュールである「mod_small_light」にてリサイズして配信するようにしていました。
具体的な画像サイズと用途は以下のとおりです。
| 画像サイズ(横幅) | 用途 |
|---|---|
| 500 px | パソコン/タブレット用。1つの設置先の表示用の大きい画像 |
| 180 px | パソコン/タブレット用。複数の設置先の一覧表示用の小さい画像 |
| 280 px | スマートフォン用。1つの設置先の表示用の大きい画像 |
| 100 px | スマートフォン用。 複数の設置先の一覧表示用の小さい画像 |
サービス開始当初は、リクエスト毎にmod_small_lightにてリサイズをして配信をしていましたが、リサイズは高負荷な処理でした。そのため、一度リサイズした画像ファイルは一定期間キャッシュして配信するように構成を変更しました。
Wi-Fiアクセスポイントの利用者からのPR画像ファイルへのリクエストは以下のような流れで行っていました。
- Wi-Fiアクセスポイントの利用者からのPR画像ファイルのリクエストは、Apache(80/tcp, 443/tcp)が受け付ける
- Apacheはmod_rewrite/mod_proxyにて特定URLへのリクエストを、Nginx(81/tcp)にリバースプロキシ
- Nginxは、リクエストのあったPR画像ファイルがキャッシュされていればキャッシュを応答し、なければApache(mod_small_light)にリバースプロキシ
- mod_small_lightはPR画像ファイルの元ファイルを取得し、指定されたサイズにリサイズして応答
実際のAppサーバでは、以下のように設定していました。
Apache(mod_rewrite/mod_proxy)
RewriteRule ^/pr/images/(.+)$ http://127.0.0.1:81/pr/images/$1 [P,L]
Nginx(キャッシュとリバースプロキシ)
server {
listen 81;
proxy_cache cache-space;
proxy_cache_valid 200 302 2d;
proxy_cache_valid 404 1m;
location /pr/images/large/ {
proxy_pass http://127.0.0.1/small_light(dw=500,ds=s,jpeghint=y,info=0)/;
}
location /pr/images/small/ {
proxy_pass http://127.0.0.1/small_light(dw=180,ds=s,jpeghint=y,info=0)/;
}
location /pr/images/m-large/ {
proxy_pass http://127.0.0.1/small_light(dw=280,ds=s,jpeghint=y,info=0)/;
}
location /pr/images/m-small/ {
proxy_pass http://127.0.0.1/small_light(dw=100,ds=s,jpeghint=y,info=0)/;
}
}
Apache(mod_small_light)
<LocationMatch ^/small_light[^/]*/>
SetOutputFilter SMALL_LIGHT
</LocationMatch>
RewriteRule ^/small_light[^/]*/(.+)$ /pub/wifi.synapse.jp/original-primages/$1
まとめ
シナプスWi-Fiスポットがサービス提供を開始した2011年10月はiPhone 4Sが販売開始された頃で、より多くの方々がスマートフォンを利用しはじめていくタイミングでもあり、サービス利用におけるPC/スマートフォンの比率は、少しずつスマートフォンの比率が高まっていくのを実感するサービスでもありました。
そういった中で、「WebDAV」「GlusterFS」「Nginx」「mod_small_light」など複数の技術の組み合わせて使い、2011年当時としてはちょっと尖った構成であり、サービスの規模やアクセス数に対してオーバーエンジニアリングでもありましたが、技術的には楽しめたサービスでした。
家族で、このシナプスWi-Fiスポットが設置されている場所に訪問した際に、子供より「あそこにWi-Fiあったよ」と言われて「それは俺が作ったサービスだよ」というと、子供から「すげー」と言われたのはいい思い出で、家族に誇れるサービスを作ったことは技術者冥利に尽きるものでもありました。
シナプスでは、今後も多くの方々にご利用いただけるようなサービスが提供できるよう、技術面なチャレンジをしてまいります。
